SharePoint od środka: Wzmacnianie zabezpieczeń SharePoint

Autor: Pav Cherny

Opublikowano: 18 listopada 2009

Zawartość strony

	Uwarunkowania zabezpieczeń w środowisku SharePoint
	Włączanie Network Access Protection
	Ustanawianie izolacji domeny
	Implementowanie izolacji serwera (i stacji roboczej)
	Podsumowanie
	Odnośniki

Wzmocnienie zabezpieczeń SharePoint wymaga podejścia całościowego, będącego w stanie objąć pełne spektrum uwarunkowań bezpieczeństwa i zagrożeń, które mogą wystąpić wewnątrz i pomiędzy farmami serwerów. W szczególności najnowsze innowacje i rozwiązania dostępne standardowo w systemie Windows Server 2008, takie jak Network Access Protection (NAP) z wymuszaniem Internet Protocol Security (IPsec), mogą pomóc w zwiększeniu zabezpieczeń SharePoint. Tym niemniej, jak dotąd trudno jest znaleźć szczegółowe zalecenia firmy Microsoft na temat poprawy zabezpieczeń SharePoint w środowisku Windows Server 2008. Witryna Windows Server 2008 Resource Center for SharePoint Products and Technologies nie zawiera poradnika zabezpieczeń. Dodatkowo poradniki wzmacniania zabezpieczeń dla Windows SharePoint Services (WSS) 3.0 oraz Microsoft Office SharePoint Server (MOSS) 2007 nadal opierają się na wzorach i praktykach datowanych na czerwiec 2003 i zostały jedynie częściowo uaktualnione w styczniu 2006 – w każdym przypadku dość długo przed datą opublikowania Windows Server 2008 oraz Internet Information Services (IIS) 7.0.

Oczywiste jest, iż zrewidowane wskazówki są pilnie potrzebne i nie tylko z tego powodu, że przeszliśmy długą drogę od czasów Windows 2000, SQL Server 2000, IIS 5.0 i Microsoft .NET Framework 1.1, ale również dlatego, że stare metody radzenia sobie z zabezpieczeniami są już niewystarczające. Nie wystarczy już po prostu zabezpieczenie farmy SharePoint jako izolowanej wyspy, jakby egzystowała ona w próżni. Praktyka pokazuje, że nie istnieje pojedynczy sposób wzmocnienia zabezpieczeń farmy SharePoint – jej bezpieczeństwo jest zagrożone, jeśli las Active Directory nie jest zabezpieczony, gdy środowisko intranetowe zostanie zainfekowane przez programy szpiegowskie lub rootkity albo gdy użytkownicy niechcący lub z premedytacją złamią zasady zabezpieczeń, na przykład pobierając i instalując jakieś oprogramowanie z podejrzanych źródeł.

Problemy takie można wyeliminować, używając technik udostępnianych przez system Windows Server 2008. Jest to klucz do osiągnięcia wysokiego poziomu zabezpieczeń środowiska SharePoint w całej rozciągłości, od komputerów klienckich zaczynając, a na serwerach baz danych kończąc.

W tym artykule przedstawiam aspekty zabezpieczeń SharePoint w środowisku intranetu opartego na Windows Server 2008. Rozważać będę ogólne uwarunkowania zabezpieczeń SharePoint wykraczające poza granicę indywidualnej farmy i wdrożenie NAP z wymuszaniem IPsec oraz towarzyszącymi regułami zabezpieczeń i izolacji w celu ograniczenia ryzyka. Dla administratorów SharePoint oczywistą korzyścią ze stosowania NAP jest możliwość zablokowania dostępu do zasobów SharePoint przez niezarządzane komputery klienckie. Inną być może mniej rzucającą się w oczy korzyścią jest możliwość podzielenia intranetu na oddzielne sieci logiczne poprzez izolację domeny i serwera. W ten sposób można ochronić zarówno przychodzącą, jak i wychodzącą łączność pomiędzy klientem a serwerem, a także ograniczyć ruch do właściwych serwerów frontowych. Przy założeniu, że do 30 procent firmowych witryn SharePoint zlokalizowanych jest na niedostatecznie zabezpieczonych, źle zorganizowanych serwerach oddziałowych, często całkowicie poza bezpośrednią kontrolą działów IT, korzyści z ograniczenia ruchu klienckiego nie można przecenić.

Uwarunkowania zabezpieczeń w środowisku SharePoint

Przy rozważaniu złożoności rozwiązań opartych na SharePoint, ogólnej wielkości danych przechowywanych na tych witrynach oraz częstej sprzeczności pomiędzy wymaganiami zabezpieczeń a potrzebą produktywności, ustalenie, jak i gdzie należy rozpocząć działania w celu wzmocnienia zabezpieczeń może być bardzo trudne. Być może pierwszą rzeczą, z którą będzie trzeba się ostatecznie rozstać, jest długo utrzymywane przekonanie, że nasze intranety są środowiskiem przyjaznym, dostatecznie chronionym przez zapory brzegowe i skanery antywirusowe. Zapory ani skanery nie powstrzymają podstępnego użytkownika przed podłączeniem sprzętowego rejestratora klawiatury (ze złączem PS2 lub USB) do któregoś z komputerów – żadne sterowniki nie są potrzebne. Nie zdołają również zablokować rootkita wykorzystującego nieznaną jeszcze lukę (tzw. zagrożenie zero-day) przed przekształceniem komputerów przenośnych w zombie, gdy zostaną podłączone do niezabezpieczonej sieci w domu, hotelu czy na lotnisku. Może to zabrzmieć niemiło, ale skategoryzowanie wewnętrznego środowiska jako nieprzyjaznego może pomóc w rozpoznawaniu krytycznych uwarunkowań zabezpieczeń – zarówno wewnątrz, jak i wokół farm serwerów SharePoint.

Przyjrzyjmy się, jakie krytyczne problemy możemy znaleźć w stosunkowo prostym laboratorium testowym, przedstawionym na Rysunku 1. To środowisko SharePoint nie jest bezpieczne. W istocie moje arkusze wdrożenia łamią liczne, najlepsze praktyki zabezpieczeń i ignorują ważne uwarunkowania. Zazwyczaj nie przejmuję się tym, zakładając, że w laboratorium testowym nie ma wymagań bezpieczeństwa. Oczywiście: moglibyśmy zrobić coś jeszcze gorszego, na przykład instalując SharePoint na kontrolerze domeny albo przyznając uprawnienia administracyjne kontom zabezpieczeń, ale nie musimy popełniać intencjonalnych błędów: z punktu widzenia zabezpieczeń moje środowisko testowe jest już wystarczająco złe.

Rysunek 1: Niezabezpieczone środowisko testowe z wieloma farmami SharePoint.

Parę wyjaśnień dla nowicjuszy: używam konta administratora domeny do logowania się na wszystkich serwerach i stacjach roboczych i instalowania wszystkich systemów, podczas gdy były one połączone z Internetem. To ryzykowne. Należy unikać logowania się na niezabezpieczonych komputerach przy użyciu konta administratora domeny. Analogicznie – najlepsze praktyki nakazują instalowanie i aktualizowanie komputerów w odrębnym, zabezpieczonym środowisku pośrednim przed ich wdrożeniem. Narzędzia Windows Automated Installation Kit (AIK) oraz Windows Deployment Services (WDS) oferują dobre rozwiązania, choć nie korzystałem z nich w moim laboratorium testowym ze względu na ich złożoność. Ponieważ wybrałem drogę na skróty, moje środowisko Active Directory już mogło zostać skompromitowane – a razem z nim moje wszystkie farmy SharePoint. Mecz zakończył się jeszcze przed rozpoczęciem! Farma SharePoint nigdy nie będzie mogła być bezpieczniejsza niż jej środowisko Active Directory.

Konta administratorów domeny są naprawdę bardzo wrażliwymi bytami. Na grząski teren wkraczamy również, uzyskując dostęp do takich zasobów SharePoint jak witryna SharePoint 3.0 Central Administration oraz zbiory witryn SharePoint. Dostęp do witryny SharePoint pociąga za sobą uruchomienie kodu ASP.NET przy użyciu tożsamości bieżącego użytkownika na serwerze frontowym. Jeśli użytkownik ten przypadkiem jest administratorem domeny, kod zostanie wykonany z przywilejami administracyjnymi. Z tego względu należałoby zabronić administratorom – tak domeny, jak i lokalnym – dostępu do aplikacji Web SharePoint, gdyż sprawia to możliwość nadużycia ich podniesionych uprawnień, na przykład poprzez wydobycie kont zabezpieczeń i ich haseł, co opisałem w artykule ze stycznia 2009. Jeżeli napastnik zdoła skłonić administratora SharePoint do rozpowszechnienia złośliwego komponentu albo umożliwienia działania wstawek kodu ASP.NET, będzie również w stanie ustalić hasła kont zabezpieczeń i w konsekwencji uzyskać dostęp do wszystkich witryn we wszystkich farmach, które używają tych kont.

W mojej sieci testowej zignorowałem te uwarunkowania i zagrożenia, konfigurując farmę WSS oraz farmę HR przy użyciu tych samych kont zabezpieczeń i używając konta administratora domeny do konfigurowania witryny SharePoint 3.0 Central Administration w obu farmach. Współużytkowanie kont zabezpieczeń pomiędzy farmami jest niedobrym pomysłem, szczególnie w przypadku, gdy mają one inne wymagania bezpieczeństwa. Farmy, które korzystają ze wspólnych kont, zależne są od siebie nawzajem pod względem bezpieczeństwa – nigdy więc nie będzie można uzyskać w żadnej lepszego poziomu zabezpieczeń niż w pozostałych.

Korzystanie z oddzielnych kont zabezpieczeń jest bardzo ważnym zaleceniem, jednak skompromitowana farma nadal może udostępnić drogę ataku na inne farmy zlokalizowane w tym samym środowisku Active Directory. Na przykład przekształcenie skompromitowanego serwera SharePoint w wewnętrzną platformę phishingu nie wymaga wiele wysiłku. Napastnik może włączyć uwierzytelnianie Basic albo wprowadzić złośliwy komponent do działającej farmy SharePoint, który będzie wysyłał nagłówek „WWW-Authenticate” do użytkowników i będzie przechwytywał zwracane poświadczenia jako czysty tekst, co ilustruje Rysunek 2. Ponieważ użytkownicy ufają wewnętrznym witrynom SharePoint, najprawdopodobniej bez wahania wpiszą żądane poświadczenia – i atak się powiedzie.

Rysunek 2: Skompromitowana farma SharePoint może umożliwić atak na inne farmy.

Oczywiście skompromitowanie właściwie utrzymywanego serwera SharePoint jest trudne, ale nie tym się powinniśmy zajmować. Właściwym podejściem jest uniemożliwienie rozpowszechnienia się włamania do systemu, który nie był właściwie utrzymywany, na inne, wrażliwe systemy z wyższymi wymaganiami zabezpieczeń. Z tego względu przynajmniej dla najbardziej wrażliwych zasobów SharePoint, takich jak farma działu kadr (HR w przykładach powyżej) zawierająca informacje personalne, trzeba rozważyć te zależności. Wynika z nich, mówiąc w uproszczeniu, że SharePoint może być tylko tak bezpieczna, jak najmniej bezpieczne witryny, do których uzyskują dostęp jej administratorzy, administratorzy zbiorów witryn oraz użytkownicy, używając swoich kont.

W analizie uwarunkowań dostępu i wykorzystania nie wolno pominąć komputerów klienckich. Ponownie moje środowisko testowe jest złym przykładem, gdyż każdy użytkownik może skorzystać z dowolnej stacji roboczej w celu uzyskania dostępu do dowolnego zasobu, zaś komputery nie zostały wyposażone w skanery antywirusowe ani ostatnie poprawki zabezpieczeń. Możemy sobie więc wyobrazić, że użytkownik dysponujący uprawnieniami administratora farmy lub zbioru witryn loguje się lokalnie na komputerze zarażonym oprogramowaniem szpiegowskim albo na maszynie w ogólnie dostępnym biurze, w którym napastnik mógł bez trudu dołączyć sprzętowy rejestrator klawiatury. Farmy i zbiory witryn zostaną skompromitowane, gdy tylko napastnik pozna nazwę i hasło administratora. Oprogramowanie do współdzielenia plików na komputerach klienckich również tworzy zagrożenie, gdyż komputery klienckie przechowują zawartość witryn SharePoint lokalnie, ręcznie lub automatycznie pobierając ją do swoich katalogów tymczasowych. Tym samym farma SharePoint nie może być bezpieczniejsza niż komputery klienckie, z których korzystają użytkownicy uzyskujący dostęp do zasobów farmy.

Oczywiście moje środowisko testowe ma jeszcze inne słabości. Zapraszam do przestudiowania odpowiednich rozdziałów w podręcznikach wzmacniania zabezpieczeń SharePoint i kontynuowania tego śledztwa na własną rękę. Jak sądzę, uważny Czytelnik znajdzie przynajmniej kilka dodatkowych problemów, takich jak utrzymywanie witryny SharePoint 3.0 Central Administration oraz mechanizmów wyszukiwania bezpośrednio na serwerach frontowych, które obsługują zawartość witryn, brak jakiegokolwiek rozwiązania antywirusowego na serwerach, współużytkowanie niezabezpieczonego serwera bazodanowego przez farmy WSS i HR, tak że wszystkie komputery w środowisku testowym mają bezpośredni dostęp do serwera bazy danych czy to, że komunikacja sieciowa odbywa się bez szyfrowania. Żadne z tych zjawisk nie jest pożądane, zatem spróbujmy zająć się przynajmniej niektórymi z nich.

 Do początku strony

Włączanie Network Access Protection

Istnieje wiele działań, które można podjąć w celu podniesienia bezpieczeństwa środowiska SharePoint, takich jak kontrola fizycznego dostępu do komputerów i sieci, skonfigurowanie sieci vLAN i list kontroli dostępu (ACL) na routerach czy zabezpieczenie serwerów infrastruktury (DNS, DHCP, kontrolerów domeny i tak dalej) poprzez wdrożenie Microsoft Forefront Security for SharePoint oraz Active Directory Rights Management Services (AD RMS). Rozwiązania kontroli nad dostępem fizycznym oraz konfigurowanie sieci TCP/IP i routerów wykracza poza tematykę tego artykułu. Korzystanie z AD RMS omówiono w poprzednim odcinku, zatem kolejnym logicznym krokiem będzie wykorzystanie mechanizmów NAP, IPsec, HTTP over Secure Sockets Layer (SSL) oraz Forefront Security. W tym artykule skoncentruję się na zagadnieniach NAP i IPsec. HTTP over SSL oraz Forefront Security zostaną omówione w kolejnych publikacjach.

NAP w powiązaniu z IPsec oferuje co najmniej trzy kluczowe korzyści dla wewnętrznego środowiska SharePoint:

Dodatkowym bonusem jest możliwość centralnego zarządzania łącznością sieciową przez mechanizm Zasad grupy i inspekcji dostępu do sieci. Mówiąc w skrócie, NAP z IPsec pozwala skutecznie ustanowić pełną strategię zabezpieczeń środowiska SharePoint.

W swojej istocie NAP z IPsec opiera się na inteligentnym mechanizmie dystrybucji certyfikatów X.509. Na komputerze klienckim działają agenci kondycji systemu (System Health Agents – SHA), informujący agenta NAP o stanie zgodności poprzez oświadczenia kondycji (Statement-of-Health – SoH), które agent NAP konsoliduje w systemowe oświadczenia kondycji (System Statement of Health – SSoH). Utworzony SSoH jest przesyłany do składnika IPsec NAP Enforcement Client (NAP EC) na komputerze klienckim, a ten z kolei przesyła SSoH do NAP Enforcement Server (NAP ES). Na serwerze tym działa składnik Health Registration Authority (HRA), który uzyskuje certyfikaty kondycji systemu z urzędu certyfikacji (CA) dla komputerów zgodnych z zasadami. Rysunek 3 ilustruje uzyskiwanie certyfikatu kondycji przez klienta NAP.

Rysunek 3: Komunikacja pomiędzy klientem i serwerem NAP w celu uzyskania certyfikatu kondycji (Health Certificate).

W celu sprawdzenia, czy komputer żądający certyfikatu jest zgodny z zasadami, NAP ES przesyła SSoH w komunikacie RADIUS do serwera zasad sieciowych (Network Policy Server – NPS). Z kolei NPS przesyła SSoH do NAP Administration Server, który wydobywa poszczególne oświadczenia kondycji (SoH) z SSoH i przesyła je do odpowiednich weryfikatorów (System Health Validators – SHV). SHV analizują informacje zawarte w SoH i zwracają odpowiedź o stanie kondycji (SoHR), które NPS konsoliduje w systemową odpowiedź kondycji (SSoHR), przesyłaną przez system NAP zwrotnie do agentów kondycji na komputerze klienckim. Poprzez SoH i SoHR weryfikatory SHV komunikują się ze swoimi odpowiednikami SHA. Na przykład odpowiedź SoHR z SHV odpowiedzialnego za oprogramowanie antywirusowe może poinstruować odpowiadającego mu agenta, by pobrał najnowszą wersję pliku sygnatur z serwera naprawczegow celu doprowadzenia komputera do stanu zgodności.

Po stronie serwera NAP wykonuje porównanie odebranych SoHR ze skonfigurowanymi zasadami sieci i kondycji i wystawia certyfikat zdrowia, jeśli komputer kliencki jest zgodny. Klient NAP otrzymuje certyfikat z NAP ES i zapisuje go w lokalnym magazynie certyfikatów komputera. Certyfikat ten jest odtąd dostępny dla negocjacji Internet Key Exchange (IKE), pozwalając na utworzenie powiązań zabezpieczeń IPsec z zaufanymi partnerami łączności. Klient NAP odnawia certyfikat kondycji, gdy jego czas ważności zbliża się ku końcowi lub gdy SHA zasygnalizuje zmianę statusu kondycji. Podstawą tego mechanizmu jest to, że komputery zgodne z zasadami otrzymują certyfikaty kondycji, zaś niezgodne ich nie otrzymują. Więcej szczegółów technicznych można znaleźć w dokumencie „Network Access Protection Platform Architecture”.

 Do początku strony

Ustanawianie izolacji domeny

Nawet w mojej skromnej, małej sieci testowej, w której role NPS i HRA zostały umieszczone na pojedynczym serwerze, można natychmiast dostrzec korzyści wynikające z NAP. Gdy tylko włączymy NAP na komputerach klienckich, wykorzystując ustawienia Zasad grupy, pojawi się zalecenie zainstalowania najświeższych poprawek zabezpieczeń i skanera antywirusowego. Klient NAP poinformuje o brakujących składnikach zabezpieczeń, zaś użytkownik zostanie powiadomiony, że dostęp do sieci może zostać ograniczony, dopóki komputer nie będzie zgodny z wymaganiami kondycji. W tym momencie jednak niezgodne komputery nadal będą miały dostęp do wszystkich serwerów, gdyż jeszcze nie skonfigurowaliśmy zasad IPsec. Bez zasad IPsec, które żądają lub wymagają uwierzytelnienia dla połączeń przychodzących i wychodzących, infrastruktura NAP nie jest niczym więcej niż mechanizmem dystrybucji certyfikatów kondycji. Aby osiągnąć prawdziwą efektywność NAP, musimy zaimplementować izolację domeny.

Wdrożenie izolacji domeny oznacza podział sieci wewnętrznej na segmenty sieci z ograniczeniami, brzegowej i zabezpieczonej za pośrednictwem zasad wymuszania IPsec. Celem jest uniemożliwienie niezgodnym komputerom komunikacji z jakimkolwiek serwerem w sieci wewnętrznej – z wyjątkiem tych serwerów, do których komputery te muszą mieć dostęp, aby poprawić stan kondycji i uzyskać certyfikat. Na Rysunku 4 jest to serwer NAP – NPS01. Różnica pomiędzy segmentem brzegowym i zabezpieczonym polega na tym, że w segmencie brzegowym zasady IPsec żądają uwierzytelnienia połączeń, ale pozwalają przejście na niezabezpieczoną łączność z niezgodnymi komputerami, podczas gdy segment zabezpieczony wymaga uwierzytelniania, co uniemożliwia komunikację z niezgodnymi komputerami.

Rysunek 4: Segmenty sieci z ograniczeniami (Restricted), brzegowy (Boundary) i zabezpieczony (Secure) w NAP.

Kontroler domeny widoczny na Rysunku 4 stanowi przypadek szczególny. Możemy żądać lub wymagać łączności zabezpieczonej przy użyciu IPsec pomiędzy członkami domeny i kontrolerami domeny, o ile wszystkie komputery pracują pod kontrolą systemu Windows Vista lub Windows Server 2008 (patrz arkusz „Configuring IPSec for Domain Controller Communication”), ale konfiguracja taka nie jest wspierana w systemach Windows Server 2003 ani Windows XP. Jeśli zdecydujemy się, że IPsec nie będzie używane do łączności z kontrolerami domeny, DC01 stanie się częścią sieci z ograniczeniami; żądanie IPsec przeniesie go do segmentu brzegowego, zaś wymaganie IPsec uczyni go częścią segmentu zabezpieczonego. Rzeczywista konfiguracja jest zależna od konkretnej sytuacji i potrzeb. W miarę możliwości zalecane jest korzystanie z IPsec.

 Do początku strony

Implementowanie izolacji serwera (i stacji roboczej)

Ustanowienie NAP z wymuszaniem IPsec oraz izolacji domeny jest pierwszym znaczącym kamieniem milowym na drodze do wzmocnienia zabezpieczeń. Wszystkie komputery klienckie muszą teraz spełnić rozsądnie zdefiniowane wymagania kondycji, zanim będą mogły uzyskać dostęp do jakichkolwiek wewnętrznych zasobów SharePoint. Teraz możemy się skoncentrować na podziale środowiska SharePoint na kilka warstw, aby osiągnąć bardziej szczegółową kontrolę nad łącznością, w tym nad komunikacją pomiędzy komputerami klienckimi. Rysunek 5 ilustruje możliwą strategię segmentacji, opartą na roli poszczególnych komputerów w sieci wewnętrznej.

Rysunek 5: Ulepszone środowisko testowe z wieloma farmami SharePoint.

Jak można zauważyć, moje środowisko testowe zawiera teraz dodatkowe systemy. Oprócz innych rzeczy, zmieniłem konfigurację farm WSS i HR, określając dla nich oddzielne konta zabezpieczeń, przeniosłem bazy danych konfiguracji i zawartości farmy HR na oddzielny serwer SQL oraz wdrożyłem oddzielne serwery dla ról SharePoint 3.0 Central Administration i SharePoint Search w obu farmach.

Zabezpieczenie łączności pomiędzy poszczególnymi warstwami staje się teraz prostym zadaniem dzięki wcześniejszej pracy nad skonfigurowaniem NAP z wymuszaniem IPsec. Za pomocą Zasad grupy można w scentralizowany sposób zarządzać wszystkimi regułami Windows Firewall with Advanced Security, blokując komunikację przychodzącą i wychodzącą na klientach i serwerach na najbardziej restrykcyjnych poziomach. Zalecam wyłączenie łączenia reguł w Zasadach grupy, aby powstrzymać administratorów lokalnych przed wprowadzeniem konfliktowych reguł zapory i bezpieczeństwa połączenia na komputerach członkowskich. Możemy na przykład zablokować porty 1434 UDP i TCP na serwerach bazodanowych, otworzyć niestandardowy port TCP dla domyślnej instancji SQL Server, zaszyfrować ruch, otworzyć tylko te porty TCP, których aplikacje sieci Web używają na serwera frontowych i dla wszystkich komputerów nienależących do działu HR zablokować dostęp do dowolnego serwera lub klienta w tym dziale.

Interesujące jest pytanie, czy należy również zablokować dostęp z wrażliwych komputerów do tych, które mają mniejsze wymagania zabezpieczeń – na przykład, czy klienci HR powinni mieć dostęp do serwerów SharePoint w farmie WSS. Jest to klasyczna sytuacja, w której następuje kolizja pomiędzy wymaganiami zabezpieczeń i produktywności. Z praktycznego punktu widzenie niemożliwe wydaje się odmówienie pracownikom działu kadr dostępu do ogólnego zasobu firmowego, jakim są witryny SharePoint w moje farmie WSS, co jednak oznacza, że farma ta musi być zgodna z tymi samymi standardami zabezpieczeń, jak farma HR. Dlatego w obu farmach musiałem przenieść role witryny SharePoint 3.0 Central Administration i wyszukiwania na oddzielny komputer i zastosować reguły zapory i bezpieczeństwa połączenia. Oczywiście należy również wyznaczyć dedykowane, nieuprzywilejowane konta do celów administracji SharePoint w obu farmach i zastosować dalsze działania wzmacniające zabezpieczenia. Joel Oleson opublikował doskonałą listę podsumowującą kroki wzmacniania zabezpieczeń w swoim blogu SharePoint Land. Zdecydowanie polecam zastosowanie się do jego porad i zbudowania solidnego fundamentu dla całościowego zabezpieczenia środowiska SharePoint.

 Do początku strony

Podsumowanie

Farmy SharePoint nie działają w próżni. Istnieją w środowisku obejmującym komputery klienckie, serwery infrastruktury i sprzęt sieciowy. Oznacza to, że trzeba zająć się również tymi składnikami, jeśli chcemy osiągnąć lepszy poziom zabezpieczeń SharePoint. Nie jest możliwe utworzenie bezpiecznej farmy SharePoint wewnątrz niezabezpieczonej struktury Active Directory. Nie jest możliwe zabezpieczenie farmy SharePoint, jeśli komputery klienckie będą zainfekowane wirusami i programami szpiegowskimi. Nie jest możliwe zabezpieczenie farmy SharePoint, jeśli napastnik może przechwycić konta użytkowników, administratorów lub usług w dowolnym miejscu.

Windows Server 2008 udostępnia podstawy do narzucenia solidnych mechanizmów zabezpieczeń na las Active Directory poprzez Network Access Protection w powiązaniu z wymuszaniem Internet Protocol Security, Windows Firewall with Advanced Security oraz zarządzaniem Zasad grupy. Korzyści wynikające z zastosowania tych technik w środowisku SharePoint ponad wszelką wątpliwość warte są poniesionych wysiłków. Umożliwiają one kontrolę i zabezpieczenie łączności pomiędzy stacjami roboczymi, serwerami i kontrolerami domeny; wymuszenie standardów kondycji; implementację izolacji domeny, a także podział środowiska SharePoint na odseparowane warstwy. Poprzez członkostwo w grupach zabezpieczeń lub jednostkach organizacyjnych Active Directory automatycznie określa, jakie ustawienia zasad mają być stosowane na każdym członku domeny – komputerach klienckich, serwerach baz danych, serwerach frontowych lub serwerach warstwy pośredniej służących do celów administracyjnych i innych. Można ustanowić ogólne zasady dla każdej warstwy i szczegółowe zasady dla każdego typu komputera i roli serwera. Można też powstrzymać użytkowników przed utrzymywaniem SharePoint na komputerach klienckich, blokując wszystkie przychodzące połączenia, jak również zablokować możliwość instalowania niezaakceptowanych farm SharePoint w biurach oddziałowych, które mogłyby stać się furtkami dla napastników.

Nie należy jednak nigdy przesadzać z ograniczeniami. Trzeba pamiętać, że wiele działań opiera się na wdrożeniach SharePoint rozmieszczonych poza serwerownią. Poza wszystkim SharePoint jest przede wszystkim platformą współpracy dla całego przedsiębiorstwa.

 Do początku strony

Odnośniki

• Witryna Network Access Protection
  go.microsoft.com/fwlink/?LinkId=69752
• Witryna SharePoint Products and Technologies
  microsoft.com/sharepoint
• Windows SharePoint Services TechCenter
  technet.microsoft.com/windowsserver/sharepoint
• Windows SharePoint Services Developer Center
  msdn2.microsoft.com/sharepoint
• Microsoft SharePoint Products and Technologies Team Blog
  blogs.msdn.com/sharepoint

O autorze

Pav Cherny jest ekspertem IT i autorem specjalizującym się w technologiach firmy Microsoft służących współdziałaniu i komunikacji. Jego publikacje obejmują dokumenty techniczne, podręczniki oraz książki skoncentrowane na operacjach IT i administrowaniu systemami. Jest prezesem Biblioso Corporation – firmy specjalizującej się w zarządzanych usługach dokumentacyjnych i lokalizacyjnych.

Do początku strony