5. Jérémie Rodon
Architecte Cloud
Une certaine passion pour la sécurité et
plus de 2 ans d’expérience
professionnelle sur AWS
Votre serviteur ce soir
jeremie.rodon@d2si.io
6. D2SI partenaire AWS
🎓 50 AWS Professional & 200 AWS Associate
&
DEVOPS & BIG DATA
+ 2 600 adhérents
Meetup AWS
7. AGENDA
1 Les habilitations dans AWS
3 Les “Boundary Policy”
2 L’escalade de privilèges
4 Aller plus loin : la protection de ressources
9. Service IAM Le service IAM permet de
contrôler précisément Qui a quels Accès à
Quoi dans quelles Conditions
Identity and Access Management
Policy IAM Les policies utilisent une
syntaxe poussée, basée sur JSON, pour
exprimer des droits d’accès très précis
10. IAM : Les composants du service
Role
User Group
Policy
11. Statement - Une policy est un ensemble de
statements qui contiennent...
IAM : les Policy
Effect - Allow or Deny
Action - La liste d’actions concernée par
l’effet, sous la forme <service>:<api_call>.
Accepte les wildcards (*)
Resource - La liste des ressources pour
lesquels s’applique l’effet sur les actions.
Accepte les wildcards (*)
Condition - Une liste (optionnelle) de
conditions auxquelles s’applique l’effet sur les
actions pour les ressources
12. AssumeRolePolicy - Une Resource Policy
qui permet de définir Qui peut assumer le
role, éventuellement avec des conditions.
Dans la console, c’est elle qui determine la
Trust Relationship
IAM : les Role
Session - Lorsqu’on assume un role, on
obtient une session. Ce sont des credentials
temporaires qui ont les droits du role.
13. IAM : les Role
Moi et mes permissions
Un role et ses permissions
Mes droits
sts:AssumeRole
Session
=
credentials temporaires
14. Naviguer
entre
différents
comptes
AWS
Permettre à
un compte
AWS tiers
d’avoir un
accès
limité
Donner des
droits à un
service
AWS
Fédération
d’identité avec
un provider
externe
EC2, Lambda… Mais aussi Config, Firehose, CloudWatch Events et bien
d’autres...
Base des architectures multi-comptes, les utilisateurs utilisent des rôles pour
accéder aux comptes AWS qui les concernent
Besoin de donner à un fournisseur tiers un accès limité à un compte AWS ?
Role.
Vous souhaitez que vos utilisateurs utilisent leur compte d’entreprise pour se
connecter à la console AWS ? Encore role...
IAM : l’utilisation des Role
16. L’escalade de privilèges, qu’est-ce donc ?
Tentative de définition : Fait, pour un utilisateur ayant des droits limités sur un système,
d’acquérir sur ce système des droits supplémentaires qui ne lui étaient pas destinés.
17. Et dans AWS ?
DevOps
projet EC2
ec2:RunInstances
ec2:StartInstances
ec2:StopInstances
etc...
iam:CreateRole
iam:PutRolePolicy
iam:CreateInstanceProfile
iam:AddRoleToInstanceProfile
etc...
Role
Créer
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
20. Une policy - C’est une policy comme les
autres, utilisée en tant que boundary
IAM : les Boundary Policy
User ou Role - Une boundary ne peut être
appliquée que sur un user ou un role, pas sur
un groupe !
Frontière - Si elle est écrite correctement,
elle agit comme une frontière indépassable
pour l’utilisateur ou le role
Modifie les droits - Une boundary ne
donne aucun droit, mais on ne peut pas avoir
un droit qu’elle ne donne pas...
21. Protection - La boundary doit être écrite de
sorte à se protéger elle-même
Écrite correctement ?
Réplication - La boundary doit obliger celui
qui la porte à la répliquer sur les user/role qu’il
crée
Pas automatique - Contrairement à ce
qu’on entend parfois, les points précédents ne
sont pas une feature automatique des
boundary
25. Les
systèmes
de
compliance
La
topologie
réseau
Les roles
d’Organizati
ons
Celui d’Organizations et de manière générale tous les roles de sécurité,
audit, etc...
On laisse la liberté aux utilisateurs, et des systèmes contrôlent la validité de
leurs systèmes et les avertissent
En général la topologie réseau est planifiée, les utilisateurs ont rarement le
droit d’attacher de nouveaux subnets au réseau d’entreprise
Des ressources à protéger
Comment protéger ces ressources ?
26. Comment protéger des ressources ?
● Les boundaries !
● Oui, jusqu’à fin mars 2019, il n’y avait pas le choix…
Mais maintenant il y a les SCP !
27. SCP Des IAM policy un peu spéciales qui
résident au niveau d’AWS Organizations
Service Control Policy
Service Control Historiquement, elles
permettaient uniquement de contrôler les
Action autorisées dans les comptes enfants,
sans bloc Resource ou Condition
Mars 2019 La date à laquelle les SCP se
sont mises à supporter les Resource et
Condition (uniquement sur des “Deny”)
Incontournable Les SCP s’appliquent aux
comptes d’une Organization et même le “root”
de ces comptes ne peut y échapper !