Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Débuter avec Azure
  3. Identité et accès
Extrait - Débuter avec Azure Concepts fondamentaux et mise en oeuvre
Extraits du livre
Débuter avec Azure Concepts fondamentaux et mise en oeuvre
2 avis
Revenir à la page d'achat du livre

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 accès ou RBAC est plutôt traitée par les administrateurs Azure.

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 est donc une équipe Active Directory qui est déjà responsable de l’existant sur site (On-premises) et qui va continuer à assurer ce rôle pour l’Azure Active Directory (que l’on trouve régulièrement sous le terme AAD ou Azure AD).

Lors de la création d’un Cloud Azure, cette équipe va synchroniser l’AD existant sur le Cloud et ainsi créer un nouvel annuaire avec un type d’objets et d’attributs choisis. Il n’est pas nécessaire de faire une copie complète mais plutôt de conserver uniquement des objets et attributs utilisés sur Azure. Cette première synchronisation...

Rôles Azure AD et rôles d’accès aux ressources

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

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

Liste des rôles prédéfinis Azure AD, vue partielle

Liste des rôles prédéfinis Azure AD, 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 aussi des limitations comme le fait de ne pas pouvoir supprimer un administrateur général....

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 :

  • Utilisateur

  • Groupe(s)

  • Principal de service

  • Identité managée (système ou utilisateur)

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.

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.

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

1. L’objet de sécurité

Comme expliqué en introduction, le premier niveau de l’identité est un objet de sécurité. Quatre objets sont disponibles : Utilisateur, Groupe(s), Principal de service ou Identité managée (système ou utilisateur).

Si les objets utilisateurs et groupes sont très connus, voici quelques explications complémentaires sur le principal de service et l’identité managée.

Le principal de service est un objet applicatif. C’est une identité pour votre application. Sur cette identité sont définies les stratégies d’accès et les autorisations.

L’identité managée est plus récente et assez proche du principal de service. Dans la définition de l’identité managée, on trouve souvent le terme principal...

Authentification multifacteur

L’authentification multifacteur ou MFA é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 :

  • L’application Microsoft Authenticator

  • Un SMS

  • Un appel vocal

  • Un jeton matériel

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

Le MFA est une fonctionnalité disponible à partir d’un certain niveau de licence, Azure AD Premium. C’est une option qui n’est pas activée par défaut et que l’administrateur doit mettre en place en complément de la méthode d’authentification par mot de passe. C’est...

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.

 Positionnez-vous sur le groupe de ressources rg-formation-eni-test, puis choisissez Contrôle d’accès (IAM) dans la partie gauche du menu.

 Avant d’attribuer un rôle, vérifiez les accès existants pour le groupe GroupeSecu0001. Sélectionnez l’onglet Vérifier l’accès, vérifiez que l’ascenseur de sélection est bien positionné sur Utilisateur, groupe ou principal de service puis effectuez une recherche sur GroupeSecu0001.

 L’objet est affiché dans les résultats de la recherche ; choisissez cet objet qui ouvre une nouvelle fenêtre GroupeSecu0001 affectations - rg-formation-eni-test.

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.

 Fermez cette vue puis sélectionnez dans la partie haute du menu + Ajouter et choisissez Ajouter une attribution de rôle.

On retrouve dans cette vue deux des piliers de la gestion des accès :...

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 :

  • L’Active Directory local ou AD DS : c’est l’annuaire historique de l’entreprise. Il est local mais peut être aussi présent dans le Cloud Azure sous la forme d’une machine Windows Server qui est promue contrôleur de domaine. Les accès au réseau sont ouverts pour que cette machine discute avec les contrôleurs de domaines hébergés localement ; c’est un vrai contrôleur de domaine, même s’il est hébergé dans le Cloud. Il est même possible techniquement de déployer une forêt AD complète dans un Cloud. On parle toujours d’Active Directory.

  • L’Azure Active Directory ou AAD (déjà présenté en introduction) : Azure Active Directory (AAD) n’est pas un contrôleur de domaine mais un service d’annuaire ; et c’est important ! Un exemple est présenté dans le chapitre Le stockage lorsqu’il est question de donner des droits d’accès aux partages de fichiers Azure au travers d’Active Directory....