Dynamic Access Control : enfin du changement dans la gestion des droits d’accès aux données

Avec l’adoption progressive de Windows Server 2012, les entreprises s’intéressent progressivement aux nouvelles fonctionnalités offertes par ce système d’exploitation. L’une d’entre-elles est le contrôle d’accès dynamique (Dynamic Access Control ou DAC).

Le DAC, un objectif ambitieux

Avec le DAC Microsoft affiche un objectif ambiteux : renforcer la confidentialité des informations de l’entreprise par la simplification de la classification des données et des règles qui en régissent l’accès.

Lorsque l’on aborde la confidentialité des données, la théorie (EBIOS par exemple) vient tout de suite à l’esprit : 

•  « Il convient de classer les informations en termes de valeur, d’exigences légales, de sensibilité et de criticité. »
•  « Il convient d’élaborer et de mettre en œuvre un ensemble approprié de procédures pour le marquage et la manipulation de l’information, conformément au plan de classification adopté par l’organisme. »

Mais la mise en pratique n’a rien de très évidente d’autant plus lorsque le volume de données croit exponentiellement au fil du temps.

Le DAC est une nouveauté disponible à partir de Windows Server 2012 et Windows 8 permettant d’apporter une première réponse à cette problématique. Étant compatible avec la sécurisation par groupe de sécurité actuellement largement répandue dans les environnements Microsoft, la mise en œuvre de cette nouvelle technologie peut donc être envisagée en parallèle des mécanismes actuels.

Vers une gestion des règles d’accès facilité

Le système de contrôle d’accès dynamique s’appuie sur les informations utilisateurs ou machines renseignées dans l’AD comme par exemple un pays de rattachement, un département dans l’entreprise ou un type de poste de travail. Durant l’authentification de l’utilisateur ou de la machine, ces informations sont incluent dans le jeton de sécurité Kerberos et sont utilisées lors de l’accès aux fichiers de l’entreprise.

L’enrichissement du jeton Kerberos avec les données de l’utilisateur ou de la machine requiert l’activation de la GPO appropriée sur au moins un contrôleur de domaine.

Les ressources accédées sont elles classifiées selon plusieurs méthodes :

• Manuellement fichier par fichier (par le propriétaire par exemple)
• En fonction de leur répertoire sur le serveur de fichier
• En fonction de leur contenu (basé sur des expressions régulières)
• Selon le résultat d’un script PowerShell personnalisé 

Les règles de classification peuvent être définies sur les serveurs de fichiers via la Data Classification Toolkit^[1] et la File Classification Infrastructure.

Une fois l’ensemble des paramétrages réalisés pour les utilisateurs, machines et fichiers les règles d’accès centralisées définies sur l’AD entrent en action. Ces règles permettent de définir les conditions logiques autorisant la lecture, la modification ou l’exécution d’un fichier. Elles offrent la possibilité de combiner des contraintes liées aux caractéristiques des utilisateurs, machines et fichiers.

L’utilisateur dispose d’un accès en lecture, écriture et exécution si ses attributs Country et Department concordent avec ceux du fichier accédé.

L’intérêt majeur de ces règles est qu’elles autorisent une grande finesse dans leur définition et induisent une réduction de la complexité de gestion des droits d’accès en entreprise.

Prenons par exemple, le cas d’une entreprise ou les règles suivantes s’appliquent :

• Seuls les employés du département « Finance » peuvent accéder en modification aux fichiers classifiés « Finance » ;
• L’accès aux fichiers classifiés « Secret » n’est autorisé que depuis un poste de travail dont la sécurité est renforcée ;
•  Les employés des bureaux d’audit peuvent accéder en lecture aux fichiers classifiés « Finance » des filiales françaises et britanniques. 

À l’aide des règles d’accès centrales et une fois la classification des utilisateurs, des machines et des fichiers effectuée, cela pourrait se traduire par les simples règles suivantes :

• SI « User.Department » = « Finance » ET SI « User.Department » = « Resource.Department » ALORS accès en modification
• SI « Resource.Type » = « Secret » ET SI « Device.Type » = « Sécurité Renforcée » ALORS accès en modification
• SI « User.Department » = « Auditeur » ET SI « Resource.Department » = « Finance » ET SI « Resource.Country » = « France » OU SI « Resource. Country » = « Grande Bretagne » ALORS accès en lecture 

Une brève expérience dans la définition et la gestion des groupes de sécurité met rapidement en évidence le casse-tête que peuvent représenter ce genre d’exemples.

Avec le DAC, la difficulté est désormais uniquement reportée sur le provisioning des attributs utilisateurs dans l’AD et sur la classification des données (en s’appuyant par exemple sur les outils cités précédemment). En revanche, l’audit des règles d’accès est très largement simplifié.

Quelle méthode de déploiement ?

Le système de contrôle d’accès dynamique étant compatible avec les groupes de sécurité Windows, il est possible d’envisager un déploiement progressif de la solution. Les contextes organisationnels et techniques pouvant fortement varier d’une entreprise à l’autre, nous ne pouvons citer qu’un exemple parmi d’autres de processus de mise en œuvre :

• Étape 1 : Déploiement de postes de travail Windows 8 ou 8.x
• Étape 2 : Déploiement d’un ou plusieurs contrôleurs de domaine Windows Server 2012
• Configuration du/des contrôleur(s) pour délivrer des jetons de sécurité Kerberos compatible DAC
•  Étape 3 : Déploiement d’un ou plusieurs serveurs de fichiers Windows Server 2012
• Configuration du/des serveur(s) pour activer le DAC

• Création des ACL centralisées s’appuyant sur les groupes de sécurité Windows :
  SI « User.MemberOf » = « Dept_Audit_FR » OU SI « User.MemberOf » = « Dept_Audit_UK » ET SI « Resource.MemberOf » = « File_Finance_FR » OU SI « Resource.MemberOf » = « File_Finance_UK » ALORS accès en lecture

• Étape 4 : Classification progressive des utilisateurs et des machines
•  Provisioning des attributs utilisateur et machine nécessaires
•  Conversion des ACL centralisées pour utiliser les attributs utilisateurs :
  SI « User.Department » = « Auditeur » ET SI « Resource.MemberOf » = « File_Finance_FR » OU SI « Resource.MemberOf » = « File_Finance_UK » ALORS accès en lecture

• Étape 5 : Classification progressive des fichiers hébergés
• Création des règles de classification des données
• Conversion des ACL centralisées pour s’appuyer sur la classification des données :
  SI « User.Department » = « Auditeur » ET SI « Resource.Department » = « Finance » ET SI « Resource.Country » = « FR » OU SI « Resource. Country » = « UK » ALORS accès en lecture

L’atout principal de cette méthode est qu’elle permet le déploiement rapide du socle nécessaire au DAC et d’un 1^er niveau de configuration basé sur l’existant. L’évolution de cet existant est ensuite possible au fur et à mesure du projet permettant d’éviter un déploiement en « big bang » souvent synonyme de complexité technique et de conduite du changement difficile.

Pour tirer le meilleur parti de toute la flexibilité apportée par le DAC, il semble indispensable de pouvoir assurer une flexibilité équivalente dans la gestion de ses utilisateurs, machines et données.

Malgré les outils natifs apportés par Microsoft et selon la dimension de l’entreprise, l’interfaçage avec des solutions d’IAM (pour le provisioning dynamique des attributs utilisateurs) ou de DLP (pour une classification avancée des fichiers) peut se révéler indispensable. 

[1] https://technet.microsoft.com/en-us/library/hh204743.aspx

Kévin GUERIN