Déléguer les services AWS liés à l'organisation sur des comptes membres

Le compte AWS payeur est la brique centrale de votre landing zone. C'est ce compte qui détient les informations de facturation ainsi que la racine de l'organisation.

Au fil des années, AWS a ajouté de nombreuses fonctionnalités autour de l'organisation pour pouvoir travailler à l'échelle et faciliter la maintenance de la landing zone. Le compte payeur devenait de plus en plus stratégique au fil des services ajoutés.

En 2020, AWS a mis en place pour la première fois la délégation de compte vers un compte membre (pour le service IAM Access Analyzer). Cela a permis de déplacer les responsabilités pour ce service, et au fil des mois de nouveaux services ont profité de la délégation pour s'affranchir de la contrainte du compte payeur.

Mes clients font preuve de prudence quand on parle du compte payeur, une liste très limitée d'utilisateurs ont accès à ce compte, avec un respect strict du moindre privilège.

Nous allons voir les services principaux qui peuvent être délégués, et nous allons les regrouper pour optimiser leur utilisation pour chaque équipe, et pour sécuriser ces services plus facilement en les déléguant sur les bons comptes.

Qu'est-ce que la Délégation de Services AWS ?

La délégation de services AWS est le mécanisme qui permet à un service AWS (comme AWS Config ou AWS Systems Manager) d'effectuer des opérations et de gérer des ressources au nom de votre organisation, et surtout, de désigner un compte membre spécifique pour administrer ce service pour l'ensemble de l'organisation.

Il existe deux concepts clés à comprendre :

Accès de confiance (Trusted Access)

C'est la première étape. Lorsque vous activez l'accès de confiance pour un service AWS avec AWS Organizations, vous autorisez ce service à créer des rôles liés au service (Service-Linked Roles) dans vos comptes membres. Ces rôles permettent au service d'accéder aux ressources nécessaires pour fonctionner au niveau de l'organisation. C'est une permission large, mais nécessaire pour l'intégration. Par exemple, si vous activez l'accès de confiance pour AWS Config, AWS Config pourra déployer des règles et collecter des données de conformité dans tous les comptes de votre organisation.

Administrateur Délégué (Delegated Administrator)

C'est le cœur de la délégation. Au lieu que le compte de gestion (Management Account) soit le seul à pouvoir administrer un service pour toute l'organisation, vous pouvez désigner un compte membre spécifique comme « administrateur délégué » pour ce service. Ce compte délégué peut alors effectuer des opérations d'administration pour le service dans tous les comptes de l'organisation, sans avoir besoin d'accéder directement au compte de gestion.

Imaginez le compte de gestion comme le PDG de l'entreprise. Il définit la stratégie globale. La délégation de services, c'est comme nommer un directeur de département (le compte administrateur délégué) qui gère les opérations quotidiennes de son département (le service AWS) pour toutes les filiales (les comptes membres), sans que le PDG n'ait à s'immiscer dans chaque détail opérationnel. Cela permet de décharger le compte de gestion de tâches opérationnelles et de renforcer le principe du moindre privilège.

Les services liés à l'organisation et les possibilités de délégation

Nous pouvons trouver la liste complète de tous les services pouvant être délégués ici : Services AWS que vous pouvez utiliser avec AWS Organizations

Nous allons définir quelle équipe de l'entreprise pourrait être responsable de chaque service, pour ensuite déployer la délégation de service sur les comptes correspondants. Nous allons choisir en priorité les équipes qui effectueront les actions sur les comptes AWS et le maintien en condition opérationnelle (MCO / RUN).

Pour plusieurs services, nous pouvons configurer une délégation sur plusieurs comptes AWS. Je vous conseille de limiter à un compte la délégation pour que l'on soit aligné avec le RACI (Responsible, Accountable, Consulted et Informed). Chaque fonctionnalité doit être prise en charge (Accountable) par une équipe pour éviter tout conflit ou zone non couverte (« Ce n'est pas ma responsabilité mais celle de l'autre équipe »).

(1) : Malgré le fait que AWS Config soit un service de sécurité et indispensable pour la gouvernance, il est plus intéressant de le déléguer à l'équipe opérations. L'équipe sécurité va définir les objectifs (en se basant sur les obligations légales et des frameworks tels que PCI-DSS ou NIST par exemple) et lister les tests de conformité à mettre en place. Les Opérations vont implémenter ces demandes, rajouter d'autres tests, ajouter des remédiations automatiques dans certains cas. En cas de non-conformité, les opérations seront alertées et seront responsables de la remise en conformité de la ressource qui a créé l'alarme. L'équipe sécurité sera informée de ces actions.

(2) : Le choix sur ce point est assez complexe, et les 2 équipes proposées pourraient parfaitement être responsables de ce point. J'ai choisi de proposer plutôt l'équipe sécurité car dans les grands groupes où j'ai pu intervenir, la taille et la formation des équipes sécurité était suffisante pour répondre aux demandes (réactivation exceptionnelle des comptes root ou déblocage SQS et S3). Cette fonctionnalité touche les comptes root, ce qui reste un point très sensible, et donc nous allons privilégier l'équipe sécurité qui est garante des données critiques, sensibles et confidentielles.

(3) : Les licences sont un point qui doit être précisément suivi par les FinOps pour éviter toute pénalité. Ce sont les équipes opérations qui vont déployer les licences et faire le suivi de leur utilisation. Il est donc nécessaire que les opérations soient responsables de ce point (Responsible) et qu'elles partagent les informations de suivi avec les FinOps qui sont validateurs et responsables de l'utilisation (Accountable).

(4) : Cette fonctionnalité peut être utile pour les FinOps, mais les utilisateurs principaux seront dans l'équipe opérations.

Avantages de la Délégation de Services

La délégation de services apporte de nombreux bénéfices à votre organisation.

• Gouvernance centralisée et simplifiée : Le compte de gestion reste léger et se concentre sur la gouvernance de haut niveau (création de comptes, OUs, SCPs). Les opérations quotidiennes et la gestion des services sont déléguées à des comptes membres spécialisés, réduisant la charge sur le compte racine.
• Sécurité améliorée : Réduit la surface d'attaque du compte de gestion en limitant les opérations directes sur celui-ci. La gestion des permissions est plus aisée dans les comptes membres, car la portée de chacun est réduite. Cela permet une application cohérente des politiques de sécurité et une meilleure posture globale.
• Principe du moindre privilège : Renforce ce principe fondamental de sécurité. Les équipes n'ont accès qu'aux services nécessaires à leurs missions. Par exemple, le compte de gestion n'a pas besoin d'accéder aux données de sécurité agrégées, c'est le compte de sécurité délégué qui le fait.
• Évolutivité : Facilite l'ajout de nouveaux comptes à l'organisation, car ils héritent automatiquement des configurations déléguées des services, réduisant le temps de mise en conformité des nouveaux environnements.

Défis liés à la délégation

Malgré ses nombreux avantages, la délégation de services présente certaines limites.

• Complexité initiale : La mise en place demande une bonne compréhension d'AWS Organizations, IAM, et des services spécifiques que vous souhaitez déléguer. Ce n'est pas encore une solution « plug-and-play » et nécessite une planification minutieuse.
• Dépendance au compte administrateur délégué : Le compte désigné comme administrateur délégué devient un point de contrôle critique pour le service qu'il gère. Sa sécurité est primordiale. Une compromission de ce compte peut avoir des répercussions sur toute l'organisation pour le service délégué.
• Portée des permissions : Il est crucial de comprendre précisément quelles permissions le service délégué obtient et ce que l'administrateur délégué peut faire. Une mauvaise configuration peut entraîner des permissions excessives ou des lacunes de sécurité.
• Pas tous les services ne supportent la délégation : C'est une limite importante. Avant de planifier, vérifiez toujours la documentation AWS pour confirmer si le service que vous souhaitez déléguer prend en charge la fonctionnalité "Delegated Administrator" ou "Trusted Access" avec AWS Organizations. La liste des services évolue régulièrement.
• Impact sur les SCPs : Les SCPs peuvent toujours restreindre les actions des administrateurs délégués. Assurez-vous que vos SCPs n'empêchent pas les actions nécessaires à la gestion déléguée du service.

Recommandations

Pour tirer le meilleur parti de la délégation de services et éviter les pièges, suivez ces bonnes pratiques :

• Planification Rigoureuse : Ne vous lancez pas à l'aveugle. Définissez clairement les rôles, les responsabilités, les services à déléguer et les comptes qui seront administrateurs délégués. Gardez en tête que la transformation du modèle opérationnel et des équipes reste un des grands challenges de la délégation.
• Principe du Moindre Privilège (encore et toujours !) : Appliquez des politiques IAM strictes aux rôles et utilisateurs dans le compte administrateur délégué. Ils ne devraient avoir que les permissions nécessaires pour administrer le service délégué, et rien de plus.
• Surveillance : Utilisez AWS CloudTrail pour auditer toutes les actions effectuées par les services délégués et les administrateurs délégués.
• Automatisation (IaC) : Utilisez l'Infrastructure as Code (IaC) pour gérer la configuration d'AWS Organizations et la délégation de services. Cela assure la cohérence, la reproductibilité et facilite les mises à jour.
• Documentation : Documentez minutieusement votre stratégie de délégation, les services délégués, les comptes administrateurs et les processus associés. C'est vital pour la maintenabilité et la compréhension par les équipes.
• Formation des équipes : Assurez-vous que vos équipes comprennent le nouveau modèle de gouvernance et leurs responsabilités dans un environnement délégué.
• Tests : Testez toujours vos configurations de délégation dans un environnement non-production avant de les déployer à grande échelle. Validez que les services fonctionnent comme prévu et que les permissions sont correctement appliquées.

Conclusion

La délégation de services AWS est intéressante et peut devenir une nécessité pour une organisation souhaitant opérer sur AWS à grande échelle de manière sécurisée, conforme et efficace. Pour des organisations plus modestes, qui n'ont pas d'obligations légales ou qui n'ont pas d'équipes opérationnelles ou de sécurité de taille suffisante, il peut être intéressant de rester sur un modèle centralisé.

Dans tous les cas, une gestion rigoureuse des permissions IAM est nécessaire pour assurer la sécurité de la landing zone.

Mon conseil : commencez par un service clé comme AWS Config ou AWS CloudFormation StackSets, maîtrisez le concept, puis étendez progressivement à d'autres services. La route vers une gouvernance cloud optimale est un marathon, pas un sprint. Investissez dans la planification et l'automatisation, et vous récolterez les fruits d'un environnement AWS bien géré et sécurisé.