L'auditeur réclame une politique d'audit de sécurité AWS — que doit-elle contenir concrètement ?

Du point de vue d'un auditeur, c'est très carré : la politique formalise ce qui « doit être fait », la procédure détaille « comment le faire » et la preuve atteste que « c'est fait ». On vous demande ici le premier volet. Indiquez par exemple « l'entreprise impose l'authentification MFA matérielle ou logicielle pour tout compte AWS », puis joignez en preuve l'export de l'état MFA tiré de votre console IAM.

Les auditeurs d'entreprise recherchent en priorité ces quatre points dans le document : 1) La protection des logs CloudTrail contre la suppression. 2) Qui accède à l'environnement de production et via quel processus de validation. 3) Le délai maximum d'application des correctifs de sécurité. 4) La clause garantissant que les accès AWS des anciens employés sont révoqués le jour même de leur départ.

On a passé un audit similaire le trimestre dernier pour un client dans la finance avec un budget de 80.000 $. On a rédigé une politique simple de 6 pages. Après l'avoir lue, l'auditeur n'a demandé des preuves en direct que sur deux points : la date de dernière connexion du compte root et les alertes de connexions non autorisées configurées sur CloudWatch. Si les deux sont en règle, le dossier est généralement validé en 48 heures.

Ne vous embêtez pas à tout rédiger de zéro. Cherchez « CIS AWS Foundations Benchmark » sur le net. Récupérez les points de contrôle de ce guide dans un fichier Word et adaptez-les aux règles internes de votre boîte. Mettez le nom de l'entreprise et un numéro de version en en-tête, puis signez le tout en PDF.

Le pire piège ici, c'est de pomper un modèle générique de 30 pages trouvé sur internet et de l'envoyer tel quel. Si vous écrivez dans le document qu'un scan de vulnérabilités est fait chaque semaine et que ce n'est pas le cas, tout votre process de vente tombe à l'eau dès que l'auditeur demande une preuve. Limitez-vous à ce que vous appliquez réellement : peu importe si c'est court, tant que c'est vrai.

Lors de notre premier audit d'entreprise, on avait écrit dans la politique : « les clés d'accès sont renouvelées tous les 90 jours ». L'auditeur est arrivé, a vu qu'une clé API tournait depuis 410 jours sur le système, et a directement collé une non-conformité dans son rapport. Le contrat a pris un mois de retard. Il faut absolument que chaque phrase écrite corresponde à ce qui est configuré dans la console.

Il s'agit uniquement d'un document Word/PDF et non de code technique ; vous y formalisez par écrit vos règles d'infrastructure et votre rigueur en matière de journalisation.

Le document à élaborer doit impérativement être conforme aux processus de gestion de la sécurité de l'information de l'entreprise. La présence de la date d'entrée en vigueur, du numéro de révision ainsi que de la signature d'approbation de la direction générale constitue une exigence stricte au regard des normes d'audit.

Je vais résumer ce qui a été dit jusqu'ici. N'hésitez pas à demander, celui qui ne demande pas paie toujours plus cher.

Tout point non écrit est un point que les deux parties se rappelleront différemment plus tard. Bon courage.

Vous avez raison. Tout point non écrit est un point que les deux parties se rappelleront différemment plus tard.

C'est mon avis, je ne l'écris pas comme une vérité absolue.

Merci beaucoup, je teste dès aujourd'hui.

Merci d'avoir écrit cela, c'est exactement ça. Si vous grondez les fausses alertes, plus personne ne signalera rien.

À votre place, j'irais par cette voie.

Je vais essayer.

exact.

C'est exactement ça. Le temps que vous mettez à détecter un problème détermine directement son coût.

Je suis passé par là, laissez-moi vous raconter. Si c'est une première, commencez petit, l'échelle viendra plus tard.

J'espère que cela vous sera utile.

exactement et ce n'est pas si connu que ça.. puis franchement la réponse varie beaucoup selon le secteur, il n'y a pas de règle générale.

bien sûr, cela change si votre situation est différente.