Gestion des accès d’un cluster de ligne de base AKS pour un PCI DSS 3.2.1 (partie 6 sur 9)

Cet article décrit les considérations 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.

Kubernetes dispose d’un contrôle d’accès en fonction du rôle (RBAC) natif qui gère les autorisations sur l’API Kubernetes. Il existe plusieurs rôles intégrés avec des autorisations ou des actions spécifiques sur les ressources Kubernetes. Azure Kubernetes Service (AKS) prend en charge ces rôles intégrés et les rôles personnalisés pour un contrôle différencié. Ces actions peuvent être accordées (ou refusées) à un utilisateur au moyen de Kubernetes RBAC.

Cette architecture et l’implémentation ne sont pas conçues pour fournir des contrôles sur l’accès physique aux ressources ou aux centres de donnes locaux. L’un des avantages de l’hébergement de votre CDE dans Azure, par rapport à votre plateforme en périphérie ou à l’hébergement dans votre centre de données, est que la sécurité du centre de données Azure gère déjà en grande partie la restriction de l’accès physique. L’organisation n’a aucune responsabilité dans la gestion du matériel physique.

Implémenter des mesures de contrôle d’accès strictes

Condition requise 7 - Restreindre l’accès aux données en fonction du besoin métier

Prise en charge des fonctionnalités AKS

AKS est entièrement intégré à Microsoft Entra ID en tant que fournisseur d’identité.

Vous n’avez pas à gérer des identités d’utilisateur et des informations d’identification distinctes pour Kubernetes. Vous pouvez ajouter des utilisateurs Microsoft Entra pour Kubernetes RBAC. Cette intégration permet d’effectuer des attributions de rôles à des utilisateurs Microsoft Entra. Microsoft Entra RBAC prend en charge les définitions de rôle, telles qu’utilisateur, rédacteur, administrateur de service, administrateur de cluster en tant que rôles intégrés. Vous pouvez également créer des rôles personnalisés pour un contrôle plus précis.

Par défaut, RBAC Azure est défini sur Refuser tout afin qu’une ressource ne soit pas accessible sans autorisations accordées. AKS limite l’accès SSH aux nœuds Worker AKS et utilise la stratégie réseau AKS pour contrôler l’accès aux charges de travail dans les pods.

Pour plus d’informations, consultez Utiliser Azure RBAC pour l’autorisation Kubernetes et Sécuriser votre cluster avec Azure Policy.

Vos responsabilités

Condition requise	Responsabilité
Condition requise 7.1	Restreindre l’accès aux composants du système et aux données du titulaire aux seuls individus qui doivent y accéder pour mener à bien leur travail.
Condition requise 7.2	Établir un système de contrôle d’accès pour les composants système qui limite l’accès aux seuls utilisateurs qui doivent accéder aux données et qui est configuré pour « refuser tout » sauf ce qui est spécifiquement autorisé.
Condition requise 7.3	Assurer que les stratégies de sécurité et les procédures opérationnelles pour la restriction de l’accès aux données du titulaire sont documentées, utilisées et connues de toutes les parties concernées.

Condition requise 7.1

Restreindre l’accès aux composants du système et aux données du titulaire aux seuls individus qui doivent y accéder pour mener à bien leur travail.

Vos responsabilités

Voici quelques éléments à prendre en compte :

• Assurez-vous que votre implémentation est conforme aux exigences de l’organisation et aux exigences de conformité en matière de gestion des identités.
• Réduisez au minimum les autorisations permanentes, en particulier pour les comptes à impact stratégique.
• Suivez le principe de l’accès à privilèges minimum. Fournissez un accès juste suffisant pour terminer la tâche.

Condition requise 7.1.1

Définir les besoins d’accès pour chaque rôle, y compris :

• Les composants de système et les ressources de données dont chaque rôle a besoin pour accéder aux fonctions de son poste
• Le niveau de privilège nécessaire (par exemple, utilisateur, administrateur, etc.) pour accéder aux ressources.

Vos responsabilités

Définissez les rôles en fonction des tâches et des responsabilités requises pour les composants dans l’étendue et leur interaction avec les ressources Azure. Vous pouvez commencer par des catégories étendues, telles que :

• Étendue par groupes d’administration, abonnements ou groupes de ressources Azure
• Azure Policy pour la charge de travail ou l’abonnement
• Opérations sur les conteneurs
• Gestion des secrets
• Pipelines de build et de déploiement

Bien que la définition des rôles et des responsabilités dans ces domaines puisse être associée à la structure de votre équipe, concentrez-vous sur les exigences de la charge de travail. Par exemple, qui est responsable de la gestion de la sécurité, de l’isolation, du déploiement et de l’observation. Voici quelques exemples :

• Décisions concernant la sécurité des applications, le contrôle d’accès en fonction du rôle Kubernetes, les stratégies réseau, les stratégies Azure et la communication avec d’autres services.
• Configuration et maintenance de Pare-feu Azure, du pare-feu d’applications web (WAF), des groupes de sécurité réseau (NSG) et de la configuration DNS.
• Surveillez et corrigez la sécurité du serveur, la mise à jour corrective, la configuration et la sécurité des points de terminaison.
• Définition de l’orientation de l’utilisation du contrôle d’accès en fonction du rôle Azure (RBAC), de Microsoft Defender pour le cloud, de la stratégie de protection de l’administrateur et d’Azure Policy pour gouverner des ressources Azure.
• Équipe de surveillance et de traitement des incidents Examinez et corrigez les incidents de sécurité dans Security Information and Event Management (SIEM) ou Microsoft Defender pour le cloud.

Ensuite, formalisez la définition en déterminant le niveau d’accès requis pour le rôle par rapport à la charge de travail et à l’infrastructure. Voici une définition simple à des fins d’illustration.

Role	Responsabilités	Niveaux d'accès
Propriétaires d'applications	Définissez et classez par ordre de priorité les fonctionnalités alignées sur les résultats de l’entreprise. Ils comprennent dans quelle mesure les fonctionnalités ont un impact sur la conformité de la charge de travail, et équilibrent la protection et la propriété des données des clients avec les objectifs commerciaux.	Accès en lecture aux journaux et aux métriques émis par l’application. Ils n’ont pas besoin d’autorisations pour accéder à la charge de travail ou au cluster.
Développeurs d’applications	Développez l’application. Tous les codes d’application font l’objet d’une formation et de contrôles de qualité, conformément aux processus de conformité, d’attestation et de gestion des versions. Peut gérer les pipelines de build, mais généralement pas les pipelines de déploiement.	Accès en lecture aux espaces de noms Kubernetes et aux ressources Azure qui résident dans l’étendue de la charge de travail. Aucun accès en écriture pour le déploiement ou la modification de n’importe quel état du système.
Opérateurs d’application (ou SRE)	Possédez une connaissance approfondie de la base de code, de l’observabilité et des opérations. Effectuez le triage et le dépannage des sites en temps réel. Avec les développeurs d’applications, améliorez la disponibilité, l’extensibilité et les performances de l’application. Gérez le pipeline de déploiement « dernier kilomètre » et aidez à gérer les pipelines de build.	Privilèges élevés au sein de l’étendue de l’application qui comprend les espaces de noms Kubernetes et les ressources Azure associés. Il est probable que vous disposiez d’un accès permanent aux différentes parties du cluster Kubernetes.
Propriétaires d’infrastructure	Concevez une architecture rentable, y compris sa connectivité et la fonctionnalité des composants. L’étendue peut inclure des services cloud et locaux. Décidez des fonctionnalités de conservation des données, de continuité des activités et autres.	Accédez aux journaux de la plateforme et aux données du centre de coûts. Aucun accès n’est requis au sein du cluster.
Opérateurs d’infrastructure (ou SRE)	Opérations liées au cluster et aux services dépendants. Générez, déployez et amorcez le pipeline pour le cluster dans lequel la charge de travail est déployée. Définissez les cibles des pools de nœuds et les exigences de dimensionnement et d’échelle attendues. Surveillez l’intégrité de l’infrastructure d’hébergement de conteneur et des services dépendants.	Accès en lecture aux espaces de noms de la charge de travail. Accès à privilèges élevés pour le cluster.
Stratégie, propriétaires de sécurité	Bénéficiez d’une expertise en matière de sécurité ou de réglementation. Définissez des stratégies qui protègent la sécurité et la conformité réglementaire des employés de l’entreprise, de ses actifs et de ceux des clients de l’entreprise. Fonctionne avec tous les autres rôles pour garantir que la stratégie est appliquée et être auditée à chaque phase.	Accès en lecture à la charge de travail et au cluster. Permet également d’accéder aux données de journal et d’audit.
Opérateurs réseau	Allocation de réseau et de sous-réseau virtuels dans l’ensemble de l’entreprise. Configuration et maintenance du Pare-feu Azure, du pare-feu d’applications web, des groupes de sécurité réseau et de la configuration DNS.	Possédant des privilèges élevés dans la couche réseau. Aucune autorisation d’écriture au sein du cluster.

Condition requise 7.1.2

Restreindre l’accès des ID utilisateurs privilégiés aux privilèges les plus faibles nécessaires pour la réalisation du travail.

Vos responsabilités

En vous fondant sur les fonctions du poste, efforcez-vous de minimiser l’accès sans causer de perturbations. Voici quelques bonnes pratiques :

• L’identité doit disposer un accès juste suffisant pour effectuer une tâche.
• Réduisez au minimum les autorisations permanentes, en particulier sur les identités à impact critique qui ont accès aux composants dans l’étendue.
• Ajoutez des restrictions supplémentaires dans la mesure du possible. L’une des méthodes consiste à fournir un accès conditionnel basé sur des critères d’accès.
• Procédez à une révision et un audit réguliers des utilisateurs et des groupes qui ont accès à vos abonnements, même pour l’accès en lecture. Évitez d’inviter des identités externes.

Condition requise 7.1.3

Affecter les accès en fonction de la classification et de la fonction du poste chaque employé.

Vos responsabilités

Déterminez les autorisations en fonction des tâches clairement attribuées à l’individu. Évitez les paramètres tels que le système ou l’absence de l’employé. Accordez des droits d’accès à un seul utilisateur ou à un groupe.

Voici quelques exemples.

Classification du travail	Role
Un propriétaire de produit définit l’étendue de la charge de travail et hiérarchise les fonctionnalités. Trouver un équilibre entre la protection et la propriété des données des clients et les objectifs stratégiques. Nécessite l’accès aux rapports, au centre de coûts ou aux tableaux de bord Azure. Aucun accès n’est nécessaire pour les autorisations internes au cluster ou de niveau cluster.	Propriétaires d'applications
Un ingénieur logiciel conçoit, développe et conteneurise le code de l’application. Un groupe disposant d’autorisations de lecture permanentes dans des étendues définies au sein d’Azure (telles que Application Insights) et dans les espaces de noms de la charge de travail. Ces étendues et autorisations peuvent être différentes entre les environnements de pré-production et de production.	Développeur d’application
Un ingénieur de fiabilité de site effectue le triage des sites en temps réel, gère les pipelines et configure l’infrastructure des applications. Groupe A avec contrôle total dans leur(s) espace(s) de noms alloué(s). Des autorisations permanentes ne sont pas requises. Groupe B pour les opérations quotidiennes sur la charge de travail. Ils peuvent avoir des autorisations permanentes dans le(s) espace(s) de noms qui leur sont attribués mais sans disposer de privilèges élevés.	Opérateurs d’application
Un opérateur de cluster conçoit et déploie un cluster AKS fiable et sécurisé sur la plateforme. Responsable de la gestion de la durée de bon fonctionnement du cluster. Groupe A avec contrôle total dans leur(s) espace(s) de noms alloué(s). Des autorisations permanentes ne sont pas requises. Groupe B pour les opérations quotidiennes sur la charge de travail. Ils peuvent avoir des autorisations permanentes dans le(s) espace(s) de noms qui leur sont attribués mais sans disposer de privilèges élevés.	Opérateurs d’infrastructure
Un ingénieur réseau alloue le réseau virtuel et les sous-réseaux de l’entreprise, la sécurité réseau et la connectivité entre le site local et le cloud.	Opérateurs d’infrastructure

Condition requise 7.1.4

Demander l’approbation documentée des parties responsables spécifiant les privilèges nécessaires.

Vos responsabilités

Mettez en place un processus d’approbation des modifications des rôles et des autorisations, y compris l’attribution initiale des privilèges. Assurez-vous que ces approbations sont documentées et disponibles à des fins d’inspection.

Condition requise 7.2

Établir un système de contrôle d’accès pour les composants système qui limite l’accès aux seuls utilisateurs qui doivent accéder aux données et qui est configuré pour « refuser tout » sauf ce qui est spécifiquement autorisé.

Vos responsabilités

Conformément à la condition requise 7.1, vous devez avoir évalué les rôles et les responsabilités applicables à votre organisation et à la charge de travail. Tous les composants de l’architecture appartenant à l’étendue doivent disposer d’un accès restreint. Cela comprend les nœuds AKS qui exécutent la charge de travail, le stockage des données, l’accès réseau et tous les autres services qui participent au traitement des données de détenteurs de cartes (CHD).

En fonction des rôles et des responsabilités, attribuez des rôles au contrôle d’accès en fonction du rôle (RBAC) de l’infrastructure. Ce mécanisme peut être :

• Kubernetes RBAC est un modèle d’autorisation Kubernetes natif qui contrôle l’accès au plan de contrôle Kubernetes, exposé via le serveur d’API Kubernetes. Cet ensemble d’autorisations définit ce que vous pouvez faire avec le serveur d’API. Par exemple, vous pouvez refuser à un utilisateur l’autorisation de créer ou même de répertorier les pods.
• Azure RBAC est un modèle d’autorisation basé sur Microsoft Entra ID qui contrôle l’accès au plan de contrôle Azure. Il s’agit d’une association de votre locataire Microsoft Entra avec votre abonnement Azure. Avec Azure RBAC, vous pouvez accorder des autorisations pour créer des ressources Azure, telles que des réseaux, un cluster AKS et des identités managées.

Supposons que vous deviez accorder des autorisations aux opérateurs de cluster (mappés au rôle opérateur d’infrastructure). Toutes les personnes auxquelles sont affectées les responsabilités de l’opérateur d’infrastructure appartiennent à un groupe Microsoft Entra. Comme établi par la condition requise 7.1.1, ce rôle nécessite les privilèges les plus élevés dans le cluster. Kubernetes possède des rôles RBAC intégrés, tels que cluster-admin, qui répondent à ces exigences. Vous devez lier le groupe Microsoft Entra pour l’opérateur d’infrastructure à cluster-admin en créant des liaisons de rôle. Il y a deux approches possibles, qui fournissent un accès identique au flux de messages. Vous pouvez opter pour les rôles intégrés. Cependant, si les rôles intégrés ne répondent pas à vos exigences (par exemple, ils peuvent être trop permissifs), créez des rôles personnalisés pour vos liaisons.

L’implémentation de référence illustre l’exemple précédent en utilisant le mode natif RBAC de Kubernetes. La même association peut être réalisée avec Azure RBAC. Pour plus d’informations, consultez Contrôler l’accès aux ressources de cluster à l’aide du contrôle d’accès en fonction du rôle Kubernetes et des identités Microsoft Entra dans Azure Kubernetes Service.

Vous pouvez choisir l’étendue de l’autorisation au niveau du cluster ou au niveau de l’espace de noms. Pour les rôles ayant des responsabilités délimitées, comme les opérateurs d’application, les autorisations sont affectées au niveau de l’espace de noms pour la charge de travail.

En outre, les rôles ont également besoin d’autorisations Azure RBAC pour pouvoir effectuer leurs tâches. Par exemple, l’opérateur de cluster doit accéder à Azure Monitor par le biais du portail. Par conséquent, le rôle opérateur d’infrastructure doit disposer de l’attribution RBAC appropriée.

Hormis les personnes et leurs rôles, les ressources Azure et même les pods internes au cluster possèdent des identités managées. Ces identités ont besoin d’un ensemble d’autorisations via Azure RBAC et doivent être étroitement définies en fonction des tâches attendues. Par exemple, Azure Application Gateway doit avoir les autorisations nécessaires pour obtenir les secrets (certificats TLS) à partir de Azure Key Vault. Il ne doit pas avoir les autorisations nécessaires pour modifier les secrets.

Voici quelques bonnes pratiques :

• Maintenez une documentation détaillée sur chaque rôle et les autorisations qui lui sont attribuées. Distinguez clairement les autorisations qui sont nécessaires ponctuellement et celles qui sont permanentes.

• Surveillez l’évolution des rôles, par exemple les changements d’affectation ou les définitions de rôles. Créez des alertes sur les changements, même s’ils sont attendus, afin d’avoir une meilleure visibilité sur les intentions à l’origine des changements.

Condition requise 7.2.1

Couverture de tous les composants du système

Vos responsabilités

Voici quelques meilleures pratiques pour gérer les mesures de contrôle d’accès :

• Évitez d’utiliser un accès permanent. Envisagez plutôt l’appartenance à un groupe AD juste-à-temps. Cette fonctionnalité nécessite Microsoft Entra Privileged Identity Management.

• Configurez des stratégies d’accès conditionnel dans Microsoft Entra ID pour votre cluster. Cela impose des restrictions d’accès au plan de contrôle Kubernetes. Grâce aux stratégies d’accès conditionnel, vous pouvez exiger une authentification multifacteur, limiter l’authentification aux appareils managés par votre locataire Microsoft Entra ou bloquer les tentatives de connexion atypiques. Appliquez ces stratégies à des groupes Microsoft Entra mappés à des rôles Kubernetes ayant des privilèges élevés.

  Remarque

  Les choix technologiques JIT et d’accès conditionnel nécessitent Microsoft Entra ID P1 ou P2.

• Idéalement, désactivez l’accès SSH aux nœuds du cluster. Cette implémentation de référence ne génère pas de détails de connexion SSH à cette fin.

• Tout calcul supplémentaire, tel que les zones de rebond, doit être accessible aux utilisateurs autorisés. Ne créez pas de connexions génériques disponibles pour toute l’équipe.

Condition requise 7.2.2

L’octroi de privilèges aux individus repose sur leur classification et leurs fonctions professionnelles

Vos responsabilités

En nous basant sur la condition requise 7.1.3, nous constatons que de nombreux rôles seront impliqués dans les opérations de cluster. Outre les rôles de ressources Azure standard, vous devez définir l’étendue et le processus d’accès.

Par exemple, considérez le rôle opérateur de cluster. Ils doivent disposer d’un guide opérationnel clairement défini pour les activités de triage de clusters. Dans quelle mesure cet accès est-il différent de celui de l’équipe responsable de la charge de travail ? En fonction de votre organisation, ils peuvent être identiques. Voici quelques points à prendre en considération :

• Comment les utilisateurs doivent-ils accéder au cluster ?
• Quelles sont les sources dont l’accès est autorisé ?
• Quelles autorisations doivent-elles avoir sur le cluster ?
• Quand ces autorisations sont-elles attribuées ?

Assurez-vous que les définitions sont consignées dans la documentation de gouvernance, la stratégie et les supports de formation concernant l’opérateur de charge de travail et l’opérateur de cluster.

Condition requise 7.2.3

Configuration par défaut du paramètre « Refuser tout ».

Vos responsabilités

Lorsque vous démarrez la configuration, optez pour les stratégies de Confiance Zéro. Définissez des exceptions si nécessaire et documentez-les en détail.

• Kubernetes RBAC implémente Refuser tout par défaut. Évitez de passer outre en ajoutant des liaisons de rôle de cluster extrêmement permissives qui inversent l’action du paramètre Refuser tout.

• Azure RBAC implémente également Refuser tout par défaut. Ne passez pas outre en ajoutant des affectations RBAC qui inversent l’action du paramètre Refuser tout.

• Par défaut, tous les services Azure, Azure Key Vault et Azure Container Registry possèdent des jeux d’autorisation Refuser tout.

• Tout point d’accès administratif, tel qu’une zone de rebond, doit refuser tout accès dans la configuration initiale. Toutes les autorisations élevées doivent être définies explicitement s’il est nécessaire de contourner la règle Refuser tout.

Condition requise 7.3

Assurer que les stratégies de sécurité et les procédures opérationnelles pour la restriction de l’accès aux données du titulaire 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. Cela comprend les stratégies Azure et Kubernetes RBAC ainsi que les stratégies de gouvernance d’organisation. 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 qui font partie du processus d’approbation du point de vue de la stratégie.

Condition requise 8 - Identifier et authentifier l’accès aux composants du système

Prise en charge des fonctionnalités AKS

Grâce à l’intégration d’AKS et de Microsoft Entra, vous pouvez tirer parti des fonctionnalités de gestion des identifiants et des autorisations, notamment la gestion des accès, la gestion des objets identifiants, etc. Pour plus d’informations, consultez Intégration Microsoft Entra gérée par AKS.

Vos responsabilités

Condition requise	Responsabilité
Condition requise 8.1	Définir et implémenter des stratégies et procédures pour assurer une gestion efficace de l’identification des utilisateurs pour les utilisateurs non consommateurs et les administrateurs sur tous les composants du système comme suit :
Condition requise 8.2	Outre l’affectation d’un identifiant unique, assurer la bonne gestion de l’authentification des utilisateurs pour les utilisateurs non consommateurs et les administrateurs sur tous les composants du système en utilisant au moins l’une des méthodes suivantes pour authentifier tous les utilisateurs :
Condition requise 8.3	Sécuriser tous les accès administratifs non-console et tous les accès à distance sur le CDE à l’aide de l’authentification multifacteur.
Condition requise 8.4	Documenter et communiquer les stratégies et les procédures d’authentification ainsi que les stratégies et procédures à tous les utilisateurs, notamment :
Condition requise 8.5	Ne pas utiliser d’identifiants ou de mots de passe groupés, partagés ou génériques, ou d’autres méthodes d’authentification comme suit :
Condition requise 8.6	Lorsque d’autres mécanismes d’authentification sont utilisés (par exemple, des jetons de sécurité physique ou logique, des cartes à puce, des certificats, etc.), l’utilisation de ces mécanismes doit être assignée comme suit :
Condition requise 8.7	Tous les accès aux bases de données contenant des données de titulaires de cartes (y compris l’accès aux applications, administrateurs et tous les autres utilisateurs) sont limités comme suit :
Condition requise 8.8	Assurer que les stratégies de sécurité et les procédures opérationnelles pour l’identification et l’authentification sont documentées, utilisées et connues de toutes les parties concernées.

Condition requise 8.1

Définir et implémenter des stratégies et procédures pour assurer une gestion efficace de l’identification des utilisateurs pour les utilisateurs non consommateurs et les administrateurs sur tous les composants du système comme suit :

• 8.1.1 Affecter à tous les utilisateurs un ID unique avant de les autoriser à accéder aux composants du système ou aux données des titulaires de cartes.
• 8.1.2 Contrôler l’ajout, la suppression et la modification des ID utilisateur, des informations d’identification et des autres objets d’identification.
• 8.1.3 Révoquer immédiatement l’accès des utilisateurs résiliés.
• 8.1.4 Supprimer/désactiver des comptes utilisateur inactifs dans les 90 jours.
• 8.1.5 Gérer les identifiants utilisés par des tiers pour accéder à, prendre en charge ou assurer la maintenance des composants du système via l’accès à distance comme suit :
  • Activé uniquement pendant le temps nécessaire et désactivé en cas de non-utilisation.
  • Surveillé lorsqu’il est utilisé.
• 8.1.6 Limiter les tentatives d’accès répétées en verrouillant l’identifiant utilisateur après six tentatives maximum.
• 8.1.7 Définir la durée du verrouillage sur un minimum de 30 minutes ou jusqu'à ce qu’un administrateur active l’identifiant utilisateur.
• 8.1.8 Si une session a été inactive pendant plus de 15 minutes, demander que l’utilisateur s’authentifie à nouveau pour réactiver le terminal ou la session.

Vos responsabilités

Voici les considérations générales pour cette exigence :

S’APPLIQUE À : 8.1.1, 8.1.2, 8.1.3

Ne partagez pas ou ne réutilisez pas les identités pour des parties fonctionnellement différentes du CDE. Par exemple, n’utilisez pas de compte d’équipe pour accéder aux données ou aux ressources de cluster. Assurez-vous que la documentation d’identité n’utilise pas de comptes partagés.

Étendez ce principal d’identité aux attributions d’identité managées dans Azure. Ne partagez pas les identités managées par les utilisateurs entre les ressources Azure. Affectez à chaque ressource Azure sa propre identité managée. De même, lorsque vous utilisez une Microsoft Entra Workload ID dans le cluster AKS, veillez à ce que chaque composant de votre charge de travail reçoive sa propre identité au lieu d’utiliser une identité d’étendue générale. N’utilisez jamais la même identité managée en pré-production et en production.

Options d’accès et d’identité pour Azure Kubernetes Service (AKS)

S’APPLIQUE À : 8.1.2, 8.1.3, 8.1.4

Utilisez Microsoft Entra ID comme fournisseur d’identité. Comme le cluster et toutes les ressources Azure utilisent Microsoft Entra ID, la désactivation ou la révocation de l’accès Microsoft Entra ID est appliquée à toutes les ressources automatiquement. S’il existe des composants qui ne sont pas soutenus directement par Microsoft Entra ID, assurez-vous que vous disposez d’un processus pour en supprimer l’accès. Par exemple, les informations d’identification SSH pour accéder à une zone de rebond peuvent nécessiter une suppression explicite si l’utilisateur n’est plus valide.

S’APPLIQUE À : 8.1.5

Tirez parti de Microsoft Entra B2B (Business-to-Business) conçu pour héberger des comptes tiers, tels que des fournisseurs, des partenaires, en tant qu’utilisateurs invités. Accordez le niveau d’accès approprié en utilisant des stratégies conditionnelles pour protéger les données d’entreprise. Ces comptes doivent avoir des autorisations permanentes minimales et des dates d’expiration obligatoires. Pour plus d’informations, consultez Qu'est-ce que l'accès des utilisateurs invités dans Microsoft Entra B2B ?.

Votre organisation doit disposer d’un modèle clair et documenté d’accès des fournisseurs et autres personnes similaires.

S’APPLIQUE À : 8.1.6, 8.1.7, 8.1.8

Vos responsabilités

Microsoft Entra ID fournit une fonctionnalité de verrouillage intelligent pour verrouiller les utilisateurs après l’échec de tentatives de connexion. La méthode recommandée pour implémenter les verrouillages est celle des stratégies d’accès conditionnel de Microsoft Entra.

Implémentez le verrouillage pour les composants qui prennent en charge des fonctionnalités similaires mais qui ne sont pas adossés à Microsoft Entra ID (par exemple, les machines compatibles avec SSH, telles que les serveurs de rebond). Cela garantit que les verrouillages sont activés pour empêcher ou ralentir les tentatives d’accès abusives.

Les nœuds AKS ne sont pas conçus pour être accessibles régulièrement. Bloquez les connexions SSH directes ou Bureau à distance au nœuds de cluster. L’accès SSH ne doit être pris en compte que dans le cadre des opérations avancées de résolution des problèmes. L’accès doit être étroitement surveillé et rapidement rétabli une fois l’événement spécifique terminé. Si vous procédez ainsi, n’oubliez pas que les modifications au niveau du nœud peuvent annuler la prise en charge de votre cluster.

Condition requise 8.2

Outre l’attribution d’un identifiant unique, assurer la gestion correcte de l’authentification des utilisateurs non consommateurs et des administrateurs sur tous les composants du système en employant au moins une des méthodes suivantes pour authentifier tous les utilisateurs :  quelque chose que vous connaissez, tel qu’un mot de passe ou une phrase secrète, quelque chose que vous possédez, tel qu’un dispositif à jeton d’authentification ou une carte à puce, quelque chose qui vous caractérise, tel qu’un élément biométrique.

• 8.2.1 À l’aide d’un chiffrement fort, rendre toutes les informations d’identification (par exemple, les mots de passe ou phrases secrètes) illisibles pendant la transmission et le stockage sur l’ensemble des composants du système.
• 8.2.2 Vérifier l’identité de l’utilisateur avant de modifier les informations d’identification ; par exemple, effectuer des réinitialisations de mot de passe, provisionner de nouveaux jetons ou générer de nouvelles clés.
• 8.2.3 Les phrases secrètes/mots de passe doivent respecter les conditions suivantes :
  • Longueur minimale d’au moins sept caractères.
  • Contenir des caractères alphabétiques et numériques.
• 8.2.4 Modifier les mots de passe/phrases secrètes des utilisateurs au moins une fois tous les 90 jours.
• 8.2.5 Ne pas autoriser une personne à soumettre un nouveau mot de passe/phrase identique à l’un des quatre derniers mots de passe/phrases utilisés.
• 8.2.6 Définir les mots de passe/phrases pour la première utilisation et la réinitialisation sur une valeur unique pour chaque utilisateur et modifier immédiatement après la première utilisation.

Vos responsabilités

Configurez des stratégies d’accès conditionnel dans Microsoft Entra ID pour votre cluster. Cela impose des restrictions d’accès au plan de contrôle Kubernetes.

Plusieurs des exigences précédentes sont gérées automatiquement par Microsoft Entra ID. Voici quelques exemples :

• Sécurité du mot de passe

  Microsoft Entra ID fournit des fonctionnalités qui imposent l’utilisation de mots de passe forts. Par exemple, les mots de passe faibles appartenant à la liste globale des mots de passe interdits sont bloqués. La protection est insuffisante. Envisagez d’ajouter la fonctionnalité de protection par mot de passe Microsoft Entra pour créer une liste d’exclusion propre à l’organisation. Une stratégie de mot de passe est appliquée par défaut. Certaines stratégies ne peuvent pas être modifiées et couvrent en partie les conditions requises abordées précédemment. Il s’agit notamment de l’expiration du mot de passe et des caractères autorisés. Pour obtenir la liste complète, consultez les Stratégies de mot de passe Microsoft Entra. Envisagez d’utiliser des fonctions avancées qui peuvent être appliquées avec des stratégies d’accès conditionnel, telles que celles basées sur le risque utilisateur, qui détectent les paires de nom d’utilisateur et de mot de passe divulguées. Pour plus d’informations, consultez Accès conditionnel : accès conditionnel basé sur les risques d’utilisateur.

  Notes

  Nous vous recommandons vivement de prendre en compte les options sans mot de passe. Pour plus d’informations, consultez Planifier un déploiement d’authentification sans mot de passe dans Microsoft Entra ID.

• Vérification d’identité utilisateur

  Vous pouvez appliquer la politique d’accès conditionnel au risque de connexion pour détecter si la requête d’authentification a été émise par l’identité requérante. La requête est validée après interrogation des sources de renseignement sur les menaces. Ces dernières incluent les anomalies de pulvérisation de mot de passe et d’adresse IP. Pour plus d’informations, consultez Accès conditionnel : accès conditionnel basé sur les risques de connexion.

Vous pouvez avoir des composants qui n’utilisent pas Microsoft Entra ID, comme l’accès SSH aux serveurs de rebond. Dans ce cas, utilisez le chiffrement à clé publique avec une taille minimale de clé RSA de 2 048 bits. Spécifiez toujours une phrase secrète. Mettez en place un processus de validation qui effectue le suivi des clés publiques approuvées connues. Les systèmes qui utilisent l’accès à clé publique ne doivent pas être exposés à Internet. Au lieu de cela, tous les accès SSH doivent être autorisés par un intermédiaire, tel qu’Azure Bastion, afin de réduire l’impact d’une fuite de clé privée. Désactivez l’accès direct par mot de passe et utilisez une solution alternative sans mot de passe.

Condition requise 8.3

Sécuriser tous les accès administratifs non-console et tous les accès à distance sur le CDE à l’aide de l’authentification multifacteur. Remarque : l’authentification multifacteur nécessite d’utiliser au moins deux des trois méthodes d’authentification (voir la condition requise 8.2 pour obtenir une description des méthodes d’authentification). Utiliser deux fois un facteur (par exemple, à l’aide de deux mots de passe distincts) n’est pas considéré comme une authentification multifacteur.

Vos responsabilités

Utilisez les stratégies d’accès conditionnel pour appliquer l’authentification multifacteur, en particulier sur les comptes d’administration. Ces stratégies sont recommandées sur plusieurs rôles intégrés. Appliquez ces stratégies à des groupes Microsoft Entra mappés à des rôles Kubernetes ayant des privilèges élevés.

Cette stratégie peut être renforcée à l’aide de stratégies supplémentaires. Voici quelques exemples :

• Vous pouvez restreindre l’authentification aux appareils managés par votre locataire Microsoft Entra.
• Si l’accès provient d’un réseau situé en dehors du réseau du cluster, vous pouvez appliquer l’authentification multifacteur.

Pour plus d'informations, consultez les pages suivantes :

• Accès conditionnel : Exiger MFA pour les administrateurs
• Procédure : Exiger des appareils gérés pour accéder aux applications cloud avec l’accès conditionnel
• Procédure : Exiger une authentification multifacteur (MFA) pour l’accès à partir de réseaux non approuvés disposant d’un accès conditionnel

Condition requise 8.4

Documenter et communiquer les stratégies et les procédures d’authentification ainsi que les stratégies et procédures à tous les utilisateurs, notamment :

• Conseils pour choisir des informations d’identification fortes
• Conseils à l’attention des utilisateurs pour assurer la protection de leurs informations d’identification
• Instructions pour la non-réutilisation des mots de passe précédemment utilisés
• Instructions pour la modification des mots de passe en cas de risque de compromission.

Vos responsabilités

Maintenez la documentation sur les stratégies appliquées. Dans le cadre de votre formation d’intégration d’identité, fournissez des conseils pour les procédures de réinitialisation de mot de passe et les meilleures pratiques organisationnelles sur la protection des ressources.

Condition requise 8.5

Ne pas utiliser d’identifiants ou de mots de passe groupés, partagés ou génériques, ou d’autres méthodes d’authentification comme suit :

• Les identifiants utilisateur génériques sont désactivés ou supprimés.
• Les identifiants utilisateur partagés n’existent pas pour l’administration du système et d’autres fonctions stratégiques.
• Les identifiants utilisateur partagés et génériques ne sont pas utilisés pour administrer des composants du système.

Vos responsabilités

Ne partagez pas ou ne réutilisez pas les identités pour des parties fonctionnellement différentes du cluster ou des pods. Par exemple, n’utilisez pas de compte d’équipe pour accéder aux données ou aux ressources de cluster. Assurez-vous que la documentation d’identité n’utilise pas de comptes partagés.

Désactivez les utilisateurs racine dans le CDE. Désactivez l’utilisation des comptes locaux Kubernetes pour que les utilisateurs ne puissent pas utiliser l’accès --admin intégré aux clusters dans le CDE.

Condition requise 8.6

Lorsque d’autres mécanismes d’authentification sont utilisés (par exemple, des jetons de sécurité physique ou logique, des cartes à puce, des certificats, etc.), l’utilisation de ces mécanismes doit être assignée comme suit :

• Les mécanismes d’authentification doivent être assignés à un compte individuel et non partagées entre plusieurs comptes.
• Des contrôles physiques et/ou logiques doivent avoir été mis en place pour garantir que seul le compte concerné puisse utiliser ce mécanisme d’accès.

Vos responsabilités

Assurez-vous que tous les accès à la CDE sont fournis par le biais d’identités utilisateur et qu’ils sont étendus à des jetons physiques ou virtuels. Cela inclut les accès VPN au réseau CDE, en veillant à ce que les accès point-à-site de l’entreprise (le cas échéant) emploient des certificats par utilisateur dans le cadre de ce flux d’authentification.

Condition requise 8.7

Tous les accès aux bases de données contenant des données de détenteurs de cartes (y compris l’accès aux applications, administrateurs et tous les autres utilisateurs) sont limités comme suit :

• Tous les accès utilisateur aux bases de données, ainsi que les requêtes et les actions sur les bases de données, s’effectuent par le biais des méthodes de programmation.
• Seuls les administrateurs de base de données ont la possibilité d’accéder directement ou d’interroger des bases de données.
• Les identifiants des applications de base de données peuvent uniquement être utilisés par les applications (et non par des utilisateurs ou d’autres processus non applicatifs).

Vos responsabilités

Fournir l’accès en fonction des rôles et des responsabilités. Les individus peuvent utiliser leur identité, mais l’accès doit être restreint en fonction du besoin de savoir, avec des autorisations permanentes minimales. Les individus ne doivent jamais utiliser les identités des applications, et les identités d’accès aux bases de données ne doivent jamais être partagées.

Si possible, accédez à la base de données à partir des applications par le biais de l’identité managée. Dans le cas contraire, limitez l’exposition aux chaînes de connexion et aux informations d’identification. Utilisez les secrets Kubernetes pour stocker les informations sensibles au lieu de les conserver dans des endroits où elles sont accessibles aisément, comme la définition des pods. Une autre méthode consiste à stocker et à charger des secrets vers et depuis un magasin managé, comme Azure Key Vault. Si les identités managées sont activées sur un cluster AKS, elles doivent s’authentifier auprès de Key Vault pour y accéder.

Condition requise 8.8

Assurer que les stratégies de sécurité et les procédures opérationnelles pour l’identification et l’authentification 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 votre formation d’intégration d’identité, fournissez des conseils pour les procédures de réinitialisation de mot de passe et les meilleures pratiques organisationnelles sur la protection des ressources. 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 qui font partie du processus d’approbation du point de vue de la stratégie.

Condition requise 9 - Restreindre l’accès physique aux données de titulaires de carte

Prise en charge des fonctionnalités AKS

Il n’existe aucune fonctionnalité AKS applicable pour cette exigence.

Vos responsabilités

Cette architecture et l’implémentation ne sont pas conçues pour fournir des contrôles sur l’accès physique aux ressources ou aux centres de donnes locaux. Pour plus d’informations, reportez-vous à l’aide de la norme PCI-DSS 3.2.1.

Voici quelques suggestions concernant l’application de contrôles techniques :

• Réglez les délais d’expiration de session dans tout accès à la console d’administration, tels que les serveurs de rebond dans le CDE, afin de réduire l’accès.

• Paramétrez les stratégies d’accès conditionnel pour réduire la durée de vie des jetons d’accès Azure à partir des points d’accès, tels que le Portail Azure. Pour plus d’informations, consultez les articles suivants :

  • Configurer la gestion de session d’authentification avec l’accès conditionnel
  • Durées de vie des jetons configurables - plateforme d’identité Microsoft

• Pour le CDE hébergé sur le cloud, il n’y a aucune responsabilité concernant la gestion de l’accès physique et du matériel. Appuyez-vous sur les contrôles physiques et logiques du réseau d’entreprise.

• Réduisez l’exportation des sauvegardes CHD vers des destinations locales. Utilisez des solutions hébergées dans Azure pour limiter l’accès physique aux sauvegardes.

• Réduisez au minimum les sauvegardes locales. Si cela s’avère nécessaire, sachez que la destination locale fera l’objet d’un audit.

Étapes suivantes

Effectuez le suivi et surveillez tous les accès aux ressources réseau et aux données de titulaires de carte. Testez régulièrement les processus et les systèmes de sécurité.