Concepts fondamentaux

Chapitre 6 : Gestion des accès

Paru le 11 mai 2004 | Dernière mise à jour le 26 juin 2006

La gestion des accès comprend les processus et technologies visant à surveiller et à contrôler l'accès aux ressources liées aux stratégies gouvernementales. La gestion des accès inclut :

• Authentification

• Autorisation

• Approbation

• Audit de sécurité

Sur cette page

Authentification
Autorisation
Approbation et fédération
Audit de sécurité

Authentification

Le service d'annuaire Microsoft® Active Directory® est la technologie recommandée pour le stockage d'informations d'identité dans la plate-forme Microsoft de gestion des identités et des accès. Les informations stockées incluent les clés cryptographiques qui valident les informations d'identification utilisateur lors du processus d'authentification.

Les applications intégrées à Microsoft Windows Server™ 2003, Microsoft Windows® XP Professional et aux services de sécurité de Windows utilisent les fonctionnalités intégrées du système d'exploitation pour le processus d'authentification.

Services d'authentification Windows

L'implémentation de protocoles d'authentification application par application est inefficace et risque d'introduire des failles de sécurité dans l'organisation. La meilleure approche consiste à créer des applications à l'aide des mécanismes d'authentification de la plate-forme Windows.

Pour de meilleurs résultats, les développeurs doivent comprendre les différents types d'authentification, les ramifications liées à l'utilisation de différents protocoles et les interfaces prises en charge avant de démarrer le processus de conception de l'application.

Architecture de services d'authentification Windows

Windows Server 2003 et Microsoft Windows XP mettent en œuvre un ensemble complet de méthodes d'authentification et de protocoles de sécurité qui satisfont de nombreuses exigences en matière d'authentification d'application. Les clés publiques Microsoft .NET Passport permettent d'authentifier les certificats ou les cartes à puce et les combinaisons nom d'utilisateur/mot de passe. Elles offrent des environnements utilisateur différents compte tenu des différentes exigences en termes d'informations d'identification, chacun disposant de caractéristiques de sécurité différentes. Le mécanisme de transfert de données peut également définir les protocoles d'authentification que vous pouvez utiliser.

Le système de sécurité des services d'authentification de la plate-forme Microsoft de gestion des identités et des accès se définit comme suit : Il s'étend des interfaces de niveaux supérieurs, offrant davantage de flexibilité et de contrôle, aux interfaces de niveau supérieur, offrant moins de flexibilité mais des interfaces de programmation d'application (API) plus simples. La figure suivante présente la façon dont les protocoles d'authentification et les API d'application sont définis.

Figure 6.1. L'API d'authentification et la hiérarchie protocolaire sous Windows

Au sommet de la pile d'authentification de la figure précédente, les API et services de haut niveau fournissent des mécanismes ICP (inter-process communication) intégrant un canal authentifié et sécurisé pour la transmission de données d'application. De tels services et API incluent par exemple le modèle COM distribué (DCOM, Distributed Component Object Model), les appels de procédure distante (RPC, remote procedure calls), Microsoft ASP.NET, la technologie ASP, WinInet parmi d'autres.

Microsoft RPC est un mécanisme IPC puissant, efficace et sécurisé permettant d'échanger des données et d'appeler une fonctionnalité qui réside dans un processus différent. Ce processus peut se trouver sur le même ordinateur, sur le réseau local ou sur Internet.

WinInet est une interface gérant les protocoles d'application, conçue pour prendre en charge les protocoles IP tels que les protocoles SSL (Secure Sockets Layer) afin d'utiliser des protocoles Internet. L'implémentation de la prise en charge de sécurité WinInet utilise l'interface SSPI (Security Support Provider Interface) sur le fournisseur de sécurité du canal sécurisé (implémentation Windows NT® de SSL).

Dans certains cas, les API exposés par ces services donnent au développeur d'applications un contrôle parfait sur la façon dont l'authentification est réalisée et les données protégées. Par exemple, les API DCOM permettent au développeur de sélectionner un protocole d'authentification spécifique tel que le protocole Kerberos ou la séquence stimulation/réponse NT LAN Manager (NTLM). Ils indiquent également si les données doivent être signées (protection contre les pirates effectuant des modifications sur les données) ou cryptées (protection contre les espions consultant les données). D'autres services et API sont uniquement affectés par la configuration système. ASP.NET représente le meilleur exemple. Il est hébergé sur un serveur exécutant Microsoft Internet Information Services (IIS) 6.0, qui peut être configuré pour utiliser le mécanisme d'authentification approprié dans un scénario donné.

Interface du fournisseur de la prise en charge de sécurité

L'interface d'application de niveau le plus bas pour l'authentification est SSPI, la version Microsoft de l'interface GSS-API (Generic Security Service API). Pour plus d'informations sur l'interface GSS-API, consultez les RFC (Request for Comments) 1508 et 1509 sur le site Web de l'ITEF (Internet Engineering Task Force).

Pour plus d'informations sur l'interface SSPI, consultez l'article The Security Support Provider Interface Revisited (Révision de l'interface du fournisseur de la prise en charge de sécurité, en anglais) sur le site Web MSDN.

L'idée principale véhiculée par les interfaces SSPI et GSS-API est que l'authentification réseau entre les deux parties suit généralement un modèle commun. Les parties doivent échanger une ou plusieurs informations dans un ordre précis. Puisqu'il est possible qu'elles communiquent via un ou plusieurs protocoles réseau différents — HTTP (Hypertext Transfer Protocol), RPC, SMB (server message block), IIOP (Internet Inter-ORB Protocol), DCOM, RMI (Java Remote Method Invocation), etc. — il est préférable de ne pas préprogrammer de négociation d'authentification unique dans le protocole réseau en lui-même. Il est préférable de ne fournir qu'une interface générique produisant des « jetons d'authentification », structures de données binaires représentant un aspect d'une séquence d'authentification. Ces jetons sont échangés via n'importe quel protocole d'application en cours d'utilisation.

Par exemple, dans RPC, une négociation est déjà utilisée pour synchroniser les protocoles entre le client et le serveur. RPC ne fournit dans cette négociation que de l'espace pour les jetons d'authentification opaques et dimensionnés de façon arbitraire. La majeure partie du travail réalisé par les interfaces SSPI et GSS-API concerne la génération et l'évaluation de ces jetons.

Comme nous l'avons vu précédemment, Windows Server et les systèmes d'exploitation client mettent en oeuvre un large éventail de protocoles d'authentification. Ces protocoles sont des « packages de sécurité » (également appelés packages d'authentification) constitués de DLL chargées par le service LSA (Local Security Authority). L'interface SSPI concerne tous les packages de sécurité fournis avec Windows Server et les systèmes d'exploitation client. De manière générale, ces packages de sécurité implémentent un protocole d'authentification réseau tel que le protocole d'authentification Kerberos version 5, la séquence stimulation/réponse NTLM, l'authentification Digest, SSL (Secure Sockets Layer) ou TLS (Transport Layer Security). Les applications peuvent utiliser ces protocoles pour les intégrer de manière sécurisée et transparente avec Active Directory pour authentification. Elles peuvent également utiliser les fonctionnalités des protocoles pour sécuriser les données d'application.

SPNEGO (Secure Protocol Negotiation) est un type spécial de package de sécurité qui négocie les protocoles d'authentification en fonction des besoins. La méthode recommandée pour les applications utilisant SSPI et le protocole Kerberos version 5 ou NTLM consiste à utiliser le package SPNEGO plutôt que ces protocoles. Pour plus d'informations sur SPNEGO, consultez la page Sécurité Windows sur le site Web de MSDN.

Authentification Kerberos

Le protocole d'authentification Kerberos version 5 est spécifié sur la page IETF RFC 1510 du site Web RFC (Request for Comments). Le protocole est extrêmement sécurisé et évolutif, idéal pour l'authentification dans un environnement réseau intégré.

Sur les serveurs et clients Windows s'exécutant sous Microsoft Windows 2000 Server ou ultérieur, le protocole d'authentification Kerberos version 5 constitue la base de l'authentification d'Active Directory. Il est également intégré à SMB, HTTP et RPC, ainsi qu'aux applications serveur et client utilisant ces protocoles. La plate-forme Windows offre à l'utilisateur un environnement utilisateur transparent et intégré pour ce puissant outil de sécurité.

Le protocole Kerberos version 5 est essentiel à la plate-forme Microsoft de gestion des identités et des accès puisqu'il repose sur une norme ouverte. Plusieurs autres fournisseurs ont également implémenté le protocole Kerberos version 5 en se basant sur l'implémentation du protocole du Massachusetts Institute of Technology (MIT), définissant ainsi le niveau d'interopérabilité d'authentification entre les plates-formes et applications Microsoft et non Microsoft.

Windows prend en charge deux méthodes de configuration du protocole Kerberos version 5 pour assurer l'interopérabilité :

• Vous pouvez établir une relation d'approbation entre un domaine Windows et un domaine de protocole Kerberos version 5 basé sur le MIT. Cette relation permet aux clients de ce domaine d'effectuer le processus d'authentification via le mécanisme d'approbation sur les ressources réseau du domaine Windows.

• Les clients et serveurs non Windows peuvent utiliser les comptes Active Directory pour obtenir l'authentification d'un contrôleur de domaine.

Sur un serveur intranet, les implémentations du protocole Kerberos version 5 sur la plate-forme Windows permettent à l'utilisateur d'ouvrir une session unique. Ce scénario d'authentification unique (SSO) est réalisable grâce aux caractéristiques de base du protocole d'authentification et aux fonctionnalités spécifiques de l'implémentation du protocole sur les systèmes d'exploitation client et serveur Windows.

La limitation principale du protocole Kerberos version 5, qui l'empêche ainsi d'être une solution universelle d'authentification et de sécurité de l'application, concerne son inefficacité pour configurer l'authentification Kerberos pour une utilisation sur Internet. Les causes de cette limitation sont étudiées plus en détail dans la section « Authentification Web unique », plus loin dans ce chapitre.

Pour plus d'informations sur le protocole d'authentification Kerberos version 5, voir la page Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability (Guide pas-à-pas de l'interopérabilité Kerberos 5 (krb5 1.0), en anglais) sur le site Web de Microsoft TechNet.

Secure Sockets Layer 3.0 et Transport Layer Security 1.0

SSL 3.0 et TLS 1.0 sont des protocoles étroitement liés que vous pouvez utiliser pour résoudre un problème d'ordre général sur la façon de sécuriser un canal de communication entre deux applications. SSL 3.0 est un protocole Netscape Communications propriétaire, alors que TLS 1.0 est la définition de la norme IETF RFC 2246 sur le site Web RFC (Request for Comments). Les deux protocoles sont identiques, mais TLS n'a pas subi d'améliorations importantes et Microsoft recommande de l'utiliser chaque fois que cela est possible. Les protocoles TLS et SSL permettent d'authentifier le serveur lors de l'établissement du canal de données sécurisées. L'authentification client est disponible en option.

La plupart du temps, ils sont utilisés pour assurer l'intégrité et la protection des données (cryptage) via le protocole HTTP. D'autres protocoles offrent la prise en charge des protocoles SSL ou TLS. Par exemple, le protocole LDAP (Lightweight Directory Access Protocol) intègre SSL pour générer LDAP via SSL ou LDAPS. De plus, les applications personnalisées ou tierces peuvent utiliser les protocoles SSL ou TLS directement via SSPI et spécifier le package de sécurité SChannel.

SSL et TLS proposent une authentification basée sur les transferts de certificats et de données sécurisées à l'aide de clés de cryptage symétriques. Sur Internet, les organisations utilisent souvent SSL et TLS pour l'authentification du serveur. Pour authentifier les serveurs dans SSL et TLS, les clients vérifient les conditions suivantes :

• Le certificat serveur est valide.

• Le serveur s'est avéré possesseur de la clé privée appropriée associée au certificat serveur X.509.

• Le serveur authentifié est identique au serveur spécifié dans le certificat.

Les protocoles SSL et TLS prennent en charge et intègrent également l'authentification client à la plate-forme Windows Server 2003 via les certificats lient X.509. Une authentification client et serveur simultanée correspond généralement à une authentification mutuelle. Pour terminer l'authentification client, le client doit présenter un certificat client valide, reconnu par le serveur en fonction des mêmes critères utilisés pour l'authentification serveur. Après validation du certificat client, Windows Server peut le définir dans un compte Active Directory. Active Directory offre une certaine flexibilité dans la définition des certificats, autorisant les mappages « un à un » ou « plusieurs à un ».

Par rapport à d'autres protocoles d'authentification, SSL et TLS disposent de très bonnes caractéristiques de sécurité lors de l'utilisation des certificats numériques X.509 pour authentification.

Remarque   SSL et TLS offrent une authentification Web unique (Web SSO) aux utilisateurs via le gestionnaire d’informations d’identification Windows sur le client Windows XP, décrit plus loin dans ce chapitre.

Authentification Passport

Microsoft Passport est un service Web qui permet d'authentifier les utilisateurs par rapport à une base de données massive d'identités numériques. Les individus gèrent leur identité Passport via un site Web sécurisé. Passport active les fonctionnalités d'authentification et SSO Web sur un grand nombre de sites Web. Il fonctionne sur plusieurs sites Web Microsoft mais également sur certains sites non Microsoft.

Les développeurs peuvent générer des applications liées à Passport, pour qu'elles n'acceptent que les connexions d'utilisateurs Passport enregistrés. Si Passport détermine la validité des informations d'identification d'un utilisateur, il renvoie un ticket d'authentification que l'application peut décrypter pour déterminer l'identité de l'utilisateur. En raison des exigences de confidentialité, une authentification principale Passport ne fournira qu'un seul PUID (identificateur unique Passport) à l'application affiliée.

De manière générale, l'application définit ensuite le PUID sur un compte utilisateur géré localement pour obtenir une identité numérique valide dans l'organisation. Windows Server 2003 s'intègre totalement à Passport lorsque l'option de configuration de l'authentification Passport est sélectionnée dans IIS 6.0. De plus, vous pouvez définir les utilisateurs Passport sur des comptes Active Directory pour que l'authentification Passport soit totalement intégrée au modèle de sécurité Windows.

L'authentification Passport offre une authentification unique aux utilisateurs pour les applications Internet. Pour ce faire, Passport fournit un ticket d'authentification codé dans un cookie HTTP. Le cookie, qui expire lorsque la session du navigateur se termine, permet d'authentifier plusieurs applications sans que l'utilisateur ait à se connecter continuellement au service d'authentification Passport.

Pour plus d'informations sur Passport, consultez le Guide des services .NET Passport (.NET Passport Service Guide Kit) sur le site Web de MSDN.

Authentification Digest

L'authentification Digest est un autre protocole d'authentification normalisé décrit dans RFC 2617 sur le site Web RFC (Request for Comments), défini en tant que package d'authentification dans Windows Server 2003. L'authentification Digest fournit avant tout une interopérabilité entre les plates-formes Windows et non Windows pour l'authentification Internet.

Windows Server 2003 met également en oeuvre une authentification Digest sous la forme d'un mécanisme SASL (simple authentification and security layer), comme indiqué dans RFC 2831 sur le site Web RFC (Request for Comments). SASL constitue une autre couche d'abstraction entre l'application et le protocole sous-jacent qui facilite l'inclusion de mécanismes d'authentification différents sans modifier l'application. Il est identique sur quelques points au mécanisme SPNEGO décrit précédemment. SASL est principalement utilisé pour l'authentification LDAP.

L'authentification Digest dispose de caractéristiques de sécurité identiques au protocole propriétaire NTLM. Les authentifications Digest et NTLM sont des protocoles de stimulation/réponse nécessitant la génération d'une stimulation contenant un certain nombre de données imprévisibles, par le serveur d'authentification. Le client crée ensuite la réponse en cryptant la stimulation à l'aide d'une clé dérivée du mot de passe de l'utilisateur. Le serveur, ou un service tiers de confiance tel que Active Directory, peut vérifier que l'utilisateur détient le mot de passe correct en comparant la réponse client à une valeur calculée basée sur les informations d'identification relatives à l'utilisateur dans la banque d'identités. Si sa réponse correspond à la valeur calculée, l'utilisateur est supposé connaître le mot de passe secret et est authentifié.

De manière générale, l'authentification Digest n'est pas aussi sécurisée que le protocole Kerberos version 5 car elle dépend de mots de passe renforcés pour protéger le mécanisme de stimulation/réponse contre les attaques. Cependant et parce que le mot de passe sous forme de texte brut n'est pas présenté au serveur lors de l'authentification, elle surpasse l'authentification basée sur les formulaires ou l'authentification Basic. Les protocoles SSL et TLS sont souvent utilisés pour protéger l'authentification Digest contre les attaques.

Comme le protocole Kerberos version 5 dans la plupart des scénarios, l'authentification Digest n'évolue pas, mais fonctionne dans les scénarios où le protocole Kerberos ne fonctionne pas. L'authentification de sites Web exposés extérieurement illustre ce point.

L'authentification Digest n'offre une authentification unique que pour protéger les informations disponibles via une URL Web unique. Si les utilisateurs accèdent à un site différent ou même à un serveur différent sur le même site, ils devront généralement saisir de nouveau leurs informations d'identification.

Authentification basée sur les formulaires

L'authentification basée sur les formulaires s'appuie sur les formulaires d'ouverture de session des pages Web pour recueillir les informations d'identification des utilisateurs, presque toujours dans le formulaire nom d'utilisateur/mot de passe sous forme de texte brut. Ainsi, ce type d'authentification n'est pas un protocole d'authentification entre un client et un serveur comme le sont le protocole Kerberos version 5 ou l'authentification Digest, décrits dans la section précédente.

L'authentification basée sur les formulaires doit être minutieusement contrôlée pour pouvoir protéger correctement une application qui la prend en charge. Microsoft recommande de ne pas l'utiliser sans SSL. Une vulnérabilité exploitée dans une application utilisant l'authentification basée sur les formulaires peut permettre au pirate de collecter des données de mot de passe sous forme de texte brut, ce qui constituerait un sérieux risque de sécurité pour les données d'application dans l'organisation et pour le réseau en lui-même.

L'application effectuant une authentification basée sur les formulaires reçoit des informations d'identification utilisateur sous forme de texte brut ; par conséquent, l'application peut choisir de s'authentifier par rapport à des banques d'utilisateurs autres qu'Active Directory. Microsoft recommande de ne pas utiliser cette approche dans la plupart des cas, car des stockages d'identité supplémentaires peuvent compliquer la solution de gestion des identités et des accès.

Les développeurs d'applications qui implémentent l'authentification basée sur les formulaires sont encouragés à authentifier les utilisateurs dans Active Directory via une liaison LDAP ou un API Windows tel que LogonUser(), pour valider les informations d'identification utilisateur et également générer un contexte de sécurité comme décrit dans la section « Autorisation » plus loin dans ce chapitre.

Les applications qui implémentent l'authentification basée sur les formulaires utilisent généralement des cookies HTTP ou des URL modifiés pour offrir une authentification unique à l'utilisateur. ASP.NET offre une fonctionnalité qui permet de protéger les cookies d'une lecture non autorisée (à l'aide du cryptage) et de toute modification (à l'aide de signatures numériques).

Le document « Développement des applications ASP.NET sensibles à l'identification » de ce kit fournit plus de détails sur la façon dont les développeurs peuvent utiliser l'authentification basée sur les formulaires sur la plate-forme Windows.

Authentification de base

Comme pour l'authentification basée sur les formulaires, l'authentification de base n'est pas vraiment un protocole d'authentification réseau dans le sens où elle ne protège pas de façon cryptographique les informations d'identification de l'utilisateur lorsqu'il s'authentifie sur une ressource réseau. De même, le serveur procédant à l'authentification reçoit les informations d'identification de l'utilisateur sous forme de texte brut, puis utilise les API Windows pour authentifier l'utilisateur. Enfin, le développeur et l'administrateur système déployant cette technique d'authentification doivent rigoureusement veiller à protéger l'application ou le serveur. C'est la raison pour laquelle Microsoft recommande fortement de ne pas utiliser l'authentification de base sans SSL. L'authentification de base dispose des mêmes caractéristiques SSO que l'authentification Digest.

Authentification unique

L'un des éléments les plus importants d'une étude sur l'authentification concerne le concept de l'authentification unique (SSO). Plusieurs approches permettent de procéder à l'authentification unique dans le cadre du processus d'authentification :

• Authentification unique intégrée au bureau (Desktop integrated SSO) ;

• Authentification Web unique (Web SSO) ;

• Mappage des informations d'identification ou authentification unique d'entreprise (Enterprise SSO).

L'authentification unique vise exclusivement à éliminer les besoins en informations d'identification supplémentaires de l'utilisateur, et ne dépend aucunement du niveau de sécurité de l'authentification concernée. Il est possible que certains types d'authentification unique soient privilégiés pour des raisons de sécurité.

De plus, l'authentification unique extranet (Extranet SSO) et l'authentification unique intranet (Intranet SSO) sont des termes utilisés pour se référer aux techniques d'authentification unique dans des scénarios extranet ou intranet. L'authentification unique extranet (Extranet SSO) est généralement de type Web, alors que l'authentification unique intranet (Intranet SSO) peut appeler plusieurs types d'applications et de services, y compris les applications Web, les applications client lourd et les sessions Terminal.

Authentification unique intégrée au bureau (Desktop integrated SSO)

L'ouverture de session sécurisée demande à l'utilisateur de prouver son identité sur un réseau ; cependant l'utilisateur ne souhaite pas forcément saisir de manière répétée son mot de passe pour accéder à de multiples ressources. La plate-forme Microsoft Windows tire parti de la capacité à utiliser une identité utilisateur unique (gérée dans Active Directory) sur le réseau. Les informations d'identification utilisées pour se connecter à la station de travail sont la plupart du temps identiques aux informations utilisées pour accéder aux ressources réseau ; par conséquent, les informations d'identification d'ouverture de session utilisateur (combinaison nom d'utilisateur/mot de passe) sont mises en cache localement dans l'autorité de sécurité locale (LSA, Local Security Authority) sur le système d'exploitation client. Lorsqu'un utilisateur se connecte au domaine, l'authentification Windows utilise les informations d'identification en cache pour offrir une authentification unique lors de l'authentification aux ressources réseau.

L'utilisateur doit fournir une identité authentifiée pour accéder en toute sécurité à une ressource réseau. L'authentification unique permet aux utilisateurs de s'authentifier une seule fois sur le système. Il peut ainsi accéder à toutes les applications et sources de données qu'il est habilité à utiliser sans avoir à saisir un autre identificateur de compte ou mot de passe.

Le protocole d'authentification Kerberos version 5, NTLM et les techniques d'authentification de carte à puce sont tous intégrés au processus d'ouverture de session dans les systèmes d'exploitation serveur et client Microsoft. Ceci dans le but de fournir une authentification unique aux utilisateurs d'un domaine ou d'une forêt Windows dans l'intranet d'une entreprise. Active Directory fournit la tierce partie approuvée qui permet aux serveurs de valider l'identité des utilisateurs sans avoir à enregistrer localement les informations concernant chaque utilisateur.

Les mécanismes d'approbation avancés, tels que les approbations entre forêts dans Windows Server 2003, permettent aux identités d'une seule forêt de bénéficier de l'authentification unique lors de l'accès aux ressources d'autres forêts.

Authentification Web unique (Web SSO)

À mesure que les entreprises déploient des applications Web basées sur l'extranet et l'intranet utilisées par les employés, les partenaires et les clients, la capacité à fournir une authentification unique à l'utilisateur augmente.

Les applications Web sont différentes des applications client/serveur « lourdes » traditionnelles, car elles s'appuient souvent sur le serveur Web pour procéder à l'authentification. Cette dépendance permet d'ajouter des mécanismes d'authentification à une application unique (le serveur Web) tout en résolvant le problème d'authentification pour un grand nombre d'applications hébergées par le serveur. Dans un environnement intranet, les produits client et serveur Microsoft fournissent une authentification Web unique (Web Single Sign On ou Web SSO) en implémentant le protocole d'authentification Kerberos version 5 dans Internet Explorer et IIS 6.0, comme décrit dans le document « Gestion de l'accès intranet » de ce kit.

Malheureusement, l'implémentation Kerberos qui fonctionne correctement dans le scénario intranet ne fonctionne pas pour les applications accessibles sur Internet dans l'extranet d'une entreprise. La différence entre l'authentification Web unique intranet et extranet relève d'une combinaison de trois facteurs :

• Les difficultés inhérentes au déploiement d'un centre de distribution de clés (KDC, Key Distribution Center) Internet, tel que le contrôleur de domaine Active Directory.

• Le fait que de nombreux navigateurs ne supportent pas l'authentification Kerberos sur HTTP.

• Vulnérabilités inhérentes au protocole KDC

Une étude détaillée des difficultés inhérentes au déploiement d'un centre de distribution de clés Internet n'entre pas dans le cadre de ce document, mais le problème est un frein au déploiement.

Le second problème est généralement le plus significatif pour les déploiements extranet. Contrairement aux déploiements internes où les normes logicielles peuvent être appliquées, très peu d'entreprises peuvent définir le type et la version du logiciel de navigation utilisé par les clients et les partenaires commerciaux externes pour l'accès aux applications externes. Microsoft Internet Explorer version 6.0 et ultérieur est l'unique navigateur disponible à la vente qui prend en charge l'authentification Kerberos sur HTTP.

L'approche standard de résolution du problème d'authentification unique sur plusieurs applications Web consiste à utiliser les « cookies » de session comme décrit dans les Mécanismes de gestion de l'état HTTP, définis par IETF RFC 2109 sur le site Web RFC (Request for Comments). Plusieurs éditeurs de logiciels (ISV) proposent des solutions permettant de procéder à une authentification Web unique (Web SSO) via vos applications Web extranet.

Les services de Microsoft Passport, décrits en détail dans la section précédente, offrent également à l'utilisateur une authentification unique aux sites prenant en charge l'authentification Passport.

Vous pouvez associer les techniques d'authentification Web unique (Web SSO) à celles de l'authentification unique d'entreprise (Enterprise SSO), telles qu'un site Web SharePoint Portal Server incluant WebPart, pour l'accès aux données d'application héritées dans un répertoire unique d'authentification. Dans cet exemple, une technique Web SSO donne accès au site Web et une technique Enterprise SSO permet d'accéder aux données d'application héritées.

Mappage des informations d'identification et authentification unique d'entreprise (Enterprise SSO)

L'authentification unique d'entreprise (Enterprise SSO) définit les techniques utilisées par un formulaire de mappage des informations d'identification pour offrir une authentification unique. Le mappage des informations d'identification est fondamental, car différents répertoires ou stockages d'identité sont impliqués dans l'authentification. Un service (qui peut s'exécuter sur le client ou sur un serveur) s'authentifie sur l'application cible au nom du compte, en simulant une authentification unique. Ce service doit rechercher les informations d'identification correctes (comptes, mots de passe, etc.) à partir d'une base de données ou d'un stockage de mappage des informations d'identification.

Microsoft BizTalk® Server, Host Integration Server, SharePoint® Portal Server, Windows Credential Manager et les produits des éditeurs de logiciels tels que PassLogix, Protocom et Version3 utilisent différentes techniques Enterprise SSO pour les anciens systèmes à authentification unique, les applications utilisant leurs propres répertoires pour l'authentification et même pour l'accès aux ressources dans des domaines Windows non approuvés.

L'authentification unique d'entreprise (Enterprise SSO) offre un environnement utilisateur supérieur à une authentification unique avec plusieurs stockages d'identité de non approbation, comme on le constate dans de nombreuses entreprises. L'approche Enterprise SSO devrait être intégrée aux approches de création et de gestion des mots de passe pour garantir un environnement transparent et minimiser les appels su support technique. Cette approche offrira également le meilleur environnement utilisateur tout en limitant le coût total de possession.

Remarque   L'authentification unique intégrée au bureau (Desktop integrated SSO) est privilégiée à l'authentification unique d'entreprise (Enterprise SSO), car elle est étroitement intégrée au répertoire de choix et ne nécessite aucune création et administration de répertoires redondants et de base de données de mappage des informations d'identification.

Pour plus d'informations sur le mappage des informations d'identification via l'authentification unique d'entreprise (Enterprise SSO), consultez le document « Gestion de l'accès intranet » de ce kit.

Gestionnaire d’informations d’identification Windows

Windows XP Professional et Windows Server 2003 incluent une fonction Noms et mots de passe utilisateur enregistrés qui offre également une fonctionnalité de gestion des informations d'identification. En fonction du type d'authentification concerné, ce composant peut enregistrer les informations d'identification utilisateur et les réutiliser lors de nouvelles tentatives d'accès.

Figure 6.2. La fonction Noms et mots de passe utilisateur enregistrés permet de procéder à une authentification unique sur plusieurs informations d'identification

Si l'application ne permet pas à l'utilisateur d'enregistrer ses informations d'identification, celui-ci doit accéder manuellement à la fonction Noms et mots de passe utilisateur enregistrés pour configurer une information d'identification pour cette ressource. Le gestionnaire d'informations d'identification prend en charge les types d'informations d'identification suivants :

• Combinaisons nom d'utilisateur/mot de passe pour le protocole Kerberos version 5 et l'authentification NTLM.

• Certificats numériques X.509 pour l'authentification client à l'aide de SSL/TLS.

• Informations d'identification Microsoft Passport pour l'authentification Web.

Remarque   Vous pouvez utiliser le gestionnaire d’informations d’identification Windows pour offrir une authentification Web unique (Web SSO) à l'aide de l'authentification par certificat client SSL/TLS X.509. Par défaut, les utilisateurs sont invités à sélectionner un certificat pour authentification chaque fois qu'ils disposent de plusieurs certificats valides. Le gestionnaire d’informations d’identification peut garantir que le certificat correct est présenté automatiquement lors de l'authentification d'une ressource spécifique.

Pour plus d'informations sur le gestionnaire d’informations d’identification Windows, consultez le document « Gestion de l'accès intranet » de ce kit.

Autorisation

L'autorisation est le processus par lequel une application ou une plate-forme détermine l'accès à une ressource en comparant les droits utilisateur à la configuration de sécurité de la ressource. Par exemple, un utilisateur peut s'authentifier sur un serveur de fichiers, puis le serveur peut déterminer si l'utilisateur a la capacité de lire, d'écrire ou de supprimer un fichier.

Les applications intégrées au système d'exploitation Windows Server 2003 et à Active Directory utilisent les fonctionnalités intégrées du système d'exploitation pour procéder à l'autorisation.

Windows Server 2003 prend en charge deux mécanismes d'autorisation : le modèle d'usurpation d'identité basé sur les listes de contrôle d'accès (ACL) Windows et le gestionnaire d'autorisation basé sur les nouveaux rôles. De plus, les applications Microsoft ASP.NET peuvent utiliser les rôles ASP.NET pour le processus d'autorisation. Les deux mécanismes sont étudiés en détail dans les sections suivantes.

Usurpation d'identité Windows et listes de contrôle d'accès

Microsoft Windows NT 3.1 a exposé l'usurpation d'identité et le modèle ACL pour l'autorisation des services et des applications. L'usurpation d'identité est le résultat d'un étroit couplage des mécanismes d'authentification et d'autorisation pour une interface utilisateur transparente et une gestion facile.

Un package d'authentification permet d'authentifier l'utilisateur, puis de générer un « contexte de sécurité » pour cet utilisateur. Le contexte de sécurité représente l'identité et les groupes auxquels appartient l'utilisateur, ainsi que les droits utilisateur. Une fois que le package d'authentification génère le contexte de sécurité, l'application ou le service reçoit le contexte de sécurité à utiliser pour autoriser l'accès aux ressources. En d'autres termes, le service peut emprunter l'identité de l'utilisateur localement lors de sa tentative d'accès aux ressources en utilisant le contexte de sécurité de l'utilisateur plutôt que le propre contexte du service.

Ce concept est important, car la plupart des services disposent de plusieurs privilèges sur un ordinateur. Par exemple, le service SMB (server message block), qui fournit des services de fichier et d'impression sur les serveurs s'exécutant sous Windows, fonctionne en tant que système local et a accès à n'importe quelle ressource. Pour limiter l'accès utilisateur aux fichiers conformément aux règles établies par le propriétaire du fichier ou l'administrateur système, le service SMB emprunte l'identité de l'utilisateur distant.

L'autre partie du modèle d'autorisation Windows concerne la liste ACL basée sur l'objet. La liste ACL d'un objet définit les entités de sécurité au niveau de l'accès (utilisateurs ou groupes) de l'objet. Par exemple, la liste ACL sur un fichier peut définir qu'un utilisateur dispose de droits de lecture d'un fichier et qu'un autre utilisateur dispose de droits de lecture et de suppression du fichier.

Le système d'exploitation, en particulier le gestionnaire d'objet NT, est l'arbitre final qui gère l'accès aux objets à l'aide de ce modèle. Pour ce faire, le gestionnaire d'objets NT compare le contexte de sécurité de l'utilisateur à la liste ACL de l'objet. Le système d'exploitation est l'arbitre final, par conséquent le modèle usurpation d'identité/ACL dispose de caractéristiques de sécurité adéquates aux scénarios dans lesquels plusieurs applications peuvent accéder à une ressource système.

Dans certaines zones, cependant, il est possible d'améliorer le modèle usurpation d'identité/ACL, notamment :

• Performances Pour les services distribuant du contenu à plusieurs utilisateurs différents simultanément, le coût d'utilisation de l'usurpation d'identité pour changer les contextes peut générer une charge supplémentaire du serveur qui peut affecter l'évolutivité de l'application.

• Flexibilité Le modèle d'usurpation d'identité ne permet pas au développeur d'applications ou à l'administrateur de services de créer des groupes ou des rôles pour les utilisateurs, sans modifier les membres du groupe au niveau du domaine. Les administrateurs de domaine ne veulent pas créer plusieurs groupes pour une seule application ; les développeurs d'application doivent donc travailler avec les groupes existants.

• Règles métier Le modèle usurpation d'identité/ACL exprime l'autorisation d'objets de façon adéquate, il est toutefois difficile de décrire la logique des règles métier comme on pourrait décrire l'heure ou une autre logique d'exécution. Par exemple, vous pouvez choisir d'appliquer une stratégie d'autorisation qui permet uniquement à certains individus d'exécuter une certaine action pendant quelques heures.

Pour surmonter ces problèmes, Windows Server 2003 inclut un gestionnaire d'autorisations pour les administrateurs système ou les développeurs d'application. La version Windows 2000 du gestionnaire d'autorisations est disponible sur la page de téléchargement Windows 2000 Authorization Manager Runtime du site Web Microsoft.com.

Gestionnaire d'autorisations Windows Server 2003

Le gestionnaire d'autorisations de Windows Server 2003 est une interface de contrôle d'accès basée sur les nouveaux rôles (RBAC). Le gestionnaire d'autorisations offre aux développeurs la capacité d'exécuter les opérations suivantes :

• Simplifier l'administration du contrôle d'accès d'application.

• Fournir un modèle de développement naturel et simplifié.

• Prendre des décisions d’autorisation flexibles et dynamiques.

Pour une tâche donnée, l'interface du gestionnaire d'autorisations classe les utilisateurs dans différents rôles dans l'application et leur donne accès tout en usurpant l'identité de ces rôles. La figure suivante présente trois utilisateurs différents accédant à une application. Le gestionnaire d'autorisations fait correspondre chacun de ces utilisateurs à un rôle défini dans le magasin de stratégies d'autorisation.

Figure 6.3. Définition et application des rôles par le gestionnaire d'autorisations

Le gestionnaire d'autorisations permet de définir et de gérer les tâches et rôles logiques conformément aux besoins de chaque application. La représentation du modèle de sécurité selon une structure organisationnelle simplifie l'administration du contrôle d'accès. De plus, les définitions des rôles et des tâches sont propices à la modélisation des workflows d'application, et à fournir aux développeurs un environnement orienté application via le gestionnaire d'autorisations.

De plus, le gestionnaire d'autorisations qualifie dynamiquement les droits accordés lors de l'exécution. Cette capacité résout le problème d'autorisation distincte pour les applications Web métier, telles que les applications de création de notes de frais ou d'achat Web.

Pour de telles applications, l'accès à des objets persistants correctement définis ne détermine pas, dans la plupart des cas, les décisions d'autorisation. Elles nécessitent plutôt la vérification d'un workflow ou d'un ensemble d'opérations distinctes, telles que l'interrogation d'une base de données et l'envoi d'un message électronique. De telles décisions d'accès ne se basent pas uniquement sur le jeton d'appartenance à un groupe, mais également sur la logique métier, incluant le montant soumis à une application de notes de frais ou la vérification de l'exécution du workflow. Les applications qui ne disposent pas d'objets persistants correctement définis n'ont pas la place de réaliser une liste ACL. Ces décisions d'accès dynamiques sont disponibles dans le formulaire des règles métier dynamiques (BizRules) fourni par le gestionnaire d'autorisations.

Les règles métier sont généralement implémentées à l'aide d'un script VBScript (Microsoft Visual Basic® Scripting Edition) ou d'une routine JScript® qui s'exécute lorsque les droits d'accès sont vérifiés lors de l'exécution de l'application. Si les règles métier réussissent, l'application effectue les opérations requises.

La stratégie du gestionnaire d'autorisations qui définit les tâches et rôles logiques utilisés par une application peut être enregistrée, soit dans une partition d'application dans Active Directory ou Active Directory Application Mode, soit dans un fichier XML sur le serveur ou sur le réseau.

Pour plus d'informations sur le contrôle d'accès basé sur les nouveaux rôles avec le gestionnaire d'autorisations Windows Server 2003, consultez la page Authorization Manager Concepts (Concepts du gestionnaire d'autorisations, en anglais) sur le site Web TechNet.

IIS 6.0 fournit un exemple d'utilisation d'un environnement basé sur les rôles du gestionnaire d'autorisations. IIS 6.0, fourni avec Windows Server 2003, s'intègre au gestionnaire d'autorisations pour implémenter l'autorisation par URL IIS 6.0. Cette intégration permet aux administrateurs d'applications Web de contrôler l'accès aux URL basées sur les rôles utilisateur personnalisés, les requêtes LDAP et les règles métier.

L'accès utilisateur autorisé aux pages Web dans IIS 6.0 peut nécessiter de gérer plusieurs listes de contrôle d'accès discrétionnaire (DACL) sur des ressources utilisées par les applications Web. Les ressources d'applications Web peuvent inclure les fichiers de page Web, les enregistrements de base de données et les clés de registre. La gestion des DACL nécessite une connaissance parfaite, de la part des administrateurs, des exigences d'autorisation principales nécessaires à chaque objet pour exécuter les tâches importantes dans l'application Web.

L'autorisation par URL IIS 6.0 permet aux administrateurs de simplifier la gestion des accès en autorisant l'utilisateur à accéder aux URL qui constituent une application Web. Lorsqu'un client sollicite une URL, l'autorisation par URL IIS 6.0 valide l'accès utilisateur basé sur les rôles de l'utilisateur. Si nécessaire, l'application Web peut restreindre l'accès ultérieurement aux ressources et aux opérations à l'aide de l'environnement basé sur les rôles du gestionnaire d'autorisations.

Autorisation ASP.NET

ASP.NET offre un modèle d'autorisation basé sur les rôles qui utilise les groupes Active Directory ainsi que les rôles dérivés d'une application. Il existe quelques similitudes entre le contrôle d'accès basé sur les nouveaux rôles du gestionnaire d'autorisations et l'autorisation basée sur les rôles ASP.NET. Ils sont cependant mis en œuvre via des mécanismes séparés. Les rôles ASP.NET sont les plus utiles pour les applications autonomes, dont l'appartenance à une plus grande suite d'applications est peu probable.

Approbation et fédération

Dans certaines situations, vous pouvez avoir besoin d'associer au moins deux banques d'identité séparées, par exemple lorsque vous devez implémenter un accord de partenariat ou utiliser des structures de répertoire externes et internes. Cette association permet aux utilisateurs pouvant authentifier un stockage d'identité d'en authentifier un deuxième, même s'ils ne disposent pas d'identité numérique dans le deuxième stockage d'identité. Cette accord est appelé « relation d'approbation ».

Des relations d'approbation existent entre des domaines séparés, où un domaine définit des limites de sécurité. Dans les environnements Windows NT et Active Directory, vous pouvez établir des approbations entre les domaines. Dans Windows Server 2003, vous pouvez établir des niveaux d'approbation supérieurs entre les forêts. Cependant, les domaines d'une forêt ont des approbations implicites entre eux.

Les applications intégrant Windows Server 2003 et Active Directory utilisent les fonctionnalités intégrées du système d'exploitation pour établir et gérer l'approbation.

Gestion des relations d'approbation

Les relations d'approbation de niveau élevé permettent simplement de s'authentifier entre les domaines. Cependant, les mécanismes d'approbation deviennent plus complexes, car diverses tâches doivent s'exécuter dans les domaines pour que l'authentification puis l'autorisation s'avèrent réellement utiles.

La suite de cette section présente les types d'approbations disponibles sur la plate-forme Windows, ainsi que leur utilisation dans le but de résoudre les problèmes de gestion des accès et des identités.

Approbations externes

Microsoft Windows NT Server a introduit le concept des approbations de domaine. L'approbation de domaine Windows NT, ou approbation externe, autorisait un domaine Windows NT à approuver un autre domaine Windows NT en tant qu'autorité pour authentifier les utilisateurs appartenant à ce domaine. Les approbations externes peuvent être à sens unique ou bidirectionnelles, et la direction de l'approbation définit la direction via laquelle l'authentification et l'accès peuvent se produire, comme indiqué sur la figure suivante.

Figure 6.4. Relation entre les domaines d'approbations et les domaines approuvés

Le modèle Windows NT Server 4.0 était très souple et permettait aux départements d'implémenter les domaines Windows NT 4.0 en fonction des besoins d'un modèle de déploiement local ascendant. Au fur et à mesure que les grandes entreprises achetaient de plus en plus de domaines en ligne, la gestion des relations d'approbation externes devenait un problème majeur. Chaque domaine déployé peut avoir n relations d'approbation. Par conséquent, le nombre total de relations d'approbation à gérer augmente rapidement au fur et à mesure que le nombre de domaines augmente. Il est possible qu'une petite entreprise de 4 domaines ne puisse gérer que 12 approbations différentes, une plus grande entreprise de 10 domaines peut cependant avoir à gérer 90 relations d'approbation. Une entreprise de 100 domaines peut avoir à gérer un plus grand nombre de relations d'approbation.

Forêts Windows 2000 Server

Pour simplifier la gestion des approbations dans des grandes entreprises, Microsoft Windows 2000 Server a introduit le concept de la forêt Active Directory. La forêt Active Directory préserve la flexibilité du modèle d'approbation ascendant Windows NT Server 4.0 si nécessaire, mais pose le problème d'une simplification de la gestion des approbations descendante, comme indiqué dans la figure suivante.

Figure 6.5. Forêt Windows 2000 Server unique

Cette figure présente une organisation avec une seule forêt Windows 2000 Server. Les relations d'approbation au sein d'une forêt sont des approbations implicites, qui offrent la même fonctionnalité que les approbations externes bidirectionnelles, mais qui sont créées automatiquement lorsque des domaines (imaginez-les comme des arbres dans une forêt) sont ajoutés à la même forêt. Les domaines d'une forêt sont hiérarchiques, ce qui permet au réseau d'une entreprise de mettre en correspondance les entités commerciales de l'entreprise.

Malheureusement, Windows 2000 Server n'a pas fourni la réponse finale aux relations d'approbation. On a supposé que la plupart des entreprises allaient déployer une forêt unique, répartissant toutes leurs ressources et réseau. Il existe toutefois plusieurs raisons pour lesquelles cela n'a pas été le cas.

Par exemple, certaines grandes entreprises ne disposent pas d'un groupe administratif approuvé de manière centralisée, ayant la responsabilité de gérer toutes les ressources de l'entreprise. Par conséquent dans de telles entreprises, il existe des limites de sécurité naturelles entre les différentes parties de l'entreprise que l'architecture du service d'annuaire doit implémenter. Le besoin de séparer les forêts intranet et extranet est un autre exemple courant. S'il était possible de concevoir l'extranet en tant que domaine de la forêt intranet, de nombreuses entreprises souhaiteraient isoler davantage l'extranet et l'intranet pour des raisons de sécurité.

Pour plus d'informations sur les caractéristiques des limites de sécurité des forêts et domaines Windows, consultez la page « Creating and Enhancing Security Boundaries » (Création et optimisation des limites de sécurité, en anglais) sur le site Web Microsoft.com.

Pour une entreprise disposant de plusieurs forêts avec Windows 2000 Active Directory mais souhaitant utiliser l'approbation entre les domaines des différentes forêts, il est nécessaire d'établir des approbations explicites entre les domaines d'une seule forêt pour chaque domaine de l'autre forêt. Cette configuration n'est que légèrement moins complexe si on la compare à la mise en place d'approbations entre chaque domaine Windows NT Server 4.0. Une meilleure solution semblait clairement nécessaire.

Approbation de forêt Windows Server 2003

Pour faciliter les déploiements de forêt, Windows Server 2003 a créé le concept de l'approbation de forêt. Une approbation de forêt permet aux administrateurs de fédérer deux forêts Active Directory avec une seule relation d'approbation pour créer une authentification et une autorisation transparentes entre elles. Une approbation de forêt est un lien d'approbation unique entre les domaines racine de deux forêts ; elle établit une approbation transitive entre tous les domaines de chaque forêt. Par exemple, si la Forêt A approuve la Forêt B, tous les domaines de la Forêt A approuvent alors tous les domaines de la Forêt B via l'approbation de forêt. La figure suivante illustre ce concept :

Figure 6.6. Approbation de forêt Windows Server 2003

Cependant, les approbations de forêt ne sont pas transitives entre les forêts. Ainsi, si la Forêt A approuve la Forêt B et que la Forêt B approuve la Forêt C, la Forêt A n'approuve pas automatiquement la Forêt C.

Pour plus d'informations sur l'utilisation de la configuration des approbations entre forêts Windows Server 2003, consultez la page Planning and Implementing Federated Forests in Windows Server 2003 (Planification et implémentation des forêts fédérées dans Windows Server 2003, en anglais) sur le site Web Microsoft TechNet.

Utilisation des approbations de forêt

Avec les approbations de forêt, le concept des forêts fédérées devient réalisable dans Windows Server 2003. Comme nous l'avons vu précédemment, une approbation de forêt permet une approbation transitive entre tous les domaines de deux forêts ; l'approbation est établie entre les domaines racine des deux forêts.

Les approbations de forêt peuvent être à sens unique ou bidirectionnelles. Dans la figure précédente, il existe une approbation bidirectionnelle entre la Forêt A et la Forêt B . Pour cette raison, les utilisateurs de la Forêt A peuvent s'authentifier auprès des ressources de la Forêt B et les utilisateurs de la Forêt B s'authentifier auprès des ressources de la Forêt A. Outre l'authentification, l'approbation de forêt permet une autorisation par laquelle les propriétaires de ressources de chaque forêt peuvent ajouter des entités provenant de l'autre forêt aux DACL et aux groupes, ou créer des rôles basés sur ces groupes.

Utilisation de comptes virtuels à la place d'approbations

Les exigences de sécurité vous empêcheront parfois d'utiliser les mécanismes d'approbations Windows entre les forêts. Dans ces cas, vous pouvez créer des comptes virtuels dans un des répertoires pour mettre les comptes en correspondance. En règle générale, le compte virtuel fait correspondre toutes les informations d'identité provenant du domaine source nécessaires à l'application ou au scénario spécifique. Pour satisfaire les exigences de sécurité, les attributs d'identité particulièrement sensibles ne sont pas représentés. Les informations sensibles peuvent par exemple contenir le numéro de sécurité sociale de l'identité ou le mot de passe de l'utilisateur.

L'utilisation de comptes virtuels peut ne pas sembler intuitive pour les employés ; elle peut cependant envisager le cas où une entreprise utilise une instance intranet d'Active Directory pour l'authentification de ses employés, mais souhaite également disposer d'un extranet pour l'utilisation par ses employés. Les deux options d'authentification des employés sur l'extranet sont :

• L'utilisation d'une approbation de forêt ou de domaine du réseau périphérique (également appelé DMZ, zone démilitarisée ou sous-réseau filtré) vers l'intranet.

• La création de comptes virtuels dans le réseau périphérique.

La première option implique l'ouverture d'un certain nombre de ports pour créer un chemin d'accès via le pare-feu, séparant ainsi le réseau périphérique de l'intranet. Cette option est acceptable pour un grand nombre d'entreprises, les autres exigeant un isolement complet entre leurs réseaux périphériques et leurs intranets.

L'utilisation d'un compte virtuel pour les entreprises exigeant une isolation stricte de leurs réseaux peut être la meilleure option. Microsoft recommande de créer des comptes virtuels à l'aide d'un mécanisme automatisé, tel que les mécanismes disponibles dans Microsoft Identity Integration Server 2003, Enterprise Edition (MIIS 2003 SP1). Dans certains scénarios, les comptes virtuels peuvent même être ajoutés à la sécurité réseau s'ils permettent d'exécuter des mécanismes d'authentification non basés sur un mot de passe sur des serveurs moins sécurisés tels que les serveurs de l'extranet. Par exemple, l'authentification basée sur SSL (Secure Sockets Layer) 3.0 et l'authentification par certificat client TLS (Transport Layer Security) 1.0 ou les mécanismes d'authentification OTP (one-time password) tels que le système d'authentification à deux facteurs SecurID de RSA Security Inc.

Approbations d'infrastructure de clé publique (PKI)

Une infrastructure de clé publique (PKI) est un système de certificats numériques, d'autorités de certification (CA) et d'autres autorités d'enregistrement qui vérifient et authentifient la validité de chaque partie impliquée dans une transaction électronique via l'utilisation d'une cryptographie de clé publique. Pour ce faire, chaque partie doit cependant approuver l'émetteur du certificat, le plus souvent une autorité de certification (CA).

Pour les utilisateurs, ordinateurs et services Windows, l'approbation d'une autorité de certification est établie lorsqu'il existe une copie du certificat racine dans la banque d'autorités de certification racine approuvées ainsi qu'un chemin d'accès de certification valide. Un chemin d'accès de certification valide signifie qu'aucun des certificats du chemin d'accès de certification n'a été révoqué ou n'a expiré. Le chemin d'accès de certification inclut tous les certificats délivrés à chaque autorité de certification (CA) dans la hiérarchie de certification, allant d'une autorité de certification subordonnée à l'autorité de certification racine.

Par exemple, pour une autorité de certification racine, le chemin de certification constitue un seul certificat, son propre certificat autosigné. Pour une autorité de certification subordonnée, qui se trouve juste en dessous de l'autorité de certification racine dans la hiérarchie, le chemin d'accès de certification utilise deux certificats : son propre certificat et le certificat de l'autorité de certification racine.

Le processus d'importation d'un certificat racine dans la banque d'autorités de certification racine approuvées constitue la façon la plus simple d'établir une approbation d'infrastructure de clé publique (PKI) pour un ordinateur, ainsi que les applications hébergées par ce dernier. Par exemple, si un serveur Web de Contoso Pharmaceuticals (une entreprise fictive) ne dispose pas de l'autorité de certification du certificat racine pour Fabrikam Inc. (autre entreprise fictive) installée dans la banque d'autorités de certification racine, le serveur Web Contoso approuvera alors n'importe quel certificat valide émis par l'autorité de certification Fabrikam. Toutefois, ce processus n'établit que la part d'approbation de la transaction, il n'établit pas d'identité ou de contexte sur le serveur Web. La création d'un mappage de l'identité au contexte nécessite d'autres actions telles que le mappage de certaines informations du certificat à une entité de sécurité dans Active Directory.

Pour plus d'informations sur l'authentification mutuelle à l'aide du mappage de certificats dans Active Directory, consultez la page Step-by-Step Guide to Mapping Certificates to User Accounts (Guide pas-à-pas du mappage de certificats sur les comptes utilisateur, en anglais) sur le site Web Microsoft Windows 2000 Server.

Bien que le mécanisme de la banque d'autorités de certification racine approuvées soit relativement simple à déployer, il est possible qu'il ne réponde pas aux exigences de sécurité dans les scénarios complexes de création d'une approbation fédérée entre deux entreprises telles que Contoso et Fabrikam. Imaginez un scénario dans lequel les utilisateurs Contoso et Fabrikam peuvent présenter des certificats valides pour accéder au site Web Contoso. Dans ce cas, l'Active Directory externe contiendrait des mappages de certificats provenant des autorités de certification Contoso et Fabrikam.

Un mappage pourrait être établi en se basant sur le sujet du certificat, par exemple : E=fred@fabrikam.com. Le problème de cette approche est lié à l'approbation illimitée. L'approbation illimitée signifie que Contoso est prêt à approuver entièrement Fabrikam pour ne pas émettre de certificat ayant pour sujet E=fred@contoso.com, où fred@contoso.com est un utilisateur de l'entreprise Contoso, et non un utilisateur de Fabrikam. Dans ce cas, le détenteur du certificat pourrait accéder aux données sensibles sur le site Contoso. La cause du problème ne concerne pas la faiblesse inhérente de l'approbation d'infrastructure de clé publique (PKI), mais la trop grande diversité des définitions de certificat. La réponse à ce problème réside dans un mécanisme d'approbation d'infrastructure de clé publique (PKI) pouvant être contrôlé de manière plus précise, qui permettrait à Fabrikam d'émettre des certificats pour le domaine @fabrikam.com et non pour le domaine @contoso.com.

Subordination qualifiée

Il était impossible d'établir une véritable certification croisée des hiérarchies d'autorité de certification au sein d'un réseau Windows 2000. La seule alternative consistait à définir des listes d'approbation de certificats (CTL) qui permettaient d'approuver des autorités de certification spécifiques et de limiter l'utilisation des certificats.

La subordination qualifiée, introduite dans Windows 2003 Server, est le processus de certification croisée des hiérarchies d'autorités de certification par lequel une stratégie de base, l'affectation de noms et des contraintes d'application permettent de limiter les certificats acceptés provenant des hiérarchies d'autorités de certification partenaire ou d'une hiérarchie secondaire au sein de la même entreprise. À l'aide d'une subordination qualifiée, un administrateur d'autorité de certification peut clairement définir les certificats émis par l'infrastructure de clé publique (PKI) d'un partenaire qui sont approuvés par l'entreprise de l'administrateur d'autorité de certification. La subordination qualifiée fournit également des méthodes de cloisonnement et de contrôle de l'émission des certificats au sein d'une entreprise conformément aux règles de la stratégie.

La subordination qualifiée permet également d'établir une approbation entre les autorités de certification dans des hiérarchies d'approbation séparées. Ce type de relation d'approbation est également appelé certification croisée. Dans une telle relation d'approbation, la subordination qualifiée ne se limite pas aux autorités de certification subordonnées. Il est possible d'établir une approbation entre des hiérarchies à l'aide d'une autorité de certification subordonnée dans une hiérarchie, et de l'autorité de certification racine dans une autre hiérarchie.

La subordination qualifiée permet de placer des conditions d'approbation supplémentaires dans et entre les domaines de votre infrastructure de clé publique (PKI) afin de développer votre hiérarchie d'approbation. Avec une subordination qualifiée, chacune des autorités de certification subordonnées qualifiées de votre hiérarchie d'approbation peut disposer de règles différentes régissant l'émission des certificats et l'utilisation possible de leurs certificats.

Un exemple d'utilisation des conditions d'approbation peut résoudre le problème décrit précédemment relatif à la diversité excessive des définitions de certificats. Il consiste à utiliser les contraintes d'espace de noms lors de la création d'une certification croisée entre les hiérarchies Contoso et Fabrikam. De cette façon, Contoso accepterait uniquement les certificats des autorités de certification Fabrikam spécifiant un domaine fabrikam.com.

Pour plus d'informations sur la subordination qualifiée, consultez la page Qualified subordination (Subordination qualifiée, en anglais) sur le site Web Microsoft TechNet.

Implémentation de la fédération

La gestion fédérée des identités est un processus de technologie de l'information et de technologie normalisée qui permet l'identification, l'authentification et l'autorisation distribuées dans des limites de plate-forme et d'organisation. Les systèmes fédérés interagissent dans des limites organisationnelles et connectent les processus utilisant différentes technologies, stockages d'identité, approches de sécurité et modèles de programmation. Au sein d'un système fédéré, une entreprise nécessite une méthode normalisée et sécurisée d'émission des services disponibles aux clients et partenaires approuvés. Une entreprise doit également implémenter les stratégies qui la font exister, telles que :

• Les autres entreprises et utilisateurs approuvés.

• Les types d'informations d'identification et de requêtes acceptés.

• Les stratégies de privilèges appliquées.

Microsoft Windows Server 2003 R2 présente ADFS (Active Directory Federation Services), un outil permettant aux entreprises de partager les informations d'identité d'un utilisateur de façon sécurisée. ADFS offre des technologies d'authentification Web unique (SSO) pour authentifier un utilisateur sur plusieurs applications Web sur toute la durée d'une seule et même session en ligne. ADFS réalise cette authentification en partageant de façon sécurisée l'identité numérique et les habilitations, également appelées « affirmations », dans les limites de l’infrastructure de sécurité et de l'entreprise.

ADFS travaille à la fois avec Active Directory et avec ADAM (Active Directory Application Mode) et plus spécifiquement, ADFS fonctionne avec les déploiements d'Active Directory à l'échelle de l'entreprise ou avec des instances d'ADAM. Avec Active Directory, ADFS peut tirer parti des puissantes technologies d'authentification d'Active Directory parmi lesquelles Kerberos, les certificats numériques X.509 et les cartes Smart Card. Avec ADAM, ADFS utilise la liaison LDAP (Lightweight Directory Access Protocol) pour authentifier les utilisateurs.

ADFS prend en charge l'authentification et l'autorisation distribuées sur Internet. Il peut être intégré dans la solution de gestion d'accès d'un service ou d'une organisation pour traduire les termes utilisés dans l'organisation en affirmations acceptées dans le cadre d'une fédération. ADFS peut créer, sécuriser et vérifier les affirmations qui circulent entre les organisations. Il peut également réaliser un audit de l'activité entre les organisations et les services et la surveiller pour garantir la sécurisation des transactions.

Pour plus d'informations sur ADFS, consultez la page Overview of Active Directory Federation Services (ADFS) in Windows Server 2003 R2 (Présentation d'ADFS (Active Directory Federation Services) dans Windows Server 2003 R2, en anglais) sur le site Web Microsoft.com.

Audit de sécurité

L'audit permet de contrôler les modifications et événements de gestion des accès pour identifier les objets. L'audit de sécurité est généralement utilisé pour contrôler l'occurrence des problèmes et les failles de sécurité. Les technologies telles que le journal d'événements de sécurité de Windows, WMI (Windows Management Interface) et les produits tels que MOM 2005 SP1 peuvent fournir une création de rapports et un audit de sécurité complets.

Audit du service d'annuaire

Active Directory et ADAM sont entièrement intégrés à l'audit Windows Server 2003. Le journal d'événements de sécurité de Windows reflète les modifications apportées aux attributs et aux objets de l'annuaire, ainsi que la stratégie d'autorisation pour les attributs et objets de l'annuaire, le schéma et la stratégie de groupe. Vous disposez d'un contrôle précis sur la configuration d'événements auditables pouvant se baser sur la réussite, l'échec ou la tentative.

Audit d'authentification

La totalité des mécanismes d'authentification Windows décrits ci-dessus génèrent des audits dans le journal d'événements de sécurité de Windows. Vous pouvez configurer les audits à générer (en tant que réussite ou échec d'authentification) à l'aide de la stratégie de groupe, ou configurer manuellement chaque serveur.

Windows Server 2003 fournit également un contrôle précis sur les événements d'authentification en les classant par type d'authentification. Par exemple, un type d'audit effectue le suivi des ouvertures de session console alors qu'un autre effectue le suivi des tentatives d'authentification des ressources réseau. Les audits d'authentification sont toujours traçables sur une entité de sécurité unique.

Une fois que l'utilisateur s'est authentifié auprès de la banque d'identités, la prochaine étape consiste à spécifier les entités auxquelles l'utilisateur peut accéder. L'autorisation est le processus qui contrôle l'accès aux ressources.

Audit d'autorisation

La plate-forme Windows Server offre une prise en charge complète de l'audit d'autorisation des actions. Pour le modèle usurpation d'identité/ACL, le gestionnaire d'objets NT génère des rapports d'audits d'accès aux ressources conformément à la configuration de l'audit. Vous pouvez appliquer cette configuration via la stratégie de groupe ou manuellement sur chaque serveur. Dans la mesure où le système génère ces audits, l'événement d'audit apparaît dans le journal d'événements de sécurité du système.

Les fonctionnalités de la configuration de l'audit sont précises, permettant par exemple d'auditer uniquement les échecs de tentatives d'accès aux fichiers. Les mécanismes d'authentification et d'autorisation sont étroitement intégrés. Par conséquent, l'audit d'autorisation spécifie l'entité de sécurité permettant d'accéder à la ressource en fonction de son identificateur SID unique (security identifier).

Le gestionnaire d'autorisations prend en charge l'audit d'exécution et l'audit de modification de stratégie du gestionnaire d'autorisations. L'audit d'exécution utilise les audits de réussite ou d'échec pour signaler l'initialisation de l'application, la suppression et la création du contexte et l'accès aux objets. L'audit de modification de stratégie du gestionnaire d'autorisations peut signaler toute modification apportée au stockage d'identité, y compris les audits effectués sur la stratégie et la définition de la stratégie.

L'authentification et l'autorisation au sein d'un domaine de sécurité unique ou d'une forêt Active Directory est un processus relativement simple. Cependant, la gestion des identités et des accès doit souvent faire face à une exigence de liaison des deux domaines de sécurité séparés, ce qui nécessite l'implémentation d'une forme d'approbation, entre les services d'annuaire ou les entreprises. Le chapitre suivant revient sur cette exigence.

Audit des approbations

Windows Server 2003 audite intégralement et de manière détaillée la configuration d'approbation. Vous pouvez auditer des événements pour la création, la suppression et la modification des approbations. Les événements d'audit d'approbation apparaissent dans le journal d'événements de sécurité.

Télécharger

Téléchargez le kit Microsoft de gestion des identités et des accès

Notifications de mise à jour

Abonnez-vous aux mises à jour et aux nouvelles versions

Commentaires

Envoyez-nous vos commentaires ou suggestions