Introduction

Que vous soyez développeurs, devops ou utilisateurs ayant déjà interagi avec les cloud AWS ou Azure, vous avez surement déjà lu la mention “Operation forbidden”. Le début des contrariétés de la gestion des permissions et des identités dans le cloud. Cela n’a pas été simplifié par les différentes identités, rôles et services que l’on doit gérer lorsque nous devons octroyer des autorisations à une ressource ou à un utilisateur.

La capacité à gérer les identités et les accès touche tant à la sécurité qu’à l’administration des utilisateurs. Indépendamment de la notion de cloud, c’est un prérequis pour protéger l’accès aux données. Sa raison étant bien définie, nous démystifierons les solutions proposées par les clouds Amazon Web Service et Microsoft Azure dans cet article.

AWS

Pourquoi gérer les identités et les accès dans le cloud ?

La responsabilité du cloud revient aux fournisseurs tandis que la responsabilité dans le cloud revient aux utilisateurs. En d’autres termes nous nous devons de protéger peu importe le type de déploiement :

  • Les données,
  • Les points de terminaison
  • Le réseau
  • Le compte chez le fournisseur cloud
  • La gestion des accès

Tous ces éléments sont administrés à partir de l’interface utilisateur, de l’invite de commande, de l’API ou des différents outils mis à votre disposition dans votre compte par le fournisseur de cloud. Il vous incombe donc de gérer les autorisations des utilisateurs pour les différents services dont vous avez besoin. En l’absence de configurations adéquates, les utilisateurs pourraient apporter des modifications à des ressources sensibles, ce qui pourrait avoir un impact sur les applications et entraîner des coûts supplémentaires pour l’entreprise.

Les organisations se retrouvent avec la pression d’assurer la sécurité de leurs données. Cette pression doit être contenue en respectant les normes de sécurité tout en assurant les accès requis aux utilisateurs. Les tiers parties telles que les développeurs, les administrateurs ou les experts métiers doivent pouvoir remplir leur rôle dans la limite de leur fonction. En respectant le principe du least privilege (Principe de moindre privilège).

Par exemple un membre de l’équipe a besoin de récupérer des fichiers depuis un stockage cloud, n’a pas la nécessité d’avoir des permissions Administrateur sur le compte.  Ainsi qu’une application faisant des appels à des services cloud doit être limitée dans ses autorisations, au cas où le code en lui-même ne l’est pas.

Les enjeux liés aux identités et aux accès englobent à la fois l’authentification et l’autorisation. Ces enjeux ont des répercussions significatives et sous-tendent l’existence des différents services proposés par tous les fournisseurs de cloud. En effet, la gestion efficace des identités et des accès est essentielle pour assurer la sécurité des données et des ressources dans un environnement cloud, tout en permettant aux utilisateurs d’accéder aux services dont ils ont besoin de manière sécurisée et contrôlée.

## Quelles sont les solutions d’identités dans le cloud ?

Le modèle de responsabilité partagée régit les responsabilités qui incombent à la fois aux fournisseurs de cloud et aux utilisateurs. Les interactions avec les services de votre compte de gestion, que ce soit sur AWS ou Azure, se font principalement par :

  • Console de gestion : AWS Management Console ou Azure portal
  • Interface de ligne de commande (CLI) : aws cli ou azure cli et leurs plugins
  • Kit de développement logiciel (SDK)
  • Interface de programmation d’application (API)

Ces communications avec votre compte nécessitent une protection adéquate. Chacune d’entre elles doit passer par le processus d’authentification, par lequel le fournisseur de cloud vérifie l’identité d’un utilisateur ou d’un service. Une fois que la légitimité de l’entité à interagir avec le compte est confirmée, ces communications sont soumises au processus d’autorisation. Celui-ci consiste à accorder à l’entité authentifiée les permissions nécessaires pour effectuer une action ou interagir avec une ressource spécifique.

Dans Amazon Web Service ces fonctionnalités de contrôle d’accès sont gérées avec le service AWS Identity and Access Management (IAM) et dans Azure avec Azure Active Directory devenu Microsoft Entra.

AWS Identity and Access Management

AWS assure la gestion des identités et des accès grâce au service AWS Identity and Access Management (IAM), qui permet de contrôler qui peut faire quoi sur les ressources AWS. AWS IAM offre une gestion centralisée des identités qui s’authentifient et des autorisations d’accès aux ressources. Il définit des permissions d’accès granulaires, résolvant ainsi les questions suivantes :

  • Qui peut accéder aux ressources
  • Quelle ressource est accessible et que peut faire l’utilisateur sur la ressource
  • Comment les ressources peuvent être accessibles

Les différentes solutions proposées par AWS IAM répondent à ces questions en intégrant des fonctionnalités d’implémentation dans son API et son interface. Ce service est accessible aux utilisateurs via le SDK, l’interface AWS et l’API du AWS CLI, offrant ainsi une flexibilité et une facilité d’utilisation pour gérer les identités et les accès aux ressources AWS.

AWS IAM : les principales d’identités

AWS IAM gère les utilisateurs et les identités autorisés à effectuer des actions sur les ressources du compte en tant que principaux d’identité. Ce sont ces entités que AWS IAM utilise pour l’authentification et la gestion des autorisations d’accès. Les identités sont les éléments fondamentaux de AWS IAM, et la ressource d’identité de base est l’utilisateur IAM. Un utilisateur IAM représente une personne ou une application pouvant s’authentifier dans un compte AWS et à qui des autorisations spécifiques peuvent être accordées.

Au quotidien, il est courant que plusieurs utilisateurs partagent les mêmes autorisations sur les mêmes ressources. Par exemple, plusieurs développeurs peuvent être autorisés à créer des machines virtuelles ou à accéder au stockage S3, ce qui leur confère des permissions similaires. Cependant, lorsqu’il s’agit d’une équipe composée de plusieurs dizaines voire centaines de développeurs, l’attribution individuelle des autorisations devient fastidieuse et redondante. C’est là qu’intervient AWS IAM avec les IAM groups : une collection d’utilisateurs IAM partageant le même ensemble d’autorisations. Les IAM groups simplifient la gestion des autorisations en permettant de les attribuer à un ensemble d’utilisateurs plutôt qu’à chacun individuellement.

Les autorisations sont attribuées aux groupes et aux utilisateurs à l’aide de fichiers de définition des autorisations, appelés stratégies ou politiques IAM (IAM Policy). Ces politiques IAM représentent l’élément central de la gestion des permissions dans AWS IAM. Elles définissent les actions autorisées ou interdites sur les ressources AWS pour les utilisateurs et les groupes, offrant ainsi un contrôle précis sur l’accès aux différentes fonctionnalités et services d’AWS.

Les stratégies IAM sont généralement définies dans des fichiers au format JSON, et elles peuvent être de deux types principaux : les stratégies gérées par AWS et les stratégies en ligne définies par l’utilisateur. Les stratégies gérées sont créées et gérées par AWS, définissant ainsi un ensemble d’autorisations pour un utilisateur ou un groupe. Ces stratégies sont prédéfinies et ne peuvent pas être modifiées par les utilisateurs. En revanche, les stratégies définies par l’utilisateur peuvent être créées, modifiées et attachées à plusieurs utilisateurs. Enfin, les stratégies en ligne sont spécifiquement créées pour un principal d’identité lors de sa création, et elles ne peuvent être attachées à aucune autre ressource que celle pour laquelle elles ont été créées.

Quel est l’intérêt d’AWS IAM ?

AWS

Activation de la MFA pour une sécurité renforcée

Outre l’authentification classique par la création d’un utilisateur IAM, IAM renforce la sécurité grâce à l’activation de la MFA (authentification multi-facteur). Cette fonctionnalité exige que les utilisateurs fournissent deux moyens d’identification distincts pour accéder à leur compte AWS, ce qui augmente considérablement la sécurité. Chaque utilisateur peut associer jusqu’à huit (8) dispositifs MFA à son compte AWS, offrant ainsi une protection supplémentaire contre les accès non autorisés.

Gestion des identités pour une sécurité accrue

Le véritable intérêt réside dans les identités attachées aux ressources AWS. Par exemple, une application de gestion des paies peut s’exécuter sur une instance de machine virtuelle EC2 et stocker ses données sur le stockage S3, accessible par le service comptabilité. Dans ce scénario, l’application dépose les fiches de paie dans un compartiment AWS S3. Pour cela, l’instance de calcul doit disposer des autorisations nécessaires pour accéder au service Amazon S3. C’est un exemple concret illustrant la nécessité de gérer efficacement les autorisations et les identités dans un environnement AWS.

Gestion sécurisée des accès pour les applications déployées

Si nous déployons notre application sur une instance EC2, le backend développé avec le SDK AWS en Node.js doit être autorisé à appeler l’API d’AWS S3 pour interagir avec les fichiers stockés. AWS propose une solution pratique pour cela : les “Instances profiles”. Ces derniers fournissent des clés de connexion temporaires à l’instance EC2, que les applications exécutées sur celle-ci peuvent utiliser pour accéder aux services AWS. Un “instance profile” est simplement l’association d’un rôle IAM avec les permissions nécessaires, et ce rôle est ensuite associé à l’instance EC2 via l’instance profile. Cette approche permet d’attribuer le même rôle à plusieurs instances, avec des clés de connexion distinctes, et ces clés sont automatiquement mises à jour, assurant ainsi la sécurité des accès.

Gestion centralisée des autorisations avec IAM

Si notre application est conteneurisée et bénéficie de l’orchestration d’AWS ECS, IAM joue également un rôle crucial dans la sécurisation de ses accès. Un “IAM execution role” est utilisé pour autoriser les agents de conteneur à effectuer des appels API pour tous les conteneurs du cluster, leur accordant ainsi les mêmes permissions. Cependant, certaines tâches peuvent nécessiter des interactions spécifiques avec des services comme AWS SQS. Pour cela, nous pouvons attribuer des autorisations spécifiques à chaque tâche en utilisant un “IAM task role”, permettant ainsi à chaque tâche d’avoir ses propres permissions distinctes en fonction de ses besoins.

En tant que fonctionnalité la plus reconnue, IAM prend en charge la gestion des autorisations des utilisateurs au sein du compte AWS. Tout comme les “instance profiles”, il facilite l’autorisation des interactions entre les différentes ressources, le tout grâce aux politiques d’accès définies.

Définition de politiques pour une gestion fine des accès

Les politiques basées sur l’identité, qui sont associées à un principal d’identité, définissent les actions que ce dernier est autorisé à effectuer. Quant aux politiques basées sur les ressources, qui reposent sur le principe du RBAC (Contrôle d’accès basé sur les ressources), elles définissent les actions qu’elles autorisent pour un principal en fonction de conditions spécifiques. Ces politiques sont directement liées aux ressources concernées.

Best practices AWS

La théorie est bien belle mais en pratique l’administration d’accès IAM peut être un métier à lui seul. AWS propose ses recommandations et de nombreux principes s’insèrent dans les bonnes pratiques.

L’utilisation des clés d’authentification temporaires au travers de l’IAM rôle est essentiel. Vous donnez les permissions nécessaires dont les clés ne sont ni accessibles directement ni utilisables intemporellement. Il y a moins de risques de corruption de clés d’accès.

En utilisant ces rôles et les politiques le principe du least-privilege permission en définissant des permissions réduites. Limités sur les ressources, les permissions augmentent au besoin sans donner tous les accès aux ressources. Il y a moins de risque d’accident de suppression ou d’actions non autorisées car il tient compte du principal autorisé.

Une autre recommandation est l’utilisation du MFA pour les utilisateurs.

Les charges de calcul ne sont pas laissées pour compte avec les instances profiles, les task role, les task execution roles, les IAM Service Account pour AWS EKS.

Dans notre exploration de l’univers du cloud nous implémenterons ensemble une ou plusieurs solutions d’identifications dans un prochain épisode.