Bienvenue CLUB SHAREPOINT FRANCE

 

Vue d'ensemble:
Fournisseurs d'authentification
Les fonctionnalités de cryptage natives
Mappage des accès de substitution et zones
Gestion des droits relatifs à l'information



L'implémentation de mesures de sécurité efficaces pour votre environnement Microsoft Office SharePoint Server (MOSS) 2007 peut réduire de manière significative les tâches de gestion tout en permettant aux équipes de

collaborer et de partager les données de l'entreprise dans un environnement sécurisé. Les fonctionnalités d'authentification innovatrices intégrées dans MOSS 2007 vous permettent d'employer les normes de sécurité Web via des fournisseurs d'authentification personnalisés, l'authentification basée sur les formulaires Internet et l'authentification Web unique (SSO). En outre, MOSS offre une gestion précise des droits des informations d'entreprise tels que les fichiers système Microsoft® Office 2007, les fonctionnalités de cryptage natives et les obligations d'authentification client réduits.

Voici les sept composants de sécurité fournis par MOSS 2007 et qui peuvent être mis en œuvre rapidement.

1. Fournisseur d'authentification enfichable Un fournisseur d'authentification est un composant qui vous permet de vérifier les informations d'identification de l'utilisateur. La configuration de ce fournisseur d'authentification pour votre environnement MOSS est une décision de sécurité importante lors de la configuration de l'authentification Sharepoint® sur Internet. MOSS continue à prendre en charge les méthodes d'authentification basées sur Windows® disponibles dans les versions précédentes de Sharepoint y compris l'authentification intégrée et de base (tout en ajoutant l'authentification Digest) pour résoudre les utilisateurs vers des identités Windows tangibles. Cependant, la résolution d'une identité de Windows n'est plus la seule option. Vous pouvez même employer plusieurs fournisseurs d'authentification afin que, par exemple, les utilisateurs internes se connectent à l'aide de l'authentification Windows alors que les utilisateurs externes se connectent avec un autre fournisseur enfichable.

MOSS s'appuie sur ASP.NET 2.0, qui permet l'utilisation de fournisseurs d'authentification enfichables. Cela vous permet d'utiliser des répertoires configurables pour stocker des informations utilisateur s'il y a un fournisseur d'appartenance ASP.NET 2.0 (et un fournisseur de rôles facultatif) qui correspond au magasin de données des membres. Les informations d'authentification enfichables de fournisseur peuvent être hachées, chiffrées ou enregistrées en texte brut en fonction des valeurs de nœud enregistrées dans le fichier machine.config qui correspond au fournisseur d'appartenance. Plusieurs fournisseurs d'appartenance peuvent être utilisés avec MOSS, dont un fournisseur LDAP V3 (livré avec MOSS), un fournisseur SQL Server™ et un fournisseur Active Directory® disponible avec ASP.NET 2.0.

Les fournisseurs d'appartenance et de rôles qui peuvent être implémentés ne sont pas limités aux fournisseurs envoyés. À l'aide de l'architecture d'appartenance ASP.NET 2.0, il est possible de créer des fournisseurs personnalisés qui utilisent les magasins d'appartenance comme Microsoft Access™ ou les bases de données Oracle, les fichiers XML ou même les fichiers texte plats. Un fournisseur d'authentification personnalisé hérite de l'interface MembershipProvider d'ASP.NET, qui à son tour hérite de la classe ProviderBase (voir Figure 1).


Figure 1 Hiérarchie de la classe Membership de .NET

 

Certaines implications de l'utilisation de l'authentification ASP.NET 2.0 (par opposition à l'authentification Windows) avec MOSS doivent être prises en considération. L'impact le plus significatif pour de nombreux utilisateurs est une interaction moins importante entre les clients Microsoft Office dans la mesure où la communication des services Web entre MOSS et les clients Office a été conçue à l'origine pour une utilisation avec les identités Windows.

En outre, certains services MOSS, notamment ceux qui sont liés à l'analyse et à l'indexation du contenu, doivent utiliser un compte Windows même s'ils disposent d'un fournisseur enfichable. L'utilisation d'un type d'authentification qui ne résout pas une identité Windows implique la création d'une zone MOSS supplémentaire qui mettra en œuvre l'authentification Windows. (J'aborderai les zones plus tard dans cet article).

Si vous disposez d'une infrastructure de clé publique (PKI) mandatée basée sur des mécanismes de sécurité tels que les cartes à puce pour lesquelles les clés publiques ou les certificats sont transportés par les clients, cela nécessite généralement la résolution d'une identité Windows pour une acceptation et une autorisation appropriées de certificat client, selon l'implémentation. Cela peut aussi nécessiter la création d'une zone MOSS supplémentaire ou d'autres configurations d'authentification.

2. Authentification basée sur les formulaires et authentification Web unique Un autre mécanisme d'authentification intéressant disponible dans MOSS 2007, c'est l'authentification basée sur les formulaires d'ASP.NET 2.0. Dans les versions précédentes de Sharepoint, cela pouvait être effectué uniquement via une extension ISAPI (Internet Server Application Programming Interface) personnalisée ou en utilisant l'extension ISAPI CustomAuth à partir du toolkit IIS 6.0. Et même avec ces solutions, Sharepoint a encore besoin du compte pour résoudre une identité utilisateur Windows, ce qui entraîne des déploiements basés sur le périmètre.

L'authentification MOSS basée sur les formulaires utilise les fournisseurs d'authentification enfichable et de rôles pour activer des mécanismes de sécurité Internet qui ne limitent pas les clients à l'ancienne invite de connexion NT. Vous pouvez aussi générer un processus de connexion personnalisé adapté aux besoins de vos utilisateurs. Pour mieux protéger le processus d'authentification, les cookies d'authentification de formulaires et les tickets d'authentification sont cryptés et infalsifiables.

Le fournisseur d'identité de formulaires ne doit pas nécessairement résider localement et peut, en effet, se connecter à un système de gestion d'identité externe, qui à son tour fournit la validation des informations d'identification de l'utilisateur. Cette fonctionnalité est appelée authentification Web unique et utilise un module HTTP pour l'authentification externe. Dans un tel scénario, vous pouvez fédérer des identités entre votre organisation et vos partenaires commerciaux qui leur permettent d'utiliser les connexions de l'organisation pour s'authentifier sur votre implémentation MOSS.

3. Cryptage des chaînes de connexion d'applications MOSS Pour des raisons de sécurité, il est déconseillé de placer les informations de chaînes de connexion importantes en texte brut dans un fichier web.config. Les informations exposées peuvent permettre à un utilisateur de créer une instance d'objet sur le serveur de base de données SQL et de manipuler des données sensibles. Cependant, à l'aide des fonctionnalités inhérentes à ASP.NET 2.0, vous pouvez crypter les données en utilisant l'une des deux technologies disponibles : Le cryptage Windows DPAPI (Data Protection API) ou RSA. DPAPI exploite les fonctionnalités cryptographiques intégrées de Windows pour crypter et décrypter à l'aide de la clé machine du serveur MOSS. Le cryptage RSA vous permet d'utiliser les algorithmes de clé publique, mais est confronté à la nécessité de disposer de conteneurs appropriés pour les clés de cryptage.

Pour MOSS 2007, et plus précisément pour le fournisseur d'authentification enfichable SQL Server d'ASP.NET 2.0, vous devez crypter le nœud dans le texte de chiffrement puisque c'est là que la faille de sécurité la plus significative peut se produire :

Pour les codes voir :

De même que l'architecture générale de MOSS, c'est un modèle enfichable dans lequel vous pouvez créer vos propres fournisseurs de cryptage pour gérer le texte de chiffrement pour les fichiers de configuration MOSS pertinents, tels que web.config ou machine.config, et, de plus, vous n'êtes pas limité au cryptage RSA ou DPAPI.

L'utilisation du cryptage a certaines conséquences. Comme vous utilisez la clé machine locale pour le cryptage, vous ne pouvez utiliser ce nœud de configuration que sur le serveur MOSS sur lequel il a été créé, sinon, le processus de chiffrement échouera. Si un intrus accède au serveur, il peut récupérer la clé machine et décrypter la chaîne de connexion. Le processus de décryptage entraînera également un impact mineur sur les performances des applications.

4. Mappage des accès de substitution et zones Le mappage des accès de substitution (AAM) est crucial, surtout lors de la configuration de plusieurs emplacements d'entrée pour votre environnement Sharepoint. L'AAM vous permet simplement de spécifier plusieurs URL par lesquelles les utilisateurs peuvent accéder à un seul site physique (voir le diagramme de la Figure 2). L'AAM peut diriger les utilisateurs vers le même chemin physique pour votre site MOSS, mais avec différents fournisseurs d'authentification et différentes stratégies de sécurité des applications Web. L'AAM compense également l'utilisation de différents domaines, proxys inversés et d'autres mécanismes de redirection des URL. L'URL que MOSS utilisera est déjà mappée pour vous par défaut, mais cela peut être étendu aux URL supplémentaires qu'un architecte Sharepoint crée explicitement pour gérer différentes méthodes d'entrée. L'AAM est requis pour s'assurer que le mappage des URL internes et publiques appropriées fonctionne correctement.


Figure 2 Mappage des URL et zones

Dans MOSS, les zones sont une nouvelle fonctionnalité qui permet de mieux contrôler le mappage du site fourni par l'AAM. Les zones vous permettent de mapper différents fournisseurs d'authentification vers le même chemin physique et contenu MOSS en fonction des mappages AAM des URL par lesquels les utilisateurs se connectent au contenu. Lors de la spécification des mappages AAM des URL, même s'il n'est pas nécessaire que la zone soit liée à un mécanisme d'authentification, c'est recommandé. Un mappage AAM des URL vers une zone qui n'est pas définie dans la page des fournisseurs d'authentification utilisera le paramètre de sécurité pour la zone par défaut.

Les zones nécessitent une planification puisqu'elles auront un impact important sur la manière dont les utilisateurs sont authentifiés et routés via votre portail à partir de plusieurs points d'entrée des URL. Lors de l'extension d'une nouvelle application Web, vous pouvez spécifier la zone que vous souhaitez utiliser sous la section relative à l'URL d'équilibrage de charge des paramètres (voir Figure 3). Il est recommandé de placer l'URL la plus accessible publiquement (par exemple, l'URL que vous souhaitez exposer sur Internet) dans la zone par défaut, puisque c'est l'URL que Sharepoint utilisera s'il ne peut pas déterminer la zone dans laquelle vous vous trouvez.


Figure 3 Configuration des zones MOSS

 

Dans chaque zone vous pouvez lier une stratégie de sécurité globale des applications Web qui définit des paramètres d'autorisations pour les utilisateurs de la zone. Cela vous permet de gérer de façon centralisée les modifications d'autorisations à grande échelle. Les applications Web incluent généralement plusieurs sites sur différentes collections de sites, et la gestion des autorisations de ces sites peut devenir problématique lorsque les applications sont importantes et complexes. MOSS 2007 permet des stratégies de sécurité globales qui lient les paramètres de stratégie tels que l'accès complet, l'accès en lecture complet, le refus d'accès en écriture, ou le refus total d'accès à un utilisateur ou à un groupe spécifique dans l'application. Ces stratégies peuvent remplacer les paramètres d'autorisation précis fournis par MOSS et gérés à partir de l'interface Administration centrale de SharePoint, donc vous pourrez planifier votre configuration soigneusement.

Votre site exposé extérieurement peut avoir deux URL comme défini dans vos paramètres AAM : une pour l'accès des utilisateurs de votre entreprise et une deuxième pour les utilisateurs externes. Chaque utilisateur dispose d'une URL unique, peut-être contoso pour les utilisateurs internes et extranet.contoso.com pour les partenaires externes fiables. Alors que les deux URL mappent vers le même contenu, chacune peut accéder au site via sa propre zone, avec son propre fournisseur d'authentification et sa propre stratégie de sécurité des applications. La configuration de la zone intranet sur l'URL interne permet aux utilisateurs internes de résoudre leurs identités Windows authentifiées par le domaine tandis que les partenaires externes se connectent via l'authentification Web unique dans la zone extranet, ce qui leur permet d'utiliser les informations d'identification utilisateur propres à l'organisation. Le pouvoir de lier les stratégies de sécurité des applications Web aux zones permet de donner à tous les utilisateurs externes fiables un accès complet en lecture, au lieu d'effectuer une configuration manuelle objet par objet.

5. Contenu ciblé pour une collaboration sécurisée Le verrouillage de vos collections de sites SharePoint signifie que les utilisateurs ne géreront que les informations auxquelles vous les autorisez à accéder. Les nouveaux mécanismes d'autorisations souples permettent un meilleur contrôle sur les différents types d'informations d'entreprise enregistrées dans votre environnement MOSS.

MOSS 2007 vous propose l'option de lier une identité à un objet spécifique, que ce soit une collection de sites, un site individuel, une bibliothèque de documents, un sous-dossier, une liste, un document individuel ou un élément de liste. Cela permet d'appliquer des contrôles d'accès précis et une appartenance explicite à cet élément, en refusant l'accès et en adaptant l'interface utilisateur de sorte que les utilisateurs ignorent les éléments auxquels ils n'ont pas accès. Cette fonctionnalité de MOSS est appelée sécurité au niveau de l'élément (Item Level Security, ILS) ou objets sécurisés (Secured Objects, SO). Les autorisations d'objets MOSS sont hiérarchiques par nature, ce qui leur permet de d'évoluer des objets individuels tels que des éléments de liste vers des éléments plus importants tels qu'une liste ou une bibliothèque de documents. L'héritage des autorisations peut être implémenté, ce qui permet aux objets enfants de niveau inférieur d'hériter de manière facultative des autorisations des objets parents de niveau supérieur. Il existe 33 autorisations uniques par défaut qui peuvent être données à un utilisateur ou à un groupe Sharepoint, chacune d'entre elles peut être liée à un objet. Vous pouvez aussi créer de nouveaux niveaux d'autorisation.

Par exemple, dans un site de gestion de projets, vous pouvez autoriser uniquement les développeurs et les gestionnaires de projets à accéder aux documents de développement sensibles, tels que les spécifications de conception et les techniques de codage intégrées dans les documents Microsoft Word stockés dans une bibliothèque de documents. Les autorisations par défaut de la bibliothèque hériteront des autorisations de site, mais celles-ci peuvent être modifiées pour donner l'accès uniquement aux développeurs et aux gestionnaires de projets ou même pour que chaque document Word puisse être vu et être accessible par le gestionnaire de projet et l'équipe de développement appropriés. À l'inverse, les documents non sensibles peuvent être rendus complètement publics, au niveau de l'élément, du dossier, ou de la bibliothèque de documents.

Les autorisations peuvent même être spécifiées sur les éléments d'événements, tels que les dates d'échéance des projets dans une liste d'événements, afin de vous assurer que seuls certains membres verront les événements spécifiques. De plus, les fonctionnalités ILS s'étendent aux résultats de recherche qui renvoient uniquement les objets mappant vers le contexte de sécurité de l'utilisateur qui effectue la recherche. Ainsi, tous ces contrôles limitent l'interface utilisateur au contexte utilisateur exclusif.

L'architecture de gestion des autorisations a été considérablement améliorée dans MOSS 2007. Les autorisations peuvent être définies pour les groupes Sharepoint et les groupes de domaines, ainsi qu'au niveau individuel. Plusieurs groupes sont déployés par défaut, notamment les Propriétaires (qui obtiennent le contrôle total), les Visiteurs (qui obtiennent des droits de collaborateur) et les Membres (qui obtiennent des droits de lecture). Des individus ou des groupes de domaines peuvent être attribués à ces groupes par défaut ou à des groupes personnalisés que vous pouvez créer et gérer au niveau des collections de sites, qui peuvent avoir différents niveaux d'autorisations uniques.

Lors de la création des groupes basés sur des rôles, vous pouvez créer des groupes « développeurs » et « gestionnaires de projets ». Il est possible ensuite d'attribuer des autorisations précises qui permettent, par exemple, aux développeurs de télécharger la documentation de codage pertinente et d'accorder des autorisations de lecture et d'approbation aux gestionnaires de projets afin qu'ils puissent évaluer et approuver ces documents. L'appartenance aux groupes reste cohérente dans la collection de sites afin que les groupes créés puissent être réutilisables à travers différents sites de projets.

6. Intégration de l'authentification unique enfichable Dans un environnement informatique classique un utilisateur peut accéder à toutes les applications tierces, chacune avec ses propres critères d'authentification, ce qui entraîne divers problèmes de sécurité et la fragilisation des mots de passe. Le service d'authentification unique MOSS permet d'éviter ce problème en fournissant un cache principal crypté d'informations d'authentification des utilisateurs pour mapper vers les systèmes métier connectés. Cela peut permettre de récupérer des informations essentielles de l'entreprise à afficher via les mécanismes MOSS tels que le catalogue des données de l'entreprise (BDC) ou les composants WebPart DataView de Sharepoint (DVWP).

Le fournisseur d'authentification unique (SSO) MOSS, comme plusieurs autres fonctionnalités architecturales d'applications abordées, est enfichable ; vous pouvez spécifier un fournisseur SSO extérieur à celui qui a été livré avec MOSS (SpsSsoProvider), bien qu'un seul fournisseur SSO par système métier puisse être enregistré à la fois dans l'environnement.

7. Gestion des droits relatifs à l'information (IRM) La protection des informations au niveau client même lorsque les informations d'entreprise sont mises hors ligne constitue une préoccupation majeure pour les entreprises qui ont tendance à traiter des données sensibles, surtout celles qui relèvent de législations telles que le Projet de loi N° 1386 du Sénat de Californie, Sarbanes-Oxley (conformité SOX), et l'Acte de responsabilité et de transférabilité de l'assurance santé (Health Insurance Portability and Accountability Act (HIPAA)). La Gestion des droits relatifs à l'information (IRM) côté serveur intègre des référentiels MOSS pour fournir une solution commune basée sur l'environnement de Gestion des Droits Windows (WRM). L'IRM permet de contrôler étroitement les données de l'entreprise en imposant des restrictions d'accès au niveau des documents, quel que soient l'emplacement de stockage du document ou l'utilisateur qui essaie de l'ouvrir. Une implémentation commune de la gestion IRM permet d'autoriser l'affichage ou l'impression, mais cela peut s'étendre à d'autres scénarios tels que la vérification d'informations d'authentification d'utilisateur après une période donnée, l'interdiction de télécharger des ressources qui ne bénéficient pas de la gestion IRM, une balise d'expiration planifiée qui supprimera la stratégie de restriction et la liaison à une stratégie globale d'autorisation de la gestion IRM de l'organisation.

Les fonctionnalités IRM sont fournies par un protecteur et plusieurs sont installés avec MOSS 2007. Un protecteur est une application qui gère le processus de cryptage pour un type de fichier, généralement tous les fichiers que vous enregistrez dans MOSS disposent déjà de protecteurs intégrés. (Les fichiers système Microsoft Office sont pris en charge en mode natif, avec les formats de fichier OpenXML). Cependant, comme les autres fournisseurs au sein de MOSS, l'architecture des applications est enfichable de sorte que vous pouvez implémenter des protecteurs personnalisés pour les autres types de fichier.

La première étape de l'implémentation IRM est de s'assurer que vous répondez à toutes les exigences de votre environnement MOSS. Le client des services WRM doit être installé sur chaque serveur Web MOSS frontal et les services de Gestion des droits Microsoft (RMS) doivent être connectés à vos serveurs Web MOSS frontaux. Vous devez ensuite spécifier le serveur RMS que MOSS doit assimiler via l'Administration centrale de SharePoint, en utilisant la valeur par défaut d'Active Directory ou en spécifiant l'emplacement.

IRM fonctionne directement avec les structures de magasin de données de Sharepoint telles que les bibliothèques de documents pour maintenir les autorisations. Lorsqu'un utilisateur accède à une bibliothèque de documents IRM et essaie de télécharger un document, MOSS lie les autorisations configurées pour la bibliothèque au document (voir Figure 4). Par conséquent, il existe un mappage 1:1 entre MOSS et les autorisations de documents, convertissant les rôles de Sharepoint liés au document en niveaux d'autorisation IRM dans le document lui-même.


Figure 4 Transition des autorisations IRM à partir d'une Bibliothèque de documents

 

Le document est crypté localement pour une protection hors ligne et maintenu dans cet état jusqu'à son téléchargement dans la bibliothèque de documents. Lorsque le document est téléchargé, il est maintenu dans un formulaire non crypté afin que le rassembleur Sharepoint indexe son contenu pour une recherche de texte intégral (bien qu'aucun compte utilisateur ne puisse accéder au contenu dans le formulaire non crypté).

MOSS 2007 fournit un certain nombre de nouvelles fonctionnalités qui permettent d'implémenter une sécurité efficace dans votre organisation sans ajouter de nombreuses tâches de gestion. En outre, les fonctionnalités très flexibles offrent de nombreuses possibilités de personnalisation pour assurer aux utilisateurs un accès direct aux informations dont ils ont besoin. Voir l'encadré « Fournisseur d'authentification SQL Server » qui donne un exemple simple.



--------------------------------------------------------------------------------
Adam Robert Buenz est architecte Sharepoint et développeur pour ARB Security Solutions LLC (sharepointsecurity com). Il se concentre sur les environnements de collaboration centrés sur la sécurité. Contactez-le à l'adresse adam@sharepointsecurity.com.

--------------------------------------------------------------------------------