12 min de lecture

Objectifs d'apprentissage

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

  • Faire la distinction entre les trois types de comptes et séparer les droits de capacité (ce qu'un groupe peut faire) des concessions de ressources (quelles ressources il peut toucher).
  • Appliquer le principe de moindre privilège sur une plateforme dont le modèle d'accès est implicite-lire et qui n'a pas de règle de refus, où le principe de moindre privilège signifie simplement ne pas accorder.
  • Expliquer pourquoi la fédération est uniquement une authentification, sans provisionnement juste-à-temps et sans mappage fournisseur d'identité-groupe, et concevoir le manuel de runbook d'ajout/suppression/deplacement manuel que cela impose.
  • Créer un groupe, définir une concession de ressource, et ajouter un membre dans le Data Center Designer, et émettre et définir un jeton API qui garde les informations d'identification personnelles en dehors de l'automatisation.

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

Introduction

Le contrôle d'accès sur IONOS ne ressemble pas au langage de politique IAM des hyperscalers américains. Il n'y a pas de document de politique JSON, pas de refus explicite, et pas de conditions fines par action. L'accès est basé sur les groupes, avec des droits de capacité attribués à un groupe et des ressources accordées au 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 certaine discipline : le principe du moindre privilège est atteint en ne grantissant pas, et non en écrivant une règle restrictive. Cette unité établit cette discipline, définit où la fédération s'arrête vraiment, et se termine par la création d'un groupe étendu et d'un jeton API étendu dans le Data Center Designer pour FinCorp.

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

Trois types de comptes existent au sein d'un contrat. Le propriétaire du contrat est créé automatiquement pour la personne qui s'est enregistrée en premier, a un accès total à toutes les ressources, peut créer et supprimer des utilisateurs et attribuer le rôle d'Administrateur, et est le seul compte qui peut modifier le mode de paiement du contrat ; il n'y en a qu'un seul et il ne peut pas être révoqué. Un Administrateur (illimité par contrat) a la même portée que le propriétaire, à l'exception du mode de paiement, peut attribuer le rôle d'Administrateur à d'autres, et accède à toutes les ressources contractées sans appartenir à aucun groupe. Un Utilisateur est le type de compte de base : il n'a aucun accès, sauf par l'intermédiaire d'un groupe et des privilèges attribués à ce groupe, et peut être promu au rôle d'Administrateur.

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

  • Les droits de capacité sont des capacités à l'échelle du contrat attribuées à un groupe, régissant le type d'action que ses membres peuvent effectuer. Les droits de groupe attribuables incluent Créer un centre de données, Créer des instantanés, Réserver des blocs IP, Créer un accès à Internet, Utiliser Object Storage, Créer des unités de sauvegarde, Créer des grappes Kubernetes, et Accéder au journal d'activité.
  • Les octrois de ressources définissent les ressources spécifiques qu'un groupe peut modifier, issues des types de ressources contrôlables : centres de données virtuels, instantanés, images, blocs IP, unités de sauvegarde, et grappes Kubernetes. Chaque octroi comporte un niveau d'autorisation : Lecture (implicite dès qu'un groupe est attribué une ressource), Édition, et Partage.

Un groupe ayant le droit de créer un centre de données mais sans centre de données virtuel attribué ne peut créer de nouveaux centres de données mais ne peut pas voir ou modifier les centres de données existants ; un groupe ayant un centre de données virtuel spécifique attribué au niveau Édition mais ne disposant pas du droit de créer un centre de données peut modifier ce centre de données mais ne peut pas en créer de nouveaux. La capacité et l'octroi sont orthogonaux, et un utilisateur obtient l'intersection des deux à travers tous les groupes auxquels il appartient. Les Administrateurs sont en dehors de cela : puisqu'ils ont un accès direct à toutes les ressources, ils n'ont pas besoin d'appartenance à un groupe, ce qui fait que le rôle d'Administrateur est une attribution délibérément rare plutôt qu'une commodité.

2. Lecture implicite, pas de refus et principe de moindre privilège en n'accordant pas

La plateforme n'a pas de règle de refus. Vous ne pouvez pas écrire une stratégie qui soustrait l'accès ; vous ne pouvez qu'ajouter des droits de capacité et des octrois de ressources. Combiné avec la lecture implicite (l'attribution d'une ressource à un groupe accorde automatiquement la lecture), cela signifie que le principe de moindre privilège est une fonction de retenue au moment de l'octroi, et non d'une règle corrective par la suite. L'attitude de moindre privilège est donc : créer des groupes à portée étroite, accorder à chacun uniquement les ressources dont il a vraiment besoin au niveau le plus bas qui fonctionne (préférer la lecture à l'édition, et réserver la mise en commun de manière délibérée), et ne jamais s'appuyer sur le rôle Administrateur comme raccourci.

Puisqu'il n'y a pas de refus, un octroi trop large ne peut pas être corrigé avec une exception ; il doit être supprimé et rétabli. La discipline opérationnelle qui suit est de modeler les groupes autour des rôles (un groupe d'exploitation de base de données, un groupe réseau, un groupe d'auditeur en lecture seule) et de maintenir l'ensemble des ressources accordées à chacun aussi étroit que le rôle le permet. Pour FinCorp sous surveillance de la BSI, un groupe d'auditeur est accordé le droit d'accès au journal d'activité et des octrois de niveau de lecture sur les VDC pertinents et rien de plus, afin que l'auditeur puisse examiner sans aucune capacité à modifier l'infrastructure.

3. La fédération est uniquement une authentification

FinCorp utilise déjà un fournisseur d'identité d'entreprise, donc l'instinct est de fédérer et de laisser le fournisseur d'identité gérer tout. La plateforme prend en charge la fédération avec SAML 2.0 et les fournisseurs d'identité OpenID Connect (OIDC), mais sa portée aujourd'hui est uniquement l'authentification. Cette phrase comporte trois conséquences difficiles qui doivent être prises en compte :

  • Pas de provisionnement juste-à-temps. Un connexion fédérée ne crée pas de compte IONOS à 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é ; l'association de compte nécessite un utilisateur existant.
  • Pas de mappage du fournisseur d'identité aux groupes. Le fournisseur d'identité ne gère pas les membres des groupes IONOS. La fédération authentifie la personne ; elle n'attribue pas les droits de capacité ou les concessions de ressources. La mise en correspondance des revendications du fournisseur d'identité avec les groupes IONOS est prévue, mais n'est pas disponible aujourd'hui.
  • Authentification, et non autorisation. La fédération répond à la question « est-ce la bonne personne » ; le modèle de groupe et de concession répond toujours à la question « que peuvent-ils faire », et ce modèle est administré à l'intérieur d'IONOS, indépendamment du fournisseur d'identité.

Le modèle que cela impose est un livre de bord de jonction/mouvement/départ explicite et manuel. Lorsqu'une personne rejoint, un administrateur crée l'utilisateur IONOS et attribue les groupes corrects avant que la connexion fédérée ne soit utile. Lorsqu'une personne change de rôle (mouvement), un administrateur ajuste son adhésion au groupe manuellement. Lorsqu'une personne part (départ), la désactivation dans le fournisseur d'identité arrête les nouvelles connexions, mais l'utilisateur IONOS et ses concessions doivent être supprimés séparément, car le fournisseur d'identité n'a jamais possédé l'accès IONOS. Traiter la fédération comme si elle provisionnait et déprovisionnait des comptes est une mauvaise interprétation dangereuse ; elle ne fait ni l'un ni l'autre. Le modèle natif est de conserver un livre de bord documenté et d'auditer la liste des utilisateurs IONOS par rapport au système RH sur un calendrier, puisque rien ne les réconcilie automatiquement.

DCD Parcours de mise en œuvre

Vous créerez un groupe FinCorp étendu, lui accorderez une seule ressource, ajouterez un membre, puis émettrez un jeton API étroitement défini. Seuls les propriétaires de contrats et les administrateurs peuvent gérer les utilisateurs. L'objectif architectural est un groupe à privilèges minimum dont l'accès est exactement les ressources accordées, plus une crédence d'automatisation qui n'est pas le login personnel de quiconque.

Objectif de construction : Créer un groupe, définir une concession de ressource, ajouter un membre ; émettre et définir un jeton API.

Étapes (dans le Data Center Designer) :

  1. Ouvrez le Gestionnaire d'utilisateurs (Utilisateurs et groupes). Dans l'onglet Groupes, sélectionnez Créer, entrez un nom de groupe (par exemple fincorp-db-ops), et sélectionnez Créer pour confirmer. Le groupe apparaît maintenant dans la liste des groupes sans droits et sans ressources encore.
  2. Avec le groupe sélectionné, attribuez ses droits de capacité en activant uniquement les privilèges dont le rôle a besoin (par exemple Créer des clusters Kubernetes, ou Accéder au journal d'activité pour un groupe d'auditeur). Laissez tous les autres droits désactivés ; le désactivé est le refus.
  3. Ouvrez l'onglet Ressources du groupe, cliquez sur Accorder l'accès, et sélectionnez la ressource spécifique (par exemple le fincorp-prod-de VDC) dans le menu déroulant. L'octroi d'une ressource active implicitement la lecture ; augmentez-la à la modification uniquement si le rôle nécessite des modifications.
  4. Ouvrez l'onglet Membres et ajoutez l'utilisateur à partir du menu déroulant Ajouter un utilisateur. L'utilisateur hérite maintenant exactement des droits et des concessions de ce groupe, et rien de plus. (N'ajoutez pas les administrateurs aux groupes ; ils ont déjà accès à tout.)
  5. Pour l'automatisation, allez dans Menu > Gestion > Token Manager et générez un jeton d'authentification. Sélectionnez une durée de vie 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 plus courte qui convient au travail. Les autorisations du jeton sont les autorisations de l'utilisateur sous lequel il est généré, donc générez-le sous un utilisateur de service créé à cet effet qui n'appartient qu'au groupe étroitement défini, et non sous un compte administrateur personnel.
  6. Copiez immédiatement la valeur du jeton. Il est affiché exactement une fois à la génération et n'est pas récupérable par la suite ; stockez-le dans votre gestionnaire de secrets avant de quitter l'écran.

Erreurs courantes :

  • Accorder une ressource en modification lorsque la lecture suffit. Il n'y a pas de règle de refus pour la rétrograder ; une concession trop large doit être supprimée et 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 ; émettez-le sous un utilisateur de service dédié et étroitement défini à la place.
  • Supposer qu'un jeton peut être suspendu. La désactivation d'un jeton signifie le supprimer ; la suppression est immédiate et permanente, et la valeur ne peut pas être récupérée, donc planifiez la rotation comme suppression et réémission.
  • S'attendre à ce que la fédération crée ou supprime des comptes. Elle n'authentifie que ; le cycle de vie de l'utilisateur est un runbook manuel côté IONOS.
  • Traiter l'affichage d'un jeton à usage unique comme récupérable. Capturez-le à la génération ; il n'y a pas de deuxième chance pour le lire.

Une courte illustration de la limite de la crédence : la programmation contre le API utilise le jeton comme crédence de porteur, et non un nom d'utilisateur et un mot de passe, ce qui est exactement pourquoi le jeton doit transporter uniquement la portée minimale de l'utilisateur de service.

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

Le point architectural est dans l'en-tête : le jeton est l'identité. Quoi que puisse faire l'utilisateur de service, le script peut le faire, c'est pourquoi limiter l'utilisateur, et non le script, est le contrôle.

Résumé

Le contrôle d'accès IONOS est basé sur des groupes avec des droits de capacité et des octrois de ressources séparés, une lecture implicite et pas de règle de refus, donc le privilège le moins élevé est atteint en accordant étroitement plutôt que en écrivant une politique restrictive. La fédération avec SAML ou OIDC est uniquement une authentification, sans provisionnement juste-à-temps et sans mappage IdP-vers-groupe, ce qui oblige à exécuter manuellement un runbook d'ajout/suppression/deplacement. Les jetons API héritent des autorisations de l'utilisateur émetteur et sont affichés une seule fois, donc ils appartiennent aux utilisateurs de services étendus et sont rotatifs par suppression et réémission.

Points clés :

  • Trois types de comptes : un propriétaire de contrat non révocable, des administrateurs illimités (portée complète moins la méthode de paiement, pas de groupe nécessaire), et des utilisateurs qui n'ont accès qu'aux groupes.
  • Les droits de capacité (ce qu'un groupe peut faire) et les octrois de ressources (quelles ressources, à des niveaux Lecture/Édition/Partage) sont orthogonaux ; un utilisateur reçoit l'intersection de ses groupes.
  • Il n'y a pas de règle de refus et la lecture est implicite, donc le privilège le moins élevé signifie ne pas accorder ; un octroi trop large est supprimé et rétabli, et non corrigé.
  • La fédération est uniquement une authentification : l'utilisateur doit préexister (pas de JIT), l'IdP ne mappe pas les groupes, et l'ajout/suppression/deplacement est un runbook manuel.
  • Les jetons API héritent des autorisations de l'utilisateur émetteur, permettent jusqu'à 100 par utilisateur, sont affichés une seule fois et non récupérables, et sont supprimés (et non désactivés) pour révoquer ; émettez-les sous les utilisateurs de services étendus.

Terminologie importante :

  • Droit de capacité : Un privilège de groupe à l'échelle du contrat qui régit le type d'action que les membres peuvent effectuer (par exemple, créer des clusters Kubernetes).
  • Octroi de ressource : Un octroi d'une ressource spécifique à un groupe à un niveau Lecture, Édition ou Partage ; l'octroi permet la lecture de manière implicite.
  • Fédération : Une confiance d'authentification SAML 2.0 / OIDC ; elle vérifie l'identité uniquement et ne provisionne pas les comptes ou n'attribue pas les groupes.
  • Jeton API : Un jeton porteur qui hérite des autorisations de l'utilisateur émetteur, affiché une seule fois lors de la génération et révoqué par suppression.