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
  • 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 des règles Access Context Manager aux composants de solution BeyondCorp Enterprise suivants:

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 entraîne des vecteurs d'attaque supplémentaires qui ne sont pas pris en compte par le modèle de périmètre. Le périmètre ne se limite plus à l'emplacement physique de l'entreprise, et ce qu'il contient ne peut pas ê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 dans lequel les points de terminaison ne comportent pas d'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 la règle d'accès 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 avec champ d'application et définir son champ d'application au niveau du dossier ou du projet. L'administrateur délégué auquel la règle étendue est attribuée ne peut gérer que cette règle, 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, telles que des modifications de 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 permet d'éviter les écrasements involontaires et les conflits.

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

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. Ces attributs sont combinés en tant qu'opération AND (tous doivent être vrais) ou NOR (aucun ne doit être vrai) pour déterminer si la condition est remplie.

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 de la requête d'origine. La plage d'adresses IP à autoriser est spécifiée sous la forme d'un bloc de routage inter-domaine sans classe (CIDR), qui permet 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 basés uniquement sur l'identité à l'aide de l'outil de ligne de commande gcloud, mais pas dans 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 plus d'informations sur la création d'un niveau d'accès autorisant l'accès en fonction du 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 du réseau de l'entreprise et d'un appareil exécutant un système d'exploitation le plus récent.

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.

Learn more