Sécuriser et auditer un compte

Pourquoi

Un lundi matin, le réplica en lecture de sig-db a disparu. Les tableaux de bord de la leçon 14 montrent l'heure : dimanche, 22 h 47. Personne, dans l'équipe, ne se souvient de l'avoir supprimé. Était-ce une erreur de manipulation, un script de nettoyage trop zélé, ou quelqu'un qui n'aurait pas dû avoir accès ? Sans réponse, on ne sait ni s'il faut corriger un script, ni s'il faut révoquer des accès, ni quoi écrire au client.

Au même moment, la métropole envoie son questionnaire de sécurité annuel. Il demande, entre autres : la liste des personnes et des automates qui ont un accès en écriture à la production, la date de la dernière revue des accès, la durée de conservation des journaux d'administration, et l'état du chiffrement des données au repos. Il demande aussi la procédure suivie en cas de fuite d'une clé d'accès.

Ce sont deux faces du même besoin : rendre l'exploitation vérifiable. Le cours Le cloud : les fondamentaux a posé les identités et les droits ; la leçon 1 de ce cours a organisé le compte. Cette leçon donne les moyens de prouver que cette organisation est tenue, et de réagir quand elle ne l'est pas.

Les concepts

Audit Trail : ce qu'il enregistre

Audit Trail enregistre les actions effectuées sur les ressources d'une organisation, qu'elles aient réussi ou qu'elles aient été refusées. Pour chaque événement, le SDK Go décrit les champs suivants : la date (recorded_at), la localisation, le principal (l'utilisateur ou l'application à l'origine), l'organisation et le projet, l'adresse IP source, le logiciel client (user_agent), le produit, le service et la méthode d'API appelés (DeleteReadReplica, CreateAPIKey...), les ressources concernées, le corps de la requête et le code de statut (200 si l'action a été exécutée, 403 si la permission a été refusée).

Quelques propriétés, au 5 octobre 2026 :

• Audit Trail est gratuit.
• Les événements sont stockés dans la région où l'action a eu lieu. Les produits globaux (IAM, Account, Edge Services) sont enregistrés comme des événements de fr-par.
• Depuis septembre 2025, les connexions des membres à la console sont aussi journalisées (méthodes CreatePasswordLogin, CreateOAuth2Login, CheckLoginMFAOTP, CommitLogin...).
• Les événements peuvent être exportés chaque jour vers un bucket Object Storage : chaque jour, ceux de la veille, sous la forme préfixe/AAAA/MM/JJ/logs_xxx.json. Le premier export reprend les 90 derniers jours. Une seule configuration d'export active par région.
• Une intégration native avec Splunk existe.

La documentation consultée ne donne pas explicitement la durée de conservation des événements dans la console ; la mention des « 90 derniers jours » pour le premier export est la seule indication chiffrée. Pour une conservation maîtrisée et prouvable, l'export est la réponse.

Audit Trail : ce qu'il n'enregistre pas

C'est la partie la plus importante à connaître, parce qu'un auditeur la demandera. La page d'intégration des produits, validée le 29 septembre 2026, distingue les produits intégrés et ceux qui ne le sont pas encore. Pour l'architecture de Signalements :

Deux remarques de lecture :

• La même page liste à la fois « PostgreSQL & MySQL » comme intégré et « Managed Databases » comme non intégré. La liste détaillée des points d'accès journalisés lève l'ambiguïté pour PostgreSQL : suppression d'instance, de réplica, de sauvegarde, d'utilisateur, modification des ACL, etc., y figurent.
• Pour Secret Manager, la liste des points d'accès journalisés contient la création, la modification, la suppression, la protection et les versions des secrets, mais pas la lecture d'une version. Au 5 octobre 2026, Audit Trail ne dit donc pas qui a lu un secret.

Conséquence pour Signalements : la suppression d'une photo dans le bucket, le remplacement d'une image dans le registre ou la lecture du mot de passe de la base ne laissent pas de trace dans Audit Trail. Ces trous se compensent ailleurs : versionnement et Object Lock pour le bucket, signature des images (cours Construire des images de conteneurs), rotation des secrets.

Être prévenu plutôt que chercher

Depuis avril 2026, Audit Trail propose des alertes préconfigurées, à activer une à une dans la console, par région. La documentation en cite des exemples : ApiKeyCreated, ApiKeyDeleted, ApiKeyCreationUnauthorized, IAMPolicyCreated, IAMPolicyCreationUnauthorized, et HttpForbiddenErrorRateHigh, déclenchée par plus de 20 réponses 403 en cinq minutes (essai de force brute ou mauvaise configuration). Les notifications partent par courriel vers les adresses abonnées au type de notification Security dans le gestionnaire de notifications du compte : sans cet abonnement, les alertes se déclenchent sans que personne ne les lise.

Revoir les accès

Une revue des accès est le contrôle périodique, par une personne qui en a la responsabilité, que chaque accès existant est encore justifié. Le guide d'hygiène de l'ANSSI et les CIS Controls (contrôles 5 et 6) en font une mesure de base. Elle porte sur quatre objets IAM :

• les membres : qui est encore dans l'organisation, avec le second facteur, et quand s'est-il connu pour la dernière fois (champ last_login_at) ;
• les applications : à quoi sert chacune, et a-t-elle encore des clés ;
• les clés d'API : qui les porte, quand expirent-elles, lesquelles n'expirent jamais ;
• les politiques : lesquelles portent sur toute l'organisation plutôt que sur un projet, lesquelles accordent un accès complet.

Deux réglages d'organisation réduisent ce que la revue doit rattraper :

• la durée maximale des clés d'API : une fois fixée, toute nouvelle clé (propriétaire compris) doit avoir une date d'expiration conforme. Elle ne s'applique pas aux clés existantes : on peut ajouter une date d'expiration à une clé qui n'en a pas, mais pas modifier une date existante ; une clé non conforme se révoque et se recrée. Les sessions de la console ont aussi une durée maximale, de 30 jours par défaut ;
• l'authentification à facteurs multiples obligatoire pour toute l'organisation, avec un délai de grâce au-delà duquel les comptes non conformes sont verrouillés.

Ce qui est chiffré au repos, et ce qui ne l'est pas

Le questionnaire de la métropole demande « l'état du chiffrement des données au repos ». La réponse honnête, au 5 octobre 2026 et d'après la documentation de Scaleway, n'est pas « tout est chiffré » :

Deux précisions importantes. Pour SSE-ONE et SSE-KMS, les objets déposés avant l'activation ne sont pas chiffrés : il faut les recopier. Pour SSE-KMS, la documentation avertit que les jeux de permissions Object Storage ne suffisent plus : chaque principal qui lit ou écrit doit aussi avoir KeyManagerKeyDecrypt ou KeyManagerKeyEncrypt, sans quoi il reçoit « access denied », même avec ObjectStorageFullAccess. Le chiffrement d'enveloppe et ce qu'apportent réellement les clés gérées par le client sont traités dans le cours Cloud souverain.

Les sauvegardes, cible des attaquants

Un rançongiciel moderne commence par supprimer les sauvegardes avant de chiffrer les données. Une clé d'API dérobée avec des droits d'écriture sur le bucket des sauvegardes suffit. Les protections vues au cours précédent (versionnement, Object Lock en mode conformité, voir Le stockage) prennent ici tout leur sens : une sauvegarde verrouillée ne peut pas être supprimée, même par une clé qui en a le droit, avant sa date de fin de rétention. Et comme Object Storage n'est pas couvert par Audit Trail, c'est la protection elle-même, et non le journal, qui fait foi.

Certifications et qualification

Les certifications de Scaleway (ISO/IEC 27001, hébergeur de données de santé) et le statut de son offre SecNumCloud (en cours de qualification au 5 octobre 2026) sont détaillés dans le cours Cloud souverain. Retenez ici qu'une certification du fournisseur couvre sa part du modèle de responsabilité partagée : elle ne dit rien des droits que vous avez donnés, ni des buckets que vous avez laissé publics.

En pratique

Les commandes ont été vérifiées avec l'aide de la CLI scw 2.62 et les structures du SDK Go. Rappel vu au cours précédent : scw audit-trail event list renvoie la réponse complète de l'API, avec un tableau events et un jeton de page suivante, d'où les filtres .events[]. La leçon ne montre aucune sortie.

1. Retrouver qui a supprimé le réplica

$ scw audit-trail event list region=fr-par \
    resource-type=rdb_instance_read_replica \
    recorded-after=2026-10-04T20:00:00Z recorded-before=2026-10-05T00:00:00Z \
    -o json | jq '.events[] | {recorded_at, method_name, status_code,
                               principal: .principal.id, source_ip, user_agent}'

• resource-type filtre sur un type de ressource ; l'aide de la CLI en liste plus de cent, de iam_api_key à serverless_containers_container.
• recorded-after et recorded-before bornent la période (par défaut, la dernière heure seulement : sans eux, on ne voit presque rien).
• Le principal est un identifiant : scw iam user get <id> ou scw iam application get <id> dit de qui il s'agit.

Le user_agent est souvent la réponse la plus parlante : un scaleway-sdk-go suivi d'une version, ou le nom d'un fournisseur Terraform, désigne un automate ; un navigateur, une personne dans la console.

2. Les requêtes à connaître

Trois requêtes couvrent la plupart des enquêtes :

# Les refus des dernières 24 heures, regroupés par principal et par méthode
$ scw audit-trail event list region=fr-par status=403 recorded-after=-24h -o json \
    | jq -r '.events[] | [.principal.id, .method_name, .source_ip] | @tsv' \
    | sort | uniq -c | sort -rn

# Les clés d'API créées dans la semaine (IAM est global : région fr-par)
$ scw audit-trail event list region=fr-par method-name=CreateAPIKey recorded-after=-7d -o json \
    | jq '.events[] | {recorded_at, principal: .principal.id, source_ip, status_code}'

# Tout ce qu'a fait un principal donné, depuis une adresse donnée
$ scw audit-trail event list region=fr-par principal-id=<id> source-ip=<adresse> \
    recorded-after=-7d -o json | jq -r '.events[] | [.recorded_at, .method_name, .status_code] | @tsv'

La syntaxe des dates relatives (-24h, -7d) est celle de la CLI (scw help date). Une liste de refus dominée par un seul principal et une seule méthode signe en général une politique trop étroite ; une liste dispersée, sur de nombreuses méthodes, depuis une adresse inconnue, signe quelqu'un qui explore ce qu'une clé lui permet.

3. Conserver les événements hors d'atteinte

L'export se configure dans la console (Audit Trail, onglet d'export, par région ; la CLI 2.62 ne propose pas de commande pour cela). Préparez d'abord un bucket dédié, dans un projet de sécurité distinct de signalements-prod, auquel seule l'équipe sécurité a accès :

$ aws s3api create-bucket --bucket lyneko-audit-<suffixe> --object-lock-enabled-for-bucket
$ aws s3api put-object-lock-configuration --bucket lyneko-audit-<suffixe> \
    --object-lock-configuration \
    '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":400}}}'

• --object-lock-enabled-for-bucket active le versionnement et Object Lock dès la création. La documentation de Scaleway permet aussi de l'activer sur un bucket existant ; dans les deux cas, il ne se désactive plus, et le versionnement ne peut plus être suspendu.
• La rétention par défaut en mode COMPLIANCE empêche toute suppression des objets pendant 400 jours, même par le propriétaire du compte. Choisissez la durée avec le client : elle se raccourcit difficilement.

Puis, dans la console, créez l'export vers ce bucket avec un préfixe (audit-trail/fr-par/), et répétez pour chaque région utilisée. Le lendemain, vérifiez l'arrivée du premier fichier.

4. Activer les alertes et les recevoir

Dans la console : Audit Trail, région fr-par (où arrivent les événements IAM), onglet Alerts ; activez au minimum ApiKeyCreated, ApiKeyCreationUnauthorized, IAMPolicyCreated, IAMPolicyCreationUnauthorized et HttpForbiddenErrorRateHigh. Puis, dans le gestionnaire de notifications du compte, abonnez une adresse d'équipe (pas une adresse personnelle) au type Security. Testez : créez une clé d'API de test à expiration courte, vérifiez la réception, supprimez la clé.

5. La revue des accès outillée

Le script suivant produit l'état que la revue doit examiner. Il ne modifie rien.

#!/usr/bin/env bash
# Revue des accès IAM d'une organisation Scaleway : membres, clés, politiques larges.
# Usage : ./revue-acces.sh > revue-$(date +%F).txt   (exige scw et jq)
set -euo pipefail
export LC_ALL=C.UTF-8
maintenant=$(date -u +%Y-%m-%dT%H:%M:%SZ)

echo "== Membres sans second facteur, ou sans connexion depuis 90 jours"
scw iam user list -o json | jq -r --arg seuil "$(date -u -d '-90 days' +%Y-%m-%dT%H:%M:%SZ)" '
  .[] | select((.mfa | not) or ((.last_login_at // "") < $seuil))
  | [.email, .type, (if .mfa then "mfa" else "SANS-MFA" end), (.last_login_at // "jamais")] | @tsv'

echo "== Clés d'API sans expiration, ou expirées"
scw iam api-key list -o json | jq -r --arg now "$maintenant" '
  .[] | select(.expires_at == null or .expires_at < $now)
  | [.access_key, (.application_id // .user_id // "?"), (.expires_at // "JAMAIS"), .description] | @tsv'

echo "== Applications sans aucune clé (à supprimer ?)"
scw iam application list -o json | jq -r '.[] | select(.nb_api_keys == 0) | [.id, .name] | @tsv'

echo "== Règles portant sur toute l'organisation"
for p in $(scw iam policy list -o json | jq -r '.[].id'); do
  scw iam rule list "$p" -o json | jq -r --arg p "$p" '
    .[] | select(.organization_id != null)
    | [$p, (.permission_set_names // [] | join(","))] | @tsv'
done

Chaque bloc correspond à une question de la revue. Le résultat est daté, archivé avec la décision prise pour chaque ligne (« conservé, justifié par... », « révoqué le... ») : c'est cette trace que l'auditeur demandera, pas le script. Pour les règles de portée organisation, une partie est normale (la gestion de l'IAM ou de la facturation se donne à l'échelle de l'organisation) ; ce qui doit attirer l'œil, c'est un AllProductsFullAccess ou un jeu « complet » sur un produit de production.

Fixez enfin, dans les paramètres de sécurité de l'organisation, la durée maximale des clés d'API (90 jours, par exemple) et l'obligation du second facteur, si ce n'est pas déjà fait à la leçon 1.

6. Combler les manques de chiffrement

Pour le bucket des photos, SSE-ONE se règle avec l'AWS CLI, d'après la documentation de Scaleway :

$ aws s3api put-bucket-encryption --bucket signalements-pj-<suffixe> \
    --server-side-encryption-configuration \
    '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'
$ aws s3api get-bucket-encryption --bucket signalements-pj-<suffixe>

Les nouveaux objets seront chiffrés ; les anciens restent en clair tant qu'ils ne sont pas réécrits, par exemple en les copiant vers un nouveau préfixe (aws s3 cp s3://<bucket>/photos/ s3://<bucket>/photos-chiffrees/ --recursive) puis en basculant l'application et en supprimant les originaux. Pour des clés gérées dans Key Manager, SSE-KMS s'active depuis la console, après avoir donné les jeux de permissions Key Manager aux applications qui lisent et écrivent.

Pour la base, le chiffrement au repos s'active par une mise à niveau, irréversible :

$ scw rdb instance upgrade <id-de-sig-db> enable-encryption=true region=fr-par

Faites-le d'abord en préproduction, dans une fenêtre de maintenance, et vérifiez la documentation pour l'effet sur la disponibilité pendant l'opération.

7. La procédure « clé compromise »

Une clé d'accès Scaleway (SCW...) apparaît dans un dépôt public, un ticket ou une capture d'écran. Le déroulé suivant suit la logique du guide de réponse aux incidents du NIST (SP 800-61, révision 3) : contenir, enquêter, éradiquer, rétablir, tirer les leçons. Il doit être écrit avant l'incident, et répété.

1. Révoquer immédiatement, sans attendre de savoir si la clé a servi :

   $ scw iam api-key get SCWXXXXXXXXXXXXXXXXX -o json \
       | jq '{application_id, user_id, description, default_project_id, created_at}'
   $ scw iam api-key delete SCWXXXXXXXXXXXXXXXXX
   

   La première commande note à qui appartenait la clé, avant qu'elle ne disparaisse.

2. Rétablir le service légitime : créer une nouvelle clé pour le porteur (avec expiration), la déposer là où l'ancienne servait (secret de CI, Secret Manager), redéployer ce qui en dépend.

3. Enquêter dans Audit Trail, sur toutes les régions utilisées, depuis la création de la clé : toutes les actions du principal porteur, en isolant les adresses IP et les logiciels clients inhabituels. Chercher en priorité les actions de persistance : nouvelles clés (CreateAPIKey), nouvelles politiques, nouveaux membres ou applications, clés SSH ajoutées, instances créées (minage de cryptomonnaie).

4. Éradiquer tout ce que l'enquête a trouvé : clés et politiques créées par l'attaquant, ressources lancées, règles modifiées.

5. Couvrir les angles morts : la clé avait-elle des droits sur Object Storage, le registre ou Block Storage, que Audit Trail ne journalise pas ? Si oui, considérer que les données correspondantes ont pu être lues ou modifiées : vérifier les versions des objets, l'intégrité des images, et changer les secrets que la clé permettait de lire.

6. Informer : le responsable de la sécurité, le client si ses données sont concernées, et évaluer avec le délégué à la protection des données une notification à la CNIL (72 heures au plus pour une violation de données personnelles, article 33 du RGPD).

7. Corriger la cause : pourquoi la clé était-elle là où elle a fui ? Détection de secrets avant commit, clés plus courtes, droits plus étroits. Rédiger le postmortem.

Sous le capot

Où naît un événement d'audit. Chaque appel à l'API Scaleway traverse une passerelle qui authentifie la clé, résout le principal et évalue ses politiques ; c'est à ce niveau que l'appel, autorisé ou refusé, est connu, avec son adresse source et son logiciel client. Pour qu'un produit soit « intégré » à Audit Trail, il faut que son API émette ces événements avec la description des ressources touchées : c'est un travail produit par produit, d'où la liste qui s'allonge au fil des mois. Les opérations du plan de données (lire un objet dans un bucket, tirer une image d'un registre) passent par d'autres chemins, beaucoup plus volumineux, et sont les dernières à être couvertes chez la plupart des fournisseurs.

Pourquoi l'export doit être immuable. Un journal d'audit que l'attaquant peut effacer ne prouve rien. Le bucket d'export, dans un projet séparé, avec Object Lock en mode conformité, garantit que même un accès complet au projet de production ne permet pas de faire disparaître les traces de ce qui y a été fait.

Le chiffrement au repos protège contre quoi ? Contre la perte ou le vol d'un support physique, et contre une mauvaise réaffectation de disques. Pas contre une clé d'API volée : l'API déchiffre pour quiconque est autorisé. C'est pourquoi le chiffrement au repos complète le contrôle d'accès sans jamais le remplacer, et pourquoi SSE-KMS ajoute une seconde autorisation (sur la clé) à la première (sur le bucket).

Pièges courants

Chercher sans borner la période. scw audit-trail event list ne renvoie, par défaut, que la dernière heure. « Aucun événement » ne veut souvent rien dire d'autre.

Chercher dans la mauvaise région. Les événements sont rangés dans la région de l'action ; ceux de l'IAM, dans fr-par. Une enquête complète parcourt toutes les régions utilisées.

Conclure à l'innocence d'un silence. Une clé qui n'a laissé aucune trace dans Audit Trail a peut-être servi à lire tout un bucket : Object Storage n'est pas journalisé.

Activer les alertes sans abonnement. Les alertes d'Audit Trail sont envoyées aux abonnés du type Security ; sans abonné, elles se déclenchent dans le vide.

Fixer une durée maximale des clés et croire le problème réglé. Elle ne vaut que pour les clés créées ensuite. Les anciennes clés sans expiration restent valides jusqu'à ce que la revue les traite.

Activer SSE-KMS sans donner les droits Key Manager. Les dépôts de photos échouent soudain en « access denied », alors que la politique Object Storage n'a pas changé.

Une revue sans décision. Une liste produite et jamais tranchée n'est pas une revue. Chaque ligne doit finir par « conservé, parce que » ou « révoqué le ».

Sécurité

Cette leçon est entièrement consacrée à la sécurité ; quelques principes transverses la résument :

• Séparer les rôles. Le projet de sécurité (journaux, sauvegardes verrouillées) n'est pas administré par les mêmes clés que la production. Une compromission de la production ne doit pas pouvoir effacer ses propres traces.
• Moindre privilège, revu. Les droits accordés pour un incident ou une migration ont une date de fin, et la revue vérifie qu'ils ont été retirés.
• Prévenir plutôt que constater. Les alertes sur la création de clés et de politiques détectent la persistance d'un attaquant en minutes ; la revue trimestrielle la détecte en mois.
• Connaître ses angles morts. La liste des produits non couverts par Audit Trail fait partie du dossier de sécurité ; elle se relit à chaque évolution de la documentation.
• Répéter la procédure. Une procédure de réponse jamais jouée échoue sur un détail (qui a les droits de supprimer la clé ? où est la nouvelle ?). Un exercice semestriel, avec une clé de test, suffit.

En production

• Une revue des accès trimestrielle, avec le script de la pratique, un responsable nommé, et une archive des décisions. Les départs de l'équipe déclenchent une revue immédiate, sans attendre le trimestre.
• Les exports d'Audit Trail vers un outil d'analyse. Le format JSON quotidien s'ingère dans un outil de recherche (l'intégration Splunk est documentée ; d'autres outils lisent le bucket). Garder un an d'événements consultables est une demande fréquente des clients publics.
• Les clés des automates sont courtes et tournantes. Une rotation automatique (création de la nouvelle clé, mise à jour du secret, suppression de l'ancienne) rend la fuite d'une clé moins grave et la procédure de compromission plus banale.
• Un tableau de bord de l'hygiène : nombre de clés sans expiration, de membres sans second facteur, de buckets sans chiffrement. Des chiffres qui ne doivent que baisser.
• Chez Lyneko, les pipelines de déploiement reposent sur des applications IAM dédiées par projet, et les secrets des applications sur Kapsule sont tirés de Secret Manager par External Secrets (GitOps avec Argo CD, leçon 8) : la revue porte donc autant sur ces applications que sur les personnes.

Exercices

1. Lire un événement (niveau 200). Un événement d'Audit Trail indique : méthode DeletePolicy, statut 200, principal une application nommée sig-deploiement, adresse source inconnue de l'équipe, logiciel client curl/8.5.0, dimanche à 3 h. Qu'en concluez-vous, et quelles sont vos trois premières actions ?

2. Répondre au questionnaire (niveau 300). Rédigez, en cinq à huit lignes, la réponse de Lyneko à la question « Quelle est la durée de conservation des journaux d'administration, et comment garantissez-vous leur intégrité ? » pour Signalements, en restant exact sur ce qu'Audit Trail couvre.

3. Détecter la persistance (niveau 300). Écrivez la commande qui liste, sur les sept derniers jours, toutes les créations réussies de clés d'API, de politiques et d'applications IAM, avec leur auteur et leur adresse source.

$ for m in CreateAPIKey CreatePolicy CreateApplication; do
    scw audit-trail event list region=fr-par method-name="$m" status=200 \
      recorded-after=-7d -o json \
      | jq -r --arg m "$m" '.events[] | [$m, .recorded_at, .principal.id, .source_ip] | @tsv'
  done

Récapitulatif

• Audit Trail enregistre qui a fait quoi, d'où, avec quel outil et avec quel résultat (200 ou 403) ; il est gratuit, régional (IAM dans fr-par) et s'exporte chaque jour vers un bucket.
• Au 5 octobre 2026, il ne couvre pas Object Storage, Block Storage, Container Registry ni la lecture des secrets : ces angles morts se compensent par d'autres mesures et se déclarent dans les dossiers de sécurité.
• Les alertes préconfigurées d'Audit Trail préviennent des créations de clés et de politiques et des rafales de refus, à condition d'abonner une adresse au type Security.
• La revue des accès porte sur les membres, les applications, les clés et les politiques ; elle se trace avec ses décisions. La durée maximale des clés et le second facteur obligatoire réduisent ce qu'elle doit rattraper.
• Le chiffrement au repos n'est pas partout par défaut : Object Storage (SSE-ONE, SSE-KMS, SSE-C) et la base (option irréversible) s'activent ; les volumes bloc restent à votre charge.
• Les journaux et les sauvegardes vivent dans un projet séparé, verrouillés par Object Lock.
• Une clé compromise se révoque d'abord, s'enquête ensuite, sur toutes les régions, en cherchant la persistance.

Pour aller plus loin

• La page des points d'accès journalisés par Audit Trail, produit par produit, à relire avant chaque audit.
• Le guide de réponse aux incidents du NIST (SP 800-61 révision 3) et le guide d'hygiène informatique de l'ANSSI.
• Le cours Gestion des secrets, pour la rotation automatique des clés et des mots de passe.
• La leçon suivante, Une architecture de référence, qui rassemble les mesures de cette leçon dans la liste de contrôle de mise en production.