Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Fonctionnement des politiques de configuration dans Security Hub
L' AWS Security Hub administrateur délégué peut créer des politiques de configuration pour configurer Security Hub, les normes de sécurité et les contrôles de sécurité pour une organisation. Après avoir créé une politique de configuration, l'administrateur délégué peut l'associer à des comptes spécifiques, à des unités organisationnelles (OUs) ou à la racine. La politique prend ensuite effet dans les comptes spécifiésOUs, ou à la racine.
Pour obtenir des informations générales sur les avantages de la configuration centralisée et son fonctionnement, consultezComprendre la configuration centrale dans Security Hub.
Cette section fournit un aperçu détaillé des politiques de configuration.
Considérations relatives aux politiques
Avant de créer une politique de configuration dans Security Hub, prenez en compte les informations suivantes.
Les politiques de configuration doivent être associées pour prendre effet : après avoir créé une politique de configuration, vous pouvez l'associer à un ou plusieurs comptes, unités organisationnelles (OUs) ou à la racine. Une politique de configuration peut être associée à des comptes, OUs par le biais d'une application directe ou par héritage d'une unité d'organisation parent.
Un compte ou une unité d'organisation ne peut être associé qu'à une seule stratégie de configuration : pour éviter tout conflit de paramètres, un compte ou une unité d'organisation ne peut être associé qu'à une seule politique de configuration à la fois. Un compte ou une unité d'organisation peut également être autogéré.
Les politiques de configuration sont complètes : les politiques de configuration fournissent une spécification complète des paramètres. Par exemple, un compte enfant ne peut pas accepter les paramètres de certains contrôles d'une politique et les paramètres d'autres contrôles d'une autre politique. Lorsque vous associez une politique à un compte enfant, assurez-vous que la politique spécifie tous les paramètres que vous souhaitez que le compte enfant utilise.
Les politiques de configuration ne peuvent pas être annulées : il n'est pas possible d'annuler une politique de configuration une fois que vous l'avez associée à des comptes ou. OUs Par exemple, si vous associez une politique de configuration qui désactive les CloudWatch contrôles à un compte spécifique, puis que vous dissociez cette politique, les CloudWatch contrôles continuent d'être désactivés dans ce compte. Pour réactiver CloudWatch les contrôles, vous pouvez associer le compte à une nouvelle politique qui active les contrôles. Vous pouvez également transformer le compte en compte autogéré et activer chaque CloudWatch contrôle du compte.
Les politiques de configuration prennent effet dans votre région d'origine et dans toutes les régions liées : une politique de configuration affecte tous les comptes associés dans la région d'origine et toutes les régions liées. Vous ne pouvez pas créer une politique de configuration qui ne s'applique que dans certaines de ces régions et pas dans d'autres. Les contrôles qui utilisent des ressources globales font exception à cette règle. Security Hub désactive automatiquement les contrôles impliquant des ressources globales dans toutes les régions, à l'exception de la région d'origine.
Les régions AWS introduites le 20 mars 2019 ou après cette date sont appelées régions optionnelles. Vous devez activer une telle région pour un compte avant qu'une politique de configuration n'y prenne effet. Le compte de gestion des Organizations peut activer l'option « Régions » pour un compte membre. Pour obtenir des instructions sur l'activation des régions optionnelles, voir Spécifier les régions que Régions AWS votre compte peut utiliser dans le Guide de référence AWS sur la gestion des comptes.
Si votre politique configure un contrôle qui n'est pas disponible dans la région d'origine ou dans une ou plusieurs régions liées, Security Hub ignore la configuration du contrôle dans les régions non disponibles mais applique la configuration dans les régions où le contrôle est disponible. Vous n'êtes pas couvert pour un contrôle qui n'est pas disponible dans la région d'origine ou dans aucune des régions associées.
Les politiques de configuration sont des ressources : en tant que ressource, une politique de configuration possède un Amazon Resource Name (ARN) et un identifiant unique universel (UUID). ARNUtilise le format suivant :
arn:. Une configuration autogérée ne comporte aucun ARN ouUUID. L'identifiant d'une configuration autogérée estpartition:securityhub:region:delegated administrator account ID:configuration-policy/configuration policy UUIDSELF_MANAGED_SECURITY_HUB.
Types de politiques de configuration
Chaque politique de configuration définit les paramètres suivants :
-
Activez ou désactivez Security Hub.
-
Activez une ou plusieurs normes de sécurité.
-
Indiquez quels contrôles de sécurité sont activés dans le cadre des normes activées. Vous pouvez le faire en fournissant une liste de contrôles spécifiques qui doivent être activés, et Security Hub désactive tous les autres contrôles, y compris les nouveaux contrôles lorsqu'ils sont publiés. Vous pouvez également fournir une liste de contrôles spécifiques qui doivent être désactivés, et Security Hub active tous les autres contrôles, y compris les nouveaux contrôles lorsqu'ils sont publiés.
-
Vous pouvez éventuellement personnaliser les paramètres pour sélectionner les contrôles activés selon les normes activées.
Les politiques de configuration centrales n'incluent pas les paramètres de l' AWS Config enregistreur. Vous devez activer AWS Config et activer séparément l'enregistrement pour les ressources requises afin que Security Hub puisse générer des résultats de contrôle. Pour de plus amples informations, veuillez consulter Configuration AWS Config pour Security Hub.
Si vous utilisez la configuration centralisée, Security Hub désactive automatiquement les contrôles impliquant des ressources globales dans toutes les régions, à l'exception de la région d'origine. Les autres contrôles que vous choisissez d'activer par le biais d'une politique de configuration sont activés dans toutes les régions où ils sont disponibles. Pour limiter les résultats de ces contrôles à une seule région, vous pouvez mettre à jour les paramètres de votre AWS Config enregistreur et désactiver l'enregistrement des ressources globales dans toutes les régions, à l'exception de la région d'origine. Lorsque vous utilisez la configuration centralisée, vous ne pouvez pas couvrir un contrôle qui n'est pas disponible dans la région d'origine ou dans aucune des régions associées. Pour obtenir la liste des contrôles impliquant des ressources globales, voirContrôles utilisant des ressources globales.
Politique de configuration recommandée
Lorsque vous créez une politique de configuration pour la première fois dans la console Security Hub, vous avez la possibilité de choisir la politique recommandée par Security Hub.
La politique recommandée active Security Hub, la norme AWS Foundational Security Best Practices (FSBP) et tous les FSBP contrôles existants et nouveaux. Les contrôles qui acceptent des paramètres utilisent les valeurs par défaut. La politique recommandée s'applique au root (tous les comptesOUs, qu'ils soient nouveaux ou existants). Après avoir créé la politique recommandée pour votre organisation, vous pouvez la modifier à partir du compte d'administrateur délégué. Par exemple, vous pouvez activer des normes ou des contrôles supplémentaires ou désactiver des FSBP contrôles spécifiques. Pour obtenir des instructions sur la modification d'une politique de configuration, consultezMise à jour des politiques de configuration.
Politique de configuration personnalisée
Au lieu de la stratégie recommandée, l'administrateur délégué peut créer jusqu'à 20 politiques de configuration personnalisées. Vous pouvez associer une seule politique personnalisée à l'ensemble de votre organisation ou différentes politiques personnalisées à différents comptes etOUs. Pour une politique de configuration personnalisée, vous devez spécifier les paramètres souhaités. Par exemple, vous pouvez créer une politique personnalisée qui active FSBP le Center for Internet Security (CIS) AWS Foundations Benchmark v1.4.0 et tous les contrôles de ces normes, à l'exception des contrôles Amazon Redshift. Le niveau de granularité que vous utilisez dans les politiques de configuration personnalisées dépend de l'étendue de la couverture de sécurité prévue dans l'ensemble de votre organisation.
Note
Vous ne pouvez pas associer une politique de configuration qui désactive Security Hub au compte d'administrateur délégué. Une telle politique peut être associée à d'autres comptes mais ignore l'association avec l'administrateur délégué. Le compte d'administrateur délégué conserve sa configuration actuelle.
Après avoir créé une politique de configuration personnalisée, vous pouvez passer à la stratégie de configuration recommandée en mettant à jour votre politique de configuration afin de refléter la configuration recommandée. Cependant, vous ne voyez pas la possibilité de créer la politique de configuration recommandée dans la console Security Hub après la création de votre première politique.
Association des politiques par le biais de l'application et de l'héritage
Lorsque vous optez pour la première fois pour la configuration centralisée, votre organisation n'a aucune association et se comporte de la même manière qu'avant l'inscription. L'administrateur délégué peut ensuite établir des associations entre une politique de configuration ou un comportement autogéré et les comptesOUs, ou le root. Les associations peuvent être créées par le biais d'une demande ou d'un héritage.
À partir du compte d'administrateur délégué, vous pouvez appliquer directement une politique de configuration à un compte, à une unité d'organisation ou à la racine. L'administrateur délégué peut également appliquer directement une désignation autogérée à un compte, à une unité d'organisation ou à la racine.
En l'absence d'application directe, un compte ou une unité d'organisation hérite des paramètres du parent le plus proche doté d'une politique de configuration ou d'un comportement autogéré. Si le parent le plus proche est associé à une politique de configuration, l'enfant hérite de cette politique et n'est configurable que par l'administrateur délégué de la région d'origine. Si le parent le plus proche est autogéré, l'enfant hérite du comportement autogéré et a la possibilité de spécifier ses propres paramètres dans chacun d'eux. Région AWS
L'application a la priorité sur l'héritage. En d'autres termes, l'héritage ne remplace pas une politique de configuration ou une désignation autogérée que l'administrateur délégué a directement appliquée à un compte ou à une unité d'organisation.
Si vous appliquez directement une politique de configuration à un compte autogéré, cette politique remplace la désignation autogérée. Le compte est géré de manière centralisée et adopte les paramètres reflétés dans la politique de configuration.
Nous recommandons d'appliquer directement une politique de configuration à la racine. Si vous appliquez une politique à la racine, les nouveaux comptes qui rejoignent votre organisation hériteront automatiquement de la politique racine, sauf si vous les associez à une autre stratégie ou si vous les désignez comme autogérés.
Une seule politique de configuration peut être associée à un compte ou à une unité d'organisation à la fois, par le biais d'une application ou d'un héritage. Ceci est conçu pour éviter les conflits de paramètres.
Le schéma suivant illustre le fonctionnement de l'application des politiques et de l'héritage dans une configuration centrale.
Dans cet exemple, une politique de configuration est appliquée à un nœud surligné en vert. Aucune politique de configuration n'est appliquée à un nœud surligné en bleu. Un nœud surligné en jaune a été désigné comme étant autogéré. Chaque compte et unité d'organisation utilise la configuration suivante :
OU:root (vert) — Cette unité d'organisation utilise la politique de configuration qui lui a été appliquée.
OU:Prod (Blue) — Cette UO hérite de la politique de configuration de OU:Root.
OU:Applications (vert) — Cette unité d'organisation utilise la politique de configuration qui lui a été appliquée.
Compte 1 (vert) — Ce compte utilise la politique de configuration qui lui a été appliquée.
Compte 2 (bleu) — Ce compte hérite de la politique de configuration de OU:Applications.
OU:dev (Yellow) — Cette UO est autogérée.
Compte 3 (vert) — Ce compte utilise la politique de configuration qui lui a été appliquée.
Compte 4 (bleu) — Ce compte hérite du comportement autogéré de OU:dev.
OU:Test (Blue) — Ce compte hérite de la politique de configuration de OU:Root.
Compte 5 (bleu) — Ce compte hérite de la politique de configuration de OU:root puisque son parent immédiat, OU:Test, n'est associé à aucune politique de configuration.
Tester une politique de configuration
Pour tester l'effet d'une politique de configuration, vous pouvez l'associer à un compte ou à une unité d'organisation unique avant de l'associer plus largement au sein de votre organisation.
Pour tester une politique de configuration
Créez une politique de configuration personnalisée, mais ne l'appliquez à aucun compte. Vérifiez que les paramètres spécifiés pour l'activation, les normes et les contrôles de Security Hub sont corrects.
Appliquez la politique de configuration à un compte de test ou à une unité d'organisation qui ne possède aucun compte enfant ouOUs.
Vérifiez que le compte de test ou l'unité d'organisation utilise la politique de configuration de la manière prévue dans votre région d'origine et dans toutes les régions associées. Vous pouvez également vérifier que tous les autres comptes et OUs ceux de votre organisation restent autogérés et peuvent modifier leurs propres paramètres dans chaque région.
Après avoir testé une politique de configuration dans un seul compte ou unité d'organisation, vous pouvez l'associer à d'autres comptes etOUs. Pour obtenir des instructions sur la création et l'association de politiques, voirCréation et association de politiques de configuration. Les enfants des comptes appliqués héritent de la politique à moins qu'ils ne soient autogérés ou qu'une politique de configuration différente ne s'applique à eux. Vous pouvez également modifier vos politiques de configuration et créer des politiques de configuration supplémentaires si nécessaire.
