Cette page a été traduite par l'API Cloud Translation.

Présentation d'Access Context Manager

Access Context Manager permet aux administrateurs d'organisation Google Cloud de définir un contrôle d'accès précis et basé sur des attributs pour les projets et les ressources dans Google Cloud.

Les administrateurs définissent en premier lieu une stratégie 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 :

Type d'appareil et 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 celle-ci. Access Context Manager n'est pas responsable de l'application des règles. Son but est de décrire les règles que vous souhaitez mettre en œuvre. Une règle est configurée et appliquée sur différents éléments, tels que VPC Service Controls. Pour en savoir plus sur ces services, reportez-vous aux guides d'utilisateur correspondants.

Vous pouvez configurer et appliquer les règles Access Context Manager sur les composants suivants de la solution Chrome Enterprise Premium :

Pourquoi Access Context Manager ?

De nombreuses entreprises s'appuient sur un modèle de sécurité périmétrique (par exemple, des pare-feu) pour sécuriser les ressources internes. Ce modèle peut être assimilé à un château médiéval : une forteresse aux murs épais, entourée d'un fossé et offrant un unique point d'entrée et de sortie fortement surveillé. Tout élément situé à l'extérieur des murs du château 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 génère des vecteurs d'attaque supplémentaires non pris en compte par le modèle de périmètre. Le périmètre n'est plus seulement l'emplacement physique de l'entreprise, et le contenu qui s'y trouve ne peut être considéré comme sûr.

Access Context Manager vous permet de réduire la taille du réseau privilégié et de 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.

Access Context Manager fait partie intégrante du modèle de sécurité BeyondCorp (au-delà de l'entreprise) développé par Google. Pour en savoir plus, consultez la page propre à BeyondCorp.

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 utiliser au niveau de l'organisation 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 la portée de la règle 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 des niveaux d'accès à une version spécifique de la stratégie. 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 garantit qu'aucun écrasement ni conflit involontaire ne se produit.

Pour savoir comment créer des règles d'accès, consultez la section 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 aux utilisateurs, appareils et comptes de service disposant du niveau d'accès "High_Trust". Ces vérifications s'ajoutent 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.

Access Context Manager propose deux méthodes pour définir des niveaux d'accès: accès de base et accès personnalisé.

Un niveau d'accès de base est un ensemble de conditions utilisées pour tester des requêtes. Les conditions sont des groupes d'attributs que vous souhaitez tester, tels que le type d'appareil, l'adresse IP ou l'identité de l'utilisateur. La sont combinés sous la forme d'une opération AND (tous les éléments doivent être vrais), Opération NOR (aucun ne doit être vrai) pour déterminer si la condition est satisfaite.

Les niveaux d'accès personnalisés sont créés à l'aide d'un sous-ensemble de CEL (Common Expression Language). En plus du contexte de la requête utilisé pour les niveaux d'accès de base, vous pouvez également utiliser des niveaux d'accès personnalisés pour autoriser les requêtes basées sur les données de services tiers. Pour en savoir plus, consultez la page Niveaux d'accès personnalisés.

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 autorisées à accéder aux ressources est spécifiée sous la forme d'un bloc CIDR (Classless Inter-Domain Routing). Cette approche offre un contrôle à la fois simple et précis sur les adresses IP autorisées.

Un même niveau d'accès peut contenir plusieurs plages IP.

Reportez-vous à la page Créer un niveau d'accès pour l'accès au réseau d'entreprise pour découvrir comment créer un niveau d'accès qui n'accorde l'accès aux ressources concernées qu'à une plage IP spécifique (par exemple, les adresses IP faisant partie du réseau interne de l'entreprise).

Type d'appareil

Access Context Manager utilise la validation des points de terminaison pour recueillir des informations sur les appareils des utilisateurs, y compris le système d'exploitation installé et la version utilisée. Vous pouvez accorder un niveau d'accès en fonction de ces données. Par exemple, vous pouvez décider d'accorder un niveau d'accès plus permissif aux appareils exécutant la dernière version du principal système d'exploitation déployé dans votre entreprise.

Pour plus d’informations sur l’attribution d’un niveau d’accès à certains appareils, consultez la page Créer un niveau d’accès pour les appareils des utilisateurs.

Identité des utilisateurs

Dans certains scénarios, il se peut que vous souhaitiez accorder un niveau d'accès à des entités spécifiques. En pareil cas, 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 (par exemple, pour permettre à une fonction Cloud d'accéder aux données protégées par les contrôles de service VPC).

Vous pouvez créer et gérer des niveaux d'accès d'identité uniquement avec l'outil de ligne de commande gcloud, mais pas avec la console Google Cloud.

Pour commencer à créer un niveau d'accès de base, consultez la section Créer un niveau d'accès pour Access Context Manager.

Pour en savoir plus sur la création d'un niveau d'accès autorisant l'accès en fonction du le contexte d'une requête, consultez Créer un niveau d'accès personnalisé.

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. Elle 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 particulier.

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.