C

Contrôle de connexion Active Directory : 8 points sur lesquels AD échoue et comment y remédier

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.

Avec UserLock: Identifier un point d'accès initial à partir d'une session imbriquée (contenu en anglais)
Autoriser l'accès en fonction de si une session est un nouveau point d'entrée ou si elle vient d'une session existante.

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.

Avec UserLock: Limiter ou empêcher les sessions simultanées
Restreindre un compte d'utilisateur pour accéder à un seul ordinateur / périphérique à la fois.

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.

Avec UserLock: Forcer la fermeture de session en dehors des délais autorisés
Déconnecter un utilisateur lorsqu'il est connecté à la console.

5. Pas de réponse aux événements et déconnexion forcée à distance

Au-delà de l'utilisation de PowerShell (page 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é.

Avec UserLock: Répondre immédiatement aux alertes sur les événements d'accès
Interagir à distance avec n'importe quelle session, ouverte ou verrouillée, pour forcer la déconnexion, le verrouillage ou la réinitialisation.

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!

Avec UserLock: Avertir les utilisateurs de l'utilisation suspecte des identifiants
Alerter les utilisateurs en temps réel pour accéder aux événements (réussis ou non) impliquant leurs informations d'identification de compte.

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.

Avec UserLock: Envoyer des notifications de connexion précédente (page en anglais)
Informer les utilisateurs des événements de connexion précédente impliquant leurs informations d'identification.

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 UserLock: Appliquer des contrôles temporaires (page en anglais)
Défini pour une période définie. Aucun utilisateur ne dispose de règles d'accès au-delà de ses besoins immédiats.

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.