Fondamentaux et meilleures pratiques en matière de sécurité du cloud AWS

Amazon Web Services, ou AWS, est depuis longtemps la plateforme de cloud public la plus populaire. Mais elle s’est aussi considérablement développée au cours de la dernière décennie en déployant toute une série de nouveaux services (comme les services gérés de containers et de Kubernetes, pour ne citer que quelques exemples), qui ont rendu la sécurité du cloud AWS plus complexe.

Dans le même temps, l’adoption généralisée du cloud hybride et des architectures multiclouds signifie que les entreprises qui utilisent AWS peuvent être confrontées à de nouveaux défis en matière de sécurité du cloud qui n’existaient pas lorsqu’elles exécutaient tout dans un environnement AWS cloud unique.

En conséquence de tout ce qui précède, les pratiques de sécurité AWS qui fonctionnaient dans le passé ne sont plus nécessairement suffisantes à elles seules pour répondre à toutes les exigences de sécurité AWS. Compte tenu de ce défi, cet article présente les principes fondamentaux de la sécurité moderne d’AWS et conseille les meilleures pratiques à suivre pour sécuriser les workloads qui s’exécutent sur AWS, notamment les applications basées sur les containers et Kubernetes.

Responsabilité partagée sur AWS

La première étape pour orchestrer la sécurité d’AWS consiste à comprendre le modèle AWS de responsabilité partagée. Comme d’autres grands clouds publics, AWS utilise un concept de sécurité partagé pour distinguer les risques de sécurité qu’AWS gère de ceux qu’il attend des clients.

La définition officielle du modèle de responsabilité partagée d’AWS est moins détaillée que celle des autres grands clouds publics. Elle se résume au concept selon lequel « AWS est responsable de la protection de l’infrastructure qui exécute tous les services proposés dans le cloud AWS », tandis que les clients sécurisent tout le reste.

Cela dit, dans la pratique, la responsabilité partagée d’AWS est pratiquement identique aux modèles adoptés par d’autres clouds publics, même si AWS n’en précise pas autant les nuances. En gros, les clients doivent simplement se rappeler qu’AWS sécurise toute l’infrastructure cloud à laquelle les clients ne peuvent pas accéder ou configurer directement, et que les clients sécurisent tout le reste. C’est le cas des services gérés par AWS, comme Elastic Kubernetes Service, ou EKS, où AWS sécurise l’infrastructure du cluster mais où les clients doivent sécuriser l’environnement Kubernetes et les applications qu’ils y déploient.

Comment sécuriser les environnements AWS ?

Après avoir compris le modèle de responsabilité partagée d’AWS, les étapes suivantes de la planification de la sécurité AWS consistent à identifier et à mettre en œuvre des outils et des pratiques qui sécurisent les aspects de votre environnement AWS dont vous êtes responsable.

Meilleures pratiques de sécurité d’AWS de base

Dans la plupart des cas, les meilleures pratiques fondamentales pour la sécurité du cloud AWS ne sont pas différentes des pratiques de sécurité que vous appliqueriez dans tout type d’environnement cloud. En voici une sélection :

Utilisation de cloud IAM : En utilisant le framework de Gestion des identités et des accès AWS (IAM), les clients doivent configurer des contrôles d’accès granulaires qui limitent au minimum nécessaire les privilèges d’accès pour chaque utilisateur et service fonctionnant dans un environnement AWS. Les clients peuvent également utiliser les outils d’audit IAM pour détecter les mauvaises configurations des politiques IAM qui créent une faible posture de sécurité du cloud.
Utilisation des VPC cloud : Les clients peuvent configurer des environnements isolés pour leurs workloads en utilisant Amazon Virtual Private Cloud, ou VPC. En créant un VPC, les clients isolent les workloads les uns des autres (et, selon la configuration du VPC, de l’Internet public) au niveau du réseau. Bien que vous ne soyez pas obligé d’utiliser un VPC si vous utilisez AWS, les VPC sont un outil utile pour réduire les risques de sécurité.
Gestion judicieuse de vos comptes cloud : Il n’y a pas de limite au nombre de ressources cloud que vous pouvez déployer à l’aide d’un seul compte AWS. Toutefois, il est préférable de créer des comptes distincts pour des utilisateurs ou des unités commerciales distincts afin d’isoler les workloads non liés au niveau du compte. L’inconvénient de l’utilisation de plusieurs comptes est qu’ils sont plus difficiles à gérer, mais des services comme AWS Landing Zone peuvent aider à relever ce défi.
Chiffrement des données du cloud : En plus de sécuriser les données du cloud stockées dans des services comme AWS S3 à l’aide de contrôles d’accès, les clients doivent activer le chiffrement par défaut côté serveur. Ils sont également invités à appliquer le chiffrement côté client pour protéger les données du cloud en transit.
Connaissance de l’emplacement où se trouvent les données sensibles : Dans les environnements cloud à grande échelle, il est facile de perdre la trace de l’endroit où sont stockées les données sensibles (telles que les données contenant des informations personnellement identifiables). Le balisage des ressources AWS peut contribuer à résoudre ce risque en aidant les équipes à baliser les workloads sensibles. Amazon fournit également un service automatisé, appelé Macie, qui peut identifier les informations sensibles stockées sur le cloud AWS.

Considérations particulières en matière de sécurité pour AWS

Au-delà des bonnes pratiques de sécurité standard du cloud décrites ci-dessus, il existe quelques points de sécurité particuliers que les équipes peuvent vouloir prendre en compte lorsqu’elles utilisent AWS :

Sécurisation des workloads cloud existants : AWS étant le plus ancien des grands clouds publics, certaines entreprises l’utilisent depuis plus de dix ans. Elles peuvent exécuter des workloads cloud « anciens » (comme des containers déployés sur ECS, le service interne d’orchestration de containers qu’AWS a lancé avant d’ajouter des options de containers gérés basés sur Kubernetes) qui ne sont pas nécessairement conformes aux pratiques de sécurité modernes d’AWS. Si votre équipe fonctionne sur AWS depuis plusieurs années, il est utile d’évaluer les différents types de services AWS que vous utilisez et de vérifier si les configurations que vous avez appliquées lors de la mise en place initiale de ces ressources sont toujours conformes aux meilleures pratiques actuelles en matière de sécurité du cloud.
Utilisation des outils de sécurité AWS : AWS offre un plus grand choix d’outils de sécurité natifs que la plupart des autres grands fournisseurs de cloud publics. En plus des outils de surveillance de la sécurité standard comme GuardDuty, AWS fournit sa propre solution CSPM ainsi que Trusted Advisor, un outil qui recommande les meilleures pratiques lors de la configuration des workloads. Ainsi, AWS dispose d’un ensemble particulièrement vaste et complexe d’outils de sécurité natifs, que les équipes devraient envisager d’utiliser dans le cadre de leur stratégie de sécurité AWS. Dans le même temps, il est toutefois important de comprendre les limites de ces outils, en particulier le fait qu’ils ne prennent en charge que les environnements AWS (ce qui signifie qu’ils ne fonctionnent pas correctement dans les architectures multicloud et de cloud hybride). Il s’agit également, pour la plupart, de solutions de sécurité génériques qui ne sont généralement pas conçues pour répondre aux exigences de sécurité nuancées de types d’environnements très spécifiques, comme Kubernetes.
Sécurité du cloud hybride AWS : AWS fournit un framework de cloud hybride, appelé Outposts, qui permet aux clients d’exécuter les services AWS sur des serveurs qui existent on-premises ou dans une installation de colocation privée. Les serveurs eux-mêmes sont fournis par AWS ; cependant, malgré ce fait, les clients assument la responsabilité de la plupart des exigences de sécurité de l’infrastructure qui incomberaient autrement à AWS dans le contexte d’une infrastructure appartenant à AWS. Si vous utilisez Outposts pour créer un cloud hybride, il est important de vous informer sur l’architecture de sécurité unique utilisée par AWS pour Outposts.

Sécuriser les containers AWS

Comme les autres grands clouds publics, AWS offre plusieurs façons d’exécuter des applications en containers. Les principaux services de containers AWS sont les suivants :

Elastic Container Service, ou ECS, un service de containers géré qui repose sur un orchestrateur développé par Amazon lui-même.
Elastic Kubernetes Service, ou EKS, un service de containers géré basé sur Kubernetes.
Fargate, un service qui simplifie le déploiement de containers via ECS ou EKS, avec pour contrepartie que les utilisateurs ont moins de contrôle sur l’infrastructure et la configuration.
Lambda, un service de fonctions serverless qui peut exécuter des applications empaquetées comme des images de containers.

Vous pouvez également déployer des containers directement sur des machines virtuelles AWS EC2 si vous êtes prêt à mettre en place et à gérer vous-même l’infrastructure et les couches d’exécution et d’orchestration des containers.

Selon le ou les services que vous utilisez pour déployer des containers sur AWS, votre approche de la sécurisation de vos containers variera. Toutefois, quel que soit le service que vous utilisez, quelques bonnes pratiques de base en matière de sécurité des containers AWS s’appliquent :

Recherchez les vulnérabilités dans les images de containers. AWS n’analyse pas les images pour vous.
Dans la mesure du possible, analysez toutes les configurations associées à votre environnement – comme le déploiement de Kubernetes et les fichiers RBAC, ainsi que les politiques AWS IAM – pour détecter les éventuelles anomalies au niveau de la posture de sécurité du cloud.
Utilisez les outils disponibles dans les frameworks d’orchestration de containers pour sécuriser votre environnement et détecter les violations. Dans les environnements AWS basés sur Kubernetes, cela signifie utiliser des outils tels que les journaux d’audit de Kubernetes, RBAC, et les contextes de sécurité.

Il est également important de comprendre comment le modèle de responsabilité partagée d’AWS s’applique à tous les services de containers que vous utilisez. Ce sujet est assez nuancé et complexe, d’autant plus qu’AWS propose plusieurs façons d’utiliser des services comme EKS (vous pouvez les gérer via Fargate ou directement via EKS), et chaque approche a des implications différentes quant aux responsabilités en matière de sécurité qui incombent au client. La documentation d’AWS explique bien ces détails, mais n’oubliez pas de vous renseigner sur les politiques de sécurité d’AWS spécifiques au service de containers que vous choisissez.

Conclusion

Tant qu’AWS restera la plateforme de cloud dominante en termes de parts de marché, la sécurisation des workloads AWS restera une préoccupation majeure pour les organisations du monde entier. Et comme AWS continue à déployer de nouveaux types de services et à faciliter leur intégration dans des architectures hybrides et multiclouds, la sécurité d’AWS ne fera que se complexifier.

La bonne nouvelle est que, tant que vous effectuez vos recherches pour comprendre quels défis de sécurité s’appliquent aux services et configurations spécifiques du cloud AWS que vous adoptez, la gestion de la sécurité AWS n’est pas si difficile. Les informations et les outils dont vous avez besoin existent ; il s’agit simplement de trouver les bonnes ressources.