Appliquer les principes Confiance Zéro à un réseau virtuel Spoke dans Azure
Résumé : Pour appliquer les principes de Confiance Zéro à un réseau virtuel « spoke » dans Azure, vous devez tirer profit du contrôle d’accès en fonction du rôle (RBAC, role-based access control), isoler les sous-réseaux et les machines virtuelles (groupes de ressources, groupes de sécurité réseau et groupes de sécurité d’application), sécuriser le trafic et les ressources au sein du VNet et des applications de machine virtuelle, et activer la détection, les alertes et la protection avancées des menaces.
Cet article vous aide à appliquer les principes de Confiance Zéro à un réseau virtuel Spoke pour les charges de travail IaaS dans Azure de la manière suivante :
| Principe de Confiance Zéro | Définition | Respecté par |
|---|---|---|
| Vérifier explicitement | Toujours s'authentifier et autoriser en fonction de tous les points de données disponibles. | Utilisez des groupes de sécurité d'application pour vérifier que les cartes réseau individuelles disposent des autorisations nécessaires pour communiquer sur des canaux spécifiques. |
| Utiliser le droit d'accès minimal | Limitez l'accès utilisateur avec l'accès juste-à-temps et juste suffisant (JIT/JEA), des stratégies adaptatives basées sur les risques et une protection des données. | N'activez pas l'accès 3389/RDP par défaut sur n'importe quel canal. Utilisez les autorisations de rôle correctes pour le contexte Spoke. |
| Supposer une violation | Réduisez le rayon d'explosion et segmentez l'accès. Vérifiez le chiffrement de bout en bout et utilisez l'analytique pour obtenir de la visibilité, détecter les menaces et améliorer les défenses. | Limitez les communications inutiles entre les ressources. Assurez-vous que vous êtes en mesure de vous connecter aux groupes de sécurité réseau et que vous avez une visibilité appropriée sur le trafic anormal. Suivez les modifications apportées aux groupes de sécurité réseau. |
Cet article fait partie d'une série d'articles qui montrent comment appliquer les principes de Confiance Zéro dans un environnement azure qui inclut un réseau virtuel Spoke qui héberge une charge de travail basée sur des machines virtuelles. Pour plus d'informations, consultez la vue d'ensemble Appliquer les principes de Confiance Zéro à Azure IaaS.
Architecture de référence
Le diagramme suivant illustre une architecture de référence commune pour les charges de travail IaaS.
Comme le montre le diagramme :
- Un réseau virtuel Spoke inclut des composants pour prendre en charge une application IaaS composée de machines virtuelles.
- L'application IaaS est une application à trois niveaux qui comprend deux machines virtuelles pour chaque niveau : front-end, application et données.
- Chaque niveau est contenu dans un sous-réseau dédié avec un groupe de sécurité réseau dédié.
- Chaque rôle de machine virtuelle est attribué à un groupe de sécurité d'application correspondant à son rôle.
- L'accès à l'application est fourni via une passerelle Application Gateway contenue dans son propre sous-réseau.
L'application affichée dans l'architecture de référence obéit au style d'architecture multiniveau
Le diagramme suivant montre les composants d'un groupe de ressources pour un réseau virtuel Spoke dans un abonnement Azure distinct de l'abonnement pour le réseau virtuel Hub.
Dans le diagramme, tous les composants du réseau virtuel Spoke sont contenus dans un groupe de ressources dédié :
- Un réseau virtuel
- Une passerelle Azure Application Gateway (APP GW), y compris un pare-feu d'applications Web (WAF)
- Trois groupes de sécurité réseau, soit un pour chaque couche Application
- Trois groupes de sécurité d'application, soit un pour chaque couche Application
Que contient cet article ?
Les principes de Confiance Zéro sont appliqués dans l'architecture, du client et du niveau d'annuaire jusqu'à l'affectation de machines virtuelles aux groupes de sécurité d'application. Le tableau suivant décrit les recommandations relatives à la sécurisation de cette architecture.
| Step | Task | Principe(s) de Confiance Zéro appliqué(s) |
|---|---|---|
| 1 | Utilisez le contrôle d'accès en fonction du rôle (RBAC) de Microsoft Entra ou configurez des rôles personnalisés pour les ressources réseau. | Utiliser le droit d'accès minimal |
| 2 | Isolez l'infrastructure dans son propre groupe de ressources. | Supposer une violation |
| 3 | Créez un groupe de sécurité réseau pour chaque sous-réseau. | Utiliser le droit d'accès minimal Supposer une violation |
| 4 | Créez un groupe de sécurité des applications pour chaque rôle de machine virtuelle. | Vérifier explicitement Utiliser le droit d'accès minimal Supposer une violation |
| 5 | Sécurisez le trafic et les ressources au sein du réseau virtuel : |
Vérifier explicitement Utiliser le droit d'accès minimal Supposer une violation |
| 6 | Sécurisez l'accès au réseau virtuel et à l'application. | Utiliser le droit d'accès minimal Supposer une violation |
| 7 | Activez la détection, l'avertissement et la protection avancées des menaces. | Supposer une violation |
Étape 1 : utiliser Microsoft Entra RBAC ou définir des rôles personnalisés pour les ressources du réseau
Vous pouvez utiliser des rôles intégrés Microsoft Entra RBAC pour les contributeurs réseau. Toutefois, une autre approche consiste à utiliser des rôles personnalisés. Les gestionnaires de réseau Spoke n'ont pas besoin d'un contrôle total aux ressources réseau accordées par le rôle Collaborateur réseau Microsoft Entra RBAC, mais ont besoin de plus d'autorisations que d'autres rôles courants. Vous pouvez utiliser un rôle personnalisé pour étendre l'accès à ce qui est nécessaire.
Un moyen simple d'implémenter cela consiste à déployer les rôles personnalisés trouvés dans l'architecture de référence de zone d'atterrissage Azure.
Le rôle spécifique est le rôle personnalisé Gestion du réseau avec les autorisations suivantes :
- Tout lire dans l'étendue
- Toutes les actions avec le fournisseur de réseau
- Toutes les actions avec le fournisseur de support
- Toutes les actions avec le fournisseur de ressources
Vous pouvez créer ce rôle à l'aide des scripts pour les rôles personnalisés ou via Microsoft Entra ID avec le processus décrit dans les Rôles personnalisés Azure, Azure RBAC.
Étape 2 : isoler l'infrastructure dans son propre groupe de ressources
En isolant les ressources réseau des ressources de calcul, de données ou de stockage, vous réduisez la probabilité d'une perte d'autorisations. En outre, en vous assurant que toutes les ressources associées se trouvent dans un groupe de ressources, vous pouvez effectuer une attribution de sécurité et mieux gérer la journalisation et la surveillance sur ces ressources.
Au lieu d'avoir les ressources du réseau Spoke disponibles dans plusieurs contextes dans un groupe de ressources partagées, créez un groupe de ressources dédiées. L'architecture de référence prise en charge par cet article illustre ce concept.
Dans la figure, les ressources et les composants de l'architecture de référence sont divisés en groupes de ressources dédiées pour les machines virtuelles, les comptes de stockage, les ressources de réseau virtuel Hub et les ressources de réseau virtuel Spoke.
Avec un groupe de ressources dédiées, vous pouvez attribuer un rôle personnalisé à l'aide du processus suivant : Tutoriel : accorder à un utilisateur l'accès aux ressources Azure à l'aide du Portail Azure : Azure RBAC.
Recommandations supplémentaires :
- Référencez un groupe de sécurité pour le rôle au lieu des personnes nommées.
- Gérez l'accès au groupe de sécurité via vos modèles de gestion des identités d'entreprise.
Si vous n'utilisez pas de stratégies qui appliquent la redirection des journaux sur les groupes de ressources, configurez ceci dans le journal d'activité pour le groupe de ressources : Naviguer vers Journal d'activité > Exporter les journaux d'activité et sélectionner + Ajouter un paramètre de diagnostic.
Dans l'écran Paramètres de diagnostic, sélectionnez toutes les catégories de journaux (en particulier Sécurité) et envoyez-les aux sources de journalisation appropriées, telles qu'un espace de travail Log Analytics pour l'observabilité ou un compte de stockage pour le stockage à long terme.
Démocratisation des abonnements
Vous devez planifier votre abonnement RBAC de la même manière, même si cette planification n'est pas directement liée à la mise en réseau. Outre l'isolation logique des ressources par groupe de ressources, vous devez également isoler l'abonnement en fonction des domaines d'activité et des propriétaires de portefeuille. L'abonnement en tant qu'unité de gestion doit avoir une étendue limitée.
Pour plus d'informations sur la démocratisation des abonnements, consultez les principes de conception des zones d'atterrissage Azure : Cloud Adoption Framework.
Vous configurez les diagnostics à partir de la catégorie Sécurité de Paramètre de diagnostic dans Azure Monitor, comme illustré ici.
Consultez Paramètres de diagnostic pour savoir comment consulter ces journaux et lancer des alertes.
Étape 3 : créer un groupe de sécurité réseau pour chaque sous-réseau
Les groupes de sécurité réseau Azure sont utilisés pour filtrer le trafic réseau entre les ressources Azure dans un réseau virtuel Azure. Il est recommandé d'appliquer un groupe de sécurité réseau à chaque sous-réseau, qui est appliqué par défaut via la stratégie Azure lors du déploiement des zones d'atterrissage Azure. Un groupe de sécurité réseau contient des règles de sécurité qui autorisent ou refusent le trafic réseau entrant ou sortant en direction/à partir des différents types de ressources Azure. Pour chaque règle, vous pouvez spécifier la source et la destination, le port et le protocole.
Pour une application basée sur des machines virtuelles multiniveau, il est recommandé de créer un groupe de sécurité réseau dédié (NSG dans la figure suivante) pour chaque sous-réseau qui héberge un rôle de machine virtuelle.
Comme le montre le diagramme :
- Chaque niveau de l'application est hébergé dans un sous-réseau dédié, à l'instar de la couche front-end, de la couche Application et la couche Données.
- Un groupe de sécurité réseau est configuré pour chacun de ces sous-réseaux.
La configuration des groupes de sécurité réseau selon une méthode différente de celle indiquée dans la figure peut entraîner une configuration incorrecte de certains ou de tous les groupes de sécurité réseau et peut créer des problèmes lors du dépannage. Elle peut également rendre difficile la surveillance et la journalisation.
Si vous devez créer un groupe de sécurité réseau, consultez Créer, modifier ou supprimer un groupe de sécurité réseau
Consultez les groupes de sécurité réseau pour comprendre comment les utiliser pour sécuriser l'environnement.
Étape 4 : créer un groupe de sécurité des applications pour chaque rôle de machine virtuelle
Les groupes de sécurité d'application permettent de configurer la sécurité réseau comme un prolongement naturel de la structure de l'application, et donc de regrouper les machines virtuelles et définir des stratégies de sécurité réseau basés sur ces groupes. Vous pouvez réutiliser votre stratégie de sécurité à grande échelle sans maintenance manuelle d'adresses IP explicites. La plateforme gère la complexité des adresses IP explicites et plusieurs ensembles de règles, ce qui vous permet de vous concentrer sur la logique métier.
À l'intérieur de votre charge de travail, identifiez les rôles de machine virtuelle spécifiques. Ensuite, créez un groupe de sécurité d'application pour chaque rôle. Dans l'architecture de référence, trois groupes de sécurité d'application sont représentés.
Comme le montre le diagramme :
- Trois groupes de sécurité d'application sont créés pour prendre en charge cette application, une pour chaque niveau : front-end, application et données.
- Chaque machine virtuelle est attribuée au groupe de sécurité d'application correspondant pour son rôle (texte rouge dans le diagramme).
Pour plus d'informations sur les groupes de sécurité des applications et sur la manière de les affecter aux machines virtuelles, consultez la vue d'ensemble des groupes de sécurité des applications Azure.
Remarque
Si vous utilisez des équilibreurs de charge, l'adresse IP de l'équilibreur de charge dans les groupes de sécurité réseau est requise, car les groupes de sécurité d'application ne peuvent pas étendre un équilibreur de charge.
Étape 5 : sécuriser le trafic et les ressources au sein du réseau virtuel
Cette section porte sur les recommandations suivantes :
- Déployer des règles de refus de base de référence pour les groupes de sécurité réseau
- Déployer des règles spécifiques à l'application pour les groupes de sécurité d'application
- Planifier le trafic de gestion dans le réseau virtuel
- Déployer la journalisation des flux du groupe de sécurité réseau
Déployer des règles de refus de base de référence pour les groupes de sécurité réseau
Un élément clé de Confiance Zéro est l'utilisation du privilège d'accès le plus bas possible. Les groupes de sécurité réseau disposent par défaut de règles d'autorisation. En ajoutant une base de référence de règles de refus, vous pouvez appliquer le niveau d'accès le moins élevé.
Une fois l'approvisionnement effectué, créez une règle de refus de tout dans chacune des règles de trafic entrant et sortant, avec une priorité de 4096. Il s'agit de la dernière priorité personnalisée disponible, ce qui signifie que vous disposez toujours de l'étendue restante pour configurer les actions d'autorisation.
Dans le groupe de sécurité réseau, accédez à Règles de sécurité sortantes, puis sélectionnez Ajouter. Renseignez les informations suivantes :
- Source : quelconque
- Plages de ports sources : *
- Destination : quelconque
- Service : Personnalisé
- Plages de ports de destination : *
- Protocole : quelconque
- Action : Deny
- Priorité : 4096
- Nom : DenyAllOutbound
- Description : refuse tout le trafic sortant, sauf s'il est spécifiquement autorisé.
Voici un exemple.
Répétez ce processus avec des règles de trafic entrant, en ajustant le nom et la description selon les besoins. Vous remarquerez que sous l'onglet Règles de sécurité de trafic entrant, il existe un signe d'avertissement sur la règle, comme indiqué ici.
Si vous cliquez sur la règle et faites défiler vers le bas, vous verrez plus de détails, comme indiqué ici.
Ce message affiche les deux avertissements suivants :
- Les équilibreurs de charge Azure ne pourront pas, par défaut, accéder aux ressources à l'aide ce groupe de sécurité réseau.
- D'autres ressources sur ce réseau virtuel ne pourront pas, par défaut, accéder aux ressources à l'aide de ce groupe de sécurité réseau.
Pour notre objectif dans Confiance Zéro, c'est ainsi que les choses doivent se passer. Cela signifie qu'il ne suffit pas que quelque chose se trouve sur ce réseau virtuel pour qu'elle ait un accès immédiat à vos ressources. Pour chaque modèle de trafic, créez une règle qui l'autorise explicitement, et ce avec le moins d'autorisations possible. Par conséquent, si vous avez des connexions sortantes spécifiques pour la gestion, telles que des contrôleurs de domaine Active Directory Domain Services (AD DS), des machines virtuelles DNS privées ou des sites Web externes spécifiques, ils doivent être contrôlés ici.
Autres règles de refus
Si vous utilisez un pare-feu Azure pour gérer vos connexions sortantes, au lieu d'effectuer un refus total de sortie, vous pouvez créer d'autres règles pour les connexions sortantes. Dans le cadre de l'implémentation de Pare-feu Azure, vous allez configurer une table de route qui envoie l'itinéraire par défaut (0.0.0.0/0) au pare-feu, qui gère le trafic en dehors du réseau virtuel.
Vous pouvez ensuite créer une règle de trafic sortant de réseau virtuel Refuser tout ou une règle de trafic sortant Autoriser tout (mais sécuriser les éléments à l'aide de leurs règles entrantes).
Pour en savoir plus sur Pare-feu Azure et les Tables de route, découvrez comment vous pouvez les utiliser pour renforcer la sécurité de l'environnement.
Règles de gestion des machines virtuelles
Pour configurer des machines virtuelles avec Microsoft Entra Login, Anti-Malware et les mises à jour automatiques activées, vous devez autoriser les connexions sortantes suivantes. La plupart d'entre elles sont de FQDN. Cela signifie que Pare-feu Azure est nécessaire pour les règles de FQDN, ou que vous allez rendre un plan plus complexe. Pare-feu Azure est recommandé.
Les connexions sortantes sont les suivantes :
- Sur le port 443 :
- enterpriseregistration.windows.net
- settings-win.data.microsoft.com
- sls.update.microsoft.com
- v10.events.data.microsoft.com
- login.microsoftonline.com
- pas.windows.net
- 169.254.169.254
- Sur le port 80 :
- ctldl.windowsupdate.com
- www.msftconnecttest.com
- Sur le port 123 :
- 40.119.6.228
- Sur le port 1688 :
- 40.83.235.53
Déployer des règles spécifiques à l'application pour les groupes de sécurité d'application
Définissez les modèles de trafic avec la quantité minimale d'autorisations et suivez uniquement les chemins d'accès explicitement autorisés. Voici un exemple de diagramme d'utilisation de groupes de sécurité d'application pour définir des modèles de trafic réseau dans les groupes de sécurité réseau pour un réseau virtuel Spoke utilisé avec un réseau virtuel Hub. Il s'agit de la configuration recommandée.
Voici un autre exemple de configuration pour un réseau virtuel autonome dans lequel le Web Application Firewall est placé dans le sous-réseau de la passerelle d'application du réseau virtuel Spoke.
Vous avez besoin des règles de groupe de sécurité réseau suivantes :
- Autorisation du trafic Internet dans le sous-réseau APP GW (HTTPS 443)
- Autorisation du trafic du sous-réseau APP GW vers les machines virtuelles de front-end (HTTPS 433).
- Autorisation du trafic de la couche des machines virtuelles front-end vers l'équilibreur de charge de la couche Application (HTTPS 443).
- Autoriser le trafic entre l'équilibreur de charge de la couche Application et les machines virtuelles de la couche Application (HTTPS 443).
- Autorisez le trafic des machines virtuelles de la couche Application vers l'équilibreur de charge de la couche Données (SQL 1433).
- Autoriser le trafic depuis l'équilibreur de charge de la couche Données vers les machines virtuelles de la couche Données (SQL 1433).
- Autoriser le trafic entre les machines virtuelles de la couche Données (SQL 1433)
Configurez d'abord le modèle SQL, puis répétez le processus avec les couches restantes. Les sections suivantes sont les configurations des règles qui limitent le trafic réseau pour une couche Application unique.
Règle 5 : autoriser le trafic des machines virtuelles de la couche Application vers l'équilibreur de charge de la couche Données (SQL 1433)
Dans le groupe de sécurité réseau du sous-réseau de la couche Application, accédez aux règles de sécurité entrantes, puis sélectionnez Ajouter. Remplissez la liste avec les éléments suivants :
- Source : Groupe de sécurité d'application
- Groupes de sécurité d'application source : sélectionnez le groupe de sécurité de la couche Application de votre entreprise
- Plages de ports sources : 1433 (parfois, le trafic source peut provenir de différents ports et si ce modèle se produit, vous pouvez ajouter des plages de ports sources à * pour autoriser n'importe quel port source. Le port de destination est plus significatif et certaines recommandations doivent toujours utiliser * pour le port source)
- Destination : Adresses IP
- Adresses IP de destination/plages CIDR : adresse IP explicite de l'équilibreur de charge
- Vous devez utiliser l'adresse IP explicite ici, car vous ne pouvez pas associer un équilibreur de charge à un groupe de sécurité d'application.
- Vous pouvez planifier votre schéma IP ou déployer l'équilibreur de charge et faire référence à l'adresse IP attribuée.
- Service : MS SQL
- Plages de ports de destination : celle-ci est automatiquement renseignée pour le port 1433
- Protocole : cette option est automatiquement sélectionnée pour TCP
- Action : Autoriser
- Priorité : une valeur comprise entre 100 et 4096. Vous pouvez commencer à 105.
- Nom : Allow-App-Tier-to-Data-LB-Inbound
- Description : autorise l'accès entrant à partir de l'équilibreur de charge de la couche Données aux machines virtuelles de la couche Application.
Une fois l'opération terminée, vous remarquerez qu'il existe une icône bleue pour les alertes d'information sur la règle. En cliquant sur la règle, le message suivant s'affiche :
- « Les règles utilisant des groupes de sécurité d'application peuvent uniquement être appliquées lorsque les groupes de sécurité d'application sont associés aux interfaces réseau sur le même réseau virtuel. »
Voici un exemple.
La règle s'applique uniquement lorsque ce groupe de sécurité d'application est utilisé dans ce réseau.
Enfin, dans le même groupe de sécurité réseau, accédez à Règles de sécurité sortantes, puis sélectionnez Ajouter. Remplissez la liste comme dans l'exemple, en remplaçant Trafic entrant par Trafic sortant.
Règle 6 : autoriser le trafic entre l'équilibreur de charge de la couche Données et les machines virtuelles de la couche Données (SQL 1433)
Dans le groupe de sécurité réseau du sous-réseau de la couche Données, accédez aux Règles de sécurité entrantes, puis sélectionnez Ajouter. Remplissez la liste avec les éléments suivants :
- Source : adresse IP
- Adresse IP source : l'adresse IP de l'équilibreur de charge
- Plage de ports sources : 1433
- Destination : groupe de sécurité d'application
- Groupes de sécurité des applications de destination : sélectionner le groupe de sécurité de votre application de la couche Données
- Service : MS SQL
- Plages de ports de destination : celle-ci est automatiquement renseignée pour le port 1433.
- Protocole : cette option est automatiquement sélectionnée pour TCP.
- Action : Autoriser
- Priorité : une valeur comprise entre 100 et 4096. Vous pouvez commencer à 105.
- Nom : Allow-SQL-LB-to-SQL-VMs-Inbound
- Description : permet l'accès entrant aux machines virtuelles du niveau de données basées sur SQL à partir de l'équilibreur de charge de la couche Données.
Dans le même groupe de sécurité réseau, accédez à Règles de sécurité sortantes, puis sélectionnez Ajouter. Remplissez la liste comme indiqué dans l'exemple, en remplaçant le trafic entrant par le trafic sortant.
Règle 7 : autoriser le trafic entre les machines virtuelles de la couche Données (SQL 1433)
Dans le groupe de sécurité réseau du sous-réseau de la couche Données, accédez aux Règles de sécurité entrantes, puis sélectionnez Ajouter. Remplissez la liste avec les éléments suivants :
- Source : Groupe de sécurité d'application
- Groupes de sécurité des applications de destination : sélectionner le groupe de sécurité de votre application de la couche Données
- Plage de ports sources : 1433
- Destination : groupes de sécurité des applications
- Groupes de sécurité des applications de destination : sélectionner le groupe de sécurité de votre application de la couche Données
- Service : MS SQL
- Plages de ports de destination : celle-ci est automatiquement renseignée pour le port 1433.
- Protocole : cette option est automatiquement sélectionnée pour TCP.
- Action : Autoriser
- Priorité : une valeur comprise entre 100 et 4096. Vous pouvez commencer à 105.
- Nom : Allow-SQL-VM-to-SQL-VM-Inbound
- Description : autorise l'accès entrant entre les machines virtuelles de la couche Données SQL.
Dans le même groupe de sécurité réseau, accédez à Règles de sécurité sortantes, puis sélectionnez Ajouter. Remplissez la liste en tant que liste précédente, en remplaçant le trafic entrant par le trafic sortant.
Avec ces trois règles, vous avez défini le modèle de connectivité Confiance Zéro pour un niveau d'application unique. Vous pouvez répéter ce processus si nécessaire pour des flux supplémentaires.
Planifier le trafic de gestion dans le réseau virtuel
Outre le trafic spécifique à l'application, vous devez planifier le trafic de gestion. Toutefois, le trafic de gestion provient souvent de l'extérieur du réseau virtuel Spoke. Des règles supplémentaires sont requises. Vous devez tout d'abord comprendre les ports et sources spécifiques dont le trafic de gestion provient. En règle générale, tout le trafic de gestion doit partir d'un pare-feu ou d'une autre appliance virtuelle réseau (NVA) située dans le réseau Hub pour le Spoke.
Consultez l'architecture de référence complète dans l'article Appliquer les principes Confiance Zéro à l'article de présentation d'Azure IaaS.
Cela varie en fonction de vos besoins de gestion spécifiques. Toutefois, il convient d'utiliser les règles des pare-feu et du groupe de sécurité réseau pour autoriser explicitement les connexions tant du côté du réseau de la plateforme que du côté du réseau de la charge de travail.
Déployer la journalisation des flux du groupe de sécurité réseau
Même si votre groupe de sécurité réseau bloque le trafic inutile ne signifie pas que vos objectifs sont atteints. Vous devez toujours observer le trafic qui se produit en dehors de vos modèles explicites afin de savoir si une attaque se produit.
Pour activer la journalisation de flux de groupe de sécurité réseau, vous pouvez suivre le Tutoriel : journaliser le flux de trafic réseau vers et à partir d'une machine virtuelle sur le groupe de sécurité réseau existant créé.
Remarque
- Le compte de stockage doit suivre les instructions du compte de stockage Confiance Zéro.
- L'accès aux journaux doit être limité en fonction des besoins.
- Ils doivent également se connecter à Analytique des journaux d'activité et Sentinel en fonction des besoins.
Étape 6 : sécuriser l'accès au réseau virtuel et à l'application
Sécurisation de l'accès au réseau virtuel et à l'application inclut :
- La sécurisation du trafic dans l'environnement Azure vers l'application.
- Recours aux stratégies de Multi-Factor Authentication et d'accès conditionnel pour fournir un accès sécurisé aux applications.
Le diagramme suivant présente les deux modes d'accès sur l'architecture de référence.
Sécuriser le trafic dans l'environnement Azure pour le réseau virtuel et l'application
Une grande partie du travail du trafic de sécurité dans l'environnement Azure est déjà terminée. Les connexions sécurisées entre les ressources de stockage et les machines virtuelles sont configurées dans Appliquer les principes de Confiance Zéro au stockage Azure.
Pour sécuriser l'accès des ressources Hub au réseau virtuel, consultez Appliquer les principes de Confiance Zéro à un réseau virtuel hub dans Azure.
Utilisez les stratégies d’authentification multifacteur et d’accès conditionnel pour fournir à l’utilisateur un accès à l’application
L'article, Appliquer les principes de Confiance Zéro aux machines virtuelles recommande de protéger les demandes d'accès directement aux machines virtuelles avec Multi-Factor Authentication et l'accès conditionnel. Ces demandes sont probablement envoyées par les administrateurs et les développeurs. L'étape suivante consiste à sécuriser l'accès à l'application avec Multi-Factor Authentication et l'accès conditionnel. Cela s'applique à tous les utilisateurs qui accèdent à l'application.
Dabord, si l'application n'est pas encore intégrée à Microsoft Entra ID, consultez Types d'application pour la plateforme d'identités Microsoft.
Ensuite, ajoutez l'application à l'étendue de vos stratégies d'accès aux identités et aux appareils.
Lors de la configuration de l'authentification multifacteur avec l'accès conditionnel et les stratégies associées, utilisez l'ensemble de stratégies recommandé pour Confiance Zéro comme guide. Cela inclut des stratégies de « point de départ » qui ne nécessitent pas de gestion des appareils. Dans le meilleur des cas, les appareils accédant à vos machines virtuelles sont gérés et vous pouvez implémenter le niveau « Entreprise », qui est recommandé pour Confiance Zéro. Pour plus d'informations, consultez Stratégies d'accès courantes aux appareils et aux identités de Confiance Zéro.
Le diagramme suivant indique les stratégies recommandées pour Confiance Zéro.
Étape 7 : activer la détection et la protection avancées des menaces
Il se peut que votre réseau virtuel Spoke créé sur Azure soit déjà protégé par Microsoft Defender pour le cloud (MDC), car d'autres ressources de votre environnement d'entreprise informatique fonctionnant sur Azure ou localement peuvent également être protégées.
Comme mentionné dans les autres articles de cette série, Microsoft Defender pour le cloud est un outil de gestion de la posture de sécurité cloud (CSPM) et de protection de charge de travail cloud et Cloud (CWP) qui formule des recommandations en matière de sécurité, d'alertes et de fonctions avancées à l'instar de la sécurisation renforcée du réseau adaptatif pour vous aider à progresser dans votre parcours de sécurité cloud. Pour mieux visualiser l'emplacement où Defender pour le cloud s'intègre dans le plus grand paysage de sécurité Microsoft, consultez Architecture de référence de Microsoft pour la cybersécurité.
Cet article traite uniquement de Microsoft Defender pour le cloud. Toutefois, il est important de comprendre que Microsoft Defender pour le cloud fonctionne sur la base des stratégies Azure et des journaux ingérés dans l'espace de travail Log Analytics. Une fois activée sur le(s) abonnement(s) avec votre réseau virtuel Spoke et les ressources associées, vous pourrez consulter des recommandations pour améliorer leur état de la sécurité. Vous pouvez filtrer ces recommandations plus loin par la tactique MITRE, le groupe de ressources, etc. Accordez la priorité à la mise en œuvre des recommandations qui ont un impact plus important sur le niveau de sécurité de votre organisation.
Voici un exemple dans le portail Microsoft Defender pour le cloud.
Si vous choisissez d'intégrer l'un des plans Defender pour le cloud qui offrent des protections avancées des charges de travail, il inclut des recommandations de sécurisation renforcée du réseau adaptatif pour améliorer vos règles de groupe de sécurité réseau existantes. Voici un exemple.
Vous pouvez accepter la recommandation en sélectionnant Appliquer, ce qui crée une règle de groupe de sécurité réseau ou modifie une règle existante.
Recommandé pour la formation
- Sécuriser vos ressources Azure avec le contrôle d'accès en fonction du rôle Azure (Azure RBAC)
- Configurer et gérer Azure Monitor
- Configurer des groupes de sécurité réseau
- Conception et implémentation de la sécurité réseau
- Sécurisez l'accès à vos applications à l'aide des services d'identité Azure
Pour plus de formation sur la sécurité dans Azure, consultez ces ressources dans le catalogue Microsoft :
Sécurité dans Azure | Microsoft Learn
Étapes suivantes
Consultez ces articles supplémentaires pour appliquer les principes de Confiance Zéro à Azure :
- Vue d'ensemble d'IaaS
- Azure Virtual Desktop
- Azure Virtual WAN
- Applications IaaS dans Amazon Web Services
- Microsoft Sentinel et Microsoft Defender XDR
Illustrations techniques
Cette affiche fournit une vue d'ensemble, sur une seule page, des composants d'Azure IaaS en tant qu'architectures de référence et logiques, ainsi que les étapes permettant de s'assurer que ces composants ont les principes « ne jamais faire confiance, toujours vérifier » du modèle de Confiance Zéro appliqué.
| Élément | Description |
|---|---|
 PDF | Visio Mise à jour : mars 2024 |
Utilisez cette illustration avec cet article : Appliquer les principes de Confiance Zéro à Azure IaaS Guides de solution connexes |
Cette affiche fournit les architectures de référence et logiques et les configurations détaillées des composants distincts de Confiance Zéro pour Azure IaaS. Utilisez les pages de cette affiche pour des services informatiques ou des spécialités distinctes ou, avec la version Microsoft Visio du fichier, puis personnalisez les diagrammes pour votre infrastructure.
| Élément | Description |
|---|---|
 PDF | Visio Mise à jour : mars 2024 |
Utilisez ces diagrammes avec les articles, en commençant par celui-ci : Appliquer les principes de Confiance Zéro à Azure IaaS Guides de solution connexes |
Pour obtenir des illustrations techniques supplémentaires, cliquez ici.
Références
- Adopter une sécurité proactive avec une Confiance Zéro
- Sécuriser les réseaux avec la Confiance Zéro
- Réseau de Confiance zéro pour les applications Web avec le pare-feu Azure et l'Application Gateway : centre des architectures Azure
- Stratégies de zone d'atterrissage Azure
- Stratégies d'accès courantes aux appareils et aux identités de Confiance Zéro
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour