Aperçu

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.

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. Cela se traduit par 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.

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

Access Context Manager est une fonctionnalité disponible à l'échelle de l'entreprise. Par exemple, lorsque vous créez une stratégie d'accès dans le contexte d'un projet à des fins de gestion des quotas, vous pouvez réutiliser cette stratégie à n'importe quel niveau de votre organisation. La stratégie n'est pas réservée à ce projet.

Une règle d'accès gère les versions utilisant un etag. Cela vous permet de cibler les modifications apportées à votre stratégie d'accès, telles que les modifications des niveaux d'accès, sur une version spécifique de la stratégie. Si votre règle d'accès est modifiée par plusieurs sources, l'utilisation du champ etag pour les commandes gcloud et les appels d'API d'Access Context Manager permet de s'assurer qu'aucune modification n'est écrasée de manière inattendue et qu'aucun conflit inattendu n'est provoqué.

Reportez-vous à la section Démarrage rapide pour apprendre à créer une règle d'accès.

Niveaux d'accès

Les niveaux d'accès permettent d'accéder aux ressources en fonction des informations contextuelles sur la requête. À l'aide des niveaux d'accès, vous pouvez commencer à organiser les 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 d'individus hautement privilégiés. Vous pouvez également identifier un groupe de confiance plus général, 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 pour 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 complément de la stratégie standard de gestion de l'authentification et des accès (IAM).

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 les requêtes. Les conditions sont un groupe d'attributs que vous souhaitez tester, tels que le type d'appareil, l'adresse IP ou l'identité de l'utilisateur. Les attributs de niveau d'accès représentent des informations contextuelles sur une requête.

Les niveaux d'accès personnalisés sont créés à l'aide d'un sous-ensemble de Common Expression Language. En plus du contexte de 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 plus d'informations, consultez la section sur les 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

Access Context Manager utilise la Validation des points de terminaison pour collecter des informations sur les appareils des utilisateurs, parmi lesquelles le système d'exploitation installé et la version de ce dernier. 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).

Les niveaux d'accès basés uniquement sur l'identité ne peuvent être créés et gérés qu'à l'aide de l'outil de ligne de commande gcloud, et non via Google Cloud Console.

Pour vous familiariser avec l'utilisation des identités et des niveaux d'accès, reportez-vous à la page Inclure des identités dans les niveaux d'accès associés aux réseaux.

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.

En savoir plus