Les entreprises sont complexes et nécessitent beaucoup plus de configuration pour gérer les comptes AWS de centaines de personnes. Dans cet article, nous abordons les meilleures pratiques pour gérer l'accès sécurisé aux ressources de votre organisation sans gêner vos développeurs avec de la bureaucratie.

Utiliser les utilisateurs IAM pour les comptes d'employés

Si vous avez déjà utilisé AWS, vous connaissez probablement les utilisateurs IAM. Il s'agit essentiellement de comptes de service utilisés pour authentifier les éléments exécutés sur des serveurs distants et leur permettre d'accéder aux ressources AWS dont ils ont besoin (placer des éléments dans un compartiment S3, exécuter des fonctions lambda, etc.) sans donner un accès complet à votre compte principal. De cette façon, si vos serveurs sont compromis (par un pirate informatique ou un employé non autorisé), l'intrus n'a accès qu'aux autorisations que vous avez données.

Les utilisateurs IAM sont excellents et sont également utiles pour donner aux employés l'accès aux services dont ils ont besoin. Lorsque vous créez un utilisateur IAM, vous avez la possibilité d'activer l'accès à la console de gestion (par opposition à l'accès CLI / API), ce qui vous permet de donner le compte à un employé et de lui permettre d'accéder à la console de gestion avec des autorisations restreintes. Vous pouvez même activer l'authentification multifacteur (MFA) pour les utilisateurs IAM avec accès à la console, ce qui les rend très sécurisés.

Le principal problème, cependant, est que les employés utilisant des comptes IAM ne pourront pas créer leurs propres utilisateurs IAM sans l'aide du compte racine. Si vous avez un chef de projet qui doit donner un accès S3 PUT sécurisé à une application, il doit demander au titulaire du compte racine de créer un tout nouvel utilisateur IAM spécifiquement pour cette autorisation. Étant donné que le titulaire du compte racine est généralement le propriétaire, le directeur technique ou une personne de haut niveau, c'est une énorme perte de temps, surtout si vous ne touchez même pas à la production.

Sinon, les utilisateurs IAM sont la voie à suivre pour donner un accès géré à certains services. Vous pouvez créer des groupes IAM, qui sont utiles pour définir les autorisations de chaque rôle de votre organisation. Quoi que vous fassiez, rappelez-vous simplement le principe des «moindres autorisations»: chaque compte ne doit avoir que les autorisations dont il a besoin pour faire son travail efficacement, rien de plus. Assurez-vous également de ne pas accorder l'accès IAM aux utilisateurs IAM, sinon ils peuvent augmenter leurs privilèges.

Séparation des environnements de développement et de production

La solution au problème de la sécurité variable est AWS Organizations. Ce service vous permet d'administrer plusieurs comptes différents sous un compte racine, avec une facturation consolidée (l'utilisateur root paie pour chaque compte enfant).

La limite par défaut est de quatre comptes, ce qui rend les organisations impossibles à utiliser en tant que comptes d'employés individuels. Cela n'aurait pas beaucoup de sens de le faire de toute façon, car chaque compte est séparé des autres et ne pourra pas voir les services ou les serveurs lancés dans d'autres comptes. Vous pouvez demander une augmentation de limite si vous avez besoin de plus d'environnements, mais AWS souhaite que vous utilisiez des utilisateurs IAM pour les employés.

Le but d'AWS Organizations est de séparer les environnements de développement et de production. Des règles différentes s'appliquent à chaque environnement; Par exemple, vous voudrez peut-être empêcher les employés de créer de nouveaux utilisateurs IAM sans passer par tous les canaux appropriés et consulter les supérieurs, mais dans le développement, devoir passer par toutes ces vérifications ne ferait que ralentir les développeurs. Vous pouvez choisir de donner à vos chefs de projet l'accès au compte de développement pour permettre des tests plus rapides.

En ce qui concerne la hiérarchie, le compte principal joue le rôle de racine de l'arborescence et gère la création de nouveaux comptes. Les comptes peuvent être triés en unités d'organisation, qui agissent comme des groupes et appliquent des autorisations à chaque compte en dessous. Ceux-ci peuvent être imbriqués comme bon vous semble (si vous avez même suffisamment de comptes pour le faire).

La recommandation d'AWS ici est probablement à quoi votre organisation devrait ressembler. Vous avez le compte de production principal, qui est hautement sécurisé et n'est vraiment entièrement accessible que par la haute direction. L'environnement «Test» ou «Staging» fonctionne comme un miroir de la production, et est accessible par vos ingénieurs qualité et toute autre personne qui effectue des tests avant de pousser les changements vers la production. Vous pouvez choisir de les diviser en deux environnements distincts: le test est destiné aux tests automatisés avec des données factices (fonctionnellement une extension du développement, mais plus propre), et la mise en scène est un miroir complet de la production, y compris les données client et l'accès à de véritables API publiques.

Ensuite, vous avez le développement, qui est accessible par vos chefs de projet et les développeurs sous eux. Cet environnement dispose d'autorisations beaucoup plus laxistes, car la sécurité globale de celui-ci n'a pas autant d'importance que la production. Les bases de données créées en développement (ou en test, d'ailleurs) ne doivent pas inclure de données client.

La plupart de vos développeurs opèrent probablement à partir de comptes IAM personnels dans l'environnement de développement, ce qui leur donne un accès beaucoup plus complet qu'ils n'auraient autrement en production. Vous voudrez probablement donner à vos développeurs l'autorisation d'utiliser la plupart des services que vous utilisez en production (gardez simplement un œil sur les choses pour vous assurer que l'utilisation est sous contrôle).

Les unités d'organisation (UO) vous permettent également de restreindre les autorisations de chaque compte, à l'aide de stratégies de contrôle de service (SCP). Les SCP ressemblent beaucoup aux stratégies IAM, mais à un niveau supérieur: elles s'appliquent à l'ensemble du compte sous elles. Si le compte de développement créait un utilisateur IAM qui avait accès à S3, mais que S3 n'était pas activé dans le SCP, cet utilisateur IAM ne pourrait pas utiliser S3 sur ce compte. Les services sont refusés par défaut, vous devez donc les mettre manuellement sur liste blanche pour pouvoir les utiliser.

Un compte AWS par unité d'organisation devrait convenir à la plupart des applications, mais vous avez la possibilité d'en créer d'autres. Si vous souhaitez disposer d'un environnement de développement distinct pour différentes équipes, vous pouvez créer deux ou plusieurs comptes de développement sous une unité d'organisation. Même avec un seul compte, vous pouvez toujours gérer les autorisations avec les règles SCP.

Vérifiez régulièrement la sécurité de votre organisation

Si vous configurez une organisation dans AWS, vous allez rapidement rencontrer le problème de devoir exécuter des contrôles de sécurité réguliers pour vous assurer que tout est sécurisé. AWS fournit un liste de contrôle de sécurité que vous devriez lire et vous assurer que vous êtes conforme à tout. Même quelque chose d'aussi simple que de vérifier que chaque utilisateur est au bon endroit est une bonne pratique.

Si quelqu'un quitte l'entreprise, vous devez vous assurer que tous les comptes IAM associés sont désactivés ou transférés. Si quelqu'un change de rôle, vous devez également vous assurer que les règles de son compte reflètent ce rôle et qu'il ne dispose pas des autorisations restantes d'anciennes tâches.

Vous devez également vous assurer que les autorisations SCP sont correctement définies pour chaque unité d'organisation et qu'elles ne changent pas beaucoup au fil du temps. Vous ne voulez pas que l'environnement de développement puisse en louer 20 c5d.24xlarge instances et conduisez votre facture à travers le toit.