Présentation des stratégies de sécurité hiérarchiques

Les stratégies de sécurité hiérarchiques sont une catégorie de stratégies de sécurité qui étendent la portée du pare-feu d'application Web (WAF) et de la protection DDoS de Cloud Armor au-delà des projets individuels. Elles sont associées au niveau de l'organisation, d'un dossier ou d'un projet. Elles diffèrent des stratégies de sécurité au niveau du service, qui sont associées directement aux services de backend ou aux buckets backend.

Lorsque vous configurez une stratégie de sécurité hiérarchique au niveau de l'organisation ou d'un dossier, les projets à des niveaux inférieurs de la hiérarchie héritent de cette stratégie de sécurité. Cet héritage vous permet de configurer des règles de stratégie de sécurité que vous souhaitez appliquer à tous les projets ou à plusieurs projets de votre organisation. Cela permet une application centralisée et cohérente de la sécurité dans votre environnement Google Cloud .

Cette page explique en quoi les stratégies de sécurité hiérarchiques diffèrent des stratégies de sécurité au niveau du service. Avant de continuer, lisez la présentation des stratégies de sécurité pour vous assurer de bien comprendre leur fonctionnement. Nous vous recommandons également de vous familiariser avec la hiérarchie des ressources.

Cas d'utilisation

Dans les grandes organisations, la gestion des règles de sécurité dans de nombreux projets peut s'avérer complexe et chronophage. Les stratégies de sécurité hiérarchiques offrent les avantages suivants pour vous aider à surmonter ces difficultés :

Contrôle centralisé : permet aux administrateurs au niveau de l'organisation et des dossiers de définir et d'appliquer des stratégies de sécurité dans plusieurs projets.
Cohérence : assure une stratégie de sécurité uniforme dans toute l'organisation, en réduisant le risque d'erreurs de configuration et de failles de sécurité.
Efficacité : optimise le déploiement des mises à jour de sécurité et des mesures d'atténuation, comme le blocage de plages d'adresses IP spécifiques ou la résolution de failles critiques, sur un grand nombre de ressources simultanément.
Délégation : délègue les responsabilités liées à la sécurité à différentes équipes ou différents services en appliquant des stratégies aux niveaux appropriés de la hiérarchie.

Vous pouvez appliquer et combiner ces principes généraux pour répondre aux besoins de votre organisation. Voici quelques exemples de cas d'utilisation :

Blocage des adresses IP à l'échelle de l'organisation : vous pouvez bloquer le trafic provenant de plages d'adresses IP malveillantes connues dans tous les projets de votre organisation.
Restrictions géographiques : vous pouvez restreindre le trafic provenant de régions géographiques spécifiques au niveau de l'organisation ou du dossier.
Atténuation des CVE : vous pouvez déployer rapidement des règles WAF pour atténuer les failles critiques dans plusieurs projets.
Application de la conformité : vous pouvez faire respecter les exigences réglementaires en appliquant des stratégies de sécurité cohérentes dans toute votre organisation.
Contrôle d'accès précis : vous pouvez accorder à des plages d'adresses IP ou à des régions géographiques spécifiques l'accès à toutes les ressources d'un dossier donné.

Fonctionnalités

Les stratégies de sécurité hiérarchiques sont compatibles avec un sous-ensemble des fonctionnalités des stratégies de sécurité au niveau du service. Le tableau suivant compare les fonctionnalités Cloud Armor que vous pouvez utiliser avec les stratégies de sécurité hiérarchiques et les stratégies de sécurité au niveau du service :

	Stratégie de sécurité de backend globale au niveau du service	Stratégie de sécurité de backend hiérarchique
Type d'interface	Équilibreur de charge d'application externe global Équilibreur de charge d'application classique	Équilibreur de charge d'application externe global Équilibreur de charge d'application classique
Point de rattachement (ressource protégée)	Service de backend	Nœuds de la hiérarchie des ressources
Actions de la règle	Autoriser Refuser Redirection (`GOOGLE_RECAPTCHA` et `EXTERNAL_302`) Limitation Exclusion basée sur le débit	Autoriser Refuser Redirection (`EXTERNAL_302` uniquement) Déléguer au niveau suivant
Adresse IP source
Géographie source
ASN source
Gestion des bots		(`EXTERNAL_302` et décoration de requête uniquement)
Filtrage de couche 7
WAF
Google Threat Intelligence
reCAPTCHA
Adaptive Protection
Groupes d'adresses
Groupes d'adresses au niveau de l'organisation
Security Command Center
Cloud Monitoring
Journalisation des requêtes

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

Lorsque vous créez une stratégie de sécurité hiérarchique, vous la créez au niveau de l'organisation ou d'un dossier. Cette ressource est alors propriétaire de la stratégie de sécurité hiérarchique. Après avoir créé une stratégie de sécurité hiérarchique, ses règles ne sont appliquées à aucune de vos ressources.

Vous associez par la suite la stratégie de sécurité hiérarchique à une organisation, un dossier ou un projet, qui peut être identique à la ressource propriétaire de la stratégie. Une fois que vous avez associé une stratégie de sécurité hiérarchique à une ressource, elle applique les règles de la stratégie de sécurité aux ressources protégées au niveau de ce nœud et en dessous dans la hiérarchie des ressources. Pour vous aider à choisir la ressource à laquelle associer vos stratégies de sécurité hiérarchiques, consultez la liste suivante des cas d'utilisation de base pour chaque ressource :

Organisation : considérez les stratégies de sécurité hiérarchiques au niveau de l'organisation comme le type par défaut de stratégie de sécurité hiérarchique. Ce type de stratégie dispose de d'autorisations IAM (Identity and Access Management) étendues et s'applique à tous les nœuds de l'organisation. Spécifiez ces ressources à l'aide du flag --organization lors de l'association.
Dossier : utilisez ce type de stratégie de sécurité hiérarchiques lorsque vous souhaitez appliquer les mêmes règles de stratégie de sécurité à plusieurs projets, mais pas à l'ensemble de votre organisation. Spécifiez ces ressources à l'aide du flag --folder lors de l'association.
Projet : utilisez ce type de stratégie de sécurité hiérarchique lorsque vous devez appliquer les mêmes règles de stratégie de sécurité à toutes les ressources d'un projet, par exemple en appliquant une liste de blocage d'adresses IP à plusieurs services de backend. Spécifiez ces ressources à l'aide du flag --project lors de l'association.
Au niveau du service : utilisez des stratégies de sécurité au niveau du service lorsque vous avez besoin de règles de stratégie de sécurité uniques qui diffèrent d'un service à l'autre. Chaque stratégie de sécurité au niveau du service n'applique ses règles qu'à la stratégie de backend à laquelle elle est associée. Spécifiez ces ressources à l'aide du flag --project-number.

Vous ne pouvez utiliser qu'un seul de ces flags par stratégie de sécurité hiérarchique. Vous spécifiez le reste des flags, comme --name ou --type, comme vous le faites lorsque vous configurez une stratégie de sécurité au niveau du service. Pour en savoir plus sur le fonctionnement des stratégies de sécurité hiérarchiques, consultez la liste suivante :

Lorsqu'une stratégie de sécurité hiérarchique est associée à un nœud de hiérarchie des ressources, toutes les ressources protégées situées en dessous de ce nœud dans la hiérarchie héritent de la stratégie.
Vous pouvez afficher les stratégies de sécurité qui s'appliquent à chaque ressource protégée d'un projet, dans toutes les stratégies de sécurité hiérarchiques et au niveau du service. Pour en savoir plus, consultez Afficher toutes les règles Cloud Armor effectives pour une ressource protégée.
Vous pouvez déplacer des stratégies de sécurité hiérarchiques d'un nœud de la hiérarchie des ressources vers un autre. Vous pouvez le faire lorsque vous prévoyez de réorganiser la structure de vos dossiers.
Lorsque vous supprimez un nœud de la hiérarchie des ressources, comme un dossier ou un projet, la stratégie de sécurité hiérarchique associée à ce nœud n'est supprimée que si vous l'avez créée sous ce nœud de la hiérarchie des ressources.
- Si vous avez créé la règle de sécurité ailleurs, puis que vous l'avez déplacée sous le nœud, elle n'est pas supprimée.
- Pour éviter la suppression accidentelle de vos stratégies de sécurité hiérarchiques, nous vous recommandons de déplacer celles que vous souhaitez conserver vers un autre nœud de la hiérarchie des ressources avant de supprimer le nœud existant.

Ordre d'évaluation des règles

Cloud Armor évalue les stratégies de sécurité dans l'ordre suivant :

Stratégies de sécurité hiérarchiques au niveau de l'organisation
Stratégies de sécurité hiérarchiques au niveau du dossier (en commençant par le dossier parent, puis en passant à chaque sous-dossier)
Stratégies de sécurité hiérarchiques au niveau du projet
Stratégies de sécurité au niveau du service

Cet ordre d'évaluation des règles signifie que vous pouvez avoir une stratégie de sécurité hiérarchique avec une priorité faible qui est évaluée avant une stratégie de sécurité au niveau du service avec une priorité élevée. Réfléchissez bien aux règles de stratégie de sécurité au niveau du service qui ont une priorité élevée et à ce qui se passe si Cloud Armor n'évalue pas une requête autorisée ou refusée par une stratégie de sécurité hiérarchique par rapport à ces règles.

L'action `goto_next`

Cloud Armor propose une action de règle exclusive aux stratégies de sécurité hiérarchiques : l'action goto_next. Lorsque Cloud Armor applique cette action, il cesse d'évaluer les règles de la stratégie de sécurité actuelle et commence à évaluer les règles de la stratégie de sécurité suivante.

Prenons l'exemple d'une stratégie de sécurité hiérarchique au niveau de l'organisation avec de nombreuses règles que vous souhaitez utiliser pour restreindre les requêtes dans l'ensemble de votre organisation. Vous souhaitez que les requêtes provenant d'une certaine plage d'adresses IP ne soient pas évaluées par rapport à ces règles à l'échelle de l'organisation. Par conséquent, vous devez créer une règle de priorité maximale qui correspond à cette plage d'adresses IP avec l'action goto_next. Les requêtes provenant de cette plage d'adresses IP sont d'abord évaluées par rapport à cette règle. Comme elles remplissent la condition de correspondance, elles ne sont pas évaluées par rapport aux autres règles de cette stratégie de sécurité hiérarchique au niveau de l'organisation.

Dans le même exemple, si vous utilisiez une action allow ou deny au lieu de l'action goto_next, la requête serait autorisée ou refusée dès que la condition de correspondance serait remplie. Cette évaluation hiérarchique signifie qu'aucune autre stratégie de sécurité n'est évaluée par rapport à cette requête.

Comportement de facturation et d'enregistrement de Google Cloud Armor Enterprise

Lorsque vous associez une stratégie de sécurité hiérarchique, chacun des projets qui en héritent doit être enregistré dans Cloud Armor Enterprise. Cela inclut tous les projets d'une organisation ou d'un dossier ayant une stratégie de sécurité hiérarchique qui ne sont pas explicitement exclus, ainsi que tous les projets auxquels une stratégie de sécurité hiérarchique est directement associée.

Les projets associés à un compte de facturation Cloud avec un abonnement annuel Cloud Armor Enterprise sont automatiquement inscrits à Cloud Armor Enterprise annuel s'ils ne le sont pas déjà.
Sans abonnement Cloud Armor Enterprise annuel, les projets sont automatiquement enregistrés dans Cloud Armor Enterprise Paygo lorsqu'ils héritent d'une stratégie de sécurité hiérarchique. Si vous abonnez le compte de facturation à Cloud Armor Enterprise annuel après l'enregistrement automatique de votre projet dans Cloud Armor Enterprise Paygo, le projet n'est pas automatiquement enregistré dans l'abonnement annuel. Pour en savoir plus sur Cloud Armor Enterprise Paygo, consultez Cloud Armor Standard et Cloud Armor Enterprise.
Si vous mettez à jour une stratégie de sécurité hiérarchique pour exclure un projet après son enregistrement automatique dans Cloud Armor Enterprise, l'enregistrement du projet n'est pas automatiquement annulé. Pour annuler manuellement l'enregistrement de votre projet, consultez Supprimer un projet de Cloud Armor Enterprise.
Vous ne pouvez pas supprimer un projet de Cloud Armor Enterprise s'il comporte des stratégies de sécurité hiérarchiques héritées.

L'enregistrement automatique peut prendre jusqu'à une semaine. Pendant cette période, vos stratégies de sécurité hiérarchiques sont efficaces et vous n'encourez aucuns frais Cloud Armor Enterprise. Lorsque votre projet est enregistré, les journaux d'audit sont mis à jour pour refléter l'état Cloud Armor Enterprise du projet. Le nouveau niveau du projet s'affiche dans la console Google Cloud .

Limites

Les stratégies de sécurité hiérarchiques présentent les limites suivantes :

Les stratégies de sécurité hiérarchiques ne sont pas disponibles pour les projets qui ne font pas partie d'une organisation.
Pour les projets nouveaux ou récemment restaurés, la propagation des stratégies de sécurité héritées peut prendre quelques heures.
Pour un projet qui a récemment activé l'API Compute Engine, la propagation des stratégies de sécurité héritées sur ce projet peut prendre quelques heures.
Vous pouvez ajuster les règles WAF préconfigurées dans les stratégies de sécurité hiérarchiques dont vous êtes propriétaire, mais les propriétaires des services qui héritent d'une stratégie de sécurité hiérarchique ne peuvent pas ajuster les règles.

Étape suivante

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