Le contrôle d’accès dynamique sous Windows Server 2012

Bien que cette méthode ait fait ses preuves, elle possède ses limites du fait qu’un accès se résume à être autorisé ou pas suivant l’appartenance aux groupes définis ou tout du moins suivant le positionnement des ACLs sur un dossier ou un fichier. La sécurité était davantage centrée sur les utilisateurs pouvant accéder à ces données qu’à la criticité de la donnée elle-même.

Avec Windows Server 2012, il est possible d’améliorer notablement cette gestion de la donnée au travers d’une nouvelle notion appelée le Contrôle d’accès dynamique (ou Dynamic Access Control (DAC)).

Le contrôle d’accès dynamique permet d’établir des autorisations d’accès en fonction de règles précises. Il permet de compléter les droits existants sur un dossier ou un fichier. Il n’a pas vocation à remplacer les ACL mais vient s’ajouter aux droits NTFS en place.

Ces règles peuvent être liées à de nombreux paramètres comme :

• Le niveau de confidentialité associé à un fichier/dossier.

• Le poste occupé par un utilisateur, sa localisation ou tout autre attribut différenciateur.

• La configuration du périphérique utilisé pour accéder aux ressources.

Il sera, ainsi, possible de donner l’accès à une ressource en fonction de sa classification. Une condition d’accès supplémentaire peut être ajoutée comme la conformité de l’ordinateur depuis lequel l’utilisateur tente d’accéder à la ressource. Ce même utilisateur, depuis un ordinateur personnel non à jour, ne pourra pas accéder à ce même fichier. La bascule de ces deux états se faisant instantanément et à la volée puisque les critères sont vérifiés au moment de l’accès à la ressource.

Les informations concernant DAC sont stockées dans l’Active Directory au niveau de CN=Claims Configuration, CN=Services, CN=Configuration, DC=domain, DC=tld et sont répliquées au sein de la forêt AD.

Un petit peu de terminologie…

Avant de pouvoir aborder DAC, présentons les différents termes à connaître.

• Revendication (Claim) : Avant de pouvoir mettre en place DAC dans votre infrastructure, un travail de fond sera nécessaire pour catégoriser vos données, leur criticité, le périmètre système autorisé (poste vu comme Conforme ou pas) pour l’accès aux fichiers, etc. Ces éléments sont rattachés à des attributs. Une revendication est un de ces attributs ; il fera toujours référence à un utilisateur (ses attributs AD), un périphérique (attributs AD de l’ordinateur) ou une ressource (propriété de ressources définies par les admins).

Cela permet ainsi de définir de façon précise les utilisateurs, périphériques et ressources à intégrer à DAC au niveau de toute l’entreprise. Lorsqu’une revendication est basée sur un compte ordinateur, l’option FAST (Kerberos Armoring) devra être activée par GPO sur les DCs du domaine. Le regroupement d’une revendication utilisateur et ordinateur forme une authentification composée (Compound ID) disponible uniquement pour Windows 8/2012.

Les revendications, ou propriétés, sont ajoutées à une liste de propriétés de ressources.

• Règle d’accès centralisé (Rule Access Policy) : C’est une expression de règles d’autorisation qui comporte une ou plusieurs conditions. Ces conditions concernent des groupes d’utilisateurs, des propriétés de ressources, des revendications d’utilisateur ou de périphérique.

• Stratégie d’accès centralisé (Central Access Policy): est une stratégie d’autorisation comportant des expressions conditionnelles, c›est-à-dire les conditions à remplir pour pouvoir accéder à la ressource (en l’occurrence le fichier). La stratégie d’accès centralisé doit être ajoutée à une règle d’accès centralisée. La règle d’accès centralisé doit alors être appliquée à tous les fichiers concernés. La stratégie d’accès centralisée est alors déployée sur tous les serveurs de fichiers.

• Expression : On parle ici d’expression conditionnelle (ou de « la puissance du IF » !). L’accès aux ressources peut être affiné grâce à la réunion de plusieurs conditions que vous pouvez définir (comme l’appartenance d’un compte à un groupe, le niveau de sécurité du poste utilisateur, etc…). Les expressions se définissent au niveau des Paramètres de sécurité avancés du fichier/dossier ou de l’éditeur de règles d’accès centralisées.

Pour utiliser DAC, deux approches sont possibles :

• Il est possible de définir des règles et stratégies d’accès centralisé, au niveau de l’AD et ces dernières seront les seules utilisées pour autoriser l’accès à une ressource ou pas.

• La seconde méthode est de créer et intégrer des revendications dans les listes de contrôles d’accès existantes (ACLs).

Ce cas est utile notamment pour les fichiers stockés sur un système de fichier ReFS car celui-ci ne supporte pour l’instant pas de stratégie d’accès.

En terme de prérequis…

• Le niveau fonctionnel de la forêt doit au moins être Windows Server 2003.

• DAC nécessite au moins un contrôleur de domaine sous Windows Server 2012.

• Les serveurs de fichiers pour lesquels vous souhaitez utiliser une authentification basée sur les revendications, doivent également utiliser Windows Server 2012. Le rôle File Server Resource Manager (FSRM) doit être installé sur ces serveurs de fichiers.

• Un client sous Windows RT/8/2012 si l’accès se base sur les revendications et que vous cherchez à utiliser les attributs sur l’objet Ordinateur. Autrement, les clients sous Windows 7/2008 R2 fonctionnent aussi.
• Un client sous Windows RT/8/2012 devra avoir accès à un contrôleur de domaine sous Windows Server 2012 sur les sites distants

• Si l’utilisateur ne se trouve pas dans la même forêt que le serveur de fichiers, tous les contrôleurs de domaine du domaine racine du serveur de fichiers doivent utiliser Windows Server 2012.

Comme vous le voyez, plusieurs nouvelles notions sont à appréhender mais le gain en termes de sécurité pure des données peut être très intéressant.

Prenons l’exemple du service Ressources Humaines (RH) d’une grande entreprise ayant plusieurs pays regroupés autour d’un même domaine Active Directory. Les fichiers RH de chaque pays ne doivent être consultés en lecture seule que par le service RH de chaque pays respectif. Un service central RH pourra quant à lui accéder aux fichiers RH de tous les pays.

Étape 1 : Traduire les besoins en attribut de référence interprétable par DAC

Il s’agit ici d’identifier les données sensibles et les règles autorisant l’accès à ces données.

Les règles sont donc :

• Les documents ne peuvent être accédés qu’en lecture seule par le service RH

• Le service RH ne peut accéder qu’aux ressources RH relatives à son pays

• Seuls les Admins RH ont un accès en lecture /écriture

• Les membres du groupe RH_Exception pourront avoir un accès en lecture seule

• Les administrateurs et propriétaires du document auront un accès en control total

Étape 2 : Créer un type de revendications

Dans notre cas, nous nous baserons sur l’attribut Department (Département) et Country (Pays) de l’utilisateur. La définition revendication se déroule au niveau de la console Centre d’Administration Active  Directory car ces informations seront stockées dans l’Active Directory :

• Depuis la console ADAC (dsac.exe), rendez-vous au niveau de Contrôle d’accès dynamique – Claim Types – Nouveau – Type de revendication et cliquez sur l’attribut department.

• Ajoutez maintenant l’attribut Pays.

• Toujours depuis la console ADAC, Contrôle d’accès dynamique – Claim Types – Nouveau – Type de revendication et cliquez sur l’attribut c.

• Au niveau du Nom complet, indiquez country.

• Au niveau des valeurs suggérées, cliquez sur Les valeurs suivantes sont suggérées et ajoutez FR (en valeur et nom complet) JP, US, GB.

Étape 3 : Définir des Propriétés de Ressources

On configure, ici, les propriétés qui seront téléchargées par les serveurs de fichiers afin de classifier les fichiers. À noter que ces propriétés de Ressources seront ajoutées à une liste de Propriétés de Ressources. Les futurs accès de contrôle dynamique auront pour but de comparer les attributs de l’utilisateur avec les propriétés de Ressources.

Une liste des propriétés de ressources est pré-établie par Microsoft, mais il est possible de créer les siennes si nécessaire. C’est ce que nous allons voir avec l’attribut Country qui n’est pas proposé par défaut. Tout d’abord, ajoutons activons l’attribut Department…

• Ouvrez la console ADAC, puis Contrôle d’accès dynamique – Resource Properties.

• Sélectionnez Department et choisissez Activer au niveau des tâches disponibles.

Pour l’attribut Country, celui-ci n’étant pas prédéfini par défaut, il faut créer une Propriété de ressources de référence en procédant comme suit :

• Depuis la console ADAC, puis Contrôle d’accès dynamique – Resource Properties – Nouveau – Propriétés de ressources de référence.

Étape 4 : Définir une règle d’accès centralisé

Une CAR (Central Access Rule) décrit les conditions qui doivent être vérifiées pour permettre l’accès à une ressource (un fichier donc).

Depuis la console ADAC (dsac.exe), au niveau du noeud Contrôle d’accès dynamique, cliquez sur Central Access Rules – Nouveau – Règle d’accès central. Définissez alors les règles que vous souhaitez voir s’appliquer. Dans notre exemple, pour rattacher une vérification à l’attribut « Department », procédez comme ceci :

• Nom : RH – Règles pour les documents RH

• Description : (optionnel)

• Ressources Cibles : Cliquer sur Modifier puis Ajouter une Condition et choisir la ou les conditions à remplir pour permettre d’accéder aux ressources comme suit : Ressource- Department – Est égal à – Valeur – Human Resources et cliquez sur OK. (Human Resources correspondant à la valeur pré-configurée par défaut par Windows ; pouvant être modifiée si besoin au niveau des Resources Properties).

• Au niveau des autorisations, choisissez la valeur Utiliser les autorisations suivantes en tant qu’autorisation actuelle.

Au niveau des Autorisations, cliquez sur Modifier puis ajouter les « Utilisateurs authentifiés » en tant que Principal. Il faut alors créer les conditions se référant aux besoins exprimés lors de l’étude pour « Tous les utilisateurs ». Dans notre exemple, Les utilisateurs authentifiés répondant à certains critères peuvent accéder aux fichiers en lecture donc la règle suivante est à définir :

Utilisateur – country – N’importe lequel de – Ressource – country
ET
Utilisateur – department – N’importe lequel de – Ressource –  Department

• Ajouter une autorisation spécifique pour les Administrateurs RH (membres du groupe RH_Admin) qui auront, quant à eux, la possibilité de modifier le contenu en question. Cliquez sur Modifier devant Autorisations actuelles puis Ajouter – Sélectionner un principal. Indiquez le groupe RH_Admin en Modification. Voir figure 7.

• Ajouter une autorisation spécifique pour les admins n’ayant qu’un accès en lecture (membres du groupe RH_ Exception) Cliquez sur Modifier devant Autorisations actuelles puis Ajouter – Sélectionner un principal. Indiquez le groupe RH_Exception qui n’aura qu’un accès en Lecture/ Lecture-Exécution.

Maintenant, vous avez donc une règle d’accès centralisée qui limite l’accès aux fichiers RH à un même pays et un même département. Le groupe RH_Admin peut éditer les fichiers et le groupe RH_Exception peut les lire.

À noter que seuls les fichiers classifiés en tant que Human Resources sont concernés.

Étape 5 : Ajouter les règles à une stratégie d’accès centralisé

Celle-ci sera déployée par GPO.

Pour cela, depuis l’ADAC il faut ouvrir le Central Access Policies – Nouveau – Stratégie d’accès central et associer la règle d’accès centralisé créé.

La CAP peut être déployée par GPO sur les serveurs de fichiers Windows 2012 possédant le rôle FSRM. (Ce rôle s’ajoute sur le serveur au niveau de la Sélection des rôles pour le serveur – Service de fichiers et de stockage/Services de fichiers et iSCSI/et cocher Serveur de fichier et Gestionnaire de ressources du serveur de fichiers).

On crée donc une nouvelle GPO pour déployer la stratégie d’accès centralisé (CAP) aux serveurs de fichiers.

Cette stratégie de groupe va juste mettre à disposition la vpolitique d’accès centralisé mais ne forcera pas son application.

• Depuis l’éditeur de stratégie (gpmc.msc), créez une GPO au niveau de l’OU hébergeant vos serveurs de fichiers. Naviguez alors jusqu’à Configuration Ordinateur – Stratégies – Paramètres Windows – Système de fichiers – Stratégies d’accès centralisée.

• Faites un clic droit sur Stratégie d’accès centralisée, puis Gérer les stratégies d’accès centralisées. Choisissez la stratégie précédemment créée CAP_RH et cliquez sur Ajouter.

• Faite un clic droit sur l’OU correspondante à votre stratégie et choisissez Mise à jour de la stratégie de groupe. Cela aura pour effet de forcer l’application de la stratégie de groupe sur tous les serveurs de l’OU (nouveautés Windows 2012 (qui fonctionne pour des postes cibles sous Windows Vista/2008 ou versions suivantes !! ☺).

Étape 6 : Configuration des contrôleurs de domaine et des clients

L’option FAST pour Flexible Authentication Secure Tunneling, aussi connu sous le nom de « Kerberos Armoring » (ou blindage Kerberos) doit être activée sur les contrôleurs de domaine pour permettre de supporter DAC. FAST fournit notamment un canal sécurisé entre le client et le KDC.

Le blindage Kerberos est donc à appliquer par GPO sur l’OU « Domain Controllers ». Il s’applique au DC 2008 et ultérieurs.

Procédez comme suit pour configurer celui-ci :

• Préférez créer une GPO plutôt que d’utiliser la GPO par défaut « Default Domain Controllers Policy ».

• Rendez-vous au niveau de Configuration Ordinateur – Stratégies – Modèles d’administration – Système – KDC et activez le paramètre Prise en charge du contrôleur de domaine Kerberos pour les revendications, l’authentification composée et le blindage Kerberos.

• Forcez les GPO sur les DC via un gpupdate /force.

Au niveau de votre domaine (ou de vos ordinateurs clients uniquement), définissez une GPO afin de permettre l’utilisation de revendication. Cela pour effet d’étendre le ticket Kerberos géré par le client.
Rendez-vous au niveau de Configuration Ordinateur – Stratégies – Modèles d’administration – Système – Kerberos et activez le paramètre Prise en charge du client Kerberos pour les revendications, l’authentification composée et le blindage Kerberos.

Étape 7 : Classification des données sur le serveur de fichiers
Vous allez devoir d’abord classifier les fichiers du partage en spécifiant les Propriétés de ressources définies précédemment.

Au niveau des propriétés du dossier partagé devant être protégé, cliquez droit sur celui-ci puis Propriétés et visualisez l’onglet Classification. Vous devrez voir apparaître toutes les propriétés de ressources définies précédemment.

Si ce n’est pas le cas, depuis le serveur de fichier, ouvrez une invite PowerShell et tapez la commande Update-FSRMClassificationPropertyDefinition. Cette commande forcera le rafraichissement des Propriétés de ressources définies.

Sélectionnez alors la propriété de ressource country et Department et définissez les valeurs qui vont bien puis cliquez sur OK.

Maintenant que le dossier a été classifié, vous pouvez rattacher la stratégie d’accès centrale à appliquer à celui-ci.

• Au niveau des Propriétés du dossier – Sécurité – Avancés – Stratégie centralisée.

• Cliquez sur Modifier et Sélectionnez alors la stratégie d’accès centralisé nommée CAP_RH.

• Cliquez alors sur OK pour valider et ainsi rendre DAC effectif sur ce dossier.

Étape 8 : Vérification des accès effectifs

Pour cela, vous n’aurez pas besoin de vous connecter avec le compte de tel ou tel utilisateur pour faire cette vérification. L’onglet Accès Effectif a été mis à jour sous Windows Server 2012 et prend en compte les revendications.

• Depuis les Propriétés du dossier, Sécurité – Avancés – Accès effectif.

• Choisissez le compte utilisateur de votre choix et cliquez sur Afficher l’accès effectif.

Ici, bien que tous les utilisateurs authentifiés aient été définis au niveau NTFS, seuls ceux répondant aux critères définis dans DAC sont autorisés à accéder aux ressources.

Vous pourrez alors constater l’efficacité de cette stratégie en visualisant les autorisations effectives sur ce répertoire en prenant soin de sélectionner un compte utilisateur ayant les attributs correctement renseignés. Vous pourrez même spécifier une revendication spécifique et voir les droits alors appliqués.

P.S : Vous pourrez définir des attributs utilisateurs, directement depuis la console ADAC. Au niveau des propriétés de l’utilisateur se trouve une section Extension, contenant plusieurs onglets dont un nommé Editeurs d’attributs.