Active Directory (AD) est plus qu'un simple référentiel d'identifiants et de mots de passe; C'est le centre de presque toutes les sécurités de votre réseau. Au-delà de la gestion rudimentaire des permissions, AD établit des politiques et des contrôles sur les privilèges des comptes, et comment ces comptes peuvent être utilisés.
Mais quand il s'agit de garder un œil sur quand, où, comment, et si un compte peut se connecter, AD échoue.
Les ouvertures de session sont l'une des actions clés de chaque attaque externe (article en anglais), ce qui en fait un objectif primordial pour le service informatique, tant à surveiller que pour agir en fonction. Même dans les cas d'attaques internes, l'activité d'ouverture de session suspecte peut être un indicateur avancé d'activité malveillante. Et pourtant, tout ce que l'AD a à offrir, c'est des restrictions de postes de travail et de temps qui ont 17 ans.
Il est grand temps que les organisations mûrissent leur réflexion sur les contrôles d'accès aux connexions qui doivent être en place. Les meilleures pratiques de sécurité les recommandent et les normes de conformité les mandatent.
Huit trous dans les contrôles de connexion de Windows Active Directory
Vous trouverez ci-dessous une liste des échecs des contrôles d'accès prédéfinis d'AD lors de la connexion aux services informatiques: chacun représente une lacune de sécurité qui empêche les entreprises d'être conformes et, potentiellement, les expose à des risques.
Mettre en place certains de ces contrôles requiert soit des scripts très créatifs pour avoir une partie des fonctionnalités, soit faire appel à une solution tierce, telle que UserLock, qui se concentre sur le point le plus crucial de tout risque de sécurité : la connexion.
1. Pas de paramètre de restrictions par groupe et unité d'organisation
Il n'y a aucune possibilité d'établir des restrictions de temps de connexion et de poste de travail basées sur ces mécanismes de sous-ensembles d'utilisateurs logiques, malgré un large éventail de normes de conformité l'exigeant.
Avec UserLock: Définir des restrictions par groupe et UO
Cela permet d'économiser un temps considérable et permet au service informatique de définir une politique de contrôle d'accès centralisée dans toute l'organisation.
2. Pas d’identification d'un point d'accès initial à partir d'une session imbriquée
Ceci est particulièrement nécessaire dans les situations où un acteur de la menace (interne ou externe) se déplace horizontalement au sein de votre réseau. Être capable de cibler le point de terminaison initial aiderait à arrêter toute la chaîne d'accès.
3. Pas de contrôle d'ouverture de session simultanée
Autrement dit, il n'y a pas de moyen centralisé dans AD pour suivre chaque endroit où un utilisateur se connecte.
Pour cela, vous devez centraliser les journaux de chaque point de terminaison et serveur du réseau, en surveillant et en référençant chaque connexion dans une sorte de base de données. Oh, et vous devrez également garder une trace des déconnexions pour garder le numéro de connexion simultanée précis!
Ce problème, d'ailleurs, est seulement aggravé par le manque de forçage des déconnexions - si un utilisateur oublie de se déconnecter, le nombre de connexions simultanées reste plus élevé qu'il ne le devrait.
4. Pas de déconnexion forcée lorsque le délai de connexion est écoulé
AD peut établir quand les utilisateurs peuvent se connecter (et ne pas autoriser la connexion en dehors de ces heures), mais n'a pas la possibilité d'expulser quelqu'un de votre réseau.
Si un utilisateur n'est pas autorisé à se connecter après 17 heures, il est logique qu'il ne soit pas encore connecté après 17 heures.
Vous pouvez tenter une réponse à partir d'une combinaison d'une tâche planifiée dans les GPO et un script de déconnexion, mais même avec cette solution, ce n'est pas une réponse dynamique qui garantit que chaque utilisateur est déconnecté au moment opportun.
5. Pas de réponse aux événements et déconnexion forcée à distance
Au-delà de l'utilisation de PowerShell (en anglais) pour forcer un utilisateur à se déconnecter, le service informatique doit «se faufiler» vers le point de terminaison en question. Il existe de nombreuses bonnes raisons pour lesquelles vous souhaitez effectuer une déconnexion forcée à distance et c’est toutefois requis pour les principales réglementations de conformité.
6. Pas d’avertissement des utilisateurs eux-mêmes de l'utilisation suspecte des identifiants
Informer l'utilisateur de l'utilisation irrégulière de ses propres identifiants permet à l'utilisateur d'agir en tant que membre de votre équipe de sécurité. Qui de mieux pour savoir quand une connexion était inappropriée que l'utilisateur lui-même!
7. Pas d'envoi de notification de connexion précédente
Le simple fait de faire savoir à l'utilisateur la dernière fois qu'il s'est connecté améliorerait la sécurité. C'est aussi un must pour la conformité au NIST 800-53. Mais, sans suivi centralisé de chaque connexion, cela n'est tout simplement pas possible nativement.
8. Pas de contrôles temporaires
En supposant que vous puissiez faire toutes les choses précédentes concernant les connexions, le dernier contrôle serait la capacité d'appliquer à tous les contrôles mentionnés ci-dessus une base temporaire.
Avec la nécessité d'établir et de maintenir la sécurité de manière à assurer une protection contre les attaques externes, les menaces internes et le respect des normes de sécurité des données liées à la conformité, les contrôles d'accès Active Directory concernant les connexions font cruellement défaut.
Avec UserLock, le service informatique peut mettre en œuvre des contrôles d'ouverture de session efficaces qui se sont avérés impossibles ou extrêmement difficiles à réaliser uniquement grâce aux fonctionnalités Windows AD natives. En l'absence de modifications apportées à Active Directory ou à son schéma, UserLock fonctionne aux côtés d'Active Directory pour étendre et non remplacer la sécurité d'ouverture de session.