Au cœur de SharePoint Sécurisation des communications SharePoint externes

Pav Cherny

Contenu

Conception de topologie
Authentification
Site configuration pour prendre en charge TLS
Configuration de IIS pour les certificats SSL
Configuration de ISA Server
Simplifier votre douleur

Cryptage du trafic SharePoint dans les scénarios Internet accessible en utilisant TLS (Transport Layer Security) / SSL (Secure Sockets Layer) est une approche familier pour sécuriser la communication. Depuis 1995 lorsque Netscape introduit SSL comme un moyen de sécuriser les données par chiffrement implémenté sur le protocole HTTP, communication client/serveur basée sur le Web a reposent largement sur les certificats SSL. Les technologies SharePoint tirer parti de TLS via IIS avec .NET, qui fournissent la plate-forme de serveur Web prenant en charge TLS sous-jacente. Toutefois, l'activation de TLS pour les sites SharePoint est qu'un seul des aspects de sécurisation des communications externes. Vous devez également considérer autres facettes comme basé sur ordinateur hôte et réseau pare-feux, conception de topologie, sous-jacent Active Directory et dépendances de réseau physique.

Dans la colonne 2009 juillet, j'ai abordé options pour sécuriser la communication serveur dans l'environnement interne en appliquant des stratégies d'intégrité à NAP (Network Access Protection) avec IPSec et en générales SharePoint sécurité méthodes conseillées suivantes. Une des locaux principaux de sécurisation des communications internes est connaître l'identité des utilisateurs internes et des ordinateurs et, en fonction de cela, création de stratégies pour accorder et limiter l'accès. Ce principe est efficace dans un environnement authentifié comme celui qui utilise Active Directory et Kerberos ou NT LAN Manager (NTLM), mais il est incomplet dans les environnements où au moins certains des utilisateurs sont anonymes ou où une classe d'utilisateurs, comme fournisseurs ou partenaires, devez différentes stratégies appliquées. Sécurité dans le contexte des sites Internet requiert une approche similaire d'utilisation de plusieurs couches.

Parmi les principes sous-jacents de sécurisation des communications externes bloque tout accès indésirable dès que possible, lors de la possibilité d'effectuer des audits de sécurité et journalisation pour les utilisateurs non authentifiés et authentifiés. L'approche classique à satisfaire ce besoin consiste à utiliser au minimum, un pare-feu à la périphérie du réseau pour l'utilisateur d'authentification et état inspection du trafic HTTP. Toutefois, TLS pose un problème d'inspection des paquets avec état, car le pare-feu doit pouvoir décrypter les paquets, les inspecter, rechiffrer les et les passer à un serveur frontal pour le traitement. En outre, le pare-feu (et toute solution d'équilibrage de charge) doivent préserver les sessions HTTPS. Internet Security and Acceleration (ISA) Server 2006 et Intelligent Application Gateway (IAG) Server 2007 offrent une solution pare-feu qui fonctionne conjointement avec IIS et SharePoint pour fournir un moyen de TLS compatible de sécurisation des communications.

Comprendre les communications TLS dans SharePoint nécessite une connaissance d'incidences sur l'architecture et topologie hébergement la façon dont IIS et des pare-feux gérer les certificats SSL. En conséquence, il existe un certain nombre de considérations pour concevoir et déployer les solutions SharePoint qui sont accessibles à partir d'Internet. L'architecture SharePoint inclut certains aspects de configuration complexe en plus des considérations de IIS, SSL et pare-feu, telles que les autres mappages d'accès (AAM), l'authentification et zones de SharePoint.

Conception de topologie

Développement de plusieurs couches de sécurité pour les sites SharePoint commence par définir la topologie du réseau physique. Si vous pouvez réduire ou éliminer le trafic indésirable avant qu'il rencontre des serveurs frontaux et principaux, vous non seulement réduire la charge du serveur mais également limiter les risques de virus, spam et les logiciels malveillants qui accompagnent le trafic malveillant.

La topologie de réseau qui prend en charge TLS pour SharePoint varie selon le scénario d'utilisation requis pour votre organisation. La figure 1 présente une arborescence de décision avec certaines considérations et les décisions pertinentes topologie.

Vous pouvez simplifier encore les décisions en séparant les diverses options topologie en trois zones :

• Trafic avant qu'il atteigne le pare-feu.
• Trafic entre le pare-feu et le réseau interne.
• Trafic dans le réseau interne.

Figure 1 Considérations sur la décision topologies Internet accessible.

En termes de configuration TLS, le rendant cette distinction est essentiel car vous devez configurer Routage et pare-feu règles pour relier les connexions HTTPS entre les requêtes Internet et les serveurs IIS frontaux, configurer IIS pour fournir des applications SharePoint et assurez-vous que les ressources internes sont protégés. Selon la topologie, le trafic TLS peut doivent pouvoir parcourir le trois de ces zones plusieurs routeurs et pare-feu. Nous allons Examinez trois options de topologie de sites Internet accessibles et déterminer comment les topologies affectent le trafic TLS. La figure 2 présente une «côté» de basetopologie avec un pare-feu sécurisation des serveurs internes.

La figure 2 Bord base topologie avec un seul pare-feu.

Dans la topologie de bord, un pare-feu réseau unique est l'abréviation entre les utilisateurs externes et les sites SharePoint internes. Il présente l'avantage d'utiliser un seul environnement pour utilisateurs internes et externes, qui simplifie la maintenance et l'administration. Pour sécuriser le trafic via TLS, vous configurez le pare-feu pour agir également comme un proxy inverse. Le concept d'un proxy inverse intégré tel que ISA Server est indispensable pour la sécurisation des sites Internet, car le proxy inverse intercepte les demandes entrantes, peut authentifier les utilisateurs externes, décrypte le trafic TLS, inspecte conformément aux règles de pare-feu et transfère les demandes aux serveurs frontaux. URL publiques peut différer des URL internes, afin de proxy inverse doit avoir un moyen de traduction de liens pour convertir les URL externes dans les URL internes. IAG Server offre des fonctionnalités de sécurité supplémentaires, telles que point de terminaison, l'état autorisation via une stratégie d'accès basée sur utilisateur identité et le client ordinateur intégrité et la possibilité de la traduction des liens URL SharePoint interne lors de l'utilisation d'Outlook Web Access.

Pour ajouter une couche supplémentaire à la topologie et exercer un contrôle plus précis sur la communication entre serveurs, vous pouvez créer un réseau de périmètre qui héberge les serveurs SharePoint. Dans un réseau de périmètre, les serveurs SharePoint sont isolés à partir d'Internet par un pare-feu et à partir du réseau interne par un pare-feu. Ceci est une topologie DOS à DOS, comme illustré dans figure 3.

La figure 3 Topologie “ DOS à DOS respectez avec deux pare-feux.

Bien sûr, vous n'êtes pas limité à deux pare-feux dans une topologie DOS à DOS. Vous pouvez implémenter des couches supplémentaires séparés par des pare-feux ou routeurs supplémentaires pour séparent les rôles de SharePoint. Par exemple, vous pouvez utiliser une approche à trois couches, placer chaque couche dans une zone DMZ, où les serveurs frontaux sont tout d'abord, suivi par serveur application, de la base de données et/index de recherche et a conclu par les serveurs Active Directory/DNS. Vous pouvez également personnaliser une topologie DOS à DOS pour inclure un environnement de test interne dans une batterie de serveurs distinct et le publier à la batterie de serveurs dans le réseau de périmètre. Une autre option consiste à fractionner la batterie entre le réseau de périmètre et le réseau interne pour créer une topologie DOS à DOS fractionnement, comme dans la figure 4. Conformément à l'approche d'utilisation de couches de sécurité dans la topologie de serveurs frontaux résident dans le réseau de périmètre et les serveurs principaux exécutant SQL Server résident dans le réseau interne. Les rôles restants, tels qu'index, recherche et administration centrale, peuvent être une ou l'autre réseau.

Figure 4 Dans une topologie DOS à DOS “ fractionner respectez, rôles de serveur peuvent être définies dans la zone DMZ ou dans le réseau interne.

Placez le serveur de recherche sur le réseau interne pour la recherche optimal et performances d'analyse. Vous pouvez dédier le serveur de recherche à l'analyse. Gardez à l'esprit que la topologie DOS à DOS fractionnement requiert une approbation unidirectionnelle entre le périmètre et internes et les environnements Active Directory pour prendre en charge la communication.

Ressources

Site Web produits et technologies SharePoint

Windows SharePoint Services TechCenter

Centre de développement Windows SharePoint Services

Blog d'équipe produits et technologies SharePoint Microsoft

Authentification

Pour déterminer la configuration d'authentification pour sécuriser les communications externes peut rapidement devenir écrasante, en raison des options disponibles et les niveaux de topologie auxquelles l'authentification et d'autorisation ont lieu.

Par exemple, votre environnement peut prendre en charge de RSA SecureID, incorporer NPS (Network Policy Server) ou utiliser un répertoire personnalisé basé sur le protocole LDAP. Au final, les aspects pertinents de l'authentification de sécurisation des communications externes SharePoint incluent l'authentification des utilisateurs internes et externes et l'authentification IIS pour les sites SharePoint.

Nous allons simplifier ces aspects davantage en traçant le chemin de communication des demandes des utilisateurs externes à des sites SharePoint pour voir comment l'authentification et l'autorisation se produisent.

1. Un utilisateur externe effectue une demande est acheminée vers le pare-feu. Si le pare-feu une ISA serveur est configuré pour utiliser l'authentification basée sur les formulaires (FBA), l'utilisateur est présenté avec un formulaire d'ouverture de session et authentification. La demande est ensuite envoyée à un serveur frontal.
2. IIS sur le serveur frontal accepte la demande ;Détermine le site associé avec l'URL ;vérifie la configuration de l'authentification pour le site ;authentifie le trafic ;et le passe à SharePoint pour l'autorisation.
3. SharePoint exécute l'autorisation. Autorisations de site SharePoint et d'autorisation sont en dehors de la portée de cet article, car TLS est configuré pour chaque site au niveau de IIS. Pour plus d'informations sur l'autorisation SharePoint et l'authentification, consultez plan authentification méthodes (Office SharePoint Server).

Site configuration pour prendre en charge TLS

SharePoint s'appuie fortement sur IIS sous-jacent topologie et configuration de l'authentification pour fournir la fonctionnalité nécessaire pour prendre en charge le protocole TLS. Au moment où le trafic est routé vers SharePoint, il a déjà transmis via le pare-feu et été gérés par IIS. Configuration des sites SharePoint pour prendre en charge le protocole TLS est plus une tâche d'informer SharePoint de l'environnement sous-jacent pour chaque site que directement spécifiant les certificats SSL, création compte de service et ainsi de suite. Cependant, il est important à prendre en compte deux détails spécifiques à SharePoint lors du déploiement TLS : zones et de mappage de Access substitution (AAM). Les deux sont configurés dans le site Administration centrale sous Gestion des applications.

Lorsque vous créez ou étendre une application Web, vous pouvez spécifier des zones et entrer plus d'informations sur l'environnement SharePoint utilise pour créer un ensemble initial de AAMs (voir la figure 5). Les considérations clées d'un point de vue de la sécurité sont le fournisseur d'authentification et si le serveur ISA utilise TLS pour communiquer avec le serveur frontal, ou s'arrête les demandes HTTPS provenant des utilisateurs externes au niveau du pare-feu communique via HTTP.

Figure 5 SSL et les autres options de guration configuré pour un site SharePoint.

Bien que l'utilisation de TLS pour les communications depuis ISA Server aux serveurs frontaux crée plu de surcharge, de traitement il fournit une solution cryptée de bout en bout pour et ma méthode préférée. Arrêt TLS sur le serveur ISA peut interrompre également certains scénarios d'utilisation, comme à l'aide de composants WebPart personnalisés qui stockent les URL dans une base de données SQL Server. Le processus est similaire pour enabeing un site existant pour TLS. Vous devez activez la case utiliser SSL (Secure Sockets Layer), configurez les autres options et puis naviguer vers les paramètres AAM et vérifier qu'ils sont configurés correctement.

Configuration de zone et AAM interdépendants. SharePoint utilise le concept de zones pour permettre la logiques distinctions entre les parties de votre topologie, comme Internet, extranet, intranet et les URL disponibles pour les parties. Les définitions de AAM spécifient comment l'en-tête URL lorsque doit ressembler aux utilisateurs de différentes zones l'URL est différente de celle interne. Si votre URL interne est identique à une URL publique qui utilise un nom de domaine pleinement qualifié (FQDN), vous ne devez pas configurer AAM ;SharePoint qui effectue automatiquement. Pour d'autres scénarios, configurez AAMs pour vos sites SharePoint. Troy Starr validé une présentation complète des AAMs pour SharePoint sur le blog de SharePoint, vous trouverez à que chaque administrateur SharePoint doit connaître à propos de mappages des accès de substitution (partie 1 sur 3). Il convient également un coup de œil ;Une mauvaise configuration AAM est une des causes plus répandus de problèmes scénario d'extranet.

Configuration de IIS pour les certificats SSL

Comme nous l'avons mentionné, l'activation de SSL pour un site SharePoint s'effectue au niveau de IIS. Dans IIS 7.0, les certificats SSL sont configurés par l'intermédiaire de certificats de serveur. Ils se trouvent dans la page Propriétés du serveur IIS. Microsoft a déjà publié instructions, considérations et des scénarios d'utilisation à retenir lors de l'activation de sites IIS pour utiliser SSL ;n'oubliez pas qu'Autorité de certification et IP adresse/port liaison sont particulièrement pertinents pour la sécurisation des sites Internet accessibles. Il existe plusieurs options pour la génération d'un certificat SSL. Vous pouvez utiliser selfssl.exe, déployer une PKI avec une autorité de Certification Windows confiance (CA) ou utiliser un fournisseur commercial. Pour les environnements de laboratoire et à des fins de développement, un certificat auto-signé fonctionne bien, mais vous pouvez rencontrer des problèmes des utilisateurs pour les environnements de production. À moins que les utilisateurs acceptent le certificat dans leurs navigateurs, ils seront invités pour accéder à un site SSL activé, le certificat provenant d'une source non fiable. Cela peut entraîner pour prendre en charge appels et la confusion, facilitant ainsi la déployer un certificat de production d'une autorité de certification racine.

Il est possible d'utiliser la même adresse IP ou le même port pour plusieurs sites SSL activé. La simple consiste à utiliser une adresse IP fixe et le même port pour chaque site, afin de IIS peut relier le site à l'adresse IP et port. Sinon, si votre configuration utilise un domaine racine et plusieurs sous-sites Web, vous pouvez utiliser un certificat générique ou avec plusieurs noms de remplacement de site (SAN). Le processus est essentiellement la même que pour un certificat régulière, mais vous ne pouvez pas le configurer dans l'écran 7e IIS sous liens de site. Au lieu de cela, utilisez appcmd et exécutez la commande suivante pour lier SSL sur le site et définir l'en-tête ordinateur hôte : C:\Windows\System32\inetsrv\appcmd définir /site de site. nom : < CustomSiteName >/ + liaisons. [protocole = bindingInformation ' https' = ' *: 443 : < FQDN >]. Si fait correctement, vous verrez une liaison SSL avec l'en-tête d'ordinateur hôte spécifié sous liens de site.

Configuration de ISA Server

Indépendamment de si vous souhaitez sécuriser un site SharePoint nouveau ou existant avec TLS, vous devez vous assurer que le trafic peut traverser le pare-feu. ISA Server fournit plusieurs mécanismes qui fonctionnent avec SharePoint et permettent la traversée : FBA, HTTPS pontage, traduction de liens via proxy inverse et SharePoint règles de publication.

ISA Server utilise un Assistant permettant de publier des sites SharePoint. Cet Assistant crée un port d'écoute et une "Autoriser"règle pour activer le trafic de SharePoint. Avant d'exécuter l'Assistant, exporter le certificat SSL installé via IIS sur le serveur frontal qui héberge le site et importer vers ISA Server à l'aide du composant logiciel enfichable Certificats. Importer le certificat dans le magasin personnel de compte de l'ordinateur local. Cela permet à l'écouteur que vous créez dans ISA Server pour décrypter le trafic entrant, inspecter et crypter à nouveau. Pour plus d'informations sur la configuration d'ISA Server pour SharePoint, consultez authentification dans ISA Server 2006 et configurer ISA 2006 pour SharePoint 2007.

Au moment où vous configurer ISA Server pour publier vos sites SharePoint SSL activé, internes et les URL externes peut être résolus via DNS ;comptes d'utilisateurs et autorisations ont été configurées ;Zones de SharePoint et AAMs configurés ;et vous avez installé le certificat SSL pour le site par le biais de IIS. À ce stade, entrez les informations pertinentes dans ISA Server. Lorsque vous configurez le port d'écoute et la règle de publication, tenez compte des opérations suivantes :

• L'AAM : De mappage d'accès de substitution fonctionner correctement, vous devez configurer la règle de publication pour transmettre l'en-tête ordinateur hôte d'origine. En outre, assurez-vous de que spécifier les adresses FQDN appropriées pour les URL internes et externes.
• FBA : Vérifiez que vous sélectionnez authentification des formulaires HTML et de Windows (Active Directory) à partir de l'onglet authentification, sauf si vous utilisez Kerberos ou une solution de l'authentification personnalisée.
• Refuser l'accès pour les utilisateurs non authentifiés. Pour renforcer la sécurité, assurez-vous que vous ajoutez tous les utilisateurs authentifiés. Alternativelyr sélectionnez des utilisateurs spécifiques sous ensembles d'utilisateurs et assurez-vous que tous les utilisateurs est supprimé.

Simplifier votre douleur

Sécurisation de vos sites SharePoint à l'aide TLS peut être remplie de problèmes. Votre pare-feu peut ne pas correctement diriger le trafic comme un proxy inverse ou peut effectuer un travail de traduction de liens médiocre. La configuration de routage n'est pas configurée correctement dans les topologies plus complexes. Ou les configurations AAM et zone peuvent correspondent pas aux paramètres DNS ou de pare-feu. La bonne nouvelle est si vous approche sécurité externe avec une approche multi-couches, vous pouvez isoler les problèmes et résolvez-les. Vous pouvez faciliter votre vie même si vous utilisez ISA Server avec l'authentification FBA et Windows. Choisir la topologie appropriée, configurer le site dans SharePoint, activer SSL dans IIS, mettre ensemble avec ISA Server et que vous avez sécurisé les communications externes via TLS.

Pav Cherny est un expert informatique et auteur spécialisé dans les technologies Microsoft pour la collaboration et la communication unifiée. Ses publications incluent des livres blancs, des manuels de produits et des livres avec un intérêt particulier pour les opérations informatiques et l'administration système. Pav est le président de Biblioso Corporation, une entreprise spécialisée dans la documentation gérée et les services de localisation.