Introduction à IAM (Identity and Access Management) – Utilisateurs, Groupes, Rôles et Principes de moindre privilège.

Section Un peu de théorie

Cette section est probablement la section la plus importante de tout le cours, on va donc aborder un sujet complexe et ultra central au sein du cloud IAM (Identity and Access Management) en gros qui peut faire quoi et comment ?

Elle va définir tout l'accès à vos services dans le provider cloud (GCP dans notre cas) et le fait d'avoir une mauvaise posture à cet égard peut entraîner des désastres au sein de votre plateforme.

Imaginez donner des droits Administrateur à n'importe qui sur la plateforme, ou encore laisser n'importe qui pouvoir avoir accès en écriture et lecture à une base de données ? Cela serait compromettre un fondement même du cloud que l'on appelle le principe de moindre privilège ou en anglais The principle of least privilege (souvent abrégé en PoLP) qui consiste à donner uniquement les droits nécessaires et au compte-goutte. Par exemple :

Imaginons un développeur junior qui bosse sur l'application A -> on lui attribuerait des droits limités à la simple lecture d'un bucket en lien avec l'application ou à la VM ou au cluster GKE. Mais on ne lui autoriserait pas l'accès Administrateur à la base de données de production par exemple. On part du principe qu'au moins une personne a des droits au mieux la sécurité ce porte (dans la limite du raisonnable les dev doivent quand même pouvoir travailler).

---

Section L'IAM introduit plusieurs services et notions à savoir :

Les comptes de service

Ces comptes de service sont destinés à des machines et non à des humains.

Ces comptes de service vont pouvoir attribuer des droits aux différents services dans la plateforme, par exemple donner le droit à une VM d'avoir accès en lecture à un bucket pour voir des images. Cela permet de protéger vos ressources si d'autres sont piratés ou infiltrés, l'attaquant aura une limite dans les dégâts qu'il pourra infliger à votre infrastructure. À l'inverse, imaginer donner un accès admin à un bucket, il pourrait facilement tout supprimer ou ajouter des documents malveillants par exemple, ou infiltrer d'autres machines.

Les comptes de service sont donc pratiques pour pouvoir donner accès à d'autres services sans utiliser de credentials ou de mots de passe liés à un vrai compte.

Roles

Il existe un peu plus de 2400 rôles prédéfinis par Google, vous pouvez également créer des rôles personnalisés (pour les plus exigeants). Ces rôles offrent des droits plus ou moins élevés sur certains services en fonction de différents critères. En général, la plupart des rôles sont composés du nom d'un service et des mentions Administrateur, Owner, Viewer, ou de rôles techniques comme Developer, QA... Dans 99.99% des cas, les rôles proposés par GCP sont largement suffisants et respectent les critères de sécurité définis par Google.

Comme on peut le voir, chaque rôle est composé d'un titre, d'un produit ou service ciblé, et d'un nom. En général, nous allons nous servir du nom pour cibler des rôles précis à appliquer au groupe d'utilisateurs.

---

Section Groupes

Les groupes sont des collections d'utilisateurs qui partagent les mêmes permissions et accès. Ils permettent de gérer les permissions de manière centralisée et simplifiée. Les groupes peuvent être utilisés pour appliquer des rôles à plusieurs utilisateurs en même temps, ce qui facilite la gestion des accès et des permissions dans un environnement GCP.

---

Section IAM

Les IAM (Identity and Access Management) sont prévus pour des utilisateurs réels (humains). Ce sont des comptes utilisables et avec lesquels vous pouvez vous connecter sur la plateforme GCP de manière concrète. Chaque compte a des rôles définis. Les IAM permettent de contrôler l'accès aux ressources de manière granulaire et sécurisée, en appliquant les principes de moindre privilège.

Il est de bonne pratique d'éviter d'attribuer des rôles directement aux utilisateurs mais plutôt de créer des groupes avec des rôles attachés à ces derniers. Cela permet de modifier tous les utilisateurs d'un seul coup plutôt que de gérer directement sur un utilisateur.

Imaginez une entreprise de 1 000 personnes enregistrées sur la plateforme. Si demain vous déployez un nouveau service, vous devez ajouter un rôle à chaque développeur dans l'entreprise ou DevOps ? Cela serait un travail titanesque et surtout propice à se tromper et surtout impossible à réaliser. À la place, un seul groupe à modifier qui impacte derrière 400 utilisateurs est beaucoup plus simple.

Donc ce qu'il faut retenir sur cette partie IAM et management, est le principe du moindre privilège -> il faut absolument que chaque personne présente et chaque machine ait uniquement les droits qu'elle doit avoir et pas plus. Il faut également retenir que l'on attribue pas des rôles à chaque utilisateur individuellement mais à des groupes dont font partie les utilisateurs (un user peut faire partie de plusieurs groupes en même temps).

---

Section Définitions

• IAM (Identity and Access Management) : IAM est un ensemble de politiques et de technologies qui permettent de gérer les identités numériques et de contrôler l'accès aux ressources informatiques. Il vise à assurer que les utilisateurs et les services ont accès uniquement aux ressources nécessaires pour effectuer leurs tâches, conformément aux principes de sécurité et de gouvernance.

• Groupes : Les groupes sont des collections d'utilisateurs qui partagent des rôles et des permissions similaires. En attribuant des rôles à des groupes plutôt qu'à des utilisateurs individuels, on simplifie la gestion des permissions et on réduit les risques liés à la gestion individuelle des droits d'accès. Les utilisateurs peuvent appartenir à plusieurs groupes, ce qui permet une flexibilité accrue dans la gestion des permissions.

---

Cas d'usage et mise en situation

Cas d'utilisation 1 : Gestion des accès dans une entreprise

Contexte : Une entreprise de développement logiciel souhaite gérer les accès à ses ressources cloud de manière sécurisée et efficace.

Exemple concret :

• Utilisateurs : Les développeurs, les testeurs et les administrateurs système.
• Groupes : Les développeurs sont regroupés dans un groupe "Développeurs", les testeurs dans un groupe "Testeurs" et les administrateurs système dans un groupe "Admins".
• Rôles :

Principe de moindre privilège : Chaque groupe a uniquement les permissions nécessaires pour accomplir leurs tâches spécifiques, limitant ainsi les risques de sécurité.

Cas d'utilisation 2 : Projet de recherche académique

Contexte : Un projet de recherche académique utilise des ressources cloud pour analyser de grandes quantités de données.

Exemple concret :

• Utilisateurs : Les chercheurs, les étudiants et les administrateurs du projet.
• Groupes : Les chercheurs sont regroupés dans un groupe "Chercheurs", les étudiants dans un groupe "Étudiants" et les administrateurs dans un groupe "Admins".
• Rôles :

Principe de moindre privilège : Chaque groupe a uniquement les permissions nécessaires pour accomplir leurs tâches spécifiques, limitant ainsi les risques de sécurité.

Cas d'utilisation 3 : Organisation à but non lucratif

Contexte : Une organisation à but non lucratif utilise des ressources cloud pour gérer ses opérations quotidiennes.

Exemple concret :

• Utilisateurs : Les bénévoles, les membres du conseil d'administration et les administrateurs système.
• Groupes : Les bénévoles sont regroupés dans un groupe "Bénévoles", les membres du conseil d'administration dans un groupe "Conseil" et les administrateurs système dans un groupe "Admins".
• Rôles :