Configurer la mise en réseau d’un cluster régulé par AKS pour PCI DSS 3.2.1 (partie 3 sur 9)

Cet article décrit les considérations réseau relatives à un cluster Azure Kubernetes Service (AKS) configuré conformément à la norme de sécurité des données du secteur des cartes de paiement (PCI-DSS 3.2.1).

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

Le thème principal de la norme PCI-DSS 3.2.1 est la sécurité. La topologie hub-spoke est un choix naturel pour configurer un environnement réseau réglementé. Il est plus facile de créer une infrastructure permettant des communications sécurisées. Les contrôles réseau sont placés sur des réseaux hub-and-spoke et suivent le modèle Confiance Zéro de Microsoft. Les contrôles peuvent être ajustés avec le moins de privilèges possible afin de sécuriser le trafic, ce qui fournit donc un accès basé sur la nécessité. De plus, vous pouvez appliquer plusieurs approches de défense en profondeur en ajoutant des contrôles à chaque saut et couche du réseau.

Lorsque vous hébergez une charge de travail dans Kubernetes, les constructions réseau traditionnelles, telles que les règles de pare-feu, ne sont pas suffisantes. Il existe également des constructions Kubernetes natives qui contrôlent le flux du trafic dans un cluster, telles que la ressource NetworkPolicy. Nous vous recommandons vivement de vous reporter à la documentation Kubernetes pour comprendre les concepts fondamentaux relatifs aux pods isolés, ainsi qu’aux stratégies d’entrée et de sortie.

Créer et gérer un réseau et des systèmes sécurisés

Condition requise 1 : Installez et maintenez une configuration de pare-feu pour protéger les données des titulaires de carte.

Prise en charge des fonctionnalités AKS

AKS permet de déployer un cluster en tant que cluster privé dans un réseau virtuel privé. La communication entre le cluster et le serveur d’API Kubernetes géré par AKS se fait via un réseau approuvé. Avec un cluster privé, vous pouvez utiliser le réseau virtuel Azure, le groupe de sécurité réseau (NSG) ainsi que d’autres contrôles réseau intégrés afin de sécuriser l’ensemble de l’environnement de données des titulaires de carte. Cette configuration interdit tout accès public non autorisé entre Internet et l’environnement. Pour plus d’informations sur le provisionnement d’un cluster de ce type, consultez Créer un cluster Azure Kubernetes Service privé.

Vous pouvez intégrer le Pare-feu Azure à AKS et ainsi limiter le trafic sortant du cluster, ce qui est une fonctionnalité clé de l’environnement CDE. Vous pouvez simplifier la configuration en utilisant une étiquette de nom de domaine complet AKS. Le processus qu’il est recommandé de suivre est indiqué dans Utiliser le Pare-feu Azure pour protéger des déploiements d’Azure Kubernetes service (AKS).

Les clusters AKS nécessitent un accès Internet public. Limitez le trafic sortant vers Internet à l’aide du Pare-feu Azure et de groupes de sécurité réseau situés sur le sous-réseau du cluster. Pour plus d’informations, consultez Contrôler le trafic de sortie pour les nœuds de cluster dans Azure Kubernetes Service (AKS).

AKS prend éventuellement en charge la possibilité de définir un proxy HTTP utilisable pour exercer un contrôle et une surveillance supplémentaires du trafic sortant pour le cluster. Les nœuds de cluster utilisent la configuration de proxy HTTP spécifiée pour le routage du trafic sortant. De plus, un webhook en mutation étant inscrit pour injecter les informations de proxy dans les pods au moment de la création, il est recommandé que les charges de travail puissent hériter des mêmes informations de proxy. Les pods pouvant remplacer les informations de proxy, il est recommandé d’utiliser un proxy HTTP en plus d’un pare-feu Azure.

Les clusters AKS doivent être créés avec le plug-in NetworkPolicy. Dans AKS, vous avez plusieurs options pour votre plugin de politique réseau, y compris Calico, Azure Network Policy Management et Cilium. Avec la politique réseau Calico, vous pouvez utiliser soit Kubenet soit Azure CNI. Pour Azure Network Policy Management, vous pouvez uniquement utiliser Azure CNI (pas Kubenet). Les plug-ins de stratégie réseau Azure et Calico sont open source. Pour plus d’informations sur Project Calico, consultez le livre blanc sur les solutions complètes PCI, qui répond à la plupart des exigences en matière de pare-feu, visibles ci-dessous.

Vos responsabilités

Condition requise	Responsabilité
Condition requise 1.1	Établissez et implémentez les standards de configuration des pare-feu et des routeurs.
Condition requise 1.2	Créer des configurations de pare-feu et de routeur qui limitent les connexions entre les réseaux non approuvés et tous les composants système dans l’environnement CDE.
Condition requise 1.3	Interdire l’accès public direct entre Internet et tout composant du système dans l’environnement des données de titulaires de carte.
Condition requise 1.4	Installer un logiciel de pare-feu personnel ou une fonctionnalité équivalente sur tout appareil informatique portable (notamment les appareils appartenant à la société et/ou à l’employé) qui se connecte à Internet en dehors du réseau (par exemple, les ordinateurs portables utilisés par les employés) et qui permet également un accès à l’environnement CDE.
Condition requise 1.5	Garantir que les stratégies de sécurité et les procédures opérationnelles pour la gestion des pare-feu sont documentées, utilisées et connues de toutes les parties concernées.

Condition requise 1.1

Établissement et implémentation des standards de configuration des pare-feu et des routeurs comprenant ce qui suit :

Condition requise 1.1.1

Processus formel d’approbation et de test de toutes les connexions réseau et des changements apportés aux configurations des pare-feu et des routeurs.

Vos responsabilités

N’implémentez pas les configurations manuellement, par exemple en utilisant directement le portail Azure ou Azure CLI. Nous vous recommandons d’utiliser l’Infrastructure as code (IaC). Avec l’IaC, l’infrastructure est gérée à l’aide d’un modèle descriptif qui utilise un système de contrôle de version. Un modèle IaC génère le même environnement chaque fois qu’il est appliqué. Des exemples courants d’IaC sont Bicep, les modèles Azure Resource Manager (modèles ARM) ou Terraform. Si vous ne pouvez pas utiliser l’IaC, vous devez avoir un processus bien documenté pour le suivi, l’implémentation et le déploiement sécurisé des modifications des règles de pare-feu. Pour plus d’informations, reportez-vous à Condition requise 11.2.

Vous devrez utiliser une combinaison de différents contrôles réseau, notamment le Pare-feu Azure, les groupes de sécurité réseau et la ressource NetworkPolicy Kubernetes.

Réduisez le nombre de personnes qui peuvent accéder aux contrôles réseau et les modifier. Attribuez des rôles et des responsabilités clairs aux équipes. Par exemple, l’équipe réseau d’une organisation validera les modifications selon les stratégies de gouvernance définies par les équipes informatiques. Mettez en place un processus d’approbation contrôlé qui implique des personnes et des processus dans le but d’approuver les modifications apportées à une configuration réseau. Le processus doit inclure une étape pour tester tous les contrôles réseau. Créez une documentation décrivant en détail le processus.

Condition requise 1.1.2

Diagramme du réseau actuel qui identifie toutes les connexions entre l’environnement CDE et les autres réseaux, notamment tout réseau sans fil

Vos responsabilités

Dans votre documentation, incluez un diagramme représentant le flux réseau, avec le trafic entrant, le trafic sortant et des contrôles de sécurité. Cela inclut le flux de trafic provenant d’autres réseaux, y compris les réseaux sans fil de l’environnement CDE. Le diagramme doit également afficher les flux qui traversent le cluster. Il existe des exigences spécifiques pour les diagrammes, y compris qu’ils doivent montrer les capteurs d’intrusion et les contrôles appliqués.

Cette image montre le diagramme réseau de l’implémentation de référence.

Télécharger un fichier Visio de ce diagramme.

Figure 1.1.2 - Flux réseau

La description de ce flux se trouve dans les sections suivantes.

Vous pouvez afficher la topologie d’un réseau virtuel Azure si vous disposez d’Azure Network Watcher. Vous pouvez voir toutes les ressources d’un réseau virtuel, les ressources associées aux ressources d’un réseau virtuel ainsi que les relations entre ces ressources.

Condition requise 1.1.3

Diagramme actuel montrant le flux des données de titulaires de carte dans les systèmes et les réseaux.

Vos responsabilités

Dans le cadre de votre documentation, incluez un diagramme de données qui montre comment les données sont protégées aussi bien au repos qu’en transit.

Le diagramme doit indiquer les entrées et les sorties de données de la charge de travail, ainsi que les informations qui sont passées d’une ressource à l’autre. Veillez à ce que le diagramme soit toujours à jour. Ajoutez une étape dans le cadre du processus de gestion des modifications afin de mettre à jour le diagramme du flux de données.

Étant donné que cette architecture est axée sur l’infrastructure et non sur la charge de travail, nous avons omis certaines illustrations.

Condition requise 1.1.4

Conditions relatives au pare-feu au niveau de chaque connexion Internet, et entre une zone démilitarisée (DMZ) et la zone de réseau interne.

Vos responsabilités

Établir avec clarté à quoi correspond la limite d’une zone DMZ. Par exemple, l’environnement de données des titulaires de carte (CDE) peut se trouver dans une DMZ sécurisée par un pare-feu, des politiques réseau et d’autres contrôles. Pour plus d’informations, consultez Zone DMZ cloud.

Pour une infrastructure PCI DSS, vous êtes responsable de la sécurisation du CDE en utilisant des contrôles réseau pour bloquer l’accès non autorisé entrant et sortant du réseau contenant le CDE. Les contrôles réseau doivent être configurés correctement pour renforcer la sécurité. Ils doivent être appliqués à :

• La communication entre les composants colocalisés au sein du cluster.
• La communication entre la charge de travail et les autres composants des réseaux approuvés.
• La communication entre la charge de travail et l’Internet public.

Cette architecture utilise différentes technologies de pare-feu pour inspecter le trafic circulant dans les deux directions, c’est-à-dire le trafic entrant et sortant du cluster qui héberge l’environnement CDE :

• Azure Application Gateway est utilisé comme routeur de trafic, et son pare-feu d’applications web intégré (WAF) est utilisé pour sécuriser le trafic entrant (ingress) vers le cluster.

• Le Pare-feu Azure est utilisé pour sécuriser tout le trafic sortant (sortie) provenant des réseaux et de leurs sous-réseaux.

  Dans le cadre du traitement d’une transaction ou des opérations de gestion, le cluster devra communiquer avec des points de terminaison externes. Par exemple, le cluster peut nécessiter une communication avec le plan de contrôle AKS, une communication avec les systèmes de mise à jour du système d’exploitation et des paquets, et de nombreuses charges de travail interagissent avec des API externes. Certaines de ces interactions peuvent être effectuées via une connexion HTTP et doivent être considérées comme des vecteurs d’attaque. Ces vecteurs sont des cibles pour une attaque de l’intercepteur pouvant entraîner une exfiltration de données. L’ajout d’un pare-feu au trafic de sortie atténue cette menace.

  Il est même recommandé de chiffrer les communications de pod à pod à l’aide du protocole TLS. Cette pratique est illustrée dans la mise en œuvre de référence avec l’utilisation de l’authentification mutuelle TLS (mTLS).

• Des groupes de sécurité réseau sont ajoutés pour sécuriser le trafic entre le cluster et d’autres composants au sein de l’infrastructure. Par exemple, dans l’implémentation de référence, des groupes de sécurité réseau présents sur un sous-réseau avec des pools de nœuds bloquent toutes les tentatives d’accès SSH. Seul le trafic provenant de l’intérieur du réseau virtuel est autorisé.

  Si vous ajoutez des composants à l’architecture, vous pouvez ajouter des groupes de sécurité réseau qui autorisent ou refusent certains types de trafic au niveau des limites du sous-réseau. Étant donné que chaque pool de nœuds se trouve dans un sous-réseau dédié, appliquez des règles plus spécifiques en fonction des modèles de trafic attendus de votre charge de travail.

• Les objets Kubernetes NetworkPolicy sont utilisés pour contrôler les communications intra-cluster.

  Par défaut, il n’existe aucune restriction sur la communication de pod à pod. Vous devez appliquer NetworkPolicy aux communications dans le cluster, en commençant par un réseau Confiance Zéro et en ouvrant des chemins en fonction des besoins. L’implémentation de référence présente des réseaux Confiance Zéro dans les espaces de noms a0005-i et a0005-o. Tous les espaces de noms (à l’exception de kube-system, gatekeeper-system et d’autres espaces de noms fournis par AKS) ont des politiques réseau restrictives appliquées. La définition de stratégie dépend des pods qui sont exécutés dans ces espaces de noms. Veillez à ouvrir des chemins pour les probes readiness, liveliness et startup. Ouvrez également le chemin de oms-agent pour que les métriques au niveau du nœud puissent être envoyées. Vous pouvez standardiser les ports des charges de travail afin de fournir une stratégie NetworkPolicy et une stratégie Azure Policy cohérentes aux ports de conteneurs autorisés.

Condition requise 1.1.5

Description des groupes, des rôles et des responsabilités pour la gestion des composants du réseau.

Vos responsabilités

Vous devez fournir des contrôles sur les flux réseau et les composants impliqués. L’infrastructure résultante aura plusieurs segments réseau, chacun avec de nombreux contrôles, et chaque contrôle avec son propre objectif. Assurez-vous que votre documentation couvre un large éventail, de la planification du réseau à toutes les configurations appliquées. Elle doit également inclure des détails sur la propriété, avec des lignes de responsabilité claires et les rôles qui en sont responsables.

Par exemple, sachez qui est responsable de la gouvernance de la sécurisation des réseaux entre Azure et Internet. Dans une entreprise, l’équipe informatique est généralement responsable de la configuration et de la maintenance des règles de pare-feu Azure, des règles du pare-feu d’applications web (WAF), des NSG et d’autres trafics inter-réseaux. Elle peut également être responsable de l’allocation des réseaux virtuels et des sous-réseaux de l’entreprise, ainsi que de la planification des adresses IP.

Au niveau de la charge de travail, un opérateur de cluster est chargé de gérer les réseaux Confiance Zéro par le biais de stratégies réseau. Ses responsabilités peuvent aussi comprendre la communication avec le plan de contrôle Azure, les API Kubernetes et les technologies de supervision.

Commencez toujours par une stratégie de type « tout refuser ». Accordez l’autorisation uniquement lorsqu’il existe un besoin métier ou une justification de rôle.

Condition requise 1.1.6

Documentation de la justification métier et approbation de l’utilisation de tous les services, protocoles et ports autorisés, notamment la documentation des fonctions de sécurité implémentées pour les protocoles considérés comme étant non sécurisés.

Vos responsabilités

Ayez une documentation détaillée décrivant les services, les protocoles et les ports utilisés dans les contrôles réseau. Refusez tout, à l’exception des ports explicitement autorisés. Documentez les justifications métier et les fonctionnalités de sécurité documentées si l’utilisation de protocoles non sécurisés ne peut pas être évitée. Voici quelques exemples issus de l’implémentation de référence pour le Pare-feu Azure. Les règles de pare-feu doivent s’appliquer exclusivement aux ressources qui leur sont associées. Autrement dit, seul le trafic provenant de certaines sources est autorisé à accéder à certaines cibles de nom de domaine complet.

Voici quelques exemples où vous pourriez autoriser du trafic :

Règle	Protocole:Port	Source	Destination	Justification
Autoriser les communications sécurisées entre les nœuds et le plan de contrôle.	HTTPS:443	Plages d’adresses IP autorisées attribuées aux pools de nœuds de cluster	Liste des cibles de nom de domaine complet dans le plan de contrôle AKS. Celle-ci est spécifiée avec l’étiquette de nom de domaine complet AzureKubernetesService.	Les nœuds doivent pouvoir accéder au plan de contrôle pour les outils de gestion, les informations sur l’état et la configuration, ainsi que les informations permettant de savoir quels nœuds peuvent être mis à l’échelle.
Autorisez la communication sécurisée entre Flux et GitHub.	HTTPS:443	Pools de nœuds AKS	github.com, api.github.com	Flux est une intégration tierce qui s’exécute sur les nœuds. Elle synchronise la configuration du cluster avec un dépôt GitHub privé.

Condition requise 1.1.7

Passer en revue les règles concernant les pare-feu et les routeurs au moins tous les six mois.

Vos responsabilités

Mettez en place des processus permettant de passer en revue au moins tous les six mois les configurations réseau et les règles délimitées. Cela garantira que les assurances de sécurité sont à jour et valides. Passez en revue les configurations suivantes :

• Les règles de Pare-feu Azure.
• Les règles de groupe de sécurité réseau.
• Les règles Azure Application Gateway et WAF.
• Les stratégies réseau Kubernetes natif.
• Les contrôles de pare-feu des ressources Azure applicables. Par exemple, cette architecture utilise une règle dans Azure Container Registry qui autorise uniquement le trafic à partir d’un point de terminaison privé.
• Tout autre contrôle de réseau que vous avez ajouté à l’architecture.

Si vous avez retiré des charges de travail ou modifié la configuration du cluster depuis la dernière révision, il est important de vérifier que toutes les hypothèses faites concernant les exceptions de pare-feu requises ou les règles NSG sont toujours valides.

Condition requise 1.2

Créer des configurations de pare-feu et de routeur qui limitent les connexions entre les réseaux non approuvés et tous les composants système dans l’environnement CDE.

Vos responsabilités

Dans cette architecture, le cluster AKS est un composant clé de l’environnement CDE. Pour renforcer la sécurité, nous vous recommandons vivement de déployer le cluster comme un cluster privé. Dans un cluster privé, le trafic réseau entre le serveur d’API Kubernetes géré par AKS et vos pools de nœuds est privé. Le serveur d’API est exposé via un point de terminaison privé dans le réseau du cluster.

Vous pouvez également choisir un cluster public, mais cette conception n’est pas recommandée pour les clusters contenant des charges de travail réglementées. En effet, le serveur d’API sera exposé à Internet. L’enregistrement DNS sera toujours découvrable. Vous devrez donc disposer de contrôles pour protéger l’API de cluster contre tout accès public. Si l’utilisation d’un cluster public est requise, l’approche recommandée consiste à avoir des contrôles stricts via des contrôles d’accès en fonction du rôle (RBAC) Kubernetes, associés à la fonctionnalité de plages d’adresses IP autorisées AKS pour restreindre les personnes autorisées à accéder au serveur d’API AKS. Toutefois, cette solution n’est pas recommandée pour les clusters qui contiennent des charges de travail réglementées.

Lors du traitement des données d’un titulaire de carte, le cluster doit interagir aussi bien avec les réseaux approuvés qu’avec les réseaux non approuvés. Dans cette architecture, les deux réseaux hub-and-spoke situés dans le périmètre de la charge de travail PCI-DSS 3.2.1 sont considérés comme des réseaux approuvés.

Les réseaux non approuvés sont des réseaux situés en dehors de ce périmètre. Les réseaux non fiables incluent :

• Les autres hubs et spokes qui peuvent être sur la même infrastructure, mais en dehors du périmètre de la charge de travail.
• L’Internet public.
• Le réseau d’entreprise.
• D’autres réseaux virtuels dans Azure ou une autre plateforme cloud.

Dans cette architecture, le réseau virtuel qui héberge Image Builder n’est pas approuvé, car il n’a aucun rôle à jouer dans la gestion des données d’un titulaire de carte. L’interaction de l’environnement CDE avec ces réseaux doit être sécurisée conformément aux exigences. Avec ce cluster privé, vous pouvez utiliser des réseaux virtuels, des NSG et d’autres fonctionnalités intégrées pour sécuriser l’ensemble de l’environnement.

Pour plus d’informations sur les clusters privés, consultez Créer un cluster Azure Kubernetes Service privé.

Condition requise 1.2.1

Restreindre le trafic entrant et sortant à ce qui est nécessaire à l’environnement des données de titulaires de carte, et refuser tout autre trafic.

Vos responsabilités

Par conception, les réseaux virtuels Azure ne peuvent pas être atteints directement depuis Internet public. Tout le trafic entrant (ou d’entrée) doit traverser un routeur de trafic intermédiaire. Cependant, par défaut, tous les composants du réseau peuvent atteindre des points de terminaison publics. Vous pouvez désactiver ce comportement en configurant un sous-réseau privé, ou en utilisant un UDR pour envoyer tout le trafic sortant via un pare-feu. Ce trafic sortant (ou trafic de sortie) doit être explicitement sécurisé pour n’autoriser que des chiffrements sécurisés et TLS 1.2 ou ultérieur.

• Le WAF intégré d’Azure Application Gateway intercepte tout le trafic HTTP(S) entrant et dirige le trafic inspecté vers le cluster.

  Ce trafic peut provenir de réseaux approuvés ou non approuvés. Application Gateway est provisionné dans un sous-réseau du réseau spoke, et il est sécurisé par un groupe de sécurité réseau. Au fur et à mesure que le trafic circule, les règles WAF autorisent ou refusent, et Application Gateway dirige le trafic vers le backend configuré. Par exemple, Application Gateway protège l’environnement CDE en refusant ce type de trafic :

  • Tout le trafic qui n’est pas chiffré à l’aide du TLS.
  • Le trafic situé en dehors de la plage de ports pour la communication avec le plan de contrôle à partir de l’infrastructure Azure.
  • Les requêtes de sonde d’intégrité envoyées par des entités autres que le répartiteur de charge interne du cluster.

• Le Pare-feu Azure est utilisé pour sécuriser tout le trafic sortant (de sortie) provenant de réseaux approuvés et non approuvés.

  Le Pare-feu Azure est provisionné dans un sous-réseau du réseau hub. Dans le but d’appliquer le Pare-feu Azure comme point de sortie unique, des routages définis par l’utilisateur sont utilisés sur les sous-réseaux qui sont capables de générer du trafic sortant. Cela comprend les sous-réseaux appartenant à des réseaux non approuvés, comme le réseau virtuel Image Builder. Une fois que le trafic atteint le Pare-feu Azure, plusieurs règles délimitées sont appliquées de manière à autoriser le trafic provenant de certaines sources à accéder à certaines cibles.

  Pour plus d’informations, consultez Utiliser le Pare-feu Azure pour protéger des déploiements d’Azure Kubernetes Service (AKS).

• Si vous le souhaitez, il est possible d’utiliser un proxy HTTP pour superviser et sécuriser le trafic sortant (de sortie), du cluster vers des ressources externes.

  En plus d’un pare-feu, certaines organisations peuvent vouloir utiliser un proxy HTTP pour disposer de contrôles supplémentaires sur la sortie. Nous vous recommandons de toujours avoir des routes définies par l’utilisateur vers le pare-feu et de limiter le trafic de sortie pour accéder simplement au proxy HTTP. Avec cette configuration, si un pod tente de remplacer le proxy, le pare-feu peut toujours bloquer le trafic de sortie.

  Pour plus d’informations, consultez Prise en charge du proxy HTTP dans Azure Kubernetes Service.

Le cluster pourrait devoir accéder à d’autres services via l’Internet public. Par exemple, si vous utilisez un logiciel anti-malware tiers, il devra obtenir les définitions de virus d’un serveur via Internet public.

Les interactions avec les points de terminaison d’autres services Azure sont effectuées via la dorsale principale Azure. Par exemple, dans le cadre des opérations habituelles, le cluster doit obtenir des certificats du magasin de clés gérées, tirer (pull) des images d’un registre de conteneurs, etc. Assurez-vous que ces interactions sont privées et sécurisées à l’aide d’Azure Private Link.

En plus des règles de pare-feu et des réseaux privés, les flux de trafic sont également sécurisés via des règles NSG. Voici quelques exemples issus de cette architecture où l’environnement CDE est protégé par le refus du trafic :

• Les NSG sur les sous-réseaux qui ont des pools de nœuds refusent tout accès SSH aux nœuds. Assurez-vous d’avoir un processus en place pour un accès d’urgence juste à temps tout en maintenant le principe de tout-refuser.
• Un NSG sur le sous-réseau qui contient la jump box pour exécuter les outils de gestion refuse tout le trafic sauf depuis Azure Bastion dans le réseau hub.
• Les NSG sur les sous-réseaux qui ont les points de terminaison privés vers Azure Key Vault et Azure Container Registry refusent tout le trafic sauf depuis le répartiteur de charge interne et le trafic via Azure Private Link.

Condition requise 1.2.2

Sécuriser et synchroniser les fichiers de configuration des routeurs.

Vos responsabilités

Mettez en place un mécanisme de détection des écarts entre l’état de déploiement et l’état souhaité. L’Infrastructure as Code (IaC) constitue un très bon choix pour cela. Par exemple, les fichiers Bicep ou les modèles Azure Resource Manager (modèles ARM) conservent un enregistrement de l’état souhaité.

Les ressources de déploiement, telles que les fichiers Bicep, doivent être contrôlées par le référentiel afin que vous ayez l’historique de tous les changements. Collectez des informations dans les journaux d’activité Azure, les journaux de pipeline de déploiement et les journaux de déploiement Azure. Ces sources vous aideront à conserver une trace des ressources déployées.

Dans le cluster, les contrôles réseau, tels que les stratégies réseau Kubernetes, doivent également suivre le flux sous contrôle de code source. Dans cette implémentation, Flux est utilisé comme opérateur GitOps. Lorsque vous synchronisez une configuration de cluster telle que des stratégies réseau, votre historique Git, combiné aux journaux Flux et aux journaux d’API, peut constituer une source d’historique de configuration.

Condition requise 1.2.3

Installer des pare-feu de périmètre entre tous les réseaux sans fil et l’environnement CDE, et configurer ces pare-feu pour refuser ou, s’il est nécessaire à des fins professionnelles, autoriser uniquement le trafic entre l’environnement sans fil et l’environnement CDE.

Vos responsabilités

Les nœuds AKS et les pools de nœuds ne doivent pas être accessibles à partir des réseaux sans fil. En outre, les demandes adressées au serveur d’API Kubernetes doivent être refusées. L’accès à ces composants est limité aux sous-réseaux autorisés et sécurisés.

En général, vous devez limiter l’accès au réseau spoke à partir du trafic local.

Condition requise 1.3

Interdire l’accès public direct entre Internet et tout composant du système dans l’environnement des données de titulaires de carte.

Vos responsabilités

Les pools de nœuds des clusters AKS fonctionnent dans le réseau virtuel et sont isolés des réseaux publics tels qu’Internet. Maintenez l’isolation en empêchant l’association d’adresses IP publiques aux nœuds de cluster, et en appliquant des règles de groupe de sécurité réseau aux sous-réseaux de cluster afin de garantir le blocage du trafic Internet. Pour plus d’informations sur l’accès contrôlé, consultez la section relative à la zone DMZ.

Le cluster AKS comprend des pools de nœuds système qui hébergent des pods système critiques. Même sur les pools de nœuds d’utilisateur, des pods exécutent d’autres services qui participent aux opérations de cluster. Par exemple, les pods peuvent exécuter Flux pour synchroniser la configuration du cluster avec un dépôt GitHub, ou exécuter le contrôleur d’entrée pour router le trafic vers les pods des charges de travail. Quel que soit le type de pool de nœuds, tous les nœuds doivent être protégés.

Un autre composant système critique est le serveur d’API qui est utilisé pour effectuer des tâches Kubernetes natif, comme la conservation de l’état du cluster et de la configuration. L’un des avantages de l’utilisation d’un cluster privé est que le point de terminaison du serveur d’API n’est pas exposé par défaut. Pour plus d’informations sur les clusters privés, consultez Créer un cluster Azure Kubernetes Service privé.

Les interactions avec d’autres points de terminaison doivent également être sécurisées. L’une des méthodes possibles consiste à restreindre les communications effectuées sur un réseau privé. Par exemple, faites en sorte que le cluster tire (pull) les images d’Azure Container Registry via une liaison privée.

Condition requise 1.3.1

Implémenter une zone DMZ pour limiter le trafic entrant aux seuls composants de système fournissant des services, protocoles et ports autorisés, accessibles au public.

Vos responsabilités

Voici quelques bonnes pratiques :

• Ne configurez pas d’adresses IP publiques sur les nœuds du pool de nœuds.
• Utilisez Azure Policy pour vous assurer que Kubernetes n’expose pas d’équilibreur de charge public. Le trafic au sein du cluster doit être routé via des équilibreurs de charge internes.
• Exposez les équilibreurs de charge internes uniquement à Azure Application Gateway avec WAF intégré.
• Tous les contrôles réseau doivent spécifier les restrictions de la source, de la destination, du port et du protocole, lorsque cela s’applique.
• N’exposez pas le serveur d’API à Internet. Lorsque vous exécutez le cluster en mode privé, le point de terminaison n’est pas exposé et la communication entre les pools de nœuds et le serveur d’API se fait via un réseau privé.

Les utilisateurs peuvent implémenter un réseau de périmètre pour protéger les clusters AKS. Pour plus d’informations, consultez Zone DMZ cloud.

Condition requise 1.3.2

Limiter le trafic Internet entrant aux adresses IP dans la zone DMZ.

Vos responsabilités

Sur le réseau du cluster, utilisez un groupe de sécurité réseau appartenant au sous-réseau où se trouve l’équilibreur de charge interne. Configurez des règles pour accepter uniquement le trafic provenant du sous-réseau où se trouve Azure Application Gateway avec WAF intégré. Dans le cluster AKS, utilisez des NetworkPoliciesKubernetes pour limiter le trafic d’entrée vers les pods.

Condition requise 1.3.3

Implémenter des mesures de lutte contre l’usurpation d’identité numérique pour détecter et pour empêcher les adresses IP de source frauduleuse de pénétrer sur le réseau.

Responsabilités d’Azure

Azure implémente le filtrage réseau pour empêcher le trafic falsifié et limiter le trafic entrant et sortant aux composants de plateforme sécurisés.

Condition requise 1.3.4

Ne pas autoriser le trafic sortant non autorisé entre l’environnement CDE et Internet.

Vos responsabilités

Voici comment vous pouvez bloquer le trafic sortant non autorisé :

• Forcez tout le trafic sortant (egress) du cluster AKS à passer par le Pare-feu Azure en utilisant des itinéraires définis par l’utilisateur (UDR) sur tous les sous-réseaux du cluster. Cela comprend les sous-réseaux sur lesquels se trouvent des pools de nœuds système et utilisateur.
• Limitez le trafic sortant en ajoutant des groupes de sécurité réseau sur des sous-réseaux où se trouvent des pools de nœuds.
• Utilisez des NetworkPolicies Kubernetes pour limiter le trafic de sortie des pods.
• Utilisez un maillage de service pour gérer les stratégies supplémentaires. Par exemple, si vous autorisez uniquement le trafic TLS chiffré entre les pods, le proxy de maille de service peut gérer la vérification TLS. Cet exemple est illustré dans cette implémentation. Envoy est déployé en tant que proxy.
• Empêchez l’ajout d’adresses IP publiques aux réseaux dans l’environnement CDE, sauf si les sous-réseaux sont explicitement autorisés, comme les sous-réseaux du Pare-feu.
• Utilisez un proxy HTTP, en plus du Pare-feu Azure, pour limiter le trafic sortant (de sortie) du cluster AKS vers Internet.
• Utilisez Azure Monitor Private Link Service (AMPLS) pour faire en sorte que les journaux d’activité de Container Insights soient envoyés à Azure Monitor via une connexion privée sécurisée. Comprenez l’impact de l’activation d’AMPLS.

Pour plus d’informations, consultez Contrôler le trafic de sortie pour les nœuds de cluster dans Azure Kubernetes Service (AKS).

Condition requise 1.3.5

Les connexions « établies » sont les seules autorisées sur le réseau.

Responsabilités d’Azure

Azure implémente le filtrage réseau pour empêcher le trafic falsifié et limiter le trafic entrant et sortant aux composants de plateforme sécurisés. Le réseau Azure est isolé pour séparer le trafic des clients du trafic de gestion.

Condition requise 1.3.6

Placer les composants de système qui stockent les données de titulaires de carte (comme une base de données) dans une zone de réseau interne, isolée de la zone DMZ et des autres réseaux non approuvés.

Vos responsabilités

Exposez vos systèmes de stockage uniquement sur un réseau privé, par exemple à l’aide de Private Link. Accordez l’accès uniquement aux sous-réseaux de pools de nœuds qui en ont besoin. L’état ne doit pas se trouver dans le cluster, mais dans sa propre zone de sécurité dédiée.

Condition requise 1.3.7

Ne pas divulguer les adresses IP privées et les informations de routage à des parties non autorisées.

Vos responsabilités

Pour répondre à cette exigence, il est impossible d'utiliser un cluster AKS public. Un cluster privé protège les enregistrements DNS de l’Internet public à l’aide d’une zone DNS privée. En revanche, il est toujours possible de Créer un cluster AKS privé avec une adresse DNS publique. Il est donc recommandé de désactiver explicitement cette fonctionnalité en définissant enablePrivateClusterPublicFQDN sur false pour empêcher la divulgation de l'adresse IP privée de votre plan de contrôle. Envisagez d’utiliser Azure Policy pour imposer l’utilisation de clusters privés sans enregistrements DNS publics.

Utilisez également une zone DNS privée pour le routage entre le sous-réseau où se trouve Azure Application Gateway avec WAF intégré et le sous-réseau où se trouve l’équilibreur de charge interne. Vérifiez qu’aucune réponse HTTP ne contient des informations sur les adresses IP privées dans ses en-têtes ou son corps. Vérifiez que les journaux qui peuvent contenir des enregistrements IP et DNS ne sont pas exposés sans nécessité opérationnelle.

Un service Azure connecté via Private Link n’a pas d’enregistrement DNS public exposant vos adresses IP privées. Votre infrastructure devrait utiliser Private Link de manière optimale.

Condition requise 1.4

Installer un logiciel de pare-feu personnel ou une fonctionnalité équivalente sur tout appareil informatique portable qui se connecte à Internet en dehors du réseau et qui permet également un accès à l’environnement CDE.

Vos responsabilités

Le cluster privé est géré par le plan de contrôle AKS. Vous n’avez pas accès aux nœuds directement. Pour effectuer des tâches d’administration, vous devez utiliser des outils de gestion comme kubectl à partir d’une ressource de calcul distincte. L’une des méthodes possibles consiste à utiliser un jumpbox hermétique sur lequel vous pouvez exécuter les commandes. De même, le trafic entrant et sortant du jumpbox doit être restreint et sécurisé. Si le VPN est utilisé pour l’accès, vérifiez que l’ordinateur client est géré par la stratégie d’entreprise et que toutes les stratégies d’accès conditionnel ont été mises en place.

Dans cette architecture, ce jumpbox se trouve dans un sous-réseau distinct du réseau spoke. L’accès entrant au jumpbox est limité à l’aide d’un groupe de sécurité réseau qui autorise uniquement l’accès via Azure Bastion et une connexion SSH.

Pour exécuter certaines commandes sur le jumpbox, vous devez atteindre des points de terminaison publics. Par exemple, les points de terminaison gérés par le plan de gestion Azure. Ce trafic sortant doit être sécurisé. Comme pour les autres composants du réseau spoke, le trafic sortant de la jump box est restreint en utilisant un UDR qui force le trafic HTTPS à passer par le pare-feu Azure.

Condition requise 1.5

Garantir que les stratégies de sécurité et les procédures opérationnelles pour la gestion des pare-feu 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 le processus et les stratégies. Cela est particulièrement vrai lorsque vous gérez des règles du Pare-feu Azure qui segmentent le cluster AKS. Les personnes ayant des environnements réglementés doivent être sensibilisés, informés et encouragés pour prendre en charge les garanties de sécurité. Ceci est particulièrement important pour les personnes dont les comptes disposent de privilèges d’administrateur étendus.

Exigence 2 : Ne pas utiliser les paramètres par défaut fournis par le fournisseur pour les mots de passe système et autres paramètres de sécurité.

Vos responsabilités

Condition requise	Responsabilité
Condition requise 2.1	Changer systématiquement les paramètres par défaut définis par le fournisseur, et supprimer ou désactiver les comptes par défaut inutiles avant d’installer un système sur le réseau.
Condition requise 2.2	Définir des standards de configuration pour tous les composants système. Vérifier que ces normes couvrent toutes les vulnérabilités de la sécurité et sont compatibles avec toutes les normes renforçant les systèmes en vigueur dans le secteur.
Condition requise 2.3	Chiffrer tous les accès administratifs non-console à l’aide d’un chiffrement fort.
Condition requise 2.4	Effectuer régulièrement un inventaire des composants système qui sont concernés par la norme PCI DSS.
Condition requise 2.5	Garantir que les stratégies de sécurité et les procédures opérationnelles pour la gestion des paramètres par défaut du fournisseur et des autres paramètres de sécurité sont documentées, utilisées et connues de toutes les parties concernées.
Condition requise 2.6	Les fournisseurs d’hébergement partagé doivent protéger l’environnement hébergé et les données de titulaires de carte de chaque entité.

Ne pas utiliser les mots de passe système et autres paramètres de sécurité par défaut définis par le fournisseur.

Condition requise 2.1

Changer systématiquement les paramètres par défaut définis par le fournisseur, et supprimer ou désactiver les comptes par défaut inutiles avant d’installer un système sur le réseau.

Vos responsabilités

Les paramètres par défaut fournis par les fournisseurs doivent être modifiés. Les paramètres par défaut sont des vecteurs d’attaque courants et rendent le système vulnérable aux attaques. Voici quelques éléments à prendre en compte :

• Désactivez l’accès administrateur sur le registre de conteneurs.
• Assurez-vous que les jump boxes et les agents de build suivent les procédures de gestion des utilisateurs, en supprimant les utilisateurs système qui ne sont pas nécessaires.
• Ne générez pas et ne fournissez pas d’accès par clé SSH aux nœuds aux utilisateurs administrateurs. Si vous avez besoin d’un accès d’urgence, utilisez le processus de récupération Azure pour bénéficier d’un accès juste-à-temps.

Responsabilités d’Azure

Microsoft Entra ID comprend des stratégies de mot de passe qui sont appliquées aux nouveaux mots de passe fournis par les utilisateurs. Si vous changez un mot de passe, la validation de l’ancien mot de passe est requise. Un mot de passe réinitialisé par un administrateur doit être changé lors de la prochaine connexion de l’utilisateur.

Condition requise 2.1.1

Pour les environnements sans fil connectés à l’environnement des données de titulaires de carte ou qui transmettent des données de titulaires de carte, changer TOUS les paramètres par défaut définis par le fournisseur à l’installation, notamment les clés de chiffrement sans fil, les mots de passe et les chaînes de communauté SNMP.

Vos responsabilités

Cette architecture et cette implémentation ne sont pas conçues pour effectuer des transactions entre un réseau local ou d’entreprise et le cloud via des connexions sans fil. Pour plus d’informations, reportez-vous à l’aide de la norme PCI-DSS 3.2.1.

Condition requise 2.2

Définir des standards de configuration pour tous les composants système.

Vos responsabilités

Implémentez les recommandations du Microsoft cloud security benchmark. Celui-ci fournit une vue centralisée des recommandations de sécurité Azure relatives aux frameworks comme CIS, NIST, PCI-DSS 3.2.1 et autres. Utilisez les fonctionnalités de Microsoft Defender pour le cloud et Azure Policy pour faciliter le suivi des normes. Le point de référence Azure est l’initiative par défaut de Microsoft Defender pour le cloud. Vous pouvez créer des vérifications automatisées supplémentaires dans Azure Policy et dans Azure Tenant Security Solution (AzTS).

Documentez l’état de configuration souhaité de tous les composants de l’environnement CDE, en particulier les nœuds AKS, le jumpbox, les agents de build et les autres composants qui interagissent avec le cluster.

Pour plus d’informations, consultez Benchmark de sécurité cloud Microsoft.

Responsabilité Azure

Azure fournit des standards de configuration de la sécurité qui sont alignés sur les standards de durcissement de la sécurité reconnus par le secteur. Les standards sont évalués au moins une fois par an.

Condition requise 2.2.1

Implémenter une seule fonction principale par serveur pour éviter la coexistence, sur le même serveur, de fonctions exigeant des niveaux de sécurité différents. (Par exemple, les serveurs web, les serveurs de base de données et les serveurs DNS doivent être implémentés sur des serveurs distincts.)

Vos responsabilités

La stratégie clé consiste à fournir le niveau de segmentation nécessaire. L’une des méthodes possibles consiste à déployer dans des clusters distincts les composants situés dans l’étendue et ceux situés en dehors. Sachez que cela augmente les coûts relatifs à l’infrastructure ajoutée et à la maintenance. Une autre approche consiste à colocaliser tous les composants dans un cluster partagé. Utilisez des stratégies de segmentation pour maintenir la séparation. Par exemple, utilisez des pools de nœuds distincts au sein d’un cluster.

Dans l’implémentation de référence, la deuxième approche est illustrée par une application de microservices déployée sur un cluster unique. L’application a deux ensembles de services ; l’un d’eux a des pods dans l’étendue, tandis que l’autre est hors de portée. Les deux ensembles sont répartis sur deux pools de nœuds utilisateur. Avec l’utilisation des teintes Kubernetes, les pods situés dans l’étendue et ceux situés en dehors sont déployés dans des pools de nœuds distincts et ne partagent jamais une machine virtuelle de nœud.

Pour les technologies de conteneur, cette segmentation est fournie par défaut parce qu’une seule instance d’un conteneur est responsable d’une fonction dans le système.

Chaque pod de charge de travail doit utiliser sa propre identité. Elle ne doit pas hériter d’une identité au niveau du cluster ou du nœud.

Dans la mesure du possible, vous devez utiliser le stockage externe plutôt que le stockage sur nœud (en cluster). Réservez les pods de cluster exclusivement au travail qui doit être effectué dans le cadre du traitement des données du titulaire de carte. Déplacez les opérations hors étendue vers l’extérieur du cluster. Ce guide s’applique aux agents de build, aux charges de travail non associées et aux activités comme l’utilisation d’un jumpbox à l’intérieur du cluster.

Condition requise 2.2.2

Activer uniquement les services, protocoles, démons, etc. nécessaires au fonctionnement du système.

Vos responsabilités

Passez en revue les fonctionnalités et ce qu’elles impliquent avant de les activer. Les paramètres par défaut peuvent inclure des fonctionnalités dont vous n’avez pas besoin, et qui peuvent avoir besoin d’une visibilité sur la charge de travail. Les chiffrements de la stratégie SSL par défaut pour Azure Application Gateway en sont un exemple. Regardez si la stratégie n’est pas trop permissive. Il est recommandé de créer une stratégie personnalisée en sélectionnant uniquement les chiffrements dont vous avez besoin.

Pour les composants que vous contrôlez entièrement, supprimez tous les services système inutiles des images. Par exemple, examinez les images des jump boxes et des agents de build et supprimez tous les composants qui ne sont pas nécessaires.

Dans les composants pour lesquels vous ne disposez que d’une visibilité, comme les nœuds AKS, documentez ce qu’Azure installe sur les nœuds. Vous pouvez utiliser DaemonSets afin de fournir d’autres audits nécessaires pour ces composants contrôlés par le cloud.

Condition requise 2.2.3

Implémenter les fonctionnalités de sécurité supplémentaires pour tout service, protocole ou démon nécessaire et jugé comme non sécurisé.

Vos responsabilités

Application Gateway avec WAF intégré négocie l’établissement d’une liaison TLS pour la demande envoyée à son point de terminaison public, ce qui autorise uniquement les chiffrements sécurisés. L’implémentation de référence ne prend en charge que TLS 1.2 et les chiffrements approuvés.

Supposons que vous disposiez d’un appareil hérité qui doit interagir avec l’environnement CDE via Azure Application Gateway. Pour répondre à cette exigence, Application Gateway doit activer un protocole non sécurisé. Documentez cette exception et surveillez si ce protocole est utilisé ailleurs que sur l’appareil hérité. Désactivez ce protocole dès que l’interaction héritée est interrompue.

Application Gateway ne doit pas répondre aux requêtes sur le port 80. N’effectuez pas de redirections au niveau de l’application. Cette implémentation de référence comprend une règle de groupe de sécurité réseau qui bloque le trafic sur le port 80. La règle est appliquée sur le sous-réseau où se trouve Application Gateway.

Si une charge de travail de votre cluster ne peut pas adhérer à la directive organisationnelle relative aux profils de conformité de sécurité ou à d’autres contrôles (par exemple, les limites et les quotas), vous devez documenter cette exception. Vous devez vérifier que seules les fonctionnalités attendues sont exécutées.

Condition requise 2.2.4

Configurer les paramètres de sécurité du système pour empêcher toute utilisation malveillante.

Vos responsabilités

Tous les services Azure utilisés dans l’architecture doivent suivre les recommandations fournies par le Microsoft cloud security benchmark. Ces recommandations vous donnent un point de départ pour sélectionner des paramètres de configuration de sécurité. En outre, vous devez comparer votre configuration à l’implémentation de référence pour ce service. Pour plus d’informations sur les bases de référence de sécurité, consultez Bases de référence de la sécurité pour Azure.

Le contrôleur d’admission Open Policy Agent fonctionne conjointement avec Azure Policy pour détecter et bloquer les configurations inappropriées sur le cluster. Supposons qu’il existe une directive organisationnelle qui n’autorise pas les allocations d’adresses IP publiques sur les nœuds. Lorsqu’une allocation de ce type est détectée, elle est marquée pour audit ou refusée en fonction de l’action spécifiée dans la définition de stratégie.

Au niveau de l’infrastructure, vous pouvez appliquer des restrictions concernant le type et la configuration des ressources Azure. Utilisez Azure Policy pour empêcher les mauvaises configurations. Dans cette implémentation de référence, il existe une stratégie qui vous empêche de créer des clusters AKS qui ne sont pas privés.

Assurez-vous que toutes les exceptions sont documentées et revues régulièrement.

Responsabilités d’Azure

En instaurant des contrôles d’accès multifacteurs et en exigeant la preuve documentée d’un besoin métier, Azure garantit que seules les personnes autorisées peuvent configurer les contrôles de sécurité de la plateforme Azure.

Condition requise 2.2.5

Supprimer toutes les fonctions inutiles, comme les scripts, les pilotes, les fonctionnalités, les sous-systèmes et les systèmes de fichiers, ainsi que les serveurs web superflus.

Vos responsabilités

N’installez pas de logiciels sur des jumpboxs ou des agents de build qui ne participent pas au traitement d’une transaction ou qui fournissent une observabilité pour les exigences de conformité, comme les agents de sécurité. Cette recommandation s’applique également aux entités de cluster, comme DaemonSet ou les pods. Vérifiez que toutes les installations sont détectées et journalisées.

Condition requise 2.3

Chiffrer tous les accès administratifs non-console à l’aide d’un chiffrement fort.

Vos responsabilités

Tout accès administratif au cluster doit être effectué à l’aide de la console. N’exposez pas le plan de contrôle du cluster.

Responsabilités d’Azure

Azure garantit l’application d’un chiffrement fort en cas d’accès à l’infrastructure de l’hyperviseur. Cela garantit que les clients utilisant le portail Azure peuvent accéder à leur service et à leurs consoles d’hébergement en utilisant une cryptographie forte.

Condition requise 2.4

Effectuer régulièrement un inventaire des composants système qui sont concernés par la norme PCI DSS.

Vos responsabilités

Toutes les ressources Azure utilisées dans l’architecture doivent être étiquetées correctement. Les étiquettes aident à la classification des données et indiquent si le service se trouve ou non dans l’étendue. Un étiquetage méticuleux vous permet d’interroger les ressources, de gérer un inventaire, d’assurer le suivi des coûts et de configurer des alertes. Veillez également à effectuer régulièrement une capture instantanée de cette documentation.

Évitez d’étiqueter les ressources situées dans l’étendue ou en dehors de celle-ci à un niveau granulaire. À mesure que la solution évolue, les ressources situées hors étendue peuvent être placées dans l’étendue, même si elles interagissent indirectement ou sont adjacentes aux données du titulaire de carte. Ces ressources sont soumises à un audit et peuvent faire partie d’un échantillon représentatif pendant l’audit. Il est conseillé d’étiqueter à un niveau plus général, par exemple au niveau de l’abonnement et du cluster.

Pour plus d’informations sur l’étiquetage des ressources, consultez Guide de décision concernant le nommage et l’étiquetage des ressources.

Étiquetez les objets en cluster en appliquant des étiquettes Kubernetes. De cette façon, vous pourrez organiser les objets, sélectionner une collection d’objets et envoyer l’inventaire.

Condition requise 2.5

Garantir que les stratégies de sécurité et les procédures opérationnelles pour la gestion des paramètres par défaut du fournisseur et des autres paramètres 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. Les équipes doivent être formées aux fonctionnalités de sécurité et aux paramètres de configuration de chaque ressource Azure. Les personnes ayant des environnements réglementés doivent être sensibilisés, informés et encouragés pour prendre en charge les garanties de sécurité. Ces étapes sont particulièrement importantes pour toute personne à qui des privilèges administratifs étendus sont accordés.

Condition requise 2.6

Les fournisseurs d’hébergement partagé doivent protéger l’environnement hébergé et les données de titulaires de carte de chaque entité.

Vos responsabilités

Azure fournit des assurances de sécurité partagées pour tout composant d’environnement hébergé qui est partagé. Il est vivement recommandé de traiter vos nœuds AKS comme un hôte dédié pour cette charge de travail. Autrement dit, tous les calculs doivent être dans un modèle de locataire unique et non partagés avec d’autres charges de travail que vous pouvez utiliser.

Si l’isolation complète du calcul est souhaitée au niveau de l’infrastructure Azure, vous pouvez Ajouter Azure Dedicated Host à un cluster Azure Kubernetes Service (AKS). Cette offre fournit des serveurs physiques dédiés à votre charge de travail, ce qui vous permet de placer des nœuds AKS directement dans ces hôtes provisionnés. Ce choix architectural a des implications financières importantes et nécessite une planification minutieuse de la capacité. Ce n’est pas typique pour la plupart des scénarios.

Étapes suivantes

Protégez les données de titulaires de carte stockées. Chiffrez la transmission des données de titulaires de carte sur les réseaux publics ouverts.

Ressources associées

• Conception d’une architecture Azure Kubernetes Service (AKS)
• Détecter les vulnérabilités d’un cluster régulé par AKS pour PCI DSS 3.2.1 (partie 1 sur 9)
• Architecture d’un cluster régulé par AKS pour PCI DSS 3.2.1 (partie 2 sur 9)
• Architecture de référence pour un cluster Azure Kubernetes Service (AKS)
• Base de référence AKS pour les clusters multirégions