Challenge Sécurité : faire tourner un secret, révoquer un robot, et le prouver

Ce challenge ne vous donne aucune commande : il vous confie un robot, un incident et un journal, et vous demande les preuves. Il s'adresse à qui a suivi les leçons IAM, Secret Manager, Key Manager et Audit Trail, et veut savoir s'il saurait les enchaîner sans la page sous les yeux. Vous en repartirez avec une identité au strict nécessaire, une rotation sans coupure que vous avez prouvée, une révocation d'urgence datée dans le journal, et un projet revenu à zéro malgré les protections. Le corrigé est replié en bas de page : ne l'ouvrez qu'après avoir livré, ou après une heure de blocage réel.

Ce que vous allez faire

• Donner à un robot le droit de lire une valeur et de chiffrer, et rien d'autre.
• Faire tourner un secret puis une clé, sans que le robot s'en aperçoive.
• Révoquer une clé API compromise et retrouver ses dernières actions.
• Détruire ce que les protections contre la suppression retiennent.

Le besoin

Un robot de sauvegarde tourne chaque nuit : il lit le mot de passe d'une base dans Secret Manager, chiffre l'archive avec une clé de Key Manager, et dépose le résultat. Il n'a pas de visage, pas de console, et personne ne doit pouvoir se servir de sa clé API pour faire autre chose que ces deux gestes. Trois événements vont rythmer votre session, dans cet ordre.

D'abord, l'équipe base de données change le mot de passe : le robot doit lire la nouvelle valeur dès sa prochaine exécution, sans qu'une seule exécution échoue entre les deux. Ensuite, la politique interne impose de faire tourner la clé de chiffrement une fois par trimestre, sans rendre illisibles les archives déjà chiffrées. Enfin, la clé API du robot fuit dans un dépôt public : vous devez la neutraliser en quelques minutes, puis établir ce qu'elle a fait avant et après la fuite.

Rien n'a besoin de survivre à la session : le projet se construit, se prouve et se détruit le même jour, protections comprises.

Les contraintes

Chaque contrainte a une preuve associée, et c'est la preuve qui compte, pas la déclaration. Une liste vide obtenue avec la clé du robot ne prouve rien, la leçon IAM l'a montré : seule une écriture refusée prouve une restriction.

#	Contrainte	Preuve attendue
1	Le robot est une application, jamais un utilisateur, et sa clé API expire dans les sept jours	la fiche de l'application et la date d'expiration de la clé
2	Sa politique ne donne, sur le seul projet du challenge, que le droit de lire la valeur d'un secret et de chiffrer avec une clé	deux refus exacts, obtenus avec la clé du robot : créer un secret, supprimer la clé
3	Le mot de passe tourne sans coupure : une nouvelle version est ajoutée, le robot lit la nouvelle, l'ancienne reste lisible le temps de vérifier, puis n'est plus servie	la valeur lue avant et après, et l'état des deux versions
4	La clé de chiffrement tourne sans rendre l'archive existante illisible	le compteur de rotation, et le déchiffrement réussi d'une archive chiffrée avant la rotation
5	La clé API compromise est neutralisée et ses dernières actions sont retrouvées dans le journal, avec leur statut et leur adresse source	un appel refusé après révocation, et un extrait d'Audit Trail qui nomme l'application
6	Le secret et la clé sont protégés contre la suppression pendant toute la session, et détruits quand même à la fin	le refus de suppression pendant la session, puis la suppression réussie

Glissez pour voir

Une septième exigence se règle par une phrase : expliquez pourquoi le journal d'audit ne contient jamais la valeur du mot de passe, même quand vous l'avez écrite, et ce qu'il contient à la place.

Ce qui vous disqualifie

Une clé API créée sur votre propre compte pour « aller plus vite » : elle porte tous vos droits et survit au robot. Une politique qui donne un jeu IAM à l'application : elle peut alors se réécrire ses propres droits. Et un secret supprimé sans passer par la suppression programmée quand vous en aviez besoin : côté Secret Manager, la suppression est immédiate et sans retour.

Ce que vous devez livrer

Un dossier de six éléments, lisibles par quelqu'un qui n'a pas assisté à la session. Le format est libre, le contenu ne l'est pas.

1. L'inventaire : projet, application, politique avec ses jeux de permissions, clé API et son expiration, secret, clé de chiffrement, dans l'ordre de création.
2. Les six preuves du tableau des contraintes, sous forme de sorties de commandes recopiées et datées.
3. La chronologie de l'incident : l'heure de la fuite supposée, l'heure de la révocation, et l'extrait du journal qui montre les appels de l'application, réussis puis refusés, avec le champ de statut exact.
4. Le coût de la session, lu dans la consommation, et le poste qui l'a généré.
5. La destruction, dans l'ordre que les protections imposent, avec le message exact de chaque refus rencontré et la commande qui l'a levé.
6. Trois réponses écrites : pourquoi le journal ne contient pas la valeur ; pourquoi une liste vide obtenue avec la clé du robot ne prouve rien ; ce qui distingue la suppression d'un secret de celle d'une clé de chiffrement, et ce que ça change pour un incident.

Comment vous auto-évaluer

La grille se lit ligne par ligne, et une ligne à zéro sur les contraintes 2 ou 5 rend le reste secondaire : un robot qui peut faire plus que lire et chiffrer, ou une clé compromise encore active, ne sont pas « presque » sécurisés.

Critère	Ce qui vaut les points	Points
Contraintes 1 à 6 prouvées	chaque preuve est une sortie de commande, datée, reliée à la contrainte	6 × 2
Chronologie de l'incident	les appels de l'application, avant et après révocation, avec statut et adresse source	3
Ordre de destruction	chaque refus de protection cité avec sa cause, puis levé	2
Les trois réponses	chacune s'appuie sur un fait d'une leçon, pas sur une intuition	3

Glissez pour voir

Seuil : 14 sur 20. En dessous, rejouez le challenge une semaine plus tard, sans relire le corrigé entre-temps. Au-dessus, vous êtes prêt pour le lab fil rouge du volet, qui ajoute le refus vu depuis l'application elle-même.

La solution, repliée

N'ouvrez ce bloc qu'après avoir livré, ou après une heure de blocage réel. Il ne contient aucune commande nouvelle : chaque geste renvoie à la leçon qui l'a validée en lab, avec l'ancre exacte.

Le plan, les pièges et l'ordre de destruction

Le robot est une application, et sa clé expire. La leçon IAM tranche la question de l'identité, une application n'a pas accès à la console et c'est l'identité correcte pour un script, et rappelle que l'organisation peut imposer l'expiration par ses réglages de sécurité (utilisateur ou application, ce que votre organisation applique déjà). Sur l'organisation de test, expires-at est imposé : sans lui, la création de clé est refusée.

Le jeu de permissions qui lit une valeur n'est pas celui qu'on croit. Le lab fil rouge du volet l'a mesuré : SecretManagerReadOnly ne lit que les métadonnées, SecretManagerSecretAccess lit la valeur, et seule la description du jeu le dit. Ajoutez le jeu Key Manager qui chiffre, limitez la portée au projet, et rien d'autre (quel jeu de permissions autorise vraiment à lire un secret).

Les deux refus se provoquent, ils ne se supposent pas. Avec la clé du robot, tentez de créer un secret puis de supprimer la clé de chiffrement : les deux messages insufficient permissions sont la preuve, là où une liste vide n'en est pas une, IAM filtrant les listes en silence (comment prouver qu'une restriction tient).

La rotation du secret est une nouvelle version, pas une modification. Les révisions antérieures restent lisibles après l'ajout, ce qui permet de vérifier avant de couper ; c'est la leçon Secret Manager qui montre comment lire la dernière version, puis ce que devient l'ancienne (que devient l'ancienne version). Piège relevé en lab : on écrit en clair et on lit en base64, et envoyer du base64 à l'écriture stocke le base64 lui-même sans aucune erreur.

La rotation de la clé ne rechiffre rien. Le compteur passe de 1 à 2 et l'ancien chiffré reste déchiffrable : c'est exactement ce que la contrainte 4 demande de prouver, et la raison pour laquelle invalider d'anciennes archives impose de les rechiffrer (que devient l'existant après une rotation). Second piège de format : plaintext attend du base64, à l'inverse du champ data de Secret Manager, et un chiffrement sur du texte brut rend un ciphertext vide sans erreur (le format qui piège tout le monde).

La révocation se fait sur la clé API de l'application, pas sur l'application. Puis un appel avec la clé révoquée doit être refusé, et le journal doit montrer la séquence : la leçon Audit Trail explique comment retrouver une action précise, rappelle que le champ s'appelle status_code et non status, et que l'événement arrive environ vingt secondes après le geste (retrouver une action précise, ce que contient un événement).

Le journal ne contient jamais la valeur : le corps d'une création de version ne porte que l'identifiant du secret, alors que la configuration du secret, type, étiquettes, protection, y figure. C'est la réponse attendue à la septième exigence (le journal contient-il la valeur de mes secrets).

La destruction se heurte aux protections, et c'est voulu. Côté Secret Manager, la protection se pose et se lève par des commandes dédiées, et la suppression est ensuite immédiate ; côté Key Manager, les clés naissent protégées, la suppression refuse tant que la protection n'est pas levée, puis elle est programmée sur 7 jours et la clé disparaît de la liste sans commande de restauration (empêcher une suppression accidentelle, nettoyer, Secret Manager, nettoyer, Key Manager). C'est la troisième réponse écrite : un secret supprimé est perdu tout de suite, une clé supprimée reste sept jours dans un état irréversible depuis le CLI, et un incident se traite donc différemment de part et d'autre.

Le dernier refus vient d'un objet que vous n'avez pas créé : le groupe de sécurité par défaut du projet bloque la suppression du projet sans se nommer dans le message (dans quel ordre tout détruire).

À retenir

• Un robot est une application avec une clé qui expire, jamais un utilisateur : une clé humaine porte tous les droits de la personne et lui survit.
• SecretManagerSecretAccess lit la valeur, SecretManagerReadOnly non, et seule la description du jeu le dit.
• Une restriction se prouve par un refus, insufficient permissions, jamais par une liste vide.
• Une rotation de secret est une version de plus, lisible à côté de l'ancienne le temps de vérifier ; on écrit en clair, on lit en base64.
• Une rotation de clé ne rechiffre rien : l'ancien chiffré reste lisible, et plaintext attend du base64.
• Le journal nomme l'application, le statut dans status_code et l'adresse source, environ vingt secondes après le geste, sans jamais la valeur du secret.
• Secret Manager supprime tout de suite, Key Manager programme sur 7 jours, et les deux protègent contre la suppression, mais pas par défaut du même côté.

Pour aller plus loin

• Infrastructure as Code : qui fait quoi : le volet suivant confie ce robot à une chaîne d'intégration, avec la même identité minimale.
• Terraform : provisionner, et surtout détruire : la clé API restreinte de ce challenge est celle qu'un terraform apply devrait porter.

Ressources externes

• Documentation Secret Manager : versions, types, protection et politique éphémère.
• Documentation Key Manager : usages des clés, rotation et suppression programmée.
• Documentation Audit Trail : produits couverts, rétention et export.

×

📖 Voir la documentation →