Appliquer les principes Confiance Zéro à un réseau virtuel spoke avec les services PaaS d'Azure
Cet article vous aide à appliquer les principes du modèle de sécurité Confiance Zéro à une charge de travail PaaS à l'aide de réseaux virtuels Azure et de points de terminaison privés 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 la détection des menaces dans le pare-feu Azure et Azure Application Gateway pour valider le trafic et vérifier si le trafic est acceptable. |
| 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. | Réduisez l'entrée et la sortie des services Azure vers votre réseau privé. Utilisez des groupes de sécurité réseau pour autoriser uniquement des entrées spécifiques à partir de votre réseau virtuel. Utilisez une instance du pare-feu Azure centrale pour accorder au trafic de réseau virtuel un accès au service Azure. |
| 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. Vérifiez que vous êtes connecté à partir de 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. |
Pour plus d'informations sur l'application des principes de Confiance Zéro dans un environnement IaaS Azure, consultez la vue d'ensemble Appliquer les principes de Confiance Zéro à Azure IaaS.
Réseau autonome ou rayon Confiance Zéro pour les services PaaS Azure
De nombreux services PaaS contiennent leurs propres fonctionnalités de contrôle d'entrée et de sortie natives du service. Vous pouvez utiliser ces contrôles pour sécuriser l'accès réseau aux ressources du service PaaS sans avoir besoin d'infrastructure telle que des réseaux virtuels. Par exemple :
- La base de données Azure SQL possède son propre pare-feu qui peut être utilisé pour autoriser des adresses IP clientes spécifiques qui doivent accéder au serveur de base de données.
- Les comptes de stockage Azure ont une option de configuration permettant d'autoriser les connexions à partir d'un réseau virtuel spécifique ou de bloquer l'accès au réseau public.
- Azure App Service prend en charge les restrictions d'accès pour définir une liste verte/d'exclusion classée par ordre de priorité qui contrôle l'accès réseau à votre application.
Toutefois, pour les implémentations guidées de la Confiance Zéro, ces contrôles d'accès natifs du service sont souvent insuffisants. Cela crée une diffusion des contrôles d'accès et de la journalisation qui peuvent augmenter la gestion et réduire la visibilité.
En outre, les services PaaS peuvent utiliser des noms de domaine complets (FQDN) qui se résolvent en une adresse IP publique affectée dynamiquement à partir d'un pool d'adresses IP publiques dans une région spécifique pour un type de service. En raison de cela, vous ne pourrez pas autoriser le trafic depuis ou vers un service PaaS spécifique à l'aide de leur adresse IP publique, qui peut changer.
Microsoft recommande d'utiliser des points de terminaison privé. Un point de terminaison privé est une interface de réseau virtuel qui utilise une adresse IP privée de votre réseau virtuel. Cette interface réseau vous connecte de manière privée et sécurisée à un service fonctionnant avec Azure Private Link. Vous placez le service dans votre réseau virtuel en activant un point de terminaison privé.
Selon votre scénario de solution, vous pouvez toujours avoir besoin d'un accès entrant public à vos services PaaS. Mais sauf si vous le faites, Microsoft recommande que tout le trafic reste privé pour éliminer les risques de sécurité potentiels.
Ce guide fournit des instructions pour une architecture de référence spécifique, mais les principes et méthodes peuvent être appliqués à d'autres architectures en fonction des besoins.
Architecture de référence
Le diagramme suivant illustre une architecture de référence commune pour les charges de travail PaaS.
Comme le montre le diagramme :
- Un réseau virtuel Spoke inclut des composants pour prendre en charge une application PaaS.
- L'application PaaS est une application à deux niveaux tirant parti des services d'application Azure pour une application web/front-end et une base de données Azure SQL pour les bases de données relationnelles.
- Chaque niveau est contenu dans un sous-réseau dédié pour l'entrée avec un groupe de sécurité réseau dédié.
- Le niveau web contient un sous-réseau dédié pour la sortie.
- L'accès à l'application est fourni via une passerelle Application Gateway contenue dans son propre sous-réseau.
Le diagramme suivant montre l'architecture logique de ces composants au sein d'un abonnement Azure.
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 (nommés « NSG » dans le diagramme) pour la base de données, l'application et les niveaux front-end
- Deux groupes de sécurité d'application (nommés « ASG » dans le diagramme)
- Deux points de terminaison privés
En outre, les ressources du réseau virtuel Hub sont déployées dans l'abonnement de connectivité approprié.
Que contient cet article ?
Les principes de Confiance Zéro sont appliqués dans l'architecture, du locataire 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 |
|---|---|
| 1 | Tirer parti du RBAC de Microsoft Entra ou configurer des rôles personnalisés pour les ressources réseau |
| 2 | Isolez l'infrastructure dans son propre groupe de ressources. |
| 3 | Créez un groupe de sécurité réseau pour chaque sous-réseau. |
| 4 | Sécurisez le trafic et les ressources au sein du réseau virtuel :
|
| 5 | Sécurisez l'entrée et la sortie pour les services PaaS Azure. |
| 6 | Sécurisez l'accès au réseau virtuel et à l'application. |
| 7 | Activez la détection, l'avertissement et la protection avancées des menaces. |
Ce guide part du principe que vous disposez déjà d'un service d'application Azure et d'une base de données Azure SQL déployés dans leurs propres groupes de ressources.
Étape 1 : tirer parti du RBAC de Microsoft Entra ou configurer des rôles personnalisés pour les ressources réseau
Vous pouvez tirer parti des rôles intégrés à Microsoft Entra RBAC pour les contributeurs réseau. Toutefois, une autre approche consiste à tirer parti des rôles personnalisés. Les gestionnaires de réseau virtue Spoke n'ont pas besoin d'un contrôle total aux ressources réseau accordées par le rôle Contributeur réseau Microsoft Entra RBAC, mais ont besoin de plus d'autorisations que d'autres rôles courants. Un rôle personnalisé peut être utilisé 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 qui peut être utilisé est le rôle personnalisé Gestion du réseau, qui dispose des 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
Ce rôle peut être créé à l'aide des scripts dans le référentiel GitHub de l'architecture de référence de zone d'atterrissage Azure ou peut être créé via Microsoft Entra ID avec les rôles personnalisés Azure.
É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. Le diagramme d’architecture suivant illustre cette configuration.
Dans le diagramme, les ressources et les composants de l'architecture de référence sont divisés en groupes de ressources dédiées pour les services d'application, les bases de données Azure SQL, 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 tutoriel Accorder à un utilisateur l'accès aux ressources Azure à l'aide du portail Azure.
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 pratiques de gestion des identités d'entreprise.
Si vous n’utilisez pas de stratégies qui appliquent le transfert de journal sur les groupes de ressources, configurez ce qui suit dans le journal d’activité du groupe de ressources :
- Accédez au groupe de ressources dans le portail Microsoft Azure.
- Accédez à Journal d'activité -> Exporter les journaux d'activité, puis sélectionnez + 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. Voici un exemple :
Consultez Paramètres de diagnostic pour savoir comment consulter ces journaux et lancer des alertes.
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, consultez Principes de conception des zones d’atterrissage Azure.
É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. Nous vous recommandons d’appliquer un groupe de sécurité réseau à chaque sous-réseau. Cette mesure est appliquée par défaut via la stratégie Azure lors du déploiement de 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 des adresses IP source et de destination, un protocole (tel que TCP ou UDP) et un port.
Pour les applications avec plusieurs niveaux, il est recommandé de créer un groupe de sécurité réseau dédié (« NSG » dans le diagramme suivant) pour chaque sous-réseau qui héberge un composant réseau.
Comme le montre le diagramme :
- Chaque niveau de l'application a un sous-réseau d'entrée dédié, par exemple un pour le niveau web et un autre pour le niveau des données.
- Les services Azure Application disposent d'un sous-réseau de sortie dédié pour un service d'application spécifique.
- 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 le diagramme 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.
Consultez Créer, modifier ou supprimer un groupe de sécurité réseau Azure pour gérer les paramètres de vos groupes de sécurité réseau.
En savoir plus sur les groupes de sécurité réseau pour comprendre comment ils peuvent être utilisés pour sécuriser vos environnements.
Étape 4 : sécuriser le trafic et les ressources au sein du réseau virtuel
Cette section décrit les recommandations suivants :
- 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
- 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 le provisionnement effectué, créez une règle Refuser 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.
Pour ce faire, 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.
L'onglet Règles de sécurité entrantes affiche un signe d'avertissement sur la règle. Voici un exemple.
Cliquez sur la règle et faites défiler vers le bas pour afficher plus de détails. Voici un exemple :
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 que ce n'est pas parce qu'un objet se trouve sur ce réseau virtuel, ne signifie pas qu'il aura 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.
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
Remarque
Les recommandations de cette section s'appliquent uniquement au sous-réseau de sortie web.
Si vous utilisez le Pare-feu Azure pour gérer vos connexions sortantes, au lieu d’effectuer un deny-outbound-all (refuser tout le trafic sortant), vous pouvez créer d’autres règles pour les connexions sortantes. Dans le cadre de l'implémentation du pare-feu Azure, vous configurez une table de route qui envoie l'itinéraire par défaut (0.0.0.0/0) au pare-feu. Cela 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.
Consultez Pare-feu Azure et Tables de route pour découvrir comment vous pouvez les utiliser pour renforcer la sécurité de l'environnement.
Déployer des règles spécifiques à l'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. À l'aide de sous-réseaux comme sources, définissez des modèles de mise en réseau dans les groupes de sécurité réseau. Voici un exemple.
Utilisez le processus Gérer les groupes de sécurité réseau : créer une règle de sécurité pour ajouter des règles à vos groupes de sécurité réseau.
Pour sécuriser ce scénario, ajoutez les règles suivantes :
| Groupe de sécurité réseau pour le sous-réseau | Sens | Source | Détails de la source | Port source | Destination | Détails de la destination | Service | Nom du groupe de sécurité réseau | Description du groupe de sécurité réseau |
|---|---|---|---|---|---|---|---|---|---|
| Sous-réseau App Service | Entrante | Adresses IP | Plage d'adresses IP privées de votre sous-réseau Application Gateway | 443 | Adresses IP | L'adresse IP explicite du point de terminaison privé de votre App Service | MS SQL | AllowGWtoAppInbound | Autorise l'accès entrant à App Service à partir d'Application Gateway. |
| Sous-réseau de l'intégration d'App Service : | Règle de trafic sortant | Adresses IP | Plage d'adresses IP de votre sous-réseau d'intégration App Service | 1433 | Adresses IP | L'adresse IP explicite du point de terminaison privé de votre DB SQL | MS SQL | AllowApptoSQLDBOutbound | Autorise l'accès sortant au point de terminaison privé SQL à partir du sous-réseau d'intégration App Service. |
| Sous-réseau Azure SQL | Entrante | Adresses IP | Plage d'adresses IP de votre sous-réseau d'intégration App Service | 1433 | Adresses IP | L'adresse IP explicite du point de terminaison privé de votre DB SQL | MS SQL | AllowApptoSQLDBInbound | Autorise l'accès entrant au point de terminaison privé SQL à partir du sous-réseau d'intégration App Service. |
Remarque
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 important et certaines recommandations sont d'utiliser toujours « * » pour le port source.
Remarque
Pour la priorité, utilisez une valeur entre 100 et 4000. Vous pouvez commencer à 105.
Cela s'ajoute aux règles de groupe de sécurité réseau sur votre sous-réseau Application Gateway.
Avec ces 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, planifiez le trafic de gestion. Toutefois, étant donné que le trafic de gestion provient généralement de l'extérieur du réseau virtuel Spoke, d'autres règles sont requises. Vous devez tout d'abord comprendre les ports et sources spécifiques d'où 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é dans le réseau Hub pour le Spoke.
Consultez Appliquer les principes de Confiance Zéro à Azure IaaS pour l'architecture de référence complète.
Votre configuration varie en fonction de vos besoins de gestion spécifiques. Toutefois, vous devez utiliser des règles sur des appliances de pare-feu et des règles sur un 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.
Planification des déploiements
Étant donné que vos services et bases de données d'application utilisent désormais la mise en réseau privée, planifiez le fonctionnement des déploiements de code et de données sur ces ressources. Ajoutez des règles pour autoriser vos serveurs de build privés à accéder à ces points de terminaison.
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, cela ne signifie pas que vos objectifs sont atteints. Pour détecter une attaque, vous devez quand même observer le trafic qui se produit en dehors de vos modèles explicites.
Le trafic vers les points de terminaison privés n'est pas journalisé, mais si d'autres services sont déployés sur les sous-réseaux ultérieurement, ce journal permet de détecter les activités.
Pour activer la journalisation de flux de groupe de sécurité réseau, suivez le Tutoriel : journaliser le flux de trafic réseau vers et à partir d'une machine virtuelle pour le groupe de sécurité réseau existant pour les points de terminaison privés.
Remarque
Gardez à l'esprit les recommandations suivantes :
Vous devez restreindre l'accès aux journaux en fonction des besoins.
Les journaux doivent être transmis à Log Analytics et Microsoft Sentinel en fonction des besoins.
Étape 5 : sécuriser l'entrée et la sortie pour les services PaaS Azure
Cette section contient deux étapes nécessaires pour sécuriser l'entrée et la sortie de vos services PaaS :
- Déployez des points de terminaison privés pour l'entrée sur vos services.
- Déployez l'intégration au réseau virtuel pour permettre à votre service d'application de communiquer avec votre réseau virtuel.
En outre, vous devez également prendre en compte votre configuration DNS pour permettre la résolution des noms.
Déployer des points de terminaison privés pour l'entrée
Bien que de nombreux services vous permettent de créer des points de terminaison privés à partir du panneau spécifique à la ressource dans le portail Azure, une expérience plus cohérente consiste à créer un point de terminaison privé à partir de sa propre création de ressources. Pour ce faire, les ressources doivent déjà être déployées. Une fois déployées, vous pouvez créer le point de terminaison privé.
Lors du déploiement des points de terminaison privés, configurez-les comme suit :
- Placez-les dans le groupe de ressources spécifique qui héberge les ressources parentes pour conserver les ressources avec un cycle de vie similaire et fournir un accès central.
- Placez-les dans le sous-réseau approprié dans le réseau virtuel en fonction de leur rôle.
- Pour le service d'application Azure, vous pouvez configurer des points de terminaison privés pour son front-end normal et son point de terminaison SCM, qui est utilisé pour les déploiements et la gestion.
En outre, dans le cadre de ce déploiement, vous devez vous assurer que le pare-feu spécifique au service est défini pour refuser le trafic entrant. Cela empêchera toutes les tentatives d'entrée publique.
Pour la base de données Azure SQL, gérez ses règles de pare-feu IP au niveau du serveur. Vérifiez que l'accès au réseau public est défini sur Désactiver à partir du panneau réseau dans le portail Azure.
Pour le service d'application Azure, l'ajout du point de terminaison privé définit son pare-feu au niveau du service pour bloquer l'accès entrant par défaut. Pour plus d'informations, consultez Utiliser des points de terminaison privés pour les application App service.
Déployer l'intégration au réseau virtuel pour la sortie
En plus des points de terminaison privés pour l'entrée, activez l'intégration au réseau virtuel. Chaque plan App Service peut activer l'intégration au réseau virtuel et allouer ainsi un sous-réseau entier pour App Service. Pour plus d'informations, consultez Intégrer votre application à un réseau virtuel Azure.
Pour configurer votre App Service, consultez Activer l'intégration au réseau virtuel dans Azure App Service. Vérifiez que vous le placez dans votre sous-réseau désigné pour la sortie.
Considérations relatives au DNS
Dans le cadre de l'utilisation de points de terminaison privés, activez la résolution DNS des noms de domaine complets des ressources sur leurs nouvelles adresses IP privées. Pour obtenir des instructions pour implémenter cela de différentes façons, consultez Configuration DNS du point de terminaison privé.
Remarque
La résolution DNS doit s'appliquer à tout le trafic. Les ressources du même réseau virtuel ne pourront pas être résolues, sauf si elles utilisent les zones DNS appropriées.
Étape 6 : sécuriser l'accès au réseau virtuel et à l'application
La sécurisation de l'accès au réseau virtuel et aux applications inclut :
- La sécurisation du trafic dans l'environnement Azure vers l'application
- Utilisation de stratégies d’authentification multifacteur (MFA) et d’accès conditionnel pour l’accès utilisateur 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. Consultez Appliquer les principes de Confiance Zéro au stockage Azure pour configurer les connexions sécurisées antre les ressources de stockage et les machines virtuelles.
Consultez Appliquer les principes de Confiance Zéro à un réseau virtuel Hub dans Azure pour sécuriser l'accès des ressources Hub au réseau virtuel.
Utiliser des stratégies d'authentification multifacteur et d'accès conditionnel pour l'accès des utilisateurs aux applications
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 l'authentification multifacteur 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 aux applications avec l'authentification multifacteur 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 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, 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é, des alertes et des fonctions avancées à l'instar de la sécurisation renforcée du réseau adaptatif pour vous aider tout au long dans votre parcours de sécurité cloud.
Bien que cet article ne décrive pas Defender pour le cloud en détail, vous devez comprendre que Defender pour le cloud est basé sur des stratégies Azure et des journaux ingérés dans un espace de travail Log Analytics. Une fois activé sur les abonnements 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 davantage par tactique MITRE, groupe de ressources et autres. Envisagez de hiérarchiser les recommandations qui ont un impact plus important sur le niveau de sécurité de votre organisation. Voici un exemple.
Il existe des plans Defender pour le cloud qui offrent des protections avancées de charge de travail incluant des recommandations de renforcement 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éera 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
- Concevoir et implémenter un accès privé aux services Azure
Étapes suivantes
Consultez ces articles supplémentaires pour appliquer les principes de Confiance Zéro à Azure :
- Pour Azure IaaS :
- Azure Virtual Desktop
- Azure Virtual WAN
- Applications IaaS dans Amazon Web Services
- Microsoft Sentinel et Microsoft Defender XDR
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 Confiance Zéro pour les applications web avec le pare-feu Azure et Application Gateway
- Stratégies de zone d'atterrissage Azure
- Stratégies d'accès courantes aux appareils et aux identités Confiance Zéro
- Qu'est-ce qu'un point de terminaison privé ?
- Configuration DNS des points de terminaison privés
- Intégrer votre application à un réseau virtuel Azure
- Utilisation de points de terminaison privés pour les applications App Service
- Se connecter à un serveur Azure SQL avec un point de terminaison privé Azure