Considérations relatives à la sécurité pour les charges de travail stratégiques sur Azure

La sécurité est l’un des principes fondamentaux de la conception et également un domaine de conception clé qui doit être traité comme une préoccupation de première classe au sein du processus architectural stratégique.

Étant donné que le principal objectif d’une conception stratégique est d’optimiser la fiabilité afin que l’application reste performante et disponible, les considérations de sécurité et les recommandations appliquées dans ce domaine de conception se concentrent sur l’atténuation des menaces avec la capacité d’impact sur la disponibilité et entravent la fiabilité globale. Par exemple, les attaques par déni de service (DDoS) réussies sont connues pour avoir un impact catastrophique sur la disponibilité et les performances. Comment une application atténue ces vecteurs d’attaque, tels que SlowLoris, aura un impact sur la fiabilité globale. Ainsi, l’application doit être entièrement protégée contre les menaces destinées à compromettre directement ou indirectement la fiabilité de l’application pour être véritablement stratégique dans la nature.

Il est également important de noter qu’il existe souvent des compromis importants associés à une posture de sécurité renforcée, en particulier en ce qui concerne les performances, l’agilité opérationnelle et, dans certains cas, la fiabilité. Par exemple, l’inclusion d’appliances virtuelles réseau inline (NVA) pour les fonctionnalités de pare-feu de nouvelle génération (NGFW), telles que l’inspection approfondie des paquets, introduit une pénalité de performances significative, une complexité opérationnelle supplémentaire et un risque de fiabilité si les opérations d’extensibilité et de récupération ne sont pas étroitement alignées sur celle de l’application. Il est donc essentiel que d’autres composants et pratiques de sécurité destinés à atténuer les vecteurs de menace clés soient également conçus pour prendre en charge la cible de fiabilité d’une application, qui constitue un aspect clé des recommandations et considérations présentées dans cette section.

Important

Cet article fait partie de la série de charges de travail stratégiques Azure Well-Architected. Si vous n’êtes pas familiarisé avec cette série, nous vous recommandons de commencer par ce qu’est une charge de travail stratégique ?

Projet de code source ouvert stratégique

Les implémentations de référence font partie d’un projet code source ouvert disponible sur GitHub. Les ressources de code adoptent un modèle Confiance Zéro pour structurer et guider l’approche de conception et d’implémentation de la sécurité.

Alignement avec le modèle Confiance Zéro

Le modèle microsoft Confiance Zéro fournit une approche proactive et intégrée de l’application de la sécurité sur toutes les couches d’une application. Les principes fondamentaux de Confiance Zéro s’efforcent de vérifier explicitement et en permanence chaque transaction, d’affirmer le moindre privilège, d’utiliser le renseignement et la détection avancée pour répondre aux menaces en quasi-temps réel. Il est finalement centré sur l’élimination de la confiance à l’intérieur et à l’extérieur des périmètres d’application, en appliquant la vérification pour tout ce qui tente de se connecter au système.

Considérations sur la conception

Lorsque vous évaluez la posture de sécurité de l’application, commencez par ces questions comme base pour chaque considération.

• Test de sécurité continu pour valider les atténuations pour les vulnérabilités de sécurité clés.

  • Les tests de sécurité sont-ils effectués dans le cadre de processus CI/CD automatisés ?
  • Si ce n’est pas le cas, à quelle fréquence des tests de sécurité spécifiques sont-ils effectués ?
  • Les résultats des tests sont-ils mesurés par rapport à une posture de sécurité et un modèle de menace souhaités ?

• Niveau de sécurité dans tous les environnements inférieurs.

  • Tous les environnements du cycle de vie du développement ont-ils la même posture de sécurité que l’environnement de production ?

• Continuité de l’authentification et de l’autorisation en cas d’échec.

  • Si les services d’authentification ou d’autorisation sont temporairement indisponibles, l’application pourra-t-elle continuer à fonctionner ?

• Conformité et correction automatisées de la sécurité.

  • Les modifications apportées aux paramètres de sécurité clés peuvent-elles être détectées ?
  • Les réponses à la correction des modifications non conformes sont-elles automatisées ?

• Analyse des secrets pour détecter les secrets avant que le code ne soit validé pour empêcher toute fuite de secrets via des référentiels de code source.

  • L’authentification aux services est-elle possible sans avoir d’informations d’identification dans le cadre du code ?

• Sécurisez la chaîne logistique logicielle.

  • Est-il possible de suivre les vulnérabilités et les expositions courantes (CVE) dans les dépendances de package utilisées ?
  • Existe-t-il un processus automatisé de mise à jour des dépendances de package ?

• Cycle de vie des clés de protection des données.

  • Les clés gérées par le service peuvent-elles être utilisées pour la protection de l’intégrité des données ?
  • Si des clés gérées par le client sont requises, comment le cycle de vie des clés sécurisée et fiable est-il nécessaire ?

• Les outils CI/CD doivent nécessiter des principaux de service Microsoft Entra disposant d’un accès suffisant au niveau de l’abonnement pour faciliter l’accès au plan de contrôle pour les déploiements de ressources Azure à tous les abonnements d’environnement considérés.

  • Lorsque les ressources d’application sont verrouillées dans des réseaux privés, il existe un chemin de connectivité de plan de données privé afin que les outils CI/CD puissent effectuer des déploiements et une maintenance au niveau de l’application.
    • Cela introduit une complexité supplémentaire et nécessite une séquence dans le processus de déploiement par le biais d’agents de build privés requis.

Recommandations de conception

• Utilisez Azure Policy pour appliquer des configurations de sécurité et de fiabilité à tous les services, en vérifiant que tout écart est corrigé ou interdit par le plan de contrôle au moment de la configuration, afin d’atténuer les menaces associées aux scénarios d’« administrateur malveillant ».

• Utilisez Microsoft Entra Privileged Identity Management (PIM) dans les abonnements de production pour révoquer l’accès prolongé du plan de contrôle aux environnements de production. Cela réduira considérablement le risque posé par les scénarios d'« administrateur malveillant » par le biais d’autres « contrôles et soldes ».

• Utilisez les identités managées Azure pour tous les services qui prennent en charge la fonctionnalité, car elle facilite la suppression des informations d’identification du code d’application et supprime la charge opérationnelle de la gestion des identités pour la communication de service à service.

• Utilisez le contrôle d’accès en fonction du rôle (RBAC) Microsoft Entra pour l’autorisation du plan de données avec tous les services qui prennent en charge la fonctionnalité.

• Utilisez des bibliothèques d’authentification Plateforme d’identités Microsoft internes au sein du code d’application pour l’intégrer à l’ID Microsoft Entra.

• Envisagez la mise en cache de jetons sécurisée pour permettre une expérience détériorée mais disponible si la plateforme d’identité choisie n’est pas disponible ou n’est disponible que partiellement pour l’autorisation d’application.

  • Si le fournisseur ne parvient pas à émettre de nouveaux jetons d’accès, mais valide toujours ceux existants, l’application et les services dépendants peuvent fonctionner sans problème tant que leurs jetons n’expirent pas.
  • La mise en cache des jetons est généralement gérée automatiquement par les bibliothèques d’authentification (telles que MSAL).

• Utilisez les pipelines IAC (Infrastructure-as-Code) et CI/CD automatisés pour générer des mises à jour de tous les composants d’application, y compris dans des circonstances de défaillance.

  • Vérifiez que les connexions de service des outils CI/CD sont protégées en tant qu’informations sensibles critiques et ne sont pas être directement disponibles pour les équipes de service.
  • Appliquez un RBAC granulaire aux pipelines CD de production pour atténuer les risques d’« administrateur malveillant ».
  • Envisagez l’utilisation de portes d’approbation manuelles dans les pipelines de déploiement de production pour atténuer davantage les risques d'« administrateur malveillant » et fournir une assurance technique supplémentaire pour toutes les modifications de production.
    • Des portes de sécurité supplémentaires peuvent être un compromis en termes d’agilité et doivent être soigneusement évaluées, compte tenu de la façon dont l’agilité peut être maintenue même avec des portes manuelles.

• Définissez une posture de sécurité appropriée pour tous les environnements inférieurs afin d’atténuer les vulnérabilités clés.

  • N’appliquez pas la même posture de sécurité que la production, en particulier en ce qui concerne l’exfiltration des données, sauf si les exigences réglementaires stipulent la nécessité de le faire, car cela compromettra considérablement l’agilité des développeurs.

• Activez Microsoft Defender pour le cloud (anciennement Azure Security Center) pour tous les abonnements qui contiennent les ressources d’une charge de travail stratégique.

  • Utilisez Azure Policy pour appliquer la conformité.
  • Activez Azure Defender pour tous les services qui prennent en charge la fonctionnalité.

• Adoptez DevSecOps et implémentez des tests de sécurité dans des pipelines CI/CD.

  • Les résultats des tests doivent être mesurés par rapport à une posture de sécurité conforme pour informer les approbations de publication, qu’elles soient automatisées ou manuelles.
  • Appliquez des tests de sécurité dans le cadre du processus de production CD pour chaque version.
    • Si les tests de sécurité de chaque version mettent en péril l’agilité opérationnelle, assurez-vous qu’une cadence de test de sécurité appropriée est appliquée.

• Activez l’analyse des secrets et l’analyse des dépendances dans le référentiel de code source.

Modélisation des menaces

La modélisation des menaces fournit une approche basée sur les risques de la conception de la sécurité, en utilisant des menaces potentielles identifiées pour développer des atténuations de sécurité appropriées. Il existe de nombreuses menaces possibles avec différentes probabilités d’occurrence, et dans de nombreux cas, les menaces peuvent se chaîner de manière inattendue, imprévisible et même chaotique. Cette complexité et cette incertitude sont la raison pour laquelle les approches de sécurité basées sur les exigences technologiques traditionnelles sont largement inadaptées aux applications cloud critiques. Attendez-vous à ce que le processus de modélisation des menaces pour une application stratégique soit complexe et inflexe.

Pour faciliter la navigation dans ces défis, une approche de défense en couches doit être appliquée pour définir et implémenter des atténuations de compensation pour les menaces modélisées, compte tenu des couches défensives suivantes.

1. Plateforme Azure avec des fonctionnalités et des contrôles de sécurité fondamentaux.
2. Architecture de l’application et conception de sécurité.
3. Fonctionnalités de sécurité intégrées, activées et déployables appliquées à des ressources Azure sécurisées.
4. Code d’application et logique de sécurité.
5. Processus opérationnels et DevSecOps.

Remarque

Lors du déploiement dans une zone d’atterrissage Azure, sachez qu’une couche d’atténuation des menaces supplémentaire via l’approvisionnement des fonctionnalités de sécurité centralisées est fournie par l’implémentation de la zone d’atterrissage.

Considérations sur la conception

STRIDE fournit un framework de risque léger pour l’évaluation des menaces de sécurité sur les vecteurs de menace clés.

• Identité usurpée : emprunt d’identité d’individus avec autorité. Par exemple, un attaquant empruntant l’identité d’un autre utilisateur à l’aide de son
  • Identité
  • Authentification
• Falsification d’entrée : modification de l’entrée envoyée à l’application ou violation des limites d’approbation pour modifier le code de l’application. Par exemple, un attaquant utilisant l’injection SQL pour supprimer des données dans une table de base de données.
  • Intégrité des données
  • Validation
  • Blocklisting/allowlisting
• Répudiation d’action : possibilité de réfuter les actions déjà prises et la capacité de l’application à recueillir des preuves et à favoriser la responsabilité. Par exemple, la suppression de données critiques sans possibilité de trace vers un administrateur malveillant.
  • Audit/journalisation
  • Signature
• Divulgation d’informations : accès aux informations restreintes. Par exemple, un attaquant a accès à un fichier restreint.
  • Chiffrement
  • Exfiltration de données
  • Attaques man-in-the-middle
• Déni de service : interruption d’application malveillante pour dégrader l’expérience utilisateur. Par exemple, une attaque botnet DDoS telle que Slowloris.
  • DDoS
  • botnets
  • Fonctionnalités CDN et WAF
• Élévation de privilèges : obtention d’un accès d’application privilégié par le biais d’attaques d’autorisation. Par exemple, un attaquant manipule une chaîne d’URL pour accéder aux informations sensibles.
  • Exécution de code à distance
  • Autorisation
  • Isolation

Recommandations de conception

• Allouez un budget d’ingénierie au sein de chaque sprint pour évaluer les nouvelles menaces potentielles et implémenter des atténuations.

• L’effort conscient doit être appliqué pour garantir que les atténuations de sécurité sont capturées dans un critère d’ingénierie commun pour assurer la cohérence entre toutes les équipes de service d’application.

• Commencez par un service par modélisation des menaces au niveau du service et unifiez le modèle en consolidant le modèle de thread au niveau de l’application.

Protection contre les intrusions réseau

Il est primordial d’empêcher l’accès non autorisé à une application stratégique et à des données englobés pour maintenir la disponibilité et protéger l’intégrité des données.

Considérations sur la conception

• Confiance Zéro suppose un état de violation et vérifie chaque requête comme s’il provient d’un réseau non contrôlé.

  • Une implémentation réseau de confiance zéro avancée utilise une micro-segmentation et des micro-périmètres d’entrée/de sortie distribués.

• Les services PaaS Azure sont généralement accessibles sur des points de terminaison publics. Azure offre des fonctionnalités pour sécuriser ces points de terminaison publics, voire les rendre entièrement privés.

  • Azure Private Link/les points de terminaison privés fournissent un accès dédié à une ressource Azure PaaS en utilisant des adresses IP privées et une connectivité réseau privée.
  • Réseau virtuel points de terminaison de service fournissent un accès au niveau du service à partir de sous-réseaux sélectionnés aux services PaaS sélectionnés.
  • Réseau virtuel Injection fournit des déploiements privés dédiés pour les services pris en charge, tels qu’App Service via un environnement App Service.
    • Toutefois, le trafic de plan de gestion transite encore par des adresses IP publiques.

• Pour les services pris en charge, Azure Private Link à l’aide de points de terminaison privés Azure traite les risques d’exfiltration des données associés aux points de terminaison de service, tels qu’un administrateur malveillant écrivant des données dans une ressource externe.

• Lors de la restriction de l’accès réseau aux services PaaS Azure à l’aide de points de terminaison privés ou de points de terminaison de service, un canal réseau sécurisé est requis pour que les pipelines de déploiement accèdent à la fois au plan de contrôle Azure et au plan de données des ressources Azure afin de déployer et de gérer l’application.

  • Les agents de build auto-hébergés privés déployés sur un réseau privé, car la ressource Azure peut être utilisée comme proxy pour exécuter des fonctions CI/CD sur une connexion privée. Un réseau virtuel distinct doit être utilisé pour les agents de build.
    • La connectivité aux agents de build privés à partir des outils CI/CD est requise.
  • Une autre approche consiste à modifier les règles de pare-feu pour la ressource à la volée dans le pipeline afin d’autoriser une connexion à partir d’une adresse IP publique de l’agent Azure DevOps, avec le pare-feu ensuite supprimé une fois la tâche terminée.
    • Toutefois, cette approche s’applique uniquement à un sous-ensemble de services Azure. Par exemple, cela n’est pas possible pour les clusters AKS privés.
  • Pour effectuer des tâches de développement et d’administration sur les zones de rebond du service d’application peuvent être utilisées.

• L’achèvement des tâches d’administration et de maintenance est un scénario supplémentaire nécessitant une connectivité au plan de données des ressources Azure.

• Les connexions de service avec un principal de service Microsoft Entra correspondant peuvent être utilisées dans Azure DevOps pour appliquer RBAC via l’ID Microsoft Entra.

• Les balises de service peuvent être appliquées aux groupes de sécurité réseau pour faciliter la connectivité avec les services PaaS Azure.

• Les groupes de sécurité d’application ne s’étendent pas sur plusieurs réseaux virtuels.

• La capture de paquets dans Azure Network Watcher est limitée à une période maximale de cinq heures.

Recommandations de conception

• Limitez l’accès au réseau public au minimum absolu requis pour que l’application remplisse son objectif métier afin de réduire la surface d’attaque externe.

  • Utilisez Azure Private Link pour établir des points de terminaison privés pour les ressources Azure qui nécessitent une intégration réseau sécurisée.
  • Utilisez des agents de build privés hébergés pour les outils CI/CD pour déployer et configurer des ressources Azure protégées par Azure Private Link.
    • Les agents hébergés par Microsoft ne pourront pas se connecter directement aux ressources intégrées au réseau.

• Quand vous utilisez des agents de build privés, n’ouvrez jamais de port RDP ou SSH directement sur Internet.

  • Utilisez Azure Bastion pour fournir un accès sécurisé à Azure Machines Virtuelles et effectuer des tâches d’administration sur Azure PaaS via Internet.

• Utilisez un plan de protection standard DDoS pour sécuriser toutes les adresses IP publiques au sein de l’application.

• Utilisez Azure Front Door avec des stratégies de pare-feu d’applications web pour livrer et protéger des applications HTTP/S globales qui s’étendent sur plusieurs régions Azure.

  • Utilisez la validation des ID d’en-tête pour verrouiller les points de terminaison d’application publics afin qu’ils acceptent uniquement le trafic provenant de l’instance Azure Front Door.

• Si des exigences de sécurité réseau supplémentaires, telles que l’inspection approfondie des paquets ou tls, imposent l’utilisation d’Pare-feu Azure appliance virtuelle réseau (NVA) premium ou réseau, vérifiez qu’elle est configurée pour une haute disponibilité et une redondance maximales.

• Si des exigences de capture de paquets existent, utilisez les paquets Network Watcher pour capturer malgré la fenêtre de capture limitée.

• Utilisez des groupes de sécurité réseau et des groupes de sécurité d’application pour segmenter le trafic des applications.

  • Évitez d’utiliser une appliance de sécurité pour filtrer les flux de trafic intra-application.
  • Envisagez l’utilisation d’Azure Policy pour appliquer des règles de groupe de sécurité réseau spécifiques sont toujours associées aux sous-réseaux d’application.

• Activez les journaux de flux de groupe de sécurité réseau et alimentez-les dans Traffic Analytics pour obtenir des informations sur des flux de trafic internes et externes.

• Utilisez Azure Private Link/des points de terminaison privés, le cas échéant, pour sécuriser l’accès aux services Azure PaaS dans la conception de l’application. Pour plus d’informations sur les services Azure qui prennent en charge Private Link, consultez Disponibilité d’Azure Private Link.

• Si le point de terminaison privé n’est pas disponible et que les risques d’exfiltration des données sont acceptables, utilisez Réseau virtuel points de terminaison de service pour sécuriser l’accès aux services PaaS Azure à partir d’un réseau virtuel.

  • N’activez pas par défaut les points de terminaison de service de réseau virtuel sur tous les sous-réseaux, car cela introduit des canaux d’exfiltration de données importants.

• Pour les scénarios d’applications hybrides, accédez aux services Azure PaaS à partir d’un site local via ExpressRoute avec un peering privé.

Remarque

Lors du déploiement dans une zone d’atterrissage Azure, sachez que la connectivité réseau aux centres de données locaux est fournie par l’implémentation de la zone d’atterrissage. Une approche consiste à utiliser ExpressRoute configuré avec le peering privé.

Protection de l’intégrité des données

Le chiffrement est une étape essentielle pour garantir l’intégrité des données et représente en fin de compte l’une des fonctionnalités de sécurité les plus importantes qui peut être appliquées pour atténuer un large éventail de menaces. Cette section fournit donc des considérations clés et des recommandations relatives au chiffrement et à la gestion des clés afin de protéger les données sans compromettre la fiabilité de l’application.

Considérations sur la conception

• Azure Key Vault a des limites de transaction pour les clés et les secrets, avec une limitation appliquée par coffre dans un certain délai.

• Azure Key Vault offre une limite de sécurité, car les autorisations d’accès pour les clés, les secrets et les certificats sont appliquées au niveau du coffre.

  • Les affectations de stratégie d’accès de Key Vault accordent des autorisations séparément à des clés, secrets ou certificats.
    • Les autorisations granulaires au niveau de l’objet pour une clé, un secret ou un certificat spécifiques sont désormais possibles.

• Une fois qu’une attribution de rôle a été modifiée, il y a une latence allant jusqu’à 10 minutes (600 secondes) pour que le rôle soit appliqué.

  • Il existe une limite de 2 000 attributions de rôles Azure par abonnement.

• Les modules de sécurité matériel sous-jacents Azure Key Vault ont une validation FIPS 140.

  • Un HSM managé Azure Key Vault dédié est disponible pour les scénarios nécessitant une conformité FIPS 140-2 de niveau 3.

• Azure Key Vault fournit une haute disponibilité et une redondance pour aider à maintenir la disponibilité et à empêcher la perte de données.

• Pendant un basculement de région, le basculement du service Key Vault peut prendre quelques minutes.

  • Lors d’un basculement Key Vault est en mode lecture seule, il n’est donc pas possible de modifier les propriétés du coffre de clés telles que les configurations et les paramètres du pare-feu.

• Si une liaison privée est utilisée pour se connecter à Azure Key Vault, la connexion peut prendre jusqu’à 20 minutes pour que la connexion soit rétablie lors d’un basculement régional.

• Une sauvegarde crée un instantané à un point dans le temps d’un secret, d’une clé ou d’un certificat, en tant qu’objet blob chiffré qui ne peut pas être déchiffré en dehors d’Azure. Pour obtenir des données utilisables à partir de l’objet blob, elles doivent être restaurées dans un coffre de clés dans le même abonnement Azure et la même zone géographique Azure.

  • Les secrets peuvent se renouveler pendant une sauvegarde, ce qui entraîne une incompatibilité.

• Avec les clés gérées par le service, Azure effectue des fonctions de gestion de clés, telles que la rotation, réduisant ainsi l’étendue des opérations d’application.

• Les contrôles réglementaires peuvent stipuler l’utilisation de clés gérées par le client pour la fonctionnalité de chiffrement de service.

• Lorsque le trafic se déplace entre les centres de données Azure, le chiffrement de la couche de liaison de données MACsec est utilisé sur le matériel réseau sous-jacent pour sécuriser les données en transit en dehors des limites physiques non contrôlées par Microsoft ou au nom de Microsoft.

Recommandations de conception

• Utilisez dans la mesure du possible des clés gérées par le service pour la protection des données, pour éviter de gérer les clés de chiffrement ainsi que les tâches opérationnelles comme la permutation des clés.

  • Utilisez uniquement les clés gérées par le client lorsqu’il existe une exigence réglementaire claire pour ce faire.

• Utilisez Azure Key Vault comme référentiel sécurisé pour tous les secrets, certificats et clés si des mécanismes de chiffrement supplémentaires ou des clés gérées par le client ont besoin d’être pris en compte.

  • Approvisionnez Azure Key Vault avec les stratégies de suppression et de vidage réversibles activées pour autoriser la protection de la rétention des objets supprimés.
  • Utilisez la référence SKU Azure Key Vault sauvegardée par HSM pour les environnements de production d’applications.

• Déployez une instance Azure Key Vault distincte au sein de chaque tampon de déploiement régional, fournissant des avantages en matière d’isolation des pannes et de performances par le biais de la localisation, ainsi que la navigation dans les limites d’échelle imposées par une seule instance Key Vault.

  • Utilisez une instance Azure Key Vault dédiée pour les ressources globales d’application.

• Suivez un modèle de privilège minimum en limitant l’autorisation de supprimer définitivement des secrets, des clés et des certificats pour des rôles Microsoft Entra personnalisés spécialisés.

• Vérifiez que les clés de chiffrement et les certificats stockés dans Key Vault sont sauvegardés, en fournissant une copie hors connexion dans l’événement peu probable où Key Vault devient indisponible.

• Utilisez des certificats de coffre de clés pour gérer l’approvisionnement et la signature des certificats.

• Établissez un processus automatisé pour la rotation des clés et des certificats.

  • Automatisez le processus de gestion et de renouvellement des certificats auprès des autorités de certification publiques pour faciliter l’administration.
    • Définissez des alertes et des notifications pour compléter les renouvellements de certificats automatisés.

• Supervisez l’utilisation des clés, des certificats et des secrets.

  • Définissez des alertes pour une utilisation inattendue dans Azure Monitor.

Gouvernance basée sur une stratégie

En fin de compte, les conventions de sécurité sont efficaces seulement si elles sont appliquées de manière cohérente et holistique dans l’ensemble des services d’application et des équipes. Azure Policy fournit un framework permettant d’appliquer des bases de référence de sécurité et de fiabilité, garantissant ainsi une conformité continue avec des critères d’ingénierie courants pour une application stratégique. Plus précisément, Azure Policy constitue une partie clé du plan de contrôle Azure Resource Manager (ARM), en complément du contrôle RBAC en limitant les actions que les utilisateurs autorisés peuvent effectuer, et peut être utilisé pour appliquer des conventions de sécurité et de fiabilité vitales sur les services de plateforme utilisés.

Cette section explore donc les principales considérations et recommandations relatives à l’utilisation de la gouvernance pilotée par Azure Policy pour une application stratégique, ce qui garantit que les conventions de sécurité et de fiabilité sont appliquées en permanence.

Considérations sur la conception

• Azure Policy fournit un mécanisme de conformité en appliquant des conventions de sécurité et de fiabilité, telles que l’utilisation de points de terminaison privés ou l’utilisation de Zones de disponibilité.

Remarque

Lors du déploiement dans une zone d’atterrissage Azure, sachez que l’application des affectations de stratégie de référence centralisées sera probablement appliquée dans l’implémentation pour les groupes d’administration et les abonnements de zone d’atterrissage.

• Azure Policy peut être utilisé pour piloter des activités de gestion automatisées, telles que l’approvisionnement et la configuration.

  • Inscription du fournisseur de ressources.
  • Validation et approbation des configurations de ressources Azure individuelles.

• L’étendue de l’affectation Azure Policy détermine la couverture et l’emplacement des définitions Azure Policy informe la réutilisation des stratégies personnalisées.

• Azure Policy a plusieurs limites, telles que le nombre de définitions dans une étendue particulière.

• L’exécution des stratégies Deploy If Not Exist (DINE) peut prendre plusieurs minutes.

• Azure Policy fournit une entrée critique pour la création de rapports de conformité et l’audit de sécurité.

Recommandations de conception

• Mappez les exigences réglementaires et de conformité aux définitions Azure Policy.

  • Par exemple, en cas d’exigences de résidence des données, une stratégie doit être appliquée pour restreindre les régions de déploiement disponibles.

• Définissez un critère d’ingénierie commun pour capturer des définitions de configuration sécurisées et fiables pour tous les services Azure utilisés, ce qui garantit que ces critères sont mappés aux affectations Azure Policy pour appliquer la conformité.

  • Par exemple, appliquez une stratégie Azure pour appliquer l’utilisation de Zones de disponibilité pour tous les services pertinents, ce qui garantit des configurations de déploiement intrarégion fiables.

L’implémentation de référence stratégique contient un large éventail de stratégies centrées sur la sécurité et la fiabilité pour définir et appliquer un exemple de critères d’ingénierie courants.

• Surveillez la dérive de configuration du service, par rapport aux critères d’ingénierie courants, à l’aide d’Azure Policy.

Pour les scénarios stratégiques avec plusieurs abonnements de production sous un groupe d’administration dédié, hiérarchiser les affectations au niveau de l’étendue du groupe d’administration.

• Utilisez des stratégies intégrées dans la mesure du possible pour réduire la surcharge opérationnelle liée à la gestion des définitions de stratégie personnalisées.

• Lorsque des définitions de stratégie personnalisées sont requises, assurez-vous que les définitions sont déployées au niveau d’une étendue de groupe d’administration appropriée pour permettre la réutilisation entre les abonnements d’environnement inclus afin de permettre la réutilisation des stratégies dans les environnements de production et les environnements inférieurs.

  • Lors de l’alignement de la feuille de route de l’application avec des feuilles de route Azure, utilisez les ressources Microsoft disponibles pour explorer si des définitions personnalisées critiques peuvent être incorporées en tant que définitions intégrées.

Remarque

Lors du déploiement dans une zone d’atterrissage Azure, envisagez de déployer des définitions Azure Policy personnalisées au sein de l’étendue du groupe d’administration racine de l’entreprise intermédiaire pour permettre la réutilisation dans toutes les applications au sein du patrimoine Azure plus large. Dans un environnement de zone d’atterrissage, certaines stratégies de sécurité centralisées sont appliquées par défaut dans des étendues de groupe d’administration supérieures pour appliquer la conformité de la sécurité dans l’ensemble du patrimoine Azure. Par exemple, les stratégies Azure doivent être appliquées pour déployer automatiquement des configurations logicielles via des extensions de machine virtuelle et appliquer une configuration de machine virtuelle de base conforme.

• Utilisez Azure Policy pour appliquer un schéma de balisage cohérent dans l’application.
  • Identifiez les balises Azure requises et utilisez le mode d’ajout de stratégie pour appliquer l’utilisation.

Si l’application est abonnée au support stratégique Microsoft, assurez-vous que le schéma d’étiquetage appliqué fournit un contexte significatif pour enrichir l’expérience de support avec une compréhension approfondie de l’application.

• Exportez les journaux d’activité Microsoft Entra vers l’espace de travail Log Analytics global utilisé par l’application.
  • Vérifiez que les journaux d’activité Azure sont archivés dans le compte de stockage global, ainsi que les données opérationnelles pour la rétention à long terme.

Dans une zone d’atterrissage Azure, les journaux d’activité Microsoft Entra seront également ingérés dans l’espace de travail Log Analytics de plateforme centralisée. Elle doit être évaluée dans ce cas si l’ID Microsoft Entra est toujours requis dans l’espace de travail Log Analytics global.

• Intégrez les informations de sécurité et la gestion des événements à Microsoft Defender pour le cloud (anciennement Azure Security Center).

Considérations spécifiques à IaaS lors de l’utilisation de Machines Virtuelles

Dans les scénarios où l’utilisation de l’Machines Virtuelles IaaS est requise, certaines spécificités doivent être prises en compte.

Considérations sur la conception

• Les images ne sont pas mises à jour automatiquement une fois déployées.
• Les mises à jour ne sont pas installées automatiquement sur les machines virtuelles en cours d’exécution.
• Les images et les machines virtuelles individuelles ne sont généralement pas renforcées prêtes à l’emploi.

Recommandations de conception

• N’autorisez pas l’accès direct via l’Internet public à Machines Virtuelles en fournissant l’accès à SSH, RDP ou à d’autres protocoles. Utilisez toujours Azure Bastion et les jumpbox avec un accès limité à un petit groupe d’utilisateurs.
• Limitez la connectivité Internet directe à l’aide de groupes de sécurité réseau, de pare-feu (Azure) ou de passerelles d’application (niveau 7) pour filtrer et restreindre le trafic de sortie.
• Pour les applications multiniveau, envisagez d’utiliser différents sous-réseaux et d’utiliser des groupes de sécurité réseau pour restreindre l’accès entre les deux.
• Hiérarchiser l’utilisation de l’authentification par clé publique, le cas échéant. Stockez des secrets dans un endroit sécurisé comme Azure Key Vault.
• Protégez les machines virtuelles à l’aide de l’authentification et du contrôle d’accès.
• Appliquez les mêmes pratiques de sécurité que celles décrites pour les scénarios d’application stratégiques.

Suivez et appliquez des pratiques de sécurité pour les scénarios d’application stratégiques, comme décrit ci-dessus, le cas échéant, ainsi que les meilleures pratiques de sécurité pour les charges de travail IaaS dans Azure.

Étape suivante

Passez en revue les meilleures pratiques pour les procédures opérationnelles pour les scénarios d’application stratégiques.

Procédures opérationnelles