Tajniki SharePoint: Zabezpieczanie zewnętrznej komunikacji SharePoint

Autor: Pav Cherny

Opublikowano: 6 października 2009

Zawartość strony

	Analiza projektu topologii
	Uwierzytelnianie
	Konfiguracja wsparcia dla protokołu TLS w witrynie
	Konfiguracja usług IIS w celu wspierania certyfikatów SSL
	Konfiguracja serwera ISA Server
	Jak ułatwić sobie życie
	Dodatkowe materiały

Szyfrowanie ruchu SharePoint przy użyciu protokołów Transport Layer Security (TLS)/Secure Sockets Layer (SSL) stanowi popularny sposób zabezpieczania komunikacji w scenariuszach, które obejmują dostęp za pośrednictwem Internetu. Certyfikaty SSL są powszechnie wykorzystywane w komunikacji klient/serwer w sieci Web począwszy od roku 1995, kiedy to firma Netscape wprowadziła protokół SSL, który zabezpieczał dane poprzez zaimplementowanie mechanizmu kryptograficznego rozszerzającego protokół HTTP. Technologie SharePoint mogą korzystać z protokołu TLS za pośrednictwem serwera IIS oraz .NET, które stanowią wewnętrzną platformę serwera sieci Web z wsparciem dla technologii TLS. Jednak obsługa protokołu TLS w witrynach SharePoint stanowi zaledwie jeden ze środków zabezpieczania zewnętrznej komunikacji. Należy rozważyć zastosowanie również innych rozwiązań, takich jak zapory umieszczone na hoście oraz w sieci, projekt topologii, a także zależności wewnętrznej usługi Active Directory oraz fizycznej sieci.

W artykule opublikowanym w lipcu 2009 roku omówione zostały możliwości zabezpieczania komunikacji z serwerem w wewnętrznym środowisku, które polegały na wymuszaniu zasad dotyczących kondycji systemu przy użyciu technologii Network Access Protection (NAP) z IPSec oraz na postępowaniu zgodnie z ogólnymi zaleceniami dotyczącymi bezpieczeństwa systemu SharePoint. Jednym z kluczowych warunków bezpieczeństwa komunikacji wewnętrznej jest identyfikacja tożsamości użytkowników i komputerów wewnętrznych oraz mechanizm tworzenia zasad, które służą do nadawania lub odbierania uprawnień w zależności od tej tożsamości. Warunek ten jest w pełni spełniony w środowiskach uwierzytelnianych (np. tych wykorzystujących Active Directory oraz Kerberos bądź NTLM), natomiast tylko w pewnym zakresie spełniają go środowiska, w których choć część użytkowników jest anonimowa lub pewna grupa użytkowników (np. dostawcy lub partnerzy) wymaga zastosowania innych zasad. Bezpieczeństwo w kontekście witryn z dostępem do Internetu wymaga zastosowania podobnego podejścia polegającego na zastosowaniu wielu warstw.

Jedna z podstawowych reguł zabezpieczania komunikacji zewnętrznej nakazuje, aby niepożądany dostęp był blokowany możliwie jak najwcześniej, a jednocześnie zachowany został potencjał dokonywania inspekcji oraz rejestrowania aktywności użytkowników nieuwierzytelnionych i uwierzytelnionych. Typowe, minimalistyczne podejście do implementacji tej reguły polega na zastosowaniu zapory sieciowej na brzegu sieci w celu uwierzytelniania użytkowników oraz inspekcji ruchu HTTP w oparciu o informacje o stanie. Jednak zastosowanie protokołu TLS pociąga za sobą pewne wyzwania w zakresie inspekcji pakietów w oparciu o informacje o stanie, ponieważ zapora sieciowa musi mieć możliwość deszyfrowania pakietów, analizowania ich, ponownego zaszyfrowania oraz przekazania do serwera frontonu celem dalszego przetwarzania. Co więcej, zapora sieciowa (oraz wszelkie rozwiązania do równoważenia obciążenia w sieci) muszą utrzymywać sesje HTTPS. Produkty Internet Security and Acceleration (ISA) Server 2006 oraz Intelligent Application Gateway (IAG) Server 2007 oferują zapory sieciowe, które mogą zostać zintegrowane z rozwiązaniami IIS oraz SharePoint w celu dostarczenia metod zabezpieczania komunikacji zgodnych z protokołem TLS.

Aby zrozumieć mechanizm komunikacji TLS w systemie SharePoint, trzeba mieć świadomość, w jaki sposób architektura oraz topologia środowiska wpływają na sposób obsługiwania certyfikatów SSL przez serwer IIS oraz zapory sieciowe. W związku z tymi zależnościami istnieje wiele aspektów, które warto wziąć pod uwagę, projektując i wdrażając rozwiązania SharePoint dostępne za pośrednictwem Internetu. Należy przeanalizować nie tylko względy dotyczące technologii IIS, SSL oraz zapory sieciowej, ale także aspekty konfiguracyjne dotyczące samej architektury systemu SharePoint, takie jak mapowania dostępu alternatywnego (AAM), uwierzytelnianie czy strefy SharePoint.

Analiza projektu topologii

Proces projektowania wielu warstw zabezpieczeń dla witryn SharePoint rozpoczyna się od zdefiniowania topologii sieci fizycznej. Zredukowanie lub wyeliminowanie niepożądanego ruchu w sieci, zanim dotrze on do serwerów frontonu lub serwerów wewnętrznych, pozwala nie tylko zmniejszyć obciążenie serwerów, ale również ogranicza ryzyko otrzymania wirusów, spamu lub złośliwego oprogramowania.

Wybór topologii sieci wspierającej zastosowanie protokołów TLS w systemie SharePoint zależy wymagań danej organizacji. Rysunek 1 prezentuje drzewo decyzyjne obejmujące wybrane wskaźniki oraz odpowiadające im decyzje dotyczące topologii.

Można dodatkowo uprościć proces podejmowania decyzji, dzieląc opcje topologii na trzy obszary:

• Ruch przed zaporą sieciową.
• Ruch między zaporą sieciową a siecią wewnętrzną.
• Ruch w sieci wewnętrznej.

Rysunek 1: Proces decyzyjny dla topologii obejmujących dostęp za pośrednictwem Internetu.

Rozróżnienie to jest szczególnie istotne w kontekście konfiguracji środowiska TLS, ponieważ wymaga skonfigurowania mechanizmu przekierowywania oraz reguł zapory sieciowej w celu stworzenia pomostu połączeń HTTPS między żądaniami internetowymi a serwerami frontonu IIS, przygotowania usług IIS do obsługi aplikacji SharePoint oraz zapewnienia ochrony zasobów wewnętrznych. W zależności od topologii ruch TLS może przechodzić przez wszystkie trzy obszary za pośrednictwem wielu routerów oraz zapór sieciowych . Przyjrzyjmy się trzem typom topologii stosowanych w przypadku witryn dostępnych za pośrednictwem Internetu i rozważmy, w jaki sposób topologia wpływa na ruch TLS. Rysunek 2 prezentuje podstawową "brzegową" topologię z jedną zaporą sieciową zabezpieczającą serwery wewnętrzne.

Rysunek 2: Podstawowa topologia brzegowa z pojedynczą zaporą sieciową.

W topologii brzegowej pojedyncza zapora sieciowa znajduje się między użytkownikami zewnętrznymi a wewnętrznymi witrynami SharePoint. Dzięki temu dla użytkowników wewnętrznych oraz zewnętrznych wykorzystywane jest to samo środowisko Active Directory, co ułatwia zarządzanie i administrację. Aby zabezpieczyć ruch realizowany za pośrednictwem protokołów TLS, można skonfigurować zaporę sieciową tak, aby pełniła ona również rolę tzw. odwrotnego proxy (reverse proxy). Koncepcja zintegrowanego odwrotnego proxy, takiego jak ISA Server, stanowi kluczowy czynnik w zakresie zabezpieczania witryn z dostępem do Internetu, ponieważ odwrotne proxy przechwytuje przychodzące żądania, może uwierzytelniać użytkowników zewnętrznych, deszyfruje ruch TLS, analizuje zgodność pakietów z regułami zapory sieciowej i przekazuje żądania do serwera frontonu. Publiczne adresy URL mogą różnić się od wewnętrznych adresów URL, w związku z czym odwrócone proxy musi oferować funkcję tłumaczenia łączy, która konwertuje zewnętrzne adresy URL do wewnętrznych adresów URL. IAG Server oferuje dodatkowe możliwości zabezpieczania, takie jak autoryzacja punktu końcowego za pośrednictwem zasad dostępu w oparciu o tożsamość użytkownika oraz stan komputera klienckiego, a także możliwość tłumaczenia łączy dla wewnętrznych adresów URL systemu SharePoint w przypadku wykorzystania technologii Outlook Web Access.

Aby dodać do topologii dodatkową warstwę i zapewnić bardziej szczegółową kontrolę nad komunikacją między serwerami, można stworzyć sieć graniczną, w której znajdować się będą serwery systemu SharePoint. W sieci granicznej zapora sieciowa oddziela serwery SharePoint od Internetu oraz od sieci wewnętrznej. Scenariusz ten nazywa się topologią kolejnych zapór sieciowych, jak pokazano na Rysunku 3.

Rysunek 3: Topologia kolejnych zapór sieciowych (“back-to-back”) z dwoma zaporami.

Oczywiście topologia kolejnych zapór sieciowych może zawierać więcej niż dwie zapory. Można zaimplementować dodatkowe warstwy rozdzielone zaporami sieciowymi lub routerami, aby dokonać jeszcze bardziej szczegółowego podziału ról SharePoint. Na przykład można zastosować scenariusz trójwarstwowy, umieszczając każdą z warstw w strefie DMZ: w pierwszej serwery frontonu, w kolejnej serwer aplikacji, bazy danych oraz wyszukiwania/indeksowania, a w ostatniej serwery Active Directory/DNS. Można również dostosować topologię „back-to-back” tak, aby dołączyć wewnętrzne środowisko przemieszczania w postaci osobnej farmy i publikować je w farmie w sieci granicznej. Inną możliwością jest podział farmy SharePoint między sieć graniczną a wewnętrzną w celu stworzenia topologii kolejnych zapór sieciowych z podziałem, jak pokazano na Rysunku 4. Ze względu na zalecenie, zgodnie z którym należy stosować wiele różnych warstw zabezpieczeń w topologii, serwery frontonu znajdują się w sieci granicznej, a serwery wewnętrzne, na których uruchomiony jest system SQL Server, są umieszczone w sieci wewnętrznej. Pozostałe role, takie jak funkcja indeksowania, wyszukiwania czy Administracja Centralna, mogą zostać zaimplementowane w dowolnej z tych sieci.

Rysunek 4: W topologii kolejnych zapór sieciowych z podziałem ( “split back-to-back”) role serwerowe mogą być konfigurowane w strefie DMZ lub sieci wewnętrznej.

Umieszczenie serwera wyszukiwania w sieci wewnętrznej umożliwia zmaksymalizowanie wydajności operacji przeszukiwania. Można wyznaczyć serwer wyszukiwania odpowiadający za przeszukiwanie (ang. crawling). Należy pamiętać, że aby w topologii kolejnych zapór sieciowych z podziałem możliwa była komunikacja, konieczne jest jednostronne zaufanie między środowiskami Active Directory w sieci granicznej oraz wewnętrznej.

 Do początku strony

Uwierzytelnianie

Odpowiednia konfiguracja mechanizmu uwierzytelniania służącego do zabezpieczania komunikacji zewnętrznej może stać się niebagatelnym wyzwaniem ze względu na liczbę dostępnych opcji oraz poziomów topologii, na których można przeprowadzać uwierzytelnianie oraz autoryzację.

Na przykład środowisko może wspierać technologię RSA SecurID, obejmować serwer Network Policy Server (NPS) lub wykorzystywać niestandardowy katalog Lightweight Directory Access Protocol (LDAP). Zasadniczo najistotniejsze aspekty uwierzytelniania związane z zabezpieczaniem komunikacji zewnętrznej systemu SharePoint to uwierzytelnianie użytkowników zewnętrznych i wewnętrznych oraz uwierzytelnianie IIS na potrzeby witryn SharePoint.

Można dodatkowo uprościć to zagadnienie, śledząc ścieżki komunikacji dla żądań przesyłanych przez zewnętrznych użytkowników do witryn SharePoint i analizując przebieg procesu uwierzytelniania oraz autoryzacji.

1. Użytkownik zewnętrzny przesyła żądanie, które zostaje skierowane do zapory sieciowej. Jeśli rolę zapory sieciowej pełni ISA Server skonfigurowany tak, aby wykorzystywać uwierzytelnianie w oparciu o formularze (FBA), użytkownik zostanie uwierzytelniony po wypełnieniu formularza logowania. Następnie żądanie zostaje przesłane do serwera frontonu.
2. IIS na serwerze frontonu akceptuje żądanie, określa witrynę powiązaną z adresem URL, sprawdza konfigurację uwierzytelniania dla witryny, uwierzytelnia komunikację i przekazuje żądanie do systemu SharePoint w celu autoryzacji.
3. SharePoint dokonuje autoryzacji. Aspekty związane z uprawnieniami w witrynie SharePoint oraz autoryzacją wykraczają poza zakres tego artykułu, ponieważ wsparcie TLS dla każdej z witryn jest konfigurowane na poziomie serwera IIS. Dodatkowe informacje na temat uwierzytelniania oraz autoryzacji w systemie SharePoint znaleźć można w artykule Plan authentication methods (Office SharePoint Server).

 Do początku strony

Konfiguracja wsparcia dla protokołu TLS w witrynie

SharePoint w dużym stopniu polega na usługach IIS oraz wewnętrznej topologii i konfiguracji uwierzytelniania w zakresie dostarczania wsparcia dla funkcji TLS. Zanim żądanie zostaje skierowane do systemu SharePoint, musi przejść przez zaporę sieciową i zostać obsłużone przez serwer IIS. Konfiguracja wsparcia TLS w witrynach SharePoint polega w zasadzie na poinformowaniu systemu SharePoint o wewnętrznym środowisku dla każdej z witryn, a nie bezpośrednim określaniu certyfikatów SSL, tworzeniu konta usługi itd. Aczkolwiek wdrażając zabezpieczenia TLS, należy wziąć pod uwagę dwa aspekty charakterystyczne dla systemu SharePoint: strefy oraz mapowanie dostępu alternatywnego (Alternate Access Mapping - AAM). Obie funkcje są konfigurowane w witrynie Administracji centralnej w sekcji Zarządzania aplikacjami.

Tworząc lub rozszerzając aplikację sieci Web, można określić strefy i szczegółowe informacje o środowisku, które system SharePoint wykorzystuje do tworzenia początkowego zbioru mapowań AAM (patrz Rysunek 5). Kluczowe decyzje w zakresie bezpieczeństwa polegają na wyborze dostawcy uwierzytelniania oraz określeniu, czy ISA Server ma wykorzystywać protokół TLS do komunikowania się z serwerami frontonu bądź czy ma zatrzymywać żądania HTTPS od użytkowników zewnętrznych na zaporze sieciowej i kontynuować komunikację poprzez HTTP.

Rysunek 5: SSL oraz inne opcje konfiguracyjne witryny SharePoint.

Chociaż zastosowanie TLS w komunikacji serwera ISA Server z serwerami frontonu zwiększa ilość koniecznych operacji przetwarzania, pozwala uzyskać kompleksowo zaszyfrowane rozwiązanie. Ponadto zatrzymanie protokołów TLS na poziomie serwera ISA Server może zakłócić działanie pewnych scenariuszy użytkowania np. w przypadku stosowania składników Web Part, które przechowują adresy URL w bazie danych SQL Server. Proces przypomina włączanie obsługi TLS w istniejącej witrynie. Trzeba zaznaczyć pole wyboru Użyj protokołu SSL (Use Secure Sockets Layer), skonfigurować pozostałe opcje, a następnie przejść do ustawień AAM i sprawdzić, czy zostały one w odpowiedni sposób skonfigurowane.

Konfiguracje stref oraz mapowań AAM są ze sobą powiązane. System SharePoint wykorzystuje koncepcję stref do wprowadzenia logicznego podziału części topologii, takich jak Internet, ekstranet czy intranet, a także adresów URL dostępnych w tych częściach. Definicje AAM określają, w jaki sposób nagłówek URL powinien być prezentowany użytkownikom różnych stref, gdy adres URL różni się od wewnętrznego adresu URL. Jeśli wewnętrzny adres URL jest taki sam jak publiczny URL, który wykorzystuje w pełni kwalifikowaną nazwę domeny (FQDN), nie ma potrzeby konfigurowania mapowań AAM, system SharePoint realizuje je w sposób automatyczny. W innych sytuacjach należy skonfigurować mapowania AAM dla witryn SharePoint. Troy Starr umieścił na blogu SharePoint Team kompleksowe omówienie mapowań AAM w systemie SharePoint What every SharePoint administrator needs to know about Alternate Access Mappings (Part 1 of 3). Warto się z nim zapoznać, gdyż nieprawidłowa konfiguracja mapowań AAM stanowi jedno z najczęstszych źródeł problemów w scenariuszach ekstranetowych.

 Do początku strony

Konfiguracja usług IIS w celu wspierania certyfikatów SSL

Jak już wspomniano, obsługa protokołów SSL w witrynie SharePoint jest włączana na poziomie IIS. W wersji IIS7 certyfikaty SSL są konfigurowane przy użyciu konsoli Server Certificates, która znajduje się na stronie Properties (Właściwości) serwera IIS. Firma Microsoft opublikowała instrukcje, analizy oraz scenariusze użytkowania, które warto wziąć pod uwagę, przygotowując witryny IIS do obsługi protokołu SSL. Należy pamiętać, że powiązania urzędu certyfikacji z adresem IP:portem mają szczególne znaczenie w przypadku zabezpieczania witryn dostępnych w Internecie. Istnieje szereg metod generowania certyfikatu SSL. Można użyć programu selfssl.exe, wdrożyć infrastrukturę klucza publicznego (PKI) z wykorzystaniem zaufanego urzędu certyfikacji systemu Windows lub skorzystać z komercyjnego dostawcy. Własnoręcznie podpisane certyfikaty mogą stanowić zadowalające rozwiązanie w środowiskach testowych oraz programistycznych, ale w środowisku produkcyjnym mogą przysporzyć pewnych problemów. Jeśli użytkownicy nie zaakceptują certyfikatu w przeglądarce, podczas uzyskiwania dostępu do witryny wspierającej protokół SSL zostaną oni poinformowani, że certyfikat pochodzi z niezaufanego źródła. To może prowadzić do niepotrzebnych telefonów do działu wsparcia oraz nieporozumień, których można uniknąć, implementując certyfikat wystawiony przez główny urząd certyfikacji.

Istnieje możliwość wykorzystania tego samego adresu IP lub portu dla wielu witryn z włączoną obsługą protokołu SSL. Najprostsze podejście polega na zastosowaniu stałego adresu IP i tego samego portu dla każdej z witryn, aby serwer IIS mógł powiązać witrynę z adresem IP oraz portem. Alternatywnie jeśli środowisko wykorzystuje jedną główną domenę i wiele witryn podrzędnych, można użyć certyfikatu typu wildcard lub certyfikatu z wieloma alternatywnymi nazwami witryny (SAN). Proces ten w dużym stopniu przypomina zastosowanie zwykłego certyfikatu, ale w wersji IIS 7 nie można dokonać konfiguracji w konsoli Site Bindings (Powiązania witryny). Zamiast tego należy posłużyć się narzędziem appcmd i uruchomić następujące polecenie w celu powiązania SSL z witryną oraz ustawienia nagłówka hosta: C:\Windows\System32\inetsrv\appcmd set site /site.name:<CustomSiteName> /+bindings.[protocol='https',bindingInformation='*:443:<FQDN>]. Jeśli operacja zostanie wykonana pomyślnie, powiązanie SSL z określonym nagłówkiem hosta powinno pojawić się w sekcji Site Bindings.

 Do początku strony

Konfiguracja serwera ISA Server

Niezależnie od tego, czy chcemy zabezpieczyć istniejącą bądź też nową witrynę SharePoint przy użyciu protokołu TLS, ruch musi pomyślnie przechodzić przez zaporę sieciową. ISA Server oferuje szereg mechanizmów wspierających współpracę z systemem SharePoint i umożliwiających przepływ informacji: FBA, pomosty HTTPS, tłumaczenie łączy poprzez odwrotne proxy oraz reguły publikowania SharePoint.

ISA Server wykorzystuje kreator ułatwiający publikowanie witryn SharePoint. Kreator tworzy komponent nasłuchujący i regułę "przyzwalania", która akceptuje ruch SharePoint. Przed uruchomieniem kreatora należy wyeksportować certyfikat SSL, który został zainstalowany przy pomocy serwera IIS na serwerze frontonu pełniącym rolę hosta witryny i zaimportować go na serwerze ISA Server przy użyciu przystawki MMC Certificates. Dzięki zaimportowaniu certyfikatu do magazynu na lokalnym komputerze, stworzony w ISA Server komponent nasłuchujący może deszyfrować otrzymywane pakiety, analizować je i ponownie szyfrować. Dodatkowe informacje na temat konfigurowania ISA Server z Myśla o integracji z systemem SharePoint znaleźć można w artykule Authentication in ISA Server 2006.

Przed przygotowaniem serwera ISA Server do publikacji witryn SharePoint z wsparciem dla protokołu SSL, należy upewnić się, że wewnętrzne oraz zewnętrzne adresy URL mogą być rozwiązywane przez serwer DNS, skonfigurowane zostały konta i uprawnienia użytkowników oraz strefy SharePoint i mapowania AAM, a ponadto zainstalowany został certyfikat SSL dla witryny przy użyciu serwera IIS. Dopiero wtedy można wprowadzić odpowiednie dane w systemie ISA Server. Konfigurując komponent nasłuchujący oraz regułę publikowania, należy pamiętać o następujących kwestiach:

• AAM: Aby mapowania dostępu alternatywnego działały prawidłowo, trzeba skonfigurować regułę publikowania tak, aby przekazywany był oryginalny nagłówek hosta. Ponadto muszą zostać określone odpowiednie adresy FQDN dla wewnętrznych oraz zewnętrznych adresów URL.
• FBA: Należy wybrać opcję HTML Form Authentication and Windows (Active Directory) na karcie Authentication, o ile nie jest wykorzystywany protokół Kerberos lub niestandardowe rozwiązanie do uwierzytelniania.
• Należy odmówić dostępu nieuwierzytelnionym użytkownikom. W celu zwiększenia bezpieczeństwa warto wybrać opcję All Authenticated Users bądź usunąć opcję All Users i określić użytkowników w sekcji User Sets.

 Do początku strony

Jak ułatwić sobie życie

Zadanie zabezpieczania witryn SharePoint przy użyciu protokołu TLS może przysparzać wielu problemów. Zapora sieciowa może nie przekazywać ruchu w odpowiedni sposób (jako odwrotne proxy) lub może nie radzić sobie z tłumaczeniem łączy. Konfiguracja mechanizmu przekazywania w bardziej złożonych topologiach może stanowić spore wyzwanie. Ponadto ustawienia AAM oraz stref mogą nie odpowiadać ustawieniom serwera DNS lub zapory sieciowej. Dobra wiadomość jest taka, że zastosowanie wielu warstw zabezpieczeń zewnętrznych pozwala na wyizolowanie problemów, co ułatwia ich rozwiązywanie. Dodatkowe uproszczenie stanowi zastosowanie serwera ISA Server z uwierzytelnianiem FBA oraz Windows. Wystarczy wybrać odpowiednią topologię, skonfigurować witrynę w systemie SharePoint, włączyć dla niej obsługę protokołu SSL na serwerze IIS, połączyć rozwiązania przy użyciu serwera ISA Server i zabezpieczona, zewnętrzna komunikacja z wykorzystaniem protokołu TLS jest gotowa.

 Do początku strony

Dodatkowe materiały

• SharePoint Products and Technologies Web site
• Windows SharePoint Services TechCenter
• Windows SharePoint Services Developer Center
• Microsoft SharePoint Products and Technologies Team Blog

O autorze

Pav Cherny to ekspert IT i autor specjalizujący się w technologiach firmy Microsoft służących do współpracy i zunifikowanej komunikacji. Jego publikacje obejmują dokumentacje, podręczniki dla użytkowników produktów oraz książki koncentrujące się na zadaniach działu IT oraz administracji systemami. Pav pełni funkcję prezesa firmy Biblioso Corporation, która specjalizuje się w usługach zarządzania dokumentacją i lokalizacją.

Do początku strony