L'auditeur réclame la politique SecurityAudit sur AWS, quel est le niveau de risque de cet accès ?

La politique SecurityAudit n'autorise pas le téléchargement des objets stockés, ils ne peuvent donc pas aspirer les données clients. En revanche, les appels pour lire la configuration des fonctions ou les données d'initialisation des serveurs sont autorisés. Si vous avez laissé des mots de passe en clair dans votre code ou vos scripts de bootstrap d'instances virtuelles, l'auditeur les verra. Nettoyez ces parties en priorité.

Rendez la condition External ID obligatoire dès la création du rôle. Ajoutez aussi une restriction par IP source dans la relation de confiance pour que le cabinet d'audit ne puisse se connecter que depuis les IP de ses bureaux ou de son VPN. Deux semaines plus tard, vous supprimez le rôle en un clic et c'est réglé.

Le cabinet d'audit va lancer un outil d'analyse automatisé ou leurs ingénieurs vont naviguer manuellement depuis la console ? S'ils branchent des outils cloud automatisés, est-ce que vous leur avez demandé par écrit le numéro de compte tiers et leur politique d'External ID avant de configurer la relation de confiance du rôle ?

De notre côté, on a créé un rôle similaire pour un audit de conformité. L'audit a duré 12 jours. Dès que c'était fini, on a supprimé le rôle IAM et passé au crible les logs de session de l'auditeur : ils avaient fait environ 14 200 appels API en lecture seule au total. Aucune tentative de téléchargement de données à signaler.

crée surtout pas d'utilisateur iam avec une access key puis après ces clés restent oubliées dans un coin. créez juste un rôle, mettez un external id et supprimez le rôle direct quand ils ont fini.

Les cabinets d'audit veulent toujours la solution de facilité, mais vous n'êtes pas obligés de leur donner un rôle direct sur le compte de prod. La plupart des boîtes extraient elles-mêmes les rapports de config et les exports sécu via des outils CLI et les transmettent sous forme de fichiers. Pourquoi leur ouvrir tout le compte en direct ?

Dans l'accord de confidentialité signé en amont de l'audit, il convient d'engager expressément le prestataire sur le traitement des données de configuration, le délai de destruction des logs conservés en cache par leurs outils et l'interdiction de tout partage avec des tiers.

Pour résumer : SecurityAudit accède aux configurations et non aux données, c'est donc une demande standard. Cela dit, passez bien par un rôle en configurant un External ID, une restriction IP et une date d'expiration, puis supprimez le rôle et vérifiez les logs système dès le jour de la clôture de l'audit.

Vous avez raison. Quand on essaie de tout changer en même temps rien ne prend.

J'espère que cela vous sera utile.

Exactement et ce n'est pas si connu que ça. La plupart des incidents ne viennent pas d'une faille, mais d'un mot de passe divulgué.

Chez nous aussi.

Il y a un point que je ne comprends pas. Plus il est difficile de revenir sur une décision, plus il faut la prendre lentement.

Je le note au cas où.

il faut y aller étape par étape mais lors de la prise de décision écrivez aussi le pire scénario, pas seulement le meilleur.

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

Je suis d'accord. Aucun processus sans suivi ne s'améliore, car vous ne savez pas quoi corriger.

Voilà, désolé si je me suis étendu.

Mes doutes sont levés, merci. N'hésitez pas à demander, celui qui ne demande pas paie toujours plus cher.

exact. genre si vous grondez les faausses alertes plus personne ne signalera rien.

à votre place, j'irais par cette voie.

Je suis passé par là, laissez-moi vous raconter. Les gens défendent l'habitude, pas le processus. La résistance vient de là.

j'écris cela pour éviter que vous ne fassiez la même erreur mais le temps que vous mettez à détecter un problème détermine directement son coût.

à vottre place j'irais par cette voie.