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 d'entreprise

Une règle d'administration configure une seule contrainte qui restreint un ou plusieurs services Google Cloud . 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 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 d'organisation, l'administrateur des règles d'administration peut contrôler l'application de cette règle 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 sur 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 blueprint est ensuite défini sur une ressource de votre hiérarchie de 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.

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 simulation ou dans les deux.

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

Les contraintes personnalisées sont fonctionnellement similaires aux contraintes gérées avec des paramètres booléens. Elles sont appliquées ou non.

Les anciennes contraintes géré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 anciennes contraintes gérées équivalentes, mais avec plus de flexibilité et de renseignements grâce aux outils d'intelligence des règles. Ces contraintes ont une structure semblable à celle des contraintes de règles d'administration personnalisées, mais sont gérées par Google.

Si la contrainte gérée ancienne équivalente est de type 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 gérée ancienne équivalente est de type 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 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 Utiliser des contraintes.

Contraintes personnalisées

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

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

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

Contraintes gérées (ancienne version)

Les anciennes contraintes géré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 serviceGoogle Cloud responsable de l'application de la contrainte évalue son type et les valeurs qui lui sont associées pour déterminer la restriction appliquée.

Ces anciennes contraintes étaient auparavant appelées contraintes prédéfinies.

Lister les règles

Les anciennes contraintes gérées avec des règles de liste autorisent ou refusent une liste de valeurs définies dans une règle d'administration. Ces anciennes contraintes é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, l'ancienne contrainte gérée 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 confère à la valeur un sens supplémentaire, par exemple :

  • 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 à la 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 correspondre à 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 des valeurs refusées 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'administration de l'organisation suivante applique une ancienne contrainte géré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 ancienne contrainte gérée avec une règle booléenne est appliquée ou non. Par exemple, constraints/compute.disableSerialPortAccess a 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 est appliqué.

Ces anciennes contraintes étaient auparavant appelées contraintes booléennes.

La règle d'administration suivante applique une ancienne contrainte géré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 en mode dry run

Une règle d'administration en mode de simulation est créée et appliquée de la même manière que les autres règles d'administration d'administration. Les violations de la règle sont consignées dans les journaux d'audit, mais les actions qui enfreignent la règle ne sont pas refusées.

Vous pouvez utiliser les règles d'administration en mode de simulation pour surveiller l'impact des modifications de règles sur vos workflows avant leur application. Pour en savoir plus, consultez 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 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éfinir une règle 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, tous les dossiers enfants, projets et ressources de service héritent de la configuration de ces restrictions telle que définie par la règle.

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 Comprendre le processus d'évaluation hiérarchique.

Cas de non-respect

Un non-respect survient lorsqu'un service Google Cloud 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 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à engagé, la règle est considérée comme étant non respectée, mais le service ne met pas fin à son comportement actuel. 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 règles de l'organisation. Nous vous recommandons de tester et de simuler tous les changements apportés aux règles de votre organisation. Avec Policy Intelligence, vous pouvez effectuer les tâches suivantes :

Pour en savoir plus sur ces outils et les autres outils Policy Intelligence, consultez la présentation de Policy Intelligence.

Étapes suivantes