Gestionnaire de virtualisation d'entreprise

Rationale

Cette règle autorise les administrateurs (postes conformes, groupes d'annuaire restreints) et les outils d'automatisation à atteindre l'interface principale du gestionnaire en HTTPS. Le gestionnaire étant un serveur interne contrôlé, ssl_inbound_inspection déchiffre le trafic entrant pour détecter les exploits visant l'interface (T1190) et les fichiers malveillants déposés. L'identité est restreinte par groupe annuaire (moindre privilège). Le risque est critique (risk 5) car compromettre le gestionnaire permet de pivoter vers l'ensemble des hyperviseurs gérés (T1210). Cette règle couvre aussi la redirection depuis le port HTTP 80 (voir règle 3).

Profils de sécurité

Rationale

L'interface d'administration de l'appliance (port 5480) est le seul moyen de gérer les paramètres système de l'appliance : sauvegarde, configuration réseau, NTP, certificats, mises à jour OS et activation/désactivation du SSH. Elle est structurellement obligatoire (sans elle, l'appliance ne peut pas être administrée hors de l'interface principale) et distincte de l'interface de gestion 443. L'accès est restreint aux administrateurs système uniquement (group d'annuaire plus étroit que la règle 1). ssl_inbound_inspection couvre les exploits (T1190, T1078). Risque critique (risk 5) : accès à cette interface permet la reconfiguration totale de l'appliance, y compris l'activation du SSH.

Profils de sécurité

Rationale

Le port 80 est accepté uniquement pour permettre la redirection automatique vers HTTPS 443 (comportement stable et documenté). Aucune donnée applicative ne transite en clair : la session est immédiatement redirigée. L'IPS en mode block (high) détecte les tentatives d'exploitation visant la couche HTTP de redirection. Le déchiffrement est non applicable : le flux HTTP n'est pas chiffré et la redirection intervient avant tout échange de données.

Profils de sécurité

Rationale

Le gestionnaire pilote les hyperviseurs gérés via un canal bidirectionnel. Le port de gestion dédié (TCP) véhicule le transfert de données, la configuration et la console de machine virtuelle. Le port HTTPS (TCP 443) est utilisé pour le canal de configuration et la gestion des agents côté hyperviseur. Le heartbeat de disponibilité (UDP) passe également par le port de gestion dédié. Le déchiffrement est désactivé (exclusion cert_pinned_app) : les hyperviseurs gérés présentent des certificats d'équipement et une inspection MITM briserait le canal de gestion authentifié. L'IPS détecte les exploits visant les services de gestion embarqués (T1210). Risque critique (risk 5) : ce canal est le vecteur principal de pivot vers les hyperviseurs. Note : le heartbeat UDP sur le même port est couvert par une règle de service séparée si le pare-feu distingue TCP et UDP.

Profils de sécurité

Rationale

Le heartbeat de disponibilité UDP entre le gestionnaire et les hyperviseurs gérés permet la détection rapide des hôtes indisponibles. Ce flux est fondamental pour la gestion de la haute disponibilité et la surveillance de l'état des hyperviseurs. L'IPS en mode default détecte les anomalies de protocole sur ce flux UDP sans bloquer les sondes légitimes.

Profils de sécurité

Rationale

La résolution DNS est structurellement obligatoire : l'installation de l'appliance échoue si les enregistrements A/PTR de son FQDN ne sont pas résolus. En exploitation, DNS est requis pour joindre les hyperviseurs gérés, les contrôleurs d'annuaire et le service de mise à jour. Le flux est restreint vers un résolveur interne contrôlé (pas de résolution directe vers Internet). Le profil dns_security avec sinkhole atténue le tunneling DNS depuis l'appliance si elle était compromise. TCP/53 (réponses DNSSEC ou >512 octets) est traité avec la même règle si le pare-feu supporte multi-protocole ; sinon, dupliquer pour tcp/53.

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si la synchronisation NTP directe est configurée sur l'appliance (via son interface d'administration). NTP est techniquement désactivable au profit de la synchronisation via l'hyperviseur hôte, mais fortement recommandé en production car il est critique pour la validité des certificats TLS, l'authentification SSO/Kerberos et la cohérence des journaux d'événements et des mécanismes de haute disponibilité. L'IPS en mode default détecte les anomalies de protocole NTP (amplification, mode hors norme).

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si le service SSH de l'appliance a été explicitement activé via l'interface d'administration pour une opération de maintenance. Le SSH est désactivé par défaut sur l'appliance (bonne pratique de sécurité) et doit être re-désactivé après intervention. Cette règle doit être activée avec une politique de durée limitée (fenêtre de maintenance). Le déchiffrement ssh_proxy permet d'inspecter les commandes exécutées via le tunnel SSH (détection d'exfiltration ou de commandes suspectes). L'accès est restreint aux hôtes de gestion conformes et au groupe d'administration le plus étroit (T1133). Le log_start est activé pour tracer toute ouverture de session SSH.

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si le service de provisioning réseau des hyperviseurs est en place. Ce service permet le déploiement automatisé des hyperviseurs sans état : les hôtes en cours de provisioning se connectent au gestionnaire pour recevoir leur image système, leur profil de configuration et leurs règles d'assignation. L'antivirus et l'IPS inspectent les flux entrants. Le déchiffrement est désactivé (cert_pinned_app) car les hyperviseurs en boot réseau utilisent des certificats d'équipement que le proxy ne peut pas impersonner. Si le provisioning utilise UEFI HTTPS Boot (boot moderne), il passe par TCP 443 (règle 1) et cette règle peut rester désactivée.

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si le service de provisioning réseau utilise le boot PXE legacy (BIOS ou iPXE classique). Le TFTP permet le téléchargement du fichier de boot iPXE lors du démarrage PXE de l'hyperviseur. Cette règle est inutile si le boot réseau moderne (UEFI HTTPS Boot) est configuré, ce dernier passant entièrement par HTTPS 443 (règle 1 ou règle 8). TFTP est un protocole non chiffré : limiter son usage au réseau de gestion segmenté et envisager la migration vers le boot UEFI HTTPS pour éliminer ce flux.

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si le service de gestion du cycle de vie des hôtes est activé pour piloter les mises à jour et vérifier la conformité des hyperviseurs gérés. Ce service expose un dépôt HTTPS de patches et d'images depuis le gestionnaire vers les hyperviseurs. Si ce flux est bloqué, les vérifications de conformité et les remédiations échouent silencieusement. Port HTTPS (9087) : flux principal depuis la version courante du service (remplace le port HTTP hérité 9084). ssl_inbound_inspection permet l'inspection antivirus et sandboxing du contenu distribué.

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si le service de cycle de vie des hôtes utilise encore le port HTTP hérité (9084) pour des hyperviseurs en mode de compatibilité, ou le port d'accès au magasin de configuration des hôtes (8083). En version courante du service, le flux principal passe par HTTPS 9087 (règle 10) ; ces ports sont des résidus d'héritage. Note : 9084 étant HTTP non chiffré, envisager la migration vers 9087/HTTPS pour éliminer ce flux non chiffré et fermer cette règle.

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si le service de réplication de machines virtuelles est déployé. Ce flux SOAP permet au gestionnaire de piloter l'appliance de réplication (configuration des politiques de réplication, monitoring). Il est distinct du trafic de réplication de données inter-hyperviseurs, qui relève d'une fiche dédiée aux hyperviseurs. ssl_inbound_inspection inspecte les flux HTTPS SOAP entrants vers le gestionnaire.

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si l'agent SNMP du gestionnaire est activé et qu'un système de supervision réseau (NMS) effectue du polling. SNMP v3 avec authentification et chiffrement est fortement recommandé. L'accès doit être restreint à l'adresse IP du NMS. L'IPS en mode default surveille les anomalies de protocole SNMP (tentatives de walk non autorisées).

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si l'envoi de traps SNMP est configuré sur le gestionnaire vers un récepteur de traps (NMS). Le gestionnaire émet des traps SNMP UDP vers le NMS pour signaler des événements d'infrastructure. Préférer SNMP v3 avec authentification. L'IPS en mode default surveille les anomalies.

Profils de sécurité

Rationale

CONDITIONNEL — À n'activer QUE si la collecte syslog non chiffrée est configurée ET que la version courante du gestionnaire la supporte. AVERTISSEMENT DE VERSION : le syslog non chiffré sur UDP/TCP 514 est supporté en version 9.x mais est bloqué et non supporté à partir de la version 9.1 du gestionnaire. Si une montée de version vers 9.1+ est prévue, migrer vers syslog TLS (règle 16, port 1514) AVANT la mise à niveau. Syslog non chiffré expose les journaux d'événements à l'interception et à la falsification sur le réseau de gestion — préférer la règle 16 en toutes circonstances. L'IPS surveille les anomalies sur le flux.

Profils de sécurité

Rationale

CONDITIONNEL — À activer si la collecte de logs syslog chiffrée TLS est configurée sur le gestionnaire. Recommandé en version 9.x, et obligatoire à partir de la version 9.1 du gestionnaire (le syslog non chiffré sur 514 étant bloqué dès cette version). Voie de migration recommandée depuis la règle 15. Le déchiffrement est désactivé (cert_pinned_app) car le collecteur syslog TLS utilise un certificat d'équipement pour l'authentification mutuelle.

Profils de sécurité

Rationale

Le gestionnaire télécharge ses mises à jour et les patches/images des hyperviseurs depuis un service éditeur sur Internet. C'est le seul flux sortant vers Internet et un vecteur critique de chaîne d'approvisionnement (T1195.002) : ssl_forward_proxy est obligatoire pour permettre à l'antivirus et au sandboxing d'inspecter les paquets téléchargés. url_filtering bloque les catégories à risque et les sites non catégorisés. La liste blanche des domaines autorisés (service éditeur de mise à jour) est spécifique au déploiement : les domaines documentés par la source figurent en provenance (references[].endpoints), à reporter en url_filtering.allow_list au déploiement — sans encoder de marque dans la règle. Note de déploiement : le service éditeur de mise à jour utilise un token d'authentification par compte ; consulter la documentation de provenance (references[]) pour l'exclusion d'inspection SSL recommandée sur ce flux spécifique (KB 431697). Risque élevé (risk 4) : vecteur supply chain à large rayon d'impact.

Profils de sécurité

Rationale

Durcissement : les tentatives de communication en clair (HTTP) vers les interfaces de gestion des hyperviseurs sont bloquées silencieusement. Les hyperviseurs modernes n'exposent leurs interfaces de gestion qu'en HTTPS (port 443, règle 4) ; un flux HTTP entrant vers un hyperviseur est soit un résidu de configuration hérité, soit une tentative de contournement du chiffrement (T1557 — interception en vol, vol d'identifiants). Le log en haute priorité signale toute tentative pour investigation. Note : cette règle cible les flux internes gestionnaire <-> hyperviseurs ; la redirection HTTP 80 vers HTTPS pour les clients administrateurs est couverte par la règle 3 (sens entrant).