C’est votre deuxième jour chez The Green Earth Post ! Aujourd’hui, vous rencontrez vos 4 futurs collaborateurs chargés de développer et gérer le nouveau site :
Zhao, le chef de projet ;
Léo, un développeur ;
Jasmine, une développeuse et testeuse ;
Dora, une testeuse et responsable des opérations de déploiement.
Il faut maintenant configurer l'accès à votre compte AWS pour cette équipe.
À la création de votre compte AWS, vous disposez d’une seule identité nommée utilisateur racine (root account), qui a un accès complet à tous les services et ressources AWS de votre compte. Par sécurité, vous devrez utiliser un utilisateur AWS (user) avec des droits plus restreints. Le root account ne sera utilisé que pour créer cet utilisateur IAM. Pour cela, il faudra manipuler le service AWS Identity and Access Management (IAM).
Il est possible de découper votre équipe en trois groupes de responsabilité. Un pour les développeurs, un pour les testeurs et un dernier pour la gestion des opérations. Par conséquent, l’administrateur du compte AWS sera chargé de créer quatre utilisateurs IAM ainsi que trois groupes : Développeur, Testeurs et Opérationnels. Puis, il devra associer les utilisateurs IAM à leurs groupes respectifs, comme indiqué ci-dessous.
Il est à noter qu’un utilisateur IAM peut ne pas avoir de groupe – c’est le cas de Zhao – ou a contrario avoir plusieurs groupes comme Jasmine et Dora. En revanche, il n’est pas possible d’inclure un groupe dans un autre.
À vous de jouer !
Vous l'avez peut-être déjà deviné, mais vu que Zhao, Léo, Jasmine et Dora ne sont pas réels, ils ne vont pas vous aider avec le projet en réalité… Par conséquent, vous n’avez pas besoin de créer tous les utilisateurs de l’équipe mais un seul. Il s’agira d’un utilisateur IAM, nommé admin, qui aura des autorisations d’administrateur sur le compte AWS. Ces autorisations sont moins ouvertes que celles de l’utilisateur racine (root account). La procédure pour créer un utilisateur et un groupe IAM est la même pour tous, donc l’exemple avec admin sera suffisant pour comprendre comment utiliser le service IAM.
Voici les tâches à réaliser :
Créez un groupe admin avec la permission AdministratorAccess.
Créez un utilisateur IAM (user) nommé admin et associez-le au groupe précédent.
Connectez-vous dorénavant avec cet utilisateur IAM.
Poursuivez avec moi pour voir si vous avez bien réussi.
Gérez les autorisations
Mais à quoi est-ce que ça sert de créer des groupes ?
Bonne question ! L’intérêt de créer des utilisateurs et des groupes IAM est de leur affecter des politiques (autorisations) précises et distinctes en fonction des besoins. Par défaut, un utilisateur ou un groupe IAM n’a aucune autorisation, c’est le composant AWS politique IAM qui permet de les créer et de les définir sous la forme d’un document JSON. Ci-dessous, l’explication de la structure d’un tel document.
Une politique est constituée de :
une version du langage, “2012-10-17” ;
un identifiant optionnel id ;
un statement (déclaration) contenant les autorisations ou interdictions formelles :
un identifiant optionnel sid,
un objet Effect pour permettre ou interdire des actions,
un objet Action pour spécifier les actions concernées,
un objet Resource pour définir la liste des ressources AWS concernées.
Zhao, qui est le chef de projet et donc ne s’occupe pas de développement, a uniquement besoin de consulter en lecture des fichiers d’un compartiment (bucket) Amazon S3 nommé “photos”. Voici la politique à lui attacher :
{
"Version": "2012-10-17",
"Id": "TimS3Policy",
"Statement": [
{
"Sid": "TimS3Statement",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::photos/*",
"arn:aws:s3:::photos"
]
}
]
}
En revanche, le groupe de développeurs a besoin d’ajouter, de supprimer et de lire les fichiers. Voici la politique à attacher :
{
"Version": "2012-10-17",
"Id": "DevelopperS3Policy",
"Statement": [
{
"Sid": "DevelopperS3Statement",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::photos/*",
"arn:aws:s3:::photos"
]
}
]
}
Lorsqu’il s’agit d’attacher une politique à un utilisateur, un groupe ou une rôle IAM on parle de politiques/stratégies basées sur l’identité (Identity-based policies), c’est-à-dire, des autorisations basées sur l’identité. Il est également possible de faire autrement, c’est-à-dire, d’associer une politique à une ressource AWS pour autoriser un principal (utilisateur IAM, rôle, service, compte…) à y accéder. C’est ce qui se nomme une politique/stratégie basée sur une ressource (resource-based policy). Elle spécifie qui a accès à la ressource et quelles actions peuvent être exécutées. Le schéma ci-dessous explique les deux principes.
Pour le projet The Green Earth Post, si on associe des partenaires avec d’autres comptes AWS à notre compartiment S3, on pourrait mettre en place l'accès entre comptes (cross account) avec une politique basée sur une ressource.
Définissez des rôles
Le composant AWS IAM Roles permet, quant à lui, de regrouper des politiques pour former un ensemble cohérent d’autorisations sous la forme d’un rôle(role). Ce dernier peut être endossé par des utilisateurs et/ou des groupes IAM. En effet, dans notre cas, l’administrateur définit pour chaque groupe un rôle auquel il attache les politiques adéquates.
En outre, il est également possible de créer des rôles à adosser à des services AWS. En effet, cela permet d’obtenir des informations d’identification de sécurité temporaires (que l’on verra plus tard avec le service AWS STS) pour effectuer des appels d’API AWS, c'est-à-dire accéder à d’autres services AWS.
Dans le cas du site de The Green Earth Post, si un programme s’exécute sur instance EC2 et doit pouvoir lire des fichiers dans un compartiment S3 et écrire des fichiers dans un autre compartiment S3, alors, en tant qu’administrateur, vous définissez un rôle avec deux politiques : une pour la lecture avec l’action s3:GetObject sur le compartiment en lecture et une autre pour l’écriture dans l’autre compartiment avec l’action s3:PutObject .
À noter qu’il est possible de définir des permissions boundaries (limites d’autorisations) pour un utilisateur ou un rôle IAM. En effet, l’administrateur est amené à donner aux utilisateurs du groupe DEV la possibilité de créer des rôles. Afin de s’assurer qu'ils n’outrepassent pas leur champ d’action, l’administrateur définit des politiques de limite comme on peut le voir ci-dessous. Par exemple, qu’ils ne puissent pas lancer certains types d’instances EC2 très coûteuses.
Découvrez les outils de sécurité IAM
Il est désormais temps de découvrir les deux principaux outils de sécurité IAM : IAM Credentials Report et IAM Access Advisor.
L’image suivante indique comment le générer.
Ce rapport est un fichier CSV qui contient tous les utilisateurs IAM du compte et le statut de leurs diverses informations d'identification. En effet, il indique :
si l'authentification par mot de passe est activée ;
si des clés d’accès ont été générées, ainsi que leur date de dernière utilisation et de modification ;
si le dispositif MFA est mis en place, ce qui permet de identifier et s’adresser aux utilisateurs IAM qui n’appliquent pas les bonnes pratiques de sécurité.
Par exemple, dans l’image suivante on peut voir que le dernier service accédé est Amazon API Gateway.
Grâce à IAM Access Advisor vous êtes en mesure d’étudier l’historique des services auxquels l’utilisateur a accédé et de identifier quelles sont les politiques accordées à l’utilisateur IAM et non utilisées. Vous pourrez ainsi réduire les politiques non utilisées pour être en ligne avec le principe de moindre privilège.
En résumé
Le service AWS IAM permet de créer des utilisateurs IAM correspondant à des personnes physiques au sein de votre organisation.
Il permet de créer des groupes d’utilisateurs IAM ayant des autorisations et responsabilités communes.
Par défaut, un utilisateur ou un groupe IAM n’a aucune autorisation sur un compte AWS. Le sous-service AWS IAM politiques donne la possibilité de créer des politiques et de leur accorder les autorisations utiles.
Vous pouvez également regrouper des politiques au sein d’un rôle à attribuer à des services AWS.
Pour auditer la sécurité IAM de votre compte, vous disposez de deux outils : AWS Credentials Report et AWS Access Advisor.
Votre équipe de développement ne sera pas la seule à accéder à votre compte AWS. Nous allons découvrir comment mettre en place une gouvernance pour autoriser d’autres personnes de votre organisation ainsi que des partenaires externes !
