Aller au contenu

AWS Mis à jour le 2026-07-04

Soutien à la conformité AWS : produire les preuves que les auditeurs et les clients demandent vraiment

Le soutien à la conformité AWS, c'est surtout de la production de preuves : revues d'accès, historique des changements, preuve de sauvegarde, attestations de chiffrement. Voici ce que les conversations Loi 25 et SOC 2 exigent vraiment de votre environnement AWS, sans course de dernière minute.

Le travail de conformité sur AWS, c’est surtout de la production de preuves. Que la demande vienne d’un auditeur SOC 2, du questionnaire de sécurité d’un gros client ou d’une revue Loi 25 au Québec, les questions convergent vers la même courte liste : qui a accès et qui l’a révisé, qu’est-ce qui a changé et quand, les sauvegardes roulent-elles et sont-elles testées, les données sont-elles chiffrées, où vivent-elles, et que se passe-t-il quand quelque chose tourne mal. Un environnement AWS bien opéré répond à tout ça avec un outillage déjà en marche; un environnement mal opéré devient une course de deux semaines chaque fois que le questionnaire arrive. Une précision avant tout : cet article porte sur la production de preuves techniques — ce n’est pas un avis juridique, et les décisions de portée Loi 25 ou SOC 2 reviennent à vos conseillers juridiques et d’audit.

Ce que vous décidez

La décision, c’est de savoir si la preuve de conformité est un sous-produit de votre façon d’opérer, ou un projet à refaire chaque fois qu’on demande. Le deuxième mode est le défaut et il est misérable : captures d’écran assemblées à la main, listes IAM collées dans des feuilles de calcul, une « politique » de sauvegarde écrite la semaine où l’auditeur l’a demandée. Le premier mode signifie que les systèmes de référence tournent en permanence — CloudTrail comme registre des changements, AWS Config comme historique de configuration, AWS Backup comme preuve de reprise, IAM et Identity Center comme registre des accès — et répondre à un auditeur devient une exportation, pas une enquête.

Il vaut la peine d’être précis sur ce que chaque cadre attend de la couche AWS. SOC 2 Type II cherche des contrôles qui opèrent sur une période — un instantané de durcissement unique vaut peu, tandis qu’un an de CloudTrail, des registres de revues d’accès trimestrielles et des journaux datés de tests de restauration valent beaucoup. La Loi 25 est la loi québécoise sur la protection des renseignements personnels : elle attend des mesures de sécurité proportionnelles à la sensibilité des données, un registre des incidents de confidentialité, et une évaluation avant de communiquer des renseignements personnels hors du Québec — c’est pourquoi les charges de travail canadiennes détenant des renseignements personnels se standardisent habituellement sur ca-central-1 et documentent tout service qui traite des données ailleurs. Et une frontière évite des confusions sans fin : les certifications d’AWS couvrent leur côté du modèle de responsabilité partagée. Vous en héritez pour la couche d’infrastructure — vous téléchargez les attestations depuis AWS Artifact (documentation) — mais rien de ce qu’AWS publie n’atteste votre hygiène IAM, vos tests de sauvegarde ou votre processus d’incident. Cette partie-là est toujours la vôtre.

Quoi vérifier en premier

  • La machinerie de preuve est-elle allumée? CloudTrail qui journalise en continu (avec validation des fichiers), Config qui enregistre dans les régions utilisées, des tâches de sauvegarde qui réussissent. S’il y a des trous, votre période de preuve commence quand vous les bouchez — une raison de le faire aujourd’hui.
  • La rétention des journaux contre la période d’audit. Un audit Type II couvre jusqu’à un an; CloudTrail livrant vers S3 avec des règles de cycle de vie plus courtes, c’est un constat en attente.
  • Où vivent réellement les renseignements personnels. Région par magasin de données, y compris les oubliés : réplicas S3, copies d’instantanés, intégrations tierces.
  • Si des revues d’accès ont déjà eu lieu. Les auditeurs demandent les registres de revue, pas seulement l’état IAM actuel.
  • Le registre des incidents. La Loi 25 attend que les incidents de confidentialité soient consignés et évalués; si le registre n’existe pas, aucun outil AWS ne comble ce trou.

Comment vérifier

Confirmez que les systèmes de référence enregistrent vraiment :

# CloudTrail : journalise, validé, multi-région?
aws cloudtrail describe-trails \
  --query 'trailList[].[Name,IsMultiRegionTrail,LogFileValidationEnabled]'
aws cloudtrail get-trail-status --name org-trail --query '[IsLogging,LatestDeliveryTime]'

# Config : enregistreur actif, livraison en cours?
aws configservice describe-configuration-recorder-status
aws configservice describe-delivery-channel-status

# Preuve de sauvegarde : tâches terminées et tests de restauration
aws backup list-backup-jobs --by-state COMPLETED --max-results 20
aws backup list-restore-jobs --max-results 10

Vérifiez au hasard l’histoire de chiffrement que les auditeurs demandent toujours :

# Chiffrement au repos, par magasin de données
aws rds describe-db-instances \
  --query 'DBInstances[].[DBInstanceIdentifier,StorageEncrypted]'
aws s3api get-bucket-encryption --bucket prod-data-bucket

Pour les attestations côté AWS, AWS Artifact > Reports dans la console est l’endroit où télécharger les rapports SOC d’AWS et autres certifications à remettre à votre auditeur — ce téléchargement constitue la totalité de la preuve « héritée ».

L’approche

  1. Allumez les registres avant tout. CloudTrail d’organisation avec validation des fichiers, livrant vers un compte d’archives dédié avec une rétention plus longue que votre période d’audit; Config enregistrant là où vivent les charges de travail. La base de référence CloudTrail et GuardDuty est l’installation concrète.
  2. Faites des revues d’accès un événement récurrent au calendrier, et gardez les artefacts. Chaque trimestre : exportez le rapport d’identifiants IAM et les affectations Identity Center, faites confirmer la liste par le responsable de chaque système, consignez l’approbation (un document daté dans un emplacement contrôlé suffit). Le registre de la revue est la preuve — une revue sans registre n’a pas eu lieu, aux yeux d’un audit.
  3. Transformez les sauvegardes en preuve de reprise. Historique des tâches plus journaux de tests de restauration datés et chronométrés. Une copie inter-région ou inter-compte renforce l’histoire de résilience et la preuve; la mécanique est dans AWS Backup avec copie inter-région.
  4. Écrivez la carte des données. Une page par système : quelles données personnelles ou sensibles, quels services AWS, quelles régions, qu’est-ce qui sort du Canada et pourquoi. Ce seul artefact répond à la moitié de chaque questionnaire de sécurité et sert de point de départ aux évaluations de transfert Loi 25 que vos conseillers mèneront.
  5. Montez le chemin d’incident. Un registre (même une feuille de calcul disciplinée), une grille de gravité, et les constats GuardDuty branchés sur un humain pour que la détection alimente le registre. Les auditeurs demandent « montrez-moi le dernier incident et ce que vous avez fait » — un petit incident ennuyant et bien documenté est une excellente réponse.
  6. Automatisez les exportations récurrentes. Des règles Config ou des contrôles Security Hub mappés aux critères de votre cadre donnent un historique réussite/échec collecté en continu au lieu d’une chasse aux captures d’écran trimestrielle. AWS Audit Manager peut assembler des trousses de preuves par cadre; il vaut la peine de l’évaluer une fois le processus manuel rodé et quand son coût (évaluation de ressources par évaluation) se justifie par la fréquence des audits.

Quand c’est la mauvaise approche

Si personne n’a réellement demandé — aucun questionnaire client, aucun audit au calendrier, aucun traitement de renseignements personnels déclenchant des obligations Loi 25 — bâtissez la base opérationnelle (journalisation, sauvegardes, hygiène des accès) pour elle-même et laissez la paperasse en forme de cadre attendre un vrai déclencheur; une machinerie de preuve sans consommateur n’est que du poids de processus. À l’inverse, si une échéance SOC 2 Type II arrive dans moins de trois mois et qu’aucun registre ne tourne, soyez honnête sur le séquencement : la période d’observation exige que les contrôles opèrent d’abord, et un consultant qui promet des preuves rétroactives promet quelque chose que le modèle ne permet pas. Et n’achetez pas d’outillage pour régler un problème de paperasse — un environnement sans revues d’accès n’a pas besoin d’une plateforme d’audit; il a besoin de quelqu’un pour faire la revue.

Erreurs courantes

  • Présenter les certifications d’AWS comme les vôtres. « AWS est certifié SOC 2 » répond à la question du centre de données seulement; la question suivante de l’auditeur porte sur vos contrôles, et les PDF d’Artifact ne les couvrent pas.
  • Des preuves avec des trous dans la chronologie. Un journal éteint trois semaines en mars devient une exception d’audit; alarmez sur StopLogging et sur les échecs de livraison.
  • Des revues qui ne laissent aucun artefact. Revues trimestrielles verbales, approbations en fil Slack, exportations non datées — si ce n’est pas daté et récupérable, ça n’existe pas au moment de l’audit.
  • Une carte des données qui omet les copies. Les instantanés partagés vers un autre compte, les réplicas dans une deuxième région et les exportations analytiques sont autant de réponses à « où vivent les données » prêtes à vous surprendre.

Garder le contrôle

  • Mettez au calendrier la revue d’accès trimestrielle et le test de restauration trimestriel; rangez les deux artefacts dans un seul emplacement contrôlé.
  • Alarmez sur la machinerie de preuve elle-même : CloudTrail arrêté, enregistreur Config éteint, échecs de tâches de sauvegarde.
  • Rafraîchissez la carte des données dès qu’un nouveau service ou une nouvelle région entre en production — attachez-la au processus de changement, pas à la mémoire.
  • Gardez les réglages de rétention (CloudTrail, Config, sauvegardes) explicitement plus longs que la période d’audit.
  • Retéléchargez les rapports AWS Artifact courants avant chaque cycle d’audit plutôt que de réutiliser ceux de l’an passé.

Les équipes qui opèrent ainsi cessent de craindre les questionnaires — les réponses sont des exportations de systèmes qui tournaient déjà. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.