Présentation des 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 Google 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 la façon dont les ressources de votre organisation peuvent être utilisées.
  • 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 liées aux 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 d'administration

Une règle d'administration configure une seule contrainte qui limite 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 règle d'administration contient une ou plusieurs règles qui spécifient comment et si la contrainte doit être appliquée. Par exemple, une règle d'administration peut contenir une règle qui applique la contrainte uniquement aux ressources taguées environment=development, et une autre règle qui empêche l'application de la contrainte à d'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 d'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 toute votre organisation.

Concepts de règle d'administration

Contraintes

Une contrainte est un type particulier de restriction appliquée à un Google Cloud service ou à une liste de Google Cloud services. 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 Google Cloud service mappé sur cette contrainte et associé à cette ressource applique les restrictions configurées dans la règle d'administration.

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 contrainte en mode actif, en mode dry run ou les deux.

Les contraintes gérées comportent des paramètres de liste ou booléens déterminés par le service d'application Google Cloud . Les contraintes personnalisées sont fonctionnellement similaires aux contraintes gérées avec des paramètres booléens, et sont appliquées ou non.

Les contraintes gérées héritées comportent une ou plusieurs règles de liste ou règles booléennes en fonction du type de contrainte. Les règles de liste sont un ensemble de valeurs autorisées ou refusées. Les règles booléennes peuvent autoriser toutes les valeurs, refuser toutes les valeurs ou déterminer si une contrainte est appliquée ou non.

Contraintes gérées

Les contraintes gérées sont conçues pour remplacer les contraintes gérées héritées équivalentes, mais avec plus de flexibilité et une meilleure visibilité grâce aux outils Policy Intelligence. Ces contraintes ont une structure similaire à celle des contraintes de règles d'administration personnalisées, mais sont gérées par Google.

Si le type de contrainte de la contrainte gérée héritée équivalente est 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 le type de contrainte de la contrainte gérée héritée équivalente est une liste, 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 l'ajout des domaines example.com et altostrat.com 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 Créer des règles d'administration.

Contraintes personnalisées

Comme les contraintes gérées, les contraintes personnalisées autorisent ou limitent la création et la mise à jour des ressources. Toutefois, les contraintes personnalisées sont gérées par votre organisation et non par Google. Vous pouvez utiliser les outils Policy Intelligence 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 Services compatibles avec les contraintes personnalisées.

Pour en savoir plus sur l'utilisation des règles d'administration personnalisées, consultez Créer des contraintes personnalisées.

Pour obtenir une liste d'exemples de contraintes personnalisées, consultez la bibliothèque de règles d'administration personnalisées sur GitHub.

Contraintes gérées (héritées)

Les contraintes gérées héritées 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 service d'application Google Cloud évalue le type et la valeur de la contrainte pour déterminer la restriction appliquée.

Ces contraintes héritées étaient auparavant appelées contraintes prédéfinies.

Règles de la liste

Les contraintes gérées héritées avec des règles de liste autorisent ou refusent une liste de valeurs définie dans une règle d'administration. Ces contraintes héritées étaient auparavant appelées contraintes de liste. La liste des valeurs autorisées ou refusées 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 gérée héritée constraints/compute.trustedImageProjects accepte une liste d'ID de projet au format projects/PROJECT_ID.

Vous pouvez spécifier que toutes les valeurs sont autorisées, que toutes les valeurs sont refusées ou qu'une liste spécifique de valeurs est autorisée ou refusée. Lorsque vous spécifiez une liste de valeurs autorisées ou refusées, la règle d'administration évalue implicitement que seules ces valeurs sont autorisées ou refusées. Par exemple, si vous avez une contrainte qui n'autorise que projects/PROJECT_ID, toutes les autres valeurs sont implicitement refusées.

Les valeurs peuvent recevoir un préfixe au format prefix:value pour les contraintes qui les prennent en charge, ce qui confère à la valeur un sens supplémentaire :

  • is: : applique une comparaison à la valeur exacte. Il s'agit du même comportement que l'absence de préfixe, et il est obligatoire lorsque la valeur inclut un signe deux-points.

  • under: : applique une comparaison à la valeur et à toutes ses valeurs enfants. Si une ressource est autorisée ou refusée avec ce préfixe, ses ressources enfants sont également autorisées ou refusées. 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 refusée de la constraints/gcp.resourceLocations contrainte pour bloquer tous les emplacements inclus dans la us région.

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'administration suivante applique une contrainte gérée héritée qui autorise les instances de VM Compute Engine vm-1 et vm-2 dans organizations/1234567890123 à 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

Règles booléennes

Une contrainte gérée héritée avec une règle booléenne est appliquée ou non. Par exemple, constraints/compute.disableSerialPortAccess comporte deux états possibles :

  • Appliquée : 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.

Ces contraintes héritées étaient auparavant appelées contraintes booléennes.

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

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

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 de 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 conditionnelle à l'aide de tags, consultez Délimiter les règles d'administration 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 est transmise à tous les dossiers, projets et ressources de service descendants.

Vous pouvez définir une règle d'administration sur une ressource descendante qui remplace l'héritage ou hérite de la règle d'administration de la ressource parente. Les règles d'administration qui appliquent des contraintes gérées héritées sont fusionnées en fonction des règles d'évaluation de la hiérarchie. Ce système permet de contrôler précisément l'application de vos règles d'administration dans votre organisation et les exceptions que vous souhaitez apporter.

Pour en savoir plus, consultez Évaluation hiérarchique.

Cas de non-respect

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 sur une action ou un état dans lequel un service se trouve déjà, la règle est considérée comme non respectée, mais le service ne cesse 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 d'administration. Nous vous recommandons de tester et d'exécuter toutes les modifications apportées à vos règles d'administration. Avec Policy Intelligence, vous pouvez effectuer des tâches telles que les suivantes :

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

Étapes suivantes