Ce document fournit un aperçu général du service Access Context Manager et de ses fonctions.Les administrateurs de l'organisation Trusted Cloud by S3NS peuvent utiliser Access Context Manager pour définir un contrôle d'accès précis basé sur des attributs pour les projets et les ressources dans Trusted Cloud by S3NS . Trusted CloudEn tant qu'administrateur, vous devez d'abord définir une règle d'accès, qui est un conteneur à l'échelle de l'organisation pour les niveaux d'accès et les périmètres de service.
Les niveaux d'accès décrivent les conditions requises pour que les requêtes soient honorées. Voici quelques exemples :
- le type d'appareil et le système d'exploitation ;
- l'adresse IP ;
- Identité des utilisateurs
Les périmètres de service définissent des "bacs à sable" de ressources, qui peuvent librement échanger des données au sein du périmètre, mais ne sont pas autorisés à exporter des données en dehors de celui-ci. Access Context Manager n'est pas responsable de l'application des règles. Access Context Manager est plutôt conçu pour définir des règles ou un contexte spécifiques. Une règle est configurée et appliquée sur différents points, tels que VPC Service Controls. Pour en savoir plus sur ces services, reportez-vous aux guides d'utilisateur correspondants.
Vous pouvez configurer et appliquer des règles Access Context Manager dans les composants suivants de la solution Chrome Enterprise Premium :
Avantages
De nombreuses entreprises s'appuient sur un modèle de sécurité périmétrique (par exemple, un pare-feu) pour sécuriser les ressources internes. Un modèle de sécurité de périmètre est fortement gardé et ne comporte qu'un seul point d'entrée et de sortie. Tout élément situé à l'extérieur est considéré comme dangereux. Tout élément qui se trouve dans l'enceinte du château est considéré comme fiable.
Les pare-feu et le modèle de sécurité périmétrique fonctionnent bien s'il existe une limite précise entre des utilisateurs et des services spécifiques. Toutefois, pour une entreprise dont tout ou partie de l'effectif est mobile, le parc d'appareils devient de plus en plus hétérogène à mesure que les utilisateurs apportent leurs propres appareils (BYOD) et utilisent des services cloud. Ce scénario entraîne l'apparition de vecteurs d'attaque supplémentaires qui ne sont pas pris en compte par le modèle périmétrique. Le périmètre à sécuriser ne se limite plus à l'emplacement physique de l'entreprise, et même ce qui se trouve à l'intérieur ne peut pas être considéré comme sûr.
Vous pouvez utiliser Access Context Manager pour réduire la taille du réseau privilégié et passer à un modèle où les points de terminaison ne sont pas porteurs d'une autorité ambiante basée sur le réseau. À la place, vous pouvez accorder un accès basé sur le contexte de la requête, tel que le type d'appareil, l'identité de l'utilisateur, etc., tout en continuant à surveiller les accès au réseau de l'entreprise si nécessaire.
Règles d'accès
Une stratégie d'accès est un conteneur pour toutes vos ressources Access Context Manager, telles que les niveaux d'accès et les périmètres de service.
Vous pouvez créer une règle d'accès dans le contexte d'une organisation et l'utiliser n'importe où dans votre organisation. Pour déléguer l'administration d'une règle d'accès, vous pouvez créer une règle d'accès limitée et définir son champ d'application au niveau du dossier ou du projet. L'administrateur délégué auquel la règle limitée est attribuée ne peut gérer que la règle d'accès limitée, et non la règle d'accès au niveau de l'organisation.
La gestion des versions d'une règle d'accès s'effectue à l'aide d'un etag.
Vous pouvez utiliser etag pour cibler les modifications apportées à votre règle d'accès, comme les modifications apportées aux niveaux d'accès ou à une version spécifique de la règle. Si plusieurs sources modifient votre règle d'accès, l'utilisation du champ etag pour l'outil de ligne de commande gcloud et les appels d'API permet d'éviter les écrasements et les conflits involontaires.
Pour savoir comment créer des règles d'accès, consultez Créer une règle d'accès.
Niveaux d'accès
Les niveaux d'accès sont utilisés pour autoriser l'accès aux ressources en fonction des informations contextuelles concernant la requête. Grâce aux niveaux d'accès, vous pouvez commencer à organiser des niveaux de confiance. Par exemple, vous pouvez créer un niveau d'accès appelé High_Level qui autorisera les requêtes d'un petit groupe de personnes disposant de privilèges élevés. Vous pouvez également identifier un groupe plus général à approuver, tel qu'une plage d'adresses IP à partir de laquelle vous souhaitez autoriser les requêtes. Dans ce cas, vous pouvez créer un niveau d'accès appelé Medium_Level servant à autoriser ces requêtes.
Une fois que vous avez défini les niveaux d'accès, les services d'application peuvent les utiliser pour déterminer s'il convient d'accepter une requête. Par exemple, vous pouvez choisir d'accorder l'accès à de nombreuses ressources pour le niveau Medium_Trust, tout en réservant l'accès à certaines ressources plus sensibles au niveau High_Trust. Ces vérifications sont appliquées en plus de la stratégie IAM standard.
Les niveaux d'accès sont personnalisables. Les niveaux d'accès High_Trust et Medium_Trust sont des exemples. Vous pouvez spécifier plusieurs niveaux d'accès dans le cadre d'une règle d'accès.
!(origin.region_code in ['RU', 'BY', 'UA']) -> FAILED // levels.regions_check
inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED // levels.ip_check
!(origin.region_code in ['RU', 'BY', 'UA']) || inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED
levels.regions_check || levels.ip_check -> GRANTED
Adresse IP
Vous pouvez accorder un niveau d'accès en fonction de l'adresse IP dont provient la requête d'origine. La plage d'adresses IP à autoriser est indiquée sous la forme d'un bloc CIDR (Classless Inter-Domain Routing). Cette méthode offre un contrôle précis sur les adresses IP autorisées.
Un même niveau d'accès peut contenir plusieurs plages IP.
Pour découvrir comment créer un niveau d'accès qui n'accorde l'accès aux ressources concernées qu'à une plage d'adresses IP spécifique (par exemple, celles faisant partie d'un seul réseau d'entreprise), consultez Créer un niveau d'accès pour l'accès au réseau d'entreprise.
Identité des utilisateurs
Dans certains scénarios, il se peut que vous souhaitiez accorder un niveau d'accès à des entités spécifiques. Dans ces scénarios, l'identité de l'appelant détermine si la condition est remplie. Ce scénario est souvent utilisé conjointement avec les comptes de service et les contrôles de service VPC.
Vous pouvez créer et gérer des niveaux d'accès basés uniquement sur l'identité avec l'outil de ligne de commande gcloud, mais pas avec la console Trusted Cloud .
Pour savoir comment créer un niveau d'accès de base, consultez Créer un niveau d'accès pour Access Context Manager.
Combiner des conditions
Un même niveau d'accès peut contenir plusieurs conditions. Les conditions peuvent être évaluées à l'aide de l'opérateur AND ou de l'opérateur OR. Vous pouvez spécifier le mode d'évaluation lors de la création ou de la mise à jour d'un niveau d'accès.
L'option AND (par défaut) est la plus stricte. Cette option n'accorde le niveau d'accès que si toutes les conditions sont remplies. Par exemple, vous pouvez exiger qu'une requête provienne à la fois du réseau interne de l'entreprise et d'un appareil exécutant la dernière version d'un système d'exploitation.
L'option OR est moins restrictive. Il suffit que l'une des conditions soit remplie. Cela peut être utile pour traiter les identités d'utilisateur, par exemple pour exclure des entités spécifiques (telles que des comptes de service) des exigences standard.
Imbriquer des conditions
Il est possible d'imbriquer des conditions pour créer des dépendances entre elles. Par exemple, si vous avez défini deux niveaux d'accès "Medium trust" (confiance moyenne) et "High trust" (confiance élevée), vous pouvez faire en sorte que les exigences associées au niveau "High trust" incluent celles du niveau "Medium trust", ainsi que d'autres conditions.
L'imbrication de conditions peut faciliter la gestion des niveaux d'accès. Par exemple, vous pouvez spécifier que le niveau d'accès le plus permissif doit utiliser une version minimale du système d'exploitation et définir les niveaux plus restrictifs comme "dépendances" du premier niveau. Ainsi, lorsque vous mettrez à jour la version minimale requise, vous n'aurez besoin d'actualiser qu'une seule condition. Il ne sera pas nécessaire de modifier tous les niveaux d'accès de la règle.
En savoir plus
- Découvrez les différences entre Access Context Manager dans Trusted Cloud et Google Cloud.
- Guide de démarrage rapide : créer un niveau d'accès pour Access Context Manager
- Créer un niveau d'accès de base