Nous vous recommandons de définir des contraintes liées aux règles pour appliquer des configurations de ressources acceptables et éviter les configurations risquées. Le plan utilise un ensemble de contraintes liées aux règles d'administration et de validation IaC (Infrastructure as Code) dans votre pipeline. Ces contrôles empêchent la création de ressources qui ne respectent pas les directives de vos règles. L'application de ces contrôles dès le début de la conception et de la création de vos charges de travail vous permet d'éviter les tâches correctives ultérieurement.
Contraintes liées aux règles d'administration
Le service de règles d'administration applique des contraintes pour empêcher la création de certaines configurations de ressources dans votre organisation Google Cloud, y compris par un utilisateur disposant d'un rôle IAM approprié.
Le plan applique des règles au niveau du nœud d'organisation afin que ces contrôles soient hérités par tous les dossiers et projets de l'organisation. Ce groupe de règles est conçu pour empêcher certaines configurations à haut risque, telles que l'exposition d'une VM à l'Internet public ou l'octroi d'un accès public aux buckets de stockage, sauf si vous autorisez délibérément une exception à la règle.
Le tableau suivant présente les contraintes liées aux règles d'administration mises en œuvre dans le plan :
| Contrainte liée aux règles d'administration | Description |
|---|---|
| La virtualisation imbriquée sur les VM Compute Engine peut échapper à la surveillance et à d'autres outils de sécurité de vos VM si elle est mal configurée. Cette contrainte empêche la création de la virtualisation imbriquée. |
| Les rôles IAM tels que |
| Les sous-réseaux IPv6 externes peuvent être exposés à un accès Internet non autorisé s'ils sont mal configurés. Cette contrainte empêche la création de sous-réseaux IPv6 externes. |
| Le comportement par défaut des clés SSH dans les métadonnées peut autoriser un accès à distance non autorisé aux VM si des clés sont exposées. Cette contrainte applique l'utilisation de OS Login au lieu de clés SSH basées sur des métadonnées. |
|
Le transfert de protocole de VM pour les adresses IP externes peut entraîner une sortie Internet non autorisée si le transfert est mal configuré. Cette contrainte n'autorise le transfert de protocole de VM que pour les adresses internes. |
|
La suppression d'un projet hôte de VPC partagé peut perturber tous les projets de service qui utilisent des ressources réseau. Cette contrainte empêche la suppression accidentelle ou malveillante des projets hôtes de VPC partagé en empêchant la suppression des privilèges liés à ces projets. |
|
Un ancien paramètre de DNS interne global (à l'échelle du projet) n'est pas recommandé, car il réduit la disponibilité du service. Cette contrainte empêche l'utilisation de l'ancien paramètre. |
| Un réseau VPC par défaut et des règles de pare-feu VPC par défaut trop permissives sont créés dans chaque nouveau projet qui active l'API Compute Engine. Cette contrainte ignore la création du réseau et des règles de pare-feu VPC par défaut. |
| Par défaut, une VM est créée avec une adresse IPv4 externe pouvant entraîner un accès Internet non autorisé. Cette contrainte configure une liste d'autorisation d'adresses IP externes vide pouvant être utilisée par la VM et refuse toutes les autres. |
|
Par défaut, les contacts essentiels peuvent être configurés pour envoyer des notifications concernant votre domaine à n'importe quel autre domaine. Cette contrainte exige que seules les adresses e-mail des domaines approuvés soient définies comme destinataires des contacts essentiels. |
| Par défaut, des règles d'autorisation peuvent être accordées à tout compte Google, y compris aux comptes non gérés et aux comptes appartenant à des organisations externes. Cette contrainte garantit que les règles d'autorisation de votre organisation ne peuvent être accordées qu'aux comptes gérés de votre propre domaine. Vous pouvez éventuellement autoriser d'autres domaines. |
|
Par défaut, les comptes de service par défaut se voient automatiquement attribuer des rôles trop permissifs. Cette contrainte empêche les attributions automatiques de rôles IAM aux comptes de service par défaut. |
|
Les clés de compte de service sont des identifiants persistants à haut risque. Dans la plupart des cas, une alternative plus sécurisée aux clés de compte de service peut être utilisée. Cette contrainte empêche la création de clés de compte de service. |
|
L'importation du matériel de clé de compte de service peut augmenter le risque si celui-ci est exposé. Cette contrainte empêche l'importation de clés de compte de service. |
|
Les instances Cloud SQL peuvent être exposées à un accès Internet non authentifié si elles sont configurées pour utiliser des réseaux autorisés sans proxy d'authentification Cloud SQL. Cette règle empêche la configuration des réseaux autorisés pour l'accès à la base de données, et force l'utilisation du proxy d'authentification Cloud SQL à la place. |
| Les instances Cloud SQL peuvent être exposées à un accès Internet non authentifié si elles sont créées avec des adresses IP publiques. Cette contrainte empêche les adresses IP publiques dans les instances Cloud SQL. |
| Par défaut, les objets dans Cloud Storage sont accessibles via les anciennes listes de contrôle d'accès (LCA) au lieu d'IAM, ce qui peut entraîner des contrôles d'accès incohérents et une exposition accidentelle en cas de mauvaise configuration. L'accès aux anciennes LCA n'est pas concerné par la contrainte |
|
Les buckets Cloud Storage peuvent être exposés à un accès Internet non authentifié s'ils sont mal configurés. Cette contrainte empêche les LCA et les autorisations IAM d'accorder l'accès à |
Ces règles constituent un point de départ que nous recommandons pour la plupart des clients et dans la plupart des scénarios, mais vous devrez peut-être modifier les contraintes liées aux règles d'administration pour les adapter à certains types de charges de travail. Par exemple, une charge de travail qui utilise un bucket Cloud Storage comme backend pour que Cloud CDN héberge des ressources publiques est bloquée par storage.publicAccessPrevention, ou une application Cloud Run publique qui ne requiert pas d'authentification est bloquée par iam.allowedPolicyMemberDomains. Dans ce cas, modifiez la règle d'administration au niveau du dossier ou du projet pour autoriser une exception spécifique.
Vous pouvez également ajouter des contraintes à la règle d'administration de manière conditionnelle en définissant un tag qui accorde une exception ou une application de règle, puis en l'appliquant à des projets et dossiers.
Pour découvrir d'autres contraintes, consultez les sections Contraintes disponibles et Contraintes personnalisées.
Validation de l'Infrastructure as Code avant le déploiement
Le plan utilise une approche GitOps pour gérer l'infrastructure, ce qui signifie que toutes les modifications apportées à l'infrastructure sont implémentées via l'IaC avec contrôle des versions et peuvent être validées avant le déploiement.
Les règles appliquées dans le plan définissent les configurations de ressources acceptables pouvant être déployées par votre pipeline. Si le code envoyé à votre dépôt GitHub ne passe pas les vérifications des règles, aucune ressource n'est déployée.
Pour en savoir plus sur l'utilisation des pipelines et sur l'application des contrôles via l'automatisation CI/CD, consultez la page Méthodologie de déploiement.
Étapes suivantes
- Découvrez la méthodologie de déploiement (document suivant de cette série).