none
Renforcement Active Directory : les comptes priviligiés RRS feed

  • Question

  • Bonjour,

    Je me renseigne sur les méthodes de renforcement de l'Active Directory  (pour ma part Windows Server 2016 )

    Microsoft préconise d'appliquer le modèle d'administration 3 tiers pour l'administration de l'infrastructure :

      - niveau 0 : les ordinateurs concourant au fonctionnement de l'AD  (contrôleurs de  domaine CD, forêt ...)

      - niveau 1 : les serveurs membres et leurs applications

      - niveau 2 : les stations de travail et autres équipements.

    Pour chaque niveau un compte avec privilège doit être défini en respectant la règle qu'un compte de niveau X ne peut se connecter à un niveau X+1 ou X-1.

    Par conséquent, un administrateur SI doit posséder 4 comptes :

       - 1 compte nominatif sans privilège pour accéder à sa bureautique, messagerie, internet...

       et 1 compte nominatif  pour chacun des 3 niveaux .

    • Compte administrateur pour les workstations

    Pour le niveau 0, l'ANSSI  recommande d'utiliser un compte administrateur local qui doit être unique par machine et changé régulièrement. Microsoft fournit une application gratuite : LAPS. On peut donc se passer du compte nominatif pour le niveau 2 (postes de travail). Par contre on ne sera pas capable à posteriori de déterminer qui s'est connecté  en tant qu'administrateur local.

    • Qu'est ce qui est recommandé pour les serveurs membres ?

                   - un compte nominatif du domaine, administrateur local de chaque serveur qui entre dans le périmètre d'action de l'administrateur pour respecter la règle du moindre privilège?

                   - utiliser le compte administrateur local mis à jour par LAPS ? par contre les traces ne permettront pas de distinguer formellement l'administrateur.

    • Pour accéder à chaque niveau (dans mon cas niveau 0 et 1), un poste d'administration dédié, isolé d'Internet  devrait être utilisé. L'administrateur se connectera avec son compte d'administrateur correspondant à ce niveau. 

          J'envisage de créer des GPO par niveau pour empêcher les administrateur des autres niveaux d'ouvrir une session locale, une session bureau à distance , d'accéder par le réseau, lancer une tâche en tant que... Cela suppose donc de créer un groupe distinct d'administrateurs pour les niveau 0 et 1.

           Pour isoler les contrôleurs de domaine des autres serveurs membres (donc niveaux 0 et 1), faut il aller jusqu'à créer un VLAN pour les CD et un VLAN pour les serveurs membres, quitte à mettre en place des ACL  sur les équipements réseau de niveau 3 et à forcer l'utilisation de ports protocolaires fixes ?

         J'aimerai, selon vos expériences, que vous me confirmiez que je vais bien dans la bonne direction et je suis preneur de tout conseils supplémentaire dans ce domaine

       Cordialement 

       Christophe

     

    vendredi 13 septembre 2019 12:31

Toutes les réponses

  • Bonjour,

    Je vais faire une réponse simple à vos questions :

    • Les recommandations de l'ANSSI sont plutôt bonnes, mais orientées pour des SI plutôt importants
    • Appliquer leurs recommandations à la lettre dans un petit SI peut devenir une faille de sécurité : en effet, imaginez un SI avec 2 administrateurs : s'ils doivent avoir chacun 3 comptes nominatifs, sous peu de temps, ils utiliseront le compte avec le maximum de privilège...
      Par contre, s'il existe une équipe suffisante, les administrateurs auront un compte nominatif dans le tiers qui les concerne => pas de risque

    Idem pour les administrateurs locaux.

    Du coup, il faut commencer par se poser la question suivante : si on segmente les privilèges (donc les rôles), a-ton l'équipe suffisante pour distribuer ces rôles ?

    Si ce n'est pas le cas, il faut imaginer un découpage avec moins de tiers.


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    WWW : http://snsv.consulting | Blog : http://sylvaincoudeville.fr

    "Aléatoire" et "Mystérieux" sont des qualificatifs inventés par l'Homme pour éviter de dire qu'il n'a pas trouvé la root cause du problème...


    vendredi 13 septembre 2019 12:39
  • Merci pour ta réponse rapide?

    Je travaille sur la migration d'une insfractucture vers une nouvelle qui devra être homologuée. D'où mes lectures approfondies des guides e l'ANSSSI

    L'équipe d'administration est bien fournie (administrateur Windows, Linux, Stockage, SGBD, reseaux) sans compter une cinquantaine de développeurs qu'il faut freiner.

    Je maintiens donc ce découpage en 3 tiers.

    Cordialement

    Christophe

    vendredi 13 septembre 2019 13:10
  • Bonjour,

    D'expérience chez plusieurs clients, nous utilisons 3 comptes.

    - 1 utilisateur standard pour la bureautique.

    - 1 admin de tous les serveurs.

    - 1 admin du domaine qui est utilisé que très rarement (généralement ajouté temporairement dans le groupe administrateurs du domaine).

    Pour les stations de travail, l'administrateur local + utilisateur standard permet de réaliser les dépannages et l'accès aux ressource réseau. Les personnes en charge de la partie poste de travail on un compte admin juste sur les workstations (mais pas génial selon moi).

    L'utilisation du compte administrateur local couplé avec LAPS (pour la gestion du mot de passe) est une bonne solution. Car il y a moins de risque d'attaque horizontale.

    Couplé avec l'UAC et un peu de hardeming (MSC) donne de bon résultat :

    https://docs.microsoft.com/fr-fr/windows/security/threat-protection/security-compliance-toolkit-10

    https://www.microsoft.com/en-us/download/details.aspx?id=55319

    Je rejoins Sylvain, trop de sécurité et tous le monde utilise un compte admin du domaine.

    Donc :

    - Peu de compte admin du domaine (privilégier les délégations).

    - Utiliser le moins possible sur les workstations des compte du domaine qui peuvent avoir des droits élevés sur le reste de l’infrastructure.

    - utiliser le groups 'protected users' pour les administrateurs

    http://www.pbarth.fr/node/334

    Cordialement


    Benoit

    vendredi 13 septembre 2019 13:34
  •     J'envisage de créer des GPO par niveau pour empêcher les administrateur des autres niveaux d'ouvrir une session locale, une session bureau à distance , d'accéder par le réseau, lancer une tâche en tant que... Cela suppose donc de créer un groupe distinct d'administrateurs pour les niveau 0 et 1.

    C'est un peu le principe de l'authentification par Silo. Les groupes comme protected users est déja une étape.

    https://www.sstic.org/2017/presentation/administration_en_silo/

    Les recommandations de l'ANSSI sont plutôt bonnes, mais orientées pour des SI plutôt importants

    La majorité des conseils sont des éléments de base qui concernent tout ce qui souhaite avoir un minimum de sécurité et non une élite qui cherche un maximum.

    Il n'est pas utile de tout appliquer à la lettre, mais d'adapter par rapport à son environnement. 

    vendredi 13 septembre 2019 14:30
  • Bonsoir,

    l'utilisation de LAPS permet simplement de gérer/bloquer le compte administrateur local par défaut.

    => Ce compte ne doit être utilisé que si il ne reste pas d'autres options.

    LAPS ne dispense pas de créer d'autres comptes "nominatifs"(locaux ou du domaine) avec les droits suffisants pour administrer les stations.

    Les 3 niveaux de séparations de droits doivent être adaptés à la taille de l'organisation.

    => La philosophie est qu'aucun compte(/voire utilisateur?) n'ait les droits complets sur tous les (3) niveaux: Domaines/Forêts, Serveurs, Stations.

    A bientôt,


    Thierry DEMAN-BARCELO. Offce Apps&Services MVP. MCSE:Messaging 2016,MCSE:Server Infrastructure 2016(87 MCPs). MCSA Office 365,Microsoft 365 Certified: Messaging Administrator Associate,Modern Desktop Administrator Associate https://base.faqexchange.info

    vendredi 13 septembre 2019 18:06
  • [...] Par contre on ne sera pas capable à posteriori de déterminer qui s'est connecté  en tant qu'administrateur local.

    ==> Tout à fait, mais tel n'est pas l'objectif de LAPS. Cependant, il faut garder à l'esprit que seuls les membres du Groupe Domain Admins pourront voir (by design) les pw du compte administrator des machines gérées, par conséquent, ça restreint fortement l'usage de ces compte locaux.

    • Qu'est ce qui est recommandé pour les serveurs membres ?

                   - un compte nominatif du domaine, administrateur local de chaque serveur qui entre dans le périmètre d'action de l'administrateur pour respecter la règle du moindre privilège?

    ==> Toujours un compte nominatif, les comptes génériques c'est LE MAL ! Par conséquent, un compte nominatif de domaine, membre du groupe d'administration TiersX qui va bien, qui n'a le droit d'ouvrir une session que sur les serveurs TiersX et les postes d'administration TiersX. Ce n'est le le compte qui a directement les droits sur les postes/serveurs du Tiers concerné, mais le groupe. On ne doit jamais, non jamais accorder des droits à un compte mais à un groupe.

                   - utiliser le compte administrateur local mis à jour par LAPS ? par contre les traces ne permettront pas de distinguer formellement l'administrateur.

    ==> Tout à fait, tu as tout compris. Administrator est générique on ne sait pas qui est derrière. LAPS permet d'assurer la gestion des mots de passe et de "garantir" une restriction d'usage à des cas exceptionnels. De plus, un compte local, n'a des droits que localement, pas très pratique dans un domaine pour faire certains actes d'administration.

    Pour de dernier point que tu évoques, c'est ce que recommande l'ANSI en effet. Je sors de plusieurs années chez un grand compte qui avait mis en oeuvre ce type de pratique.

    • un compte nominatif me permettant de me connecter sur l'ensemble des postes de travail Tiers3 (ceux qui ont accès à internet et à la messagerie). Membres de groupes me permettant d'accéder à des ressources (shares, appli, ...) comme n'importe quel utilisateur. Pas membre du groupe d'administrateur local, par défaut, mais sur demande on pouvait le devenir. Là, mon expérience personnelle recommande d'être extrêmenent prudent et vigilant. Mettre en place un process strict du style "Moindre remontée dans les outils du SOC (Security Office Center) impactant ce type de poste, ... remasterisation immédiate, rappel à l'ordre sévère du collaborateur, voire sanction". Pour la petite histoire, il y a peu, je montrais à un collègue, en interne dans ma boite, comment un hackeur pouvait entamer sa phase de reconnaissance (simple demande de transfert de zone DNS si mal configuré). Je me suis fait toper immédiatement par notre SOC, et j'ai du me justifier. Pas de bobo, merci tout va bien.
    • un compte nominatif me permettant de me connecter sur l'ensemble des serveurs et postes d'administration du Tiers concerné (en l'occurence il y en avait 3 (DC, sensibles, moins sensibles), mais on pourrait envisager de restreindre à 2 (DC, serveurs).

    Chacun de ces comptes à une convention de nommage distinctive qui permet de le ... distinguer.

    De plus, Un compte membre d'un groupe tiers quelquonque ne peut pas accorder les droits d'être dans un groupe de niveau supérieur au sien.

    Indispensable également de mettre sous surveillance les groupes Tiers sensibles (ajout/sup de membres).

    Gestion des comptes de service par GMSA en respectant les best practices : ce n'est pas la machine qui a délégation auprès de l'AD pour gérer le changement du pw dudit compte, mais un groupe de sécurité de domaine (peuplé avec des comptes machines of course). Intérêt : Moins de comptes de services pour un rôle donné (un GMSA SQL_svc, un autre NBU_svc, un autre ....). Un GMSA particulier pour les tâches planifiées par Tiers (pour tous les cas, ou une tâche planifiée ou le script qu'elle exécute requiert des privilèges sur le domaine ou d'autres machine). Ce dernier peut faire juste ce qu'il doit faire, rien de plus (principe du moindre privilège). 

    Pour isoler les contrôleurs de domaine des autres serveurs membres (donc niveaux 0 et 1), faut il aller jusqu'à créer un VLAN pour les CD et un VLAN pour les serveurs membres, quitte à mettre en place des ACL  sur les équipements réseau de [...].

    Pas seulement pour les serveurs mais également pour les postes d'administration. Ca semble lourd mais en fait ça apporte un niveau de sécurité supplémentaire. un poste d'administration ne dit pas avoir acces à internet, comme les serveurs. 

    Après, il y a des trucs opérationnels auxquels il faut penser, mais que ce client n'avait pas totalement pris en compte.

    • Besoin d'avoir des modules PS en provenance d'internet et de mettre à jour régulièrement ces modules dont les cmdlets sont utlisées au quotidien directement ou dans des scripts. ==> Mettre en place un repository interne (il y a différentes manières pour ça), configurer les machines via GPO pour avoir ledit repository configuré et en Trusted, Process particulier à définir et à respecter déterminant qui et comment le repo interne peut être mis à jour, ... également source de mise à jour pour Update-help.
    • Besoin d'avoir un repository de binaires internes (windows et linux) : une ou des solutions de distribution (wsus, RedHatSatellite, SuseManager, ...)
    • Configurer le Remote Shell et le remote Management par défaut ... et on n'oubliera pas le lobbying forcené, couplé à des ateliers de sensibilisation/formation, à faire auprès des équipes d'administration (notamment Windows) pour limiter l'usage intensif du RDP. Que celui qui se connecte en RDP sur une machine distante pour la redémarrer, voir l'état de tel ou tel service, consulter les eventlogs, et pleins d'autres tâches quotidiennes d'administration soit pendu haut et court jusqu'à ce que mort s'en suive.  Le remoteManagement et le remote shell ce n'est pas pour les chiens. De plus, on peut toujours envisager d'installer un WAC (Windows Admin Center) bien comme il faut avec HA et tout et tout dans un environnement dédié. Ainsi, ceux qui ne peuvent pas de passer de GUI, seront heureux.
    • On peut (devrait) également configurer le Remoteshell/RemoteManagement pour utiliser https au lieu de http par défaut (facile par GPO).
    • Mettre en place le logging powershell (via GPO. Il y a pleins de documents sur ce sujet sur le net).
    • Durcissement des postes d'administration (PAW - securing-privileged-access/privileged-access-workstations, ...)

    Un dernier point : On n'est pas obligé de mettre cela en place partout. Je m'explique. Imaginons que nous ayons 2 domaines distincts, sans aucun lien entre eux. Dans le premier, il y a des utilisateurs, des groupes d'administration de différents  niveaux, et accès à internet possible. Dans le second (extranet par exemple), il n'y a pas de postes de travail, il n'y a que des serveurs et des groupes d'administration. Pas d'accès internet possible depuis les serveurs et les postes d'administration, VLANs spécifiques et isolés du reste de l'infra. Doit-on mettre en place le même type de solution ? Peut-être mais dans une mesure moindre.

    Comme l'a dit Thierry : => La philosophie est qu'aucun compte(/voire utilisateur?) n'ait les droits complets sur tous les (3) niveaux: Domaines/Forêts, Serveurs, Stations.

    Je rajouteraisque les emmer... (comprendre usurpation d'identité, élévation de privilèges, compromission de données, ...) ne viennent pas toujours de vilains méchants situés dans un lointain pays et qui portent des noms qui ne sont pas "de chez nous". Le mec du bureau d'à côté, oui, tu sais celui qui est aigri parce qu'il n'a pas eu d'augmentation alors qu'il avait fait des efforts et ne jettait plus le papier essuie-main par terre après usage mais dans la corbeille dédiée à cet effet, et bien ... regarde le de plus près ? Bon sang, mais c'est bien sur, c'est lui qui a lancé ce pu... de crypto-locker qui m'a donné du boulot pendant 1 semaine. L'enfoiré ! Et le DBA dont la femme s'est cassé avec le mec du marketing (houais, je suis d'accord, font chi... ces marketeux, zont pas de morale. ca se fait pas de prendre la femme d'un collègue), ça ne serait pas lui qui aurait foutu la grouille en diffusant sur le Net les documents confidentiels de la stratégie de l'entreprise, documents auxquels il avait accès par son activité de DBA, juste pour faire porter le chapeau à l'autre enfoi... du marketing ? (c'est couillon, car un coup de bate de base-ball, pas derrière la tête trop définitif, mais dans les genoux, quand le mec fait son footing matinal, aurait pu tout aussi bien faire l'affaire. :-) ). Bon j'arrête là.

    Olivier

    samedi 14 septembre 2019 05:33
  • Merci Benoit, Philipp, Thierry et Olivier pour vos réponses bien détaillées.

    J'ai 3 points à éclaricir :

    • faut-il un poste d'administration dédié à chaque niveau (tiers ou sillo) ou les administrateurs peuvent ils se connecter sur ces postes avec leur compte d'administration nominatif unique pour chacun des niveaux ?
    • J'ai lu qu'il était possible si on ne pouvait multiplier les postes physiques d'administration, d'avoir un poste dédié d'administration sur lequel on pouvait lançait une machine virtuelle pour accéder à sa session de travail niveau 3. (sillo workstation).     

           Je suppose que ce poste physique idéalement ne devrait pas accéder à Internet. Si la session utilisateur membre du domaine a un accès Internet, en quoi cette solution est plus sécurisée que l'architecture inverse : poste avec session utilisateur du domaine depuis laquelle on peut lancer une VM d'administration ? Le mécanisme de virtualisation nous assure t'il qu'aucune interaction entre la VM hébergée et l'OS de la station höte ne peut se produire ?

    • Comment traite t'on les services de gestion des ordinateurs utilisés dans au moins 2 niveaux différents : exemple WSUS, sauvegarde ?

           Les contrôleurs de domaine et autres entités du niveau 0 (Tier 0 ou sillo rouge) doivent être mis à jour au niveau sécurité. Faut il un WSUS dédié à ce niveau et indépendant des autres niveaux, soit un WSUS par niveau ? Ou peut-on disposer d'un seul serveur WSUS accessible par les entités des 3 niveaux ?

           Pour la sauvegarde on utilise Veeam Backup et Replication avec 1 job de sauvegarde pour l'ensemble de l'infrastructure. Pour se coller au découpage par sillo, il faudrait créer des profils sous Veeam : un pour chaque niveau, avec sauvegarde des entités du niveau 0 (les CD donc l'AD), un profil pour les serveurs du niveau 1 et un dernier pour le niveau 2. Un seul serveur physique serait suffisant en s'assurant de mettre en place les bons ACL pour  les dossiers hébergeant les sauvegardes ? Pour chaque niveau, l'administrateur dédié aurait alors en charge l'externalisation séparée des fichiers physiques de la sauvegarde de son niveau.

          Merci d'avance pour vos conseils

         Christophe


    • Modifié OutalNau lundi 16 septembre 2019 07:17
    lundi 16 septembre 2019 07:07
  • faut-il un poste d'administration dédié à chaque niveau (tiers ou sillo) ou les administrateurs peuvent ils se connecter sur ces postes avec leur compte d'administration nominatif unique pour chacun des niveaux ?

    C'est le principe d'isolement en silo des PAW (Privilieged Access Workstation). Sur un PAW Tier X, il ne doit y avoir que des comptes du même niveau. 

    J'ai lu qu'il était possible si on ne pouvait multiplier les postes physiques d'administration, d'avoir un poste dédié d'administration sur lequel on pouvait lançait une machine virtuelle pour accéder à sa session de travail niveau 3. (sillo workstation).     

    Tout à fait, mais le poste physique ne dit pas permettre de compromettre les postes virtuels. Attention à ce qu'on fait.

    Comment traite t'on les services de gestion des ordinateurs utilisés dans au moins 2 niveaux différents : exemple WSUS, sauvegarde ?

    IL faut distinguer l'utilisation d'un applicatif, et la connection sur un serveur hébergant ledit applicatif. 

    Si les applicatifs ont du RBAC, çela permet de faire une administration différentiée, mais ce n'est pas pour autant que tout le monde doit se connecter sur le serveur correspondant. SI on peut installer une console déportée, tant mieux.

    Pour prendre un exemple bien chiant : Netbackup. Avec le console (par défaut, sur le serveur, mais tu peux l'installer sur une machine déportée), bon avec NBU, depuis la console, tu as tous les droits qu'à la dite console et en plus avec son compte (générique) de service. Il existe bien un addon pour gérer ça, mais il génère masse de pb à chaque mise à jour. Bref, une galère. Et là, il faut se creuser. La solution : uune infra NBU dédié pour les DCs et une autre pour le reste (en mode licence volume NBU, no pb), mais j'avoue que c'est très chiant.

    Les contrôleurs de domaine et autres entités du niveau 0 (Tier 0 ou sillo rouge) doivent être mis à jour au niveau sécurité. Faut il un WSUS dédié à ce niveau et indépendant des autres niveaux, soit un WSUS par niveau ? Ou peut-on disposer d'un seul serveur WSUS accessible par les entités des 3 niveaux ?

    Un seul suffit.

    Oliv

    lundi 16 septembre 2019 07:41