Fin de Windows Server Update Services : quelles sont les alternatives ?
Microsoft a annoncé le 20 septembre dernier la dépréciation de Windows Server Update Services (WSUS) à compter de Windows Server...
La définition des rôles et des scopes sur les outils informatiques est une question centrale dans un projet modern workplace. De par les actions de masse réalisables à travers ces outils, il est essentiel de définir les équipes et leurs droits ainsi que les périmètres sur lesquels chacun peut intervenir.
Au sein de Microsoft Intune et d’Entra ID (Azure AD), la gestion des rôles et des permissions s’implémente à plusieurs échelles.
Il faut tout d’abord visualiser Intune comme étant une brique d’Entra ID. Plusieurs années auparavant, Intune était même un menu d’Entra ID avant d’avoir son portail dédié. Il existe plusieurs rôles Entra ID qui donnent des permissions dans Intune. Il s’agit de rôles pré-créés sur lesquels il est bon de s’appuyer lors de la mise en œuvre d’un RBAC (Role-Based Access Control).
Un rôle Entra ID se définit par un ensemble de permissions qui est assigné ensuite sur un groupe contenant des administrateurs. Il existe des rôles donnant des permissions de lecture et d’écriture sur des menus d’Entra ID, d’autres de lecture exclusif sur le portail Defender, d’autres sur Intune, d’autres de lecture sur des logs, etc. Il faut noter que ces rôles sont pilotés au sein d’Entra ID, nerf de l’écosystème Azure.
Les admins s’appuient sur des rôles natifs comme par exemple :
Le rôle Intune Administrator consiste à donner les pleins pouvoirs à celui ou celle qui le détient sur tout ce qui se trouve dans la console Intune, mais pas que. Cette personne possède également des droits dans Entra ID, notamment sur les groupes et les appareils en lecture mais aussi en écriture. Un droit donc à distribuer avec parcimonie d’autant que, par défaut, il n’est pas “scopable”.
Un rôle Entra ID non “scopable” signifie que son périmètre s’étend à l’ensemble de l’annuaire. En effet, il faut envisager l’annuaire Azure AD comme étant à plat et non à travers un schéma hiérarchique.
Dans les grandes organisations, il est difficile d’imaginer la totalité des admins pouvant effectuer des actions de masse sur plusieurs pays ou BU différents. C’est l’une des raisons pour laquelle les Administrative Units (AU) ont vu le jour. Il s’agit d’une fonctionnalité développée par Microsoft dans Entra ID pour limiter un périmètre (groupe d’appareils ou d’utilisateurs) aux admins possédant un rôle Entra ID.
En tant qu’expert Intune, la lecture des clés Bitlocker stockées sur Azure AD est un cas d’usage fréquemment rencontré. Pour éviter que TOUTES les clés soient lues par TOUS les admins ayant le rôle dédié, on “scope” le rôle seulement sur les admins FR afin qu’ils puissent faire les actions du rôle (lecture des clés) seulement sur les machines FR.
Lorsqu’il s’agit d’un autre pays, on crée une autre Administrative Unit BE pour la Belgique, par exemple. Puis, on y lie les postes de travail BE pour que seuls les admins BE puissent lire les clés de chiffrement de ces appareils BE, et ainsi de suite.
A noter que les AU ne sont pas des OU. Dans Intune, une Organizational Unit (OU) se définit comme un conteneur dans l’Active Directory on-premise dans lequel on place des stratégies, des groupes, des imbrications, etc. Il faut voir une AU comme une étiquette que l’on place sur les appareils et sur lesquels on lie des permissions précises pour des admins précis.
En marge des rôles Entra ID, il existe aussi des rôles qui sont propres à Intune. Leur gestion ne peut d’ailleurs se faire que dans la console Intune.
Un rôle Intune permet de donner des droits aux administrateurs pour œuvrer seulement dans la console Intune que ce soit sur les appareils mobiles ou les postes. Ainsi, un admin peut très bien avoir les droits pour gérer les applications mobiles et postes de travail sans avoir les droits pour gérer les configurations des appareils.
À noter qu’il n’est pas utile de combiner un rôle Intune au rôle Entra ID « Intune Administrator » puisque ce dernier comprendra implicitement les permissions du rôle Intune.
Un rôle Intune se décompose ainsi :
Prenons l’exemple d’un rôle donnant des accès d’écriture sur les types d’objets Intune que sont les applications, les appareils, les configurations, etc. Il s’agit de permissions. Ce rôle doit alors être assigné sur plusieurs groupes pays mais les admins ne doivent pouvoir lire uniquement les objets Intune de leurs pays. Alors, on peut créer au sein du même rôle écriture un assignement par pays (FR, BE, NL, BR, etc) afin que chaque scope soit étanche avec son voisin, sur cette même base de permissions d’écriture.
Un assignement dans Intune est composé de :
C’est donc avec cette combinaison de permissions et de scopes que les admins peuvent interagir sur les mêmes outils Cloud.
Il est important de découper avec attention les périmètres et les équipes correspondantes au préalable. Cette tâche amont permet au mieux de retranscrire le modèle de l’entreprise dans les différents outils et de suivre son évolution.
D’autre part, les accès aux outils Cloud tels qu’Intune se couple à de l’accès conditionnel dans Entra ID. Ainsi, on peut limiter les accès au portail Intune aux machines enrôlées dans le MDM (Mobile Device Management) et respectant les normes de sécurité définies comme l’antivirus, l’EDR, le chiffrement, la complexité mot de passe, le Secure Boot, la double authentification, etc.
Enfin, il est possible de s’appuyer sur des rôles temporaires le temps d’une ou plusieurs actions (Priviliged Identity Management Role). Les permissions prennent fin dès que l’action se termine.
Articles similaires
Microsoft a annoncé le 20 septembre dernier la dépréciation de Windows Server Update Services (WSUS) à compter de Windows Server...
Avec la croissance des fusions, acquisitions et réorganisations internes, la migration de tenant à tenant dans Microsoft 365 est un...
Pourquoi migrer vers Microsoft 365 ? Face à l’évolution constante des technologies numériques, les entreprises sont confrontées à un choix...