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'organisationFOLDER_ID
: ID du dossierPROJECT_ID
: ID du projetAssociez 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'organisation10000001
, tout en excluant le projet dont l'ID est2000000002
: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'organisation10000001
, tout en excluant le dossier dont l'ID est3000000003
: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
:
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
Ajoutez une règle avec la priorité
1000
, une condition de correspondance pour la plage d'adresses IP192.0.2.0/24
et une actiondeny
: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"
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
:
Utilisez les commandes suivantes pour déplacer
project-1
,project-2
etproject-3
dans un dossier dont l'ID est20000002
:gcloud projects move project-1 --folder=20000002 gcloud projects move project-2 --folder=20000002 gcloud projects move project-3 --folder=20000002
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
Ajoutez une règle de priorité
1000
avec une condition de correspondance pour la plage d'adresses IP192.0.2.0/24
et une action de règlegoto_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"
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.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