12 min de lecture

Objectifs d'apprentissage

À la fin de ce module, vous serez en mesure de:

  • Distinguer les trois types de comptes et de séparer les droits de capacité (ce qu'un groupe est autorisé à faire) des autorisations de ressources (les ressources auxquelles il peut accéder).
  • Appliquer le principe du moindre privilège sur une plateforme dont le modèle d'accès est la lecture implicite et qui ne dispose d'aucune règle de refus, où le moindre privilège signifie simplement de ne pas accorder d'autorisation.
  • Expliquer pourquoi la fédération ne concerne que l'authentification, sans approvisionnement en temps opportun ni correspondance entre le fournisseur d'identité et le groupe, et concevoir le guide d'exploitation manuel pour les entrées, transferts et sorties d'utilisateurs que cela impose.
  • Créer un groupe, définir le périmètre d'une autorisation de ressources et ajouter un membre dans Data Center Designer, ainsi que créer et définir le périmètre d'un jeton API afin de garder les identifiants personnels hors des automatisations.

Unité 2.2 : Identité, RBAC et fédération

Introduction

Le contrôle d'accès sur IONOS CLOUD ne ressemble pas à l'IAM à langage de politique des hyperscalers américains. Il n'y a aucun document de politique JSON, aucun refus explicite et aucune condition fine par action. L'accès est basé sur les groupes, avec des droits de capacité attribués à un groupe et des ressources accordées à ce même groupe, et l'accès en lecture est implicite dès qu'une ressource est accordée. Ce modèle est plus simple, mais il impose une discipline particulière : le principe du moindre privilège est atteint en ne concédant pas, plutôt qu'en rédigeant une règle restrictive. Cette unité établit cette discipline, précise où la fédération s'arrête réellement, et se termine par la création d'un groupe à portée limitée et d'un jeton API à portée limitée dans le Data Center Designer pour FinCorp.

1. Types de comptes, droits de capacité et attributions de ressources

Trois types de comptes existent au sein d'un contrat. Le propriétaire du contrat est créé automatiquement pour la première personne qui s'est inscrite, dispose d'un accès complet à toutes les ressources, peut créer et supprimer des utilisateurs et attribuer le rôle Administrateur, et est le seul compte pouvant modifier le mode de paiement du contrat ; il n'en existe qu'un seul et il ne peut pas être révoqué. Un Administrateur (nombre illimité par contrat) dispose des mêmes prérogatives que le propriétaire, à l'exception du mode de paiement, peut attribuer le rôle Administrateur à d'autres utilisateurs, et accède à toutes les ressources du contrat sans appartenir à aucun groupe. Un Utilisateur est le type de compte de base : il n'a aucun accès en soi, sauf par le biais de l'appartenance à un groupe et des privilèges attribués à ces groupes, et il peut être promu au rang d'Administrateur.

Pour les Utilisateurs, l'accès est construit à partir de deux couches indépendantes, et le maintien de leur distinction constitue le cœur du modèle :

  • Les droits de capacité sont des habilitations applicables à l'ensemble du contrat, attribuées à un groupe, qui déterminent le type d'actions que ses membres peuvent effectuer. Les droits de groupe attribuables comprennent Create Data Center, Create Snapshots, Reserve IP Blocks, Create Internet Access, Use Object Storage, Create Backup Units, Create Kubernetes Clusters, et Access Activity Log.
  • Les attributions de ressources définissent quelles ressources spécifiques un groupe peut utiliser, parmi les types de ressources contrôlables : Virtual Data Centers, Snapshots, Images, IP Blocks, Backup Units, et Kubernetes Clusters. Chaque attribution comporte un niveau d'autorisation : Read (implicite dès qu'un groupe se voit attribuer une ressource), Edit, et Sharing.

Un groupe disposant du droit Create Data Center mais à qui aucun VDC n'est attribué peut créer de nouveaux centres de données, mais ne peut ni voir ni modifier les existants ; un groupe à qui un VDC spécifique est attribué au niveau Edit, mais qui ne dispose pas du droit Create Data Center, peut modifier ce VDC précis, mais ne peut pas en créer de nouveaux. La capacité et l'attribution sont orthogonales, et un utilisateur obtient l'intersection des deux à travers tous les groupes auxquels il appartient. Les Administrateurs sont entièrement en dehors de ce mécanisme : comme ils accèdent directement à toutes les ressources, ils n'ont pas besoin d'appartenir à un groupe, ce qui fait du rôle d'Administrateur une attribution volontairement rare plutôt qu'une simple commodité.

2. Lecture implicite, absence de refus et moindre privilège par non-attribution

La plateforme ne dispose d'aucune règle de refus. Il est impossible de rédiger une politique qui soustrait des accès ; il est seulement possible d'ajouter des droits de capacité et des attributions de ressources. Combiné à la lecture implicite (l'attribution d'une ressource à un groupe accorde automatiquement le droit de lecture sur celle-ci), cela signifie que le moindre privilège est une question de retenue au moment de l'attribution, et non d'une règle corrective ultérieure. L'attitude en matière de moindre privilège consiste donc à créer des groupes à portée étroite, à n'attribuer à chacun que les ressources dont il a réellement besoin au niveau le plus bas qui fonctionne (privilégier Read par rapport à Edit, et réserver Sharing de manière délibérée), et à ne jamais recourir au rôle Administrator comme raccourci.

Étant donné qu'il n'y a pas de refus, une attribution trop large ne peut pas être corrigée par une exception ; elle doit être supprimée et redéfinie. La discipline opérationnelle qui en découle consiste à modéliser les groupes autour des rôles (un groupe d'opérations sur les bases de données, un groupe réseau, un groupe d'auditeurs en lecture seule) et à maintenir l'ensemble des ressources attribuées à chaque groupe aussi restreint que le rôle le permet. Pour FinCorp sous le contrôle de BSI, un groupe d'auditeurs se voit accorder le droit Access Activity Log et des attributions au niveau de lecture sur les VDCs concernés, et rien d'autre, afin que l'auditeur puisse effectuer une revue sans aucune capacité de modifier l'infrastructure.

3. La fédération ne concerne que l'authentification

FinCorp exploite déjà un fournisseur d'identité d'entreprise, ce qui donne l'intuition de mettre en place une fédération et de laisser le fournisseur d'identité (IdP) piloter l'ensemble. La plateforme prend en charge la fédération avec des fournisseurs d'identité SAML 2.0 et OpenID Connect (OIDC), mais son périmètre actuel se limite à l'authentification. Cette précision entraîne trois conséquences majeures auxquelles il faut prendre en compte dans la conception :

  • Aucune provisionnement en temps réel. Une connexion fédérée ne crée pas de compte IONOS CLOUD à la volée. L'utilisateur doit déjà exister en tant qu'utilisateur IONOS CLOUD avant de pouvoir s'authentifier via le fournisseur d'identité ; le rattachement du compte nécessite un utilisateur existant.
  • Aucune correspondance entre le fournisseur d'identité et les groupes. Le fournisseur d'identité ne pilote pas l'appartenance aux groupes IONOS CLOUD. La fédération authentifie la personne ; elle n'attribue pas ses droits de capacité ni ses autorisations de ressources. La correspondance des accès, des assertions du fournisseur d'identité vers les groupes IONOS CLOUD, est prévue dans la feuille de route, mais n'est pas disponible à l'heure actuelle.
  • Authentification, et non autorisation. La fédération répond à la question « est-ce la bonne personne » ; le modèle de groupes et d'autorisations répond toujours à la question « que peuvent-ils faire », et ce modèle est administré au sein d'IONOS CLOUD, indépendamment du fournisseur d'identité.

Le schéma imposé par cette situation est une procédure manuelle et explicite pour les arrivées, les changements de poste et les départs. Lorsqu'une personne arrive, un administrateur crée l'utilisateur IONOS CLOUD et lui assigne les groupes appropriés avant que la connexion fédérée ne soit utile. Lorsqu'une personne change de rôle (changement de poste), un administrateur ajuste manuellement son appartenance aux groupes. Lorsqu'une personne quitte l'organisation (départ), la désactivation de son compte dans le fournisseur d'identité empêche les nouvelles connexions, mais l'utilisateur IONOS CLOUD et ses autorisations doivent être supprimés séparément, car le fournisseur d'identité n'a jamais détenu le contrôle de l'accès côté IONOS CLOUD. Considérer la fédération comme un mécanisme de provisionnement et de déprovisionnement des comptes est une interprétation dangereuse ; elle n'effectue ni l'un ni l'autre. Le schéma natif consiste à maintenir une procédure documentée et à auditer la liste des utilisateurs IONOS CLOUD par rapport au système de ressources humaines selon un calendrier défini, car rien ne les réconcilie automatiquement.

Déroulement de l'implémentation de DCD

Vous allez créer un groupe FinCorp avec un périmètre défini, lui accorder une ressource unique, ajouter un membre, puis émettre un jeton API au périmètre restreint. Seuls les propriétaires de contrats et les administrateurs peuvent gérer les utilisateurs. L'objectif architectural est de créer un groupe au principe du moindre privilège, dont l'accès se limite exactement aux ressources qui lui sont accordées, ainsi qu'une identifiante d'automatisation qui ne correspond pas à la connexion personnelle de quiconque.

Objectif de construction : Créer un groupe, définir le périmètre d'une attribution de ressource, ajouter un membre ; émettre un jeton API et en définir le périmètre.

Étapes (dans Data Center Designer) :

  1. Ouvrir le Gestionnaire d'utilisateurs (Utilisateurs et groupes). Dans l'onglet Groups, sélectionner Create, saisir un nom de groupe (par exemple fincorp-db-ops), puis sélectionner Create pour confirmer. Le groupe apparaît désormais dans la liste des groupes, sans droits ni ressources pour le moment.
  2. Avec le groupe sélectionné, attribuer ses droits de capacité en activant uniquement les privilèges dont le rôle a besoin (par exemple Create Kubernetes Clusters, ou Access Activity Log pour un groupe d'auditeurs). Laisser tous les autres droits désactivés ; une case non cochée signifie un refus.
  3. Ouvrir l'onglet Resources of Group, cliquer sur Grant Access et sélectionner la ressource spécifique (par exemple le VDC fincorp-prod-de) dans la liste déroulante. L'attribution d'une ressource active implicitement le droit de lecture ; passer en mode édition uniquement si le rôle nécessite des modifications.
  4. Ouvrir l'onglet Members et ajouter l'utilisateur depuis la liste déroulante Add User. L'utilisateur hérite désormais exactement des droits et des attributions de ce groupe, et rien d'autre. (N'ajoutez pas d'administrateurs aux groupes ; ils ont déjà accès à tout.)
  5. Pour l'automatisation, aller dans Menu > Management > Token Manager et générer un jeton d'authentification. Sélectionner une TTL parmi les valeurs autorisées (1 heure, 4 heures, 1 jour, 7 jours, 30 jours, 60 jours, 90 jours, 180 jours, 365 jours), en choisissant la durée la plus courte qui convient à la tâche. Les permissions du jeton sont celles de l'utilisateur sous lequel il est généré ; il faut donc le générer sous un utilisateur de service dédié, qui n'appartient qu'au groupe au périmètre restreint, et jamais sous un compte administrateur personnel.
  6. Copier la valeur du jeton immédiatement. Elle n'est affichée qu'une seule fois lors de la génération et ne peut pas être récupérée par la suite ; stocker cette valeur dans votre gestionnaire de secrets avant de quitter l'écran.

Erreurs courantes :

  • Accorder une ressource en mode édition alors que la lecture suffit. Il n'existe pas de règle de refus pour revenir en arrière ; une attribution trop large doit être supprimée puis redéfinie.
  • Émettre des jetons API sous un compte personnel ou administrateur. Le jeton hérite de la portée complète de ce compte ; il faut plutôt l'émettre sous un utilisateur de service dédié au périmètre restreint.
  • Supposer qu'un jeton peut être mis en pause. Désactiver un jeton signifie le supprimer ; la suppression est immédiate et définitive, et la valeur ne peut pas être récupérée, il faut donc planifier la rotation comme une suppression et une réémission.
  • S'attendre à ce que la fédération crée ou supprime des comptes. Elle n'authentifie que ; le cycle de vie d'arrivée, de mobilité et de départ est une procédure manuelle côté IONOS CLOUD.
  • Considérer l'affichage unique du jeton comme récupérable. Le capturer lors de la génération ; il n'y a pas de seconde chance pour le lire.

Une brève illustration de la frontière des identifiants : l'automatisation via l'API utilise le jeton comme identifiant porteur, jamais un nom d'utilisateur et un mot de passe, ce qui explique précisément pourquoi le jeton doit porter uniquement le périmètre minimal de l'utilisateur de service.

curl --location \
  --request GET 'https://api.ionos.com/cloudapi/v6/datacenters' \
  --header 'Authorization: Bearer <SERVICE_USER_TOKEN>'

L'élément architectural clé se trouve dans l'en-tête : le jeton constitue l'identité. Tout ce que l'utilisateur du service peut faire, le script peut le faire, ce qui explique pourquoi le contrôle réside dans la limitation de l'utilisateur, et non du script.

Résumé

Le contrôle d'accès IONOS CLOUD est basé sur les groupes, avec les droits de capacité et les attributions de ressources maintenus séparément, une lecture implicite et aucune règle de refus. Le moindre privilège est donc atteint en accordant des droits restreints plutôt qu'en rédigeant des politiques restrictives. La fédération avec SAML ou OIDC ne constitue qu'une authentification, sans provisionnement just-in-time ni correspondance entre l'IdP et les groupes, ce qui impose un runbook manuel pour les entrées, transferts et sorties. Les jetons API héritent des autorisations de l'utilisateur émetteur et sont affichés une seule fois ; ils doivent donc être attribués à des utilisateurs de service aux permissions limitées et renouvelés par suppression et réémission.

Points clés :

  • Trois types de comptes : un propriétaire de contrat non révocable, un nombre illimité d'Administrators (accès complet sauf méthode de paiement, sans groupe requis), et des Users qui n'obtiennent un accès que par le biais de groupes.
  • Les droits de capacité (ce qu'un groupe est autorisé à faire) et les attributions de ressources (quelles ressources, au niveau Read/Edit/Sharing) sont orthogonaux ; un utilisateur obtient l'intersection de ces droits à travers ses groupes.
  • Il n'y a pas de règle de refus et la lecture est implicite, si bien que le moindre privilège consiste à ne pas accorder ; une attribution trop large est supprimée et réajustée, et non corrigée.
  • La fédération ne constitue qu'une authentification : l'utilisateur doit préexister (pas de JIT), l'IdP ne correspond pas aux groupes, et le processus d'entrée, de transfert et de sortie est un runbook manuel.
  • Les jetons API héritent des autorisations de l'utilisateur émetteur, sont limités à 100 par utilisateur, sont affichés une seule fois et ne sont pas récupérables, et sont supprimés (et non désactivés) pour être révoqués ; ils doivent être émis au nom d'utilisateurs de service aux permissions limitées.

Terminologie importante :

  • Droit de capacité : Un privilège de groupe à l'échelle du contrat qui régit le type d'action que les membres sont autorisés à effectuer (par exemple, créer des Clusters Kubernetes).
  • Attribution de ressource : L'attribution d'une ressource spécifique à un groupe au niveau Read, Edit ou Sharing ; l'attribution active implicitement le niveau Read.
  • Fédération : Confiance d'authentification SAML 2.0 / OIDC ; elle vérifie uniquement l'identité et ne provisionne pas de comptes ni n'assigne de groupes.
  • Jeton API : Un jeton de porteur qui hérite des autorisations de l'utilisateur émetteur, affiché une seule fois lors de sa génération et révoqué par suppression.