Introduction à la sécurité AWS

Utiliser la sécurité AWS pour les développeurs

Rahul Singh

Technical Product Manager

Préalables du cours

Bases de la sécurité AWS
Notions de base du nuage
Concepts de sécurité et de gestion des coûts AWS

Carte titre du cours sur la sécurité AWS et la gestion des coûts

Objectifs du cours

Identité : qui appelle
Autorisation : quoi peut être atteint
Secrets et chiffrement : protéger les 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 volet du cours. 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 est livré par 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 » part d'un encadré « Vous » vers le pipeline. Étape 3 : un badge orange sous le pipeline « sa propre identité ». Une flèche continue vers un encadré « AWS ».

D'abord, un terme de vocabulaire

Un pipeline automatise la création, les tests et le déploiement de votre code
Il s'exécute sur votre push, sans intervention humaine

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 un changement

Étape 1 d'un flux vertical. Un encadré « Vous », qui pousse un changement 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 un changement
Votre pipeline s'exécute

Un flux vertical. Étape 1 : Vous, poussant un changement de code. Une flèche mène vers l'étape 2 : votre pipeline, qui exécute 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 un changement
Votre pipeline s'exécute
Le déploiement s'arrête : AccessDenied

Premier réflexe : « Je vais vérifier mes propres autorisations. »

Un flux vertical. Étape 1 : Vous, poussant un changement de code. Étape 2 : votre pipeline exécute le déploiement. Étape 3 : AWS évalue la demande et renvoie AccessDenied.

Ce qui s'est réellement passé

Étape 1 d'un flux de gauche à droite. Un encadré « Vous », dont l'intervention se termine ici.

Vous poussez. Votre intervention se termine ici

Ce qui s'est réellement passé

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

Vous poussez. Votre intervention se termine ici
Le pipeline déploie, en tant que rôle créé par votre équipe

Ce qui s'est réellement passé

Un flux de gauche à droite de Vous, à Votre pipeline, à AWS. Un badge « deploy-role » sous le pipeline, et une flèche en pointillé « vérifie » d'AWS vers ce badge (pas vers Vous).

Vous poussez. Votre intervention se termine ici
Le pipeline déploie, en tant que rôle créé par votre équipe
AWS évalue ce rôle

Acteur et principal

Acteur

Celui ou celle qui déclenche le travail.

Ici : vous.

Icône d'une personne représentant l'acteur qui déclenche le travail.

Acteur et principal

Acteur

Celui ou celle qui déclenche le travail.

Ici : vous.

Principal

L'identité qu'AWS évalue à la réception de la demande.

Ici : le rôle du pipeline.

Icône d'une personne représentant l'acteur qui déclenche le travail.

Icône représentant le principal.

Acteur et principal

Acteur

Celui ou celle qui déclenche le travail.

Ici : vous.

Principal

L'identité qu'AWS évalue à la réception de la demande.

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 d'une personne représentant l'acteur qui déclenche le travail.

Icône montrant qu'AWS vérifie le principal plutôt que l'acteur.

Même déploiement, deux rôles

Rôle A (La forme de AdministratorAccess)

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

Rôle B

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

Préfixe : un chemin de type dossier dans un compartiment

Image montrant un rôle tout accès lié à six politiques différentes.

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

Rayon d'impact

Rôle large

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

Rôle étroit

S'il est compromis : atteint un préfixe, dans un compartiment. Rien de plus.

Anneaux concentriques illustrant un rôle large couvrant tout le compte.

Anneaux concentriques illustrant qu'un rôle étroit n'atteint que les anneaux les plus internes (objet et préfixe), laissant le reste intact.

Principe du moindre privilège, en pratique

Un rôle doit faire ce que son travail exige, et très peu plus.

Géré par AWS, comme AmazonS3ReadOnlyAccess : tous les compartiments. Géré par le client : le vôtre, jusqu'à un seul préfixe
Portée et durée : justificatifs de courte durée plutôt que clés de longue durée
AWS sécurise l'infrastructure
L'étendue de vos rôles relève de vous, et vit dans votre dépôt

Exemple : un rôle lecteur du compartiment 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 : trois permissions superflues biffées en rouge, deux requises conservées en vert.

Passons à la pratique !

Utiliser la sécurité AWS pour les développeurs