Règles appliqué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 appliquées à des dossiers ou projets spécifiques, ainsi qu'à une règle d'accès applicable à l'ensemble de l'organisation. Vous pouvez utiliser des règles appliquées pour déléguer l'administration de périmètres et de niveaux d'accès VPC Service Controls à des administrateurs au niveau du dossier et du projet.

Les organisations ne peuvent avoir qu'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.

Dans certains cas, vous pouvez 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 appliquées à des dossiers ou projets spécifiques, parallèlement à une règle d'accès applicable à l'ensemble de l'organisation. Pour déléguer l'administration de périmètres et de niveaux d'accès VPC Service Controls à des administrateurs au niveau des dossiers et des projets, vous pouvez utiliser des stratégies ciblées.

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

Gestion des règles appliquées

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

Voici une séquence montrant comment les administrateurs gèrent les règles appliqué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 des 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 concernée, mais pas sur d'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 sur cette stratégie à tout 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. En outre, si vous déplacez un projet vers un autre nœud de la hiérarchie de l'organisation, la stratégie appliquée au projet n'est pas automatiquement modifiée. Vous devez supprimer la stratégie associée au projet, puis recréer la stratégie et spécifier le champ d'application.

Hiérarchie des règles appliqué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 constituent un mécanisme de regroupement par-dessus les projets. Les dossiers et les projets existent en tant que nœuds enfants de la ressource Organisation.

Le schéma suivant présente un exemple d'organisation contenant des dossiers pour chaque service, et contenant les 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 stratégie ciblée:

  • Les périmètres de service d'une règle de champ d'application ne peuvent restreindre que les ressources appartenant au champ d'application de 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 les projets se trouvent dans le dossier d'ingénierie.

    Si la stratégie de champ d'application 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 de champ d'application peut autoriser l'accès aux projets dans d'autres dossiers en utilisant des règles d'entrée et de sortie.

  • Les niveaux d'accès d'une règle de champ d'application 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 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 les niveaux d'accès des autres dossiers ne peuvent pas utiliser le niveau d'accès défini dans le dossier d'ingénierie.

Un emplacement, tel qu'un dossier, dans la hiérarchie des ressources de l'organisation example.com, peut avoir plusieurs stratégies contenant un niveau d'accès ou un périmètre de service. Lorsqu'il existe plusieurs stratégies, 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 en créer une pour chaque niveau d'une organisation. Par exemple, si le champ d'application de la stratégie 1 correspond au dossier "engineering", vous ne pouvez pas le définir comme le champ d'application d'une autre stratégie. Vous pouvez définir une autre stratégie avec le champ d'application défini sur le dossier enfant du dossier d'ingénierie, tel que example-prod.

  • Si le champ d'application d'une stratégie s'applique à un projet ou à un parent de projet, vous pouvez ajouter le projet à la stratégie. Toutefois, un projet ne peut être membre que d'un seul périmètre de service sur toutes les stratégies. 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 stratégie dont le champ d'application est défini sur le dossier d'ingénierie ou le champ d'application défini sur le projet "example-dev" peut également ajouter le projet "example-dev" à un périmètre défini dans l'un ou l'autre. Cependant, seule l'une de ces trois règles peut contenir ce projet.

Étapes suivantes