Azure Well-Architected Framework est un ensemble de principes directeurs qui permettent d’évaluer une solution en s’appuyant sur les piliers de qualité de l’excellence architecturale :
Cet article est le dernier de la série. Lisez l’introduction.
Les conseils de cette série intègrent les principes de Well-Architected pour tous les choix de conception. Cet article résume les choix énoncés. L’implémentation GitHub : Cluster de référence Azure Kubernetes Service (AKS) pour les charges de travail réglementées illustre ces principes, le cas échéant.
Les charges de travail PCI DSS 3.2.1 exigent la rigueur d’une solution Well-Architected. Bien que l’alignement de l’infrastructure sur les exigences PCI soit essentiel, la conformité ne s’arrête pas à l’infrastructure d’hébergement. Le fait de ne pas prendre en compte les piliers de la qualité, notamment la sécurité, peut compromettre la conformité. Les solutions Well-Architected combinent à la fois les perspectives de l’infrastructure et de la charge de travail pour obtenir des résultats conformes dans un cadre rigoureux.
Sécurité
Suivez les conseils fondamentaux fournis par les Principes de conception de la sécurité. Les meilleures pratiques pour un environnement réglementé sont résumées dans les sections suivantes.
Gouvernance
L’implémentation de la gouvernance est régie par les exigences de conformité de la norme PCI-DSS 3.2.1. Cela influence les contrôles techniques pour maintenir la segmentation, accéder aux ressources, détecter les vulnérabilités et, surtout, protéger les données des clients.
Stratégie de segmentation d’entreprise
Pour assurer une isolation complète, nous recommandons de déployer l’infrastructure réglementée dans un abonnement autonome. Si vous avez plusieurs abonnements nécessaires à la conformité, envisagez de les regrouper dans une hiérarchie de groupes d’administration qui applique les stratégies Azure appropriées uniformément à vos abonnements dans l’étendue. Dans l’abonnement, appliquez les stratégies Azure associées au niveau de l’abonnement pour capturer les stratégies générales qui doivent s’appliquer à tous les clusters de l’environnement de données des détenteurs de cartes (CDE). Appliquez les stratégies Azure associées au niveau du groupe de ressources pour capturer les stratégies qui s’appliquent à une instance de cluster spécifique. Ces stratégies constituent les garde-fous principaux d’une zone d’atterrissage.
Isolez la charge de travail PCI (dans l’étendue) des autres charges de travail (hors de l’étendue) en termes d’opérations et de connectivité. Vous pouvez créer une isolation en déployant des clusters distincts. Vous pouvez également utiliser des stratégies de segmentation pour maintenir la séparation. Par exemple, les clusters utilisent des pools de nœuds séparés afin que les charges de travail ne partagent jamais une machine virtuelle (VM) de nœud.
Application des stratégies
Appliquez des contrôles de sécurité en activant les stratégies Azure. Par exemple, dans cette architecture réglementée, vous pouvez empêcher la configuration incorrecte de l’environnement des données des détenteurs de cartes. Vous pouvez appliquer une stratégie Azure qui n’autorise pas l’attribution d’adresses IP publiques sur les nœuds de machine virtuelle. De telles allocations sont détectées et signalées ou bloquées.
Pour plus d’informations sur les stratégies que vous pouvez activer pour AKS, consultez Définitions intégrées d’Azure Policy pour Azure Kubernetes Service.
Azure fournit plusieurs stratégies intégrées pour la plupart des services. Évaluez ces définitions de stratégie intégrées Azure Policy et appliquez-les selon vos besoins.
Surveillance de la conformité
La conformité doit être surveillée et gérée systématiquement. Des attestations de conformité sont régulièrement produites. Le fait de savoir si vos ressources cloud sont conformes permet de préparer les attestations et les audits.
Tirez parti du tableau de bord de conformité réglementaire dans Microsoft Defender pour le cloud. En surveillant en permanence le tableau de bord, vous pouvez suivre l’état de conformité de votre charge de travail.
Sécurité du réseau
Dans une topologie hub-and-spoke, le fait de disposer de réseaux virtuels distincts pour chaque entité permet la segmentation de base de l’empreinte réseau. Chaque réseau est encore segmenté dans des sous-réseaux.
Le cluster AKS forme le cœur du CDE. Il ne doit pas être accessible depuis des adresses IP publiques, et la connectivité doit être sécurisée. Les flux classiques dans et hors CDE peuvent être classés comme suit :
- Trafic entrant vers le cluster.
- Trafic sortant du cluster.
- Trafic intra-cluster entre les pods.
Pour répondre aux exigences d’un environnement réglementé, le cluster est déployé en tant que cluster privé. Dans ce mode, le trafic vers et depuis l’Internet public est limité. Même la communication avec le serveur d’API Kubernetes managé par AKS est privée. La sécurité est encore améliorée avec des contrôles réseau stricts et des règles de pare-feu IP.
- Groupes de sécurité réseau (NSG) pour sécuriser la communication entre les ressources d’un réseau.
- Pare-feu Azure pour filtrer le trafic sortant entre les ressources cloud, Internet et locales.
- Azure Application Gateway intégré à Azure Web Application Framework pour filtrer tout le trafic entrant provenant d’Internet intercepté par Azure Application Gateway.
- Kubernetes NetworkPolicy pour n’autoriser que certains chemins entre les pods du cluster.
- Azure Private Link pour se connecter à d’autres services Azure platform as a service (PaaS), tels qu’Azure Key Vault et Azure Container Registry pour les tâches opérationnelles.
Des processus de surveillance sont en place pour s’assurer que le trafic circule comme prévu et que toute anomalie est détectée et signalée.
Pour plus d’informations sur la sécurité réseau, consultez Segmentation réseau.
Sécurité des données
La norme PCI-DSS 3.2.1 exige que toutes les données des détenteurs de cartes ne soient jamais codées en clair, que ce soit en transit ou en stockage.
Comme cette architecture et son implémentation sont axées sur l’infrastructure et non sur la charge de travail, la gestion des données n’est pas présentée. Voici quelques recommandations d’architecture bien pensée.
Données au repos
Les données doivent être chiffrées au moyen d’algorithmes de chiffrement conformes aux normes industrielles.
- Ne stockez pas de données dans l’environnement des détenteurs de cartes.
- Chiffrez en dehors de la couche de stockage.
- Écrivez uniquement des données chiffrées dans le support de stockage.
- Ne stockez pas les clés dans la couche de stockage.
Toutes les données de Stockage Azure sont chiffrées et déchiffrées à l’aide d’un chiffrement fort. Les clés de chiffrement gérées automatiquement sont préférables.
Si vous avez besoin de stocker temporairement des données, appliquez les mêmes considérations à ces données. Nous vous recommandons vivement d’activer la fonctionnalité de chiffrement par hôte de AKS. Vous pouvez appliquer le chiffrement des données temporaires avec les stratégies Azure intégrées.
Lorsque vous choisissez une technologie de stockage, explorez les fonctionnalités de rétention. Assurez-vous que toutes les données sont supprimées en toute sécurité lors de l’expiration du délai configuré.
La norme exige également que les données d’authentification sensibles (SAD) ne soient pas stockées. Assurez-vous que les données ne sont pas exposées dans les journaux, les noms de fichiers, le cache et autres données.
Données en transit
Toute communication avec les entités qui interagissent avec le CDE doit se faire sur des canaux chiffrés.
- Seul le trafic HTTPS doit être autorisé à pénétrer dans le CDE. Dans cette architecture, Azure Application Gateway refuse tout trafic sur le port 80.
- Il est préférable de ne pas chiffrer et déchiffrer les données en dehors du CDE. Si c’est le cas, considérez cette entité comme faisant partie du CDE.
- Au sein du CDE, assurez une communication sécurisée entre les pods avec mTLS. Vous pouvez choisir d’implémenter un maillage de service à cet effet.
- Autorisez uniquement les chiffrements sécurisés et TLS 1.2 ou version ultérieure.
Identité
Suivez ces principes de sécurité lorsque vous concevez des stratégies d’accès :
- Commencez avec les stratégies de Confiance Zéro. Faites des exceptions si nécessaire.
- Accordez le moins de privilèges possible, juste assez pour accomplir une tâche.
- Réduisez au minimum les accès permanents.
Le fonctionnalité de contrôle d’accès en fonction du rôle (RBAC) de Kubernetes gère les autorisations sur l’API Kubernetes. AKS prend en charge ces rôles Kubernetes. AKS est entièrement intégré à Microsoft Entra ID. Vous pouvez attribuer des identités Microsoft Entra aux rôles et bénéficier également d’autres capacités.
Accès Confiance Zéro
Les services Kubernetes RBAC, RBAC Azure et Azure implémentent Tout refuser par défaut. Contournez ce paramètre avec prudence, en autorisant l’accès uniquement aux entités qui en ont besoin. Une autre façon d’implémenter la Confiance Zéro consiste à désactiver l’accès SSH aux nœuds du cluster.
Privilèges minimum
Vous pouvez utiliser des identités managées pour les ressources et les pods Azure et les limiter aux tâches prévues. 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.
Minimisation des accès permanents
Optez pour l’appartenance JIT au groupe Microsoft Entra afin de recourir le moins possible aux accès permanents. Renforcez le contrôle avec des stratégies d’accès conditionnel dans Microsoft Entra ID. Cette option prend en charge de nombreux cas d’utilisation, comme l’authentification multifacteur, la restriction de l’authentification aux appareils managés par votre locataire Microsoft Entra ou le blocage des tentatives de connexion atypiques.
Gestion des secrets
Stockez les secrets, les certificats, les clés et les mots de passe en dehors du CDE. Vous pouvez utiliser les secrets Kubernetes natifs ou un magasin de clés managé, tel que Azure Key Vault. L’utilisation d’un magasin managé vous aide à effectuer des tâches de gestion des secrets, comme la rotation des clés et le renouvellement des certificats.
Veillez à ce que l’accès au magasin de clés soit soumis à un équilibre entre le réseau et les contrôles d’accès. Lorsque vous activez les identités managées, le cluster doit s’authentifier auprès de Key Vault pour obtenir l’accès. En outre, la connectivité au magasin de clés ne doit pas passer par l’Internet public. Utilisez un réseau privé, tel que Private Link.
Excellence opérationnelle
Suivez les conseils fondamentaux fournis par les Principes d’excellence opérationnelle. Les meilleures pratiques pour un environnement réglementé sont résumées dans les sections suivantes.
Séparation des rôles
Il est essentiel de mettre en place une séparation claire des tâches dans les environnements réglementés. Disposez des définitions des rôles et des responsabilités basées sur les besoins de la charge de travail et de l’interaction avec le CDE. Par exemple, vous pouvez avoir besoin d’un rôle d’opérateur d’infrastructure ou d’ingénieur de fiabilité de site (SRE) pour les opérations liées au cluster et aux services dépendants. Le rôle est responsable de la gestion de la sécurité, de l’isolation, du déploiement et de l’observation. Formalisez ces définitions et déterminez les autorisations dont ces rôles ont besoin. Par exemple, les SRE bénéficient d’un privilège élevé pour l’accès aux clusters mais ont besoin d’un accès en lecture aux espaces de noms des charges de travail.
Isolation des charges de travail
La norme PCI-DSS 3.2.1 impose l’isolation de la charge de travail PCI des autres charges de travail en termes d’opérations. Dans cette implémentation, les charges de travail dans l’étendue et hors de l’étendue sont segmentées dans deux pools de nœuds utilisateur distincts. Les développeurs d’applications pour les charges de travail dans l’étendue et les développeurs pour les charges de travail hors de l’étendue peuvent avoir des ensembles d’autorisations différents. En outre, les critères de qualité seront différents. Par exemple, le code dans l’étendue est soumis au respect de la conformité et à l’attestation, contrairement au code hors de l’étendue. Il est également nécessaire d’avoir des pipelines de build et des processus de gestion des mises en production distincts.
Métadonnées opérationnelles
La condition requise 12 de la norme PCI DSS 3.2.1 vous oblige à conserver des informations sur l’inventaire des charges de travail et la documentation sur l’accès du personnel. Nous vous recommandons vivement d’utiliser des balises Azure, car vous pouvez assembler les informations d’environnement avec les ressources, les groupes de ressources et les abonnements Azure.
Tenez à jour les informations sur les solutions approuvées qui font partie de l’infrastructure et de la charge de travail. Cela comprend une liste d’images de machines virtuelles, de bases de données et de solutions tierces de votre choix que vous apportez au CDE. Vous pouvez même automatiser ce processus en créant un catalogue de services. Cela permet le déploiement en libre-service à l’aide de ces solutions approuvées dans une configuration spécifique qui respecte les opérations courantes de la plateforme.
Observabilité
Pour répondre à la condition requise 10, il est impératif de pouvoir observer l’activité interne du CDE. Les journaux d’activité fournissent des informations sur les opérations liées à la gestion des comptes et des secrets, la gestion des paramètres de diagnostic, la gestion des serveurs, ainsi que sur d’autres opérations d’accès aux ressources. Tous les journaux sont enregistrés avec la date, l’heure, l’identité et d’autres informations détaillées. Conservez les journaux jusqu’à un an en configurant des stratégies de conservation et d’archivage des données dans les journaux Azure Monitor.
Assurez-vous que les journaux sont accessibles uniquement par les rôles qui en ont besoin. Log Analytics et Microsoft Sentinel prennent en charge différents contrôles d’accès basés sur les rôles pour gérer l’accès des pistes d’audit.
Réponse et correction
Les services de monitoring Azure, Azure Monitor et Microsoft Defender pour le cloud peuvent générer des notifications ou des alertes lorsqu’ils détectent une activité anormale. Ces alertes comprennent des informations contextuelles telles que la gravité, l’état et la durée d’activité. À mesure que des alertes sont générées, vous devez disposer d’une stratégie de correction et passer en revue la progression. Nous vous recommandons de centraliser les données dans une solution SIEM (Security information and Event Management), car l’intégration des données peut fournir un contexte d’alerte élaboré.
À partir de l’affichage Alertes de sécurité dans Microsoft Defender pour le cloud, vous avez accès à toutes les alertes que Microsoft Defender pour le cloud détecte sur vos ressources. Mettez en place un processus de triage pour résoudre le problème. Collaborez avec votre équipe de sécurité pour comprendre comment les alertes appropriées seront mises à la disposition des propriétaires de la charge de travail.
Efficacité des performances
Suivez les instructions fondamentales fournies dans les Principes de l’efficacité des performances. Les meilleures pratiques pour un environnement réglementé sont résumées dans les sections suivantes.
Mise à l'échelle
L’observation de la façon dont l’environnement s’ajuste à l’évolution des demandes permet de comprendre le comportement attendu de l’environnement en cas de charge élevée. La mise à l’échelle automatique des ressources dans la charge de travail réduit le nombre d’interactions humaines dans le CDE. Réduire la surface d’attaque à tout moment constitue un avantage de sécurité supplémentaire. Vous pouvez en tirer le meilleur parti en profitant des ressources qui soutiennent l’approche de mise à l’échelle à zéro. Par exemple, AKS prend en charge le scale down à 0 des pools de nœuds utilisateur. Pour plus d’informations, consultez Mise à l’échelle des pools de nœuds utilisateur à 0.
Partitionnement
Le partitionnement est un facteur clé de l’efficacité des performances dans les charges de travail réglementées. Le fait de disposer de composants distincts permet de définir clairement les responsabilités et facilite la mise en place de contrôles précis, tels que les stratégies réseau. Comme toute stratégie de segmentation, le partitionnement permet d’isoler les composants et de contrôler l’impact du rayon de l’explosion sur les défaillances inattendues ou la compromission du système.
Architecture sans partage
L’architecture sans partage est conçue pour éliminer la contention entre les charges de travail colocalisées. Il s’agit également d’une stratégie visant à supprimer les points de défaillance uniques. Dans un environnement réglementé, les composants doivent être isolés par des limites logiques ou physiques. Cela s’aligne sur l’architecture sans partage, ce qui présente des avantages en termes d’évolutivité. Elle permet également de cibler les contrôles de sécurité pertinents et de renforcer les fonctionnalités d’audit des différents composants.
Infrastructures légères
La complexité des charges de travail est difficile à documenter et à auditer. Recherchez la simplicité en raison des avantages en matière de performance et de la facilité d’audit des exigences réglementaires. Évaluez les choix plus permissifs que nécessaire, car ils augmentent la surface d’exposition aux attaques et le risque d’une mauvaise configuration.
Fiabilité
La fiabilité des environnements réglementés doit être prévisible afin de pouvoir être expliquée de manière cohérente dans le cadre d’un audit. Suivez les instructions fondamentales fournies dans les principes de fiabilité. Les meilleures pratiques pour un environnement réglementé sont résumées dans les sections suivantes.
Cibles de récupération et récupération d’urgence
En raison de la nature sensible des données gérées dans les charges de travail réglementées, la définition des cibles de récupération et des objectifs de point de récupération (RPO) est essentielle. Quelle est la perte acceptable de données CHD ? Les efforts de récupération au sein du CDE sont toujours soumis aux exigences standard. Attendez-vous à des défaillances et disposez d’un plan de récupération clair pour ces défaillances qui s’aligne sur les rôles, les responsabilités et l’accès justifié aux données. Les problèmes de site actif ne justifient pas de s’écarter des réglementations. Cela est particulièrement important dans une situation de récupération d’urgence complète. Disposez d’une documentation claire sur la récupération d’urgence qui est conforme aux exigences et réduit les accès indésirables à un CDE ou à un CHD. Après la récupération, passez toujours en revue les étapes du processus de récupération pour vous assurer qu’aucun accès inattendu ne s’est produit. Documentez les justifications métier pour ces instances.
Récupération
L’ajout de stratégies de résilience et de récupération à votre architecture permet de se dispenser d’un accès ad hoc au CDE. Le système doit être en mesure d’effectuer une récupération automatique au RPO défini sans nécessiter d’intervention humaine directe. De cette façon, vous pouvez éliminer toute exposition inutile de données CHD, même aux personnes autorisées à avoir un accès d’urgence. Le processus de récupération doit être audité.
Résolution des risques liés à la sécurité
Examinez les risques de sécurité, car ils peuvent engendrer une interruption de la charge de travail et une perte de données. Les investissements en matière de sécurité influent également sur la fiabilité de la charge de travail.
Processus opérationnels
La fiabilité s’étend à tous les processus opérationnels dans le CDE et aux processus opérationnels adjacents à celui-ci. Des processus bien définis, automatisés et testés pour des questions, telles que la création d’images et la gestion de la zone de rebond, font partie d’une solution Well-Architected.
Optimisation des coûts
Suivez les instructions fondamentales fournies dans les principes d’optimisation des coûts.
En raison des exigences de conformité et des contrôles de sécurité stricts, le coût constitue un compromis évident. Nous vous recommandons d’établir des estimations initiales à l’aide de la calculatrice de prix.
Voici une représentation de haut niveau de l’impact sur les coûts des ressources principales utilisées par cette architecture.
Les principaux moteurs sont les groupes de machines virtuelles identiques qui constituent les pools de nœuds et le Pare-feu Azure. Log Analytics est un autre contributeur. Il existe également des coûts incrémentiels pour Microsoft Defender pour le cloud, en fonction de votre choix de plans.
Comprenez clairement ce qui constitue le prix d’un service. Azure effectue l’utilisation facturée à l’usage. Voici un exemple d’exploration hiérarchique du Pare-feu Azure pour cette architecture.
Les coûts associés à certaines ressources, telles que le Pare-feu Azure, peuvent être répartis sur plusieurs unités commerciales et/ou applications. Une autre façon d’optimiser les coûts peut consister à héberger un cluster multilocataire au sein d’une organisation, en maximisant la densité avec la diversité des charges de travail. Cette approche n’est pas recommandée pour les charges de travail réglementées. Hiérarchisez toujours la conformité et la segmentation des avantages en terme de coûts.
Pour respecter les contraintes budgétaires, il est possible de contrôler les coûts en ajustant l’infrastructure Azure Application Gateway, en fixant le nombre d’instances pour la mise à l’échelle automatique et en réduisant la sortie du journal, à condition qu’ils répondent toujours à la piste d’audit requise par la norme PCI-DSS 3.2.1. Évaluez toujours ces choix par rapport aux compromis sur d’autres aspects de la conception qui vous permettent de respecter votre contrat de niveau de service (SLA). Par exemple, êtes-vous encore en mesure d’effectuer une mise à l’échelle appropriée pour répondre aux pics de trafic ?
Lorsque vous créez des groupes de ressources Azure, appliquez-leur des balises afin de pouvoir suivre le coût. Utilisez des outils de gestion des coûts comme Azure Advisor et Microsoft Cost Management pour le suivi et l’analyse des coûts.
Envisagez d’activer l’analyse des coûts AKS pour l’allocation granulaire des coûts de l’infrastructure de cluster par des constructions spécifiques à Kubernetes.