Recommandations pour la création d’une stratégie de segmentation

S’applique à la recommandation de la liste de contrôle de sécurité well-architected Framework :

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 d’autres unités avec son propre ensemble d’exigences et de mesures de sécurité.

Ce guide décrit les recommandations relatives à la création d’une stratégie de segmentation unifiée. À l’aide de périmètres et de limites d’isolation dans les charges de travail, vous pouvez concevoir une approche de sécurité qui fonctionne pour vous.

Définitions 

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é tout au long d’une solution, y compris le segment des ressources à des fins de gestion et le contrôle d’accès.

La segmentation vous aide à concevoir une approche de sécurité qui applique la défense en profondeur en fonction des principes du modèle Confiance Zéro. 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 les ressources d’être exposées. Voici quelques exemples de segments :

• Abonnements qui isolent les charges de travail d’une organisation
• Groupes de ressources qui isolent les ressources de charge de travail
• Environnements de déploiement qui isolent le déploiement par étapes
• Équipes et rôles qui isolent les fonctions de travail liées au développement et à la gestion des charges de travail
• Niveaux d’application isolés 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 d’obtenir 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 des groupes de sécurité réseau et de routage pour autoriser uniquement les modèles de trafic attendus, ce qui évite le trafic vers des segments réseau arbitraires.

• L’isolation est la pratique de regroupement d’entités avec des garanties similaires pour les protéger avec une limite. L’objectif est de faciliter la gestion et l’isolement 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 les é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 à vérifier. L’isolation concerne le regroupement. Contiennent activement une attaque à l’aide de ces concepts ensemble.

L’isolation ne signifie pas la création de silos dans l’organisation. Une stratégie de segmentation unifiée fournit un alignement entre les équipes techniques et définit des lignes claires de responsabilité. La clarté réduit le risque d’erreurs humaines et d’échecs d’automatisation pouvant entraîner des vulnérabilités de sécurité, des temps d’arrêt opérationnels ou les deux. Supposons qu’une violation de 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. L’organisation 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 aussi un compromis en coût. Par exemple, d’autres 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 de permettre des chemins de communication valides au sein du segment.

Établir l’identité comme périmètre de sécurité principal

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’emplacement de la demande d’accès. Utilisez l’identité comme périmètre pour :

• Attribuez l’accès par rôle. Les identités doivent uniquement accéder aux segments requis pour effectuer leur travail. Réduisez l’accès anonyme en comprenant les rôles et responsabilités de l’identité demandeur afin que vous connaissiez l’entité qui demande l’accès à un segment et à quel objectif.

  Une identité peut avoir des étendues d’accès différentes dans différents segments. Considérez une configuration d’environnement classique, avec des segments distincts pour chaque étape. Les identités associées au rôle développeur ont un accès en lecture-écriture à l’environnement de développement. À mesure que le déploiement passe à la mise en lots, ces autorisations sont bloqué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.

• Envisagez 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 des développeurs ou 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 un accès à privilèges minimum. Si l’identité est autorisée, 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 moindre privilège, vous limitez les effets négatifs si l’identité est jamais compromise. Si l’accès est limité par le temps, la surface d’attaque est réduite. L’accès limité au temps est particulièrement applicable aux comptes critiques, tels que les administrateurs ou les composants logiciels qui ont une identité compromise.

Compromis : Les performances de la charge de travail peuvent être affectées par les périmètres d’identité. La vérification de chaque requête nécessite explicitement des cycles de calcul supplémentaires et des E/S de réseau supplémentaires.

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é au lieu d’identités individuelles.

Risque : les paramètres d’identité peuvent être complexes. Les configurations incorrectes peuvent affecter la fiabilité de la charge de travail. Par exemple, supposons qu’il existe une attribution de rôle mal configurée qui n’a pas accès à une base de données. Les demandes commencent à échouer, ce qui entraîne finalement des problèmes de fiabilité qui ne peuvent pas être détectés avant l’exécution.

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 vivement recommandé d’effectuer une révision d’accès régulière et de demander un flux de travail d’approbation pour obtenir des privilèges pour les comptes d’impact critique. Par exemple, consultez les modèles de segmentation d’identité.

Améliorer avec la 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 le 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 l’objectif principal du périmètre d’identité soit le moins privilégié, vous devez supposer qu’il y aura une violation lorsque vous concevez le périmètre du 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 par la suite via le reste de votre réseau.

Pensez comme un attaquant pour atteindre un pied de page dans la charge de travail et établir des contrôles pour réduire l’expansion supplémentaire. 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 la ligne de vue des réseaux publics à votre réseau autant que possible.
• 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 en fonction de l’intention. Par exemple, segmentez les réseaux fonctionnels de charge de travail à partir de réseaux opérationnels.

Pour connaître les modèles courants liés à la segmentation réseau, consultez les modèles de segmentation réseau.

Compromis : les contrôles de sécurité réseau sont souvent coûteux, car ils sont inclus avec les références SKU Premium. La configuration des règles sur les pare-feu entraîne souvent une complexité écrasante nécessitant de grandes exceptions.

La connectivité privée modifie la conception architecturale, ajoutant souvent davantage de composants tels que des zones de rebond 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.

Risque : les contrôles réseau sont basés sur des règles et il existe un risque important de mauvaise configuration, ce qui constitue une préoccupation de fiabilité.

Pour plus d’informations sur les contrôles réseau, consultez Mise en réseau et connectivité.

Définir des rôles et définir des lignes claires de responsabilité

La segmentation qui empêche la confusion et les risques de sécurité est atteinte en définissant clairement les lignes de responsabilité au sein d’une équipe de charge de travail.

Documentez et partagez 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 responsables des fonctions clés. Prenez en compte les rôles intégrés dans Azure avant de créer des rôles personnalisés pour les objets.

Envisagez la cohérence lors de l’adaptation 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.

Risque : l’appartenance à des groupes peut changer au fil du temps lorsque les employés rejoignent ou quittent des équipes ou modifient des rôles. La gestion des rôles entre les segments peut entraîner une surcharge de gestion.

Organiser les ressources pour promouvoir la segmentation

La segmentation vous permet d’isoler les ressources de charge de travail d’autres parties de l’organisation 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 façons 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 seul système de base de données 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 les 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 d’autres exemples, consultez Isolation dans le cloud public Azure.

Compromis : L’isolation des ressources peut entraîner une augmentation du coût total de possession (TCO). Pour les magasins de données, il peut y avoir une complexité et une coordination supplémentaires lors de la récupération d’urgence.

Facilitation Azure

Certains services Azure sont disponibles pour une utilisation dans l’implémentation d’une stratégie de segmentation, comme indiqué 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 doivent uniquement observer le système peuvent recevoir des autorisations de lecteur par rapport aux autorisations de contributeur qui permettent à l’identité de gérer les ressources.

Pour plus d’informations, consultez Les meilleures pratiques pour RBAC.

Mise en réseau

Réseaux virtuels : les réseaux virtuels fournissent une confinement au niveau du réseau des ressources 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 des réseaux virtuels et les réseaux externes, tels que l’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 prendre 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 balise 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 les déploiements du hub Azure Virtual WAN. Utilisez Pare-feu Azure pour filtrer le trafic 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 des contrôles de couche 3 à couche 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 le filtrage avancé et la protection des utilisateurs. support Azure s le déploiement d’appliances virtuelles réseau, ce qui permet 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 (Information Technology) é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é par une organisation.

Modèles de segmentation d’identité

Modèle 1 : Regroupement basé sur le titre du travail

L’une des façons d’organiser des groupes de sécurité consiste en un titre de travail tel que l’ingénieur logiciel, l’administrateur de base de données, l’ingénieur de fiabilité du site, l’ingénieur assurance qualité ou l’analyste de 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 des autorisations RBAC aux groupes de sécurité, debout 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 hautement visible au niveau de l’attribution de rôle, ce qui facilite la visibilité d’un rôle . Chaque personne est généralement membre d’un seul groupe de sécurité, ce qui facilite l’intégration et la désactivation. Toutefois, sauf si 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 des fonctions.

Modèle 2 : Regroupement basé sur des fonctions

Le regroupement basé sur des fonctions est une méthode d’organisation de groupe de sécurité qui reflète le travail discret qui doit être accompli, sans tenir compte de la structure de votre équipe. Avec ce modèle, vous accordez des autorisations RBAC aux groupes de sécurité, debout 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 ces groupes du modèle 1. Voici quelques 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 de certificat de production
• Opérateurs de rotation de certificat de préproduction
• Production live-site/triage
• Préproduction de tous les accès

Cette approche maintient l’accès le moins privilégié le plus strict et fournit des groupes de sécurité où l’étendue est évidente, ce qui facilite l’audit des appartenances par rapport aux tâches de travail effectuées. Souvent, un rôle Azure intégré existe pour correspondre à cette fonction de travail.

Toutefois, l’appartenance est abstraite au moins une couche, vous obligeant à accéder au fournisseur d’identité pour comprendre qui est dans le groupe lorsque vous regardez du point de vue de la ressource. En outre, une personne doit avoir plusieurs appartenances maintenues 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 rendre les modèles d’accès le focus, et non l’organigramme. Les organigrammes et les rôles membres changent parfois. La capture de la gestion des identités et des accès de votre charge de travail à partir d’une perspective fonctionnelle vous permet d’extraire votre organisation 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 réversibles)

Dans ce modèle, la charge de travail est placée dans un seul réseau virtuel à l’aide de sous-réseaux pour marquer les limites. La segmentation est obtenue à l’aide de deux sous-réseaux, un pour la base de données et un 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. Les omponents cde 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é accrue de la gestion et du dimensionnement du réseau virtuel. La communication entre les deux réseaux se déroule 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, en cassant la segmentation en les connectant pour créer un segment plus grand. Le peering doit être effectué quand aucun autre point de terminaison public n’est nécessaire.

Organisation des ressources

Organiser les ressources Azure en fonction de la responsabilité de propriété

Considérez un patrimoine Azure qui contient plusieurs charges de travail et composants de service partagé comme les réseaux virtuels hub, les pare-feu, les services d’identité et les services de sécurité tels que Microsoft Sentinel. Les composants du patrimoine doivent être regroupés en fonction de leurs zones fonctionnelles, charges de travail et propriété. Par exemple, les ressources réseau partagées doivent être regroupées en un seul abonnement et gérées par une équipe réseau. Les composants dédiés à des charges de travail individuelles doivent se trouver dans leur propre segment et peuvent être divisés en fonction des niveaux d’application ou d’autres principes organisationnels.

Accordez l’accès pour gérer les 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 bénéficier d’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 balises de ressources Azure pour annoter des groupes de ressources ou des abonnements avec l’équipe propriétaire.

Configurer et passer en revue le contrôle d’accès

Accordez un accès approprié en fonction du besoin en définissant clairement des segments pour vos ressources.

Considérez le principe du privilège 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 disposez d’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 pouvoir interroger les données sensibles stockées dans la base de données. Sélectionnez les autorisations qui accordent l’étendue minimale nécessaire aux utilisateurs pour 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.

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 du Gestionnaire de pare-feu

Liste de contrôle de sécurité

Reportez-vous à l’ensemble complet de recommandations.