Modifier

Partager via

Considérations de sécurité pour les applications IaaS hautement sensibles dans Azure

Azure Disk Encryption
Pare-feu Azure
Azure Key Vault
Microsoft Defender pour le cloud
Réseau virtuel Azure

Il existe de nombreuses considérations relatives à la sécurité pour le déploiement d’applications IaaS (infrastructure-as-a-service) sur Azure. Cet article s’appuie sur des architectures de référence pour les charges de travail basées sur les machines virtuelles et sur les infrastructures réseau hybrides pour se concentrer sur la sécurité des charges de travail IaaS très sensibles dans Azure, en fonction de notions de base de la sécurité Azure.

Consultez également Vue d’ensemble de la sécurité des machines virtuelles Azure et Meilleures pratiques de sécurité pour les charges de travail IaaS dans Azure.

Machines virtuelles Azure

La plateforme de calcul Azure est basée sur la virtualisation des machines. Un hyperviseur s’exécute sur le matériel physique de chaque nœud Azure ou point de terminaison réseau et crée un nombre variable de machines virtuelles Hyper-V invitées sur le nœud. Tout le code utilisateur s’exécute sur les machines virtuelles. Pour obtenir des instructions de base sur le déploiement d’une machine virtuelle Azure, consultez Exécuter une machine virtuelle Linux sur Azure ou Exécuter une machine virtuelle Windows sur Azure. La plupart des processus de déploiement sont les mêmes pour les deux systèmes d’exploitation, mais les outils spécifiques au système d’exploitation, comme le chiffrement de disque, peuvent être différents.

Vous pouvez utiliser Microsoft Defender pour le cloud pour la gestion des correctifs de machines virtuelles et pour déployer et analyser des outils anti-programme malveillant. Vous pouvez également gérer vos propres outils de mise à jour corrective et anti-programme malveillant tiers, ce qui est courant lors de l’extension ou de la migration d’infrastructures existantes vers Azure.

Microsoft fournit la protection DDoS (déni de service distribué) de base dans le cadre de la plateforme Azure. Les applications qui ont des points de terminaison publics peuvent utiliser une Protection DDos Azure pour une protection supplémentaire. Toutefois, les charges de travail très sensibles n’ont généralement pas de points de terminaison publics et elles ne sont accessibles qu’à partir d’emplacements spécifiques sur un réseau privé virtuel (VPN) ou une ligne allouée.

Architectures de niveau N

De nombreuses applications IaaS se composent de plusieurs niveaux, tels qu’un niveau web, un niveau métier et un niveau données, hébergés sur plusieurs machines virtuelles. Les aspects clés du déploiement des architectures d’application multiniveau sur des machines virtuelles Azure sont les suivants :

  • Haute disponibilité (HA). Les applications HA doivent être disponibles plus de 99,9 % du temps. La mise en place de machines virtuelles de niveau dans différentes zones de disponibilité Azure (AZ) garantit la haute disponibilité, car les AZ s’étendent sur un ou plusieurs centres de données, garantissant la résilience grâce à une résistance aux défaillances du centre de données. Les régions qui ne prennent pas en charge les AZ peuvent utiliser des groupes à haute disponibilité (AS), qui distribuent des machines virtuelles sur plusieurs nœuds matériels isolés.
  • Équilibrage de charge. Les équilibreurs de charge répartissent le trafic entre les machines virtuelles, pour équilibrer la charge et garantir la résilience en cas de défaillance d’une machine virtuelle. Vous n’avez pas besoin d’équilibreurs de charge si l’application gère l’équilibrage de charge et que les machines virtuelles individuelles sont connues de l’appelant.
  • Réseaux virtuels. Les réseaux virtuels et les sous-réseaux segmentent votre réseau, ce qui facilite la gestion de la sécurité et le routage avancé.
  • DNS (Domain Name System) . Azure DNS fournit un service DNS hautement disponible et sécurisé. Une zone privée dans Azure DNS vous permet d’utiliser des domaines personnalisés à l’intérieur de vos réseaux virtuels.

Sauvegarde et restauration

Pour vous protéger contre les erreurs humaines, la suppression de données malveillantes et des rançongiciels, vous devez sauvegarder au moins vos machines virtuelles de niveau données. La Sauvegarde Azure peut sauvegarder et restaurer des machines virtuelles chiffrées s’il peut accéder aux clés de chiffrement dans Azure Key Vault.

Pour les niveaux web et métier, vous pouvez utiliser le groupe de machines virtuelles identiques des règles de mise à l’échelle automatique pour supprimer des machines virtuelles compromises automatiquement et déployer les nouvelles instances de machine virtuelle à partir d’une image de base.

Isolation du calcul

Sur chaque nœud Azure ou point de terminaison réseau, l’hyperviseur et un système d’exploitation racine spécial garantissent que les machines virtuelles invitées ne peuvent pas accéder au serveur hôte physique et que le code utilisateur s’exécute uniquement sur les machines virtuelles invitées. Cet isolement empêche les utilisateurs d’obtenir un accès brut en lecture/écriture/exécution au système et réduit le risque de partage des ressources. Azure protège contre toutes les attaques par canal auxiliaire et les voisins bruyants connus par le biais de l’hyperviseur et d’un algorithme de placement de machine virtuelle avancé. Pour plus d’informations, consultez Isolement de la capacité de calcul.

Pour les charges de travail hautement sensibles, vous pouvez ajouter une protection supplémentaire contre les attaques par canal auxiliaire avec des machines virtuelles isolées ou des hôtes dédiés.

Machines virtuelles isolées

Les machines virtuelles isolées sont de grandes machines virtuelles isolées d’un type de matériel spécifique et dédié à un client unique. L’utilisation d’une taille de machine virtuelle isolée garantit que votre machine virtuelle sera la seule en cours d’exécution sur cette instance de serveur spécifique. Vous pouvez également subdiviser les ressources de ces machines virtuelles isolées à l’aide du support Azure pour les machines virtuelles imbriquées.

La taille minimale d’une machine virtuelle isolée est 64 cœurs de processeur virtuel et 256 Gio de mémoire. Ces machines virtuelles, beaucoup plus volumineuses que la plupart des applications multiniveau, requièrent et peuvent créer une surcharge de coût importante. Pour réduire la surcharge, vous pouvez exécuter plusieurs niveaux d’application sur une machine virtuelle unique avec la virtualisation imbriquée ou dans différents processus ou conteneurs. Vous devez toujours déployer différentes machines virtuelles dans des AZ pour la résilience et exécuter des appliances de zone démilitarisée (DMZ) sur des machines virtuelles distinctes. La combinaison de plusieurs applications sur une infrastructure pour des raisons économiques peut également être en conflit avec les stratégies de répartition des applications organisationnelles.

Étant donné que les fonctionnalités de la région Azure se développent au fil du temps, Azure peut également supprimer les garanties d’isolement de certaines tailles de machine virtuelle, avec un préavis d’un an.

Hôtes dédiés Azure

Azure Dedicated Host est la solution d’isolement de calcul préférée pour les charges de travail hautement sensibles. Un hôte dédié est un serveur physique dédié à un client pour l’hébergement de plusieurs machines virtuelles. Outre l’isolement des machines virtuelles, les hôtes dédiés vous permettent de contrôler la maintenance et le placement des machines virtuelles pour éviter les voisins bruyants.

Hôtes dédiés

Les hôtes dédiés ont la même taille minimale et un grand nombre des mêmes considérations de dimensionnement que les machines virtuelles isolées. Toutefois, un hôte dédié peut héberger des machines virtuelles situées dans différents réseaux virtuels, afin de satisfaire les stratégies de répartition des applications. Vous devez toujours exécuter des machines virtuelles DMZ sur un autre ordinateur hôte de l’ordinateur virtuel, afin d’éviter toute attaque par canal auxiliaire à partir d’une machine virtuelle compromise dans la zone DMZ.

Chiffrement

Le chiffrement des données est un composant important de la sécurisation des charges de travail. Le chiffrement encode les informations afin que seuls les destinataires autorisés puissent les décoder à l’aide d’une clé ou d’un certificat. Le chiffrement comprend le chiffrement de disque, le chiffrement de données au repos et le protocole TLS (Transport Level Security) pour le chiffrement en transit sur les réseaux.

Azure Key Vault

Vous pouvez protéger les clés de chiffrement et les certificats en les stockant dans Azure Key Vault, une solution Module de sécurité matériel (HSM) cloud validée pour les normes FIPS (Federal Information Processing Standards) 140-2 niveau 2. Pour connaître les meilleures pratiques et permettre uniquement aux applications et utilisateurs autorisés d’accéder à Key Vault, consultez Sécuriser l’accès à un coffre de clés.

Pour protéger les clés dans Key Vault, vous pouvez activer suppression réversible, qui garantit que les clés supprimées sont récupérables. Pour une protection supplémentaire, vous pouvez sauvegarder des clés individuelles dans un fichier chiffré que vous pouvez utiliser pour restaurer les clés, potentiellement dans une autre région Azure dans la même zone géographique.

Lorsque vous hébergez SQL Server sur une machine virtuelle, vous pouvez utiliser le connecteur SQL Server pour Microsoft Azure Key Vault pour obtenir des clés pour le chiffrement transparent des données (TDE) , le chiffrement au niveau des colonnes (CLE) et le chiffrement de la sauvegarde. Pour plus d’informations, consultez Configurer l’intégration Azure Key Vault pour SQL Server sur des machines virtuelles Azure.

Azure Disk Encryption

Azure Disk Encryption utilise le protecteur de clé externe BitLocker pour assurer le chiffrement de volume des disques de système d’exploitation et de données des machines virtuelles Azure. Il peut s’intégrer à Azure Key Vault pour vous aider à contrôler et à gérer les secrets et les clés de chiffrement de disque. Chaque machine virtuelle génère ses propres clés de chiffrement et les stocke dans Azure Key Vault. Pour configurer Azure Key Vault pour activer la Azure Disk Encryption, consultez Créer et configurer un coffre de clés pour Azure Disk Encryption.

Pour les charges de travail très sensibles, vous devez également utiliser une clé de chiffrement à clé (KEK) pour une couche supplémentaire de sécurité. Quand vous spécifiez une KEK, Azure Disk Encryption utilise cette clé pour envelopper les secrets de chiffrement avant d’écrire dans Key Vault. Vous pouvez générer une KEK dans Azure Key Vault, mais une méthode plus sécurisée consiste à générer une clé dans votre HSM local et à l’importer dans Azure Key Vault. Ce scénario est souvent appelé Apportez votre propre cléou désigné par l’acronyme BYOK. Étant donné que les clés importées ne peuvent pas conserver la limite HSM, la génération de la clé dans votre HSM vous permet de vous assurer que vous êtes en contrôle total sur les clés de chiffrement.

Chiffrement protégé par HSM

Pour plus d’informations sur les clés protégées par HSM, consultez Comment générer et transférer des clés protégées par HSM pour Azure Key Vault.

Chiffrement du trafic

Les protocoles réseau, comme HTTP, chiffrent les données en transit avec des certificats. Le trafic client à application utilise généralement un certificat d’une autorité de certification approuvée. Les applications internes peuvent utiliser un certificat émanant d’une autorité de certification interne ou d’une autorité de certification publique telle que DigiCert ou GlobalSign. La communication de niveau à niveau utilise généralement un certificat émis par une autorité de certification interne ou un certificat auto-signé. Azure Key Vault peut prendre en charge l’un de ces types de certificat. Pour plus d’informations sur la création de différents types de certificats, consultez les méthodes de création de certificat.

Azure Key Vault peut agir entant qu’autorité de certification auto-signée pour le trafic de niveau à niveau. L’extension de machine virtuelle Key Vault permet d’analyser et d’actualiser automatiquement les certificats spécifiés sur les machines virtuelles, avec ou sans la clé privée en fonction du cas d’usage. Pour utiliser l’extension de machine virtuelle Key Vault, consultez Extension de machine virtuelle Key Vault pour Linux et Extension de machine virtuelle Key Vault pour Windows.

Key Vault peut également stocker des clés pour les protocoles réseau qui n’utilisent pas de certificats. Les charges de travail personnalisées peuvent nécessiter le script d’une extension de script personnalisé qui récupère une clé de Key Vault et la stocke pour les applications à utiliser. Les applications peuvent également utiliser les identités managées d’une machine virtuelle pour récupérer les secrets directement à partir de Key Vault.

Sécurité du réseau

Les groupes de sécurité réseau filtrent le trafic réseau entre les ressources dans des réseaux virtuels Azure. Les règles de sécurité NSG autorisent ou refusent le trafic réseau vers ou depuis les ressources Azure en fonction des adresses IP et des ports. Par défaut, les NSG bloquent le trafic entrant à partir d’Internet, mais autorise les connexions sortantes à partir de machines virtuelles vers Internet. Pour éviter tout trafic sortant accidentel, ajoutez une règle personnalisée avec la priorité la plus basse possible, 4096, pour bloquer tout le trafic entrant et sortant. Vous pouvez ensuite ajouter des règles de priorité plus élevée pour autoriser un trafic spécifique.

Les NGS créent des enregistrements du flux pour les connexions existantes et autorisent ou refusent la communication en fonction de l’état de connexion de l’enregistrement du flux. Un enregistrement du flux accorde un état à un groupe de sécurité réseau. Par exemple, si vous spécifiez une règle de sécurité sortante vers n’importe quelle adresse sur le port 443, il n’est pas nécessaire d’indiquer en plus une règle de sécurité entrante pour la réponse. Vous devez uniquement spécifier une règle de sécurité entrante si la communication est établie en externe.

La plupart des services Azure vous permettent d’utiliser une balise de service de réseau virtuel au lieu d’un groupe de sécurité réseau. Une étiquette de service représente un groupe de préfixes d’adresses IP d’un service Azure et permet de réduire la complexité liée aux fréquentes mises à jour des règles de sécurité réseau. Une balise de service Azure Key Vault peut autoriser la récupération de certificats, de clés et de secrets par une machine virtuelle depuis Azure Key Vault.

Vous pouvez également contrôler la sécurité du réseau via le routage du trafic du réseau virtuel et le tunneling forcé. Azure crée des itinéraires système automatiquement et assigne les itinéraires pour chaque sous-réseau dans un réseau virtuel. Vous ne pouvez pas créer ou supprimer des itinéraires système, mais vous pouvez en remplacer certains par des itinéraires personnalisés. Le routage personnalisé vous permet d’acheminer le trafic sur une appliance virtuelle réseau (NVA) comme un pare-feu ou un proxy ou de déposer le trafic non souhaité, ce qui a un effet similaire au blocage du trafic avec un groupe de sécurité réseau.

Vous pouvez utiliser des NVA comme le Pare-feu Azure pour autoriser, bloquer et inspecter le trafic réseau. Le Pare-feu Azure est un service de pare-feu de plate-forme managé et hautement disponible. Vous pouvez également déployer des NVA tierces à partir de la Place de marché Azure. Pour rendre ces NVA hautement disponibles, consultez Déployer des appliances virtuelles réseau hautement disponibles.

Groupes de sécurité d’application

Pour filtrer le trafic entre les couches Application au sein d’un réseau virtuel, utilisez des groupes de sécurité d’application (ASG). Les groupes de sécurité d’application permettent de configurer la sécurité réseau comme une extension naturelle de la structure de l’application et donc de grouper les machines virtuelles et de définir des stratégies de sécurité réseau basées sur ces groupes. Vous pouvez réutiliser votre stratégie de sécurité à grande échelle sans maintenance manuelle d’adresses IP explicites.

Groupes de sécurité d’application

Étant donné que les ASG sont appliqués à une interface réseau au lieu d’un sous-réseau, ils permettent la micro-segmentation. Vous pouvez contrôler étroitement les machines virtuelles qui peuvent communiquer entre elles, même en bloquant le trafic entre les machines virtuelles du même niveau et en facilitant le contrôle d’une machine virtuelle en supprimant les ASG de cette machine virtuelle.

Réseaux hybrides

Les architectures hybrides connectent des réseaux locaux avec des clouds publics tels qu’Azure. Il existe plusieurs façons de connecter des réseaux locaux à des applications qui s’exécutent dans Azure :

  • Point de terminaison public sur Internet. Vous pouvez vous appuyer sur l’identité, la sécurité au niveau du transport (HTTPS) et la passerelle applicative pour protéger l’application, éventuellement en association avec un pare-feu. Toutefois, pour les charges de travail très sensibles, il n’est pas recommandé d’exposer un point de terminaison public sur Internet.
  • Passerelle VPN Azure ou tierce. Vous pouvez connecter un réseau local à Azure à l’aide d’une passerelle VPN Azure. Le trafic circule toujours sur Internet, mais sur un tunnel chiffré qui utilise le protocole TLS. Vous pouvez également exécuter une passerelle tierce sur une machine virtuelle, si vous avez des exigences spécifiques qui ne sont pas prises en charge par la passerelle VPN Azure.
  • ExpressRoute. Les connexions ExpressRoute utilisent une connexion privée et dédiée via un fournisseur de connectivité tiers. La connexion privée étend votre réseau local dans Azure et fournit une scalabilité et un contrat de niveau de service (SLA) fiable.
    • ExpressRoute avec basculement VPN. Cette option utilise ExpressRoute dans des conditions normales, mais bascule vers une connexion VPN en cas de perte de connectivité au niveau du circuit ExpressRoute, fournissant une plus haute disponibilité.
    • VPN par ExpressRoute. Cette option est idéale pour les charges de travail très sensibles. ExpressRoute fournit un circuit privé avec scalabilité et fiabilité et le VPN fournit une couche supplémentaire de protection qui met fin à la connexion chiffrée dans un réseau virtuel Azure spécifique.

Pour plus de conseils sur le choix entre différents types de connectivité hybride, consultez Choisir une solution pour connecter un réseau local à Azure.

Déployer d’une zone DMZ

La connexion d’environnements locaux et Azure permet aux utilisateurs locaux d’accéder à des applications Azure. Un réseau de périmètre ou une zone démilitarisée (DMZ) fournit une protection supplémentaire pour les charges de travail hautement sensibles.

Une architecture comme celle de la zone DMZ du réseau entre Azure et un centre de données local déploie tous les services de la zone DMZ et d’application dans le même réseau virtuel, avec des règles de groupe de sécurité réseau et des itinéraires définis par l’utilisateur pour isoler les sous-réseaux de la DMZ et d’application. Cette architecture peut rendre le sous-réseau de gestion disponible via l’Internet public, pour gérer les applications même si la passerelle locale n’est pas disponible. Toutefois, pour les charges de travail très sensibles, vous ne devez autoriser le contournement de la passerelle que dans un scénario de secours. Une meilleure solution consiste à utiliser Azure Bastion, qui permet d’accéder directement à partir du Portail Azure tout en limitant l’exposition des adresses IP publiques.

Vous pouvez également utiliser l’accès à la machine virtuelle juste-à-temps (JAT) pour la gestion à distance tout en limitant l’exposition des adresses IP publiques. Avec l’accès JAT à la machine virtuelle, un groupe de sécurité réseau bloque les ports de gestion à distance tels que le protocole RDP (Remote Desktop Protocol) et Secure Shell (SSH) par défaut. À la demande, l’accès à la machine virtuelle JAT active le port uniquement pour une fenêtre de temps spécifiée et éventuellement pour une plage ou une adresse IP spécifique. L’accès JAT fonctionne également pour les machines virtuelles qui ont uniquement des adresses IP privées. Vous pouvez utiliser Azure Bastion pour bloquer le trafic vers une machine virtuelle jusqu’à ce que l’accès à la machine virtuelle JAT soit activé.

Pour déployer d’autres applications, vous pouvez utiliser une topologie hub-and-spoke dans Azure, avec la zone DMZ dans le réseau virtuel hub et les applications dans les réseaux virtuels spoke. Le réseau virtuel hub peut contenir une passerelle VPN et/ou ExpressRoute, une appliance virtuelle réseau du pare-feu, des hôtes de gestion, une infrastructure d’identités et d’autres services partagés. Les réseaux virtuels spoke sont connectés au hub avec l’appairage de réseaux virtuels. Un réseau virtuel Azure n’autorise pas le routage transitif sur le hub d’un spoke à l’autre. Le trafic spoke-à-spoke est uniquement possible via les appliances de pare-feu dans le hub. Cette architecture isole efficacement les applications les unes des autres.

Déploiement multi-régions

La continuité d’activité et reprise d’activité peut nécessiter le déploiement de votre application dans plusieurs régions Azure, ce qui peut avoir un impact sur la résidence et la sécurité des données.

Paires régionales

Une géographie Azure est une zone du monde définie contenant au moins une région Azure, chacune avec un ou plusieurs centres de données. Chaque région Azure est associée à une autre région de la même géographie dans une paire régionale. Les paires régionales ne sont pas toutes les deux mises à jour en même temps et si une catastrophe atteint les deux régions, l’une des régions est prioritaire pour revenir en ligne en premier. Pour la continuité d’activité, vous devez déployer des applications hautement sensibles au moins dans des paires régionales si vous déployez dans plusieurs régions.

Pour plus d’informations, consultez Continuité d'activité et reprise d'activité (BCDR) : régions jumelées d’Azure. Le livre blanc Atteindre une sécurité et une résidence des données conformes avec Azure aborde la résidence des données et ce qu’il faut faire pour répondre aux exigences de résidence des données.

Réplication entre régions

Dans les architectures IaaS, la réplication des données entre les régions est la responsabilité de l’application. Le scénario de réplication le plus courant utilise des technologies de réplication de base de données intégrées au produit du serveur de base de données, telles que Groupes de disponibilité AlwaysOn SQL Server, Protection des données Oracle ou Réplication MySQL.

La configuration de la réplication entre les serveurs de bases de données IaaS n’est pas simple et vous devez prendre en compte les exigences en matière de continuité d’activité. Les services de base de données Azure, tels que Azure SQL Database, Azure Database pour MySQL et Azure Cosmos DB facilitent la réplication entre les régions, mais peuvent ne pas répondre aux exigences de sécurité pour les charges de travail très sensibles.

Pour plus d’informations et pour obtenir des conseils pour les déploiements SQL Server et Oracle dans plusieurs régions, consultez :

Peering interrégional

Vous pouvez activer la communication sécurisée entre les réseaux virtuels dans des régions différentes à l’aide de l’appairage de réseaux virtuels. Le peering mondial fonctionne de la même façon que le peering régional. Le trafic entre les régions s’exécute sur le segment principal de Microsoft, ne traverse pas Internet et est isolé du reste du trafic. Pour plus de sécurité, vous pouvez déployer des appliances virtuelles réseau VPN dans les deux régions et utiliser des itinéraires définis par l’utilisateur pour forcer le trafic entre les régions sur les appliances virtuelles réseau, de la même façon que le déploiement d’une zone DMZ.

Routage du trafic par basculement

Avec les points de terminaison publics, vous pouvez utiliser Traffic Manager ou Azure Front Door pour diriger le trafic vers la région active ou la région la plus proche dans une configuration de basculement active-active. Toutefois, Traffic Manager et Azure Front Door nécessitent tous deux des points de terminaison publics pour analyser la disponibilité et les entrées DNS correspondantes sont publiques. Pour les charges de travail hautement sensibles, l’autre solution consiste à déployer le DNS localement et à modifier les entrées dans la région active pour le basculement.

Gestion et gouvernance

La sécurisation de vos applications IaaS hautement sensibles nécessite plus que le simple déploiement des architectures appropriées et l’implémentation des règles de sécurité réseau. Étant donné que les environnements cloud sont facilement modifiés, il est particulièrement important de s’assurer que les modifications ne peuvent être apportées qu’avec certaines autorisations et dans les limites des stratégies de sécurité. Par exemple, vous devez empêcher un acteur malveillant de pouvoir modifier une règle de sécurité réseau pour autoriser le trafic à partir d’Internet.

Pour déployer des charges de travail dans Azure, vous avez besoin d’un ou de plusieurs comptes de gestion. La sécurisation des comptes de gestion est essentielle pour sécuriser vos charges de travail. Pour plus d’informations, consultez Sécuriser l’accès privilégié pour les déploiements hybrides et cloud dans Microsoft Entra ID.

Utilisez les ressources de votre sous-réseau de gestion pour accorder l’accès au niveau de l’application uniquement aux personnes qui doivent gérer ce niveau. Par exemple, vous pouvez utiliser Microsoft Identity Manager avec Microsoft Entra ID. Toutefois, pour les scénarios natifs Cloud, Microsoft Entra Privileged Identity Management (PIM) est préférable.

Il existe plusieurs autres moyens de contrôler les rôles et les stratégies Azure :

  • Le contrôle d’accès en fonction du rôle Azure (RBAC Azure) pour les ressources Azure vous permet d’attribuer des rôles intégrés ou personnalisés aux utilisateurs, de sorte qu’ils disposent uniquement des privilèges dont ils ont besoin. Vous pouvez combiner RBAC Azure avec PIM pour implémenter un workflow d’approbation audité qui élève les privilèges pendant une période limitée.
  • Les stratégies appliquent des règles d’entreprise, des normes et des Contrat de niveau de service. Azure Policy est un service Azure qui crée, attribue et gère des stratégies et évalue vos ressources pour la conformité aux stratégies.
  • Azure Blueprints combine des attributions de rôles, des attributions de stratégies et des modèles de déploiement pour définir un ensemble de ressources Azure réplicables qui implémentent et suivent les normes, les modèles et les exigences d’une organisation. Les blueprints constituent un moyen déclaratif d’orchestrer le déploiement des modèles de ressources et d’autres artefacts. Vous pouvez créer vous-même des blueprints ou tirer parti des blueprints existants. Par exemple, le blueprint des services partagés ISO 27001 déploie un hub de services partagés que vous pouvez modifier et étendre aux exigences de votre organisation.

Supervision

Microsoft Defender pour le cloud fournit des analyses et des alertes qui vous aident à maintenir la sécurité de votre environnement. Le service gratuit vérifie automatiquement les vulnérabilités, telles que les correctifs de système d’exploitation manquants, la configuration incorrecte de la sécurité et la sécurité réseau de base. La version payante standard offre des fonctionnalités supplémentaires, telles que l’analyse comportementale, le renforcement de la sécurité réseau adaptative et l’accès à la machine virtuelle JAT. Pour obtenir la liste complète des fonctionnalités, consultez Couverture des fonctionnalités pour les machines. Defender pour le cloud fournit également une protection contre les menaces pour d’autres ressources telles qu’Azure Key Vault.

Vous pouvez utiliser Azure Monitor pour un suivi et une analyse supplémentaires. Pour analyser l’identité et l’accès, vous pouvez acheminer les journaux d’activité Microsoft Entra vers Azure Monitor. Vous pouvez également analyser les machines virtuelles, les réseaux et le Pare-feu Azure et analyser les journaux importés avec la puissante fonctionnalité de requête de journaux. Vous pouvez intégrer Azure Monitor à votre solution SIEM, qui peut être une solution SIEM tierce ou Microsoft Sentinel.