Règles limitées (original) (raw)
Les règles limitées sont des règles d'accès qui s'appliquent à des dossiers ou des 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 limitées pour déléguer l'administration des périmètres et des niveaux d'accès VPC Service Controls aux administrateurs au niveau des dossiers et des projets.
Les organisations ne peuvent avoir qu'une seule règle d'accès au niveau de l'organisation. Vous pouvez appliquer la règle d'accès au niveau de l'organisation à n'importe quel dossier ou projet de votre organisation.
Il peut arriver que vous souhaitiez déléguer la gestion d'une stratégie pour un sous-ensemble des ressources d'une organisation, comme un dossier, à un administrateur délégué. Vous pouvez créer des règles d'accès qui sont limitées à des dossiers ou des projets spécifiques, en même temps qu'une règle d'accès qui s'applique à l'ensemble de l'organisation. Pour déléguer l'administration des périmètres et des niveaux d'accès VPC Service Controls aux administrateurs au niveau des dossiers et des projets, vous pouvez utiliser des règles limitées.
Lorsque vous déléguez l'administration d'une stratégie limitée, les administrateurs délégués peuvent modifier ou lire cette stratégie spécifique, mais pas la stratégie Access Context Manager de l'organisation. Les règles de portée 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 limitées
En tant qu'administrateur Access Context Manager au niveau de l'organisation, vous pouvez créer, modifier et supprimer des règles de portée. Vous pouvez spécifier directement des liaisons de gestion de l'identité et des accès (IAM) sur la stratégie Access Context Manager et autoriser la délégation ultérieure de l'administration des stratégies Access Context Manager à d'autres utilisateurs de l'organisation. Un administrateur de règles de portée peut configurer des périmètres de service et des niveaux d'accès dans les règles. Toutefois, un administrateur de règles limitées ne peut pas créer de règle ni modifier son champ d'application pour l'appliquer à un autre dossier ou projet.
Voici comment les administrateurs gèrent les stratégies de portée:
- L'administrateur au niveau de l'organisation crée une règle d'accès avec un champ de champ d'application référençant un dossier ou un projet spécifique.
- L'administrateur au niveau de l'organisation attribue des autorisations IAM à l'administrateur délégué directement dans la ressource de stratégie d'accès. L'administrateur délégué dispose désormais d'autorisations sur la règle limitée, mais pas sur toute autre règle, sauf si l'administrateur au niveau de l'organisation les attribue explicitement à l'administrateur délégué.
- L'administrateur délégué peut désormais modifier la règle 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 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 est le dossier ou le 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 définie pour le 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 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 "Organisation". Les dossiers sont un mécanisme de regroupement en plus des projets. Les dossiers et les projets existent en tant que nœuds enfants de la ressource "Organisation".
Le diagramme suivant montre un exemple d'organisation contenant des dossiers pour chaque service, et ces dossiers contiennent 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 stratégie de portée:
- Les périmètres de service d'une stratégie à portée limitée ne peuvent limiter que les ressources qui existent dans le champ d'application de cette stratégie. Par exemple, un périmètre de service dans une règle couvrant le dossier d'ingénierie 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 de portée s'applique au dossier "sales", 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 de portée 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 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 "engineering", seuls les périmètres de service et les niveaux d'accès du dossier "engineering" peuvent l'utiliser. Les périmètres de service et les niveaux d'accès dans d'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 stratégies contenant un niveau d'accès ou un périmètre de service. Lorsqu'il existe plusieurs règles, une demande de ressources dans l'organisation example.com est évaluée en fonction des 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 stratégie pour chaque niveau d'une organisation. Par exemple, si le champ d'application de la stratégie 1 est le dossier "Engineering", vous ne pouvez pas définir le dossier "Engineering" comme champ d'application d'une autre stratégie. Vous pouvez définir une autre stratégie avec la portée définie 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 appartenir qu'à un seul périmètre de service pour toutes les règles. Par exemple, une règle dont la portée est définie sur l'organisation example.com peut définir un périmètre de service avec example-dev. Une règle dont la portée est définie 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 dans l'un ou l'autre. Toutefois, un seul de ces trois règles peut contenir ce projet.