Présentation d'Access Context Manager

Ce document fournit une présentation générale du service Access Context Manager et de ses fonctions.Les administrateurs de l'organisation Google Cloud peuvent utiliser Access Context Manager pour définir un contrôle des accès précis et basé sur des attributs pour les projets et les ressources dans Google Cloud. En tant qu'administrateur, vous définissez d'abord 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 :

  • 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. Les ressources situées dans le périmètre peuvent échanger des données librement, mais ne peuvent pas les exporter en dehors du périmètre. 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, consultez leurs guides de l'utilisateur respectifs.

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

Avantages

De nombreuses entreprises s'appuient sur un modèle de sécurité périphérique, tel qu'un pare-feu, pour sécuriser leurs ressources internes. Un modèle de sécurité périmétrique est lourdement gardé avec un seul point d'entrée et de sortie. Tout ce qui se trouve en dehors du périmètre 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é du périmètre fonctionnent bien s'il existe une limite bien définie autour d'utilisateurs et de 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. Par conséquent, le périmètre ne se limite plus à l'emplacement physique de l'entreprise, et 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 dans lequel les points de terminaison ne disposent pas d'une autorité ambiante basée sur le réseau. Vous pouvez plutôt accorder l'accès en fonction du contexte de la requête, comme le type d'appareil, l'identité de l'utilisateur, etc., tout en vérifiant l'accès au réseau d'entreprise si nécessaire.

Access Context Manager fait partie intégrante de l'initiative BeyondCorp de Google. Pour plus d'informations, consultez 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 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, par exemple 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 des niveaux d'accès, les services d'application peuvent les utiliser pour déterminer s'il convient d'honorer une requête. Par exemple, vous pouvez spécifier que, même si de nombreuses ressources sont disponibles pour Medium_Trust, certaines ressources plus sensibles nécessitent le niveau High_Trust. Ces vérifications s'appliquent 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 façons de définir des niveaux d'accès :

  • Un niveau d'accès de base se compose d'un ensemble de conditions utilisées pour tester les requêtes. Les conditions peuvent être définies comme 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 sont combinés sous la forme d'une opération AND (tous doivent être vrais) ou d'une opération 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 Niveaux d'accès personnalisé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 de 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 apprendre à créer un niveau d'accès qui n'autorise l'accès qu'à une plage d'adresses IP spécifique, telle que celles d'un réseau d'entreprise, consultez Créer un niveau d'accès pour l'accès au réseau d'entreprise.

Les plages d'adresses IP suivantes sont traitées comme des plages privées par Access Context Manager :

  • 10.0.0.0/8 (RFC 1918)
  • 172.16.0.0/12 (RFC 1918)
  • 192.168.0.0/16 (RFC 1918)
  • 100.64.0.0/10 (espace d'adressage partagé RFC 6598)
  • fc00::/7 (adresses locales uniques IPv6 RFC 4193)

Type d'appareil

Access Context Manager utilise Endpoint Verification pour collecter des informations sur les appareils des utilisateurs, telles que le système d'exploitation, le type d'appareil ou la version. Vous pouvez accorder un niveau d'accès en fonction de ces données. Par exemple, vous pouvez accorder un niveau d'accès plus permissif aux appareils qui exécutent la dernière version du principal système d'exploitation déployé dans votre entreprise.

Pour savoir comment accorder un niveau d'accès en fonction de ces attributs d'appareil, consultez Limiter l'accès par type d'appareil.

Identité des utilisateurs

Dans certains cas, vous pouvez 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 des comptes de service et VPC Service Controls. Par exemple, vous pouvez utiliser ce scénario pour autoriser Cloud Functions à accéder à des données protégées par VPC Service Controls.

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 avec la console Google Cloud .

Pour commencer à créer un niveau d'accès de base, consultez 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 qui autorise 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.

Le cas AND est l'option la plus stricte et l'option par défaut. 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 du réseau d'entreprise et d'un appareil exécutant la dernière version d'un système d'exploitation.

L'option OR est moins restrictive. Cette option ne nécessite qu'une seule des nombreuses conditions pour être vraie. Cela peut être utile lorsque vous traitez des identités d'utilisateurs, par exemple pour exclure des entités spécifiques (telles que des comptes de service) des exigences normales.

Imbriquer des conditions

Il est possible d'imbriquer des conditions pour créer des dépendances entre elles. Par exemple, si vous disposez de deux niveaux d'accès de confiance "Moyen" et "Élevé", vous pouvez définir les exigences pour "Élevé" afin d'exiger "Moyen", en plus 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. Si vous mettez à jour la version minimale à l'avenir, vous n'aurez qu'à mettre à jour une seule condition, plutôt que chaque niveau d'accès de la règle.

Lorsque vous imbriquez des niveaux d'accès, tenez compte des limites et restrictions suivantes :

  • Aucune dépendance circulaire : les dépendances circulaires ne sont pas autorisées. Les niveaux d'accès ne peuvent pas se référencer mutuellement dans une boucle, que ce soit directement (par exemple, Level_A nécessite Level_B et Level_B nécessite Level_A, ou un niveau d'accès se référence lui-même) ou de manière transitive (par exemple, Level_A nécessite Level_B, Level_B nécessite Level_C et Level_C nécessite Level_A). Si vous tentez de créer ou de mettre à jour un niveau d'accès qui introduit une dépendance circulaire, l'appel échoue avec une erreur INVALID_ARGUMENT.

  • Nombre maximal de dépendances par condition : dans un niveau d'accès de base, la liste requiredAccessLevels d'une seule condition peut référencer jusqu'à 15 autres niveaux d'accès.

  • Profondeur d'imbrication : étant donné qu'Access Context Manager évalue les niveaux d'accès imbriqués dans l'ordre de dépendance plutôt que de les développer de manière récursive, il n'existe pas de limite de profondeur maximale distincte sur une chaîne de niveaux d'accès imbriqués au-delà de la limite globale des niveaux d'accès par règle d'accès. Tous les niveaux d'accès référencés doivent appartenir à la même règle d'accès.

En savoir plus