Il existe deux manières principales de gérer l'accès des employés aux utilisateurs IAM et aux organisations AWS du compte AWS de votre entreprise—. Les deux ont leur utilité, mais il est important de souligner les différences lors de la planification de votre structure d'autorisation AWS.
Réponse courte : les deux, en fait
Lequel devriez-vous utiliser ? La réponse est les deux, car les utilisateurs IAM et les organisations AWS font des choses différentes. Bien qu'ils soient similaires en surface, ils sont conçus pour des objectifs différents.
Les utilisateurs IAM sont un excellent moyen de gérer l'accès des employés. Ils vous permettent d'authentifier les employés sur un “sous-compte” avec des autorisations limitées. Ce système de gestion des autorisations est crucial pour segmenter l'accès des employés à vos ressources AWS.
Les utilisateurs IAM sont également utilisés pour authentifier les comptes de service. Par exemple, si l'AWS CLI s'exécute sur une instance EC2 et que vous souhaitez lui donner accès à la gestion d'un compartiment S3, vous pouvez le faire avec un utilisateur IAM afin de ne pas avoir à quitter votre racine. identifiants de compte sur un serveur distant.
AWS Organizations fait quelque chose de similaire. Il vous permet de créer de véritables sous-comptes entièrement distincts du compte principal, dotés de leurs propres autorisations, tout en conservant une facturation et un contrôle centralisés. Vous pensez peut-être que ce serait un excellent moyen de donner l'accès aux employés, mais les organisations ne sont pas faites pour cela.
Publicité
Le principal problème est que vous êtes limité à quatre comptes par défaut. Bien que vous puissiez demander une augmentation de la limite, la limite est là pour une raison : tous les comptes de votre organisation sont entièrement séparés. Cela signifie que si vous aviez un développeur travaillant sur une table DynamoDB dans son propre compte, elle serait invisible pour tous les autres employés.
Ce que vous voulez vraiment, c'est que tous vos employés travaillent ensemble dans un environnement partagé. La meilleure configuration pour presque toutes les entreprises serait la suivante :
- Utilisez AWS Organizations et créez des comptes distincts pour le développement et la production. Cela soulage vos développeurs et vous permet de leur donner des autorisations plus laxistes dans l'environnement de développement sans craindre qu'ils ne bousillent vos serveurs de production.
- Vous pouvez également créer deux autres environnements : les tests , qui contient des données factices propres et est utilisé par l'équipe QE pour exécuter des builds automatisés ; et la mise en scène, un miroir complet de la production utilisé pour détecter les bogues pouvant survenir à l'aide d'API publiques et de données réelles avant qu'ils n'affectent réellement les clients.
- Dans l'environnement de développement, créez plusieurs utilisateurs IAM pour donner un accès géré à votre employés.
- Répétez le même processus pour votre équipe QE lors des tests, et pour vos chefs de projet et architectes de solutions lors de la mise en scène. La production ne doit être mise à jour que par des personnes très autorisées et, bien sûr, contenir les comptes de service IAM dont elle a besoin pour fonctionner correctement.
Cette structure combine les avantages des deux types de comptes, et semble être comment AWS souhaite que vous le configuriez, compte tenu de la règle des quatre comptes (par défaut) d'AWS Organization.