Créer un bucket Amazon S3 sécurisé (AWS)

La presse et les publications techniques ont beaucoup parlé de la sécurité d’Amazon S3 sur Amazon Web Services (AWS), mais une grande partie de ces contenus simplifie à outrance le sujet et présente peu d’intérêt pratique. Amazon S3 est un service cloud incroyablement simple à utiliser, mais sécuriser correctement vos ressources S3 est tout sauf simple, comme trop d’organisations l’ont découvert.

Dans cet article (et au cours de nos deux sessions Cloud Security Masterclass consacrées à Amazon S3), je vous propose une approche pragmatique pour comprendre la sécurité S3. Vous pourrez réfléchir à la sécurisation de vos cas d’usage S3 et créer un bucket sécurisé adapté à vos besoins.

Si vous vous fiez uniquement à ce que vous lisez dans la presse, vous pourriez croire à tort que la seule mesure nécessaire pour sécuriser votre bucket S3 consiste à activer Block Public Access. Bien qu’il soit important de configurer correctement ce paramètre (et qu’AWS ait pris les mesures nécessaires pour vous avertir en cas de mauvaise configuration), vous pourriez aussi avoir un faux sentiment de sécurité si vous vous en tenez à cela.

Les différentes couches de sécurité d’Amazon S3

La sécurité d’Amazon S3 comporte plusieurs couches, dont certaines sont plus importantes que d’autres.

• Points de contrôle des accès (ACL)

• Politiques de gestion des identités et des accès (IAM)

• Politiques de bucket

• Block Public Access

• Points d’accès

• Chiffrement

Parmi ces éléments, les politiques IAM, le chiffrement et les politiques de bucket sont les plus importants à comprendre, du moins au départ. Mais avant d’entrer dans le détail de ces types de politiques, il est essentiel de disposer d’un modèle mental des politiques et de leur lien avec les actions et les ressources dans AWS. Nous passerons les ACL sous silence, car elles sont héritées et AWS recommande de ne pas les utiliser dans la plupart des cas.

Politiques IAM

Dans AWS, il existe des principaux, des actions et des ressources. Bien sûr, AWS comprend d’autres types d’entités, mais ce sont celles que vous devez connaître pour concevoir des buckets S3 sécurisés.

• Les principaux sont des acteurs, humains ou machines. Ce sont les entités qui effectuent des appels sur des actions et des ressources, à l’aide des identifiants nécessaires.

• Les actions sont les points de terminaison d’API utilisés pour effectuer des opérations dans le cloud. Chaque service AWS comprend un ensemble d’actions, comme ListBuckets ou GetObject dans S3.

• Les ressources sont les instances et objets spécifiques d’un service AWS, comme un bucket ou un objet S3, ou encore une instance EC2.

Pour qu’un principal puisse effectuer une action sur une ressource (par exemple, lister le contenu d’un bucket S3), des politiques doivent accorder les autorisations nécessaires à chaque étape. Tout refus, à n’importe quelle étape, empêchera l’action sur la ressource. AWS applique une politique par défaut à toutes les actions et ressources pour tous les principaux : Deny.

Illustrons cela.

Vous voyez la ligne verticale entre les principaux et les actions, et une autre entre les actions et les ressources ? Appelons-les nos « murs de refus ». Pour créer un bucket S3 sécurisé, nous devons ouvrir des brèches dans ces lignes uniquement pour les actions dont le principal a besoin, et uniquement sur les ressources appropriées.

Pour les principaux AWS, comme les utilisateurs et les ressources AWS (par exemple, une instance EC2 associée à un rôle IAM), nous pouvons utiliser IAM pour autoriser l’accès à des actions et à des ressources. Voici un exemple de politique IAM qui autorise un groupe d’actions sur tous les buckets S3 du compte :

1{
2    "Version": "2012-10-17",
3    "Statement": [
4        {
5            "Sid": "VisualEditor0",
6            "Effect": "Allow",
7            "Action": [
8                "s3:GetObjectAcl",
9                "s3:GetObject",
10                "s3:GetObjectTagging"
11            ],
12            "Resource": "*"
13        }
14    ]
15}

Notez que la politique comporte des sections dédiées aux actions et aux ressources, comme dans notre schéma. Voyez comment nous avons percé le mur de refus entre les principaux et les actions pour les trois opérations Get définies dans la politique, et que cette autorisation s’applique à tous les buckets S3 des ressources.

Dans cet exemple et dans bien d’autres, la section Resources contient « * », ce qui signifie que toutes les ressources associées à cette action sont concernées. C’est souvent une bonne approche : lors de l’évaluation de l’ensemble des politiques, nous pouvons utiliser les politiques de bucket et d’autres moyens pour limiter les ressources autorisées.

Lorsque vous décidez où préciser des éléments comme les noms des ressources, il est important d’éviter de multiplier les politiques IAM : leur suivi devient une source de coûts et de risques. Il est donc généralement déconseillé d’intégrer des identifiants de ressources spécifiques dans une politique IAM, car cela entraînerait la création de nombreuses copies de la politique. Nous utiliserons ensuite les politiques de bucket S3 pour limiter l’accès aux ressources au niveau du bucket. Ainsi, lorsqu’elle est attribuée à un utilisateur ou à un processus, cette politique n’autorise pas l’accès à tous les buckets S3.

Nous vous recommandons d’utiliser les politiques gérées par AWS chaque fois que cela est pertinent. Votre compte en comprend déjà plus de 700, et AWS les maintient pour vous. Même si vous n’en trouvez aucune qui corresponde parfaitement à vos besoins, elles constituent de bons exemples pour créer manuellement des politiques IAM de qualité.

Politiques de bucket

Nous avons maintenant une politique IAM qui autorise plusieurs actions Get sur tous les buckets S3 du compte. Mais nous souhaitons probablement limiter son champ d’application aux seuls buckets S3 nécessaires à l’application sur laquelle nous travaillons. Plusieurs approches sont possibles, mais nous recommandons de définir une politique de bucket pour chacun de vos buckets S3, comme dernière ligne de défense.

Les politiques de bucket sont des politiques AWS appliquées à chaque bucket. Elles permettent notamment de refuser les requêtes que les politiques IAM pourraient autoriser. Dans cet exemple, nous voulons que le bucket « foo » n’accepte que les actions initiées depuis deux réseaux VPC spécifiques. Voici une politique tirée directement du portail d’assistance AWS.

1{
2  "Version": "2012-10-17",
3  "Id": "VPCe and SourceIP",
4  "Statement": [{
5    "Sid": "VPCe and SourceIP",
6    "Effect": "Deny",
7    "Principal": "*",
8    "Action": "s3:*",
9    "Resource": [
10      "arn:aws:s3:::awsexamplebucket",
11      "arn:aws:s3:::awsexamplebucket/*"
12    ],
13    "Condition": {
14      "StringNotEquals": {
15        "aws:sourceVpce": [
16          "vpce-1111111",
17          "vpce-2222222"
18        ]
19      },
20      "NotIpAddress": {
21        "aws:SourceIp": [
22          "11.11.11.11/32",
23          "22.22.22.22/32"
24        ]
25      }
26    }
27  }]
28}

Nous commençons par appliquer un refus à tous les principaux pour toutes les actions S3, puis nous ajoutons une condition qui limite ce refus aux points de terminaison VPC qui ne correspondent pas à deux identifiants VpcE ni à deux blocs CIDR. Autrement dit, seuls les principaux passant par ces points de terminaison VPC et se trouvant dans ces blocs CIDR sont autorisés à effectuer des actions S3.

En réunissant ces éléments dans le schéma, en appliquant cette politique au bucket « foo » et en définissant d’autres politiques de bucket avec différents points de terminaison VPC et blocs CIDR, nous obtenons :

Ici, l’utilisateur bleu passe par un VPC doté du point de terminaison vpce-1111111, tandis que l’utilisateur rouge passe par le point de terminaison vpce-3333333. La politique du bucket foo refuse l’accès à l’utilisateur rouge, même si elle utilise la même politique IAM que l’utilisateur bleu, car elle passe par un point de terminaison VPC non autorisé.

Vous pouvez donc considérer toutes ces politiques comme faisant l’objet d’une évaluation unique, où tout refus entraîne le rejet de la requête. Vous pouvez ainsi choisir où placer les instructions Allow et Deny en fonction de votre cas d’usage et de votre architecture.

Block Public Access

Nous entendons souvent dire que les utilisateurs pensent être protégés contre les violations de données dans S3 en activant la fonctionnalité Block Public Access d’AWS. C’est une fonctionnalité très utile. Vous devriez l’utiliser lorsque cela est approprié, mais son effet sur le blocage des accès est loin d’être aussi vaste que vous pourriez le croire. Ne partez pas du principe que son activation suffit à vous protéger.

Dans la documentation d’AWS, on peut lire :

« Pour être considérée comme non publique, une politique de bucket doit accorder l’accès uniquement à des valeurs fixes (des valeurs sans caractère générique) d’un ou plusieurs des éléments suivants :

• Un ensemble de blocs CIDR (Classless Inter-Domain Routing), à l’aide de aws:SourceIp. … »

Le document contient beaucoup plus d’informations (et nous vous encourageons à le lire), mais ce seul extrait montre qu’une liste de blocs CIDR autorisant l’accès public n’est pas considérée comme « publique » par cette fonctionnalité. Les blocs CIDR peuvent représenter de vastes portions d’Internet. Votre bucket pourrait donc être considéré comme « non public » tout en étant exposé à des millions d’adresses IP, alors que vous pensez être en sécurité. Il est toujours recommandé d’utiliser la politique de bucket la plus restrictive possible pour chaque bucket S3.

À propos du chiffrement

Lorsque vous chiffrez un bucket S3, il est important d’utiliser des clés KMS ou des clés gérées par l’utilisateur. Ces méthodes obligent un pirate à accéder à des services ou à des données supplémentaires pour récupérer les informations déchiffrées de votre bucket S3. Si vous activez simplement le chiffrement côté serveur sous sa forme la plus élémentaire, vous ne bénéficiez que du chiffrement des données au repos dans le service S3. Tout principal disposant des autorisations GetObject recevra les objets sous forme déchiffrée.

Si la réglementation vous impose de chiffrer toutes les données au repos, cette mesure répondra à cette exigence. Mais, en pratique, elle n’a que peu ou pas d’incidence sur votre niveau de sécurité.

Et ce n’est pas tout…

AWS propose bien d’autres fonctionnalités et couches de sécurité S3 que celles abordées dans cet article. Certaines sont présentées dans notre série Cloud Security Masterclass consacrée à la sécurité S3. Si vous ne deviez retenir qu’une chose de cet article, ce serait qu’il faut vraiment comprendre les politiques AWS pour comprendre la sécurité S3, et qu’on ne peut pas maîtriser le sujet en se fiant simplement à des exemples prêts à l’emploi.

MISE À JOUR : J’ai oublié de préciser que vous devriez activer la journalisation des accès, la journalisation au niveau des objets et la gestion des versions pour vos buckets S3. La journalisation des accès et celle au niveau des objets vous permettront de voir ce qui s’est passé dans votre bucket. La gestion des versions vous permettra de revenir à des versions antérieures de vos objets si quelqu’un accède au bucket et modifie ou supprime des objets nécessaires.

Si vous souhaitez que nous abordions d’autres aspects de la sécurité S3, n’hésitez pas à nous contacter : nous les examinerons !