IAM signifie « Gestion des identités et des accès ». L’IAM apporte des réponses à la question fondamentale du DevOps : « Qui peut accéder à quoi ? »
Les racines d’IAM remontent aux débuts de l’informatique, où les utilisateurs de systèmes UNIX avaient besoin d’un nom d’utilisateur et d’un mot de passe pour accéder à leurs comptes et fichiers. Au fur et à mesure que les systèmes devenaient plus complexes, augmentaient en nombre et que de plus grands groupes d’utilisateurs avaient besoin d’un accès, les solutions de gestion des identités telles que LDAP, LDAP, sont devenues de plus en plus populaires, où une équipe centrale pouvait gérer l’accès pour plusieurs services et rôles.
La révolution de DevOps a ajouté une nouvelle couche de complexité à la gestion des accès ; les entités non humaines avaient également besoin d’accéder aux données et aux systèmes. Ces non-humains incluaient à la fois des applications sur la même plate-forme ainsi que des systèmes tiers, ce qui rendait les choses encore plus complexes.
Bien qu’il soit généralement associé à AWS et à son service AWS IAM, IAM ne se limite pas à sa plate-forme. Tous les fournisseurs de cloud, tels que Google Cloud et Azure DevOps, proposent des solutions IAM qui permettent aux utilisateurs d’accéder aux ressources et aux systèmes.
Pour le reste de cet article, nous examinerons les meilleures pratiques génériques qui ont évolué au cours de la dernière décennie autour de chaque partie de la question de base avec laquelle nous avons commencé : « Qui peut accéder à quoi ? » :
- OMS: Entités humaines et non humaines (applications et machine workers)
- Peut accéder: ensembles d’autorisations
- Quoi: ressources et systèmes
Qui : Utilisateurs dans IAM
Il y a deux grands groupes qui nous intéressent dans l’IAM : les humains et les non-humains.
Les humains sont généralement des développeurs, des ingénieurs, des analystes ou toute autre personne ayant besoin d’accéder aux données et aux ressources de vos environnements DevOps. Les services IAM vous permettent de créer des utilisateurs spécifiques pour des rôles spécifiques et de leur attribuer les autorisations nécessaires. Ce ne sont pas des comptes séparés mais juste des utilisateurs sous un seul compte.
Les entités non humaines, également appelées identités de machine, sont tout système, API, plate-forme ou service qui doit pouvoir se connecter et interagir avec votre pipeline CI/CD. Les systèmes IAM peuvent accorder à ces entités l’accès dont elles ont besoin et l’étendre étroitement uniquement pour autoriser un accès spécifique dans les bonnes conditions. Nous approfondirons ce type d’accès plus loin dans la section ressources et services.
Accès zéro confiance ou moindre privilège
Quel que soit le type d’utilisateur, le principe du moindre privilège doit toujours être appliqué. Tout nouvel utilisateur créé ou approuvé doit commencer sans aucun accès, puis ne se voir accorder que des autorisations qui lui permettront d’accomplir son travail, mais rien de plus. C’est ce que nous entendons par zéro confiance.
Par défaut, la plupart des fournisseurs de cloud utilisent ce modèle afin que tout nouvel utilisateur démarre avec zéro autorisation. Ce n’est qu’une fois attribué un rôle ou des autorisations spécifiques qu’ils pourront accéder à toutes les ressources.
Une approche par étapes des autorisations
Bien que nous estimions que tout le monde devrait se tourner vers Zero-Trust, il est également important d’équilibrer la restriction d’accès avec les besoins commerciaux réels. Une bonne façon d’y penser est de définir l’accès en fonction de la maturité ou de l’avancement d’un projet.
Par exemple, pour la recherche à un stade précoce d’un nouveau produit ou d’une nouvelle application, il peut être nécessaire de donner à un utilisateur un accès illimité pour accéder efficacement à un produit minimum viable, MVP. Il serait alors judicieux de créer un tout nouveau compte dédié au projet et isolé de votre infrastructure de production. Au fur et à mesure que le projet progresse vers la production, des restrictions d’accès supplémentaires peuvent être appliquées et ajustées, n’autorisant que l’accès nécessaire pour finaliser l’application. Enfin, une fois lancées, les autorisations peuvent être alignées sur les politiques et les meilleures pratiques existantes de l’entreprise.
Fournisseurs d’identité et informations d’identification temporaires
Pour les utilisateurs humains, les meilleures informations d’identification sont de courte durée et celles qu’aucun humain ne voit ou ne connaît jamais. Ceci est tout à fait réalisable grâce à des fournisseurs d’identité tels qu’AWS IAM Identity Center ou Google Cloud Identity. Vous pouvez également synchroniser une source d’identification externe fiable telle que Okta Universal Directory, Microsoft Active Domain ou tout système open source basé sur SAML pour obtenir le même résultat.
Lors de l’utilisation d’un fournisseur d’identité, tout utilisateur s’authentifie auprès de son service d’identité et reçoit ensuite un jeton ou un certificat à court terme qui n’est jamais exposé aux utilisateurs et, par conséquent, presque impossible à fuir. Il y a quelques avantages supplémentaires à cette approche, tels que :
- Magasins d’utilisateurs centralisés faciles à gérer
- Réduction de la fatigue des mots de passe grâce à la rotation constante des mots de passe
- Une diminution du nombre de systèmes à sécuriser globalement
- Un gestionnaire d’ID centralisé plus simple à sécuriser et à auditer
Utilisateurs racine
Il existe un type particulier d’utilisateur humain dans IAM qui contrôle le compte d’une organisation sur un fournisseur de cloud : Root, également appelé super administrateur. Ces utilisateurs sont ultimement responsables de l’accès, des ressources et de la facturation. Ce sont des comptes extrêmement puissants et doivent être utilisés avec prudence.
C’est une très bonne idée d’éviter d’utiliser du tout les informations d’identification root. Au lieu de cela, créez des utilisateurs uniques pour effectuer des tâches spécifiques. Certains fournisseurs, comme AWS, vous permettent d’empêcher les utilisateurs root de gérer ou de travailler avec certains processus, garantissant ainsi que ces comptes spéciaux et puissants restent protégés.
Étant donné que les comptes root nécessitent nécessairement des mots de passe à longue durée de vie, il est essentiel de créer des mots de passe complexes à haute entropie et de les protéger. Nous vous recommandons fortement d’utiliser un gestionnaire de mots de passe comme LastPass ou 1Password. Combiné avec l’authentification multifacteur, MFA. MFA signifie avoir quelque chose que vous connaissez, comme un mot de passe, combiné avec quelque chose que vous avez, comme un mot de passe à usage unique Google Authenticator, OTP ou, mieux encore, un jeton matériel.
Une autre approche consiste à créer des mots de passe très longs et complexes, mais à ne jamais les stocker n’importe où après la connexion, en s’appuyant plutôt sur des réinitialisations de mot de passe chaque fois qu’un accès est nécessaire.
Il est vital pour votre entreprise de s’assurer que les informations d’identification de longue durée d’un utilisateur root n’apparaissent jamais dans votre code ou votre configuration, où que ce soit. En fait, la meilleure pratique consiste à jamais utilisez votre clé d’accès utilisateur root et, encore mieux, supprime-le. Bien que cela puisse sembler radical, cela présente deux avantages intéressants : cela limite les vecteurs par lesquels le compte peut être compromis (rappelez-vous, ce compte a des privilèges d’administration complets !) et cela force la création de comptes basés sur les rôles avec des privilèges restreints.
La confiance c’est bien, mais vérifier c’est mieux.
Protégez le chemin de récupération des informations d’identification
Assurez-vous également de sécuriser le flux de récupération des informations d’identification racine. Malheureusement, il y a eu récemment une augmentation constante des tentatives de phishing ciblant les réinitialisations de mot de passe au niveau de l’administrateur. Les attaquants savent que c’est un bon moyen d’essayer de voler les identifiants de connexion.
Un élément important de toute stratégie de réinitialisation de mot de passe est l’application de MFA pour tous les comptes de messagerie utilisés pour la récupération. Une autre stratégie consiste à créer des comptes de messagerie dédiés pour ces informations d’identification très prisées et puissantes. Si les acteurs malveillants ne connaissent pas ou ne peuvent pas deviner les adresses e-mail associées de vos utilisateurs root, il leur sera d’autant plus difficile de lancer une attaque.
Assurez-vous que votre liste d’utilisateurs est exacte et à jour
L’utilisateur le plus facile à administrer est celui qui n’existe pas. Dès qu’un utilisateur n’est plus nécessaire, supprimez-le du système. Assurez-vous d’auditer régulièrement les utilisateurs pour voir s’ils sont toujours actifs et se comportent comme prévu. Si jamais vous découvrez qu’un utilisateur que vous ne reconnaissez pas accède à vos ressources, il est probablement temps d’avoir une conversation avec votre équipe de sécurité.
Peut accéder — Autorisations dans IAM
La deuxième partie de l’équation IAM, « qui peut accéder à quoi ? » définit les autorisations. Les autorisations peuvent être gérées par utilisateur ou par rôle.
La définition d’autorisations pour les comptes d’utilisateurs de longue durée peut parfois être nécessaire, mais cela signifie que vous devrez surveiller et gérer chacune des autorisations de ces utilisateurs au fil du temps. Cela signifie également que vous devrez suivre quelles personnes ont quelles autorisations pour éviter les chevauchements ou les erreurs de configuration.
L’autre chemin que vous pouvez utiliser pour les autorisations est la création de rôles. Les rôles peuvent se voir attribuer n’importe quel nombre d’autorisations, puis vous pouvez attribuer ces rôles aux utilisateurs. Cette approche facilite la gestion des ensembles d’autorisations à plus grande échelle et permet de voir rapidement qui a accès à chaque rôle. Si une nouvelle ressource est ajoutée à votre configuration, vous pouvez rapidement ajouter les autorisations nécessaires à toute personne ayant un rôle plutôt que de définir des autorisations utilisateur individuelles. Cela permet également de révoquer largement l’accès à un service beaucoup plus rapidement.
Le modèle AWS EPARC
Bien que IAM soit proposé par divers fournisseurs, il peut être utile d’examiner de plus près le modèle qu’AWS utilise pour sa structure d’autorisation, EPARC :
- Effet — que doit-il se passer si l’autorisation est accordée
- Principe — l’utilisateur ou le travailleur de la machine dont l’accès est autorisé ou refusé
- Action — ce qui sera fait si l’accès est autorisé ou refusé
- Ressource — le service ou les données à accéder
- Condition — les conditions dans lesquelles l’accès peut être accordé
Si vous pouvez fournir et comprendre toutes les informations nécessaires pour satisfaire au modèle EPARC, vous êtes alors en bonne position pour définir une politique.
Utiliser des conditions pour restreindre davantage l’accès inattendu
Lors de la définition d’une stratégie, vous pouvez utiliser des conditions pour restreindre davantage les droits d’accès. Les conditions sont des contrôles précis permettant de définir des circonstances spécifiques pour autoriser les autorisations. Vous pouvez les considérer comme des déclarations « mais, seulement si ». Par exemple:
- Accorder l’accès aux ressources, MAIS UNIQUEMENT SI la demande d’accès provient d’un sous-réseau spécifique et dans une plage d’adresses IP spécifique
- Accorder l’accès aux ressources, MAIS UNIQUEMENT SI la demande d’accès commence par un préfixe spécifique
- Autoriser la création d’une fonction AWS Lambda, MAIS UNIQUEMENT SI vous utilisez AWS CloudFormation
- Autoriser une fonction Google Cloud, MAIS UNIQUEMENT SI elle résidera dans un VPC spécifique
Bien que toutes les plates-formes cloud diffèrent légèrement dans les spécificités de mise en œuvre, toutes prennent en charge les conditions de mise en œuvre.
Quoi : ressources et services en IAM
Enfin, la dernière pièce de l’IAM « qui peut accéder à quoi ? » puzzle est les ressources et les services auxquels un utilisateur peut accéder. Dans le cas où « l’utilisateur » est une entité non humaine, vous pouvez le considérer comme une « ressource pouvant accéder à une ressource ». Heureusement, si…