Un garde-fou est une règle que même l'administrateur du compte ne peut pas contourner. C'est ce qui le distingue d'une bonne pratique documentée, laquelle suppose que chacun l'ait lue et retenue au bon moment. Cette leçon montre quelles règles poser, comment un refus se propage dans la hiérarchie sans qu'on puisse le lever plus bas, et pourquoi l'étiquetage conditionne toute mesure ultérieure.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Poser les quatre garde-fous qui couvrent l'essentiel des accidents réels.
- Comprendre l'héritage : pourquoi un refus posé en haut ne se rattrape pas en bas.
- Diagnostiquer un refus qui semble incohérent avec les permissions affichées.
- Imposer un étiquetage à la création, plutôt que de le rattraper par campagnes.
Les garde-fous : interdire plutôt que recommander
Section intitulée « Les garde-fous : interdire plutôt que recommander »Un garde-fou est une règle que même l'administrateur du compte ne peut pas contourner. C'est toute la différence avec une bonne pratique documentée, qui suppose que chacun l'ait lue, comprise et retenue au bon moment. Ces règles ne distribuent aucun droit : elles retirent des possibilités, y compris à qui possède par ailleurs toutes les permissions.
| Fournisseur | Le mécanisme | Portée d'application |
|---|---|---|
| AWS | politiques de contrôle de service | unité d'organisation, compte, organisation entière |
| Azure | Azure Policy | groupe d'administration, souscription, groupe de ressources |
| Google Cloud | politiques d'organisation | organisation, dossier, projet |
Comment une règle posée en haut atteint-elle les comptes du bas ?
Section intitulée « Comment une règle posée en haut atteint-elle les comptes du bas ? »Une politique s'applique au nœud où vous l'attachez et à tout ce qui se trouve en dessous. Attachée à la racine de l'organisation, elle vaut pour tous les comptes ; attachée à une unité, elle ne vaut que pour cette branche. C'est ce qui permet de poser une règle une fois pour des dizaines de comptes.
La propriété décisive est la suivante, et elle vaut chez les trois grands fournisseurs sous des formulations proches : un refus hérité ne peut pas être levé plus bas. L'administrateur d'un compte enfant, même avec tous les droits de son compte, ne peut pas s'accorder ce que le parent a interdit. C'est exactement ce qu'on attend d'un garde-fou, et c'est ce qui le distingue d'une permission, laquelle se cumule au contraire par unions successives.
Deux conséquences pratiques en découlent.
Le droit effectif est une intersection. Une identité peut faire ce que son
IAM autorise et ce qu'aucun garde-fou hérité n'interdit. Un Allow généreux
au niveau du compte ne sert donc à rien si une politique d'organisation ferme la
porte plus haut.
Le diagnostic d'un refus commence par le haut. Le symptôme est trompeur : la console affiche un accès refusé alors que l'utilisateur voit ses permissions et qu'elles semblent suffisantes. Le réflexe utile est de remonter la hiérarchie avant d'inspecter la politique de l'identité, en s'aidant de l'outil d'analyse de politique du fournisseur, qui indique quel niveau a produit le refus.
Les quatre garde-fous à poser en premier
Section intitulée « Les quatre garde-fous à poser en premier »Quatre garde-fous suffisent à couvrir l'essentiel des accidents réellement constatés. Ils se posent tôt, coûtent peu et se justifient facilement auprès des équipes, ce qui n'est pas le cas d'une politique tatillonne :
- Restreindre les régions autorisées. C'est le plus rentable : créer des ressources dans une région que personne ne surveille est le premier geste d'un attaquant qui exploite des identifiants volés pour miner.
- Interdire la suppression et la désactivation des journaux d'audit, sans exception locale. Sans cela, le compte de journalisation décrit plus haut ne garantit rien.
- Interdire l'exposition publique du stockage objet, sauf sur les comptes qui hébergent délibérément un site statique.
- Imposer les étiquettes obligatoires dès la création. Le problème de couverture évoqué plus haut se règle en amont, au lieu d'être rattrapé par des campagnes de nettoyage sans fin.
Un garde-fou d'un autre genre mérite d'être connu : le verrou de suppression. Il ne s'applique pas à une branche de l'organisation mais à une ressource précise, et il refuse l'effacement tant qu'un humain ne l'a pas retiré délibérément. Azure le propose sous forme de verrous posés sur une ressource ou un groupe, Google Cloud sous forme d'un blocage de suppression du projet, AWS par des protections activables sur les objets qui le méritent, instances et bases en tête.
Posez-en sur le petit nombre de ressources dont la disparition serait une catastrophe : la base de production, le seau qui reçoit les sauvegardes, la zone DNS du domaine principal. Sur ces objets, le verrou transforme une erreur irréversible en message d'erreur, ce qui est exactement le résultat recherché. N'en posez pas partout : un verrou oublié sur une ressource jetable finit par bloquer la destruction d'un environnement entier, et c'est ainsi qu'on prend l'habitude de les retirer sans lire.
L'étiquetage, sans lequel rien n'est mesurable
Section intitulée « L'étiquetage, sans lequel rien n'est mesurable »Une ressource sans étiquette est une ressource que personne ne revendique, et que personne n'osera supprimer. C'est le mécanisme exact par lequel une facture gonfle : le doute protège le gaspillage.
Trois étiquettes suffisent pour commencer, et elles répondent aux trois questions qu'on se pose devant une ressource inconnue.
| Étiquette | Répond à | Exemple |
|---|---|---|
environnement | Puis-je y toucher sans risque ? | production, recette, bac-a-sable |
equipe | Qui appelle-t-on ? | paiement |
projet | Qui paie ? | refonte-caisse |
La troisième est celle qui transforme une facture en information. Sans elle, la question « combien nous a coûté la refonte » n'a aucune réponse, et les arbitrages se prennent au ressenti.
Deux conditions pour que cela fonctionne réellement :
Étiqueter à la création, par le code. Une étiquette ajoutée après coup n'est jamais complète, et personne ne reprendra les six cents ressources existantes. Les modules d'infrastructure as code doivent poser les étiquettes par défaut, sans que l'utilisateur ait à y penser.
Vérifier périodiquement le taux de couverture. Le chiffre à suivre est le pourcentage de ressources correctement étiquetées. Tant qu'il n'est pas proche de 100, les rapports de coûts sous-estiment tout ce qui est mal rangé.