Classer six constats par chemin d’attaque
Triés selon l’allure de chacun pris isolément, les six constats de notre rapport type fictif placent l’exposition à Internet en tête et relèguent au bas de la liste deux des trois constats de gravité élevée, parce que les contrôles qu’ils évoquent sont conformes. Une fois les constats classés par entrée, identité et rayon d’impact, le serveur de compilation qui peut déployer en production reste au premier rang, et les droits du rôle WorkloadAdmin d’arrêter la journalisation et de supprimer les copies de sauvegarde montent aux deuxième et troisième rangs. Les constats d’exposition reculent, car chacun exige d’abord la défaillance d’un autre contrôle.
Le Groupe industriel Orivane est une entreprise fictive. Nous l’avons inventée, avec son personnel et ses 48 comptes AWS, pour nos rapports types ; aucune donnée client n’est en jeu. Cette note reprend les six constats de notre rapport type de Revue de sécurité infonuagique et les classe deux fois : d’abord selon l’allure de chacun pris isolément, puis selon la méthode de Gravité CSPM ou priorisation par chemin d’attaque — entrée, identité, rayon d’impact.
Deux classements pour les mêmes six constats
Le classement par signature est une reconstitution faite pour cette note : il ne provient d’aucun produit et ne figure pas dans le rapport. Il trie les constats selon ce que chacun montre de plus alarmant quand on examine une ressource à la fois : l’exposition à Internet, puis la segmentation réseau, puis l’hygiène, puis les contrôles conformes. Le classement par chemin suit la séquence de correction du rapport, du 13 au 24 juillet. Sa grille de gravité tient déjà compte « des accès possibles, des privilèges requis, des effets potentiels et de la capacité à détecter l’attaque ».
| Constat | Ce que voit un contrôle ressource par ressource | Signature | Chemin | Gravité (rapport) |
|---|---|---|---|---|
| SEC-01 Le serveur de compilation peut déployer en production | Un serveur de compilation accessible par Internet | 1 | 1 | Élevée |
| SEC-03 Les exceptions expirées restent actives | Une exception qui permet encore un point d’accès public | 2 | 5 (ex æquo) | Moyenne |
| SEC-05 Le réseau partagé relie des environnements à isoler | Une table de routage qui importe des rattachements de production et hors production | 3 | 4 | Moyenne |
| SEC-06 Un déploiement réussi ne suffit pas à autoriser la production | Aucun responsable des coûts, aucun test des journaux | 4 | 5 (ex æquo) | Moyenne |
| SEC-02 Les administrateurs peuvent arrêter leurs journaux | Journaux reçus dans orv-log : contrôle conforme | 5 (ex æquo) | 2 | Élevée |
| SEC-04 Les mêmes droits donnent accès aux applications et aux sauvegardes | Sauvegarde planifiée pour les 24 charges de production : contrôle conforme | 5 (ex æquo) | 3 | Élevée |
SEC-01 reste en tête, mais pour une autre raison
Un contrôle par signature place SEC-01 au sommet parce que nacre-build-03 est accessible par Internet. Le vrai risque tient à la relation d’accès qui se cache derrière. Neuf des 24 rôles de production sont accessibles à orv-ci/BuildRunner, et l’essai ID-17 confirme que nacre-build-03 peut utiliser le rôle ReleaseDeploy de LedgerFlow pour modifier orders-api, sans rien changer en production. Une fois l’exécuteur compromis, aucune connexion utilisateur supplémentaire n’est requise.
Cette relation s’étend sur deux comptes : la politique de confiance de ReleaseDeploy se trouve dans orv-ledgerflow-prod, le droit de l’appelant dans orv-ci. AWS n’autorise une requête entre comptes que si les politiques des deux comptes la permettent ; une règle qui lit une ressource à la fois ne voit donc qu’une moitié de relation de chaque côté. Un analyseur d’accès externe d’IAM Access Analyzer dont la zone de confiance est l’organisation reste muet, lui aussi : tout principal situé dans cette zone est considéré comme fiable, et orv-ci est l’un des comptes d’Orivane.
Le test est simple. Rendez l’exécuteur inaccessible depuis Internet : le constat par signature disparaît, mais le chemin reste ouvert, car un exécuteur compromis peut toujours utiliser le rôle. Le rapport est clair sur ce point : ce qui compte, c’est la combinaison de la politique de confiance, du droit de l’appelant et d’une action de déploiement permise, pas la seule présence d’un exécuteur public.
SEC-02 et SEC-04 passent de « conformes » aux deuxième et troisième rangs
Les deux constats partent d’une même identité : WorkloadAdmin. Dans six comptes de production, ce rôle peut arrêter l’envoi des journaux vers orv-log (AUD-12 confirme un StopLogging permis pour orv-dockline-prod). Il peut aussi utiliser RecoveryAdmin pour 18 des 24 charges de production, dont LedgerFlow et Dockline. Le contrôle de journalisation est conforme, puisque les journaux arrivent dans orv-log ; celui des sauvegardes aussi, puisque chaque charge de production a une sauvegarde planifiée. Ni l’un ni l’autre ne vérifie qui peut désactiver le contrôle.
Pour ces deux constats, l’entrée est une session d’administration d’une charge, pas Internet ; ils se classent donc derrière SEC-01. C’est leur rayon d’impact qui les place devant les autres. SEC-02 permet à un attaquant d’interrompre l’enregistrement de nouvelles traces avant d’agir. SEC-04 lui permet de supprimer les copies dont Orivane aurait besoin pour se rétablir ; une sauvegarde réussie confirme la création d’une copie, pas sa protection contre un attaquant qui détient ces droits.
Le rapport pose deux limites à retenir. Le droit de déployer n’entraîne aucun droit sur les journaux ni sur les sauvegardes : ce sont des chemins distincts (P2 et P3 dans le rapport), pas un prolongement de SEC-01. Et les objets déjà archivés restent protégés : ce que SEC-02 permet d’interrompre, c’est la collecte à venir. La correction consiste à confier la collecte à l’équipe de sécurité. Sur AWS, un journal de suivi de l’organisation est une façon d’y arriver, puisque les utilisateurs des comptes membres ne peuvent ni activer ni désactiver sa journalisation.
SEC-05 et SEC-03 reculent : chacun exige une autre défaillance
Sur le papier, SEC-05 semble grave. Dans ca-central-1, la table nacre-tgw-shared importe 12 rattachements hors production et huit de production, et l’essai NET-31 atteint le sous-réseau LedgerFlow depuis orv-partsdesk-test. Le pare-feu refuse toutefois le trafic TCP 5432. Le constat est réel, puisque les routes ne respectent pas la séparation prévue, mais pour en tirer un accès, il faut une autre défaillance, par exemple une modification ultérieure du pare-feu. C’est exactement ce que le rapport entend par gravité moyenne.
SEC-03 paraît le plus alarmant après SEC-01. L’exception EX-014 permet encore un point d’accès public : orv-partsdesk-test est passé de Sandbox à NonProduction le 2 juillet, et l’échéance du 30 juin n’a déclenché aucune revue. Sept exceptions sur onze sont échues. Vu comme un graphe, ce constat rejoint SEC-05, puisqu’orv-partsdesk-test est aussi le compte d’où part NET-31. Une entrée par ce point d’accès commencerait là où commence la route de SEC-05 et dépendrait ensuite des pare-feu, pas d’une frontière entre environnements. Deux lignes dans la liste d’un scanneur forment un seul chemin dans le graphe, et ce chemin exige encore une seconde défaillance.
SEC-06 reste en bas, mais protège le prochain compte
SEC-06 ressemble à une simple question d’hygiène : ACF-218 a déclaré orv-cartonspec-prod prêt malgré l’absence de responsable des coûts et de test des journaux. Ce constat n’ouvre aucun point d’entrée par lui-même. Il encadre plutôt le prochain compte de production, puisque nacre-1.3.2 ne prévoit aucune vérification indépendante avant la mise en production. Voilà pourquoi il partage la dernière fenêtre avec SEC-03, et pourquoi le rapport recommande de suspendre l’expansion jusqu’à ce que les contrôles requis réussissent leurs essais.
À retenir
- Classez la relation, pas la ressource : politique de confiance, droit de l’appelant et action permise, lus ensemble.
- Voyez chaque contrôle conforme comme une question : qui peut le désactiver ?
- Regroupez les constats selon l’identité ou le compte qu’ils partagent. WorkloadAdmin relie SEC-02 et SEC-04 ; orv-partsdesk-test relie SEC-03 et SEC-05.
- Un saut refusé peut faire reculer un constat, jamais le faire disparaître.
Une Revue de sécurité infonuagique produit ce genre de classement : les chemins d’abord, chaque constat accompagné de l’essai qui prouve sa correction — un jeton de compilation refusé, une livraison approuvée qui réussit toujours. Le rapport type montre ce que cela donne pour les 48 comptes d’Orivane.