Identité et accès

Introduction

L’identité (ou plutôt les identités) et les accès représentent des points bien à part pour le cloud Azure, car une partie du sujet identité est souvent traitée par des équipes qui ne sont pas les administrateurs Azure mais plutôt les administrateurs de l’annuaire d’entreprise, par exemple l’Active Directory Microsoft. 

La seconde partie des accès ou RBAC (Role-Based Access Control ou contrôle d’accès basé sur un rôle Azure) est plutôt traitée par les administrateurs Azure ; ce sont des accès aux ressources.

Il existe une séparation nette entre les deux équipes et il est très rare que l’ensemble des responsabilités soit porté par une seule et même équipe.

Le cas courant pour la gestion implique une équipe Active Directory déjà responsable de l’environnement local (On-premises). Cette même équipe continue généralement à assurer ce rôle pour Entra ID (anciennement...

Rôles Entra ID et rôles d’accès aux ressources

Les accès Azure sont découpés en deux grandes familles : les rôles Entra ID (anciennement Azure AD) et les rôles d’accès aux ressources.

1. Rôle Entra ID

Un rôle Entra ID autorise des actions sur des objets comme les utilisateurs, les groupes et les applications.

Liste des rôles prédéfinis Entra ID, vue partielle

Les listes de rôles prédéfinis sont très fournies. Par exemple, le rôle Administrateur d’utilisateurs est décrit de la façon suivante (source éditeur Microsoft) :

Les utilisateurs dotés de ce rôle peuvent créer et gérer tous les aspects des utilisateurs et des groupes. De plus, ce rôle inclut la possibilité de gérer les tickets de support et de surveiller l’intégrité du service. Certaines restrictions s’appliquent. Par exemple, ce rôle n’autorise pas la suppression d’un administrateur général. Les administrateurs de comptes utilisateur peuvent modifier les mots de passe des utilisateurs, des administrateurs du support technique et des autres administrateurs de compte utilisateur uniquement.

Ce rôle est complet, avec des actions possibles sur les utilisateurs, sur les tickets de support mais...

Autorisation, concept de base

Obtenir des autorisations sur Azure se fait en plusieurs étapes. Il s’agit d’abord de créer un objet de sécurité ; il en existe quatre :

Sur ces objets sont attachés des rôles, par exemple un rôle d’Administrateur de l’accès utilisateur. Il existe un grand nombre de rôles dits prédéfinis, prêts à l’utilisation. Si ces rôles prédéfinis ne sont pas suffisants, comme expliqué, il est tout à fait possible de créer des rôles particuliers.

Pour la dernière étape, il faut définir une étendue pour appliquer ces rôles. Il existe quatre étendues : les abonnements, les groupes de management, les ressources et les groupes de ressources.

Cette granularité permet de positionner des autorisations très fines puisqu’un objet utilisateur peut se voir attacher une ou plusieurs listes de rôles et que cet ensemble est ensuite affecté sur une ou plusieurs étendues spécifiques. Attention, il faut rester le plus simple possible pour définir les droits, et être particulièrement attentif à la notion d’arborescence. Il n’est pas nécessaire d’assigner deux fois le même rôle à un niveau d’arborescence différent. Le rôle positionné au plus haut de l’arborescence va couvrir le besoin.

Pour en finir avec cette introduction, on applique sur Azure comme On-premises la règle du moindre privilège : donner les bons droits et les bonnes autorisations, mais pas plus que nécessaire. Il faut passer du temps dans les rôles prédéfinis. Ils sont assez complets et, pour certains, couvrent des besoins d’accès aux ressources de manière transverse. Dans la suite du chapitre, le rôle Contributeur de sauvegarde est présenté. C’est un exemple de rôle transverse, ce qui est expliqué par la suite.

Dans la suite du chapitre, ces différents points seront revus en détail.

Authentification multifacteur

L’authentification multifacteur ou MFA (Multi-Factor Authentication) élève la sécurité de l’identification. Un mot de passe fort est une première étape dans la sécurisation. Il doit être complexe, c’est-à-dire composé de chiffres, de lettres, de majuscules, de minuscules et de caractères spéciaux. Sa longueur doit être importante mais ce n’est pas suffisant. L’introduction d’une seconde méthode d’authentification (un second facteur) est une pratique courante et conseillée.

Lors de la séquence d’authentification, après la saisie et la vérification du couple compte/mot de passe, la séquence est interrompue et une nouvelle fenêtre est affichée.

Le second facteur peut être :

Comme l’authentification est composée de plusieurs facteurs, un attaquant éventuel est bloqué, il ne peut fournir que l’une des parties de l’authentification.

Accès Just In Time

L’accès Just-In-Time (JIT) est une option disponible avec Entra ID et une licence de niveau P2. C’est une fonctionnalité de Privileged Identity Management (PIM) dans Azure. Cette fonctionnalité permet de gérer l’accès privilégié aux ressources de manière sécurisée et contrôlée. Ainsi, les comptes à fort privilèges avec des rôles de type propriétaire ou contributeur sont activés à la demande. Ils ne portent pas ces rôles tant qu’ils n’en font pas la demande. Les utilisateurs doivent demander l’activation de leur rôle via le portail Azure lorsqu’ils ont besoin d’accéder à des ressources spécifiques. Les administrateurs peuvent approuver ou refuser ces demandes, assurant ainsi un contrôle très strict. Il est aussi possible d’approuver de manière automatique. L’accès est accordé pour une période limitée, réduisant ainsi les risques de sécurité.

Par exemple, pour une durée de 2 ou 4 heures pour des opérations très spécifiques.

Exercices

Les exercices suivants mettent en œuvre tous les points du chapitre. Dans le premier exercice, un premier contrôle d’accès est effectué. Le contrôle d’accès est un menu utilisé quotidiennement par l’administrateur. Pour un objet de sécurité donné (un compte utilisateur ou un groupe par exemple), il affiche un résumé de son niveau d’accès sur l’étendue sélectionnée. Indispensable ! Ensuite, un rôle prédéfini est ajouté sur un groupe puis un nouveau contrôle d’accès est effectué. Puis un rôle custom est créé depuis le portail. Enfin, le cas particulier des rôles à fort privilèges est abordé.

Il n’y a aucune donnée dans les champs Attributions de rôles (0) et Affectations de refus (0). Ce groupe n’a aucune affectation de rôles sur cette étendue.

Informations complémentaires

Il y a souvent beaucoup de confusions sur cette partie Active Directory et les explications qui suivent doivent être parfaitement assimilées pour qui souhaite approfondir le sujet.

Active Directory est un annuaire. Dans un environnement Azure, il y a deux ou trois Active Directory :