Présentation du service de règles d'administration

Grâce au service de règles d'administration, vous disposez d'un contrôle centralisé et automatisé sur les ressources cloud de votre organisation. En tant qu'administrateur des règles d'administration, vous pouvez configurer des contraintes sur l'ensemble de votre hiérarchie des ressources.

Avantages

  • Centralisez le contrôle pour configurer des restrictions sur l'utilisation des ressources de votre organisation.
  • Définissez et établissez des garde-fous pour que vos équipes de développement puissent respecter les limites de conformité.
  • Aidez les porteurs de projets et leurs équipes à agir rapidement sans craindre de se soustraire à la conformité.

Cas d'utilisation courants

Les règles d'administration vous permettent d'effectuer les opérations suivantes:

Il existe de nombreuses autres contraintes qui vous permettent de contrôler avec précision les ressources de votre organisation. Pour en savoir plus, consultez la liste de toutes les contraintes du service de règles d'administration.

Différences avec Identity and Access Management

Identity and Access Management se concentre sur la réponse à la question qui, et permet à l'administrateur d'autoriser une personne à prendre des mesures sur les ressources spécifiques en fonction des autorisations.

La règle d'administration met l'accent sur la réponse à la question quoi, et permet à l'administrateur de définir des restrictions sur des ressources spécifiques afin de déterminer leur configuration.

Fonctionnement des règles de l'organisation

Une règle d'administration configure une seule contrainte qui restreint un ou plusieurs Google Cloud services. La règle d'administration est définie sur une ressource d'organisation, de dossier ou de projet pour appliquer la contrainte à cette ressource et à toutes les ressources enfants.

Une stratégie d'administration contient une ou plusieurs règles qui spécifient comment appliquer la contrainte et si elle doit être appliquée. Par exemple, une règle d'administration peut contenir une règle qui n'applique la contrainte qu'aux ressources taguées environment=development et une autre règle qui empêche l'application de la contrainte aux autres ressources.

Les descendants de la ressource à laquelle la règle d'administration est associée héritent de la règle d'administration. En appliquant une règle d'administration à la ressource de l'organisation, l'administrateur des règles d'administration peut contrôler l'application de cette règle d'administration et la configuration des restrictions dans l'ensemble de votre organisation.

Concepts de règle d'administration

Contraintes

Une contrainte est un type particulier de restriction appliqué à un serviceGoogle Cloud ou à une liste de services Google Cloud . On peut la considérer comme un modèle définissant les comportements à contrôler. Par exemple, vous pouvez empêcher les ressources de projet d'accéder aux ressources de stockage Compute Engine à l'aide de la contrainte compute.storageResourceUseRestrictions.

Ce modèle est ensuite défini sur une ressource de votre hiérarchie des ressources en tant que règle d'administration, qui applique les règles définies dans la contrainte. Le service Google Cloud mappé sur cette contrainte et associé à cette ressource applique les restrictions configurées dans la règle d'administration de l'organisation.

Une règle d'administration est définie dans un fichier YAML ou JSON par la contrainte qu'elle applique et, éventuellement, par les conditions dans lesquelles la contrainte est appliquée. Chaque règle d'administration applique exactement une seule contrainte en mode actif, en mode simulation ou les deux.

Les contraintes prédéfinies ont un type de contrainte de liste ou booléen, qui détermine les valeurs pouvant être utilisées pour vérifier l'application. Le serviceGoogle Cloud responsable de l'application de la contrainte évalue le type et les valeurs qui lui sont associés pour déterminer la restriction appliquée.

Les contraintes personnalisées sont fonctionnellement similaires aux contraintes booléennes et sont appliquées ou non.

Les contraintes gérées comportent des paramètres de liste ou booléens. Les paramètres disponibles sont déterminés par le service Google Cloud d'application.

Contraintes de liste

Une contrainte de liste est une contrainte prédéfinie qui autorise ou interdit une liste de valeurs définie dans une règle d'administration. Cette liste de valeurs est exprimée sous forme de chaîne de sous-arborescence hiérarchique. La chaîne de sous-arborescence spécifie le type de ressource auquel elle s'applique. Par exemple, la contrainte de liste constraints/compute.trustedImageProjects accepte une liste d'ID de projet sous la forme projects/PROJECT_ID.

Les valeurs peuvent recevoir un préfixe sous la forme prefix:value pour les contraintes qui les acceptent, ce qui leur donne un sens supplémentaire:

  • is: : applique une comparaison par rapport à la valeur exacte. Ce comportement est le même que celui applicable en l'absence de préfixe ; il est requis lorsque la valeur inclut le caractère deux-points.

  • under: : applique une comparaison à une valeur et à toutes ses valeurs enfants. Si une ressource est autorisée ou refusée via ce préfixe, ses ressources enfants le seront également. La valeur fournie doit être l'ID d'une ressource d'organisation, de dossier ou de projet.

  • in: : applique une comparaison à toutes les ressources qui incluent cette valeur. Par exemple, vous pouvez ajouter in:us-locations à la liste de refus de la contrainte constraints/gcp.resourceLocations pour bloquer tous les emplacements inclus dans la région us.

Si aucune liste de valeurs n'est fournie ou si la règle d'administration est définie sur la valeur par défaut gérée par Google, le comportement par défaut de la contrainte prend effet, ce qui autorise ou refuse toutes les valeurs.

La règle d'organisation suivante applique une contrainte de liste qui permet aux instances de VM Compute Engine vm-1 et vm-2 dans organizations/1234567890123 d'accéder aux adresses IP externes:

name: organizations/1234567890123/policies/compute.vmExternalIpAccess
spec:
  rules:
  - values:
      allowedValues:
      - is:projects/project_a/zones/us-central1-a/instances/vm-1
      - is:projects/project_b/zones/us-central1-a/instances/vm-2

Contraintes booléennes

Une contrainte booléenne est une contrainte prédéfinie qui est appliquée ou non. Par exemple, la contrainte prédéfinie constraints/compute.disableSerialPortAccess a deux états possibles:

  • Appliqué : la contrainte est appliquée et l'accès au port série n'est pas autorisé.
  • Non appliquée : la contrainte disableSerialPortAccess n'est ni appliquée ni vérifiée. L'accès au port série est donc autorisé.

Si la règle d'administration est définie sur la valeur par défaut gérée par Google, le comportement par défaut de la contrainte prend effet.

La règle d'administration suivante applique une contrainte prédéfinie qui désactive la création de comptes de service externes dans organizations/1234567890123:

name: organizations/1234567890123/policies/iam.disableServiceAccountCreation
spec:
  rules:
  - enforce: true

Contraintes gérées

Les contraintes gérées sont des contraintes créées sur la plate-forme de règles d'administration personnalisées. La plate-forme de règles d'organisation personnalisée permet de concevoir des règles d'organisation avec plus de flexibilité et avec des insights plus précis grâce aux outils Policy Intelligence.

Les contraintes gérées sont conçues pour remplacer les contraintes prédéfinies équivalentes. Si la contrainte prédéfinie équivalente a un type de contrainte booléen, la contrainte gérée peut être appliquée ou non de la même manière. Par exemple, la règle d'administration suivante applique iam.managed.disableServiceAccountCreation, qui est la contrainte équivalente à iam.disableServiceAccountCreation:

name: organizations/1234567890123/policies/iam.managed.disableServiceAccountCreation
spec:
  rules:
  - enforce: true

Si la contrainte prédéfinie équivalente a un type de liste de contraintes, la contrainte gérée permet de définir des paramètres qui définissent les ressources et les comportements limités par la contrainte. Par exemple, la règle d'administration suivante applique une contrainte gérée qui n'autorise que les domaines example.com et altostrat.com à être ajoutés aux contacts essentiels pour organizations/1234567890123:

name: organizations/1234567890123/policies/essentialcontacts.managed.allowedContactDomains
spec:
   rules:
     - enforce: true
       parameters:
          allowedDomains:
               - @example.com
               - @altostrat.com

Pour en savoir plus sur l'utilisation des contraintes gérées, consultez la page Utiliser des contraintes.

Contraintes personnalisées

Les contraintes personnalisées autorisent ou limitent la création et la mise à jour de ressources de la même manière que les contraintes booléennes, mais permettent aux administrateurs de configurer des conditions en fonction des paramètres de requête et d'autres métadonnées. Vous pouvez utiliser les outils d'intelligence des règles pour tester et analyser vos règles d'administration personnalisées.

Pour obtenir la liste des ressources de service compatibles avec les contraintes personnalisées, consultez la page Services compatibles avec les contraintes personnalisées.

Pour en savoir plus sur l'utilisation des règles d'administration personnalisées, consultez la page Créer et gérer des règles d'administration personnalisées.

Règles d'administration en mode dry run

Une règle d'administration en mode simulation est créée et appliquée de la même manière que les autres règles d'administration d'administration. Les cas de non-respect de la règle sont consignés dans le journal d'audit, mais les actions non conformes ne sont pas refusées.

Vous pouvez utiliser les règles d'administration en mode simulation pour surveiller l'impact des modifications de règles sur vos workflows avant leur application. Pour en savoir plus, consultez la section Créer une règle d'administration en mode simulation.

Règles d'administration conditionnelles

Les tags permettent d'appliquer des contraintes de manière conditionnelle selon qu'une ressource possède un tag spécifique ou non. Vous pouvez utiliser des tags et l'application conditionnelle des contraintes pour fournir un contrôle centralisé des ressources de votre hiérarchie.

Pour en savoir plus sur les tags, consultez la page Présentation des tags. Pour découvrir comment définir une règle d'administration d'organisation conditionnelle à l'aide de tags, consultez la page Définir une règle d'administration d'organisation avec des tags.

Héritage

Lorsqu'une règle d'administration est définie sur une ressource, tous les descendants de cette ressource héritent de la règle d'administration par défaut. Si vous définissez une règle d'administration sur la ressource d'organisation, la configuration des restrictions définies par cette règle sera transmise à tous les dossiers enfants, projets et ressources de service.

Vous pouvez définir une règle d'administration sur une ressource descendante qui écrase l'héritage ou hérite de la règle d'administration de la ressource parente. Dans ce dernier cas, les deux règles d'administration sont fusionnées en fonction des règles d'évaluation hiérarchique. Cela permet de contrôler précisément l'application des règles d'administration d'administration dans votre organisation ainsi que les emplacements où vous souhaitez créer des exceptions.

Pour en savoir plus, consultez la page Comprendre le processus d'évaluation hiérarchique.

Infractions

Un non-respect survient lorsqu'un Google Cloud service agit ou se trouve dans un état opposé à la configuration de la restriction de la règle d'administration dans le champ d'application de sa hiérarchie des ressources. Google Cloud Les services appliquent des contraintes pour empêcher le non-respect des règles, mais l'application de nouvelles règles d'administration n'est généralement pas rétroactive. Si une contrainte liée à une règle d'administration est appliquée de manière rétroactive, elle est libellée comme telle sur la page Contraintes liées aux règles d'administration.

Si une nouvelle règle d'administration définit une restriction applicable à une action ou un état dans lequel un service est déjà intégré, le système considère bien qu'il y a violation de la règle mais le service n'arrête pas son comportement d'origine. Vous devrez traiter ce non-respect manuellement. Cela évite le risque qu'une nouvelle règle d'administration arrête complètement la continuité de votre activité.

Policy Intelligence

Policy Intelligence est une suite d'outils conçus pour vous aider à gérer les stratégies de sécurité. Ces outils peuvent vous aider à comprendre l'utilisation des ressources, à comprendre et à améliorer les stratégies de sécurité existantes et à éviter les erreurs de configuration des règles.

Certains outils Policy Intelligence sont spécialement conçus pour vous aider à tester et à analyser les règles du service de stratégie d'organisation. Nous vous recommandons de tester et d'effectuer un test avant de déployer toutes les modifications apportées aux règles de votre organisation. Avec l'intelligence des règles, vous pouvez effectuer les tâches suivantes:

Pour en savoir plus sur ces outils et les autres outils Policy Intelligence, consultez la page Présentation des outils Policy Intelligence.

Étapes suivantes