Les règles étendues sont des règles d'accès appliquées à des dossiers ou projets spécifiques, en plus d'une règle d'accès que vous pouvez appliquer à l'ensemble de l'organisation. Vous pouvez utiliser des règles par champ d'application 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 ou du projet.
Les organisations ne peuvent disposer que d'une seule règle d'accès au niveau de l'organisation, et vous pouvez l'appliquer à n'importe quel dossier ou projet de votre organisation.
Dans certains cas, vous pouvez déléguer la gestion d'une stratégie pour un sous-ensemble de ressources d'une organisation, tel qu'un dossier, à un administrateur délégué. Vous pouvez créer des règles d'accès limitées à des dossiers ou projets spécifiques, en plus d'une règle d'accès pouvant s'appliquer à 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 d'un dossier ou d'un projet, vous pouvez utiliser des règles par champ d'application.
Lorsque vous déléguez l'administration d'une stratégie étendue, les administrateurs délégués peuvent modifier ou lire cette règle spécifique, et non la stratégie Access Context Manager de l'organisation. Elles limitent les ressources pouvant être restreintes dans un périmètre VPC Service Controls, ainsi que la visibilité des niveaux d'accès.
Gestion des règles délimitées
En tant qu'administrateur Access Context Manager au niveau de l'organisation, vous pouvez créer, modifier et supprimer des règles délimitées. Vous pouvez spécifier directement des liaisons IAM (Identity and Access Management) sur la stratégie Access Context Manager et autoriser davantage la délégation de l'administration des stratégies à d'autres utilisateurs de l'organisation. Un administrateur des règles définies peut configurer des périmètres de service et des niveaux d'accès dans des règles. Toutefois, un administrateur des règles à champ d'application ne peut pas créer de règles ni modifier le champ d'application de la règle pour qu'elle s'applique à un autre dossier ou projet.
Voici comment les administrateurs gèrent les règles étendues:
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.
L'administrateur au niveau de l'organisation attribue des autorisations IAM à l'administrateur délégué directement sur la ressource de stratégie d'accès. L'administrateur délégué dispose désormais d'autorisations sur la stratégie étendue, mais n'a accès à aucune autre stratégie, sauf si l'administrateur au niveau de l'organisation les attribue explicitement à l'administrateur délégué.
L'administrateur délégué peut maintenant modifier la stratégie pour configurer des niveaux d'accès et des périmètres de service. L'administrateur délégué peut également accorder des autorisations IAM sur cette stratégie à n'importe quel autre utilisateur.
Lorsque vous supprimez un dossier ou un projet, la stratégie dont le champ d'application correspond au dossier ou au projet supprimé est également supprimée. De plus, 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 règle associée au projet, puis la recréer et spécifier le champ d'application.
Hiérarchie des règles délimitées
La ressource 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 constituent un mécanisme de regroupement en plus des projets. Les dossiers et les projets existent en tant que nœuds enfants de la ressource d'organisation.
Le schéma suivant présente un exemple d'organisation contenant des dossiers pour chaque service, ainsi que des projets de développement, de test et de production.
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 délimitée:
Les périmètres de service d'une règle à champ d'application ne peuvent restreindre que les ressources comprises dans le champ d'application de cette règle. Par exemple, un périmètre de service au sein d'une stratégie limitée au dossier "Engineering" peut sécuriser les projets example-dev, example-prod et example-test, car ils se trouvent dans le dossier d'ingénierie.
Si la stratégie étendue s'applique au dossier de vente, 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 définie peut autoriser l'accès aux projets d'autres dossiers à l'aide de règles d'entrée et de sortie.
Les niveaux d'accès d'une règle délimitée ne sont visibles que dans le champ d'application de la règle. Si vous créez un niveau d'accès dans la stratégie limitée au dossier "ingénierie", seuls les périmètres de service et les niveaux d'accès du dossier "ingénierie" peuvent l'utiliser. Les périmètres de service et les niveaux d'accès des autres dossiers ne peuvent pas utiliser le niveau d'accès défini dans le dossier "Engineer".
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. Lorsqu'il existe plusieurs règles, une requête de ressources dans l'organisation example.com est évaluée en fonction des règles suivantes:
Une règle ne peut contenir qu'un seul champ d'application, tel qu'un dossier, mais vous pouvez en créer une pour chaque niveau d'une organisation. Par exemple, si le champ d'application de la règle 1 est le dossier "ingénierie", vous ne pouvez pas définir ce dossier comme champ d'application d'une autre règle. Vous pouvez définir une autre règle dont le champ d'application est défini sur l'enfant du dossier d'ingénierie, par exemple example-prod.
Si le champ d'application d'une règle s'applique à un projet ou à un parent du projet, vous pouvez ajouter le projet à la règle. Toutefois, un projet ne peut être membre que d'un seul périmètre de service pour toutes les règles. Par exemple, une règle 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 sur le projet example-dev peut également ajouter le projet example-dev à un périmètre défini au sein de l'un ou l'autre de ces projets. Cependant, une seule de ces trois règles peut contenir ce projet.