En tant que projet informatique, il paraît naturel que des employés de The Green Earth Post et des partenaires externes doivent avoir accès à différents services de votre compte AWS. Par exemple, Assitan, une data scientist de The Green Earth Post et qui doit analyser les commentaires sur le site ; ou encore une société partenaire qui s’occupe du design web et qui doit alimenter le compartiment S3 en images et logos.
En tant qu’administrateur, vous êtes chargé de mettre en place une politique de gouvernance pour authentifier ces personnes et leur donner des accès limités et temporaires par mesure de sécurité.
Organisez vos comptes de manière centralisée
Au sein de votre organisation, certains employés ont à la fois besoin d’un accès à un compte AWS pour leurs propres projets et d’un accès à vos ressources AWS. Par exemple, une équipe de design qui travaille sur les images et logos d’un site sur un compte AWS et qui doit les insérer dans le compartiment d’un autre compte AWS.
Vous pouvez mettre en place la même politique vue dans le chapitre précédent à partir des utilisateurs et groupes IAM. Cependant, cela devient vite un cauchemar pour une organisation d’un grand groupe où des projets de départements (RH, Finance, Supply Chain, etc.) et des environnements de développement cohabitent dans le même compte. En effet, la gestion des autorisations, des coûts d'utilisation par projet et par environnement, est beaucoup trop complexe.
Les avantages de ce service sont multiples.
Tout d’abord, cela permet de cloisonner les projets par compte et d’y affecter un administrateur dédié. Ce dernier sera chargé de la gestion complexe des utilisateurs IAM, des groupes IAM et des politiques associées.
En outre, Il est plus facile de centraliser les activités de monitoring au travers de la remontée des logs dans un bucket S3 du compte de gestion via le service AWS CloudTrail activé sur tous les comptes. Il en va de même du service CloudWatch activé dans tous les comptes vers celui du compte de gestion. Avec une stratégie de tag standard qui peut s’appliquer à tous les comptes à leur création, il est alors possible d’analyser et filtrer les logs par compte, par projet et par environnement.
Finalement, d’un point de vue financier, AWS Organizations offre une tarification plus avantageuse pour l’ensemble des comptes et une facturation consolidée pour tous les comptes avec une unique méthode de paiement.
Mais comment est structurée une organisation sur AWS ?
C’est assez simple. Les comptes AWS sont organisés en Organization Units (OU, unités organisationnelles) qui correspondent à des groupes de comptes servant une application ou un service. Il est possible d'inclure des OU dans une OU.
Comme indiqué dans l’image suivante, il existe plusieurs stratégies pour structurer les comptes :
soit par Business Unit (BU) (RH, Supply Chain, Marketing…) ;
soit par environnement de développement (DEV, OAT, PROD) ;
soit par projet.
En outre, vous pouvez appliquer des Service Control politiques (SCP, politiques de contrôle des services) afin d'y créer des limites de gouvernance ciblées. Comme pour les politiques, les SCP sont définies sous la forme d'un document JSON. Voici un exemple d’organisation que l’on pourrait obtenir dans un grand groupe en utilisant les différentes stratégies en y appliquant des SCP à certains OU et comptes.
Les membres de la direction de The Green Earth Post ont plusieurs idées pour leurs futurs projets : ils voudraient mettre en place des webinars autour des nouvelles technologies pour l’environnement, un jour même peut-être lancer une formation sur ce sujet. Dans le futur, on peut imaginer qu’il mettront en place la structure du compte par projets : “journal”, “école”, “évènements”…
Il est important de noter qu’une SCP appliquée au compte de gestion n’a aucun effet sur celui-ci. En outre, une SCP appliquée à une OU prédomine sur les SCP appliquées aux OU et comptes qu’elle contient. L’exemple sur l’image suivante illustre cela.
Jusqu’à présent nous venons de voir qu’il y avait quatre types d’autorisation :
les Identity-based politiques
les Resource-based politiques ;
les Permission Boundaries ;
les SCP.
Pour déterminer les autorisations effectives d’un utilisateur, d’un groupe ou d’un rôle IAM, il est nécessaire d’appliquer la Policy Evaluation Logic (politique d’évaluation des autorisations), qui se matérialise dans l’image ci-dessous.
Et qu’est-ce qui se passe avec les comptes de The Green Earth Post si l’organisation change ? Une migration des comptes vers la nouvelle organisation peut être nécessaire !
Oui. Et c’est tout à fait possible de le faire.
Pour migrer un compte membre, procédez comme suit :
Envoyez une invitation au compte membre à partir de la nouvelle organisation.
Acceptez l'invitation à la nouvelle organisation à partir du compte membre.
Pour migrer le compte de gestion, procédez comme suit :
Supprimez les comptes membres de l'organisation à l'aide de la procédure ci-dessus.
Répétez la procédure ci-dessus afin d'inviter l'ancien compte de gestion à rejoindre la nouvelle organisation en tant que compte membre.
Accordez des accès limités et temporaires avec AWS STS
Intéressons-nous d’un peu plus près à AWS STS qui est au centre de tous les autres services AWS. En effet, il permet d’accorder des accès limités et temporaires pour accéder à d’autres services AWS de différents comptes. Il émet un jeton (token) (inclus dans des informations d’identification de sécurité temporaires), valide entre 15 minutes et une heure et qu’il faudra renouveler. Ainsi, l’équipe de design pourra demander des accès temporaires afin d’accéder au compartiment S3 et y déposer des images et des logos.
Comme tout autre service, AWS STS est accessible via API et expose plusieurs opérations, selon les cas, pour récupérer le token. Voici les quatre opérations principales à retenir.
AssumeRole, destinée aux utilisateurs IAM – pour accéder à leur propre compte ou faire du cross account, c’est-à-dire, accéder à un autre compte ;
AssumeRoleWithSAML, destinée à des utilisateurs qui ont été authentifiés par SAML (Security Assertion Markup Language), généralement des employés d’une entreprise qui s’authentifient via les mécanismes de l’entreprise pour accéder à AWS ;
AssumeRoleWithWebIdentity, destinée à des utilisateurs qui ont été authentifiés dans une application mobile ou web avec un fournisseur d'identité web, comme par exemple Facebook Login, Google Login ou un fournisseur compatible OIDC ;
GetSessionToken, destinée aux utilisateurs IAM utilisant MFA.
Pour comprendre plus en détail le fonctionnement, étudions le cas de l’opération la plus répandue AssumeRole. L’image suivante montre comment un utilisateur IAM emprunte et assume un rôle.
1 - L’utilisateur IAM invoque l’API AssumeRole de STS pour récupérer des informations d’identification de sécurité temporaires et assumer le rôle.
2 - STS vérifie grâce à AWS IAM si l’utilisateur IAM a des politiques pour assumer le rôle.
3 - Si oui, il obtient de la part de STS des informations d’identification de sécurité temporaires (incluant un jeton de session).
4 - L’utilisateur IAM peut assumer le rôle temporairement entre 15 minutes et 1 heure.
Ce fonctionnement est très similaire dans le cas où l’utilisateur IAM ou un processus AWS souhaite faire du cross-account (accès entre les comptes), comme indiqué dans l’image ci-dessous.
A - Admin crée un rôle MettreAJourApp qui autorise le compte DEV à accéder en lecture/écriture au compartiment productionApp.
B - Admin accorde aux utilisateurs IAM du groupe Développeurs d’assumer le rôle MettreAJourApp.
C - Un utilisateur IAM du groupe développeurs demande à un accès au rôle.
D - STS renvoie le jeton.
E - L’utilisateur IAM met à jour le compartiment productionApp grâce au rôle assumé.
En résumé
Le service AWS Organizations permet de gérer et d’organiser une multitude de comptes au sein d’une organisation.
Les comptes AWS sont organisés en Organizational Unit(s) (OU).
Les Service Control Policies (SCP) permettent de créer des limites de gouvernance ciblées au niveau des OU et des comptes.
La Policy Evaluation Logic donne les moyens de déterminer les autorisations effectives.
AWS STS est au centre de tous les autres services AWS et permet d’accorder des accès limités et temporaires pour accéder à d’autres services AWS.
Après avoir vu comment mettre en place une gouvernance d’un compte voire d’une organisation, nous allons découvrir comment centraliser l’authentification d’utilisateurs et d’applications externes à notre compte et à nos applications !
