¶ Dans le cadre des politiques de sécurité des différents CHU, certains outils de sécurité externes peuvent être déployés au niveau des Noeuds hébergeant la plateforme Arkhn (ex. internalisation des dépôts de paquets, orchestration des mises à jour système/paquets, déploiement d'un EDR).
Cette section vise à expliciter les conditions de compatibilité avec les exigences de Maintien en Conditions Opérationnelles de la plateforme Arkhn, ainsi que les points d'attention à prendre en compte.
- La plupart des nœuds du cluster Arkhn sont sur la version 12 de Debian.
- Aucune mise à jour système (packages critiques, kernel, redémarrage, modifications de configuration système) ne doit être effectuée sans coordination préalable avec l'équipe Arkhn**.**
- L'enjeu principal est de garantir la stabilité de la plateforme et d'éviter toute interférence avec les outils d'automatisation, de déploiement et d'exploitation Arkhn.
- L'utilisation de ces outils (exemple : **SUSE Manager) **pour la gestion des dépôts et l'orchestration des mises à jour système n'est pas bloquante en soi.
- Elle nécessite toutefois :
- une visibilité complète sur les actions réalisées au niveau système (installation de paquets, mises à jour, modifications dans
/etc) ;
- une coordination formelle avec l'équipe Arkhn avant toute action susceptible d'avoir un impact sur les nœuds.
- La modification/internalisation des repository de packages publics n'est pas bloquante, tant que le flux vers le Nexus Arkhn est ouvert (nexus.arkhn.io).
Exemples :
- Microsoft Defender
- Palo Alto Cortex XDR
Le déploiement d'une solution EDR sur les nœuds hébergeant la plateforme Arkhn n'est pas bloquant en soi. Il doit toutefois respecter un cadre strict afin de garantir le maintien de la plateforme**.**
De manière générale, tout EDR pour Linux :
- s'exécute via un agent installé au niveau du système hôte ;
- peut observer ou analyser les processus Linux, y compris ceux liés aux conteneurs ;
- peut intervenir lors de modifications système (configuration, paquets, services).
À ce titre, les principes suivants s'appliquent quel que soit l'éditeur :
- toute installation, mise à jour ou modification de configuration de l'EDR doit être planifiée et coordonnée avec Arkhn:
- Communiquer les règles et configurations qui seront appliquées par l'EDR
- les répertoires critiques Kubernetes (notamment
/var/lib/rancher/k3s) doivent être explicitement exclus des mécanismes d'analyse afin d'éviter tout impact sur le cluster K3S Arkhn ;
- les règles iptables ou nftables doivent être gérées par la plateforme Arkhn à l'exclusion de tout autre outil (firewall, EDR, MDM, etc.) ;
- Un point de synthèse devra être organisé entre les deux parties, 1 mois après l'installation de l'outil, afin de revoir ensemble les impacts, et possiblement reconfigurer certains aspects ;
- Arkhn recommande d'être positionné a minima en Approbateur pour toute action susceptible d'impacter la plateforme ;
- Les composants liés à la virtualisation et aux DCR (kernel, modules de virtualisation, services associés, redémarrages système) ne doivent pas être modifiés ou interceptés par l'EDR sans validation préalable conjointe.
- La plupart des noeuds Debian du cluster utilisent un kernel 6.1.0-39-amd64, compatible avec Cortex XDR en mode User Space.
- La documentation Cortex XDR indique les pré-requis suivants :
- 4 Go de RAM minimum par nœud ;
- 8 Go recommandés.
Ces éléments doivent être évalués au regard du dimensionnement réel des nœuds Arkhn et des charges existantes.
- Cortex XDR peut activer une protection des processus conteneurisés, indépendamment de la solution de conteneurisation utilisée ;
- Lorsque cette protection est active, un impact non négligeable sur les performances ou le comportement de la plateforme ne peut être exclu ;
- Cortex XDR peut également intervenir lors de :
- modifications de configuration système (
/etc),
- installation ou mise à jour de paquets,
- opérations système sensibles.
Une mise en œuvre coordonnée avec Arkhn est donc indispensable afin d'éviter toute interférence avec les outils d'automatisation et d'exploitation de la plateforme.
- Coordination obligatoire pour toute mise à jour système ou modification bas niveau ;
- Compatibilité conditionnelle des outils de gestion de configuration et de mises à jour système (eg. Suse Manager), sous réserve de visibilité et de gouvernance partagée ;
- Impacts potentiels des EDR sur les nœuds et les conteneurs ;
- Exclusion de
/var/lib/rancher/k3s ;
- Mise en place d'une "période d'essai" de 1 mois avec une réunion à terme, pour vérification et possible reconfiguration/réparation ;
- Validation conjointe requise pour toute modification kernel / virtualisation impactant les DCR.
Ces conditions sont nécessaires pour garantir le maintien de la plateforme Arkhn.