Définir des rôles pour Privileged Access Management

  • Article

Avec Privileged Access Management, vous pouvez affecter des utilisateurs à des rôles privilégiés qu’ils peuvent activer si nécessaire pour un accès juste-à-temps. Ces rôles sont définis manuellement et établis dans l’environnement bastion. Cet article vous guide tout au long du processus de détermination des rôles à gérer par le biais de PAM et de leur définition avec des restrictions et des autorisations appropriées.

Important

le modèle de cet article est destiné uniquement aux environnements Active Directory isolés à l’aide de MIM PAM. Pour les environnements hybrides, consultez à la place les conseils dans le modèle d’accès aux entreprises.

Une approche simple de la définition des rôles pour la gestion de l’accès privilégié consiste à compiler toutes les informations dans une feuille de calcul. Énumérez les rôles dans les rôles et utilisez les colonnes pour identifier les autorisations et les exigences de gouvernance.

Les exigences de gouvernance varient en fonction des stratégies d’identité et d’accès existantes, ainsi que des critères de conformité. Voici quelques exemples de paramètres à identifier potentiellement pour chaque rôle :

  • son propriétaire ;
  • les utilisateurs candidats susceptibles de l’occuper ;
  • les contrôles d’authentification, d’approbation ou de notification qui doivent être associés à son utilisation.

Les autorisations des rôles dépendent des applications gérées. Cet article utilise Active Directory comme exemple d’application, classant les autorisations en deux catégories :

  • celles nécessaires à la gestion du service Active Directory proprement dit (par exemple, configuration de la topologie de réplication) ;

  • celles nécessaires à la gestion des données contenues dans Active Directory (par exemple, création d’utilisateurs et de groupes).

Identifier les rôles

Commencez par identifier tous les rôles que vous souhaitez gérer avec PAM. Sur la feuille de calcul, chaque rôle potentiel aura sa propre ligne.

Pour rechercher les rôles appropriés, pensez à la gestion de chaque application :

  • L’application est-elle de niveau 0, 1 ou 2 ?
  • Quels sont les privilèges ayant un impact sur la confidentialité, l’intégrité ou la disponibilité de l’application ?
  • L’application a-t-elle des dépendances vis-à-vis d’autres composants du système, Par exemple, existe-t-il des dépendances sur les bases de données, la mise en réseau, l’infrastructure de sécurité, la virtualisation ou la plateforme d’hébergement ?

Déterminez comment grouper ces considérations relatives aux applications. Les rôles doivent avoir des limites claires et donner uniquement les autorisations suffisantes pour effectuer des tâches administratives courantes dans l’application.

Vous devez toujours créer des rôles pour l’attribution de privilèges minimum. Elle peut s’appuyer sur les responsabilités organisationnelles actuelles (ou planifiées) des utilisateurs et comprend les privilèges dont ont besoin les utilisateurs pour effectuer leurs tâches. Elle peut aussi inclure les privilèges qui simplifient les opérations, sans créer de risque.

Voici les autres points à prendre en considération pour définir la portée des autorisations d’inclusion de rôle :

  • Combien y a-t-il de personnes qui officient dans un rôle particulier ? S’il n’y en a pas au moins deux, le rôle est peut-être défini trop étroitement pour être utile ou vous avez défini les fonctions d’une personne spécifique.

  • Combien de rôles une personne assume-t-elle ? Les utilisateurs sont-ils en mesure de choisir le rôle qui correspond à leur tâche ?

  • La population d’utilisateurs et la façon dont ceux-ci interagissent avec les applications sont-elles compatibles avec Privileged Access Management ?

  • Est-il possible de séparer l’administration de l’audit, de sorte qu’un utilisateur ayant un rôle d’administrateur ne puisse pas effacer les enregistrements d’audit de leurs actions?

Établir les exigences de gouvernance des rôles

Au moment d’identifier des rôles candidats, commencez par compléter la feuille de calcul. Créez des colonnes pour les exigences appropriées à votre organisation. Voici quelques-unes des exigences à prendre en considération :

  • Qui est le propriétaire du rôle qui sera chargé de mieux définir le rôle, de choisir les autorisations et de gérer les paramètres de gouvernance du rôle ?

  • Qui sont les détenteurs du rôle (utilisateurs) qui effectuent les tâches associées ?

  • Quelle est la méthode d’accès (sujet abordé dans la section suivante) qui conviendrait pour les détenteurs du rôle ?

  • Un utilisateur qui active son rôle doit-il faire l’objet d’une approbation manuelle de la part du propriétaire du rôle ?

  • Un utilisateur qui active son rôle doit-il être suivi d’une notification ?

  • L’utilisation de ce rôle doit-elle générer une alerte ou une notification dans un système SIEM à des fins de suivi ?

  • Est-il utile de limiter les utilisateurs pouvant activer le rôle aux seuls utilisateurs pouvant se connecter à des ordinateurs quand l’exécution des tâches liées au rôle nécessite un accès et quand l’hôte est suffisamment vérifié pour empêcher, le cas échéant, toute utilisation incorrecte des privilèges/informations d’identification ?

  • Est-il nécessaire de fournir aux détenteurs du rôle une station de travail dédiée à l’administration ?

  • Quelles sont les autorisations d’application (voir l’exemple de liste pour AD ci-dessous) associées à ce rôle ?

Sélectionner une méthode d’accès

Dans un système de gestion des accès privilégiés, il peut y avoir différents rôles disposant des mêmes autorisations, notamment si différentes communautés d’utilisateurs ont des exigences distinctes de gouvernance des accès. Par exemple, une organisation peut appliquer différentes stratégies pour leurs employés à plein temps et pour les employés qui viennent d’une autre entreprise.

Il peut arriver, dans certains cas, qu’un utilisateur se voie attribuer un rôle à titre permanent. Dans ce cas, il n’a pas besoin de demander ni d’activer une attribution de rôle. Voici quelques exemples de scénarios d’attribution permanente :

  • Compte de service administré dans une forêt existante.

  • Compte d’utilisateur de la forêt existante, dont les informations d’identification sont gérées en dehors de PAM. Il peut s’agir d’un « compte de secours », qui aurait besoin d’un rôle tel que « Maintenance du domaine / contrôleur de domaine » pour résoudre des problèmes de confiance et d’intégrité du contrôleur de domaine notamment. En tant que compte brise-verre, le rôle aurait été affecté de façon permanente avec un mot de passe sécurisé physiquement)

  • Compte d’utilisateur de la forêt d’administration qui s’authentifie avec un mot de passe. Il peut s’agir d’un utilisateur qui a besoin d’autorisations d’administration permanentes 24 heures sur 24 et 7 jours sur 7 et ouvre une session sur un appareil non compatible avec l’authentification forte.

  • Compte d’utilisateur de la forêt d’administration disposant d’une carte à puce ou d’une carte à puce virtuelle (par exemple, un compte doté d’une carte à puce hors connexion nécessaire pour effectuer des tâches de maintenance peu fréquentes).

Déléguer des autorisations Active Directory

Windows Server crée automatiquement des groupes par défaut tels que « Admins du domaine » lors de la création de domaines. Ces groupes simplifient la prise en main et peuvent être adaptés aux organisations de petite taille. Les grandes organisations, ainsi que celles qui ont besoin d’un meilleur isolement des privilèges administratifs, doivent vider ces groupes et les remplacer par des groupes qui fournissent des permissions affinées.

Le groupe Admins du domaine ne peut pas avoir de membres issus d’un domaine externe. Autre limitation, il accorde des autorisations pour trois fonctions distinctes :

  • Gestion du service Active Directory proprement dit
  • Gestion des données contenues dans Active Directory
  • Activation des ouvertures de session distantes sur les ordinateurs joints au domaine.

À la place des groupes par défaut, comme Administrateurs de domaine, créez des groupes de sécurité qui fournissent seulement les autorisations nécessaires. Utilisez ensuite MIM pour intégrer de manière dynamique les comptes Administrateur à ces groupes.

Autorisations de gestion de service

Le tableau suivant donne des exemples d’autorisations qu’il serait pertinent d’inclure dans des rôles pour gérer Active Directory.

Role Description
Maintenance de domaine/contrôleur de domaine L’appartenance au groupe Domaine\Administrateurs permet de dépanner et de modifier le système d’exploitation du contrôleur de domaine. Sont possibles également les opérations telles que la promotion d’un nouveau contrôleur de domaine vers un domaine existant dans la forêt et la délégation de rôle AD.
Gestion des machines virtuelles Gestion des machines virtuelle du contrôleur de domaine à l’aide du logiciel d’administration de la virtualisation. Vous pouvez accorder ce privilège par le biais d’un contrôle total de toutes les machines virtuelles dans l’outil d’administration ou à l’aide de la fonctionnalité de contrôle d’accès en fonction du rôle (RBAC).
Extension du schéma Gestion du schéma consistant notamment à ajouter de nouvelles définitions d’objets, à modifier les autorisations sur les objets du schéma et à modifier les autorisations par défaut du schéma pour les types d’objets.
Sauvegarde de la base de données Active Directory Création d’une copie de sauvegarde de la base de données Active Directory dans son intégralité, y compris tous les secrets confiés au contrôleur de domaine et au domaine.
Gestion des approbations et des niveaux fonctionnels Création et suppression d’approbations associées à des domaines et forêts externes.
Gestion des sites, des sous-réseaux et de la réplication Gestion des objets de la topologie de réplication Active Directory, consistant notamment à modifier des sites, des sous-réseaux et des objets lien de site, et à lancer les opérations de réplication.
Gestion d’objets GPO Création, suppression et modification d’objets de stratégie de groupe (GPO) à l’échelle du domaine.
Gestion de zones Création, suppression et modification de zones et d’objets DNS dans Active Directory.
Modification d’unités d’organisation de niveau 0 Modification d’unités d’organisation de niveau 0 et des objets contenus dans Active Directory.

Autorisations de gestion de données

Le tableau suivant donne des exemples d’autorisations qu’il serait pertinent d’inclure dans des rôles pour gérer ou utiliser les données contenues dans AD.

Rôle Description
Modification d’unité d’organisation d’administration de niveau 1 Modification des unités d’organisation contenant des objets d’administration de niveau 1 dans Active Directory
Modification d’unité d’organisation d’administration de niveau 2 Modification des unités d’organisation contenant des objets d’administration de niveau 2 dans Active Directory
Gestion des comptes : création/suppression/déplacement Modification des comptes d’utilisateurs standard.
Gestion des comptes : réinitialisation/déverrouillage Réinitialisation des mots de passe et déverrouillage des comptes.
Groupe de sécurité : création/modification Création et modification des groupes de sécurité dans Active Directory.
Groupe de sécurité : suppression Suppression des groupes de sécurité dans Active Directory.
Gestion des objets de stratégie de groupe Gestion de tous les objets de stratégie de groupe (GPO) du domaine/forêt qui n’affectent pas les serveurs de niveau 0.
Jonction des PC/administrateur local Droits d’administration locaux sur toutes les stations de travail.
Jonction des serveurs/administrateur local Droits d’administration locaux sur tous les serveurs.

Exemples de définitions de rôle

Le choix des définitions de rôles dépend du niveau des serveurs gérés. Il dépend également du choix des applications gérées. Certaines applications, notamment Exchange ou d’autres produits d’entreprise tiers comme SAP, s’accompagnent souvent de leurs propres définitions de rôles supplémentaires pour l’administration déléguée.

Les sections suivantes donnent des exemples de scénarios d’entreprise types.

Niveau 0 - Forêt d’administration

Voici quelques rôles pouvant convenir aux comptes de l’environnement bastion :

  • Accès d’urgence à la forêt d’administration
  • Administrateurs « carton rouge » : utilisateurs ayant le rôle d’administrateur de la forêt d’administration
  • Utilisateurs ayant le rôle d’administrateur de la forêt de production
  • Utilisateurs dotés de droits d’administration limités délégués sur les applications de la forêt de production

Niveau 0 - Forêt de production d’entreprise

Voici quelques rôles adaptés à la gestion des comptes et des ressources d’une forêt de production de niveau 0 :

  • Accès d’urgence à la forêt de production
  • Administrateurs de la stratégie de groupe
  • Administrateurs DNS
  • Administrateurs de l’infrastructure à clé publique (PKI)
  • Administrateurs de la topologie et de la réplication AD
  • Administrateurs de la virtualisation des serveurs de niveau 0
  • Administrateurs du stockage
  • Administrateurs des stratégies anti-programme malveillant pour les serveurs de niveau 0
  • Administrateurs SCCM pour SCCM de niveau 0
  • System Center Operations Manager admins pour le niveau 0 Operations Manager
  • Administrateurs de sauvegarde de niveau 0
  • Utilisateurs de contrôleurs hors bande et de gestion de la carte de base (pour la gestion KVM ou « LOM » à distance) connectés à des hôtes de niveau 0

Niveau 1

Voici quelques rôles adaptés à la gestion et à la sauvegarde de serveurs de niveau 1 :

  • Maintenance des serveurs
  • Administrateurs de la virtualisation des serveurs de niveau 1
  • Compte d’analyse de la sécurité
  • Administrateurs des stratégies anti-programme malveillant pour les serveurs de niveau 1
  • Administrateurs SCCM pour SCCM de niveau 1
  • System Center Operations Manager admins pour le niveau 1 Operations Manager
  • Administrateurs de sauvegarde des serveurs de niveau 1
  • Utilisateurs de contrôleurs hors bande et de gestion de la carte de base (pour la gestion KVM ou« LOM » à distance) connectés à des hôtes de niveau 1

Voici en outre quelques rôles adaptés à la gestion d’applications d’entreprise de niveau 1 :

  • Administrateurs DHCP
  • Administrateurs Exchange
  • Administrateurs Skype Entreprise
  • Administrateurs de batteries de serveurs SharePoint
  • Administrateurs d’un service cloud, par exemple, un site web d’entreprise ou un serveur DNS public
  • Administrateurs de systèmes HCM, financiers ou juridiques

Niveau 2

Voici quelques rôles adaptés à la gestion des ordinateurs et des utilisateurs non administrateurs :

  • Administrateurs de comptes
  • Support technique
  • Administrateurs de groupes de sécurité
  • Support technique des stations de travail

Étapes suivantes