Recommandations pour la création d’une stratégie de segmentation
S’applique à la recommandation de liste de contrôle de sécurité Well-Architected Framework :
| SE :04 | Créez une segmentation et des périmètres intentionnels dans la conception de votre architecture et l’empreinte de la charge de travail sur la plateforme. La stratégie de segmentation doit inclure les réseaux, les rôles et les responsabilités, les identités de charge de travail et les organization de ressources. |
|---|
Un segment est une section logique de votre solution qui doit être sécurisée en tant qu’unité. Une stratégie de segmentation définit la façon dont une unité doit être séparée des autres unités avec son propre ensemble d’exigences et de mesures de sécurité.
Ce guide décrit les recommandations pour la création d’une stratégie de segmentation unifiée. En utilisant des périmètres et des limites d’isolation dans les charges de travail, vous pouvez concevoir une approche de sécurité qui vous convient.
Définitions
| Terme | Définition |
|---|---|
| Containment | Technique permettant de contenir le rayon d’explosion si un attaquant accède à un segment. |
| Accès aux privilèges minimum | Un Confiance nulle principe qui vise à réduire au minimum un ensemble d’autorisations pour effectuer une fonction de travail. |
| Périmètre | Limite d’approbation autour d’un segment. |
| Organisation des ressources | Stratégie de regroupement des ressources associées par flux au sein d’un segment. |
| Rôle | Ensemble d’autorisations nécessaires à l’exécution d’une fonction de travail. |
| Segment | Unité logique isolée des autres entités et protégée par un ensemble de mesures de sécurité. |
Stratégies de conception
Le concept de segmentation est couramment utilisé pour les réseaux. Toutefois, le même principe sous-jacent peut être utilisé dans l’ensemble d’une solution, y compris la segmentation des ressources à des fins de gestion et de contrôle d’accès.
La segmentation vous aide à concevoir une approche de sécurité qui applique une défense en profondeur en fonction des principes du modèle Confiance nulle. Assurez-vous qu’un attaquant qui enfreint un segment réseau ne peut pas accéder à un autre en segmentant les charges de travail avec différents contrôles d’identité. Dans un système sécurisé, les attributs d’identité et de réseau bloquent l’accès non autorisé et masquent l’exposition des ressources. Voici quelques exemples de segments :
- Abonnements qui isolent les charges de travail d’un organization
- Groupes de ressources qui isolent les ressources de charge de travail
- Environnements de déploiement qui isolent le déploiement par phases
- Équipes et rôles qui isolent les fonctions de travail liées au développement et à la gestion des charges de travail
- Niveaux Application qui isolent par utilitaire de charge de travail
- Microservices qui isolent un service d’un autre
Tenez compte de ces éléments clés de segmentation pour vous assurer que vous créez une stratégie de défense complète en profondeur :
La limite ou le périmètre est le bord d’entrée d’un segment où vous appliquez des contrôles de sécurité. Les contrôles de périmètre doivent bloquer l’accès au segment, sauf autorisation explicite. L’objectif est d’empêcher un attaquant de traverser le périmètre et de prendre le contrôle du système. Par exemple, une couche Application peut accepter le jeton d’accès d’un utilisateur final lorsqu’il traite une demande. Toutefois, la couche Données peut nécessiter un jeton d’accès différent qui a une autorisation spécifique, que seule la couche Application peut demander.
L’endiguement est le bord de sortie d’un segment qui empêche le mouvement latéral dans le système. L’objectif de l’endiguement est de minimiser l’effet d’une violation. Par exemple, un réseau virtuel Azure peut être utilisé pour configurer le routage et les groupes de sécurité réseau afin d’autoriser uniquement les modèles de trafic que vous attendez, en évitant le trafic vers des segments réseau arbitraires.
L’isolation est la pratique qui consiste à regrouper des entités avec des garanties similaires afin de les protéger avec une limite. L’objectif est la facilité de gestion et l’endiguement d’une attaque au sein d’un environnement. Par exemple, vous pouvez regrouper les ressources liées à une charge de travail spécifique dans un abonnement Azure, puis appliquer le contrôle d’accès afin que seules des équipes de charge de travail spécifiques puissent accéder à l’abonnement.
Il est important de noter la distinction entre les périmètres et l’isolation. Le périmètre fait référence aux points d’emplacement qui doivent être vérifiés. L’isolation concerne le regroupement. Contenir activement une attaque en utilisant ces concepts ensemble.
L’isolation ne signifie pas la création de silos dans le organization. Une stratégie de segmentation unifiée assure l’alignement entre les équipes techniques et définit des lignes de responsabilité claires. Clarity réduit le risque d’erreurs humaines et de défaillances d’automatisation qui peuvent entraîner des failles de sécurité, des temps d’arrêt des opérations ou les deux. Supposons qu’une violation de la sécurité soit détectée dans un composant d’un système d’entreprise complexe. Il est important que tout le monde comprenne qui est responsable de cette ressource afin que la personne appropriée soit incluse dans l’équipe de triage. Les organization et les parties prenantes peuvent rapidement identifier comment répondre à différents types d’incidents en créant et en documentant une bonne stratégie de segmentation.
Compromis : la segmentation introduit une complexité, car il y a une surcharge dans la gestion. Il y a également un compromis en termes de coût. Par exemple, davantage de ressources sont approvisionnées lorsque les environnements de déploiement qui s’exécutent côte à côte sont segmentés.
Risque : la micro-segmentation au-delà d’une limite raisonnable perd l’avantage de l’isolation. Lorsque vous créez trop de segments, il devient difficile d’identifier les points de communication ou d’autoriser des chemins de communication valides au sein du segment.
L’identité comme périmètre
Diverses identités, telles que des personnes, des composants logiciels ou des appareils, accèdent aux segments de charge de travail. L’identité est un périmètre qui doit être la ligne de défense principale pour authentifier et autoriser l’accès au-delà des limites d’isolation, quel que soit l’origine de la demande d’accès. Utilisez l’identité comme périmètre pour :
Attribuer l’accès par rôle. Les identités ont uniquement besoin d’accéder aux segments requis pour effectuer leur travail. Réduisez l’accès anonyme en comprenant les rôles et les responsabilités de l’identité demande afin de connaître l’entité qui demande l’accès à un segment et dans quel but.
Une identité peut avoir des étendues d’accès différentes dans différents segments. Envisagez une configuration d’environnement classique, avec des segments distincts pour chaque étape. Les identités associées au rôle de développeur ont un accès en lecture-écriture à l’environnement de développement. À mesure que le déploiement passe à la préproduction, ces autorisations sont freinées. Au moment où la charge de travail est promue en production, l’étendue pour les développeurs est réduite à l’accès en lecture seule.
Considérez les identités d’application et de gestion séparément. Dans la plupart des solutions, les utilisateurs ont un niveau d’accès différent de celui des développeurs ou des opérateurs. Dans certaines applications, vous pouvez utiliser différents systèmes d’identité ou répertoires pour chaque type d’identité. Envisagez d’utiliser des étendues d’accès et de créer des rôles distincts pour chaque identité.
Attribuez l’accès au moindre privilège. Si l’accès à l’identité est autorisé, déterminez le niveau d’accès. Commencez par le privilège minimum pour chaque segment et élargissez cette étendue uniquement si nécessaire.
En appliquant le privilège minimum, vous limitez les effets négatifs si l’identité est compromise. Si l’accès est limité par le temps, la surface d’attaque est encore réduite. L’accès limité dans le temps s’applique particulièrement aux comptes critiques, tels que les administrateurs ou les composants logiciels qui ont une identité compromise.
Le contrôle d’accès en fonction du rôle (RBAC) entraîne également une surcharge de gestion. Le suivi des identités et de leurs étendues d’accès peut devenir complexe dans les attributions de rôles. La solution de contournement consiste à attribuer des rôles à des groupes de sécurité plutôt qu’à des identités individuelles.
Pour plus d’informations sur les contrôles d’identité, consultez Gestion des identités et des accès.
Contrairement aux contrôles d’accès réseau, l’identité valide le contrôle d’accès au moment de l’accès. Il est fortement recommandé d’effectuer une révision régulière de l’accès et d’exiger un workflow d’approbation pour obtenir des privilèges pour les comptes à impact critique. Par exemple, consultez Modèles de segmentation d’identité.
Mise en réseau en tant que périmètre
Les périmètres d’identité sont indépendants du réseau, tandis que les périmètres réseau augmentent l’identité, mais ne la remplacent jamais. Les périmètres réseau sont établis pour contrôler le rayon d’explosion, bloquer les accès inattendus, interdits et non sécurisés, et obfusquer les ressources de charge de travail.
Bien que le principal objectif du périmètre d’identité soit le privilège minimum, vous devez supposer qu’il y aura une violation lorsque vous concevez le périmètre réseau.
Créez des périmètres définis par logiciel dans votre empreinte réseau à l’aide des services et fonctionnalités Azure. Lorsqu’une charge de travail (ou des parties d’une charge de travail donnée) est placée dans des segments distincts, vous contrôlez le trafic depuis ou vers ces segments pour sécuriser les chemins de communication. Si un segment est compromis, il est contenu et empêché de se propager latéralement dans le reste de votre réseau.
Pensez comme un attaquant pour prendre pied dans la charge de travail et établir des contrôles pour réduire l’expansion ultérieure. Les contrôles doivent détecter, contenir et empêcher les attaquants d’accéder à l’ensemble de la charge de travail. Voici quelques exemples de contrôles réseau en tant que périmètre :
- Définissez votre périmètre de périphérie entre les réseaux publics et le réseau où votre charge de travail est placée. Limitez autant que possible la visibilité des réseaux publics à votre réseau.
- Implémentez des zones démilitarisées (DMZ) devant l’application avec des contrôles appropriés via des pare-feu.
- Créez une micro-segmentation au sein de votre réseau privé en regroupant des parties de la charge de travail en segments distincts. Établissez des chemins de communication sécurisés entre eux.
- Créez des limites basées sur l’intention. Par exemple, segmentez les réseaux fonctionnels de charge de travail des réseaux opérationnels.
Pour connaître les modèles courants liés à la segmentation réseau, consultez Modèles de segmentation réseau.
La connectivité privée modifie la conception architecturale, en ajoutant souvent d’autres composants, tels que des zones de raccourci pour l’accès privé aux nœuds de calcul.
Étant donné que les périmètres réseau sont basés sur des points de contrôle, ou des tronçons, sur le réseau, chaque tronçon peut être un point de défaillance potentiel. Ces points peuvent avoir un effet sur la fiabilité du système.
Pour plus d’informations sur les contrôles réseau, consultez Mise en réseau et connectivité.
Rôles et responsabilités
La segmentation qui empêche la confusion et les risques de sécurité est obtenue en définissant clairement les lignes de responsabilité au sein d’une équipe de charge de travail.
Documenter et partager des rôles et des fonctions pour créer une cohérence et faciliter la communication. Désignez des groupes ou des rôles individuels qui sont responsables des fonctions clés. Examinez les rôles intégrés dans Azure avant de créer des rôles personnalisés pour les objets.
Tenez compte de la cohérence tout en tenant compte de plusieurs modèles organisationnels lors de l’attribution d’autorisations pour un segment. Ces modèles peuvent aller d’un groupe informatique centralisé unique à des équipes informatiques et DevOps indépendantes.
Organisation des ressources
La segmentation vous permet d’isoler les ressources de charge de travail d’autres parties du organization ou même au sein de l’équipe. Les constructions Azure, telles que les groupes d’administration, les abonnements, les environnements et les groupes de ressources, sont des moyens d’organiser vos ressources qui favorisent la segmentation. Voici quelques exemples d’isolation au niveau des ressources :
- La persistance polyglotte implique une combinaison de technologies de stockage de données au lieu d’un système de base de données unique pour prendre en charge la segmentation. Utilisez la persistance polyglotte pour la séparation par différents modèles de données, la séparation des fonctionnalités telles que le stockage et l’analytique des données, ou pour séparer par des modèles d’accès.
- Allouez un service pour chaque serveur lors de l’organisation de votre calcul. Ce niveau d’isolation réduit la complexité et peut aider à contenir une attaque.
- Azure fournit une isolation intégrée pour certains services, par exemple la séparation du calcul du stockage. Pour obtenir d’autres exemples, consultez Isolation dans le cloud public Azure.
Facilitation Azure
Certains services Azure peuvent être utilisés dans l’implémentation d’une stratégie de segmentation, comme décrit dans les sections suivantes.
Identité
Azure RBAC prend en charge la segmentation en isolant l’accès par fonction de travail. Seules certaines actions sont autorisées pour certains rôles et étendues. Par exemple, les fonctions de travail qui n’ont besoin que d’observer le système peuvent se voir attribuer des autorisations de lecteur par rapport aux autorisations contributeur qui permettent à l’identité de gérer les ressources.
Pour plus d’informations, consultez Meilleures pratiques pour RBAC.
Mise en réseau
Réseaux virtuels : les réseaux virtuels permettent de contenir les ressources au niveau du réseau sans ajouter de trafic entre deux réseaux virtuels. Les réseaux virtuels sont créés dans des espaces d’adressage privés au sein d’un abonnement
Groupes de sécurité réseau (NSG) : mécanisme de contrôle d’accès permettant de contrôler le trafic entre les ressources dans les réseaux virtuels et les réseaux externes, tels qu’Internet. Implémentez des itinéraires définis par l’utilisateur (UDR) pour contrôler le tronçon suivant pour le trafic. Les groupes de sécurité réseau peuvent porter votre stratégie de segmentation à un niveau granulaire en créant des périmètres pour un sous-réseau, une machine virtuelle ou un groupe de machines virtuelles. Pour plus d’informations sur les opérations possibles avec des sous-réseaux dans Azure, consultez Sous-réseaux.
Groupes de sécurité d’application (ASG) : les ASG vous permettent de regrouper un ensemble de machines virtuelles sous une étiquette d’application et de définir des règles de trafic qui sont ensuite appliquées à chacune des machines virtuelles sous-jacentes.
Pare-feu Azure : service natif cloud, qui peut être déployé dans votre réseau virtuel ou dans des déploiements Azure Virtual WAN Hub. Utilisez Pare-feu Azure pour filtrer le trafic circulant entre les ressources cloud, Internet et les ressources locales. Utilisez Pare-feu Azure ou Pare-feu Azure Manager pour créer des règles ou des stratégies qui autorisent ou refusent le trafic à l’aide de contrôles de couche 3 à 7. Filtrez le trafic Internet à l’aide de Pare-feu Azure et de tiers en dirigeant le trafic via des fournisseurs de sécurité tiers pour un filtrage avancé et une protection des utilisateurs. Azure prend en charge le déploiement de Appliance virtuels réseau, ce qui facilite la segmentation à partir de pare-feu tiers.
Exemple
Voici quelques modèles courants pour segmenter une charge de travail dans Azure. Choisissez un modèle en fonction de vos besoins.
Cet exemple s’appuie sur l’environnement informatique établi dans la base de référence de sécurité (SE :01). Le diagramme ci-dessous montre la segmentation au niveau du groupe d’administration effectuée par un organization.
Modèles de segmentation d’identité
Modèle 1 : Regroupement basé sur le titre du travail
Une façon d’organiser les groupes de sécurité est par titre de travail, par exemple ingénieur logiciel, administrateur de base de données, ingénieur fiabilité de site, ingénieur assurance qualité ou analyste de la sécurité. Cette approche implique la création de groupes de sécurité pour votre équipe de charge de travail en fonction de leurs rôles, sans tenir compte du travail à accomplir. Accordez aux groupes de sécurité des autorisations RBAC, permanentes ou juste à temps (JIT), en fonction de leurs responsabilités dans la charge de travail. Attribuez des principes humains et de service aux groupes de sécurité en fonction de leur accès en fonction de leurs besoins.
L’appartenance est très visible au niveau de l’attribution de rôle, ce qui permet de voir facilement à quoi un rôle a accès. Chaque personne est généralement membre d’un seul groupe de sécurité, ce qui facilite l’intégration et le retrait. Toutefois, à moins que les titres de travail se chevauchent parfaitement avec les responsabilités, le regroupement basé sur les titres n’est pas idéal pour l’implémentation des privilèges minimum. Vous pouvez finir par combiner l’implémentation avec le regroupement basé sur les fonctions.
Modèle 2 : Regroupement basé sur les fonctions
Le regroupement basé sur des fonctions est un groupe de sécurité organization méthode qui reflète le travail discret à accomplir, sans prendre en compte la structure de votre équipe. Avec ce modèle, vous accordez aux groupes de sécurité des autorisations RBAC, permanentes ou JIT selon les besoins, en fonction de leur fonction requise dans la charge de travail.
Attribuez des principes humains et de service aux groupes de sécurité en fonction de leur accès en fonction de leurs besoins. Dans la mesure du possible, utilisez des groupes homogènes existants en tant que membres des groupes basés sur des fonctions, tels que les groupes du modèle 1. Voici des exemples de groupes basés sur des fonctions :
- Opérateurs de base de données de production
- Opérateurs de base de données de préproduction
- Opérateurs de rotation des certificats de production
- Opérateurs de rotation de certificat de préproduction
- Site en direct/triage de production
- Préproduction tous les accès
Cette approche maintient l’accès le plus strict aux privilèges minimum et fournit des groupes de sécurité où l’étendue est évidente, ce qui facilite l’audit des appartenances par rapport aux tâches effectuées. Il existe souvent un rôle Azure intégré pour correspondre à cette fonction de travail.
Toutefois, l’appartenance est abstraite d’au moins une couche, ce qui vous oblige à accéder au fournisseur d’identité pour comprendre qui se trouve dans le groupe lorsque vous regardez du point de vue des ressources. En outre, une personne doit avoir plusieurs appartenances conservées pour une couverture complète. La matrice des groupes de sécurité qui se chevauchent peut être complexe.
Le modèle 2 est recommandé pour que les modèles d’accès mettent le focus, et non le graphique organization. Les organigrammes et les rôles des membres changent parfois. La capture de la gestion des identités et des accès de votre charge de travail d’un point de vue fonctionnel vous permet d’extraire votre organization d’équipe de la gestion sécurisée de la charge de travail.
Modèles de segmentation réseau
Modèle 1 : Segmentation au sein d’une charge de travail (limites souples)
Dans ce modèle, la charge de travail est placée dans un réseau virtuel unique à l’aide de sous-réseaux pour marquer les limites. La segmentation est obtenue à l’aide de deux sous-réseaux, l’un pour la base de données et l’autre pour les charges de travail web. Vous devez configurer des groupes de sécurité réseau qui autorisent le sous-réseau 1 à communiquer uniquement avec le sous-réseau 2 et le sous-réseau 2 pour communiquer uniquement avec Internet. Ce modèle fournit un contrôle de niveau couche 3.
Modèle 2 : Segmentation au sein d’une charge de travail
Ce modèle est un exemple de segmentation au niveau de la plateforme. Lesomponents de charge de travail sont répartis sur plusieurs réseaux sans peering entre eux. Toutes les communications sont acheminées via un intermédiaire qui sert de point d’accès public. L’équipe de charge de travail possède tous les réseaux.
Le modèle 2 fournit l’endiguement, mais présente la complexité supplémentaire de la gestion et du dimensionnement des réseaux virtuels. La communication entre les deux réseaux s’effectue sur l’Internet public, ce qui peut être un risque. Il existe également une latence avec les connexions publiques. Toutefois, les deux réseaux peuvent être appairés, ce qui interrompt la segmentation en les connectant pour créer un segment plus grand. Le peering doit être effectué lorsqu’aucun autre point de terminaison public n’est nécessaire.
| Considérations | Modèle 1 | Modèle 2 |
|---|---|---|
| Connectivité et routage : comment chaque segment communique | Le routage système fournit une connectivité par défaut aux composants de charge de travail. Aucun composant externe ne peut communiquer avec la charge de travail. | Dans le réseau virtuel, identique au modèle 1. Entre les réseaux, le trafic passe par l’Internet public. Il n’existe aucune connectivité directe entre les réseaux. |
| Filtrage du trafic au niveau du réseau | Le trafic entre les segments est autorisé par défaut. Utilisez des groupes de sécurité réseau ou des asg pour filtrer le trafic. | Dans le réseau virtuel, identique au modèle 1. Entre les réseaux, vous pouvez filtrer le trafic d’entrée et de sortie via un pare-feu. |
| Points de terminaison publics ouverts involontaires | Les cartes d’interface réseau n’obtiennent pas d’adresses IP publiques. Les réseaux virtuels ne sont pas exposés à la gestion des API Internet. | Identique au modèle 1. Point de terminaison public ouvert prévu sur un réseau virtuel, qui peut être mal configuré pour accepter davantage de trafic. |
Organisation des ressources
Organiser les ressources Azure en fonction de la responsabilité de propriété
Prenons l’exemple d’un patrimoine Azure qui contient plusieurs charges de travail et composants de service partagés, tels que les réseaux virtuels hub, les pare-feu, les services d’identité et les services de sécurité comme Microsoft Sentinel. Les composants de l’ensemble du patrimoine doivent être regroupés en fonction de leurs zones fonctionnelles, de leurs charges de travail et de leur propriété. Par exemple, les ressources réseau partagées doivent être regroupées dans un seul abonnement et gérées par une équipe de mise en réseau. Les composants dédiés à des charges de travail individuelles doivent se trouver dans leur propre segment et peuvent être davantage divisés en fonction des niveaux d’application ou d’autres principes organisationnels.
Accordez l’accès à la gestion des ressources dans des segments individuels en créant des attributions de rôles RBAC. Par exemple, l’équipe de mise en réseau cloud peut se voir accorder un accès administratif à l’abonnement qui contient ses ressources, mais pas à des abonnements de charge de travail individuels.
Une bonne stratégie de segmentation permet d’identifier facilement les propriétaires de chaque segment. Envisagez d’utiliser des étiquettes de ressources Azure pour annoter des groupes de ressources ou des abonnements avec l’équipe propriétaire.
Configurer et examiner le contrôle d’accès
Accordez l’accès approprié en fonction des besoins en définissant clairement des segments pour vos ressources.
Tenez compte du principe des privilèges minimum lorsque vous définissez des stratégies de contrôle d’accès. Il est important de faire la distinction entre les opérations de plan de contrôle (gestion de la ressource elle-même) et les opérations de plan de données (accès aux données stockées par la ressource). Par exemple, supposons que vous ayez une charge de travail qui contient une base de données contenant des informations sensibles sur les employés. Vous pouvez accorder l’accès de gestion à certains utilisateurs qui doivent configurer des paramètres tels que des sauvegardes de base de données ou des utilisateurs qui surveillent les performances du serveur de base de données. Toutefois, ces utilisateurs ne doivent pas être en mesure d’interroger les données sensibles stockées dans la base de données. Sélectionnez les autorisations qui accordent l’étendue minimale nécessaire pour permettre aux utilisateurs d’effectuer leurs tâches. Passez régulièrement en revue les attributions de rôles pour chaque segment et supprimez l’accès qui n’est plus nécessaire.
Notes
Certains rôles hautement privilégiés, comme le rôle propriétaire dans RBAC, permettent aux utilisateurs d’accorder à d’autres utilisateurs l’accès à une ressource. Limitez le nombre d’utilisateurs ou de groupes auxquels le rôle propriétaire est attribué et passez régulièrement en revue les journaux d’audit pour vous assurer qu’ils effectuent uniquement des opérations valides.
Liens connexes
- Isolation dans le cloud public Azure
- Recommandations pour RBAC
- Vue d’ensemble des réseaux virtuels
- ASG
- Pare-feu Azure
- Vue d’ensemble de Firewall Manager
Liste de contrôle de sécurité
Reportez-vous à l’ensemble complet de recommandations.
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