Aujourd’hui je vous propose de discuter d’une méthodologie que j’aborde souvent avec les clients avec lesquels je travaille. Il s’agit de ce que l’on appelle Just-In-Time Access & Just Needed Access. Evidemment dans mon cas, j’en parle en lien avec l’Active Directory mais c’est une démarche de sécurité qui vaut pour tout type d’infrastructure. Vous en avez peut-être entendu parlé sous le nom de principe de moindre privilège (ou en anglais Principle of Least Privilege).
Lorsque l’on aborde la question de sécuriser les accès et notamment les accès fournis par l’Active Directory au sein de l’entreprise il existe plusieurs méthodes et solutions (j’en liste quelques uns un peu plus loin dans l’article).
Administrateurs : utilisez 2 comptes
Quelque-chose de très classique que vous faîtes probablement depuis longtemps c’est séparer votre compte utilisateur standard (sur lequel vous avez votre messagerie, votre IM…) du compte que vous utilisez pour vos élévations de privilèges. C’est simple et la plupart des entreprises ont adopté ce comportement au sein de leurs infrastructures. 🙂
Cela dit, cela ne protège pas de tout… Et l’on voit bien que les attaques sont de plus courantes et peuvent impacter même des entreprises avec des moyens que l’on imagine importants. Pour s’en rendre compte il suffit de regarder l’actualité de ces derniers mois :
- Bouygues Construction paralysée par une cyberattaque : les pirates réclament une rançon
- L’assureur mutualiste MMA visé par une attaque informatique
- Garmin a payé une rançon de plusieurs millions de dollars après avoir subi une cyber-attaque
Plus ça va, plus on est en droit de penser que la question n’est plus de se protéger pour un risque 0 mais plutôt de se protéger pour le moment où cela arrivera… 😉
Protéger vos comptes à privilèges
Il est crucial de protéger les comptes de vos utilisateurs mais aussi et surtout les comptes des administrateurs de votre entreprise. Ces comptes peuvent parfois être Enterprise Admin, Domain Admins, Exchange Organization Management… ou plus généralement tout ce qui peut donner du pouvoir au sein de votre organisation.
Malheureusement, si vous n’appliquez pas la méthodologie Just-In-Time & Just Needed Access alors ces comptes conservent leurs privilèges de manière permanente et ce même lorsque vous ne les utilisez pas (puisque vous les laissez probablement dans les groupes concernés).
Evidemment, cela pose des questions : que se passerait-il dans le cas d’une attaque brute-force réussie et plus généralement si un compte venait à être compromis. Il dispose toujours de son niveau élevé de privilèges et vous vous exposez alors à des déplacements latéraux par un attaquant qui pourrait tenter de rebondir sur d’autres composants / serveurs au sein de votre infrastructure (serveur de fichiers, Active Directory, PKI, …).
Et c’est là que la méthodologie du Just-In Time & Just Needed Access entre en jeu. L’idée c’est de ne plus avoir des comptes qui disposent de privilèges de manière permanente mais uniquement lorsque vous en avez le besoin pour une durée déterminée et pour le niveau d’accès nécessaire aux actions à entreprendre !
Sur le papier, je vous l’accorde – c’est loin d’être une révolution ! Ce type d’organisation peut être atteint par le développement de scripts en interne (en PowerShell par exemple). Mais il existe également des solutions prêtes à l’emploi qui peuvent vous permettre d’atteindre ce niveau de sécurité et d’agilité. C’est ce que l’on appelle la gestion des accès privilégiés (en français).
Solutions prêtes à l’emploi
Chez Microsoft, on parlera de la solution MIM with PAM (Microsoft Identity Manager with Privilege Access Management)… Oui, le nom est particulièrement long… 😉
Ce type de solution vous permet de mettre en place une interface web au sein de laquelle vous allez pouvoir définir les personnes qui peuvent réaliser des demandes de modifications de privilèges (j’ai besoin d’être Domain Admin, Schema Admin…) pour une durée déterminée (la durée de mon intervention).
Evidemment, cette demande d’accès peut également nécessitée une approbation par un ou plusieurs responsables – ce qui permet de s’assurer de la légitimité de la demande (avons-nous bien une opération de prévue).
Et enfin, le plus souvent il est également nécessaire de détailler ce que l’on souhaite faire durant l’intervention. Cela permet de tracer tout changement au sein d’une infrastructure (bien plus précisément qu’un CAB).
Plus d’infos sur les liens suivants :
- Privileged Access Management pour les services de domaine Active Directory
- Configurer l’environnement MIM pour Privileged Access Management
MIM with PAM est une solution qui permettra de sécuriser votre environnement local Active Directory (on-premises).
Solutions alternatives
Toujours pour le on-prem, il existe également des alternatives proposées par d’autres éditeurs. On peut par exemple citer :
- Usercube – Voir le site l’éditeur : https://www.usercube.com/en/
- BeyondTrust – Voir le site de l’éditeur : https://www.beyondtrust.com/
- Cyberark – Voir le site de l’éditeur : https://www.cyberark.com/
- Arcon – Voir le site de l’éditeur : https://arconnet.com/
Il existe probablement d’autres solutions dont j’ignore l’existence. Elles sont bien entendu (souvent) payantes et à ma connaissance il n’existe pas d’alternative open-source ou gratuite qui soit immédiatement utilisable (sans passer par du développement interne).
Just-In-Time & Just Needed Access pour le Cloud
Notez également qu’il existe une alternative Cloud pour déployer le même type de workflow pour les comptes à privilèges que vous avez au sein de votre Azure Active Directory.
Cette solution s’appelle Azure PIM pour Privilege Identity Management. J’avais détaillé le fonctionnement de cette solution dans un précédent article (pour rappel, elle nécessite une licence de type Azure AD Premium P2 ou équivalent).
Conclusion
Bref, comme vous le voyez on n’est pas sur quelque-chose de complexe à mettre en oeuvre. Mais oui, cela va changer les habitudes de travailler de vos administrateurs (et ça pourra déplaire à certains d’entre eux). Mais c’est clairement l’évolution logique « aux 2 comptes séparés (utilisateur/admin) » que vous faîtes déjà depuis les années 2000 (voir avant).
Avec ce genre de façon de travailler, même un accès compromis ne pourrait pas être utilisé car au moment de l’élévation, le workflow d’approbation doit permettre de garantir et vérifier si la demande est légitime ou non ! 😉
Qu’est-ce que vous en pensez ? Est-ce que vous utilisez déjà cette façon de travailler au sein de votre organisation ? 🙂
