Modèle Active Directory N-TIERS - Implémentation du Privileged Access Management

Dans notre précédent article, nous avions démontré comment le modèle N-tier améliore significativement la sécurité des systèmes d’information en limitant les mouvements latéraux des attaquants. Cependant, nous avions conclu que la multiplication des comptes utilisateurs, inhérente au fonctionnement de ce modèle, le rendait difficilement applicable en pratique : pour réduire les mouvements entre les silos (ou tiers), le modèle préconise l’utilisation de comptes dédiés spécifiquement à chacun d’eux.
Pour autant, le modèle n’est pas impossible à mettre en œuvre. Dans cet article, nous allons explorer une solution envisageable pour répondre à cette problématique.

Changement de modèle d’authentification

L’architecture N-Tier amène une multiplication des comptes à privilège (Comptes administrateurs et comptes de service) et une potentielle perte de contrôle sur les politiques appliquées à ces derniers. C’est pourquoi nous proposons un modèle d’authentification dans lequel l’usage de comptes nominatifs est remplacé par des comptes génériques.
La politique de segmentation des comptes génériques est arbitraire. Une seule règle, un compte générique ne doit pas permettre d’accéder à des ressources de deux silos différents.
Le modèle le plus poussé imposerait l’usage d’un compte générique dédié à chaque serveur ; c’est-à-dire qu’un compte ne peut se connecter qu’à un seul serveur sur lequel il possède des droits spécifiques. Un serveur peut, en revanche, posséder plusieurs comptes d’accès génériques (relation de N comptes pour 1 serveur).

Le Privileged Access Management (PAM)

L’utilisation de comptes génériques représente un changement de paradigme complexe à implémenter. En témoignent les vives réactions que ce sujet a probablement suscité chez certains lecteurs, et pour cause : comment assurez le principe “d’imputabilité des actions” dans ce modèle ?
A cela, l’usage d’une solution dit de Privileged Access Management (« PAM ») apparait comme une solution adaptée.
Ce type de solution offre une gestion et une supervision centralisées des comptes à privilèges des différentes ressources du système d’information, ainsi que des accès des utilisateurs à ces comptes. Grâce au PAM, nous garantissons que seuls les utilisateurs autorisés peuvent accéder aux comptes à privilèges, conformément aux modalités définies. De plus, le PAM assure le respect du principe de non-répudiation en retraçant et en enregistrant précisément les actions effectuées via ces comptes.
De nombreuses solutions de ce type sont disponibles sur le marché dont celles que nous déployons et infogérons chez WELAN : Cyberark, Wallix et Teleport.
Dans ce modèle, les comptes génériques d’administration ne sont plus gérés par les administrateurs (création et rotations des mots de passe, droits, etc.) mais par la solution de PAM.
Les utilisateurs souhaitant se connecter aux ressources viennent alors s’authentifier sur le PAM (à l’aide d’un compte personnel) qui leur donne accès aux comptes génériques en adéquation avec les droits qui leur sont octroyés. Il est également capital d’activer l’authentification multi-facteurs sur le PAM afin d’assurer une ségrégation entre l’usage de bureautique et d’administration des comptes utilisateurs.

Ce contrôle total nous donne la possibilité de définir une architecture de gestion des comptes permettant de les rendre conforme à notre politique de silotage N-Tier. En effet, le périmètre de connexion des comptes n’est plus dépendant des utilisateurs et ces derniers ne supportent plus la charge de la gestion des multiples comptes.
N’étant plus limités par la quantité de comptes à gérer, il devient alors possible d’atteindre un niveau de finesse de silotage limitant au maximum les risques de mouvements latéraux au sein du SI.

L’intégration d’un nouveau serveur dans ce modèle suivrait alors la logique suivante :
1 : Ajout d’un nouveau serveur dans le SI
2 : Référencement du serveur dans l’Active Directory et application des configurations locales
3 : Création des comptes génériques et restreints au server
4 : Séquestration du serveur et de ses comptes génériques dans le PAM

Une fois tous ces éléments réunis, l’implémentation du modèle N-tier devient possible et avec elle une élévation drastique du niveau de sécurité du système d’information.

Standardisation et automatisation

L’implémentation de cette architecture nécessite la création de comptes pour tous les serveurs de notre système d’information. Pour des questions d’architectures spécifiques, d’usage ou de disponibilité des comptes, nous pouvons être amenés à créer plusieurs comptes génériques ayant les mêmes droits sur un même serveur.
En effet, le partage de comptes génériques peut entraîner des fuites d’informations. Par exemple, lorsqu’un utilisateur dépose des données sensibles (comme des identifiants) dans une session ouverte avec un compte générique, ces informations peuvent être involontairement accessibles par un autre utilisateur lors de la réutilisation de ce même compte. Pour limiter ce risque, des comptes génériques dédiés/limités à une équipe peuvent être créés.
La création de ces comptes, leur intégration dans le PAM et leur gestion au quotidien représente une charge opérationnelle relativement conséquente.
Ainsi, afin de réduire cette charge au maximum, d’assurer la réactivité et la disponibilité du service, il est nécessaire d’automatiser les tâches récurrentes relatives à ce modèle (création de comptes générique, séquestration dans le PAM, délégation de droits, etc.). L’automatisation implique également la formalisation des conventions de nommage et la standardisation des objets (comptes, groupes, unité d’organisation, nom de serveurs, etc.) du SI afin d’assurer une gestion cohérente et efficace.

Délégation des droits

Dans un SI étendu implémentant cette architecture, la gestion du cycle de vie des droits administrateurs de chaque utilisateur peut devenir complexe. Afin de faciliter cette gestion nous recommandons l’usage de solution d’Identity Access Management (IAM) et le provisionnement des droits au travers de rôles définis dans cette solution. Cela implique également l’automatisation du processus d’association entre les serveurs et les rôles devant y avoir accès.

Limitations

Comme nous l’avons répété maintes fois, cette architecture adresse les comptes d’administration. Cependant les comptes de services constituent un frein à l’implémentation de ce modèle. En effet ces derniers peuvent avoir la nécessité de se connecter à plusieurs serveurs, réalisant alors des connexions inter-tiers. Et bien que des mécanismes tels que les Managed Services Accounts facilitent la gestion de ces comptes, leur intégration dans le modèle N-tier n’en est pas améliorée pour autant.

Dans un prochain article nous verrons comment mettre en place techniquement des silos dans l’Active Directory.