Introduction à la sécurité AWS

Sécurité AWS pour les développeurs

Rahul Singh

Technical Product Manager

Prérequis du cours

Notions de base en sécurité AWS
Compréhension des concepts du cloud
Concepts de sécurité et de gestion des coûts AWS

Carte de titre du cours AWS Security and Cost Management Concepts

Objectifs du cours

Identité : qui appelle
Autorisation : ce qu'il peut atteindre
Secrets et chiffrement : protection des données
Preuves : ce qui s'est passé, après coup

Quatre bandes numérotées empilées le long d'une colonne, une par domaine couvert. Bande 1 : Identité, Chapitre 1. Bande 2 : Autorisation, Chapitre 2. Bande 3 : Secrets et chiffrement, Chapitres 2 et 3. Bande 4 : Preuves, Chapitre 3. Une flèche orange à gauche, « cette vidéo », pointe la bande 1.

Votre code part via un pipeline

Un flux de gauche à droite. Étape 1 : un encadré « Votre pipeline » avec trois étapes : Build, Test, Deploy. Étape 2 : une flèche « git push » depuis un encadré « Vous ». Étape 3 : un badge orange sous le pipeline, « sa propre identité ». Une flèche va du pipeline vers un encadré « AWS ».

D'abord, un terme de vocabulaire

Un pipeline automatise le build, les tests et le déploiement de votre code
Il s'exécute à votre push, sans humain dans la boucle

Un déploiement qui échoue pour la mauvaise raison

Lors d'un changement de code, quelles autorisations sont réellement vérifiées ?

Vous poussez une modification

Étape 1 d'un flux vertical. Un encadré « Vous », poussant une modification de code.

Un déploiement qui échoue pour la mauvaise raison

Lors d'un changement de code, quelles autorisations sont réellement vérifiées ?

Vous poussez une modification
Votre pipeline s'exécute

Un flux vertical. Étape 1 : Vous, poussant une modification. Une flèche descend vers l'étape 2 : votre pipeline, qui lance le déploiement.

Un déploiement qui échoue pour la mauvaise raison

Lors d'un changement de code, quelles autorisations sont réellement vérifiées ?

Vous poussez une modification
Votre pipeline s'exécute
Le déploiement s'arrête : AccessDenied

Premier réflexe : « Vérifier mes propres autorisations. »

Un flux vertical. Étape 1 : Vous, poussant une modification. Étape 2 : votre pipeline lance le déploiement. Étape 3 : AWS évalue la requête et renvoie AccessDenied.

Ce qui s'est vraiment passé

Étape 1 d'un flux de gauche à droite. Un encadré « Vous », dont l'implication s'arrête ici.

Vous poussez. Votre implication s'arrête ici

Ce qui s'est vraiment passé

Un flux de gauche à droite. Un encadré « Vous », flèche vers « Votre pipeline ». Un badge « deploy-role » sous le pipeline.

Vous poussez. Votre implication s'arrête ici
Le pipeline déploie, en tant que rôle créé par votre équipe

Ce qui s'est vraiment passé

Un flux de gauche à droite de Vous, vers Votre pipeline, vers AWS. Un badge « deploy-role » sous le pipeline, et une flèche en pointillés « vérifications » part d'AWS vers ce badge plutôt que vers Vous.

Vous poussez. Votre implication s'arrête ici
Le pipeline déploie, en tant que rôle créé par votre équipe
AWS évalue ce rôle

Acteur et principal

Acteur

Celui qui déclenche le travail.

Ici : vous.

Icône de personnage représentant l'acteur qui déclenche le travail.

Acteur et principal

Acteur

Celui qui déclenche le travail.

Ici : vous.

Principal

L'identité qu'AWS évalue à la réception de la requête.

Ici : le rôle du pipeline.

Icône de personnage représentant l'acteur qui déclenche le travail.

Icône représentant le principal.

Acteur et principal

Acteur

Celui qui déclenche le travail.

Ici : vous.

Principal

L'identité qu'AWS évalue à la réception de la requête.

Ici : le rôle du pipeline.

Lambda : rôle d'exécution. ECS : rôle de tâche. Nouveau nom, même principal
Exception : une clé de longue durée dans votre terminal ; l'utilisateur IAM est alors le principal

Icône de personnage représentant l'acteur qui déclenche le travail.

Icône montrant qu'AWS vérifie le principal et non l'acteur.

Même déploiement, deux rôles

Rôle A (La forme de AdministratorAccess)

Lire chaque bucket
Utiliser chaque clé
Mettre à jour chaque fonction

Rôle B

Lire un bucket
Utiliser une clé
Mettre à jour une fonction

Préfixe : un chemin type dossier dans un bucket

Image montrant un rôle tout-accès avec six politiques.

Image montrant un rôle à accès restreint avec une seule politique.

Rayon d'impact

Rôle large

S'il est compromis : atteint tous les buckets, préfixes et objets du compte.

Rôle étroit

S'il est compromis : atteint un préfixe, dans un bucket. Pas plus.

Anneaux concentriques illustrant un rôle large qui atteint tout le compte.

Anneaux concentriques montrant qu'un rôle étroit n'atteint que l'objet et le préfixe centraux, laissant le reste intact.

Moindre privilège, en pratique

Un rôle doit faire ce que son métier exige, et peu au-delà.

Géré par AWS, comme AmazonS3ReadOnlyAccess : tous les buckets. Géré par le client : le vôtre, jusqu'à un préfixe
Étendue et durée : identifiants de courte durée plutôt que clés de longue durée
AWS sécurise l'infrastructure
La largeur de vos rôles relève de votre choix, dans votre dépôt

Exemple : un rôle lecteur du bucket de rapports Deux autorisations. Rien d'autre.

Rien sur IAM, le service qui décide qui peut faire quoi

Liste des permissions d'un rôle avec trois permissions en trop barrées en rouge et deux requises en vert.

Passons à la pratique !

Sécurité AWS pour les développeurs