Comprendre la sécurité et la conformité d’Amazon S3 sur AWS

Si votre organisation utilise Amazon Web Services (AWS) pour le cloud computing, il y a de fortes chances qu’elle utilise beaucoup Amazon S3, ou Amazon Simple Storage Service. Ce service de stockage d’objets a été l’un des premiers services cloud proposés par AWS (en 2006, déjà !). Sa simplicité d’utilisation, sa fiabilité et son évolutivité ont rapidement séduit un très grand nombre d’utilisateurs.

Toutefois, une mauvaise configuration de vos ressources S3 peut entraîner d’importants incidents de sécurité et de conformité. Les fuites de données très médiatisées résultant d’erreurs de configuration de S3 continuent de faire la une, et il faut s’attendre à en voir d’autres. Une simple erreur dans la politique d’accès ou le paramètre de chiffrement d’un « bucket » S3 peut suffire pour que des acteurs malveillants accèdent à des données sensibles.

Quelle que soit la manière dont ces incidents sont présentés dans les titres, dans tous les cas, la faute revient au client du cloud, et non à AWS. AWS respecte scrupuleusement ses obligations dans le cadre du modèle de responsabilité partagée pour la sécurité du cloud, mais ne peut pas vous empêcher de vous tirer une balle dans le pied en configurant mal S3 et de faire ainsi la une des journaux.

La conformité régit probablement votre utilisation d’Amazon S3

Si votre organisation est soumise à un cadre de conformité tel que HIPAA, PCI, SOC 2, GDPR ou NIST 800-53, sachez que chacun d’eux comprend des contrôles régissant l’utilisation et la configuration de S3 (ainsi que de nombreux autres services AWS que votre organisation utilise probablement). Si aucun de ces cadres de conformité ne s’applique à votre organisation ou à vos charges de travail, envisagez sérieusement d’adopter le référentiel AWS CIS Benchmark pour vous guider dans l’utilisation sécurisée d’AWS.

Gardez le contrôle des accès à vos buckets Amazon S3

De nombreuses fuites de données liées à S3 sont dues à des politiques d’accès mal configurées. Lorsqu’un nouveau bucket S3 est créé, sa politique d’accès est définie par défaut sur « privé ». Mais ce paramètre peut changer, et c’est souvent le cas, au cours de la vie de la ressource. Les environnements cloud évoluent au fil du temps, à mesure que les développeurs mettent à jour les applications et l’infrastructure et ajoutent de nouveaux services. Lors de ces mises à jour, les politiques d’accès peuvent être affaiblies ou désactivées involontairement.

Effectuez un audit de vos ressources S3 et de leurs politiques d’accès pour vérifier qu’elles sont configurées de manière sécurisée, et suivez toute modification de ces configurations avec CloudTrail. Pour les buckets S3 contenant des données sensibles, envisagez une solution telle que Fugue, qui détecte (et peut corriger) tout « écart » par rapport à votre configuration de référence sécurisée, sans code ni scripts supplémentaires.

AWS CIS Benchmark est un bon exemple de cadre de conformité qui régit la configuration et l’utilisation de S3. La règle CIS 2.6 exige l’activation de la journalisation des accès aux buckets. La règle 3.8 exige l’activation d’un filtre de métrique de journalisation et d’une alerte pour toute modification des politiques de bucket. Enfin, vous devez vous assurer que vos buckets S3 contenant des données sensibles ne sont pas accessibles à tous. Créez plutôt une politique AWS IAM qui autorise uniquement les utilisateurs habilités à accéder au bucket.

Chiffrez vos données Amazon S3 pour les protéger

Il est indispensable de maintenir des politiques d’accès sécurisées pour vos ressources Amazon S3, mais vous devez également veiller à ce que le chiffrement soit toujours activé afin d’empêcher toute personne non autorisée de lire les données. Là encore, vous devrez auditer vos ressources S3 pour vérifier que le chiffrement est activé et utiliser la journalisation pour suivre toute modification apportée à ces ressources, notamment les cas où le chiffrement est désactivé.

Votre cadre de conformité s’appliquera probablement aussi dans ce cas. On peut citer, par exemple, la norme NIST 800-53 SC-13 : Protection cryptographique, qui exige que l’organisation mette en œuvre le chiffrement lorsque cela est pertinent, et SOC 2 CC 6.1, qui exige que le chiffrement complète les autres mesures de protection des données au repos.

Alors, la sécurité et la conformité AWS sont sous votre responsabilité !

Chaque organisation est différente, mais la sécurité des données critiques sur AWS relève généralement de la responsabilité d’un ingénieur en sécurité cloud, d’un ingénieur DevOps, d’un analyste de conformité ou d’un architecte cloud. Il arrive que certaines de ces personnes, voire toutes, se partagent la responsabilité de la sécurité du cloud. Une collaboration efficace est alors indispensable (on parle souvent de « DevSecOps »).

Quel que soit votre rôle ou votre titre, si vous êtes responsable de la sécurité et de la conformité de votre environnement AWS, vous devez notamment veiller à ce que les ressources S3 critiques soient correctement configurées et le restent tout au long de leur cycle de vie.

Mission n° 1 : certifier la conformité de vos configurations S3 aux politiques

Si ce n’est pas déjà fait, vous devez certifier que la configuration des ressources S3 existantes dans votre environnement AWS respecte les politiques de conformité et de sécurité applicables. Cela implique généralement un audit visant à déterminer la configuration de vos ressources S3, effectué manuellement dans la console AWS ou à l’aide d’un outil d’audit.

Vous devez auditer régulièrement et fréquemment tous vos environnements AWS. Pour les ressources critiques, effectuez des audits continus avec un outil qui analyse les ressources, valide leur configuration par rapport aux politiques et signale les manquements à la conformité ainsi que votre niveau global de sécurité. Assurez-vous de pouvoir détecter tout « écart » par rapport à la configuration S3 initiale afin de déterminer si la modification enfreint une politique.

Vous devrez également travailler en étroite collaboration avec vos équipes applicatives et DevOps pour certifier que leurs activités (déploiement de nouveaux environnements, mise à jour des environnements existants, par exemple) respectent les politiques en vigueur. Comme ce processus manuel est généralement long et source d’erreurs, votre équipe doit chercher des moyens de « déplacer la sécurité à gauche » en intégrant les contrôles de politiques plus tôt dans le cycle de vie du développement logiciel (SLDC), lorsque les corrections sont plus simples, plus rapides et moins coûteuses.

Mission n° 2 : identifier et corriger les erreurs de configuration d’Amazon S3

Très bien, vous avez certifié que vos ressources AWS S3 respectent les politiques et sont configurées de manière sécurisée. Bravo ! Reste maintenant le plus difficile : veiller à ce qu’elles le restent.

La dérive de configuration des ressources d’infrastructure cloud est un problème omniprésent et souvent risqué. Les configurations des buckets S3 peuvent être modifiées depuis la console AWS et via une interface de programmation d’application (API), notamment à l’aide de divers outils d’automatisation. Vous constaterez probablement que les configurations S3, ainsi que celles de nombreux autres services AWS, changent fréquemment, ce qui peut parfois les rendre non conformes et créer des failles de sécurité.

Vous avez besoin d’un outil qui analyse votre environnement AWS et vous alerte en cas de non-conformité dans la configuration de S3. Vous devez pouvoir ignorer les alertes concernant les buckets S3 destinés à être accessibles au public (comme ceux qui hébergent des sites web statiques), tout en signalant les erreurs de configuration des buckets qui doivent rester privés et chiffrés. Les alertes doivent fournir suffisamment d’informations sur l’erreur de configuration pour faciliter sa correction manuelle.

Pour les buckets S3 critiques qui contiennent des données sensibles, vous devez absolument abandonner les processus manuels et corriger automatiquement les erreurs de configuration dès qu’elles surviennent. Aucun processus manuel ne peut ramener le délai moyen de résolution (MTTR) à un niveau suffisamment sûr pour les erreurs de configuration critiques, car les menaces qui cherchent à exploiter les vulnérabilités de l’infrastructure cloud, comme les buckets S3 mal configurés, sont elles-mêmes automatisées. Avec le temps, vous constaterez que la correction automatisée vous fait gagner beaucoup de temps et que vous l’utiliserez pour davantage de ressources cloud.

Correction automatique des erreurs de configuration AWS

Pour corriger efficacement et complètement les erreurs de configuration AWS de manière automatisée, vous pouvez établir une configuration de référence qui permet à votre infrastructure AWS critique de s’auto-réparer. Cette approche consiste à définir une configuration de référence connue comme étant fiable et conforme aux politiques. Une fois cette configuration établie, détectez et examinez tout écart par rapport à celle-ci. Pour les ressources critiques, vous devez automatiquement rétablir la configuration de référence en cas d’écart. Cette méthode évite d’avoir à prévoir tous les problèmes possibles et à créer des listes de blocage. Elle permet également de déplacer la sécurité et la conformité vers les premières étapes du développement.

Fugue permet de créer une infrastructure cloud auto-réparatrice. Regardez notre webinaire pour en savoir plus.

Mission n° 3 : générer des rapports sur les erreurs de configuration d’AWS S3

En plus d’exiger des rapports périodiques sur la conformité et la sécurité, la plupart des organisations demandent un rapport pour chaque erreur de configuration touchant une ressource critique telle qu’Amazon S3. Ces rapports doivent généralement inclure les informations suivantes :

• Quelle ressource a été affectée (et dans quel environnement) ?

• Quelle configuration a changé ?

• Quand l’erreur de configuration s’est-elle produite ?

• Qui est à l’origine de l’erreur de configuration ?

• Quelle politique, le cas échéant, cette erreur de configuration a-t-elle enfreinte ?

• Quand l’erreur de configuration a-t-elle été détectée ?

• Quand l’erreur de configuration a-t-elle été corrigée (et vérifiée) ?

• Qui a corrigé l’erreur de configuration (ou comment a-t-elle été corrigée) ?

• Quelles mesures sont prises pour éviter que de telles erreurs de configuration ne se reproduisent ?

Vous devrez récupérer de nombreuses données de journalisation pour rédiger ce type de rapport ; l’automatisation peut donc aussi vous aider. Quant à la dernière exigence, seule la correction automatisée permet d’éviter que ces erreurs de configuration ne se reproduisent.

Envisagez de mesurer votre délai moyen de résolution (MTTR) des erreurs de configuration affectant les ressources cloud critiques afin d’évaluer la résilience de vos mesures de sécurité cloud. Un MTTR de plusieurs heures ou jours doit être considéré comme présentant un risque inacceptable, compte tenu des menaces automatisées qui cherchent à exploiter de telles erreurs de configuration.

Encore une chose…

Si vous gérez une infrastructure cloud à grande échelle et que la sécurité et la conformité de vos environnements vous préoccupent, Fugue peut vous aider. Avec Fugue, vous pouvez :

1. Valider la conformité de vos environnements cloud à l’aide de différents référentiels de politiques, comme HIPAA, PCI, SOC 2, NIST 800-53, ISO 27001 et GDPR.

2. Obtenir une visibilité complète sur vos environnements cloud et leurs configurations grâce à la définition d’une configuration de référence pour l’infrastructure cloud et à la détection des écarts.

3. Protéger votre infrastructure cloud contre les erreurs de configuration, les incidents de sécurité et les manquements à la conformité grâce à une infrastructure auto-réparatrice.

4. Déplacer la sécurité et la conformité de l’infrastructure cloud vers les premières étapes du développement grâce à l’intégration CI/CD, pour aider vos développeurs à travailler rapidement et en toute sécurité.

5. Bénéficier d’une visibilité et de rapports continus sur la conformité dans l’ensemble de votre infrastructure cloud d’entreprise.