On a tout migré sur AWS — existe-t-il une checklist de sécurité qu'on peut appliquer nous-mêmes ?

Trois trucs ultra urgents à faire aujourd'hui : 1) Configurez les Billing Alerts (alertes de facturation) ; en cas de piratage pour miner de la crypto, vous serez au courant avant de vous retrouver avec une facture de plusieurs milliers de livres. 2) Vérifiez que les logs CloudTrail sont activés sur toutes les régions. 3) Assurez-vous que les sauvegardes automatiques de vos BDD sont bien en place.

Vu que vous hébergez des données financières de clients, au regard de la réglementation sur la protection des données au Royaume-Uni (UK GDPR), la responsabilité juridique incombe directement aux dirigeants. Même sans faire de pentest externe complet, je vous conseille vivement de documenter au moins ces vérifications avec date et captures d'écran à l'appui.

L'année dernière, après une migration similaire, on a fait un check et on a réalisé que le dev externe avait oublié une clé API avec les droits admin sur son PC perso. La clé est restée active pendant 4 mois sans surveillance. Par chance il n'y a pas eu de fuite, mais depuis, le premier lundi de chaque mois, on épluche systématiquement les clés IAM.

Allez dans la console IAM et téléchargez le 'Credential Report'. Ce simple fichier vous donne dans un seul tableau qui n'a pas activé la MFA, la date de dernière utilisation de chaque clé d'accès et l'ancienneté des mots de passe. En 10 minutes chrono, vous repérez les plus gros angles morts.

Si on bloque complètement l'accès public côté S3, est-ce que ça va impacter les factures PDF des clients ? Comme ils téléchargent leurs documents depuis l'appli, j'ai peur que ça leur génère des erreurs si on désactive ça.

La règle d'or pour S3, c'est que les fichiers ne doivent jamais être accessibles publiquement sur le web. Pour afficher un fichier au client votre appli doit générer en arrière-plan des liens signés temporaires (presigned URLs). De cette façon, le bucket reste totalement fermé au public mais votre appli fournit un lien de téléchargement sécurisé valable 5 minutes pour l'utilisateur authentifié.

Tout le monde conseille d'activer les outils de sécurité et les systèmes de logs, mais personne ne parle du coût. Si vous activez les services de sécurité et de monitoring à l'aveugle sur toutes les régions, vous allez payer plus cher de logs à la fin du mois que pour vos serveurs principaux. Activez-les uniquement sur les régions que vous utilisez vraiment.

Premier réflexe : ouvrez la page Trusted Advisor. Même la version gratuite remonte des alertes rouges sur les failles de base, les ports ouverts et la MFA du compte root. Rien qu'en nettoyant ces alertes, vous éliminez déjà une énorme partie du risque.

Résumé rapide pour les nouveaux : Si vous grondez les fausses alertes plus personne ne signalera rien.

Je suis aussi curieux de savoir si d'autres font autrement.

Chez nous, ça s'est passé comme ça. Tous ceux qui se pressent sur checklist sécurité AWS se heurtent au même obstacle.

Ne comptez pas sur une seule mesure de sécurité ; allez par couches. Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

Désolé, mais ce n'est pas vrai dans tous les cas. bref tous ceux qui se pressent sur checklist sécurité AWS se heurtent au même obstacle.

Je le note au cas où.

Merci beaucoup, cela m'a été très utile.

J'ai vécu exactement la même chose il y a deux ans. Les environnements de test oubliés sont plus souvent des portes d'entrée que les systèmes de production.

Si vous avez des questions, écrivez-moi, je répondrai au mieux.

Laissez-moi détailler l'aspect technique. Ne comptez pas sur une seule mesure de sécurité ; allez par couches.

C'est une bonne idée d'avoir ouvert ce sujet. Ce qui nous faisait perdre le plus de temps, c'était l'absence de clarté sur qui prenait les décisions.

Les décisions hâtives finissent par être corrigées six mois plus tard. C'est mon avis, je ne l'écris pas comme une vérité absolue.

Je suis intéressé.

Chez moi c'est l'inverse qui s'est passé c'est pourquoi j'écris. du coup les solutions qui fonctionnent à petite échelle s'effondrent en grandissant j'ai appris cela trop tard.

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

Le point le plus souvent négligé concernant checklist sécurité AWS est : Ce que tout le monde fait ne signifie pas que c'est la bonne chose.

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