Présentation des processus cryptographiques¶
Date |
oct. 28, 2024 |
Rédigé par |
Hubert TOUVET, Vincent Cardon |
S’applique à WAPT |
>= 2.3.0.13180 |
Version du Document |
2.3.0.0-0 |
Hash Git |
b24964be6be4421227960d0415b2186ee469b746 |
Composants de la solution WAPT et spécification du mécanisme cryptographique¶
Les processus cryptographiques sont impliqués dans les activités suivantes :
Signature et vérification des fichiers contenus dans un paquet.
Signature et vérification des attributs d’un paquet.
Signature et vérification des actions immédiates sur les Agents WAPT.
Signature des inventaires et statut des Agents WAPT.
Communications Websockets entre les clients WAPT et le Serveur WAPT.
Communication HTTPS entre les clients WAPT et le Serveur WAPT.
Communications HTTPS entre la Console WAPT et le Serveur WAPT.
Communications HTTPS entre les clients WAPT et les dépôt WAPT.
Les versions des composants logiciels sont spécifiées dans la section « Liste des composants tiers intégrés dans le produit (COTS) » de l’objectif de sécurité.
Spécifications cryptographiques du Serveur WAPT¶
Le Serveur WAPT fonctionne sur une base de données PostgreSQL.
Service Nginx¶
Le Serveur Nginx sert les paquets vers les stations de travail clientes et agit comme un proxy inverse pour le Serveur WAPT. Il est configuré en TLSv1.3 avec les algorithmes de chiffrement EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH.
Matériel cryptographique utilisé |
Utilisation |
Spécifications |
Localisation |
Création / renouvellement |
|---|---|---|---|---|
clé privée du Serveur nginx https |
Console de connexion Serveur WAPT Connexions Agent WAPT - Serveur |
2048 bits. |
|
Serveur initial post-configuration |
certificat du Serveur nginx https |
Authentification du serveur Chiffrer les connexions https. |
Certificat X509 avec clé RSA Format :abbr:`PEM (Privacy Enhanced Mail) ` Durée 3 ans |
|
Serveur initial post-configuration Lors du renouvellement, il est nécessaire de distribuer le nouveau certificat de Serveur https aux Agents avec un paquet WAPT avant que le précédent n’expire. |
Clé Diffie-Hellman |
Échange initial de clés |
2048 bits |
|
Serveur initial post-configuration |
client https CA |
Authentification par certificat client pour les connexions https aux Agents WAPT et à la Console WAPT. |
Un magasin de certificats au format X509 contenant des copies des CA PKI Agents WAPT et CA PKI Administrateurs WAPT |
Défini dans |
Configuration initiale du Serveur et mise à jour manuelle à chaque fois que les CA PKI Agents WAPT et CA PKI Administrateurs WAPT |
Clients https CRL |
Permet à NGINX de vérifier que les certificats des clients n’ont pas été révoqués. |
Un fichier au format PEM Agents WAPT et CRL PKI Administrateurs WAPT |
Défini dans |
CRL magasin mis à jour toutes les heures par une tâche programmée sur le Serveur WAPT. Les fichiers clients_signing_crl CRL et *.crt au format :abbr:`PEM (Privacy Enhanced Mail) ` dans le répertoire défini par ssl_additional_crls sont concaténés pour être utilisés par NGINX. |
Table des clés kerberos |
Authentification des connexions à la Console WAPT. Authentification des enregistrements initiaux des Agents WAPT. |
SPN : HTTP/<fqdn du serveur WAPT> @<REALM> |
|
Keytab créé et extrait manuellement de AD. |
Pas de renouvellement automatique.
Service de Serveur WAPT¶
Pour les Agents WAPT, le service Serveur WAPT :
Gère l’autorisation et l’enregistrement initial des Agents WAPT et signe les CSR des Agents WAPT.
Vérifie l’authenticité et l’intégrité des informations d’état envoyées par les Agents WAPT.
Autorise les connexions Websockets.
Pour la Console WAPT, le WAPT :
Gère l’authentification de l’Administrateur WAPT et les autorisations d’accès aux données renvoyées par les Agents WAPT.
Matériel cryptographique utilisé |
Utilisation |
Spécifications |
Localisation |
Création / renouvellement |
|---|---|---|---|---|
PKI clé privée Agents WAPT. |
Signes Agent CSR lors de l’enregistrement initial et CSR pour les certificats clients temporaires pour l’accès https à la Console. |
2048 bits. |
Défini dans Défaut : |
Initialisé lors de l’installation du Serveur WAPT (postconf). |
CA PKI Agents WAPT. |
Certificat avec lequel les certificats des Agents peuvent être vérifiés. Ce certificat est utilisé par nginx pour l’authentification du certificat du client de l’Agent. |
Certificat X509 auto-signé et épinglé avec clé RSA. Format :abbr:`PEM (Privacy Enhanced Mail) `. Durée 3 ans. |
Défini dans Défaut : |
Initialisé lors de l’installation du Serveur WAPT (postconf). |
CA PKI Administrateurs WAPT. |
Certificats utilisés pour vérifier les certificats des administrateurs WAPT. Ce certificat est utilisé par waptserver pour autoriser l’envoi de paquets au Serveur. |
CertificatsX509 avec clé RSA. Format :abbr:`PEM (Privacy Enhanced Mail) `. Spécifications propres à l’organisation. |
Défini dans |
Fourni et géré par l’organisation. |
CRL PKI Agents WAPT. |
Stocke les numéros de série des certificats d’Agents WAPT interdits. |
Format :abbr:`PEM (Privacy Enhanced Mail) `. Durée 10 jours. |
Défini dans Défaut : |
Initialisé lors de la post-configuration. Alimenté et re-signé à chaque fois qu’un Agent WAPT est supprimé. Tâche automatique qui re-signe périodiquement la CRL. |
Certificats connus. |
Permet à la Console WAPT et aux Agents WAPT de reconstituer les chaînes de certificats (dans le cas d’autorités de certification intermédiaires). |
Défini dans Défaut : |
Les certificats sont automatiquement extraits des paquets lorsqu’ils sont envoyés au Serveur. Les certificats associés aux administrateurs sont également extraits lors de l’enregistrement des comptes utilisateurs. |
|
Compte administrateur secret. |
Pour l’authentification initiale de la Console WAPT pour le compte désigné wapt_user. |
Longueur minimale du mot de passe : 20 caractères. Complexité vérifiée. PBKDF2 dérivation de mot de passe avec 29000 itérations, hmac-sha256. |
Défini dans |
Initialisé lors de l’installation. Peut être modifié à partir de la Console WAPT par un Administrateur WAPT authentifié avec le même compte. |
Cookies de session secrets. |
Authentifie les appels au Serveur WAPT API après une connexion correcte. |
64 caractères ascii. |
Défini dans |
Réglé sur une valeur aléatoire lors de l’installation initiale. Non renouvelé automatiquement. |
Secret de cryptage du jeton. |
Authentifie les connexions Websockets de l’Agent (comportement déprécié, désactivé dans la configuration de la TOE). Authentifie le login pour l’application « Waptselfservice ». Les jetons sont générés lors de la connexion au Serveur si la configuration du serveur autorise la méthode « jeton » ou si l’appel de connexion spécifie explicitement qu’il veut un jeton au lieu d’un cookie de session. |
64 caractères ascii. |
Défini dans |
Réglé sur une valeur aléatoire lors de l’installation initiale. Non renouvelé automatiquement. |
Certificats de l’Agent WAPT. |
Authentification et vérification de l’intégrité des données envoyées par les Agents WAPT. Authentification des demandes de jetons websocket par les Agents WAPT (comportement déprécié, désactivé dans la configuration de la TOE). |
Certificat X509 signé par CA PKI Agents WAPT. Format :abbr:`PEM (Privacy Enhanced Mail) `. Durée du défaut 3 ans. Utilisation de la clé étendue : TLS Authentification du client Web. Utilisation de la clé : Signature numérique. |
Champ « host_certificate » Table « Hosts » dans la base de données wapt. |
|
Certificat d’administrateur WAPT. |
Liste des certificats personnels des administrateurs. |
Certificat X509 signé par l”CA. Format :abbr:`PEM (Privacy Enhanced Mail) `. Durée du défaut 3 ans. Utilisation de la clé étendue : TLS Authentification du client Web. Utilisation de la clé : Signature numérique. |
Champ « user_certificate » Table « WaptUsers » de la base de données wapt. |
Créé à partir de la Console WAPT. Attribué à un compte administrateur WAPTFonction « gestion des utilisateurs et des droits WAPT » de la Console WAPT. |
Empreintes de certificats Administrateur WAPT. |
Autorisation d’accès au Serveur WAPT API après authentification réussie du certificat du client par le Serveur Nginx si la méthode « ssl » est activée dans la configuration du Serveur (non activée dans la configuration de la WaptselSFervice). |
empreinte sha1 du certificat de l’administrateur. (Un sha1 est utilisé ici, car il s’agit de l’information fournie par le module d’authentification SSL de nginx). |
Champ « user_fingerprint » Table « WaptUsers » de la base de données wapt. |
Extrait du certificat de l’administrateur lors de l’attribution du certificat au compte dans la Console WAPT. |
Spécifications cryptographiques du poste de travail de l’administrateur hébergeant la Console WAPT¶
Matériel cryptographique utilisé |
Utilisation |
Spécifications |
Localisation |
Création / renouvellement |
|---|---|---|---|---|
CA https Serveurs |
Vérification du certificat https du Serveur WAPT. Vérification Certificat https du dépôt WAPT |
Stockage de certificats X509 au format PEM (Privacy Enhanced Mail) ` (extension :mimetype:.crt`). Chaque fichier .crt peut contenir plusieurs Serveurs https approuvés CAs. |
Le chemin vers le magasin de confiance est spécifié par l’attribut verify_cert dans le fichier Les fichiers sont stockés dans le répertoire |
Lors du premier lancement de la Console WAPT, les magasins et la configuration de l’agent sont copiés. |
CA système |
Vérification du certificat pour les connexions https si l’attribut verify_cert est égal à 1 |
Magasin de certificats X509 au format :abbr:`PEM (Privacy Enhanced Mail) `. |
Fichier |
Extraction automatique à partir des magasins CA et ROOT de CERTSTORE du système CA de confiance utilisé pour vérifier les certificats https. 1h de cache |
Paquets de clients et actions |
Authentification des paquets importés ou édités |
Un fichier de chaîne de certificats X509 au format :abbr:`PEM (Privacy Enhanced Mail) ` par :abbr:`CA (Autorité de Certification) approuvée. Le premier certificat de chaque fichier est approuvé (utilisation de la clé : signature numérique), les autres sont des CA intermédiaires (contrainte de base : CA, utilisation de la clé : signature du certificat). |
Défini dans le fichier ini Défaut : Certificat de l’administrateur WAPT |
L’administrateur de WAPT copie les certificats pour approbation. |
Certificat d’administrateur WAPT |
Signature du paquet Signature des actions à distance sur les Agents WAPT authentification https sur le Serveur Nginx |
Chaîne de certificats X509 au format :abbr:`PEM (Privacy Enhanced Mail) ` Le premier certificat est celui de l’administrateur, les autres sont des autorités de certification intermédiaires. Caractéristiques du certificat d’administrateur WAPT : Utilisation de la clé : Signature numérique, non-répudiation, chiffrement des données Utilisation de la clé étendue : TLS Authentification du client Web Si l’administrateur est autorisé par l’organisation à signer des paquets contenant du code python, le certificat doit également avoir : Utilisation étendue des clés : Signature de code |
|
Créé et renouvelé par l’organisation. |
Clé privée de l’administrateur WAPT |
Signature des paquets WAPT. Signature des actions aux Agents WAPT |
Signature par cRSA 2048 bits, format PKCS#8 codé pour le mot de passe. Dérivation du mot de passe PBKDF2 avec 800 itérations, cryptage hmac-sha256.AES-256-CBC Type de signature de partage et de paquet : RSA-SHA256 sans remplissage |
|
Créé par l’organisation. |
Ticket Kerberos Session Windows Administrateur WAPT |
Authentification initiale (login) au Serveur WAPT |
Session Windows |
||
Mot de passe de la clé |
Décryptage de la clé privée de l’Administrateur WAPT pour signer les actions et les paquets |
Conservé crypté dans l’espace mémoire de la Console WAPT par un secret éphémère également présent dans la mémoire de la Console WAPT et par un secret aléatoire spécifique à la session de l’utilisateur et stocké dans le répertoire privé de l’utilisateur. |
||
Mot de passe du compte administrateur WAPT |
Authentification initiale (login) au Serveur WAPT |
idem |
||
Certificat de la Console WAPT |
Authentification https du client au Serveur Nginx pour la session de la Console. |
Certificat X509 temporaire au format PEM PKI Agents WAPT. Période de validité égale à la durée des cookies de session. |
Répertoire temporaire de l’utilisateur |
Signé par les CA PKI Agents WAPT sur le serveur après une authentification Kerberos réussie de la Console. |
Clé privée Console WAPT |
Authentification https du client au Serveur Nginx pour la session de la Console. |
Clé RSA temporaire cryptée de 2048 bits. Format PKCS#8 crypté par un mot de passe aléatoire de 120 caractères crypté en mémoire par la clé de session. Dérivation du mot de passe PBKDF2 avec 800 itérations, hmac-sha256. Chiffrement AES-256-CBC |
Répertoire temporaire de l’utilisateur |
Généré par la Console à chaque fois que vous vous connectez. |
Spécifications cryptographiques pour les postes de travail clients équipés de l’Agent WAPT¶
Agent WAPT¶
Matériel cryptographique utilisé |
Utilisation |
Spécifications |
Localisation |
Création / renouvellement |
|---|---|---|---|---|
CA https Serveurs. |
Vérification du certificat https du Serveur WAPT. Vérification du certificat https du dépot WAPT. |
Stockage de certificats X509 au format PEM (Privacy Enhanced Mail) ` (extension :mimetype:.crt`). Chaque fichier .crt peut contenir plusieurs Serveurs https approuvés CAs. |
Le chemin d’accès au magasin de confiance est spécifié par l’attribut verify_cert dans le fichier wapt-get.ini de l’Agent. Les stocks sont stockés dans le répertoire |
Déployé initialement lorsque le WAPTagent est installé sur le poste de travail du client. Ajouté ou mis à jour par paquets WAPT de configuration dynamique. Supprimé par un paquet WAPT. |
CA système. |
Vérification du certificat pour les connexions https si l’attribut verify_cert est égal à True. |
Magasin de certificats X509 au format :abbr:`PEM (Privacy Enhanced Mail) `. |
Fichier |
Extraction automatique à partir des magasins CA et ROOT de CERTSTORE du système CA de confiance utilisé pour vérifier les certificats https. 1h de cache. |
Paquets de clients et actions. |
authentification et autorisation des paquets. Authentification et autorisation des actions. |
Chaîne de certificats X509 au format :abbr:`PEM (Privacy Enhanced Mail) `. Le premier certificat de chaque fichier est approuvé, les autres sont des CA intermédiaires. Type de signature pour les actions et les paquets : Algorithme RSA-SHA256 sans remplissage appliqué au condensat sha256 des données sérialisées. La fonction « Code signing » du certificat est utilisée pour autoriser ou non l’exécution du code python dans le paquet. |
|
Déployé initialement lorsque l’Agent WAPT est installé sur le poste de travail du client. Ajouter ou mettre à jour les paquets WAPT configurés dynamiquement. Processus de signature d’un paquet WAPT. |
Certificats de l’Agent WAPT. |
Authentification https du client au Serveur Nginx Signature des données d’inventaire. |
Certificat X509 au format PEM PKI Agents WAPT. |
|
Signé lorsqu’un Agent WAPT est enregistré après une authentification Kerberos réussie de l’Agent. |
Clé privée Agent WAPT. |
Authentification https du client au Serveur Nginx Signature des données d’inventaire. |
Clé RSA 2048 bits non chiffrée. |
|
Généré par l’Agent WAPT lors de l’installation ou lorsque l”:abbr:`UUID (Universally Unique IDentifier)`de l’Agent est modifié. |
Agent secret WAPT. |
Chiffrer les jetons d’authentification pour les applications locales. |
Chaîne aléatoire de 64 caractères. |
|
Généré aléatoirement lors de l’installation de l’Agent. |
Applications client locales : waptexit, waptself, wapttray¶
Matériel cryptographique utilisé |
Utilisation |
Spécifications |
Localisation |
Création / renouvellement |
|---|---|---|---|---|
Token Applications locales |
Authentification des actions locales sur l’Agent WAPT initiées à partir d’applications locales (sur la même machine que l’Agent WAPT). |
Jeton JWT daté Algorithme : HS512 Validité : 24 heures Contenu : nom d’utilisateur et groupes. |
Mémoire d’application locale. |
Après avoir authentifié les applications locales auprès de l’Agent WAPT, ce dernier génère un jeton pour authentifier les actions suivantes. |
Ticket Kerberos Utilisateur de la session Windows. |
Session Windows. |
FS1. Communications sécurisées¶
L’Agent WAPT, le Serveur WAPT et le Console WAPT utilisent à la fois du code Python interprété et du code compilé Lazarus / FPC.
Le code Lazarus / FPC utilise le framework mORMot (>= 2.0.4383) pour la gestion du protocole https, la gestion du client kerberos, les opérations sur les certificats X509, et les opérations cryptographiques (Hash, RSA).
Le framework mORMot est lui-même configuré et lié pour utiliser la bibliothèque OpenSSL pour les sockets TLS, les opérations RSA asymétriques (génération de clés, cryptage, décryptage, signature, vérification), et les opérations de certificats X509.
Le code Python (Agent WAPT, Serveur WAPT, paquets WAPT) est lié aux mêmes bibliothèques OpenSSL 1.1.1s 1 Nov 2022 et utilise les modules suivants :
les modules python cryptographie==3.3.2 et pyOpenSSL==20.0.1 liés à openssl 1.1.1s : utilisés pour toutes les opérations cryptographiques RSA, les générations de certificats X509 et les vérifications de signatures dans l’Agent WAPT en python.
winkerberos (agent Windows) / Kerberos (agent Linux) et requests-kerberos : utilisés pour authentifier l’Agent WAPT lorsqu’il s’enregistre pour la première fois auprès du Serveur WAPT.
Certifi : le paquet de certificats de l’autorité utilisé pour la validation des certificats est le magasin de certificats du système d’exploitation qui exécute l’Agent, la Console ou le Serveur (certstore Windows sous Windows et /etc/ssl/certs/ sous Redhat).
Toutes les communications entre les Agents WAPT et le Serveur WAPT utilisent le protocole https. Le sServeur Nginx utilise la couche TLS du système. Le certificat utilisé pour chiffrer la connexion https est généré et configuré par l’organisation dans le cadre de son ICP https interne.
FS2. Identification, authentification et contrôle d’accès¶
Enregistrement initial de l’Agent WAPT¶
Après l’installation, l’Agent WAPT effectue un enregistrement initial sur le Serveur WAPT. L’enregistrement initial correspond à la création d’un certificat client, qui sera utilisé pour authentifier l’Agent WAPT :
Authentification de l’Agent sur le Serveur WAPT (Kerberos ou login/mot de passe).
L’agent crée une paire de clés publiques/privées et envoie un CSR au Serveur WAPT.
Le Serveur signe le CSR avec la CA « machine ».
Enregistrement par le Serveur du certificat public de l’Agent et de son identifiant (Bios UUID par défaut).
La PKI CA des Agents WAPT est une CA interne de WAPT utilisée uniquement pour signer les CSR lors de l’enregistrement des postes de travail et pour valider l’authentification des Agents WAPT sur le Serveur WAPT par la suite. Il est généré lors de l’installation du Serveur WAPT avec une clé de 2048 bits. Il est indépendant de la PKI CA de l’Administrateur WAPT ou du client https CA.
Un fichier CRL est généré et rempli lorsqu’une machine est supprimée de l’inventaire WAPT.
Les Agents PKI WAPT CA et PKI WAPT CRL sont intégrés dans le service Nginx, qui gère l’authentification des certificats des clients.
Cela signifie que seules les machines qui ont été correctement enregistrées sur le Serveur WAPT et qui n’ont pas été supprimées peuvent accéder au dépôt de paquets.
L’URL d’enregistrement initial du poste de travail n’est pas protégée par l’authentification du certificat du client Nginx.
Pour l’authentification initiale du poste de travail lors de l’enregistrement, le poste de travail utilise le compte Kerberos de la machine pour récupérer un ticket de service pour le service WAPT, qui sera ensuite utilisé pour authentifier l’agent pour l’enregistrement avec le serveur. Une fois le poste de travail enregistré et le certificat client signé, l’Agent WAPT n’utilise plus Kerberos, mais uniquement l’authentification par certificat sur le Serveur WAPT.
Connexion websocket de l’Agent¶
Les connexions websockets de l’Agent se font sur le même canal https que les autres connexions, avec une mise à niveau après le premier échange. L’Agent WAPT utilise son certificat d’Agent WAPT pour s’authentifier sur le Serveur Nginx. Si l’authentification échoue, l’Agent tente de se réenregistrer (voir le paragraphe précédent).
Pour rappel, aucune connexion n’est établie entre le Serveur et les Agents.
Connexion de l’Agent pour un retour d’information sur l’inventaire¶
Les inventaires sont téléchargés via une connexion https. L’authentification est effectuée avec le certificat de l’Agent WAPT par le Serveur Nginx. En cas d’échec de l’authentification, le poste de travail tentera de se réenregistrer.
Connexion des Agents pour le téléchargement des paquets¶
l’index des paquets et les paquets sont téléchargés via la connexion https. L’authentification est effectuée avec le certificat de l’Agent WAPT par le Serveur Nginx.
Authentification du Serveur par les Agents¶
Le client authentifie le Serveur WAPT à l’aide du Serveur https CA.
Authentification du (des) dépôt(s) par les Agents¶
Le poste client authentifie le référentiel WAPT à l’aide du Serveur https CA.
Actions à distance sur les Agents¶
Il est possible, à partir de la Console WAPT, d’envoyer des actions aux Agents WAPT, telles que « mettre à jour la liste des mises à jour disponibles », « lancer l’installation des mises à jour disponibles », etc. Ces différentes actions sont initiées à partir de la Console WAPT et relayées par le Serveur WAPT vers les agents via la websocket existante. Ces différentes actions sont initiées par la Console WAPT et relayées par le Serveur WAPT vers les Agents via le websocket existant.
La communication entre la Console et le Serveur WAPT se fait via le canal https. La communication entre le Serveur WAPT et l’Agent WAPT s’effectue par l’intermédiaire du websocket préalablement mis en place par l’Agent.
Authentification de l’administrateur sur la Console WAPT¶
Après l’installation du Serveur WAPT, la première authentification est effectuée en utilisant le compte « admin » et le mot de passe saisi lors de l’exécution de postconf. Ce compte est utilisé pour terminer la configuration et définir ACL pour les comptes d’administration de WAPT définis dans Active Directory. Après cette configuration initiale, le compte ACL « admin » peut être assigné à des comptes Active Directory nommés.
L’authentification sur le Serveur WAPT utilise ces comptes de domaine.
En outre, l’accès au Serveur WAPT et au référentiel WAPT est protégé sur le Serveur Nginx par une authentification par certificat client basée sur les Agents WAPT PKI CA.
FS3. Protection des données¶
Les fonctions de protection des données n’utilisent pas de procédures cryptographiques et reposent entièrement sur la sécurité du système de fichiers.
FS4. Fonctions cryptographiques : Authenticité et intégrité¶
Signature des attributs du fichier de contrôle¶
Lors de la signature d’un paquet WAPT, les attributs sensibles du paquet sont répertoriés dans l’attribut signed_attributes.
Les attributs énumérés dans signed_attributes sont signés avec la clé privée de l’administrateur et la signature est stockée dans l’attribut signature du fichier de contrôle.
Le certificat associé à cette clé privée est stocké dans le fichier :<wapt>certificate.crt à l’intérieur du paquetage WAPT.
Sur le Serveur WAPT, lors de l’opération wapt-scanpackages (déclenchée par l’ajout ou la suppression d’un paquet), l’index Packages est régénéré.
Le Serveur WAPT extrait le certificat du signataire de chaque paquet et l’ajoute au fichier ZIP Packages, dans le répertoire <wapt>/ssl. Chaque certificat est nommé avec son empreinte digitale codée en hexadécimal.
Lorsque l’Agent WAPT effectue une mise à jour, il télécharge le fichier d’index des paquets, qui contient à la fois les attributs signés de tous les paquets et les certificats des signataires. Si le certificat du signataire des attributs d’un paquet est approuvé (ce qui signifie que le certificat est signé par une autorité de certification ou que le certificat lui-même est fiable) ET que le certificat du signataire peut vérifier la signature des attributs, le paquet est ajouté à l’index des paquets disponibles, sinon il est ignoré.
Signature des paquets WAPT¶
Lorsqu’un administrateur ou un développeur de paquet construit une WAPT :
Un fichier <wapt>/manifest.sha256 est créé, qui liste les sommes de contrôle de tous les fichiers du paquet.
Un fichier signature.sha256 crypté avec la clé privée est alors créé dans le dossier WAPT, contenant la somme de contrôle du fichier <wapt>/manifest.sha256.
Tous les fichiers sont archivés au format ZIP avec l’extension .wapt.
Lorsqu’un Agent WAPT télécharge un paquet WAPT, il vérifie que le fichier signature.sha256 a été signé avec la clé privée correspondant au certificat <wapt>/certificate.crt du paquet.
L’Agent WAPT vérifie ensuite que le certificat (ou la chaîne de certificats) certificate.crt a été signé avec une clé privée correspondant à l’un des certificats du dossier <wapt>ssl.
L’Agent WAPT vérifie ensuite la somme de contrôle de tous les fichiers du paquet (à l’exception des fichiers signature.sha256 et certificate.crt) et s’assure que la somme de contrôle correspond au fichier <wapt>manifest.sha256 contenu dans le paquet.
Si l’une de ces étapes n’est pas validée, cela signifie qu’un fichier a été modifié / ajouté / supprimé. Dans ce cas, l’exécution de setup.py est annulée.
Le paquet défectueux est alors supprimé du cache local ; l’événement est signalé dans les journaux de l’Agent.
FS5. Protection contre les manipulations¶
Signature « Microsoft Authenticode » pour les binaires et les programmes d’installation.¶
Nous utilisons le mécanisme standard intégré dans Windows. Les binaires sont signés dans la chaîne de construction avec un certificat Extended Validation « Code signing » délivré par une autorité validée par Microsoft.
Le Serveur d’horodatage utilisé est « http://timestamp.sectigo.com ».
Vérification du hachage de l’installateur avec waptdeploy¶
L’utilitaire waptdeploy est responsable du lancement silencieux de l’installateur waptagent.exe avec des droits élevés.
Pour garantir l’authenticité de l’installateur, nous vérifions que l’empreinte sha1 du certificat de signature « Authenticode » de l’installateur est l’une de celles utilisées par Tranquil IT. Cette liste est intégrée dans le binaire waptdeploy.exe lors de la compilation de waptdeploy.exe. L’intégrité de cette liste est assurée par la signature du binaire waptdeploy.exe.
L’installateur waptagent.exe est l’agrégation d’un binaire standard waptsetup.exe (signé par Tranquil IT) et d’une partie variable json pour la configuration spécifique à l’organisation (en particulier les URL du Serveur WAPT et du référentiel, les certificats de paquets autorisés, les certificats https de confiance). Pour garantir l’intégrité de l’ensemble « Installer » + configuration spécifique, une empreinte sha256 est fournie comme argument à l’utilitaire waptdeploy. Après avoir téléchargé waptagent.exe et avant de l’exécuter en mode silencieux, waptdeploy vérifie que l’empreinte digitale de waptagent.exe correspond à celle fournie en argument. L’intégrité de l’argument –hash est assurée par la ACL du GPO dans lequel cette ligne de commande est spécifiée. Il est de la responsabilité de l’administrateur de l’organisation de s’assurer que l’empreinte digitale de l’installateur dans le GPO est correcte.
FS6. Journalisation¶
Demandes de signature envoyées aux Agents WAPT¶
Les commandes sont signées par la Console WAPT avant d’être envoyées individuellement à chaque Agent WAPT.
Tous les attributs des demandes d’action sont signés :
l’UUID de l’Agent concerné ;
l’action (par exemple, l’installation) ;
arguments (par exemple tis-firefox) ;
demande d’horodatage.
Le certificat associé à la signature est également transmis. Lorsque l’Agent WAPT reçoit une demande, il vérifie :
Que l’UUID mentionné dans l’action correspond à son UUID.
Que le certificat associé provient d’une autorité présente dans son répertoire <wapt>/ssl.
Que la demande est correctement signée par la clé du certificat.
La date de signature doit être comprise dans l’intervalle de temps défini dans la configuration de l’Agent WAPT.
Informations sur le traitement des données¶
Aucune