L’Identity and Access Management, ou gestion des identités et des accès, apporte des réponses à la question fondamentale de DevOps : « Qui peut accéder à quoi ? ». Encore faut-il en maîtriser les bonnes pratiques de l’IAM…

Les racines de l’IAM remontent aux premiers jours de l’informatique, à l’époque 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 à leurs fichiers. À mesure que les systèmes devenaient plus complexes, que leur nombre augmentait et que de plus grands groupes d’utilisateurs avaient besoin d’un accès, les solutions de gestion des identités telles que le protocole LDAP (Lightweight Directory Access Protocol) sont devenues de plus en plus populaires, permettant à une équipe centrale de gérer l’accès de plusieurs départements et rôles.

La révolution du DevOps a ajouté une nouvelle couche de complexité à la gestion des accès. En effet, des entités non humaines devaient également avoir accès aux données et aux systèmes. Ces non-humains comprenaient aussi bien des applications sur la même plateforme que des systèmes tiers, ce qui rendait les choses encore plus complexes.

Bien qu’elle soit communément associée à AWS et à son service AWS IAM, la gestion des accès n’est pas limitée à sa plateforme. Tous les fournisseurs de cloud proposent des solutions IAM qui permettent aux utilisateurs d’accéder aux ressources et aux systèmes. Il existe des pratiques génériques, performantes, qui ont évolué au cours de la dernière décennie autour de chaque partie de la question de base « qui peut accéder à quoi ? »:

Qui : les humains et les entités non humaines (applications et travailleurs machine).

Peut accéder : ensembles de permissions

Quoi : ressources et systèmes

Avec l’IAM le « Qui » représente les « utilisateurs » dans IAM. Deux grands groupes « d’utilisateurs » sont concernés par 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 des environnements DevOps. Les services d’IAM  permettent de créer des utilisateurs spécifiques, pour des rôles spécifiques, et de leur attribuer les autorisations nécessaires. Il ne s’agit pas de comptes distincts mais simplement d’utilisateurs sous un seul compte. Les entités non-humaines, aussi communément appelées identités machine, sont des systèmes, API, plateformes ou services, qui doivent pouvoir se connecter et interagir avec le pipeline CI/CD. Les systèmes IAM peuvent accorder à ces entités l’accès dont elles ont besoin et le circonscrire étroitement pour n’autoriser qu’un accès spécifique dans les bonnes conditions.

Accès zero-trust ou de 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 par n’avoir aucun accès, puis se voir accorder uniquement les autorisations qui lui permettront d’accomplir son travail, mais rien de plus. C’est ce que nous entendons par zero-trust. Par défaut, la plupart des fournisseurs de cloud computing utilisent ce modèle, de sorte que tout nouvel utilisateur commence avec des autorisations nulles. Ce n’est qu’après s’être vu attribuer un rôle ou des autorisations spécifiques qu’il pourra accéder à des ressources.

Une approche graduelle des autorisations

Tout le monde devrait se pencher sur la confiance zéro, dite Zero Trust.  Il est important d’équilibrer les restrictions d’accès avec les besoins réels de l’entreprise. Une bonne façon d’y penser est de délimiter l’accès en fonction de la maturité ou de l’avancement d’un projet.

Par exemple, dans le cas de recherches préliminaires sur un nouveau produit ou une nouvelle application, il peut s’avérer nécessaire d’accorder à un utilisateur un accès illimité pour parvenir à un produit minimum viable (MVP). Dans ce cas, il serait judicieux de créer un tout nouveau compte dédié au projet et isolé de l’infrastructure de production. À mesure que le projet progresse vers la production, des restrictions d’accès supplémentaires peuvent être appliquées et affinées, n’autorisant que l’accès nécessaire pour finaliser l’application. Enfin, au moment du lancement, les autorisations peuvent être mises en conformité avec les politiques et les meilleures pratiques de l’entreprise.

Fournisseurs d’identité et justificatifs d’identité temporaires

Pour les utilisateurs humains, les meilleurs droits d’accès sont de courte durée. Lorsque l’on utilise 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 qui est donc pratiquement impossible à divulguer. Cette approche présente d’autres avantages, comme par exemple :

  • Une gestion d’utilisateurs centralisée et facile
  • Une réduction de la fatigue liée aux mots de passe grâce à leur rotation constante
  • Une diminution du nombre de systèmes à sécuriser dans l’ensemble
  • Un gestionnaire d’identifiants centralisé plus simple à sécuriser et à auditer.

Utilisateurs Root

Il existe un type spécial d’utilisateur humain dans IAM qui contrôle le compte d’une organisation sur un fournisseur de cloud computing : Root, également connu sous le nom de Super Administrateur. Ces utilisateurs sont en fin de compte responsables du provisionnement de l’accès, des ressources et de la facturation. Ces comptes sont extrêmement puissants et doivent être utilisés avec prudence.

Il est préférable d’éviter d’utiliser les informations d’identification root et de plutôt créer des utilisateurs uniques pour effectuer des tâches spécifiques. Certains fournisseurs permettent d’empêcher les utilisateurs root de gérer ou de travailler avec certains processus, ce qui garantit que ces comptes spéciaux et puissants restent protégés. Les comptes root, nécessitant des mots de passe à longue durée de vie, doivent être complexes et bien protégés. D’ailleurs, il est vivement recommandé d’utiliser un gestionnaire de mots de passe combiné à une authentification multifactorielle. La MFA consiste à combiner une information connue, comme un mot de passe, avec un élément que l’utilisateur possède, comme un mot de passe à usage unique (OTP) ou, mieux encore, un jeton matériel. Une autre approche consiste à créer des mots de passe très longs et complexes, mais il ne faut jamais les stocker après la connexion, et s’appuyer sur la réinitialisation du mot de passe chaque fois qu’un accès est nécessaire. Il est vital pour les entreprises de veiller à ce que les informations d’identification d’un utilisateur root n’apparaissent jamais dans le code ou la configuration. En fait, la meilleure pratique consiste à ne jamais utiliser une clé d’accès d’utilisateur root et, mieux encore, à la supprimer. Cette mesure peut sembler radicale, mais elle présente deux avantages : elle limite les vecteurs par lesquels le compte peut être compromis (ne pas oublier que ce compte dispose de tous les privilèges d’administration !) et elle oblige à créer des comptes basés sur des rôles avec des privilèges restreints.

La confiance, c’est bien, mais la vérification, c’est mieux. Il faut utiliser donc un outil de détection de secrets pour rechercher les secrets dans tous les dépôts afin de vérifier qu’aucune information d’identification root ne se trouve dans son périmètre. Les développeurs peuvent également utiliser ggshield pour s’assurer que de telles informations d’identification collées accidentellement dans un fichier ne se retrouvent jamais dans un commit ou ne sont pas poussées vers les dépôts partagés.

Protéger le chemin de récupération des informations d’identification

Il est indispensable de veiller à sécuriser également le flux de récupération des informations d’identification root. Malheureusement, les tentatives d’hameçonnage visant à réinitialiser les mots de passe au niveau de l’administrateur se sont multipliées ces derniers temps.

L’élément important de toute stratégie de réinitialisation de mot de passe est donc l’application de la 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 à ces informations d’identification très prisées et puissantes. Si les acteurs malveillants ne connaissent pas ou ne peuvent pas deviner les adresses électroniques associées à vos utilisateurs principaux, il leur sera d’autant plus difficile de lancer une attaque.

S’assurer que la 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, il est à supprimer du système. Régulièrement des vérifications à propos des utilisateurs sont à faire pour voir s’ils sont toujours actifs et se comportent comme prévu. Si une entreprise découvre qu’un utilisateur inconnu accède à ses ressources, une réunion est à organiser en urgence avec l’équipe de sécurité.

Accès possible – Permissions dans IAM

La deuxième partie de l’équation IAM, « qui peut accéder à quoi ? », est la définition des permissions. Ces dernières peuvent être gérées par utilisateur ou par rôle.

Il peut parfois être nécessaire de définir des autorisations pour des comptes d’utilisateurs à longue durée de vie, mais cela signifie qu’il faut surveiller et gérer les autorisations de chacun de ces utilisateurs au fil du temps. Cela signifie également qu’il faut suivre quelles personnes ont quelles autorisations afin d’éviter les chevauchements ou les erreurs de configuration.

L’autre voie à utiliser pour les autorisations est la création de rôles. Ils peuvent se voir attribuer un nombre quelconque d’autorisations. Cette approche facilite grandement la gestion des ensembles d’autorisations à grande échelle et permet de voir rapidement qui a accès à chaque rôle. Si une nouvelle ressource est ajoutée à la configuration, il faut rapidement ajouter les autorisations nécessaires à toute personne ayant un rôle plutôt que de définir des autorisations pour chaque utilisateur. La révocation générale de l’accès à un service est également beaucoup plus rapide.

Utiliser des conditions pour restreindre davantage les accès inattendus

Lorsqu’une politique est définie, une entreprise peut utiliser des conditions pour restreindre encore plus les droits d’accès. Ces conditions sont des contrôles détaillés permettant de définir des circonstances spécifiques pour autoriser les permissions. Elles peuvent être considérer comme des déclarations « mais, seulement si ».

Par exemple :

* Accorder l’accès aux ressources, MAIS SEULEMENT SI la demande d’accès provient d’un sous-réseau spécifique et dans une plage d’IP spécifique.
* Accorder l’accès aux ressources, MAIS SEULEMENT 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 la création d’une fonction Google Cloud, MAIS UNIQUEMENT si elle est installée dans un VPC spécifique.

Bien que toutes les plateformes de cloud diffèrent légèrement dans leurs spécificités de mise en œuvre, toutes prennent en charge les conditions de mise en œuvre.

Ressources et services dans IAM

Enfin, la dernière pièce du puzzle IAM « qui peut accéder à quoi ? » concerne les ressources et les services auxquels un utilisateur peut accéder.

Dans le cas où “l’utilisateur » est une entité non humaine, il peut être considérer comme une « ressource qui peut accéder à une ressource ». Heureusement, si l’entreprise a géré correctement l’authentification et les autorisations des utilisateurs, elle n’aura pas besoin de se préoccuper de cette partie.

Il existe essentiellement deux types de services : les systèmes sur la même plateforme et les services tiers qui existent en dehors de la plateforme. Dans certains cas rares où une équipe a construit son propre cloud privé, il se peut qu’il n’y ait pas du tout d’applications « sur la plateforme ».

Le périmètre de données

Une bonne façon d’envisager les ressources et les services est de penser qu’ils existent à l’intérieur ou à l’extérieur du « périmètre de données« , qu’il est possible de définir comme la frontière entre les applications et le reste de l’Internet. Si une ressource se trouve en dehors du périmètre de données, l’accès doit être refusé. De même, si quelqu’un de l’extérieur de ce périmètre tente d’accéder à un service de confiance, l’accès doit également être refusé et des signaux d’alarme doivent être déclenchés.

Pour les systèmes sur la même plateforme, il est généralement possible de compter sur le service de fournisseur d’identité pour s’assurer qu’il s’agit d’une ressource de confiance. Même s’il se trouve dans le compte de l’entreprise, il est toujours bon de définir des conditions pour s’assurer que seuls les utilisateurs prévus peuvent avoir accès à un service.

Pour les applications tierces, il est toujours tentant d’intégrer rapidement les informations d’accès dans la configuration… mais il ne faut pas le faire. C’est l’un des principaux chemins utilisés par les attaquants pour s’étendre latéralement lors d’une brèche, et parfois, c’est l’origine d’une brèche. Au lieu de cela, pour en faire des ressources de confiance. Il existe des outils comme Hashicorp Vault pour stocker toutes les informations d’identification. Ou, mieux encore, des services d’autorité de certification peuvent être intégrés, pour s’authentifier automatiquement via des certificats générés et gérés automatiquement.

Tirer parti des outils pour optimiser les configurations IAM

Les fournisseurs de cloud computing veulent faire appliquer les meilleures politiques de sécurité possibles. Il s’agit d’outils gratuits qui peuvent aider les entreprises à comprendre leurs paramètres actuels et à les affiner. Les analyseurs IAM peuvent montrer qui dispose de quelles autorisations et, tout aussi important, quelles autorisations n’ont pas été utilisées. Toute autorisation non utilisée doit être révoquée pour éviter les abus. Elles ne devraient pas être oubliées puisqu’elles n’étaient pas nécessaires pour le travail à effectuer. Outre la simple analyse des autorisations existantes, ces outils peuvent également suggérer des ensembles d’autorisations optimaux pour une situation donnée. Ils peuvent également valider les paramètres. Quel que soit le fournisseur choisi, il faut se renseigner pour connaître les meilleures pratiques et les outils qui peuvent aider à rester en sécurité.

Les meilleures pratiques IAM dans le temps

Pour de nombreuses organisations, la dernière fois que l’IAM a fait l’objet d’une discussion ou même d’une réflexion, c’était lors de sa première mise en œuvre. Si c’est le cas d’une entreprise, il est probablement temps pour elle de repenser ses autorisations et de répondre à la question : « Qui peut accéder à quoi ? ».

Bien qu’il n’existe pas de réponse unique à cette question, tous les fournisseurs de cloud computing s’accordent à dire qu’il faut être en mesure d’y répondre.

Les meilleurs conseils sur la gestion de l’IAM à garder en tête :

Qui :

* Utiliser des gestionnaires d’identité pour authentifier les utilisateurs.
* Créer des utilisateurs pour des tâches spécifiques avec des permissions nulles par défaut.
* Ne jamais utiliser de comptes root pour les tâches quotidiennes et supprimer les clés d’accès inutilisées.
* Lorsque des informations d’identification à long terme sont utilisées, il faut s’assurer qu’elles sont protégées ainsi que leur chemin de récupération.
* Appliquer le MFA partout.

Peut accéder :

* Utiliser les rôles pour gérer les ensembles d’autorisations, en attribuant aux utilisateurs des rôles plutôt que des autorisations.
* Penser au modèle EPARC lors de l’attribution des autorisations.
* Utilise les conditions « mais seulement si » pour affiner les autorisations.
* Utilise les outils d’analyse d’IAM pour vérifier et affiner régulièrement les autorisations.

A Quoi :

* Penser en termes de périmètre de données ; seules les identités de confiance accèdent aux ressources de confiance à partir des emplacements prévus.
* N’intégrer jamais d’informations d’identification dans les fichiers de configuration.
* Intégrer des services de certification chaque fois que possible

Dans le cheminement d’une entreprise vers des pratiques IAM plus sécurisées, celle-ci doit aussi s’assurer de s’attaquer aussi à la prolifération des secrets tout en adoptant de meilleures pratiques de sécurité.
____________________________

Par Dwayne McDaniel, Security Advocate chez GitGuardian

 

À lire également :

Sécurité des pipelines CI/CD : le casse-tête des DevOps

Développeurs, savez-vous garder un secret ?

Sécurité applicative : le nouveau segment de la détection de secrets

Pipelines de CI : 5 risques à évaluer

Comment sélectionner votre future solution IDentity-as-a-Service ?

Des comptes aux identités : la cybersécurité dans le monde réel…