9 min de lecture - Criticité des ressources AWS Security Hub : désignez un responsable avant l’automatisation

Le 14 octobre 2026, AWS a ajouté la criticité des ressources à la priorisation des expositions dans Security Hub. Une équipe peut attribuer un niveau avec une règle d’automatisation. Security Hub peut aussi en déduire un à partir des noms et des tags des ressources. Le service conserve la source à l’origine de la valeur.

Ce dernier point mérite l’attention. Un niveau de criticité peut désormais faire monter ou descendre une exposition dans la file, alors que ce niveau peut provenir de conventions de nommage qui n’ont jamais été conçues pour décider d’un risque. « prod » indique où s’exécute une ressource. Ce mot ne dit rien des effets d’une panne sur le chiffre d’affaires, les clients, les données réglementées ou le travail de reprise.

Une équipe de sécurité ne peut traiter chaque alerte cloud comme une urgence. Une personne doit donc définir la criticité, approuver les règles, examiner les valeurs déduites et les corriger lorsque l’activité change.

Ce qu’AWS a changé

L’annonce AWS indique que la criticité des ressources contribue désormais à la priorisation des expositions dans Security Hub. La valeur apparaît dans l’inventaire des ressources et dans l’analyse d’impact d’une exposition. AWS précise aussi que la fonction reste toujours active pour les clients Security Hub Essentials, sans activation séparée.

L’annonce décrit deux modes d’attribution :

• un administrateur peut utiliser une règle d’automatisation, par exemple pour attribuer un niveau élevé aux ressources de calcul d’un compte donné ;
• Security Hub peut déduire la criticité des noms et des tags, sans configuration.

Ces deux modes aident au premier tri. Aucun ne connaît toute la réalité métier. Un compte partagé peut contenir un composant d’identité dont la panne touche plusieurs applications ; un compte de production, un traitement temporaire sans données durables. Les règles fondées sur le compte ou les tags fournissent des éléments de preuve, pas une décision définitive.

Séparez la sévérité de la criticité

Les équipes de sécurité disposent déjà de niveaux de sévérité. Un nouveau classement peut donc sembler redondant. AWS attribue pourtant un rôle différent à chacun.

Sa documentation sur les résultats de contrôle indique que la sévérité d’un contrôle reflète la difficulté d’exploitation et la probabilité de compromission ; elle n’intègre pas la criticité de la ressource concernée. La criticité décrit l’importance de cette ressource. De leur côté, les expositions combinent des signaux tels que les vulnérabilités, les configurations, les menaces et les relations entre ressources. Security Hub les classe ensuite selon plusieurs facteurs, dont la sévérité, l’impact, la criticité et la probabilité d’exploitation.

La file opérationnelle a donc besoin des deux dimensions :

Une ressource de test peut exiger un confinement rapide si elle ouvre un chemin vers d’autres systèmes. Une faiblesse moins sévère sur un service d’identité peut passer plus tôt si de nombreux services en dépendent. La criticité affine le jugement technique, sans l’annuler.

Fondez le niveau sur des preuves métier

Le NIST IR 8286D étend l’analyse d’impact métier au-delà de la disponibilité. Il demande aux dirigeants d’identifier les fonctions essentielles et les scénarios susceptibles de leur nuire, puis aux responsables des systèmes d’utiliser cette orientation pour classer les actifs et définir les impacts. Le NIST intègre aussi les pertes de confidentialité et d’intégrité à l’analyse.

Cette base est plus solide qu’un nom de ressource. Pour chaque service métier, consignez :

• le processus ou le résultat client qu’il soutient, avec un responsable métier désigné ;
• les effets d’une perte de disponibilité, d’intégrité ou de confidentialité ;
• les ressources et les services externes dont il dépend ;
• la date des preuves et l’événement qui doit déclencher une nouvelle revue.

Ne classez pas séparément des milliers de ressources cloud. Partez des services métier, puis associez les ressources qui les rendent possibles. Une base de données, une file, un rôle et une clé peuvent partager le même contexte, même si AWS les inventorie sous des types différents.

Le modèle d’analyse de criticité du NIST relie lui aussi la criticité à l’importance des systèmes et composants pour les objectifs de l’organisation, ainsi qu’aux effets d’un fonctionnement insuffisant ou d’une perte. Il invite à dépasser la frontière visible du système : les composants et leurs dépendances peuvent porter la conséquence réelle.

Utilisez l’inférence comme file de revue

Selon l’annonce de lancement, Security Hub conserve la source d’une valeur de criticité. Gardez cette provenance lorsque les données quittent AWS pour un ticket, un entrepôt de données ou un SIEM. La personne qui traite l’exposition doit savoir si un humain a approuvé le niveau, si une règle l’a attribué ou si le service l’a déduit.

Utilisez trois états de travail :

Une valeur « Très élevée » déduite peut attirer l’attention sans trop de risque. Une valeur « Faible » déduite pose davantage de problèmes, car elle peut détourner l’attention. Échantillonnez les deux extrémités de l’échelle, ainsi que les ressources sans niveau exploitable. Examinez d’abord les sous-classements avant de chercher à éliminer tous les faux positifs.

Les noms et tags restent utiles. La finalité du compte, un identifiant de service, une classe de données et un responsable peuvent alimenter une règle si une personne les vérifie. Évitez un tag critical=true dont l’auteur, la raison et l’expiration sont inconnus.

Testez les dépendances, pas seulement les actifs

Les inventaires cloud poussent à examiner les ressources une par une. L’impact métier, lui, se propage par les dépendances.

Un serveur applicatif public peut avoir un faible impact direct si le trafic bascule ailleurs. Son rôle, la clé qui déchiffre les données client ou son enregistrement DNS peuvent avoir une autre criticité. Ne classer que le serveur ignore les actifs qui décident si la reprise fonctionnera.

Pour chaque service important, organisez une courte revue par scénario. Demandez ce qui se passe si la ressource devient indisponible, produit des données fausses, expose ses données ou élargit l’accès d’un attaquant. Identifiez ensuite les composants qui rendent ces résultats possibles. Vous obtenez ainsi des raisons vérifiables pour le niveau, au lieu d’un débat sur ce que « Élevé » devrait signifier.

Les dépendances intercomptes et tierces ont aussi besoin d’une trace. Si l’équipe ne peut ni voir ni taguer un composant géré, rattachez la décision de criticité à la carte du service et liez-lui les ressources AWS visibles. La couverture d’un outil ne doit pas décider des dépendances de l’entreprise.

Automatisez d’abord le routage

La criticité peut améliorer l’automatisation, mais les premières actions doivent rester réversibles. Utilisez un niveau approuvé pour changer la file d’un ticket, le canal de notification, l’objectif de réponse ou la personne chargée de la revue. Gardez les actions destructrices ou susceptibles d’affecter la disponibilité derrière un contrôle qui vérifie aussi l’alerte, le type de ressource, la menace actuelle et la procédure autorisée.

Une erreur de routage se corrige. Isoler une base de données de production parce que son nom a augmenté son rang peut provoquer un second incident ; supprimer une alerte parce qu’une règle obsolète l’a classée « Faible » peut masquer le premier.

Avant de modifier le flux, rejouez des alertes récentes dans la nouvelle logique. Comparez les deux ordres, examinez chaque déplacement important et demandez au responsable si l’impact consigné l’explique. Un écart peut révéler une carte de service obsolète ou une priorité jamais explicitée.

Le guide Exceev sur le bruit des alertes d’un agent de sécurité applique un principe proche : mesurez les décisions et les risques manqués, plutôt que de compter moins d’alertes comme un succès. Nos services d’ingénierie cloud peuvent relier la responsabilité des services, les données d’infrastructure et les flux de réponse sans transformer un score fournisseur en politique.

Donnez un responsable au modèle

Désignez un responsable de la méthode et un autre pour chaque service. Le premier définit les niveaux, les preuves, la priorité des règles et le traitement des données obsolètes. Le second confirme l’impact et les dépendances. Les opérations de sécurité décident comment chaque niveau approuvé modifie la file.

Réexaminez le niveau lors d’un changement, sans attendre uniquement une échéance calendaire. Un nouveau jeu de données, un engagement client, un chemin réseau, une dépendance d’identité, une acquisition ou une nouvelle conception de la reprise peut modifier l’impact immédiatement. La preuve doit indiquer ce qui a changé, qui a approuvé le nouveau niveau et quelles règles d’automatisation l’ont consommé.

Le résultat recherché est une file où la personne chargée de la réponse peut expliquer le rang d’une ressource, retrouver son responsable et contester une inférence avant qu’elle ne devienne un fait opérationnel.

Sources et limites

Nous avons ouvert et examiné chaque source ci-dessous le 15 octobre 2026.

• L’annonce AWS du 14 octobre est la source primaire pour la date de lancement, l’attribution par règle, la déduction depuis les noms et tags, la provenance, les emplacements dans l’interface et la disponibilité.
• La documentation AWS Security Hub sur les résultats de contrôle distingue la sévérité d’un contrôle de la criticité d’une ressource.
• La documentation AWS Security Hub sur les expositions décrit la corrélation des signaux et les facteurs de priorisation.
• Le NIST IR 8286D fournit une méthode indépendante pour relier impact métier, fonctions essentielles, classification des actifs et réponse au risque.
• Le NIST IR 8179 fournit un modèle indépendant d’analyse de criticité couvrant systèmes, composants et objectifs de l’organisation.

Nous n’avons pas inspecté l’algorithme d’AWS, testé un tenant Security Hub ni mesuré le classement d’un lecteur. AWS peut modifier sa documentation, les ressources prises en charge ou sa logique après la revue. Les états, tests et limites d’automatisation relèvent de l’analyse d’Exceev, pas d’exigences d’AWS ou du NIST. Cet article ne promet aucun résultat de sécurité ou de conformité.