Configurer des stratégies de sécurité hiérarchiques

Cette page explique comment configurer des stratégies de sécurité hiérarchiques pour protéger votre organisation, vos dossiers ou vos projets. Avant de configurer des stratégies de sécurité hiérarchiques, assurez-vous de maîtriser les informations de la présentation des stratégies de sécurité hiérarchiques.

Configurer les autorisations IAM pour les stratégies de sécurité hiérarchiques

Les opérations suivantes nécessitent que vous disposiez du rôle IAM Administrateur de la stratégie de sécurité de l'organisation Compute (roles/compute.orgSecurityPolicyAdmin) sur le nœud de la hiérarchie de ressources cible ou sur la stratégie elle-même si elle existe déjà :

  • Créer une stratégie de sécurité hiérarchique
  • Modifier une stratégie de sécurité hiérarchique en ajoutant, en mettant à jour ou en supprimant des règles
  • Supprimer une stratégie de sécurité hiérarchique

Pour effectuer les opérations suivantes, vous devez disposer du rôle IAM Administrateur des ressources de l'organisation Compute (roles/compute.orgSecurityResourceAdmin) sur le nœud de la hiérarchie des ressources cible, en plus du rôle Administrateur de la stratégie de sécurité de l'organisation Compute (roles/compute.orgSecurityPolicyAdmin) ou Utilisateur de la stratégie de sécurité de l'organisation Compute (roles/compute.orgSecurityPolicyUser) sur le nœud de la hiérarchie des ressources cible ou sur la stratégie elle-même :

  • Associer une stratégie de sécurité hiérarchique à un nœud de hiérarchie des ressources

Enfin, consultez le tableau suivant pour obtenir la liste des opérations diverses que vous pouvez effectuer si vous disposez de l'un des rôles listés :

Opérations Rôles
Afficher toutes les règles Cloud Armor effectives pour une ressource de backend
Afficher les ressources de backend effectives couvertes par un organizationSecurityPolicy

Configurer des stratégies de sécurité hiérarchiques

Les sections suivantes expliquent comment créer des stratégies de sécurité hiérarchiques, les associer à des nœuds de la hiérarchie des ressources, les déplacer entre les nœuds, les supprimer et afficher toutes les règles de stratégie de sécurité Cloud Armor qui s'appliquent à une ressource protégée.

Créer une stratégie de sécurité hiérarchique

Pour créer une stratégie de sécurité hiérarchique, utilisez la commande gcloud compute org-security-policies create. Vous créez la stratégie de sécurité hiérarchique sous une organisation ou un dossier à l'aide du flag --organization ou --folder, ainsi que du ORGANIZATION_ID ou FOLDER_ID correspondant. Utilisez les exemples suivants pour créer des stratégies de sécurité hiérarchiques, en remplaçant POLICY_NAME par le nom que vous souhaitez attribuer à la nouvelle stratégie de sécurité :

  • Créez une stratégie de sécurité hiérarchique au niveau de l'organisation :

    gcloud compute org-security-policies create \
    --organization=ORGANIZATION_ID \
    --type=CLOUD_ARMOR \
    --short-name=POLICY_NAME

  • Créez une stratégie de sécurité hiérarchique au niveau du dossier :

    gcloud compute org-security-policies create \ 
    --folder=FOLDER_ID \
    --type=CLOUD_ARMOR \
    --short-name=POLICY_NAME

Associer une stratégie de sécurité existante à un nœud de hiérarchie des ressources

Si vous disposez déjà d'une stratégie de sécurité, vous pouvez l'associer à un nœud de hiérarchie des ressources à l'aide de la commande gcloud compute org-security-policies associations create.

  • Associez une stratégie de sécurité hiérarchique à une organisation :

    gcloud compute org-security-policies associations create \
    --security-policy=POLICY_ID \
    --organization=ORGANIZATION_ID \
    --name=ASSOCIATION_NAME

  • Associez une stratégie de sécurité hiérarchique à un dossier :

    gcloud compute org-security-policies associations create \
    --security-policy=POLICY_ID \
    --folder=FOLDER_ID \
    --name=ASSOCIATION_NAME

  • Associez une stratégie de sécurité hiérarchique à un projet :

    gcloud compute org-security-policies associations create \
    --security-policy=POLICY_ID \
    --project-number=PROJECT_ID \
    --name=ASSOCIATION_NAME

Remplacez les éléments suivants :

  • POLICY_ID : ID de la stratégie de sécurité
  • ORGANIZATION_ID : ID de l'organisation
  • ASSOCIATION_NAME : nom de l'association
  • FOLDER_ID : ID du dossier
  • PROJECT_ID : ID du projet

Exclure des projets des stratégies de sécurité hiérarchiques

De plus, vous pouvez exclure des projets de vos stratégies de sécurité hiérarchiques au niveau du dossier, et vous pouvez exclure des projets et des dossiers de vos stratégies de sécurité hiérarchiques au niveau de l'organisation :

  • Vous pouvez exclure des projets d'une stratégie de sécurité hiérarchique à l'aide de la commande gcloud compute org-security-policies associations create avec le flag --excluded-projects.

    L'exemple de commande suivant associe la stratégie de sécurité example-policy à l'organisation 10000001, tout en excluant le projet dont l'ID est 2000000002 :

    gcloud compute org-security-policies associations create \
    --security-policy=example-policy \
    --excluded-projects="projects/2000000002" \
    --organization=10000001

  • Vous pouvez exclure des dossiers d'une stratégie de sécurité hiérarchique au niveau de l'organisation à l'aide de la commande gcloud compute org-security-policies associations create avec le flag --excluded-folders.

    L'exemple de commande suivant associe la stratégie de sécurité example-policy à l'organisation 10000001, tout en excluant le dossier dont l'ID est 3000000003 :

    gcloud compute org-security-policies associations create \
    --security-policy=example-policy \
    --excluded-folders="folders/3000000003" \
    --organization=10000001

Déplacer une stratégie de sécurité hiérarchique

Vous pouvez modifier le parent d'une stratégie de sécurité hiérarchique à l'aide de la commande gcloud compute org-security-policies move pour déplacer la stratégie de sécurité hiérarchique sous un autre nœud de hiérarchie des ressources parent. Vous devez indiquer la source comme premier flag et la destination comme deuxième flag. Le déplacement d'une stratégie de sécurité hiérarchique modifie sa propriété, et non les ressources auxquelles elle est associée. Seuls les organisations et les dossiers peuvent être propriétaires de stratégies de sécurité hiérarchiques. Vous ne pouvez donc pas les déplacer vers des projets.

Dans l'exemple suivant, vous déplacez une stratégie de sécurité hiérarchique de l'organisation ORGANIZATION_ID vers le dossier FOLDER_ID :

gcloud compute org-security-policies move policy-1 \
    --organization ORGANIZATION_ID \
    --folder FOLDER_ID

Supprimer une stratégie de sécurité hiérarchique

Avant de pouvoir supprimer une stratégie de sécurité hiérarchique, vous devez d'abord supprimer toutes les associations de la stratégie avec les nœuds de hiérarchie des ressources. Dans l'exemple suivant, vous utilisez la commande gcloud compute org-security-policies associations delete pour supprimer l'association nommée ASSOCIATION_NAME entre la stratégie de sécurité hiérarchique portant le nom POLICY_NAME et l'organisation ORGANIZATION_ID :

gcloud compute org-security-policies associations delete ASSOCIATION_NAME \
    --security-policy=POLICY_NAME \
    --organization=ORGANIZATION_ID

Si ce n'est pas la seule association de la stratégie de sécurité, répétez l'étape précédente pour chaque association. Lorsque la stratégie de sécurité hiérarchique n'est associée à aucun élément, vous pouvez la supprimer à l'aide de la commande gcloud compute org-security-policies delete, comme dans l'exemple suivant :

gcloud compute org-security-policies delete POLICY_NAME \
    --organization=ORGANIZATION_ID

Afficher toutes les règles Cloud Armor effectives pour une ressource protégée

Vous pouvez afficher toutes les règles de stratégie de sécurité Cloud Armor qui s'appliquent à une ressource protégée à l'aide de la commande gcloud compute backend-services get-effective-security-policies.

gcloud compute backend-services get-effective-security-policies PROTECTED_RESOURCE

Remplacez PROTECTED_RESOURCE par le nom de la ressource protégée que vous souhaitez vérifier.

Lorsque vous exécutez la commande gcloud compute backend-services get-effective-security-policies sur un service de backend dans un projet qui hérite d'une stratégie de sécurité hiérarchique, la réponse peut inclure la stratégie de sécurité hiérarchique, même si le type de ce service de backend spécifique n'est pas compatible avec les stratégies de sécurité hiérarchiques. Pour obtenir la liste des configurations de backend compatibles avec les stratégies de sécurité hiérarchiques, consultez la présentation des stratégies de sécurité hiérarchiques.

Cas d'utilisation

Les sections suivantes décrivent les cas d'utilisation des stratégies de sécurité hiérarchiques.

Refuser le trafic provenant d'un ensemble d'adresses IP vers tous les équilibreurs de charge d'application de votre organisation

Vous pouvez utiliser des stratégies de sécurité hiérarchiques pour gérer une liste d'adresses IP qui ne sont pas autorisées à accéder à l'ensemble du réseau de votre organisation, ou pour refuser le trafic provenant d'une région ou d'un pays spécifiques. Cela peut vous aider à résoudre les problèmes de sécurité spécifiques à votre entreprise ou à respecter la conformité. Les étapes suivantes vous montrent comment créer une stratégie de sécurité hiérarchique au niveau de l'organisation qui refuse le trafic provenant de la plage d'adresses IP 192.0.2.0/24 :

  1. Créez une stratégie de sécurité hiérarchique appelée org-level-deny-ip-policy, associée à une organisation dont l'ID est 1000000001 :

     gcloud compute org-security-policies create \
     --organization=1000000001 \
     --type=CLOUD_ARMOR \
     --description= "this org policy denies a set of IP addresses for all resources" \
     --short-name=org-level-deny-ip-policy

  2. Ajoutez une règle avec la priorité 1000, une condition de correspondance pour la plage d'adresses IP 192.0.2.0/24 et une action deny :

     gcloud compute org-security-policies rules create 1000 \
     --action=deny \
     --security-policy=org-level-deny-ip-policy \
     --organization=1000000001 \
     --description "Deny traffic from 192.0.2.0/24" \
     --src-ip-ranges "192.0.2.0/24"

  3. Enfin, associez la stratégie de sécurité à l'organisation, en refusant les requêtes provenant de l'adresse IP 192.0.2.0/24 à tous les services de l'organisation :

     gcloud compute org-security-policies associations create \
     --security-policy=org-level-deny-ip-policy \
     --organization=ORGANIZATION_ID

Accorder à un ensemble d'adresses IP sources l'accès à certains projets de votre organisation

Vous pouvez accorder l'accès à certains projets de votre organisation à une ou plusieurs adresses IP. Vous pouvez le faire si vous disposez d'un proxy de confiance en amont que vous souhaitez exclure de l'évaluation des règles pour certains de vos projets uniquement. Dans l'exemple suivant basé sur Cloud CDN, vous utilisez une stratégie de sécurité hiérarchique au niveau du dossier pour accorder à la plage d'adresses IP 192.0.2.0/24 l'accès aux projets nommés project-1, project-2 et project-3 dans l'organisation 10000001 :

  1. Utilisez les commandes suivantes pour déplacer project-1, project-2 et project-3 dans un dossier dont l'ID est 20000002 :

    gcloud projects move project-1 --folder=20000002
gcloud projects move project-2 --folder=20000002
gcloud projects move project-3 --folder=20000002

  2. Exécutez la commande suivante pour créer une stratégie de sécurité nommée org-level-proxy-filtering :

     gcloud compute org-security-policies create \
     --folder=20000002 \
     --type=CLOUD_ARMOR \
     --short-name=org-level-proxy-filtering

  3. Ajoutez une règle de priorité 1000 avec une condition de correspondance pour la plage d'adresses IP 192.0.2.0/24 et une action de règle goto_next. Si une requête correspond à cette condition, Cloud Armor cesse d'évaluer les règles de cette stratégie de sécurité :

     gcloud compute org-security-policies rules create 1000 \
     --action=goto_next \
     --security-policy=org-level-proxy-filtering \
     --organization=10000001 \
     --src-ip-ranges="192.0.2.0/24"

  4. Facultatif : Si vous souhaitez appliquer des règles de stratégie de sécurité à ces projets pour les requêtes qui ne proviennent pas de 192.0.2.0/24, ajoutez d'autres règles avec une priorité inférieure à 1000. Vous pourrez effectuer cette étape ultérieurement.

  5. Utilisez la commande suivante pour associer la stratégie au dossier dont l'ID est 20000002, dans lequel vous avez déplacé les projets à l'étape 1 :

     gcloud compute org-security-policies associations create \
     --security-policy=org-level-proxy-filtering \
     --folder=20000002

Étape suivante