Règles concernées

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Les règles étendues sont des règles d'accès s'appliquant à des dossiers ou des projets spécifiques, en plus d'une règle d'accès applicable à l'ensemble de l'organisation. Vous pouvez utiliser des stratégies étendues pour déléguer l'administration des périmètres et des niveaux d'accès VPC Service Controls aux administrateurs au niveau du dossier et du projet.

Les organisations ne peuvent disposer que d'une seule règle d'accès au niveau de l'organisation. Vous pouvez l'appliquer à n'importe quel dossier ou projet de votre organisation.

Vous pouvez être amené à déléguer la gestion d'une stratégie à un sous-ensemble d'une ressource d'organisation, telle qu'un dossier, à un administrateur délégué. Vous pouvez créer des règles d'accès appliquées à des dossiers ou projets spécifiques, ainsi qu'une règle d'accès applicable à l'ensemble de l'organisation. Pour déléguer l'administration des périmètres et des niveaux d'accès VPC Service Controls à des administrateurs au niveau du dossier et du projet, vous pouvez utiliser des règles étendues.

Lorsque vous déléguez l'administration d'une règle étendue, les administrateurs délégués peuvent modifier ou lire cette règle spécifique et non la règle Access Context Manager de l'organisation. Les règles étendues limitent les ressources pouvant être limitées dans un périmètre VPC Service Controls et la visibilité des niveaux d'accès.

Gestion des règles concernées

En tant qu'administrateur Access Context Manager au niveau de l'organisation, vous pouvez créer, modifier et supprimer des règles étendues. Vous pouvez spécifier des liaisons Identity and Access Management (IAM) directement dans Access Context Manager et autoriser la délégation de l'administration des stratégies à d'autres utilisateurs de l'organisation. Un administrateur de stratégies limité peut configurer des périmètres de service et des niveaux d'accès dans des règles. Toutefois, un administrateur de règles restreints ne peut pas créer de règle ni modifier le champ d'application de la règle pour l'appliquer à un autre dossier ou projet.

Voici une séquence montrant comment les administrateurs gèrent les règles concernées:

  1. L'administrateur au niveau de l'organisation crée une règle d'accès avec un champ d'application faisant référence à un dossier ou à un projet spécifique.

  2. L'administrateur au niveau de l'organisation attribue les autorisations IAM à l'administrateur délégué directement sur la ressource de la règle d'accès. L'administrateur délégué dispose désormais d'autorisations sur la stratégie étendue, mais pas sur les autres stratégies, sauf si l'administrateur au niveau de l'organisation les attribue explicitement à l'administrateur délégué.

  3. L'administrateur délégué peut désormais modifier la stratégie pour configurer les niveaux d'accès et les périmètres de service. L'administrateur délégué peut également accorder des autorisations IAM à cette autre personne sur cette stratégie.

Lorsque vous supprimez un dossier ou un projet, la règle qui a été définie pour le dossier ou le projet supprimé est également supprimée. Par ailleurs, si vous déplacez un projet vers un autre nœud de la hiérarchie de l'organisation, la règle appliquée au projet n'est pas automatiquement modifiée. Vous devez supprimer la stratégie associée au projet, puis recréer cette règle et spécifier la portée.

Hiérarchie des règles concernées

La ressource d'organisation est le nœud racine de la hiérarchie des ressources Google Cloud. Toutes les ressources appartenant à une organisation existent en tant qu'enfants du nœud d'organisation. Les dossiers sont un mécanisme de regroupement par-dessus les projets. Les dossiers et les projets existent en tant que nœuds enfants de la ressource d'organisation.

Le schéma suivant illustre un exemple d'organisation contenant des dossiers pour chaque service, et les dossiers contiennent des projets de développement, de test et de production.

Architecture de déploiement

Dans l'exemple d'organisation, les contraintes suivantes s'appliquent à un périmètre de service ou à un niveau d'accès dans une règle étendue:

  • Les périmètres de service d'une règle étendue ne peuvent restreindre que les ressources concernées par cette règle. Par exemple, un périmètre de service dans une stratégie limitée au dossier d'ingénierie peut sécuriser les projets example-dev, example-prod et example-test, car ils se trouvent dans le dossier ingénierie.

    Si la règle étendue s'applique au dossier de ventes, les périmètres de service de cette stratégie ne peuvent sécuriser aucun des projets example-dev, example-prod et example-test. Toutefois, le périmètre de service de la règle étendue peut autoriser l'accès aux projets d'autres dossiers à l'aide des règles d'entrée et de sortie.

  • Les niveaux d'accès d'une règle définie ne sont visibles que dans sa portée. Si vous créez un niveau d'accès dans la stratégie limité au dossier d'ingénierie, seuls les périmètres de service et les niveaux d'accès du dossier d'ingénierie peuvent l'utiliser. Les périmètres de service et niveaux d'accès dans les autres dossiers ne peuvent pas utiliser le niveau d'accès défini dans le dossier "Engineering".

Un emplacement, tel qu'un dossier, dans la hiérarchie des ressources de l'organisation example.com, peut comporter plusieurs règles contenant un niveau d'accès ou un périmètre de service. Lorsque plusieurs règles existent, une demande de ressources dans l'organisation example.com est évaluée selon les règles suivantes:

  • Une stratégie ne peut contenir qu'un seul champ d'application, tel qu'un dossier, mais vous pouvez créer une règle pour chaque niveau d'une organisation. Par exemple, si le champ d'application de la stratégie 1 est le dossier d'ingénierie, vous ne pouvez pas le définir en tant que champ d'application d'une autre stratégie. Vous pouvez définir une autre règle avec la portée définie sur le dossier enfant du dossier d'ingénierie, par exemple example-prod.

  • Si le champ d'application d'une stratégie s'applique à un projet ou à un parent du projet, vous pouvez l'ajouter à la stratégie. Toutefois, un projet ne peut être membre que d'un seul périmètre de service sur toutes les règles. Par exemple, une stratégie dont le champ d'application est défini sur l'organisation "example.com" peut définir un périmètre de service avec "example-dev". Une règle dont le champ d'application est défini sur le dossier d'ingénierie ou définie sur le projet "example-dev" peut également ajouter le projet "example-dev" à un périmètre défini dans l'un d'entre eux. Toutefois, seule une de ces trois règles peut contenir ce projet.

Étapes suivantes