Au cœur de SharePoint Renforcement de sécurité de SharePoint

Pav Cherny

Contenu

Dépendances de sécurité dans un environnement SharePoint
L'activation de Network Access Protection
Établissement d'isolation de domaine
Isolation d'implémentation de serveur (et station de travail)
Conclusion

Renforcement de la sécurité SharePoint requiert une approche de bout en bout pour corrige la gamme complète des dépendances de sécurité et les risques au sein et entre les batteries de serveurs. En particulier, récentes innovations et technologies disponibles d'emblée avec Windows Server 2008, telles que NAP (Network Access Protection) avec protection de sécurité du protocole Internet (IPsec), peuvent aider à améliorer la sécurité de SharePoint. Encore plues les recommandations Microsoft pour SharePoint renforcement de la sécurité dans un environnement Windows Server 2008 sont difficiles à trouver. Le Centre de ressources Windows Server 2008 pour les produits et Technologies SharePointn'inclut pas un guide sur la sécurité. En outre, le renforcement de la sécurité guide pour Windows SharePoint Services (WSS) 3.0et Microsoft Office SharePoint Server (MOSS) 2007sont toujours basées sur Modèles et pratiques juin 2003 datées du et ont été que partiellement mis à jour en janvier 2006, qui est toujours long avant la version de Windows Server 2008 et de Services Internet (IIS) 7.0, dans tous les cas.

Clairement, instructions révisées sont extrêmement en retard et pas simplement parce que nous avons long depuis déplacés de Windows 2000, SQL Server 2000, IIS 5.0 et Microsoft .NET Framework 1.1, mais aussi parce que les vieilles méthodes de traitement avec renforcement de la sécurité se sont avérées insuffisantes temps et à nouveau. Il est simplement pas suffisamment sécuriser une batterie SharePoint comme une île serveur isolé, comme si batteries de serveurs SharePoint existent dans une aspiration. La réalité est que pas une seule étape security-hardening dans une batterie de serveurs SharePoint est importante si la forêt Active Directory est sécurisée, si l'environnement intranet infested avec les logiciels espions et rootkits ou si les utilisateurs par inadvertance ou par malveillance violent stratégies de sécurité, par exemple, télécharger et installer logiciel de partage de fichiers provenant de sources douteuses.

Il est possible de s'attaquer à ces problèmes en utilisant la technologie Windows Server 2008. Il est la clé d'atteindre un niveau élevé de sécurité dans un environnement SharePoint, de bout en bout, des ordinateurs clients vers les serveurs de base de données.

Dans cet article, j'aborde les aspects de sécurité de SharePoint dans un environnement intranet basé sur Windows Server 2008. Cette discussion implique l'analyse des dépendances de sécurité SharePoint au-delà des limites d'une batterie de serveurs individuel et puis déploiement NAP avec mise en œuvre IPsec avec des règles de sécurité et d'isolation correspondants pour atténuer les risques. Pour les administrateurs SharePoint, un avantage évident de NAP est qu'il peut arrêter ordinateurs client non managé d'accéder aux ressources de SharePoint et de téléchargement de documents. Un autre, peut-être moins évidente, avantage est que vous pouvez diviser votre intranet en des réseaux logiques distincts via l'isolation de domaine et serveur. De cette façon, vous pouvez protéger la communication client à serveur et serveur à serveur entrante et sortante et également limiter le trafic vers serveurs frontaux souhaités. En supposant que jusqu'à 30 % des sites SharePoint d'une société résident sur batteries département défectueux, mal sécurisés et hors du contrôle du service informatique, les avantages de limiter le trafic client ne peut pas être overemphasized. Comme toujours, les ressources associées incluent des feuilles de calcul avec des instructions étape par étape pour suivre mes explications dans un environnement de test.

Dépendances de sécurité dans un environnement SharePoint

Compte tenu de la complexité des solutions basées sur SharePoint, le volume élevé de données stockées dans des sites SharePoint et la sécurité souvent contradictoire et exigences de productivité dans une entreprise, il peut être difficile de déterminer comment et où mise en route de renforcement de la sécurité SharePoint. La première étape consiste peut-être à retirer la notion maintenu long que notre intranet est des environnements simplifiés, suffisamment protégés par le pare-feu de périmètre et détecteurs de virus. Pare-feu et les scanneurs ne pas empêcher un utilisateur malveillant d'attacher un keylogger matériel PS2 ou USB sur un ordinateur client, aucun pilote requis. Ils ne sont pas également conserver un rootkit zero-day de transformer vos ordinateurs mobiles en zombies pendant qu'ils sont connectés à un environnement mal sécurisé à la maison, dans certains hôtels ou les aéroports ou à sites clients. Il peut sembler exigeants mais classer votre environnement interne comme hostile permet en termes de reconnaissance des dépendances de sécurité critique dans et entre les batteries de serveurs SharePoint.

Nous allons voir les problèmes critiques nous peut découvrir dans un atelier de test simple, comme celui illustré dans la figure 1 et décrites dans la feuille de calcul Compagnon «Déploiement d'un environnement de Test SharePoint plusieurs batteries et un serveur NPS». Cet environnement SharePoint n'est pas sécurisé. En fait, ma feuille de calcul de déploiement ne respecte pas plusieurs méthodes conseillées en matière de sécurité et ignore les dépendances importants. Je généralement sortir avec, en supposant qu'il ne sont aucune exigence de sécurité dans laboratoires de test. Bien sûr, j'aurais pu effectué pire en installant SharePoint sur un contrôleur de domaine ou en accordant sécurité comptes autorisations d'administration, mais ces erreurs de configuration voulu ne sont pas nécessaires. Un point de vue sécurité, mon environnement de test est déjà suffisamment incorrect.

Figure 1 un environnement de test non sécurisés avec SharePoint plusieurs batteries

Pour commencer, j'utiliser le compte administrateur de domaine pour se connecter à tous les serveurs et stations de travail et installent tous les systèmes lorsqu'ils étaient connectés à Internet. Il est risqué. Il est préférable éviter d'ouvrir une session sur un ordinateur non sécurisé en utilisant un compte administrateur de domaine. De même, il est recommandé d'installer et d'ordinateurs dans un environnement de la zone de transit distinct et sécurisé prior to déploiement des correctifs. Kit d'installation automatisée (Windows AIK) et les services de déploiement Windows (WDS) offrent une bonne solution, mais vous n'avez pas tirer parti de ces technologies dans mon laboratoire de test pour des raisons de complexité. Étant donné que j'ai pris raccourcis, mon environnement Active Directory peut déjà compromis et il tout mon batteries de serveurs SharePoint. La partie est terminée avant elle même ! Une batterie SharePoint ne peut jamais être plus sécurisée que son environnement Active Directory.

Les comptes administrateur de domaine sont des comptes très sensibles en effet. Vous êtes également dans une zone sensible lorsque vous accédez aux ressources SharePoint, telles que le site Administration centrale de SharePoint 3.0 et les collections de sites SharePoint. Accéder à un site SharePoint implique en cours d'exécution de code ASP.NET sous l'identité de l'utilisateur en cours sur le serveur frontal. Si cet utilisateur en cours se trouve être un administrateur de domaine, le code s'exécute avec des privilèges d'administration. Vous devez refuser les administrateurs de domaine et serveur local Administrateurs accès aux applications SharePoint Web car il est possible d'exploiter leurs privilèges élevés, comme l'extraction des comptes de sécurité et les mots de passe, comme expliqué dans la colonne janvier 2009. Si un attaquant peut amener un administrateur de SharePoint à déployer un composant malveillant ou l'activation en ligne ASP.NET code, l'intrus peut également être en mesure de déterminer les mots de passe compte de sécurité et accéder ensuite à tous les sites dans toutes les batteries de serveurs qui utilisent ces comptes.

Dans mon atelier de test, j'ignoré ces dépendances de compte de sécurité et les risques d'administration, configuré la batterie de serveurs WSS et la batterie de serveurs RH avec les mêmes comptes de sécurité et si utilisé votre compte administrateur de domaine pour travailler avec administration centrale de SharePoint 3.0 dans les deux batteries de serveurs. Partage des comptes de sécurité entre les batteries de serveurs est une mauvaise idée, surtout s'ils ont en matière de sécurité différents. Une batterie de serveurs qui partage ses comptes dépend de la batterie de serveurs autre pour des raisons de sécurité et peut donc jamais atteindre un niveau de sécurité plus élevé que celui de la batterie de serveurs autre.

L'utilisation de comptes de sécurité distinct est une importante recommandée, mais une batterie de serveurs compromis peut toujours fournir une voie contre les attaques sur d'autres batteries dans le même environnement Active Directory. Par exemple, il n'est pas tirer efforts pour transformer un serveur SharePoint compromis en une plate-forme de phishing interne. Un attaquant peut activer l'authentification de base ou obtenir un composant malveillant dans une batterie SharePoint établie qui envoie un en-tête «WWW-Authenticate» pour les utilisateurs et intercepte les retourné informations d'identification en texte brut, comme illustré figure 2 . Étant donné que les utilisateurs de confiance leurs sites SharePoint internes, il est probable qu'ils passera dans les informations d'identification demandées sans hésitation — et l'attaque réussisse.

La figure 2 une batterie compromis permettent attaques sur les autres batteries de serveurs.

Bien sûr, il est difficile de compromettre un serveur SharePoint correctement géré, mais qui n'est pas le point. Le point empêche violations de sécurité sur les systèmes qui ne sont pas correctement mises à jour de la diffusion de systèmes sensibles de sécurité de niveau supérieur. Par conséquent, au moins pour les ressources SharePoint plus sensibles, comme une batterie de serveurs RH avec les informations d'identification personnelle, vous devez considérer ces dépendances accès, qui impliquent en fait qu'une batterie SharePoint peut uniquement être aussi sécurisée que les sites moins sécurisés auxquels les administrateurs de batterie de serveurs, administrateurs de collection de site et les utilisateurs du site peuvent accéder avec leurs comptes d'utilisateur.

N'oubliez pas inclure les ordinateurs clients dans votre analyse des accès et l'utilisation de dépendances. Là encore, mon environnement de test définit un exemple de mauvais car n'importe quel utilisateur peut utiliser n'importe quelle station de travail pour accéder à n'importe quelle ressource, et les ordinateurs ne sont pas équipés d'un logiciel antivirus ou les derniers correctifs de sécurité. Imaginez un utilisateur disposant des droits d'un administrateur de batterie de serveurs ou collection de sites ouvrent une session localement sur un ordinateur client infested les logiciels espions ou à un ordinateur de bureau déverrouillé, où un attaquant peut associer facilement un keylogger matériel. Batteries et collections de sites sont compromises dès que l'intrus accède à un compte administrateur et un mot de passe sur n'importe quel ordinateur dans n'importe quel emplacement. Logiciels de partage de fichiers sur des ordinateurs client présente également les risques de sécurité, comme les ordinateurs clients ont tendance à stocker le contenu des sites SharePoint localement, manuellement ou automatiquement téléchargeant qu'informations dans les fichiers temporaires. Par conséquent, une batterie SharePoint ne peut jamais être plus sécurisée que les ordinateurs client que les utilisateurs utilisent pour accéder aux ressources de la batterie.

Bien sûr, il existe plus faiblesses dans mon environnement de test. Je vous inviter à étudier les sections appropriées dans les guides de renforcement de la sécurité de SharePoint et continuer cette révision sur votre propre. Vous devez reconnaître au moins quelques autres problèmes, notamment que les sites de Administration centrale de SharePoint 3.0 et les rôles de recherche sont hébergés directement sur les serveurs frontaux contenu du site, qu'il n'existe aucune solution antivirue sur les serveurs de service, que la batterie de serveurs WSS et la batterie de serveurs RH partagent un serveur de base de données courante et non protégé, que tous les ordinateurs dans l'environnement de test ont accès au directe au serveur de base de données et que la communication réseau a lieu en texte brut. Aucun des cela est souhaitable, par conséquent, nous allons aborder certains de ces problèmes de sécurité.

L'activation de Network Access Protection

Il existe de nombreuses étapes à que suivre pour renforcer la sécurité dans un environnement SharePoint, telles que le contrôle d'accès physique aux ordinateurs et le réseau, configuration vLANs et le contrôle d'accès listes (ACL) sur les routeurs et les serveurs infrastructure sécurisation (DNS serveurs, DHCP serveurs, contrôleurs de domaine et ainsi de suite) via le déploiement de Microsoft Forefront Security for SharePoint et Active Directory Rights Management Services (AD RMS). Contrôles d'accès physique et configurations de réseau et de routeur base TCP/IP sortent du cadre de cette colonne et AD RMS a été traité dans les colonnes précédentes, afin que nous laisse avec NAP, IPsec, HTTP sur SSL (Secure Sockets Layer) et Forefront Security comme les sections logiques. Cet article se concentre sur NAP et IPsec. HTTP sur SSL et Forefront Security sera résolu dans les colonnes ultérieures.

NAP avec IPsec offre au moins trois avantages clés pour un environnement interne SharePoint :

• Vous pouvez appliquer des stratégies d'état système et résoudre automatiquement les problèmes de conformité sur les ordinateurs client exécutant Windows XP Service Pack 3 et Windows Vista ;
• Vous pouvez implémenter une couche supplémentaire de réseau de la sécurité IPsec et pare-feu Windows dans une forêt Active Directory ;
• Vous pouvez établir des canaux de communication crypté par ESP (Encapsulating Security Payload) dans une batterie SharePoint et entre des ordinateurs clients et serveurs.

Une prime est la capacité à gérer la communication réseau centralisée via la stratégie de groupe et d'auditer l'accès réseau. En bref, NAP avec IPsec est un activateur important d'une stratégie efficace sécurité de bout à bout pour SharePoint.

Au cœur, NAP avec IPsec s'appuie sur un mécanisme de distribution intelligente de certificats X.509. Sur l'ordinateur client, les agents d'intégrité système (SHA) informent l'agent NAP sur leur état de conformité dans les documents instruction d'intégrité (SoH), qui regroupe l'agent NAP dans un état de système d'intégrité (SSoH). Il transmet le SSoH au client de contrainte IPsec NAP (NAP EC) sur l'ordinateur client, qui à son tour transmet le SSoH au serveur de mise en œuvre NAP (NAP ES). C'est l'état enregistrement autorité HRA () qui obtient des certificats de santé du système à partir d'une autorité de certification (CA) pour les ordinateurs compatibles. la figure 3 illustre comment un client NAP obtient un certificat d'intégrité.

La figure 3 communication client/serveur NAP aux informations de fonctionnement de Exchange et certificats

Pour déterminer que l'ordinateur demandeur est conforme, NAP ES transmet la SSoH un message RADIUS pour NPS (Network Policy Server). Le serveur NPS transmet à nouveau le SSoH au serveur d'administration NAP, qui à son tour extrait SoHs individuels à partir de la SSoH et les transfère vers le validateurs d'intégrité système correspondant (validateurs d'intégrité du système). Validateurs d'intégrité du système d'analyser les informations SoH et renvoient une réponse de relevé d'état (SoHR), le serveur NPS consolide une réponse de système instruction de fonctionnement (SSoHR) le système NAP transmet ensuite au SHA sur l'ordinateur client. Et SoH SoHRs, validateurs d'intégrité du système de communiquer avec leurs homologues SHA correspondants. Par exemple, SoHR à partir d'un antivirus SHV peut demander à l'antivirus SHA correspondant pour télécharger la dernière version du fichier de signature à partir un serveur de protection pour ramener l'ordinateur client en conformité.

Sur le côté serveur, NAP également compare SoHRs les stratégies de réseau et l'état configuré et émet un certificat du fonctionnement du système si l'ordinateur client est compatible. Le client NAP reçoit le certificat à partir de NAP ES et la stocke dans son magasin de certificat de l'ordinateur. Le certificat est désormais disponible pour la négociation IKE (Internet Key Exchange) établir des associations de sécurité IPsec avec des partenaires de communication fiable. Le client NAP renouvelle le certificat de santé du système chaque fois qu'il doit expirer ou lorsqu'un SHA indique une modification état de fonctionnement de l'agent NAP. La ligne du bas est que compatible avec les ordinateurs reçoivent un certificat d'intégrité et n'est pas ordinateurs non conformes. Pour plus d'informations techniques approfondies, je recommande fortement le livre blanc" Architecture réseau Access Protection Platform." La feuille de calcul Compagnon «Configuration de Network Access Protection» décrit les étapes pour déployer une infrastructure NAP base dans un laboratoire de test.

Établissement d'isolation de domaine

Même dans mon atelier de test peu humble rôles NPS et HRA sur un seul serveur, vous pouvez immédiatement Notez les avantages de la protection NAP. Dès que vous activez NAP sur les ordinateurs clients par le biais des paramètres de stratégie de groupe, NAP fortement encourage à installer les derniers correctifs de sécurité et un détecteur de virus. Le client NAP vous informe sur les composants de sécurité manquants et l'état du réseau inclut une notification vous informant qu'accès réseau est limité jusqu'à ce que l'ordinateur réponde aux exigences. À ce stade, toutefois, ordinateurs non conformes ont toujours accès à tous les serveurs du réseau, car nous n'avez pas encore configuré les stratégies IPSec. Sans des stratégies de demandent ou exiger l'authentification pour les connexions entrantes et sortantes, l'infrastructure NAP est vraiment beaucoup plus qu'un mécanisme de distribution de certificat d'intégrité. Nous devons implémenter l'isolation de domaine pour NAP être efficace.

Isolation de domaine implémentation signifie diviser le réseau interne en segments de restreint, limite et sécuriser les réseaux via des stratégies de mise en œuvre IPsec. L'objectif est d'empêcher des ordinateurs non conformes d'accéder à des serveurs du réseau interne, à l'exception de ces serveurs les ordinateurs non conformes doivent être en mesure d'accéder pour devenir compatibles et obtenir un certificat d'intégrité. Dans la figure 4 , cela concerne le serveur NAP NPS01. La différence entre les segments de limite et la sécurisée est que la stratégie IPsec pour le segment de limite de demande l'authentification des connexions entrantes et sortantes et permet donc de secours pour la communication en texte clair avec les ordinateurs non conformes, tandis que le segment sécurisé requiert l'authentification des connexions entrantes, ce qui interdit de secours en texte brut et empêche les ordinateurs non conformes. Vous pouvez utiliser la feuille de calcul Compagnon «Configuration de stratégies IPsec pour état application» pour implémenter cette segmentation.

La figure 4 restreint, limite et les réseaux sécurisés pour NAPNAP

Le contrôleur de domaine dans la figure 4 est un cas spécial. Vous pouvez demander ou nécessite une communication protégée par IPsec entre des membres et contrôleurs de domaine si vos ordinateurs exécutent Windows Vista ou Windows Server 2008 (voir la feuille de calcul Compagnon «Configuration de la IPSec pour communications de contrôleur de domaine»), mais cette configuration n'est pas prise en charge pour Windows Server 2003 et Windows XP. Si vous décidez de ne pas utiliser IPsec pour la communication contrôleur de domaine, DC01 fait partie de réseau restreint ; demander Qu'ipsec déplace le contrôleur de domaine dans le segment de bordure et nécessitant Qu'ipsec rend le contrôleur de domaine un membre du segment sécurisé. La configuration dépend de votre situation spécifique et les besoins. Si possible, je recommande l'utilisation d'IPsec.

Isolation d'implémentation de serveur (et station de travail)

Établissement de NAP avec isolation de domaine et de mise en œuvre IPsec joue le premier jalon important vers renforcement de la sécurité. Tous les ordinateurs clients doivent désormais satisfaire les exigences raisonnable avant de pouvoir accéder aux ressources SharePoint internes. Ensuite, vous pouvez vous concentrer sur segmentation de l'environnement SharePoint dans plusieurs niveaux pour atteindre un niveau précis de contrôle de communications bout en bout, y compris la communication des ordinateurs clients. la figure 5 illustre une stratégie de segmentation possibles en fonction du rôle de chaque ordinateur individuel sur le réseau interne.

La figure 5 un environnement de test améliorée avec plusieurs fermes SharePoint

Comme vous pouvez constater dans la figure 5 , mon environnement de test inclut désormais des systèmes supplémentaires. Entre autres choses, je modifié la configuration de fermes WSS et RH spécifié des comptes de sécurité distinct, de déplacer la configuration de RH et les bases de données de contenu sur un serveur SQL distinct et déployé des ordinateurs distincts pour administration centrale de SharePoint 3.0 et le rôle de recherche SharePoint dans les deux batteries de serveurs. Découvrez les feuilles de calcul différentes contenues dans le matériel associé, qui montrent comment effectuer ces étapes.

Sécuriser la communication entre les niveaux est maintenant un processus simple, grâce à notre NAP avec IPsec Préparation du travail. À l'aide de la stratégie de groupe, vous pouvez gérer toutes les règles de pare-feu Windows avec sécurité avancée pour verrouiller les communications entrantes et sortantes sur les clients et serveurs pour les niveaux plus restrictives de façon centralisée. Je recommande la désactivation de la règle de la fusion dans Stratégie de groupe pour empêcher l'application pare-feu en conflit des administrateurs locaux et règles de sécurité de connexion sur n'importe quel membre du domaine. Par exemple, vous pouvez verrouiller UDP et TCP port 1434 sur les serveurs de base de données, ouvrir un port TCP personnalisé pour l'instance de SQL Server par défaut, crypter le trafic, ouvrir uniquement les ports TCP vos applications Web utilisent sur les serveurs frontaux et bloquer tous les ordinateurs non-HR d'accéder à n'importe quel serveur ou à un ordinateur client de ce service.

Références

	Site Web de protection d'accès réseau go.Microsoft.com/fwlink/?LinkId=69752
	Site Web de technologies et produits SharePoint Microsoft.com/SharePoint
	Windows SharePoint Services TechCenter TechNet.Microsoft.com/windowsserver/SharePoint
	Windows SharePoint Services Developer Center msdn2.Microsoft.com/SharePoint
	Blog de l'équipe technologies et produits Microsoft SharePoint blogs.msdn.com/SharePoint

Une question intéressante est si vous devez également bloquer des ordinateurs sensibles d'accéder aux ordinateurs nonsensitive — par exemple, vous gardez RH clients d'accéder aux serveurs SharePoint non-HR dans la batterie de serveurs WSS. Voici un exemple où exigences de sécurité et productivité entrent en conflit. Pour des raisons de productivité, je pense qu'il est impossible de refuser les accès aux sites de SharePoint à l'échelle de l'entreprise tels que des sites dans ma batterie de serveurs WSS, ce qui implique que la batterie de serveurs WSS doit respecter les normes de sécurité même que la batterie de serveurs RH personnes RH. Par conséquent, dans les deux batteries, j'ai dû déplacer les sites d'administration centrale de SharePoint 3.0 et recherche les rôles à un ordinateur distinct et appliquer des règles de sécurité de pare-feu et de connexion. Bien sûr, vous aussi désigner certains comptes dédiés, sans privilège d'administration de SharePoint dans les deux batteries de serveurs et appliquer d'autres étapes de renforcement de la sécurité. Joel Oleson a publié un excellent récapitulatif des procédures de renforcement de la sécurité à son Blog SharePoint Land. Je recommande fortement les conseils de Joel suivant dans une infrastructure IPsec activé qui fournit une fondation solide de renforcement de sécurité de bout en bout pour SharePoint.

Conclusion

Batteries de serveurs SharePoint n'existent pas dans une aspiration. Elles existent dans un environnement qui comprend des ordinateurs clients, serveurs d'infrastructure et équipement réseau. Cela signifie que vous devez participer à ces composants si vous souhaitez obtenir une meilleure sécurité via SharePoint sécurisation-renforcement. Il est impossible de sécuriser une batterie SharePoint dans un environnement Active Directory sécurisée. Il est impossible de sécuriser une batterie SharePoint si les ordinateurs clients sont infested avec les logiciels espions. Il est impossible de sécuriser une batterie SharePoint si un attaquant peut highjack comptes d'utilisateurs, les comptes administrateur ou les comptes de sécurité n'importe où.

Technologie de Windows Server 2008 fournit la base effectuer un cast de sécurité large nette sur une forêt Active Directory à Network Access Protection avec mise en œuvre protocole IPSec, pare-feu Windows avec sécurité avancée et gestion des stratégies de groupe. Tirant parti de ces technologies dans un environnement SharePoint vaut sans aucun doute l'effort. Vous pouvez contrôler et sécuriser la communication entre les stations de travail, serveurs et contrôleurs de domaine, vous pouvez appliquer des normes d'état système ; vous pouvez implémenter d'isolation de domaine ; et vous pouvez appliquer des niveaux séparés dans l'environnement SharePoint interne. Par appartenance à des groupes de sécurité ou unités d'organisation, Active Directory détermine automatiquement les paramètres de stratégie qui s'appliquent à chaque membre du domaine, y compris les ordinateurs clients, serveurs de base de données, serveurs frontaux et serveurs de couche intermédiaire pour administration et autres fins. Vous pouvez établir les stratégies générales pour chaque niveau et les stratégies spécifiques pour chaque rôle de serveur et de type ordinateur. Vous pouvez empêcher les utilisateurs d'hébergement SharePoint sur les ordinateurs clients en bloquant toutes les connexions entrantes, et vous pouvez empêcher les services d'hébergement non approuvés et non sécurisés batteries de SharePoint peuvent fournir des moyens pour les attaques sur d'autres batteries dans le réseau interne.

Mais ne pas aller overboard avec des restrictions. Tenez compte de nombreux processus de gestion Services reposent sur des déploiements SharePoint en dehors du Centre de données. Après tout, SharePoint est une plate-forme de collaboration stratégiques de l'entreprise.

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 les livres blancs, manuels du produit et livres en se concentrant sur les opérations informatiques et l'administration système. Pav est le président de Biblioso Corporation, une entreprise spécialisée dans services de documentation et de localisation gérés.