Concepts liés à la gestion des accès
Lorsqu'un utilisateur authentifié tente d'accéder à une ressource, l'IAM vérifie la politique d'autorisation d'accès à la ressource pour déterminer si l'action est permise.
Les Ressources
Une ressource informatique désigne tout composant physique ou virtuel du système informatique. Dans un contexte informatique en nuage (Cloud Computing), seules des ressources virtuelles sont manipulées comme par exemple les machines virtuelles, les applications, les bases de données ou encore les orchestrateurs de conteneurs. Ces ressources ont un cycle de vie allant de la création à la suppression en passant par la modification. Au niveau conceptuel le plus élevé, une organisation et ses espaces sont des ressources.
Hiérarchie des ressources
Une organisation, ses espaces et ses ressources peuvent s'inscrire dans un graphe. Le système est composé d'utilisateurs et de ressources. Les utilisateurs sont en relation avec ces ressources par l'intermédiaire des permissions. Une action sera autorisée pour un utilisateur sur une ressource, si une relation directe ou indirecte est trouvée entre les deux.
Les permissions
Les permissions déterminent les actions autorisées pour un utilisateur ou un compte de service sur une ressource ou une catégorie de ressource. Pour une ressource gérée suivant le modèle CRUD (CREATE / READ / UPDATE / DELETE), on aura des permissions correspondant à chaque action : CREATE, READ (GET) , UPDATE et DELETE. Les actions sont parfois spécifiques à une catégorie de ressources. Par exemple pour une VM, on pourra avoir les actions de démarrage ou d'arrêt. Les droits sont le résultat de permissions associées à des rôles, qui sont eux même assignés à un utilisateur ou à un compte de service. A ce mécanisme se superpose éventuellement une personnalisation via les permissions et l'ACL.
Rôles
L'IAM NumSpot permet d'assigner un ou plusieurs rôles prédéfinis à des utilisateurs ou à des comptes de service. Chaque rôle détient un ensemble variable de permissions, adaptées en fonction de son domaine organisationnel ou fonctionnel. Lorsque vous attribuez un rôle à un utilisateur, vous lui accordez toutes les permissions que compte le rôle.
Rôles au niveau d'une organisation ou de ses espaces
Les utilisateurs se voyant affectés des rôles au niveau de l'organisation ou d'un espace auront un périmètre de permission correspondant à ces entités. Par exemple un utilisateur avec un rôle assigné d'administrateur de l'organisation, pourra se désigner ou pourra désigner un autre utilisateur comme administrateur d'un espace. Un utilisateur peut être à la fois administrateur sur un espace et un utilisateur sans privilège sur un autre.
Rôles fonctionnels
Il est possible d'attribuer des rôles pour des catégories de ressources. Par exemple : confier la gestion des machines virtuelles (VMs) à un utilisateur et la gestion des composants réseaux à un autre. Au sein d'une catégorie de ressource, en plus du rôle d'administration, il est possible de restreindre les droits à des actions précises : exemples : création d'une ressource, modification, suppression et accès.
Hiérarchie des rôles
On peut établir une échelle de gradation dans les rôles : En haut de l'échelle, on trouvera les rôles d'administrateurs qui auront toute latitude pour effectuer des opérations dans leur périmètre, puis viendront les créateurs de ressources et enfin les utilisateurs de base qui n'auront que le droit en lecture seule. Certains rôles peuvent englober des permissions d'un rôle plus basique : exemple 'LB..Editor' qui reprend les permissions de 'LB..viewer' et en ajoute des nouvelles. L'utilisateur ou le compte de service qui crée une ressource aura tous les droits sur celle-ci.
Portée des permissions d'un utilisateur ou d'un compte de service
Les permissions sont cloisonnées au périmètre de l'espace. Un utilisateur ayant des droits sur un espace, ne pourra pas intervenir sur les ressources d'un autre espace sauf s'il appartient également à cet espace. Pour qu'un utilisateur puisse acquérir des droits sur un espace, il faut soit qu'il ait déjà les droits pour s'accorder de nouvelles permissions, soit que ces permissions soient accordées par l'administrateur de l'espace.
La matrice Rôle/Permissions
Un document sous forme de matrice, liste les permissions attachées à un rôle. Les permissions et les rôles sont préchargés dans le système. Ils sont utilisables dès l'initialisation d'une organisation et ils permettent de mettre en place des politiques efficaces de contrôle d'accès aux ressources.
La matrice est organisée en colonne qui contiendra les rôles prédéfinis et les lignes seront l'ensemble des permissions organisées par thème ou famille de composant.
On trouvera tout ce qui entre dans la composition d'un VPC (VM, réseau, équilibreur de charge, stockage etc.). Avec le plus souvent les opérations supportées par le modèle CRUD : création, lecture, mise à jour et suppression. Le périmetre des permissions associées à un rôle est soit l'organisation, soit l'espace.
Concernant les rôles, on distingue les rôles d'administration avec ceux des utilisateurs qui auront un périmètre spécifique. Les rôles d'administrateurs sont englobants : un rôle d'administrateur d'un espace aura aussi les droits subordonnés de lecture sur les composants de son espace. Il est possible d'assigner plusieurs rôles à un utilisateur ou à un compte de service.
Lien vers matrice Rôle/permissions
IMPORTANT:Cette matrice peut évoluer en fonction de la mise à disposition de nouveaux services.
Les rôles spécifiques à la gestion des permissions
Il existe une famille de rôles qui permet de gérer le système de permissions et des rôles: Ces rôles sont préfixés par 'IAM..', un utilisateur ayant ce rôle assigné pourra modifier les permissions associées au rôle ou attribuer des permissions particulières (ACL). Les utilisateurs ayant le rôle de gestionnaire de compte peuvent gérer les permissions granulaires (ACL) relatives aux utilisateurs.
Les permissions granulaires ou ACL
Les rôles ont une portée générique sur les ressources d'une organisation ou de ces espaces. Si on souhaite attribuer à un utilisateur, une permission sur une ressources précise, il est possible de lui ajouter une permission qui aura une portée limitée à cette ressource bien identifiée. Ainsi un utilisateur peut cumuler des permissions attachées à un rôle et des permissions spécifiques sous forme d'ACL. On peut ajouter plusieurs ACL en même temps.
Lien vers API permissions :SetIAMGranularPolicy
Pour utiliser cette API, il faut connaitre les identifiants techniques de l'utilisateur et de la ressource visée.
Stratégie d'autorisation
L'IAM met en œuvre un dispositif de gestion des permissions qui permet de cloisonner les permissions de chaque organisation.
La stratégie par défaut nʼest de rien autoriser. Les permissions sont obtenues par l'assignation de rôle ou par la déclaration de permissions spécifiques sur une ressource.
Il est possible d'attribuer des rôles aux utilisateurs. Ces rôles déterminent un bouquet de permissions. C'est un ensemble de règles qui définissent qui a quel type d'accès. Une stratégie d'autorisation est associée à une ressource et permet d'en contrôler tous les accès. L'IAM met en œuvre un dispositif de gestion des permissions qui permet de cloisonner les permissions de chaque organisation.
Résolutions des permissions : Quand un utilisateur souhaite réaliser une action sur une ressource, le système appliquera les trois stratégies d'autorisation (RBAC, Permission unitaire et ACL) afin d'établir si l'utilisateur peut réaliser l'action sur la ressource. Pour rappel, le créateur d'une ressource possèdera tous les droits sur celle-ci.