Surveiller les opérations d’un cluster de ligne de base AKS pour un PCI DSS 3.2.1 (partie 7 sur 9)

Cet article décrit les considérations relatives à un cluster Azure Kubernetes Service (AKS) qui exécute une charge de travail en conformité avec la norme de sécurité des données de l’industrie des cartes de paiement (PCI-DSS 3.2.1).

Cet article fait partie d’une série. Lisez l’introduction.

Surveiller et tester régulièrement les réseaux

Condition requise 10—Suivre et superviser tous les accès aux ressources réseau et aux données de titulaire de carte

Prise en charge des fonctionnalités AKS

Azure offre la fonctionnalité Container Insights qui supervise les conteneurs, y compris les clusters AKS. Pour plus d’informations, consultez Vue d’ensemble de Container Insights.

AKS fournit des journaux d’audit à plusieurs niveaux, qui peuvent être utiles pour protéger le système et les données de manière proactive. Les journaux d’activité fournissent des informations sur les opérations liées à la gestion des comptes et des secrets, la gestion des paramètres de diagnostic, la gestion des serveurs, ainsi que sur d’autres opérations d’accès aux ressources. Tous les journaux sont enregistrés avec la date, l’heure, l’identité et d’autres informations détaillées. Vous pouvez également accéder à tous les enregistrements chronologiques de tous les appels d’API effectués dans le cluster AKS. Les journaux incluent des informations sur l’appelant, l’heure à laquelle l’appel a été effectué, la source de l’appel, etc. Pour plus d’informations, consultez Activer et consulter les journaux de plan de contrôle dans Azure Kubernetes Service (AKS).

Le contrôle d’accès en fonction du rôle (RBAC) peut être utilisé pour gérer la stratégie d’accès aux ressources comme pratique standard sur Azure.

Tous les journaux doivent être stockés dans un compte de stockage appartenant au client ou dans Azure Monitor. De cette façon, vous pouvez rapidement générer des insights à partir d’un grand volume de données. Tous les journaux sont conservés avec au moins trois copies dans une région. Vous pouvez avoir plus de copies en activant la réplication ou la sauvegarde interrégionales. Toutes les entrées de journal sont disponibles uniquement par le biais de canaux HTTP(s) sécurisés.

L’infrastructure d’alertes d’Azure vous permet de configurer des alertes pour détecter les accès suspects. Vous pouvez définir les alertes qui doivent être déclenchées et les événements. Les utilisateurs peuvent également vérifier manuellement le journal complet à l’aide de Log Analytics avec la fonction de filtrage basée sur le type de l’activité, le contenu de l’activité ou l’appelant de l’activité.

Vos responsabilités

Condition requise	Responsabilité
Condition requise 10.1	Implémenter des pistes d’audit pour associer tous les accès aux composants système à chaque utilisateur.
Condition requise 10.2	Implémenter des pistes d’audit automatisées pour tous les composants système afin de reconstituer les événements suivants :
Condition requise 10.3	Enregistrer au moins les entrées de piste d’audit suivantes de tous les composants système pour chaque événement :
Condition requise 10.4	À l’aide d’une technologie de synchronisation temporelle, synchronisez toutes les horloges et heures système critiques et vérifiez que les éléments suivants sont implémentés pour l’acquisition, la distribution et le stockage du temps.
Condition requise 10.5	Sécuriser les pistes d’audit de sorte qu’elles ne puissent pas être altérées.
Condition requise 10.6	Examiner les journaux et les évènements de sécurité de tous les composants système pour identifier les anomalies ou les activités suspectes.
Condition requise 10.7	Conserver l’historique des pistes d’audit pendant au moins un an, avec un minimum de trois mois disponibles tout de suite pour analyse (par exemple, en ligne, archivées ou restaurées à partir d’une sauvegarde).
Condition requise 10.8	Condition supplémentaire pour les prestataires de services uniquement : répondre aux échecs de contrôles de sécurité critiques quand il le faut. Les procédures pour répondre aux échecs de contrôles de sécurité doivent comprendre
Condition requise 10.9	S’assurer que les stratégies de sécurité et les procédures opérationnelles pour le contrôle de tous les accès aux ressources du réseau et aux données de titulaires de carte sont documentées, utilisées et connues de toutes les parties concernées.

Condition requise 11—Tester régulièrement les processus et systèmes de sécurité

Prise en charge des fonctionnalités AKS

AKS est intégré aux services de supervision Azure :

• Microsoft Defender pour les conteneurs offre de nombreuses fonctionnalités d’analyse de la sécurité. Par exemple, Defender pour les conteneurs analyse les images extraites, envoyées et importées dans des registres de conteneurs et fournit des recommandations. Pour plus d’informations, consultez Évaluation des vulnérabilités.

• Azure Monitor peut être utilisé pour définir des alertes basées sur le type d’événement pour protéger l’intégrité et la sécurité du système. En cas de défaillance du système attendu sur les nœuds AKS, AKS auto-répare la ressource en temps voulu, sans interruption du traitement du système.

Les clusters AKS sont protégés par Azure Application Gateway avec Web Application Firewall (WAF) et peuvent être configurés en mode de détection pour journaliser les alertes et les menaces. Un mode plus fort est le mode préventif, qui bloque activement les intrusions et attaques détectées. Pour obtenir des détails, consultez Bonnes pratiques pour la connectivité réseau et la sécurité dans Azure Kubernetes Service (AKS).

Vos responsabilités

Condition requise	Responsabilité
Condition requise 11.1	Implémenter des processus pour tester la présence de points d’accès sans fil (802.11), et détecter et identifier tous les points d’accès sans fil autorisés et non autorisés sur une base trimestrielle.
Condition requise 11.2	Analyser les vulnérabilités potentielles des réseaux internes et externes au moins une fois par trimestre et après tout changement significatif des réseaux (par exemple, installation de nouveaux composants du système, changement de la topologie réseau ou des règles de pare-feu, mises à niveau de produits).
Condition requise 11.3	Implémenter une méthodologie pour les tests de pénétration qui inclut :
Condition requise 11.4	Utiliser les techniques d’intrusion-détection et/ou d’intrusion-prévention pour détecter et/ou empêcher les intrusions dans le réseau.
Condition requise 11.5	Déployer des mécanismes de détection de changement (par exemple, des outils de contrôle d’intégrité de fichier) pour alerter le personnel de toute modification non autorisée (changements, ajouts, suppressions) des fichiers système critiques, fichiers de configuration ou fichiers de contenu, et configurer le logiciel pour qu’il fasse des comparaisons de fichiers critiques au moins une fois par semaine.
Condition requise 11.6	S’assurer que les stratégies de sécurité et les procédures opérationnelles pour la surveillance et les tests de sécurité sont documentées, utilisées et connues de toutes les parties concernées.

Condition requise 10.1

Implémenter des pistes d’audit pour associer tous les accès aux composants système à chaque utilisateur.

Vos responsabilités

Nous vous recommandons d’utiliser des opérations d’audit effectuées sur chaque composant en utilisant les méthodes suivantes :

• Journal d’activité Azure Monitor. Le journal d’activité fournit des informations sur le type et l’heure des opérations des ressources Azure. Il consigne également l’identité qui a démarré l’opération. Il est activé par défaut, et les informations sont collectées dès que l’opération de ressource est terminée. Cette piste d’audit est en écriture seule et ne peut pas être supprimée.

  Les données sont conservées pendant 90 jours. Pour des options de conservation plus longues, envisagez d’envoyer des entrées de journal d’activité aux journaux Azure Monitor et de configurer une stratégie de conservation et d’archivage.

  

• Paramètres des diagnostics Azure Fournit des informations de diagnostic et d’audit des ressources Azure et la plateforme à laquelle le paramètre s’applique. Nous vous recommandons d’activer des paramètres de diagnostic pour AKS et d’autres composants du système, comme Stockage Blob Azure et Key Vault. En fonction du type de ressource, vous pouvez choisir des catégories de journaux et de données de métriques, et les envoyer à une destination. Votre destination des diagnostics doit correspondre aux périodes de conservation demandées.

  • Paramètre de diagnostic pour AKS. Dans les catégories AKS fournies, activez les journaux d’audit Kubernetes. Les paramètres de diagnostic incluent kube-audit ou kube-audit-admin, et guard.

    Activez kube-audit-admin pour voir les appels du serveur d’API basés sur les journaux qui pourraient modifier l’état de votre cluster. Si vous avez besoin d’une piste d’audit de toutes les interactions serveur de l’API (y compris les événements de non-modification comme les demandes de lecture), activez plutôt kube-audit. Ces événements peuvent être prolifiques, créer du bruit et augmenter le coût de votre consommation. Ces journaux contiennent des informations sur l’accès et le nom de l’identité utilisés pour la demande.

    Activez les journaux guard pour suivre les audits managés de Microsoft Entra ID et du contrôle d’accès en fonction du rôle (RBAC) Azure.

  En plus des journaux basés sur l’utilisateur, pensez aux journaux du plan de contrôle Kubernetes, notamment kube-apiserver et kube-controller-manager. Ces journaux ne sont généralement pas associés à un utilisateur, mais ils peuvent aider à corréler les changements système apportés par les utilisateurs.

  Pour plus d’informations, consultez Afficher les journaux du composant de plan de contrôle.

  Cette implémentation de référence active les journaux cluster-autoscaler, kube-controller-manager, kube-audit-admin et guard, et les transfère à un espace de travail Log Analytics. La période de conservation de l’espace de travail est définie sur 90 jours.

  

• Les diagnostics Azure Kubernetes Service (AKS) permettent de détecter et de résoudre les problèmes liés au cluster, comme des défaillances des nœuds. Ils incluent également des données de diagnostic spécifiques au réseau, qui n’induisent pas de frais supplémentaires. Ces données ne sont généralement pas associées à un utilisateur, mais peuvent aider à corréler les changements système apportés par les utilisateurs. Pour plus d’informations, consultez Diagnostics Azure Kubernetes Service.

Les mécanismes de piste d’audit précédents doivent être implémentés au moment du déploiement des ressources. Azure Policy doit également être actif pour s’assurer que ces configurations ne sont pas désactivées par inadvertance ou intentionnellement dans votre environnement CDE.

Condition requise 10.2

Implémenter des pistes d’audit automatisées pour tous les composants système afin de reconstituer les événements suivants :

• 10.2.1 Tous les accès des utilisateurs individuels aux données de titulaires de carte
• 10.2.2 Toutes les actions exécutées par un utilisateur disposant de privilèges racines ou administratifs
• 10.2.3 Accès à toutes les pistes d’audit
• 10.2.4 Tentatives d’accès logique non valides
• 10.2.5 Utilisation et changements des mécanismes d’identification et d’authentification, y compris, mais non limitativement, la création de nouveaux comptes et l’élévation de privilèges, et tous les changements, ajouts ou suppressions aux comptes avec des privilèges racines ou d’administration
• 10.2.6 Initialisation, arrêt ou interruption des journaux d’audit
• 10.2.7 Création et suppression d’objets au niveau système

Vos responsabilités

AKS fournit des journaux d’audit à plusieurs niveaux, comme décrit dans la condition requise 10.1. Voici quelques points clés :

• Par défaut, les journaux d’activité fournissent des informations sur les opérations critiques des ressources Azure. Tous les journaux incluent l’état, l’heure et l’identité qui a démarré l’opération.
• Activez les paramètres de diagnostic pour accéder à tous les enregistrements de tous les appels d’API effectués dans le cluster AKS. Les journaux fournissent des détails sur le demandeur, l’horodatage, la source de la demande et le contenu de la demande. Stockez les journaux dans un espace de travail Log Analytics avec une période de conservation appropriée. Activez la journalisation de l’espace de travail Log Analytics pour vérifier que même l’accès à la piste d’audit est bien consigné.
• Activez la collecte syslog avec Container Insights pour capturer les journaux d’événements de sécurité et d’intégrité d’un système d’exploitation AKS au niveau du nœud dans votre espace de travail Log Analytics. Ces journaux doivent aussi être ingérés dans votre SIEM.
• Incluez la journalisation d’audit du système d’exploitation et de l’utilisation pour d’autres calculs tels que les agents de build et les serveurs de rebond. Désactivez l’accès aux systèmes directement en tant qu’utilisateur racine. Vérifiez que toutes les actions sont effectuées sous une identité spécifique.
• Journalisez les tentatives d’accès infructueuses. Ceci inclut les demandes d’accès à des composants comme Stockage Azure, Azure Key Vault, le serveur d’API AKS et tout accès RDP/SSH sur d’autres systèmes.
• Tirez parti des fonctionnalités offertes par les agents de sécurité de tiers, qui peuvent aider à analyser les modèles utilisateur dans votre cluster AKS. Ces fonctionnalités peuvent être utiles pour les données d’audit des accès utilisateur.

Condition requise 10.3

Enregistrer au moins les entrées de piste d’audit suivantes de tous les composants système pour chaque événement :

• 10.3.1 Identification de l’utilisateur
• 10.3.2 Type d’événement
• 10.3.3 Date et heure
• 10.3.4 Indication de succès ou d’échec
• 10.3.5 Origine de l’événement
• 10.3.6 Identité ou nom des données, du composant système ou de la ressource affectés

Vos responsabilités

Comme décrit dans la condition requise 10.2, vous pouvez obtenir des journaux d’audit du cluster en activant le paramètre de diagnostic pour AKS. Les journaux contiennent des informations détaillées sur les événements d’obtention, de liste, de création, de mise à jour, de suppression, de correction et de publication. Les journaux contiennent des informations dans la liste sous Conditions requises. Stockez les journaux dans un compte de stockage afin de pouvoir interroger les informations.

Par exemple, vous souhaitez afficher l’ensemble d’informations précédent pour les événements kube-audit-admin en exécutant cette requête :

AzureDiagnostics
| where Category == 'kube-audit-admin'
| project TimeGenerated, ResourceId, log_s,  pod_s
| top 200 by TimeGenerated desc

Le jeu de résultats affiche les informations dans le champ log_s.

Informations requises	schéma
Identification de l’utilisateur	SourceIPs
Type d’événement	verbe
Date et heure	requestReceivedTimestamp
Indication de succès ou d’échec	responseStatus
Origine de l’événement	utilisateur
Identité ou nom des données, du composant système ou de la ressource affectés	objectRef

Pour plus d’informations sur le journal principal, consultez Afficher les journaux des composants du plan de contrôle.

Condition requise 10.4

Utiliser une technologie de synchronisation temporelle pour synchroniser toutes les horloges et heures système critiques, et vérifiez que les éléments suivants sont implémentés pour l’acquisition, la distribution et le stockage de l’heure.

• 10.4.1 L’heure des systèmes critiques est correcte et la même pour tous.
• 10.4.2 Les données temporelles sont protégées.
• 10.4.3 Les paramètres temporels sont reçus de sources temporelles reconnues par le secteur.

Note : Le protocole NTP (Network Time Protocol) est un exemple de technologie de synchronisation temporelle.

Vos responsabilités

AKS utilise NTP à partir des hôtes Azure sous-jacents et ne nécessite aucune autorisation de trafic réseau sortant pour prendre en charge NTP. Les autres machines virtuelles que vous ajoutez à votre CDE peuvent utiliser des serveurs NTP externes, tels que ntp.ubuntu.org (et son pool) comme source de synchronisation de l’heure. Tout calcul supplémentaire que vous apportez à votre CDE doit utiliser explicitement la source NTP de votre choix et doit être documenté.

Condition requise 10.5

Limiter la visualisation des pistes d’audit aux seules personnes qui en ont besoin pour leur travail.

• 10.5.1 Limiter la visualisation des pistes d’audit aux personnes qui en ont besoin pour leur travail.
• 10.5.2 Protéger les fichiers de piste d’audit contre toute modification non autorisée.
• 10.5.3 Sauvegarder rapidement les fichiers de piste d’audit sur un serveur centralisé réservé à la journalisation ou sur des supports difficiles à altérer.
• 10.5.4 Écrire les journaux d’activité pour les technologies orientées vers l’extérieur sur un serveur de journal interne, centralisé et sécurisé, ou sur un périphérique de support.
• 10.5.5 Analyser les journaux d’activité à l’aide d’un logiciel de supervision de l’intégrité des fichiers ou de détection des modifications pour vérifier que les données contenues dans les journaux d’activité ne peuvent pas être modifiées sans entraîner le déclenchement d’une alerte (l’ajout de nouvelles données ne doit pas engendrer d’alerte).

Vos responsabilités

Le fait de disposer de plusieurs synchronisations de journalisation ajoute une surcharge à la sécurisation, l’examen, l’analyse et l’interrogation des données de piste d’audit. Planifiez vos topologies de piste d’audit pour équilibrer les compromis entre les problèmes de gestion et d’isolation des pistes d’audit.

Si possible, intégrez les journaux. L’avantage est la capacité à examiner, analyser et interroger efficacement les données. Azure fournit plusieurs options de supervision. Vous pouvez utiliser Azure Monitor Container Insights pour écrire des journaux dans un espace de travail Log Analytics. Une autre option consiste à intégrer des données dans des solutions SIEM (Security Information and Event Management), telles que Microsoft Sentinel. Splunk, QRadar et ArcSight constituent d’autres choix de tiers connus. Microsoft Defender pour le cloud et Azure Monitor prennent en charge toutes ces solutions. Ces solutions sont des récepteurs de données en ajout seul pour s’assurer que la piste ne peut pas être modifiée.

Defender pour le cloud peut exporter les résultats à intervalles configurés. Pour plus d’informations, consultez Exportation continue.

Tous les journaux sont conservés avec au moins trois copies dans une région. Comme stratégie de sauvegarde, vous pouvez avoir plus de copies en activant la réplication ou la sauvegarde interrégionales. Toutes les entrées de journal sont disponibles uniquement par le biais de canaux HTTP/S sécurisés.

Log Analytics et Microsoft Sentinel prennent en charge différents contrôles d’accès basés sur les rôles pour gérer l’accès des pistes d’audit. Assurez-vous que les rôles correspondent aux rôles et aux responsabilités de l’organisation.

Assurez-vous que votre espace de travail Log Analytics prend en charge à la fois les opérations et les besoins de conformité. Imaginez un espace de travail dédié pour vos clusters dans l’étendue, qui est transféré à votre solution SIEM.

La plupart de la journalisation dans AKS provient de stdout/stderr et sera collectée par Azure Monitor Container Insights. Si vous avez d’autres journaux créés manuellement, envisagez d’émettre des données de manière à ce qu’elles soient envoyées à un flux de transfert approuvé et qu’elles ne soient pas sujettes à des falsifications.

Condition requise 10.6

Examiner les journaux et les évènements de sécurité de tous les composants système pour identifier les anomalies ou les activités suspectes.

• 10.6.1 Examiner les points suivants au moins une fois par jour :
  • Tous les événements de sécurité
  • Les journaux d’activité de tous les composants de système qui stockent, traitent ou transmettent des CHD et/ou SAD
  • Les journaux d’activité de tous les composants système critiques
  • Les journaux de tous les serveurs et composants système qui remplissent des fonctions de sécurité (par exemple, les pare-feu, les systèmes de détection d’intrusion/systèmes de prévention d’intrusion [IDS/IPS], les serveurs d’authentification, les serveurs de redirection de l’e-commerce, etc.).
• 10.6.2 Examinez régulièrement les journaux d’activité de tous les autres composants système en fonction des politiques et de la stratégie de gestion des risques de l’organisation, comme déterminé par l’évaluation annuelle des risques de l’organisation.
• 10.6.3 Suivi des exceptions et des anomalies identifiées pendant le processus d’examen.

Vos responsabilités

Les services de monitoring Azure, Azure Monitor et Microsoft Defender pour le cloud peuvent générer des notifications ou des alertes lorsqu’ils détectent une activité anormale. Ces alertes comprennent des informations contextuelles telles que la gravité, l’état et la durée d’activité.

À mesure que des alertes sont générées, vous devez disposer d’une stratégie de correction et passer en revue la progression. Vous pouvez par exemple suivre le score de sécurité dans Microsoft Defender pour le cloud et le comparer à des résultats historiques.

Centralisez les données dans une seule vue en utilisant des solutions SIEM comme Microsoft Sentinel. L’intégration de données peut fournir un contexte d’alerte riche.

Vous pouvez aussi vérifier manuellement la totalité du journal dans votre stockage. Par exemple, dans les journaux Azure Monitor, vous pouvez utiliser une fonction de filtrage basée sur le type de l’activité, le contenu de l’activité ou l’appelant de l’activité.

Disposez de stratégies organisationnelles pour examiner les alertes et les événements à intervalles réguliers, et planifiez des initiatives avec des objectifs d’amélioration spécifiques. Utilisez des requêtes enregistrées personnalisées dans Log Analytics pour documenter les requêtes de journal prévues et interroger plus facilement. Ceci permet de garantir que l’équipe sait ce qu’il est important de vérifier concernant la condition requise 10.6, et que tous les efforts manuels impliqués dans ce processus suivent un workflow cohérent.

Condition requise 10.7

Conserver l’historique des pistes d’audit pendant au moins un an, avec un minimum de trois mois disponibles tout de suite pour analyse (par exemple, en ligne, archivées ou restaurées à partir d’une sauvegarde).

Vos responsabilités

Les journaux ne sont pas disponibles indéfiniment. Vérifiez que les journaux d’activité Azure et les paramètres de diagnostic sont conservés et peuvent être interrogés. Spécifiez une période de conservation de trois mois lorsque vous activez les paramètres de diagnostic pour vos ressources. Les journaux Azure Monitor prennent en charge l’archivage à long terme : ils peuvent donc être utilisés pour des audits ou une analyse hors connexion. Implémentez votre solution d’archivage à long terme pour l’adapter au principe « écrire une fois, lire plusieurs fois ».

Condition requise 10.8

• 10.8.1 Condition supplémentaire pour les prestataires de services uniquement : répondre aux échecs de contrôles de sécurité critiques quand il le faut. Les processus de résolution des pannes de contrôles de sécurité doivent comprendre les opérations suivantes :

• Restauration des fonctions de sécurité

• Identification et documentation de la durée (date et heure de début et de fin) de la panne de sécurité

• Identification et documentation des causes de la panne, notamment la cause racine, et documentation des corrections nécessaires pour résoudre la cause racine

• Identification et résolution des problèmes de sécurité survenus pendant la panne

• Évaluation des risques pour déterminer si d’autres actions sont indispensables à la suite d’une panne de sécurité

• Implémentation de contrôles pour éviter la répétition d’une telle panne - Reprise de la surveillance des contrôles de sécurité

Vos responsabilités

Si c’est pratique, utilisez des alertes qui indiquent l’existence de contrôles de sécurité critiques. Sinon, assurez-vous que votre processus d’audit peut détecter l’absence d’un contrôle de sécurité prévu en temps voulu. Pensez à des contrôles tels que les agents de sécurité exécutés dans le cluster AKS et les contrôles d’accès (IAM et réseau) sur les ressources Azure. Incluez des paramètres à vérifier si le cluster AKS est un cluster privé, pour les points d’exposition du réseau via des règles de groupe de sécurité réseau, ou pour rechercher des adresses IP publiques inattendues. Incluez également les modifications inattendues dans le DNS, le routage réseau, le pare-feu et Microsoft Entra ID.

Condition requise 10.9

S’assurer que les stratégies de sécurité et les procédures opérationnelles pour le contrôle de tous les accès aux ressources du réseau et aux données de titulaires de carte sont documentées, utilisées et connues de toutes les parties concernées.

Vos responsabilités

Il est essentiel de conserver une documentation complète sur les processus et les stratégies. Maintenez la documentation sur les stratégies appliquées. Dans le cadre de vos efforts de surveillance, les personnes doivent être formées à l’activation et à la consultation des journaux d’audit, ainsi qu’à l’identification et à la correction des risques courants. Ceci est important pour les personnes qui font partie du processus d’approbation du point de vue de la stratégie.

Condition requise 11.1

Implémenter des processus pour tester la présence de points d’accès sans fil (802.11), et détecter et identifier tous les points d’accès sans fil autorisés et non autorisés sur une base trimestrielle.

Les réseaux externes n’entrent pas dans le cadre de cette documentation et doivent être évalués séparément.

Vos responsabilités

Cette architecture et son implémentation ne sont pas conçues pour prendre en charge des transactions entre un réseau local ou d’entreprise et le cloud sur des connexions sans fil. Pour connaître les points à prendre en compte, reportez-vous aux recommandations fournies dans la norme officielle PCI DSS 3.2.1.

Condition requise 11.2

Exécutez des analyses de vulnérabilité réseau interne et externe au moins une fois par trimestre et après toute modification importante du réseau, par exemple :

• Des installations de nouveaux composants système
• Des modifications apportées à la topologie réseau
• Des modifications de règles de pare-feu
• Des mises à niveau de produits

Pour plus d’informations, consultez Payment Card Industry (PCI) Data Security Standard Approved Scanning Vendors.

Vos responsabilités

Disposez d’un processus qui recherche les changements dans le cluster AKS, la configuration réseau, les registres de conteneurs et autres composants de l’architecture.

En cas de changement dans le réseau, le processus doit évaluer si une analyse est nécessaire. Par exemple, le cluster est-il actuellement exposé à l’Internet public ? Les nouvelles règles de pare-feu sont-elles trop permissives ? Dans le cluster, existe-t-il des failles de sécurité dans le flux entre les pods ?

Ayez une définition claire et convenue des changements importants par rapport à votre infrastructure. Quelques exemples :

• Configuration des règles de groupe de sécurité réseau ou de Pare-feu Azure
• Peerings de réseaux virtuels
• Paramètres DNS
• Configurations Azure Private Link
• Autres composants réseau

S’APPLIQUE À 11.2.1

La recherche trimestrielle de vulnérabilités doit être exécutée par du personnel qualifié qui maîtrise parfaitement les concepts réseau Azure et Kubernetes. Associez les résultats à la condition requise 6.1 avec des niveaux de gravité et résolvez les éléments à priorité élevée. En cas de changements importants, exécutez les analyses avant l’analyse trimestrielle planifiée. Ceci vous aide à détecter de nouvelles vulnérabilités et de résoudre les problèmes de façon proactive.

Cette analyse doit également inclure les réseaux dans le cluster (pod-à-pod).

S’APPLIQUE À 11.2.2 Sélectionnez un fournisseur de services d’analyse agréé (ASV, Approved Scanning Vendor) qui a une expérience complète avec les réseaux Azure et Kubernetes. La suggestion de correction gagne en profondeur et en spécificité.

Condition requise 11.3

Implémenter une méthodologie pour les tests de pénétration qui inclut :

• Se base sur les approches de test de pénétration acceptées par l’industrie (par exemple NIST SP800-115)
• Recouvre la totalité du périmètre du CDE ainsi que les systèmes critiques
• Comprend un test depuis l’intérieur et l’extérieur du système
• Comprend un test pour valider tout contrôle de segmentation et de réduction de la portée
• Définit les tests de pénétration de couche d’application pour qu’ils comprennent, au minimum les vulnérabilités indiquées dans la Condition 6.5
• Définit les tests de pénétration de la couche d’application pour inclure des composants qui prennent en charge les fonctions réseau et les systèmes d’exploitation
• Comprend l’examen et la prise en compte des menaces et des vulnérabilités subies au cours des 12 derniers mois
• Spécifie la conservation des résultats de test de pénétration et les résultats des activités de correction.

Vos responsabilités

Procédez à des tests de pénétration pour trouver des failles de sécurité en recueillant des informations, en analysant les vulnérabilités et en générant des rapports. Nous vous recommandons de suivre les instructions du secteur que vous trouverez dans PTES (Penetration Testing Execution Standard) pour traiter les scénarios courants et les activités nécessaires à l’établissement d’une base de référence.

Le responsable des tests de pénétration doit avoir une compréhension approfondie des réseaux locaux et Azure pour s’assurer que les tests de segmentation annuels sont totalement couverts. Étendez la méthodologie de test aux réseaux dans le cluster. Cette personne doit avoir une expérience solide des concepts réseau de Kubernetes.

Les tests doivent couvrir les couches d’application et de données qui s’exécutent dans l’environnement CDE.

Dans un exercice de test de pénétration, les responsables risquent d’avoir besoin d’accéder aux données sensibles de l’ensemble de l’organisation. Suivez les règles d’engagement pour être sûr que l’accès et l’intention ne soient pas mal utilisés. Pour obtenir des conseils sur la planification et l’exécution d’attaques simulées, consultez Règles d’engagement des tests d’intrusion.

Condition requise 11.4

Utiliser les techniques d’intrusion-détection et/ou d’intrusion-prévention pour détecter et/ou empêcher les intrusions dans le réseau. Supervisez tout le trafic au périmètre de l’environnement de données du titulaire de la carte ainsi qu’aux points critiques de l’environnement des données du titulaire. Alertez le personnel en cas de compromission suspectée.

Vos responsabilités

Protégez le cluster AKS en inspectant le trafic entrant avec un pare-feu d’applications web (WAF). Dans cette architecture, Azure Application Gateway avec un WAF intégré empêche les intrusions. Utilisez le mode empêcher pour bloquer activement les intrusions et les attaques détectées. Ne vous contentez pas d’utiliser le mode détecter. Pour plus d’informations, consultez Bonnes pratiques pour la connectivité réseau et la sécurité dans Azure Kubernetes Service (AKS).

Une autre option consiste à utiliser les fonctionnalités de détection d’intrusion et/ou de prévention des intrusions dans le Pare-feu Azure Premium. Pour plus d’informations, consultez IDPS.

Une autre option consiste à activer Azure Monitor Network Insights, qui fournit l’accès aux fonctionnalités de supervision réseau, comme le Moniteur de connexion, la journalisation des flux pour les groupes de sécurité réseau et Traffic Analytics.

Activez les plans Microsoft Defender tels qu’ils s’appliquent aux différents composants de l’environnement CDE. Par exemple, si Azure SQL est utilisé pour stocker CHD, Microsoft Defender pour SQL s’assure que les intrusions de la couche de données sont détectées.

Détectez également les anomalies dans les modèles de trafic en connectant les journaux de flux NSG à une solution SIEM centralisée comme Microsoft Sentinel. Dans cette implémentation de référence, les journaux sont en mode d’ajout seul, ce qui réduit le suivi des modifications sur les journaux d’audit. Toutefois, tous les journaux qui sont envoyés aux récepteurs externes pour un stockage à long terme ne doivent pas être modifiés. Ils doivent suivre l’approche « écrire une fois/lire plusieurs ». Assurez-vous que la solution de supervision de l’intégrité des fichiers (FIM) couvre ces entités externes pour détecter les changements.

Condition requise 11.5

Déployez une solution de suivi des modifications (par exemple une solution de supervision de l’intégrité des fichiers) pour alerter le personnel en cas de modification non autorisée de fichiers système, de fichiers de configuration ou de fichiers de contenu critiques. Configurez le produit pour effectuer des comparaisons des fichiers critiques au moins une fois par semaine.

Vos responsabilités

Dans votre cluster, exécutez une solution de supervision de l’intégrité des fichiers (FIM) conjointement avec un agent de sécurité compatible Kubernetes pour détecter les accès au niveau fichier et système qui pourraient entraîner des changements au niveau nœud. Lors du choix d’une solution FIM, ayez une idée claire de ses fonctionnalités et de la profondeur de la détection. Considérez les logiciels développés par des fournisseurs réputés.

Vérifiez tous les paramètres par défaut de l’outil FIM pour garantir que les valeurs détectent les scénarios que vous voulez couvrir et adaptez ces paramètres de façon appropriée.

Activez la solution pour envoyer des journaux à votre solution de supervision ou SIEM afin qu’ils puissent générer des alertes. Attention aux changements de schéma de journal ou vous risquez de manquer des alertes critiques.

Le suivi des modifications doit être activé pour les autres calculs dans l’environnement CDE.

Condition requise 11.6

S’assurer que les stratégies de sécurité et les procédures opérationnelles pour la surveillance et les tests de sécurité sont documentées, utilisées et connues de toutes les parties concernées.

Vos responsabilités

Il est essentiel de conserver une documentation complète sur les processus et les stratégies. Maintenez la documentation sur les stratégies appliquées. Dans le cadre de vos efforts de test, incluez la cadence des révisions et les critères de révision. Assurez-vous que l’équipe comprend les aspects des tests de pénétration. Créez un plan de correction documenté pour atténuer les risques trouvés.

Ceci est important pour les personnes qui font partie du processus d’approbation du point de vue de la stratégie.

Étapes suivantes

Gérez une stratégie de sécurité des informations pour l’ensemble du personnel.