Les règles de sécurité hiérarchiques sont une catégorie de règles de sécurité qui étendent la portée du pare-feu d'application Web (WAF) et de la protection contre les attaques DDoS de Google 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 règles de sécurité hiérarchiques diffèrent des règles de sécurité au niveau du service. Avant de continuer, lisez la présentation des règles 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 être complexe et chronophage. Les stratégies de sécurité hiérarchiques offrent les avantages suivants pour vous aider à relever ces défis :
- Contrôle centralisé : permet aux administrateurs au niveau de l'organisation et des dossiers de définir et d'appliquer des règles de sécurité dans plusieurs projets.
- Cohérence : assurez une posture de sécurité uniforme dans toute l'organisation, en réduisant le risque d'erreurs de configuration et de failles de sécurité.
- Efficacité : rationalisez le déploiement des mises à jour et des mesures de sécurité, 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éguez les responsabilités liées à la sécurité à différentes équipes ou différents services en appliquant des règles 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 règles 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 spécifique.
Fonctionnalités
Les règles de sécurité hiérarchiques sont compatibles avec un sous-ensemble des fonctionnalités des règles de sécurité au niveau du service. Le tableau suivant compare les fonctionnalités Google 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 :
| Type d'interface |
|
|
| Point de rattachement (ressource protégée) | Service de backend | Nœuds de la hiérarchie des ressources |
| Actions de la règle |
|
|
| Adresse IP source | ||
| Géographie source | ||
| ASN source | ||
| Gestion des robots | (EXTERNAL_302 et décoration de la 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 règles 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, les règles de votre stratégie de sécurité ne sont appliquées à aucune de vos ressources.
Ensuite, vous associez 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 règles 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.
Ces règles disposent de larges autorisations IAM (Identity and Access Management) et s'appliquent à tous les nœuds de l'organisation. Spécifiez ces ressources à l'aide de l'option
--organizationlors de l'association. - Dossier : utilisez ces stratégies 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 de l'option
--folderlors 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 refus d'adresses IP à plusieurs services de backend.
Spécifiez ces ressources à l'aide de l'option
--projectlors de l'association. - Au niveau du service : utilisez des règles de sécurité au niveau du service lorsque vous avez besoin de règles de sécurité uniques qui diffèrent d'un service à l'autre. Chaque règle de sécurité au niveau du service n'applique ses règles qu'à la règle de backend à laquelle elle est associée. Spécifiez ces ressources à l'aide de l'indicateur
--project-number.
Vous ne pouvez utiliser qu'un seul de ces indicateurs par stratégie de sécurité hiérarchique. Vous spécifiez le reste des indicateurs, comme --name ou --type, comme vous le faites lorsque vous configurez une règle 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 de 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 règles de sécurité qui s'appliquent à chaque ressource protégée d'un projet, dans toutes les règles de sécurité hiérarchiques et au niveau du service. Pour en savoir plus, consultez Afficher toutes les règles Google 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 hiérarchie de ressources à 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 hiérarchie de 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 hiérarchie de 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 règles de sécurité hiérarchiques, nous vous recommandons de déplacer celles que vous souhaitez conserver vers un autre nœud de hiérarchie de ressources avant de supprimer le nœud existant.
Ordre d'évaluation des règles
Google Cloud Armor évalue les stratégies de sécurité dans l'ordre suivant :
- Règles de sécurité hiérarchiques au niveau de l'organisation
- Stratégies de sécurité hiérarchiques au niveau des dossiers (en commençant par le dossier parent, puis en passant à chaque sous-dossier)
- Règles de sécurité hiérarchiques au niveau du projet
- Règles de sécurité au niveau du service
Cet ordre d'évaluation des règles signifie que vous pouvez avoir une règle de sécurité hiérarchique de faible priorité qui est évaluée avant une règle de sécurité au niveau du service de priorité élevée. Réfléchissez attentivement aux règles de stratégie de sécurité de niveau de service existantes de haute priorité et à ce qui se passe si Google 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
Google Cloud Armor propose une action de règle exclusive aux stratégies de sécurité hiérarchiques : l'action goto_next. Lorsque Google 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 demande serait autorisée ou refusée dès que la condition de correspondance serait remplie. Cette évaluation hiérarchique signifie qu'aucune règle de sécurité supplémentaire 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 avec une stratégie de sécurité hiérarchique qui ne sont pas explicitement exclus, ainsi que tous les projets avec une stratégie de sécurité hiérarchique directement associée au projet.
- Les projets associés à un compte de facturation Cloud avec un abonnement annuel Cloud Armor Enterprise sont automatiquement inscrits à Cloud Armor Enterprise Annual s'ils ne le sont pas déjà.
- Sans abonnement Cloud Armor Enterprise Annual, 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 au paiement à l'utilisation, le projet n'est pas automatiquement enregistré dans le forfait annuel. Pour en savoir plus sur Cloud Armor Enterprise Paygo, consultez Google 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 inscription automatique à Cloud Armor Enterprise, le projet n'est pas automatiquement désinscrit. Pour désinscrire manuellement 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'inscription automatique peut prendre jusqu'à une semaine. Pendant cette période, vos règles de sécurité hiérarchiques sont efficaces et vous n'encourez aucun 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 règles de sécurité hiérarchiques présentent les limites suivantes :
- Les règles 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 règles 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 règles 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.