Architecture d’un cluster régulé par AKS pour PCI DSS 3.2.1 (partie 2 sur 9)

Cet article décrit une architecture de référence pour un cluster AKS (Azure Kubernetes Service) 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). Cette architecture est axée sur l’infrastructure, et non sur la charge de travail PCI-DSS 3.2.1.

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

Les recommandations et les exemples sont extraits de cette implémentation de référence qui l’accompagne :

GitHub : Azure Kubernetes Service (AKS) Baseline Cluster for Regulated Workloads montre l’infrastructure régulée. Cette implémentation fournit une application de microservices. Elle est incluse pour vous aider à expérimenter l’infrastructure et à illustrer les contrôles réseau et de sécurité. L’application ne représente pas ou n’implémente pas une charge de travail PCI DSS réelle.

Téléchargez un fichier Visio de cette architecture.

Cette architecture réseau est basée sur une topologie hub-and-spoke. Le réseau virtuel du hub contient le pare-feu pour contrôler le trafic de sortie, le trafic de passerelle des réseaux sur site, et un troisième réseau pour l'accès au cluster SRE (ingénieur de fiabilité du site). Il existe deux réseaux virtuels spoke. L’un des spokes contient le cluster AKS qui est un composant de l’environnement de données de titulaire de carte (CDE) et héberge la charge de travail PCI DSS. L’autre spoke crée des images de machine virtuelle utilisées pour l’accès SRE contrôlé à l’environnement.

Components

Voici les principaux composants utilisés dans cette architecture. Si vous n’êtes pas familiarisé avec ces services, consultez les services Azure associés pour obtenir des liens vers la documentation de produit.

Pare-feu Azure

L’instance de pare-feu sécurise le trafic réseau sortant. Sans cette couche de sécurité, le flux peut communiquer avec un service tiers malveillant susceptible d’exfiltrer des données d’entreprise sensibles.

Azure Bastion

L’architecture de base fournissait un sous-réseau pour Azure Bastion, mais ne provisionnait pas la ressource. Cette architecture ajoute Azure Bastion dans le sous-réseau, et fournit un accès sécurisé à une jumpbox.

Azure Image Builder

Approvisionné dans un réseau virtuel distinct, il crée des images de machine virtuelle avec une sécurité et une configuration de base. Dans cette architecture, il est personnalisé pour créer des images de nœud sécurisées avec des outils de gestion tels qu’Azure CLI, kubectl et l’interface de commande de flux préinstallée.

Azure Virtual Machine Scale Sets pour les instances de jump box

Le réseau spoke a une capacité de calcul supplémentaire pour une jump box. Ce groupe identique est destiné à être le point d’accès régi pour l’exécution d’outils sur le cluster AKS, par exemple kubectl, si nécessaire.

Azure Application Gateway avec le pare-feu d’applications web (WAF) intégré

Azure Application Gateway effectue un équilibrage de charge à la Couche 7. WAF protège le trafic entrant contre les attaques courantes du trafic web. L’instance présente une configuration IP frontale publique qui reçoit les demandes de l’utilisateur.

Azure Kubernetes Service (AKS)

Infrastructure d’hébergement, qui est une partie essentielle de l’environnement CDE. Le cluster AKS est déployé en tant que cluster privé. Par conséquent, le serveur d’API Kubernetes n’est pas exposé à l’Internet public, et le trafic vers le serveur d’API est limité à votre réseau privé.

ACR Tasks

Fournit un moyen automatisé de créer et de tenir à jour des images conteneur.

Azure Key Vault

Stocke et gère les secrets nécessaire aux opérations de cluster, tels que les certificats et les clés de chiffrement.

Configuration de clusters

Voici quelques modifications significatives par rapport à l’architecture de référence :

Segmentation des pools de nœuds

Dans cette architecture, le cluster a deux pools de nœuds utilisateur et un pool de nœuds système. Le choix de la capacité de calcul pour les pools de nœuds reste le même que dans l’architecture de base. Contrairement à l’architecture de base, chaque pool de nœuds réside dans un sous-réseau dédié pour fournir une frontière d’isolation réseau supplémentaire entre les niveaux de calcul.

La norme PCI-DSS 3.2.1 impose l’isolation de la charge de travail PCI des autres charges de travail en termes d’opérations et de connectivité.

• Dans l’étendue : la charge de travail PCI, l’environnement dans lequel elle réside et les opérations.

• Hors étendue : autres charges de travail qui peuvent partager des services, mais qui sont isolées des composants concernés.

La stratégie clé consiste à fournir le niveau de séparation requis. Le meilleur moyen consiste à déployer les composants dans l’étendue et hors étendue dans des clusters distincts. L’inconvénient d’utiliser plusieurs clusters est le coût plus élevé pour l’infrastructure supplémentaire et la surcharge de maintenance. Cette implémentation colocalise tous les composants dans un cluster partagé pour des raisons de simplicité. Si vous choisissez de suivre le modèle à cluster unique, utilisez une stratégie rigoureuse de segmentation au sein du cluster. Quelle que soit la façon dont vous choisissez de maintenir la séparation, sachez qu’à mesure que votre solution évolue, certains composants hors étendue pourront basculer dans l’étendue.

Dans l’implémentation de référence, nous démontrons l’approche du cluster partagé en déployant une application de microservices sur un seul cluster. Les charges de travail dans l’étendue et hors étendue sont segmentées dans deux pools de nœuds utilisateur distincts. L’application a deux ensembles de services ; l’un d’eux a des pods dans l’étendue, tandis que l’autre est hors étendue. Les deux ensembles sont répartis sur deux pools de nœuds utilisateur. En utilisant des taints Kubernetes, les pods dans le périmètre et hors du périmètre sont déployés sur des nœuds séparés et ne partagent jamais un nœud VM ni l’espace d’adressage IP du réseau.

Contrôleur d’entrée

L’architecture de base utilisait Traefik pour le contrôle d’entrée. Dans cette architecture de référence, nous utilisons plutôt Nginx. Ce changement illustre le fait que ce composant peut être modifié en fonction des exigences de votre charge de travail.

Serveur d’API Kubernetes privé

L’architecture de base de référence a déployé le cluster AKS en mode public. Cela signifie que toutes les communications avec le serveur d’API Kubernetes managé par AKS s’effectuent par le biais de l’Internet public. Cela n’est pas acceptable dans cette architecture, car la norme PCI-DSS 3.2.1 interdit l’exposition publique à tout composant système. Dans cette architecture réglementée, le cluster est déployé en tant que cluster privé. Le trafic réseau vers le serveur d’API Kubernetes est limité à votre réseau privé. Le serveur d’API est exposé par le biais d’un point de terminaison privé dans le réseau du cluster. La sécurité est encore améliorée grâce à l’utilisation de groupes de sécurité réseau et d’autres fonctionnalités intégrées. Celles-ci sont décrites dans Configuration réseau.

Sécurité des pods

Lorsque vous décrivez les besoins en matière de sécurité de votre charge de travail, utilisez des paramètres securityContext appropriés pour vos conteneurs. Cela comprend des paramètres de base tels que fsGroup, runAsUser / runAsGroup, et l’affectation de la valeur false à allowPrivilegeEscalation (sauf si la valeur true est requise). Soyez clair concernant la définition et la suppression des fonctionnalités Linux, ainsi que la définition de vos options SELinux dans seLinuxOptions.

Évitez de référencer des images d’après leurs étiquettes dans vos manifestes de déploiement. Utilisez plutôt l’ID d’image. Ainsi, vous pouvez mapper de manière fiable les résultats de l’analyse des conteneurs avec le contenu réel en cours d’exécution dans votre cluster. Vous pouvez appliquer cette stratégie par le biais d’Azure Policy, afin que le nom de l’image inclue le modèle d’ID d’image dans l’expression régulière autorisée. Respectez également ces recommandations lorsque vous utilisez l’instruction Dockerfile FROM.

Configuration de la mise en réseau

Les hub-spokes sont tous déployés dans des réseaux virtuels distincts, chacun dans leur espace d’adressage privé. Par défaut, aucun trafic n’est autorisé entre deux réseaux virtuels. Au sein du réseau, la segmentation est appliquée en créant des sous-réseaux.

Une combinaison de plusieurs services et fonctionnalités Azure et de constructions Kubernetes natives fournit le niveau de contrôle requis. Vous trouverez ci-dessous quelques options utilisées dans cette architecture.

Sécurité du sous-réseau par le biais de groupes de sécurité réseau (NSG)

Plusieurs NSG contrôlent le flux vers et à partir du cluster. Voici quelques exemples :

• Les pools de nœuds du cluster sont placés dans des sous-réseaux dédiés. Pour chaque sous-réseau, il existe des NSG qui bloquent tout accès SSH aux machines virtuelles de nœuds et autorisent le trafic à partir du réseau virtuel. Le trafic à partir des pools de nœuds est limité au réseau virtuel.

• Tout le trafic entrant à partir d’Internet est intercepté par Azure Application Gateway. Par exemple, les règles NSG garantissent que :

  • Seul le trafic HTTPS est autorisé en entrée.
  • Le trafic provenant du plan de contrôle Azure est autorisé en utilisant des étiquettes de service. Pour plus d’informations, consultez Autoriser l’accès à quelques adresses IP sources.

• Sur les sous-réseaux qui ont des agents Azure Container Registry, les NSG autorisent uniquement le trafic sortant nécessaire. Par exemple, le trafic est autorisé vers Azure Key Vault, Microsoft Entra ID, Azure Monitor et d’autres services avec lesquels le registre de conteneurs doit communiquer.

• Le sous-réseau avec la jump box est destiné aux opérations de gestion. La règle NSG sur le sous-réseau de la jump box ne permet que l’accès SSH à partir d’Azure Bastion dans le hub, ainsi que des connexions sortantes limitées. Les jump boxes ne disposent pas d’un accès Internet universel, et sont contrôlées au niveau du NSG de sous-réseau et du Pare-feu Azure.

À mesure que vos charges de travail, agents de sécurité système et autres composants sont déployés, ajoutez des règles NSG qui permettent de définir le type de trafic devant être autorisé. Le trafic ne doit pas traverser ces limites de sous-réseau. Étant donné que chaque pool de nœuds réside dans son propre sous-réseau, observez les modèles de trafic, puis appliquez des règles plus spécifiques.

Sécurité entre pods avec des stratégies réseau

Cette architecture tente d’implémenter autant que possible les principes de « Confiance Zéro » de Microsoft.

Des exemples de réseaux zéro confiance en tant que concept sont démontrés dans l’implémentation, au sein des a0005-i et a0005-o espaces de noms fournis par l’utilisateur. Chaque espace de noms de la charge de travail doit avoir une NetworkPolicy restrictive appliquée. Les définitions de stratégie dépendront des pods en cours d’exécution dans ces espaces de noms. Assurez-vous de prendre en compte les sondes de préparation, de vivacité et de démarrage, et d’autoriser la collecte des métriques par l’agent Log Analytics. Vous pouvez standardiser les ports sur vos charges de travail afin de fournir une stratégie réseau et une stratégie Azure Policy cohérentes pour les ports de conteneur autorisés.

Dans certains cas, cela n’est pas pratique pour la communication au sein du cluster. Tous les espaces de noms fournis par l’utilisateur ne peuvent pas utiliser un réseau de Confiance Zéro (cluster-baseline-settings, par exemple, en est incapable).

Chiffrement TLS

L’architecture de base de référence fournit le trafic chiffré TLS jusqu’au contrôleur d’entrée dans le cluster, mais la communication entre pods est en clair. Dans cette architecture, TLS s’étend au trafic entre pods, avec validation par l’autorité de certification. Le protocole TLS est fourni par un maillage de service, qui applique les connexions mTLS et la vérification avant d’autoriser la communication.

L’implémentation utilise mTLS. La prise en charge de mTLS peut être implémentée avec ou sans maillage de service. Si vous utilisez un maillage, vérifiez qu’il est compatible avec l’émetteur de certificat de votre choix. Cette implémentation utilise Open Service Mesh.

Le contrôleur d’entrée dans cette implémentation utilise un certificat générique pour gérer le trafic par défaut lorsqu’une ressource entrante ne contient pas de certificat spécifique. Cela peut être acceptable, mais si votre stratégie organisationnelle n’autorise pas l’utilisation des certificats génériques, vous devrez peut-être ajuster votre contrôleur d’entrée afin qu’il n’utilise pas de certificat générique.

Restrictions réseau Azure Key Vault

Tous les secrets, clés et certificats sont stockés dans Azure Key Vault. Key Vault gère les tâches de gestion des certificats, telles que la permutation. La communication avec Key Vault s’effectue par le biais d’Azure Private Link. L’enregistrement DNS associé à Key Vault se trouve dans une zone DNS privée, afin que sa résolution soit impossible à partir d’Internet. Bien que cela améliore la sécurité, il existe certaines restrictions.

Azure Application Gateway ne prend pas en charge l’obtention de certificats TLS pour l’écouteur HTTP à partir d’instances de Key Vault exposées avec Private Link. L’implémentation déploie donc Key Vault dans un modèle hybride. Il utilise toujours Private Link pour les connexions qui le prennent en charge, mais autorise également l’accès public pour l’intégration d’Application Gateway. Si cette approche hybride ne convient pas pour votre déploiement, déplacez le processus de gestion des certificats vers Application Gateway. Cela ajoutera une charge de gestion, mais l’instance Key Vault sera complètement isolée. Pour plus d’informations, consultez :

• Intégration d’Azure Application Gateway et de Key Vault
• Créer une passerelle d’application avec un arrêt TLS à l’aide de l’interface CLI Azure

Protection DDoS

Si vous avez des réseaux virtuels avec des adresses IP publiques, activez la protection réseau Azure DDoS. Dans cette architecture de référence, le sous-réseau qui contient Application Gateway a une adresse IP publique attachée, il est donc concerné par la protection DDoS.

La protection réseau Azure DDoS protège l’infrastructure et la charge de travail contre les demandes frauduleuses massives. De telles requêtes peuvent entraîner une interruption de service ou masquer une autre attaque simultanée. La protection réseau Azure DDoS représente un coût significatif, généralement amorti sur plusieurs charges de travail couvrant plusieurs adresses IP. Collaborez avec votre équipe de mise en réseau pour coordonner la couverture de vos charges de travail.

Gestion des identités et des accès

Définissez des rôles et un contrôle d’accès en fonction des exigences du rôle. Mappez les rôles aux actions Kubernetes, avec une étendue la plus étroite possible. Évitez les rôles qui s’étendent sur plusieurs fonctions. Si plusieurs rôles sont remplis par une personne, accordez à cette personne tous les rôles pertinents pour les fonctions équivalentes. Ainsi, même si une seule personne est directement responsable à la fois du cluster et de la charge de travail, créez vos ClusterRole Kubernetes comme s’il y avait des individus distincts. Accordez ensuite à cette seule personne tous les rôles pertinents.

Réduisez l’accès permanent, en particulier pour les comptes à impact élevé, pour des actions telles que les interactions SRE/Ops avec votre cluster. Le plan de contrôle AKS prend en charge le Microsoft Entra ID Privileged Access Management (PAM)juste-à-temps (JAT) et les stratégies d’accès conditionnel qui fournissent des couches supplémentaires de validation d’authentification requise pour l’accès privilégié, en fonction des règles que vous créez.

Pour plus d’informations sur l’utilisation de PowerShell pour configurer l’accès conditionnel, consultez New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy et Remove-MgIdentityConditionalAccessPolicy.

Chiffrement de disque

Lorsque vous concevez le chiffrement pour les données au repos, prenez en compte les disques de stockage, les machines virtuelles des nœuds de l’agent AKS, les autres machines virtuelles et les disques de système d’exploitation et temporaires.

Disques de stockage

Par défaut, les disques Stockage Azure sont chiffrés au repos avec des clés managées par Microsoft. Si vous utilisez des disques de système d’exploitation non éphémères, ou si vous ajoutez des disques de données, nous vous recommandons d’utiliser des clés gérées par le client pour contrôler les clés de chiffrement. Chiffrez en dehors de la couche de stockage, et écrivez uniquement des données chiffrées dans le support de stockage. Veillez également à ce que les clés ne soient jamais adjacentes à la couche de stockage. Pour plus d’informations, consultez BYOK (Bring Your Own Keys) avec des disques Azure.

Utilisez BYOK pour tous les autres disques susceptibles d’interagir avec le cluster, tels que vos jump boxes Azure Bastion. Si vous choisissez BYOK, le choix de la référence SKU pour les machines virtuelles et la disponibilité régionale seront limités, car cette fonctionnalité n’est pas prise en charge dans toutes les régions ou références SKU.

Hôtes de machine virtuelle

Nous vous recommandons d’activer la fonctionnalité de chiffrement sur l’hôte. Cela permet de chiffrer l’hôte de machine virtuelle et tout système d’exploitation temporaire, ou les disques de données qui sont mis en cache sur un hôte de machine virtuelle. Pour en savoir plus sur la prise en charge des machines virtuelles pour le chiffrement basé sur l’hôte, consultez cet article.

Cette fonctionnalité est étendue aux données stockées sur l’hôte de machine virtuelle de vos nœuds d’agent AKS par le biais de la fonctionnalité de chiffrement basé sur l’hôte. À l’instar de BYOK, cette fonctionnalité peut limiter les choix en matière de référence SKU de machine virtuelle et de région.

Vous pouvez appliquer ces fonctionnalités par le biais d’Azure Policy.

Sauvegardes de cluster (état et ressources)

Si votre charge de travail nécessite un stockage dans le cluster, vous devez disposer d’un processus robuste et sécurisé pour la sauvegarde et la récupération. Utilisez des services tels que Sauvegarde Azure (pour les disques Azure et fichiers Azure), pour la sauvegarde et la récupération de toute PersistentVolumeClaim. Il y a des avantages à ce que le système de sauvegarde prenne en charge les ressources Kubernetes natives. Vous pouvez compléter votre méthode principale qui rapproche le cluster d’un état bien connu, avec le système de sauvegarde pour les techniques de récupération système critiques. Cela peut par exemple aider à la détection de dérive et au catalogage des modifications d’état du système au fil du temps au niveau de la ressource Kubernetes.

Les processus de sauvegarde doivent classer les données dans la sauvegarde, que ces données proviennent du cluster ou de l’extérieur du cluster. Si les données sont dans l’étendue pour la norme PCI DSS 3.2.1, étendez vos limites de conformité de façon à inclure le cycle de vie et la destination de la sauvegarde, qui sera en dehors du cluster. Les sauvegardes peuvent être un vecteur d’attaque. Lors de la conception de votre sauvegarde, tenez compte des restrictions géographiques, du chiffrement au repos, des contrôles d’accès, des rôles et des responsabilités, de l’audit, de la durée de vie et de la prévention des falsifications.

Les systèmes de sauvegarde dans le cluster sont censés s’exécuter avec des privilèges élevés. Évaluez les risques et les avantages liés à l’intégration d’un agent de sauvegarde dans votre cluster. La capacité de l’agent chevauche-t-elle une autre solution de gestion dans le cluster ? Quel est l’ensemble minimal d’outils dont vous avez besoin pour accomplir cette tâche sans étendre la surface d’attaque ?

Considérations relatives à Azure Policy

En règle générale, les stratégies Azure appliquées n’ont pas de paramètres configurés par la charge de travail. Dans l’implémentation, nous appliquons l’initiative Kubernetes cluster pod security restricted standards pour les charges de travail basées sur Linux, qui fait partie des initiatives de politiques intégrées. Cette initiative ne permet pas de réglage des paramètres. Pensez à exporter cette initiative et à personnaliser ses valeurs pour votre charge de travail spécifique. Vous pouvez inclure toutes les stratégies Azure deny Gatekeeper sous une même initiative personnalisée, et toutes les stratégies Azure audit sous une autre initiative. Cela permet de catégoriser les actions de blocage des stratégies « informations uniquement ».

Incluez les espaces de noms kube-system et gatekeeper-system aux stratégies dans vos stratégies kube-system pour une visibilité accrue. L’inclusion de ces espaces de noms dans les stratégies de refus peut entraîner une défaillance du cluster en raison d’une configuration non prise en charge.

Vous pouvez appliquer le chiffrement des données en définissant des alertes Azure Policy. Par exemple, vous pouvez appliquer BYOK avec une alerte qui détecte les clusters qui n’ont pas diskEncryptionSetID sur la ressource de cluster. Une autre stratégie peut détecter si le chiffrement basé sur l’hôte est activé sur agentPoolProfiles. L’implémentation de référence n’utilise pas de disques dans le cluster, et le disque du système d’exploitation est éphémère. Ces deux exemples de stratégies sont en place en guise de rappel de la fonctionnalité de sécurité. Les stratégies ont la valeur audit, et non block.

Gestion des images

Utilisez des images de base sans distribution pour vos charges de travail. Avec ces images, la surface d’exposition de sécurité est réduite, car les images supplémentaires, telles que les shells et les gestionnaires de packages, sont supprimées. L’un des avantages est une réduction des taux d’accès CVE.

Azure Container Registry prend en charge les images qui répondent à la spécification de format d’image OCI (Open Container Initiative). Ceci, couplé à un contrôleur d’admission qui prend en charge la validation des signatures, peut garantir que vous exécutez uniquement les images que vous avez signées avec vos clés privées. Il existe des solutions open source, telles que SSE Connaisseur ou IBM Portieris, qui intègrent ces processus.

Protégez les images conteneur et autres artefacts OCI, car ils contiennent la propriété intellectuelle de l’organisation. Utilisez des clés gérées par le client et chiffrez le contenu de vos registres. Par défaut, les données sont chiffrées au repos avec des clés managées par le service. Cependant, des clés gérées par le client sont parfois nécessaires pour satisfaire aux normes de conformité réglementaire. Stockez la clé dans un magasin de clés managé tel qu’Azure Key Vault. Étant donné que vous créez la clé et que vous en êtes propriétaire, vous êtes responsable des opérations liées au cycle de vie de la clé, notamment la permutation et la gestion. Pour plus d’informations, consultez Chiffrer un registre à l’aide d’une clé gérée par le client.

Accès opérationnel au serveur d’API Kubernetes

Vous pouvez limiter les commandes exécutées sur le cluster sans nécessairement créer un processus opérationnel basé sur des jump boxes. Si vous disposez d’une plateforme d’automatisation informatique IAM, utilisez les actions prédéfinies pour contrôler et auditer le type d’action.

Agents de build

Les agents de pipeline doivent être hors étendue pour le cluster régulé, car les processus de génération peuvent être des vecteurs de menaces. Par exemple, les processus de build travaillent souvent avec des composants non testés et non fiables.

Bien qu’il soit courant d’utiliser Kubernetes comme infrastructure d’agent de build élastique, n’exécutez pas ce processus dans la limite du runtime de charge de travail régulé. Vos agents de build ne doivent pas avoir un accès direct au cluster. Par exemple, accordez uniquement aux agents de build un accès réseau à Azure Container Registry pour leur permettre d’envoyer des images conteneur, des graphiques Helm, et ainsi de suite. Ensuite, déployez par le biais de GitOps. En règle générale, les workflows de build et de mise en production ne doivent pas avoir un accès direct à votre API de cluster Kubernetes (ou à ses nœuds).

Surveillance des opérations

Activités dans le cluster

Les pods omsagent dans le cluster qui s’exécutent dans kube-system sont l’agent de collecte Log Analytics. Ils collectent la télémétrie, scrapent les journaux stdout et stderr des conteneurs, et recueillent les métriques Prometheus. Vous pouvez régler leurs paramètres de collecte en mettant à jour le fichier ConfigMap container-azm-ms-agentconfig.yaml. Dans cette implémentation de référence, la journalisation est activée dans kube-system et dans toutes vos charges de travail. Par défaut, kube-system est exclu de la journalisation. Veillez à ajuster le processus de collecte des journaux pour atteindre les objectifs en termes d’équilibre des coûts et d’efficacité SRE lorsque vous examinez les journaux, et satisfaire les besoins en matière de conformité.

Surveillance de la sécurité

Utilisez Defender pour les conteneurs dans Microsoft Defender pour le cloud pour afficher et appliquer les recommandations de sécurité et pour afficher les alertes de sécurité sur vos ressources de conteneur. Activez les plans Microsoft Defender tels qu’ils s’appliquent aux différents composants de l’environnement de données du titulaire de la carte (CDE).

Intégrez les journaux afin de pouvoir examiner, analyser et interroger efficacement les données. Azure fournit plusieurs options. Vous pouvez activer les journaux de diagnostic AKS et les envoyer à un espace de travail Log Analytics faisant partie d’Azure Monitor. Une autre option consiste à intégrer des données dans des solutions SIEM (Security Information and Event Management), telles que Microsoft Sentinel.

Conformément aux exigences de la norme, tous les espaces de travail Log Analytics sont configurés avec une période de conservation de 90 jours. Vous pouvez configurer l’exportation continue pour un stockage à plus long terme. Ne stockez pas d’informations sensibles dans les données de journal et assurez-vous que l’accès aux données de journal archivées est soumis aux mêmes niveaux de contrôles d’accès que les données de journal récentes.

Pour une vue d’ensemble complète, consultez le Guide d’intégration d’entreprise de Microsoft Defender pour le cloud. Ce guide traite de l’inscription, des exportations de données vers vos solutions SIEM, de la réponse aux alertes et de la création de l’automatisation de workflow.

Services Azure connexes

Voici des liens vers la documentation des fonctionnalités de certains composants clés de cette architecture.

• Azure Kubernetes Service (AKS)
• Pare-feu Azure
• Azure Bastion
• Azure Image Builder
• Groupes de machines virtuelles identiques Azure
• Azure Application Gateway avec le pare-feu d’applications web (WAF) intégré
• Tâches Azure Container Registry
• Azure Key Vault

Étapes suivantes

Installer et gérer la configuration d’un pare-feu pour protéger les données des titulaires de carte. Ne pas utiliser les mots de passe système et autres paramètres de sécurité par défaut définis par le fournisseur.