Configurer des règles 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 règles de sécurité hiérarchiques, assurez-vous de maîtriser les informations de la présentation des règles 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 règles de sécurité Compute pour l'organisation (roles/compute.orgSecurityPolicyAdmin) sur le nœud de la hiérarchie de ressources cible ou sur la règle 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 des règles de sécurité de l'organisation Compute (roles/compute.orgSecurityPolicyAdmin) ou Utilisateur des règles de sécurité de l'organisation Compute (roles/compute.orgSecurityPolicyUser) sur le nœud de la hiérarchie des ressources cible ou sur la règle elle-même :

  • Associer une stratégie de sécurité hiérarchique à un nœud de hiérarchie de 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 Google Cloud Armor effectives pour une ressource de backend
Afficher les ressources de backend effectives couvertes par un organizationSecurityPolicy

Configurer des règles 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 hiérarchie de ressources, les déplacer entre les nœuds, les supprimer et afficher toutes les règles de stratégie de sécurité Google Cloud Armor qui s'appliquent à une ressource protégée.

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

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

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

    gcloud beta 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 beta 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 de ressources

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

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

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

    gcloud beta 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 beta 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 beta compute org-security-policies associations create \
      --security-policy=POLICY_ID \
      --project-number=PROJECT_ID \
      --name=ASSOCIATION_NAME
    

Exclure des projets des règles 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 à la fois 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 beta compute org-security-policies associations create avec l'option --excluded-projects.

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

    gcloud beta 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 beta compute org-security-policies associations create avec l'option --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 beta compute org-security-policies associations create \
        --security-policy=example-policy \
        --excluded-folders="folders/3000000003" \
        --organization=10000001
    

Déplacer une règle de sécurité hiérarchique

Vous pouvez modifier le parent d'une règle de sécurité hiérarchique à l'aide de gcloud beta compute org-security-policies move pour déplacer la règle de sécurité hiérarchique sous un autre nœud de hiérarchie de ressources parent. Vous devez indiquer la source comme premier indicateur et la destination comme deuxième indicateur. Le déplacement d'une règle de sécurité hiérarchique modifie sa propriété, et non les ressources auxquelles elle est associée. Seules 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 sous 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 beta 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 la hiérarchie des ressources. Dans l'exemple suivant, vous utilisez la commande beta 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 beta 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 compute org-security-policies delete, comme dans l'exemple suivant :

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

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

Vous pouvez afficher toutes les règles de stratégie de sécurité Google Cloud Armor qui s'appliquent à une ressource protégée à l'aide de la commande gcloud beta compute backend-services get-effective-security-policies. Dans l'exemple suivant, remplacez RESOURCE_NAME par le nom de la ressource protégée que vous souhaitez vérifier :

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

Lorsque vous exécutez la commande gcloud beta compute 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 règles de sécurité hiérarchiques, consultez la présentation des règles 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 règles 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 à rester conforme. Les étapes suivantes vous montrent comment créer une règle 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 beta compute org-security-policies create \
         --organization=1000000001 \
         --type=CLOUD_ARMOR \
         --description= "this is an org policy to deny 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 beta 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 beta 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 en amont de confiance 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 règle 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 beta 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, Google Cloud Armor cesse d'évaluer les règles de cette stratégie de sécurité :

     gcloud beta 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 beta compute org-security-policies associations create \
         --security-policy=org-level-proxy-filtering \
         --folder=20000002
    

Étapes suivantes