Microsoft SharePoint se répand dans l’entreprise de façon souvent anarchique. Quels sont les risques spécifiques à SharePoint ? Comment en répertorier toutes les installations, et comment les sécuriser ? SecurityVibes explore l’univers sécurité de SharePoint en cinq points-clés.

« SharePoint, c’est typiquement le genre de projet qui commence petit et qui explose », explique Luis Delabarre, architecte sécurité chez Trend Micro. Et le problème avec un tel succès, lorsqu’il n’est pas anticipé, c’est que la croissance cède alors rapidement le pas à l’anarchie : des installations SharePoint poussent n’importe où, et surtout loin de toute bonne pratique encouragée par la DSI. Chaque embryon de projet essaiera d’avoir « son » SharePoint ! « Et puis c’est de toute manière un outil très métier, détenu le plus souvent par ces derniers sans trop d’intervention de la SSI », ajoute Luis Delabarre.

L’engouement est toutefois bien compréhensible : si les solutions de collaboration purement web 2.0 sont nombreuses elles ne sont pas encore vraiment entrées dans les moeurs de l’entreprise. Pour ces dernières, déjà souvent équipées d’outils Microsoft, SharePoint reste la voie la plus évidente : simple à installer et surtout parfaitement intégré à la suite bureautique Office il permet de bénéficier immédiatement de fonctionnalités de publication, de consultation, de partage et de validation des documents de la suite Microsoft Office. Sur le papier, c’est donc une très bonne idée.

Sur le terrain cependant cette pratique introduit des risques qui, s’ils ne sont pas tous nouveaux, n’en demeurent pas moins souvent ignorés. Car une installation SharePoint n’est pas la solution monolithique qu’il y paraît au premier abord : il s’agit en réalité de l’assemblage d’un serveur web IIS pour le front-end, d’un serveur d’application au milieu et d’une (ou plusieurs) base MS SQL Server derrière. Et chacun de ces tiers peut introduire des risques spécifiques.

Afin de vous aider à sécuriser SharePoint nous avons relevés cinq points vitaux à traiter en priorité : la prolifération sauvage d’instances SharePoint, leur configuration non-conforme aux pratiques de l’entreprise, l’authentification des utilisateurs, la sécurité des contenus qui y sont stockés et, enfin, la lutte antivirale.

1. Prolifération sauvage

C’est un fléau que l’on retrouve avec tout outil simple à déployer et efficace : les métiers ne s’en lassent jamais et la DSI n’a pas besoin d’être sollicitée pour son installation ou son maintient. Dans le cas de SharePoint cela représente un facteur aggravant pour l’ensemble des risques que nous évoquerons ci-dessous. La prolifération des installations rend par exemple difficile le suivi des mises à jour, l’application d’une politique de sécurité uniforme aux contenus stockés et la bonne gestion des droits d’accès utilisateurs.

La réponse passe ici d’abord par une politique de sécurité claire qui oblige les métiers à déclarer les installations. Le réglement sera respecté grâce à l’analyse régulière du parc à la recherche d’installations sauvages. Microsoft et Quest Software offrent par exemple tous deux un outil gratuit pour scanner les installations SharePoint inconnues sur le réseau.

Au delà des installations sauvages à proprement parler, une autre forme de prolifération secondaire peut provenir des sites personnels hébergés par les utilisateurs sur SharePoint. « Dans les installations SharePoint sur l’intranet chacun peut avoir son propre site (avec la fonctionnalité « MySite » ). Il est possible d’utiliser des politiques de groupes (GPO) afin de restreindre cette fonctionnalité et de limiter ainsi la prolifération de ces sous-sites », explique Bernard Ourghanlian, Directeur Technique & Sécurité pour Microsoft France.

2. Installations non-conformes à la politique de sécurité

Si le règlement de l’entreprise impose certainement une configuration-type pour ses bases de données, ainsi que leur maintient par un personnel certifié par l’éditeur, qu’en est-il des bases MS SQL Server Express Edition installées avec SharePoint ? Et même si une véritable base de données est déployée pour SharePoint, celle-ci est généralement vue comme un pré-requis un peu nébuleux dont il convient de se débarrasser rapidement, et elle répondra rarement aux standards de configuration de l’entreprise en la matière.

Or, la base de données est un point critique de SharePoint, et elle pourra être attaquée directement, en dehors du cadre de l’accès contrôlé par SharePoint. Et puis les administrateurs SharePoint sont rarement aussi administrateurs (compétents) de bases de données…

La solution pourra être dans ce cas de considérer SharePoint au même titre que les autres applications critiques de l’entreprise (le CRM, par exemple) et le faire bénéficier d’une véritable stratégie de sécurité en propre. Pour une première mise en oeuvre le Gartner a publié un guide de sécurisation pour SharePoint 2007 (payant) tandis que Microsoft prodigue quant à lui ses conseils en la matière sous la forme d’un livre électronique à télécharger gratuitement.

Dans l’absolu le problème n’est cependant qu’une très traditionnelle question d’architecture et de configuration. Pour l’architecture, il ne faut pas perdre les bonnes habitudes : « nous conseillons de cloisonner entre elles les différentes couches qui composent une installation SharePoint de manière très classique, avec pare-feu et détection d’intrusion entre chaque couche. On peut aussi ajouter du contrôle d’intégrité et de l’analyse de journaux, mais il faut alors que ces solutions soient capables de reconnaître SharePoint », précise Marc Chisinevski, architecte sécurité chez Trend Micro.

Du côté de l’organisation, il semble vital de formaliser la gestion des droits des utilisateurs. « L’administration de SharePoint est très puissante ! On peut préciser les droits utilisateurs de manière très granulaire avec des héritages puissants et de la délégation d’administration. Si l’on décide d’utiliser ces fonctionnalités il faut avoir un document très précis qui détaille les délégations et les héritages mis en place. Sans cela on risque de faire beaucoup de choses sans réfléchir aux conséquences et on fini par se retrouver avec un gigantesque plat de nouilles ! », met en garde Bernard Ourghanlian. Et de préciser, tout de même, qu’une fonctionnalité de vérification des autorisations permet aux administrateurs de balayer leur configuration afin de s’assurer de la cohérence des droits attribués.

3. Authentification des utilisateurs

Le rôle de SharePoint étant de permettre l’échange, le stockage et la publication de documents, le contrôle d’accès à la plate-forme est un aspect essentiel de son installation. « On peut considérer SharePoint comme l’extension applicative très élaborée d’un annuaire : il va falloir définir, comme pour un annuaire, des rôles d’administration divers (serveurs, services, etc) et des rôles liés au contenu (éditeur, modérateur, etc) », conseille Bernard Ourghanlian.

Mais pour cela encore faut-il authentifier l’utilisateur ! SharePoint 2007 peut s’appuyer à cet effet sur trois technologies : l’authentification intégrée à Windows (via Active Directory), des formulaires ASP.NET et un SSO propre.

Bien entendu, la solution Active Directory n’est pas adaptée aux usages externes (portail public) mais uniquement à des installations sur l’intranet. Si SharePoint doit faire cohabiter des utilisateurs internes et externes il faudra alors probablement gérer deux bases d’utilisateurs différentes. Du côté externe il pourra s’agir d’un annuaire compatible LDAP connecté grâce au LDAP Membership provider fourni avec SharePoint 2007 ou bien d’une base de données SQL dédiée à l’authentification tierce, le tout relié à un formulaire ASP.NET. Et pour des utilisateurs vraiment inconnus (pas de base d’authentification possible) Microsoft offre un connecteur pour Windows Live ID.

Si toutefois les utilisateurs extérieurs appartiennent tous à une même organisation avec qui un lien de confiance peut être établi il sera possible de mettre en oeuvre un système de fédération d’identité afin de ne pas avoir à gérer individuellement les utilisateurs extérieurs. Mais c’est là un tout autre projet !

Plus riche, SharePoint 2010 a considérablement étendu les capacités d’authentification des utilisateurs. « La version 2010 introduit un nouveau modèle de sécurité qui prend en charge l’authentification par revendication d’identité (claims, ndlr). Cela change de manière significative la façon dont SharePoint gère et utilise l’identité : plutôt que de ne s’appuyer essentiellement que sur Active Directory ou une base SQL Server à travers ASP.NET, SharePoint 2010 devient agnostique en la matière. Il implémente pour cela un STS construit sur Windows Identity Foundation (ex projet Geneva, ndlr). Cela l’ouvre de fait à WS-Trust et WS-Federation, et nous supportons maintenant les jetons de sécurité SAML. Nous n’avons plus besoin d’avoir nécessairement une base de comptes locales ou même une base de données », précise Bernard Ourghanlian.

Attention enfin : sous SharePoint 2007 les droits des utilisateurs sont gérés localement pour chaque installation. Il est donc difficile d’avoir une vision globale des droits de toutes les installations. Seule solution : tout exporter et compiler un rapport global ou s’appuyer sur un outil de gestion tiers qui le fera à votre place (CA, Quest Software, RSA et d’autres).

Le problème se pose moins avec la version 2010, qui pourra utiliser des identités issues de Windows Identity Foundation (et donc gérées de manière centralisée) et qui est en outre multi-tenants (des installations totalement distinctes peuvent être hébergées et gérées depuis la même ferme de serveurs SharePoint).

4. Gestion des droits du contenu

Contrôler l’accès à la plate-forme, c’est bien, mais qu’en est-il des droits associés au contenu lui-même ? Il s’agit là en fait de l’un des principaux reproches envers SharePoint : la facilité avec laquelle il est possible d’extraire des données métiers confidentielles d’une application chez qui elles sont correctement protégées afin de les partager et de les traiter « sur un coin de table », sans aucune protection. Ce n’est bien entendu pas « la faute » à SharePoint en soit : « il n’y a fondamentalement pas de problème de sécurité avec SharePoint, mais tout outil qui sert à partager des données est quelque part antinomique avec la SSI » fait remarquer Hervé Schauer, du cabinet HSC. Mais il existe malgré tout un risque de dissémination incontrôlée de données protégées via SharePoint.

La première réponse face à ce risque donne l’impression d’enfoncer des portes ouvertes tellement elle est évidente : l’installation SharePoint doit être bien configurée en terme de droits et de contrôle d’accès. C’est un préalable incontournable. Mais une fois le contrôle d’accès pris en charge il est devient possible d’aller bien plus loin au niveau du contenu grâce à l’intégration entre SharePoint et Windows Rights Management Services (RMS), la solution de DRM proposée par Microsoft.

SharePoint s’intègre en effet à RMS depuis la version 2007. « Il est alors possible de définir au sein d’une arborescence SharePoint un certain nombre de zones à l’intérieur desquelles des droits d’usage seront appliqués de manière obligatoire et automatique aux documents qui y sont déposés », explique Bernard Ourghanlian. Ainsi lorsque ces mêmes documents seront ensuite téléchargés hors SharePoint, ils conserveront leurs droits d’accès grâce à RMS. On peut ainsi imaginer des zones par service de l’entreprise, dont les documents déposés ne pourront être consultés que par des membres du bon groupe (au sein de chaque service, donc), y compris une fois copiés localement sur un poste de travail.

« En interne chez Microsoft nous avons par exemple commencé par classifier de manière automatique les anciens sites SharePoint existants en fonction de leurs mots-clés, de leurs auteurs et de leur position hiérarchique. Pour les nouveaux sites nous avons désormais obligation, lors de la création, de préciser le niveau de confidentialité des documents qui y seront déposés. Les droits y sont ensuite appliqués automatiquement », révèle Bernard Ourghanlian.

Si l’entreprise a déjà déployé une solution de prévention des fuites de données (DLP) elle pourra bien entendu également mettre celle-ci à profit, notamment pour s’assurer que les instances SharePoint ne contiennent pas d’information soumises à des restrictions réglementaires de type PCI-DSS. De nombreux vendeurs de DLP proposent ainsi une intégration spécifique à SharePoint (par exemple RSA avec son Data Loss Prevention RiskAdvisor for Microsoft SharePoint ou Trend Micro avec PortalProtect, Symantec DLP…).

A noter enfin que le serveur de messagerie Exchange est capable de prendre des décisions en fonction des tags placés par le DRM et SharePoint et ainsi, par exemple, interdire l’envoi par email de documents déclarés internes.

5. Lutte antivirale

La question de l’antivirus pour SharePoint se pose au même titre que pour la messagerie : car il s’agit d’une solution qui voit passer de nombreux documents et peut, le cas échéant, devenir un vecteur d’infection. Mais inutile d’installer pour autant un antivirus traditionnel sur le serveur qui héberge SharePoint, il ne verra rien. « Un antivirus standard pour serveur ou poste de travail sera inefficace sur une installation SharePoint car aucun document n’y est stocké : ce n’est qu’une base de données locale, voire distante. Tout doit se passer au niveau des flux avant d’atteindre la base de données » explique David Grout, Ingénieur avant-vente chez McAfee.

La solution est donc d’y installer un antivirus dédié capable de converser avec l’API d’inspection des flux fournie par Microsoft. « C’est un mécanisme très proche de ce qui se passe avec le filtrage antivirus sous Exchange (il s’agit d’ailleurs de la même API, ndlr). SharePoint va soumettre le document dans une zone tampon avant son écriture en base de données afin de l’analyser. On va alors pouvoir effectuer toutes sortes d’opérations : l’analyse antivirale bien sûr, mais aussi y appliquer des filtres (pas de fichiers de type MP3 ou exécutables, par exemple) ou des règles basées sur le contenu (expressions régulières, dictionnaire, etc) », poursuit David Grout.

Située au coeur de cette capacité d’inspection à la volée la librairie fournie par Microsoft – baptisée VSAPI pour Virus-Scanning API – est incontournable. Et pour SharePoint 2010, Microsoft vient de l’améliorer singulièrement afin justement de permettre des traitements plus efficaces. « Nous exposons notamment un certain nombre d’informations qui ne l’étaient pas auparavant (le nombre de fichiers à scanner par exemple), et nous permettons désormais la mise en quarantaine ou la possibilité de contourner l’analyse de gros fichiers, par exemple pour des type BLOB qui n’ont pas de sens pour un antivirus », détaille Bernard Ourghanlian. Bien entendu, le produit antivirus choisi devra être capable de tirer partie de cette nouvelle version de la VSAPI.