Un compte privilégié est un compte qui possède plus de privilèges qu’un utilisateur ordinaire. Par exemple, il peut lire et modifier la sécurité d’un système, exécuter des fonctions qui peuvent affecter de nombreux utilisateurs, etc… Ces comptes sont donc les préférés des attaquants (75 % des organisations ont subi une attaque impliquant un compte privilégié) et nécessitent un niveau de sécurité maximal.

Ce webinaire s’est concentré sur la sécurisation de l’accès aux ressources informatiques telles que les serveurs. Cependant, il est important de comprendre qu’un accès sécurisé est également nécessaire pour de nombreux autres éléments (tels que les applications) et qu’il existe différents types d’accès privilégiés, ce qui fait que la sécurité n’est pas une solution unique et doit être adaptée à chaque situation.

Les approches de sécurité traditionnelles utilisées par les organisations, y compris la solution PASM traditionnelle, ne suffisent pas à protéger les accès privilégiés contre les attaquants car elles ne répondent pas aux cinq questions clés nécessaires pour une sécurité solide, étant :

• Comment déployer l’authentification forte ?
• Comment sécuriser les superadministrateurs intégrés ?
• Comment contrôler les permissions effectives ?
• Comment gérer un grand nombre de serveurs ?
• Comment surveiller de près les opérations ?

Pour résoudre ce problème, les entreprises peuvent améliorer la solution PASM afin de la rendre plus efficace dans la sécurisation des accès privilégiés. Pour ce faire, elles peuvent :

1. Automatiser les autorisations autant que possible : Les serveurs sont nombreux et évoluent constamment, et les utilisateurs aussi. La normalisation et l’automatisation des autorisations leur permettront de suivre ce rythme.
2. Prise en compte d’autres cas d’utilisation au-delà de l’administration interactive : Il s’agit de prendre en compte d’autres besoins pour éviter que les utilisateurs ne contournent le PASM. On peut citer comme exemple les scripts utilisant des identifiants d’administrateur et les DevOps / machine-to-machine.
3. Concevoir votre modèle de compte en suivant le principe du moindre privilège (least privilege) : Par exemple, en concevant un seul compte nominatif centralisé par utilisateur pour simplifier la gestion, bien que cela n’entraîne pas de propagation latérale. Un compte générique local serait plus favorable dans ce cas précis, bien qu’il soit plus difficile à mettre en œuvre pour une organisation et qu’il pose question sur la responsabilité des comptes locaux, rendant la gouvernance plus complexe.

Le PASM présente-t-il des risques ?

Lors de la phase de projet, les administrateurs peuvent rejeter le PASM si la gestion du changement n’a pas été suffisante pour les former à ce dernier. Pour éviter cela, il est essentiel d’intégrer et de former les administrateurs à la solution PASM dès le début. De plus, la difficulté du déploiement et le coût peuvent être un obstacle aux solutions PASM pour les organisations. Ainsi, plus le modèle d’accès est simple, plus la solution sera facile à déployer et moins elle prendra de temps, ce qui permettra de réduire les coûts. Enfin, une solution PASM locale risque d’être très lourde et coûteuse en termes d’architecture, d’où l’intérêt de définir une solution SaaS. Bien qu’il s’agisse d’une solution de sécurité complète, les solutions PASM seules ne sont peut-être pas l’avenir des solutions de sécurité, avec l’émergence des stratégies ZSP…

Zero-standing Privilege(ZSP) est une stratégie de sécurité alternative qui vise à remplacer les comptes et privilèges persistants par un système « juste à temps » et « juste assez » pouvant être appliqué à la fois pour l’utilisateur et pour le serveur.

Pour l’utilisateur :

• Zero Standing Privilege : Les utilisateurs ont droit à un ensemble de privilèges préapprouvés, mais ces privilèges ne sont pas activés par défaut
• Juste assez : Lorsqu’ils doivent effectuer une opération, ils peuvent activer les privilèges minimaux nécessaires à la réalisation de leur tâche…
• Juste à temps : … pendant la période requise, suite à laquelle les privilèges sont automatiquement révoqués.

La ZSP appliquée au niveau de l’utilisateur permet de sensibiliser les utilisateurs, d’améliorer la traçabilité des opérations des organisations et de limiter le risque de « fat-finger ».

Pour le serveur :

• Zero standing privilege : Les comptes ne restent pas sur les serveurs, ou ils n’ont pas d’autorisation.
• Juste assez : Lorsqu’un utilisateur a besoin d’accéder au serveur, un compte est créé à la volée sur le serveur ciblé…
• Juste à temps : …uniquement pour la durée de la session.

La ZSP appliquée au niveau du serveur évite la compromission d’un compte en cas de violation, évite le contournement des outils PAM et évite les écarts entre les solutions théoriques et les solutions effectives.

La ZSP est-elle l’avenir de la gestion des accès privilégiés ?

La ZSP est conçue pour l’avenir des technologies de l’information, où de nombreux utilisateurs ont accès à de nombreuses ressources en constante évolution, et elle permet d’utiliser efficacement les principes du Zéro Trust. Cependant, la ZSP ne répond pas à tous les cas d’utilisation (comme machine-to-machine) et son développement n’est pas abouti, ce qui signifie que l’on manque d’expérience sur le terrain.

Ainsi, le conseil de Wavestone sur la stratégie à adopter est de définir d’abord votre stratégie PAM globale, puis une solution PASM solide pour sécuriser efficacement les accès à vos serveurs, avant d’envisager l’introduction d’un peu de ZSP. Par exemple, au niveau de l’utilisateur pour les privilèges élevés ou pour les utilisateurs ayant des besoins occasionnels et au niveau du serveur pour le cloud.

Webinar accessible à ce lien : https://www.thesasig.com/calendar/event/23-10-11-networks/

Cet article La sécurisation des accès privilégiés – Approches pour relever des défis multiples est apparu en premier sur RiskInsight.

Rappels sur le tiering

Le tiering est un modèle de sécurité applicable à l’Active Directory. L’idée principale est de séparer les comptes à privilèges dans différentes couches (les tiers) et périmètres fonctionnels, afin de restreindre leur utilisation possible dans leur tier d’origine uniquement, de sorte que si un tier est compromis, cela n’entraine pas la compromission des autres tiers. Cela permet par exemple de contenir une attaque par rançongiciel dans le tier d’origine de l’attaque uniquement, ou bien de se prémunir du scénario classique vu et revu de découverte et rejeu d’un identifiant administrateur de domaine sur un poste de travail. Typiquement le modèle se décompose comme il suit :

• Le tier 0 est le plus critique. Il est constitué de l’AD lui-même, donc les contrôleurs de domaine qui le portent, ainsi que des composants qui interagissent directement avec lui, où qui peuvent le compromettre par rebond. Ceux-ci sont typiquement les ADLDS, ADCS, PKI, mais aussi les composants IT nécessaires à son fonctionnement : hyperviseurs, SCCM, SCOM, sauvegarde, et postes d’administration dédiés (PAW, pour Privileged Access Workstation). Les comptes d’administration de ces composants sont ceux à plus hauts privilèges, car il s’agit forcément des comptes administrateurs de domaine (les comptes ayant des droits sur tout le parc Windows de l’organisation), mais aussi des comptes des autres composants pouvant s’attribuer indirectement les droits administrateurs de domaine, vu leur interaction avec les contrôleurs de domaines.
• Le tier 1 se compose classiquement des applications de l’entreprise et des serveurs qui les hébergent. Les comptes à privilèges sont donc ceux des administrateurs fonctionnels des applications ainsi que ceux des administrateurs techniques des serveurs.
• Le tier 2, pour finir, regroupe tout ce qui gravite autour de l’environnement utilisateur. En plus des comptes et postes bureautique, on peut y trouver les imprimantes, la téléphonie, ainsi que tous les comptes des différents niveaux de support utilisateur.

Pour rendre l’étanchéité possible entre les tiers, et donc limiter le périmètre de compromission, des « deny logon GPOs » (plus simple à mettre en place) ou des Authentication Policy Silos (plus sécurisées) sont mis en place, pour interdire à un compte d’un tier supérieur de se connecter à un composant appartenant à un tier inférieur. Aussi, un autre objectif du projet de mise en œuvre du tiering, pouvant avoir un impact sur le PAM, est de restreindre le nombre d’administrateurs du tier 0 au minimum, toujours dans l’optique de réduire la surface d’attaque et l’étendue d’une potentielle compromission. Une fois ce nouveau concept établi, examinons l’existant.

Bastion ? Vous avez dit bastion ?

Le bastion de sécurité est un outil très répandu dans les organisations pour implémenter le PAM. Le principe est d’héberger les comptes à privilèges dans des coffres sécurisés, et d’imposer les connexions des administrateurs (avec un compte sans privilège) vers une machine de rebond centrale, qui jouera ces comptes à privilèges pour l’administrateur, sans révéler son mot de passe. Autre avantage du bastion pour les organisations : la facilité de mise en place de l’authentification multi-facteurs, l’enregistrement et la traçabilité des actions d’administration, la gestion automatisée de la rotation de mot de passe, etc.

Jusqu’ici, rien d’incompatible avec le modèle en tiers. Et pourtant des adhérences existent. La structure de comptes à privilèges qui a été créée dans le bastion (par périmètre et/ou par équipe fonctionnelle et/ou type de composants, etc.), l’a été sans prendre en compte le concept amené par le projet de sécurisation AD : la notion de tiers.

Afin d’identifier les potentiels impacts, plaçons-nous dans l’optique du tiering et posons les questions simplement par rapport au bastion.

Comment adapter le bastion au modèle en tiers ?

Si l’on synthétise le problème à résoudre, cela donnerait le schéma ci-dessus qui est une pure vue de l’esprit. Pour réussir à l’adapter, il faut faire des choix.

Faut-il mettre le bastion dans un tier spécifique ? Faut-il le dupliquer dans chaque tier ?

Comme décrit dans le schéma d’un point de vue purement théorique du tiering, il faudrait une instance de bastion dans chaque tier, et même d’éditeurs différents afin de se prémunir d’une faille 0-day sur la technologie utilisée. Mais la mesure se heurte à une réalité financière, la possession de plusieurs bastions ayant un certain coût, doublé d’une réalité opérationnelle supportant mal la multiplication d’outils pour un même besoin. Heureusement des adaptations sont possibles. Dans la réalité, aucune entreprise ne met de bastion sur le tier 2. Ce tier étant relativement homogène et monolithique en matière de responsabilité, on autorise de s’y connecter directement, avec un compte à privilège du tier 2 évidemment, ou avec le compte administrateur local (protégé par LAPS) qui a l’avantage d’être robuste à une compromission totale du tier 2 en cas de compromission d’un seul compte à privilège du tier 2.

Pour les tiers 0 et 1, leur sort est lié et dépend à la fois du contexte de l’organisation et de l’existant. Première option, comme mentionné, le plus simple mais le plus couteux, est de déployer un bastion dédié dans chaque tier. En étant un peu plus réaliste maintenant, si une seule instance de bastion est possible, alors celle-ci devrait nécessairement être positionnée dans le tier 1. La raison de ce choix est très simple : le bastion répond à un besoin fonctionnel d’administration, or le périmètre de machines et de comptes le plus important est au sein du tier 1, à l’inverse du tier 0 dont on souhaite restreindre l’exposition (i.e. le nombre d’administrateurs y ayant accès).

Le tier 0 lui peut être plus simplement géré par des PAW, postes d’administration dédiés et durcis dans le but spécifique d’accéder à des comptes et ressources privilégiées. L’accès à la zone réseau hébergeant le tier 0 est soumise à une connexion VPN, autorisée seulement à partir de ces PAW. Il existe des organisations ayant fait une combinaison des deux : bastion et PAW. Cette implémentation reste tout à fait valable d’un point de vue sécurité, mais sa faisabilité dépend de la capacité de l’entreprise à déployer des PAW pour l’ensemble de ses administrateurs du tier 1, ce qui représente une population cible et un coût nettement supérieur. Dernier point pour conclure ce sujet : l’utilisation de bastion et PAW ne sont pas incompatibles entre eux, bien au contraire, les bénéfices sécurité sont complémentaires pour la protection des comptes à privilèges.

Dans le cas d’un bastion unique, peut-on administrer les autres tiers via celui-ci ?

Cette hypothèse simplifierait les choses, mais malheureusement elle n’est pas souhaitable. Administrer le tier 0 depuis le tier 1 briserait toute la segmentation que l’on cherche à mettre en place, notamment parce que des comptes privilégiés du tier 0 seraient hébergés dans le tier 1 et accessibles par les administrateurs du tier 1 du bastion. Cela dit, une infime possibilité existe, mais elle est très techno-dépendante car peu de bastions offrent les fonctionnalités adéquates. Sur le principe en positionnant le bastion dans le tier 0, administré par le tier 0, il serait possible de créer des groupes de machines de rebond, ainsi que des coffres (logiques), actifs ou passifs, dédiés dans chaque tier. Néanmoins notons que les rares organisations ayant tenté l’expérience font aujourd’hui machine arrière, face aux problèmes de gestion technique des coffres et à la lourdeur administrative induite.

Faut-il revoir l’attribution et la répartition des comptes dans le bastion ?

Pas nécessairement, mais encore une fois, cela dépend du contexte et de l’existant. En premier lieu, les comptes issus de chaque tier doivent être hébergés dans des coffres différents, afin de respecter la segmentation et l’étanchéité de chaque tier. Rien n’empêche si nécessaire de fragmenter, au sein de chaque tier, les coffres en sous périmètres pour répondre à l’organisation technique ou fonctionnelle existante (e.g. équipes ayant la charge du MCO/MCS des composants hébergeant des bases de données sont différentes des celles ayant la charge du MCO/MCS d’applications métier). Enfin, il est recommandé d’utiliser au maximum des comptes nominatifs et non des comptes génériques ou partagés. Si en effet rien n’empêche de mettre en coffre un compte unique administrateur de tous les serveurs du tier 1 utilisé par tous les administrateurs du périmètre, et que cette façon d’opérer ne va pas non plus contre les principes du tiering, il est quand même préférable de pouvoir immédiatement identifier le propriétaire du compte qui a fait l’action, afin de mieux maitriser les accès et habilitations de chacun, même si le bastion permettrait quand même de retrouver l’identité de manière indirecte via un recoupement dans les logs.

Bien encadrer la mise en place du tiering

Le tiering est aujourd’hui le chantier qui réduit le plus les risques de compromission des comptes à hauts privilèges et de l’AD de manière générale. C’est cependant également un sujet complexe, qui a beaucoup d’impacts sur l’ensemble des infrastructures et qui nécessite un très grand nombre d’adaptations de l’existant, pour que sa mise en place soit considérée comme réussie. Le PAM étant une brique essentielle à la gestion de ces comptes et accès d’administration, il est nécessaire de s’assurer que son implémentation n’interfère pas avec les principes du tiering voire ne vienne pas rompre la segmentation et l’isolement en couches. S’il n’y avait qu’une chose à retenir pour bien réussir cette transformation, ce serait que la mise en place du tiering, contrairement à ce que l’on croit, est loin de n’être qu’un simple sujet AD, mais qu’il doit conduire à repenser toutes les pratiques d’administration dans leur globalité.

Cet article Bastion de sécurité et modèle en tiers Active Directory : comment concilier les deux paradigmes ? est apparu en premier sur RiskInsight.