Règles Config gérées et personnalisées

Une règle Config évalue la conformité de vos ressources à une configuration souhaitée et indique pour chacune si elle est COMPLIANT ou NON_COMPLIANT. L'enregistrement de l'état est passif ; les règles ajoutent une couche d'évaluation qui signale automatiquement les paramètres non sécurisés et transforment Config en moteur de conformité continue.

Les règles gérées sont préconçues par AWS pour les contrôles courants ; vous pouvez donc les activer sans écrire de code. Parmi les exemples figurent s3-bucket-public-read-prohibited, encrypted-volumes, iam-password-policy et restricted-ssh. Il en existe des centaines couvrant les bonnes pratiques, ce qui en fait le moyen le plus rapide d'établir une référence de conformité.

Lorsqu'aucune règle gérée ne convient, vous écrivez une règle personnalisée. Elle s'exécute sous la forme d'une fonction Lambda qui reçoit la configuration de la ressource et renvoie un verdict de conformité, ou sous la forme d'une stratégie Guard utilisant le langage AWS de définition de politiques sous forme de code. Les règles personnalisées encodent les exigences propres à l'organisation que les règles gérées ne peuvent pas exprimer.

Les règles s'exécutent selon deux types de déclencheurs. Un déclencheur de modification de configuration évalue une ressource chaque fois qu'elle change, ce qui fournit une conformité presque en temps réel. Un déclencheur périodique s'exécute selon un calendrier fixe, indépendamment des modifications ; il est utile pour les contrôles qui dépendent du temps ou de paramètres au niveau du compte plutôt que d'un événement concernant une seule ressource.

Le tableau de bord Config affiche la conformité de chaque règle et répertorie les ressources non conformes. Vous obtenez ainsi une liste de tâches priorisée concernant les configurations non sécurisées. Pour la sécurité, des règles portant par exemple sur les compartiments S3 publics, les volumes non chiffrés et les groupes de sécurité ouverts font apparaître les ressources précises à corriger.

De nombreuses règles acceptent des paramètres permettant d'adapter le contrôle. La règle iam-password-policy, par exemple, vous permet de définir la longueur minimale et les exigences de renouvellement. Les paramètres permettent à une seule règle gérée d'appliquer la norme propre à votre organisation plutôt qu'une valeur par défaut générique, sans écrire de code personnalisé.

Un pack de conformité regroupe de nombreuses règles et actions de correction dans un seul package déployable, souvent associé à un référentiel comme CIS ou PCI DSS. Déployer un pack sur plusieurs comptes via un agrégateur ou Organizations applique une norme de conformité complète en une seule fois, au lieu d'activer les règles une par une.

Vous pouvez limiter le périmètre d'une règle à certains types de ressources ou à certains tags afin qu'elle n'évalue que ce qui est pertinent, ce qui réduit à la fois le bruit et le coût. Config facture chaque évaluation de règle ; définir correctement le périmètre et choisir le type de déclencheur approprié permet donc de conserver un grand ensemble de règles à un coût raisonnable, tout en couvrant les ressources essentielles à la sécurité.

Les règles Config et les normes de Security Hub se recoupent, et Security Hub utilise d'ailleurs Config pour bon nombre de ses contrôles. Les règles Config offrent une conformité précise et personnalisable, ressource par ressource ; Security Hub regroupe les résultats de plusieurs services dans un score de posture. L'examen peut vous demander lequel utiliser pour des contrôles personnalisés au niveau des ressources : il s'agit des règles Config.

Prenons restricted-ssh : cette règle marque un groupe de sécurité comme NON_COMPLIANT s'il autorise le trafic SSH entrant sans restriction sur le port 22 depuis 0.0.0.0/0. Activer cette seule règle sur vos comptes permet de détecter en continu l'une des erreurs de configuration les plus courantes et les plus dangereuses, sans écrire le moindre code personnalisé.

Commencez par les règles gérées et les packs de conformité pour obtenir une couverture étendue, puis ajoutez des règles personnalisées pour vos politiques spécifiques. Définissez soigneusement le périmètre, paramétrez les règles selon vos normes et associez les règles les plus importantes à des actions de correction. Cette approche en couches fournit une assurance continue et automatisée que votre environnement reste configuré de manière sécurisée.

Testez vos connaissances sur les règles Config.

Les règles Config marquent les ressources comme COMPLIANT ou NON_COMPLIANT. Des centaines de règles gérées couvrent les contrôles courants avec des paramètres facultatifs, tandis que les règles personnalisées (Lambda ou Guard) encodent des politiques spécifiques. Les règles se déclenchent lors d'une modification ou selon une planification, se regroupent en packs de conformité pour les référentiels et complètent Security Hub en fournissant une conformité précise, ressource par ressource.