Siedem nowych funkcji zwiększających bezpieczeństwo w aplikacji SharePoint

Opublikowano: 11 stycznia 2008

Zawartość strony

	Wstęp
	1. Dostawca dołączalnych usług uwierzytelniania (Pluggable Authentication Provider)
	2. Uwierzytelnianie na podstawie formularzy i pojedyncze logowanie (Web Single Sign-On)
	3. Szyfrowanie parametrów połączenia dla aplikacji MOSS
	4. Mapowanie stref i adresów dostępu
	5. Sprecyzowana zawartość dla osiągnięcia bezpieczniej współpracy
	6. Integracja z dołączalną usługą pojedynczego logowania
	7. Zarządzanie prawami do informacji (IRM)

Wstęp

Implementacja efektywnych rozwiązań w zakresie bezpieczeństwa środowiska aplikacji Microsoft Office SharePoint Server (MOSS) 2007 może w znacznym stopniu obniżyć koszty związane z zarządzaniem. Umożliwi to jednocześnie zespołom współpracę i dzielenie się danymi biznesowymi przy zachowaniu wymogów bezpieczeństwa. Wbudowane w aplikacji MOSS 2007 innowacyjne funkcje uwierzytelniania pozwalają na korzystanie ze standardów bezpieczeństwa sieci Web za pośrednictwem własnych dostawców usług uwierzytelniania. Odbywa się to na podstawie uwierzytelniania opartego na formularzach internetowych oraz na pojedynczym logowaniu (SSO). Ponadto aplikacja MOSS oferuje możliwość „granularnego” zarządzania prawami do zasobów biznesowych (np. plików systemu Microsoft® Office 2007), macierzystą obsługę szyfrowania, a także uproszczone procedury uwierzytelniania. Z aplikacją MOSS 2007 dostarczanych jest siedem gotowych do użycia funkcji bezpieczeństwa, które zostały omówione poniżej.

 Do początku strony

1. Dostawca dołączalnych usług uwierzytelniania (Pluggable Authentication Provider)

Dostawca usług uwierzytelniania to komponent pozwalający na zweryfikowanie autentyczności użytkownika. Skonfigurowanie tego komponentu dla środowiska aplikacji MOSS jest bardzo istotne dla zachowania bezpieczeństwa procesu internetowej autentyfikacji w aplikacji SharePoint®.

Aplikacja MOSS nadal umożliwia korzystanie z metod uwierzytelniania opartych na systemie Windows® (dostępnych w poprzednich wersjach SharePoint), tj. z autentyfikacji na podstawie realnej tożsamości danego użytkownika w systemie Windows, uwierzytelniania zintegrowanego (Integrated), podstawowego (Basic) i (nowo dodanego) typu „Digest”.

Autentyfikacja na podstawie tożsamości w systemie Windows nie jest już jednak jedyną możliwością. Można korzystać z różnych dostawców usług uwierzytelniania tak, aby, na przykład, logowanie wewnętrznych użytkowników odbywało się na bazie uwierzytelniania w systemie Windows, a zewnętrznych – przy wykorzystaniu oddzielnego, dołączalnego dostawcy.

Aplikacja MOSS powstała na bazie technologii ASP.NET 2.0, dzięki czemu możliwe stało się korzystanie z dostawców dołączalnych usług uwierzytelniania. Pozwala to na przechowywanie informacji o użytkownikach w katalogach, które to można konfigurować. Pod warunkiem, że istnieje dostawca członkostwa ASP.NET 2.0 (i opcjonalny dostawca ról) odpowiadający magazynowi danych członków.

Dane uwierzytelniające dołączalnego dostawcy mogą być mieszane (hashed), szyfrowane lub przechowywane jako zwykły tekst. Jest to uzależnione od wartości węzłów odpowiadających danemu dostawcy członkowstwa, znajdujących się w pliku machine.config. Przy pracy z aplikacją MOSS można korzystać z kilku dostawców członkostwa. W tym z dostawcy członkostwa LDAP V3 (dostarczanego z aplikacją MOSS), a także z dostawcy członkostwa SQL Server™ oraz dostawcy członkostwa Active Directory® dostępnego łącznie z technologią ASP.NET 2.0.

Wybór dostawców członkostwa i ról nie ogranicza się jedynie do implementacji dostarczonych z aplikacją rozwiązań. Dzięki architekturze członkostwa oferowana przez ASP.NET 2.0 pozwala wykorzystywać takie magazyny członkostwa, jak bazy danych Microsoft Access™ czy Oracle, pliki XML lub nawet pliki tekstowe, pełniące rolę bazy danych. Wybrany dostawca usług uwierzytelniania dziedziczy interfejs ASP.NET MembershipProvider. Ten z kolei jest dziedziczony z klasy ProviderBase (schemat przedstawiono na rys. 1.).

Rys. 1. Hierarchia klas członkowstwa platformy .NET.

Uwierzytelnianie na podstawie technologii APS.NET 2.0 (w przeciwieństwie do Windows) ma pewne implikacje. Należy wziąć pod uwagę. Najistotniejsze dla wielu użytkowników jest ograniczenie interoperatywności klientów Microsoft Office. Wynika ono z tego, że usługa komunikacji sieciowej między aplikacją MOSS a klientami Office została pierwotnie zaprojektowana do współpracy z tożsamościami systemu Windows.

Ponadto pewne usługi aplikacji MOSS muszą używać konta Windows nawet przy korzystaniu z dołączalnego dostawcy. Przede wszystkim te związane z automatycznym przeszukiwaniem zawartości (crawling) i indeksowaniem. Gdy uwierzytelnianie nie odbywa się na podstawie tożsamości systemowych (Windows), konieczne jest stworzenie dodatkowej strefy. Umożliwi ona stosowanie uwierzytelniania Windows w aplikacji MOSS. (Strefy zostaną omówione w dalszej części tego artykułu.)

Jeśli narzucona jest infrastruktura kryptografii klucza publicznego oparta na tzw. kartach inteligentnych (smartcards), gdzie klucze publiczne lub certyfikaty ma klient, wymaga się, aby akceptowanie certyfikatów i uwierzytelnianie odbywało się na podstawie tożsamości w systemie Windows. Może to skutkować koniecznością stworzenia dodatkowej strefy MOSS lub wprowadzenia innych zmian w konfiguracji mechanizmu uwierzytelniania.

 Do początku strony

2. Uwierzytelnianie na podstawie formularzy i pojedyncze logowanie (Web Single Sign-On)

Innym interesującym mechanizmem dostępnym w aplikacji MOSS 2007 jest oparta na formularzach autetnyfikacja na bazie technologii ASP.NET 2.0. W poprzednich wersjach aplikacji SharePoint była ona osiągalna tylko za pomocą własnego rozszerzenia interfejsu Internet Server Application Programming Interface (ISAPI) lub rozszerzenia interfejsu ISAPI o nazwie CustomAuth, pochodzącego z zestawu narzędzi dla „Internetowych usług informacyjnych” (IIS 6.0). Jednak nadal konieczne jest powiązanie konta z tożsamością Windows. Mimo istnienia tych rozwiązań dla aplikacji SharePoint. Co jest przeszkodą dla wdrożeń opartych na parametrach.

Oparty na formularzach mechanizm uwierzytelniania dla aplikacji MOSS działa na podstawie dołączalnych dostawców ról i usług uwierzytelniania, aby możliwe było wykorzystanie internetowych rozwiązań w zakresie bezpieczeństwa. Rozwiązania te nie narzucają klientom staromodnego terminalu logowania, jaki znamy z systemów z rodziny NT.

Zamiast terminalu można stworzyć własny proces logowania dopasowany do potrzeb klientów. Bezpieczeństwo procesu uwierzytelniania zapewniają dodatkowo zabezpieczone przed fałszowaniem i szyfrowane ciasteczka (cookies) i bilety (tickets).

Dostawca usługi identyfikacji formularza nie musi rezydować lokalnie. Może być dołączony do zewnętrznego systemu zarządzania tożsamością, który byłby odpowiedzialny za walidację autentyczności użytkownika. Taka funkcjonalność nazywana jest „pojedynczym logowaniem” (Web single sign-on). Do zewnętrznej autentyfikacji wykorzystywany jest moduł HTTP. Umożliwia to łączenie tożsamości między organizacją a jej partnerami biznesowymi, przy którym partnerzy mogą używać własnych firmowych loginów do uwierzytelniania w aplikacji MOSS należącej do organizacji.

 Do początku strony

3. Szyfrowanie parametrów połączenia dla aplikacji MOSS

Umieszczanie istotnych informacji (dotyczących połączenia ze źródłem danych) w zwykłym pliku tekstowym web.config jest niewskazane. Stanowi to zagrożenie dla bezpieczeństwa. Ujawnienie tego typu informacji mogłoby umożliwić użytkownikowi stworzenie egzemplarza obiektu (object instance) do serwera baz danych SQL i manipulowanie cennymi danymi. Na szczęście, korzystając z dziedziczonej funkcjonalności technologii ASP.NET 2.0, można szyfrować dane. Jest to możliwe za pomocą dwóch metod: interfejsu Windows Data Protection API (DPAPI) lub algorytmu RSA.

Interfejs DPAPI bazuje na wbudowanym mechanizmie kryptograficznym dostępnym w systemie Windows. Służy do szyfrowania i deszyfrowania przy użyciu klucza przechowywanego na serwerze aplikacji MOSS. Szyfrowanie RSA pozwala wykorzystać algorytmy klucza publicznego. Wymaga to jednak stosowania odpowiednich „pojemników” (containers) na klucze szyfrujące.

Dla aplikacji MOSS 2007 – konkretnie dla dołączalnego dostawcy uwierzytelniania w technologii ASP.NET 2.0/SQL Server – najodpowiedniejsze jest szyfrowanie węzła <connectionStrings> (utworzenie tzw. szyfrogramu). Ponieważ zachodzi tu największe prawdopodobieństwo powstania zagrożenia dla bezpieczeństwa:

<connectionStrings>

<add name="MembershipConnectionString" 

     connectionString="connectionString"/>

</connectionStrings>

Szyfrowanie przy wykorzystaniu interfejsu DPAPI jest relatywnie nieskomplikowane i najłatwiejsze w implementowaniu. Bazuje ono bowiem na kluczu szyfrującym na serwerze macierzystym dla wirtualnego lub fizycznego katalogu. Programiści mogą stosować różne sposoby, natomiast użycie następujących poleceń (w wierszu polecenia) będzie najmniej uciążliwym sposobem:

aspnet_regiis.exe -pe sekcja -app katalog_wirtualny_MOSS -prov dostawca



aspnet_regiis.exe -pef sekcja katalog_fizyczny_MOSS -prov dostawca

Jako że interesuje nas zastosowanie szyfrowania dla węzła parametrów połączenia (connection strings node), wystarczające będzie zaszyfrowanie tylko specyficznej sekcji przez sprecyzowanie w poleceniu parametru „sekcja”:

aspnet_regiis.exe -pef "connectionStrings" "C:\Inetpub\wwwroot\WssVirtual " -prov "Dostawca"



aspnet_regiis.exe -pe "connectionStrings" -app "/MOSSAppinstance" -prov "Dostawca"

Po zaimplementowaniu, węzły „wrażliwych” informacji zostaną zastąpione wartościami cyfrowymi uporządkowanymi w formacie XML:

<connectionStrings confiProtectionProvider=

"DostawcaSzyfrowania">

<EncryptedData>

<CipherData>

<CipherValue>XXXXXXXXXXXXXXXXXXXXXXXXXXXXX

</CipherValue>

<CipherData>

</EncryptedData>

</connectionStrings>

Zgodnie z koncepcją modularnej architektury aplikacji MOSS, model ten jest dołączalny. Oznacza to, że można utworzyć własnych dostawców usług w celu zarządzania szyfrogramami dla określonych plików konfiguracyjnych aplikacji MOSS, np. web.config, machine.config. Ponadto wybór metody szyfrowania nie ogranicza się do RSA i DPAPI.

Przeprowadzenie szyfrowania ma określone implikacje. Wykorzystując klucz szyfrujący lokalnie, tj. na danej maszynie, można korzystać z węzła konfiguracyjnego jedynie na serwerze MOSS, na którym został on stworzony. Inaczej proces deszyfrowania nie powiedzie się. Gdyby intruz uzyskał dostęp do serwera, mógłby pozyskać klucz danej maszyny i rozszyfrować parametry połączenia. Konsekwencją procesu deszyfrowania jest z kolei pewien niekorzystny (choć nieznaczny) wpływ na szybkość działania aplikacji.

 Do początku strony

4. Mapowanie stref i adresów dostępu

Mapowanie różnych adresów dostępu (Alternate Access Mapping) jest bardzo przydatne. Zwłaszcza wtedy, gdy zachodzi konieczność ustawienia więcej niż jednego punktu dostępowego dla środowiska aplikacji SharePoint. Mapowanie AAM po prostu umożliwia określenie różnych adresów URL, pod którymi użytkownicy mogą znaleźć fizyczną stronę (zasady jego działania zaprezentowano na diagramie –patrz rys. 2.).

Dzięki mapowaniu AAM, użytkownicy, korzystający z różnych dostawców usług uwierzytelniania i z różnych polityk bezpieczeństwa sieci Web, mogą być kierowani na tę samą fizyczną ścieżkę do strony aplikacji MOSS. Ponadto funkcjonalność AAM zastępuje inne mechanizmy przekierowania adresów URL (np. możliwa jest konfiguracja dla wielu domen i obsługa tak zwanego „zwrotnego proxy”).

Wykorzystywany przez aplikacje MOSS adres URL jest domyślnie mapowany. Natomiast architekt SharePoint może poszerzyć zakres tego mapowania przez utworzenie dodatkowych adresów dla różnych metod dostępu do aplikacji. Stosowanie mapowania AAM gwarantuje, że przekierowania z odpowiednich wewnętrznych i publicznych adresów URL będą działały poprawnie.

Rys. 2. Mapowanie adresów URL i stref (Kliknij obraz, aby zobaczyć go w powiększeniu).

1. Wewnętrzni użytkownicy

   http://contoso

   http://MOSS

2. Zewnętrzni użytkownicy

   http://ekstranet.contoso.com

3. Mapowanie AAM

   Strefa intranetowa

   Strefa ekstranetowa

4. Strona aplikacji MOSS

W aplikacji MOSS strefy są nowością. Pozwalają uzyskać większą kontrolę nad mapowaniem oferowanym przez mechanizm AAM. Wykorzystując strefy, można mapować różnych dostawców usług uwierzytelniania dla jednej fizycznej ścieżki i lokalizacji zawartości aplikacji MOSS. Jest to możliwe w zależności od ustawień mapowania AAM, na podstawie których użytkownicy zostają przekierowani. Przy określaniu adresów URL na potrzeby mapowania AAM nie jest wymagane, aby strefy były związanie z jakimś mechanizmem uwierzytelniania. Ale jest to zalecane. Przy mapowaniu adresów URL (na podstawie funkcji AAM) do strefy, która nie została określona na stronie dostawcy usług uwierzytelniania, wykorzystane zostaną ustawienia bezpieczeństwa dla strefy domyślnej.

Strefy wymagają pewnego planowania, gdyż mają one znaczący wpływ na to, jak portal kieruje i uwierzytelnia ludzi korzystających z różnych punktów dostępu (adresów URL). Rozszerzając zakres nowej aplikacji internetowej można określić w ustawieniach strefę, z której chce się korzystać. Wyboru można dokonać w sekcji Load Balancing URL (przedstawionej na rys. 3.). Zalecane jest umieszczenie najbardziej dostępnego publicznie adresu URL (np. adresu dostępnego z sieci Internet) w strefie domyślnej (Default). Ponieważ to ten adres będzie wykorzystywany przez aplikację SharePoint w przypadku, gdy nie uda się ustalić, w jakiej strefie jest użytkownik.

Rys. 3. Konfigurowanie stref dla aplikacji MOSS (Kliknij obraz, aby zobaczyć go w powiększeniu).

Każdą strefę można powiązać z globalną polityką bezpieczeństwa aplikacji internetowej, określającą ustawienia uprawnień dla użytkowników w danej strefie. Pozwala to modyfikować uprawnienia o szerokim zasięgu w ramach centralnego zarządzania.

Aplikacje internetowe zwykle składają się z wielu stron pogrupowanych w różne kolekcje. Przez to zarządzanie uprawnieniami dla tych stron może stać się problematyczne. Zwłaszcza w przypadku, gdy aplikacje te stają się z czasem coraz większe i bardziej złożone.

Aplikacja MOSS 2007 umożliwia stosowanie globalnych zasad ujednolicających ustawienia polityki bezpieczeństwa dla określonego użytkownika lub grupy w ramach aplikacji.

Na przykład: pełen dostęp, prawo do odczytu, dostęp bez pozwolenia na zapisywanie, brak dostępu. Zasady te mogą zawiesić (przesłonić) działanie elementarnych ustawień uprawnień w aplikacji MOSS oraz ustawień zarządzanych z centralnego interfejsu administracyjnego aplikacji SharePoint. Dlatego wszelkie zmiany w konfiguracji należy wprowadzać rozważnie.

Rekapitulując, strona internetowa może mieć, na przykład, dwa adresy URL (określone w ustawieniach mapowania AAM): jeden dla użytkowników z firmy, drugi dla użytkowników zewnętrznych. Dwa unikalne adresy URL prowadzą do tej samej zawartości. Np. contoso dla użytkowników wewnątrz firmy i ekstranet.contoso.com dla zaufanych partnerów z zewnątrz. Każdy użytkownik ma dostęp do strony przez swoją strefę, korzystając z własnego dostawcy usług uwierzytelniania i własnej polityki bezpieczeństwa aplikacji.

Skonfigurowanie strefy intranetowej dla wewnętrznego adresu URL pozwala użytkownikom uzyskiwać tożsamości systemowe Windows na podstawie uwierzytelniania w domenie. Zewnętrzni partnerzy natomiast mają do dyspozycji mechanizm pojedynczego logowania przez strefę ekstranetową. Mogą, dzięki temu, korzystać z danych uwierzytelniających odpowiednich dla ich własnych organizacji. Dzięki powiązaniu polityki bezpieczeństwa aplikacji internetowej ze strefami, możliwe staje się nadanie wszystkim zaufanym użytkownikom zewnętrznym prawa do odczytu, bez potrzeby ręcznego ustawiania tych uprawnień dla każdego obiektu oddzielnie.

 Do początku strony

5. Sprecyzowana zawartość dla osiągnięcia bezpieczniej współpracy

Poprzez zamknięcie części plików należących do strony w kolekcjach plików za pomocą aplikacji SharePoin, użytkownicy będą mieli dostęp tylko do informacji, do których przeglądania będą upoważnieni. Nowe elastyczne mechanizmy uprawnień pozwalają w większym stopniu kontrolować różne typy informacji biznesowych, jakie są przechowywane w środowisku aplikacji MOSS.

Aplikacja MOSS 2007 daje możliwość związania tożsamości z określonym obiektem. Np.: kolekcją stron internetowych, pojedynczą stroną, biblioteką dokumentów, podfolderem, listą, pojedynczym dokumentem lub pozycją z listy. Stosowanie tego rozwiązania jest jednoznaczne z narzuceniem pewnych ustawień na poziomie elementarnym i wyraźnym określeniem przynależności do danej pozycji. Jednocześnie modyfikując interfejs użytkownika w ten sposób, że nie będzie on wiedział o istnieniu pozycji, do których przeglądania nie ma uprawnień. W aplikacji MOSS funkcjonalność ta to tzw. bezpieczeństwo na poziomie pozycji (Item Level Security, w skrócie – ILS), określane też mianem „zabezpieczonych obiektów” (Secured Objects).

Uprawnienia do obiektów w aplikacji MOSS mają naturę hierarchiczną. Umożliwia to poszerzanie ich zasięgu od pojedynczych obiektów, takich, jak: pozycje z listy, do zbiorów, całe listy czy biblioteki dokumentów. Możliwe jest także dziedziczenie uprawnień obiektów macierzystych (wyższego poziomu) przez obiekty potomne (niższego poziomu). Istnieją ponad trzydzieści trzy domyślne uprawnienia, które można nadać użytkownikowi lub grupie SharePoint. Każde z takich uprawnień może być powiązane z jakimś obiektem. Nic nie stoi na przeszkodzie, aby również tworzyć nowe poziomy uprawnień.

Przykładowo w ramach strony do zarządzania projektem można nadać prawo dostępu do niektórych rozwijanych materiałów, przechowywanych w bibliotece dokumentów tylko projektantom i menedżerom projektów. Np.: specyfikacji projektów i technik kodowania, utworzonych w dokumentach programu Microsoft Word. Uprawnienia dla biblioteki są domyślnie dziedziczone z uprawnień strony, ale można je zmienić. Pozwalając w ten sposób na dostęp tylko projektantom lub menedżerom projektów lub aby każdy dokument programu Word był widoczny i dostępny jedynie dla odpowiedniego menedżera projektu lub konkretnego zespołu projektowego. Z kolei niewymagające dyskrecji materiały mogą być upublicznione albo na poziomie pozycji, albo folderu, albo biblioteki dokumentów.

Uprawnienia mogą być sprecyzowane w kontekście pozycji, takich, jak zdarzenia (np. terminy projektowe na liście zdarzeń). Można więc wprowadzić takie ustawienia, że tylko wybrani członkowie zobaczą określone zdarzenia. Ponadto funkcjonalność bezpieczeństwa na poziomie pozycji (ILS) obejmuje swym zasięgiem również wyszukiwanie, w ramach którego zwracane są jedynie obiekty (wyniki) odpowiednie dla kontekstu bezpieczeństwa, w jakim się znajduje osoba, która przeprowadza wyszukiwanie. Korzystając ze wszystkich tych ustawień można tak zawęzić interfejs określonego użytkownika, że pozostanie w nim jedynie przeznaczona dla tego użytkownika zawartość.

Architektura zarządzania uprawnieniami została w znacznym stopniu ulepszona w aplikacji MOSS 2007. Uprawnienia mogą być przyznawane zarówno grupom SharePoint i grupom domen, jak i na poziomie jednostek. Kilka grup jest od razu dostępnych, przede wszystkim Właściciele (którzy otrzymują pełną kontrolę), Goście (którzy mają prawo do współtworzenia) i Członkowie (którzy mają prawo do odczytu). Do tych domyślnie dostępnych grup lub do grup tworzonych i zarządzanych na poziomie kolekcji stron (mających różne własne poziomy uprawnień) można przypisać pojedyncze osoby lub grupy domen.

Na bazie ról można stworzyć grupy, takie jak „projektanci” czy „menedżerowie projektów”. Następnie można by przydzielić granularne uprawnienia, które na przykład pozwoliłyby projektantom umieszczać na serwerze odpowiednią dokumentację kodowania, nadać menedżerom projektów prawa do odczytu i zatwierdzania tych dokumentów. Zasady członkostwa grupy pozostają niezmienne dla kolekcji stron, aby tworzone grupy mogły być wielokrotnie wykorzystywane w różnych innych stronach projektu.

 Do początku strony

6. Integracja z dołączalną usługą pojedynczego logowania

W typowym środowisku komputerowym użytkownik ma dostęp do dowolnej ilości aplikacji z ich własnymi kryteriami uwierzytelniania. Prowadzi to do różnego typu problemów związanych z bezpieczeństwem i do nadmiaru haseł do zapamiętania. W aplikacji MOSS usługa SSO pomaga złagodzić uciążliwość wielokrotnego uwierzytelniania, dzięki zastosowaniu szyfrowanej wewnętrznej pamięci podręcznej dla danych uwierzytelniających użytkownika. Ułatwia to pozyskiwanie istotnych dla działania firmy informacji, w celu wyświetlenia ich przy użyciu mechanizmów aplikacji MOSS, takich jak katalogowanie danych z systemów biznesowych (Business Data Catalog) czy wyświetlanie danych ze źródeł zewnętrznych w ramach technologii portalowej (SharePoint DataView Web Parts).

Dostawca usługi pojedynczego logowania dla aplikacji MOSS – podobnie jak kilka innych omawianych funkcji architektury aplikacji – jest dołączalny. Poza dostawcami domyślnymi dla aplikacji MOSS (SpsSsoProvider) dostępni są także inni dostawcy SSO, ale należy ich najpierw zdefiniować. Na razie możliwe jest tylko ustanowienie jednego dostawcy SSO na system biznesowy (zarejestrowanie go w ramach środowiska aplikacji).

 Do początku strony

7. Zarządzanie prawami do informacji (IRM)

Ochrona informacji na poziomie klienta – nawet jeśli informacje biznesowe są udostępniane offline – jest jednym z głównych obszarów zainteresowania firm mających do czynienia z poufnymi danymi. Zwłaszcza tymi, których dotyczą regulacje prawne, takie, jak ustawy: California Senate Bill No. 1386, Sarbanes-Oxley (w skrócie – SOX) i Health Insurance Portability and Accountability Act (HIPAA). Zarządzanie prawami do informacji (IRM) po stronie serwera zostało zintegrowane z repozytoriami aplikacji MOSS. Dzięki temu powstało jednolite rozwiązanie zbudowane na platformie Windows Rights Management (WRM).

Zarządzanie IRM umożliwia uzyskanie precyzyjnej kontroli nad danymi biznesowymi przez narzucenie ograniczeń dostępu na poziomie dokumentu. Niezależnie od tego, gdzie dany dokument jest przechowywany i kto próbuje go otworzyć. Dzięki powszechnej implementacji zarządzania prawami do informacji można zezwolić na tylko autoryzowane przeglądanie i drukowanie. Ale jest to rozwiązanie, które można również zastosować w innych scenariuszach, takich jak: wymóg weryfikacji danych uwierzytelniających (użytkownika) po upływie jakiegoś czasu, zakaz wysyłania na serwer zasobów nieobjętych zarządzaniem prawami do informacji, znacznik zmieniający po upływie terminu ważności restrykcyjna politykę, powiązanie z globalną polityką organizacji w zakresie przyznawania uprawnień (w ramach zarządzania IRM).

Funkcjonalność IRM zapewnia tzw. obrońca (protector), a konkretnie kilku „obrońców” instalowanych z aplikacją MOSS 2007. Są to aplikacje zarządzające procesem szyfrowania danego typu pliku; zwykle wszystkie pliki przechowywane w ramach aplikacji MOSS mają już wyznaczonych obrońców. Pliki systemu Microsoft Office i pliki w formacie OpenXML mają zapewnioną macierzystą obsługę. Ponieważ architektura aplikacji MOSS jest rozszerzalna, podobnie jak w przypadku dostawców usług uwierzytelniania, można wprowadzać własnych obrońców dla innych typów plików.

Pierwszym krokiem przy implementowaniu zarządzania prawami do informacji (IRM) powinno być zapewnienie zgodności z wszystkimi wymaganiami w środowisku aplikacji MOSS. Potrzebne do tego będzie zainstalowanie klienta usług WRM na każdym zewnętrznym (front-end) serwerze sieci Web. Oprócz tego usługi RMS (Microsoft Rights Management Services) muszą mieć łączność z zewnętrznymi serwerami MOSS dla sieci Web. W kolejnym kroku należy zdefiniować za pośrednictwem strony SharePoint Central Administration serwer usług RMS, który aplikacja MOSS mogłaby asymilować. Można wykonać to zadanie, korzystając z ustawień domyślnych w usługach katalogowych Active Directory lub podając lokalizację.

W celu utrzymywania uprawnień zarządzanie IRM dostępne jest bezpośrednio ze struktur magazynowania danych, takich jak biblioteki dokumentów. Gdy użytkownik przechodzi do objętej zarządzaniem IRM biblioteki dokumentów i próbuje pobrać dokument, aplikacja MOSS wiąże uprawnienia skonfigurowane dla biblioteki dokumentów z tym dokumentem (schemat tego procesu przedstawiono na rys. 4.). W rezultacie powstaje mapowanie 1:1 między uprawnieniami dokumentu i aplikacji MOSS. Inaczej mówiąc dochodzi do tłumaczenia związanych z danym dokumentem ról aplikacji SharePoint na poziomy uprawnień IRM dla samego dokumentu.

Rys. 4. Przenoszenie uprawnień (IRM) z biblioteki dokumentów (Kliknij obraz, aby zobaczyć go w powiększeniu).

1. Użytkownik pobiera dokumenty;
2. Dopasowanie roli do biblioteki dokumentów;
3. Dokument zaszyfrowany; licencja emisyjna dodana;
4. Uprawnienia przeniesione lokalnie offline.

Dokument jest szyfrowany lokalnie na potrzeby ochrony offline i utrzymywany w tym stanie do czasu ponownego umieszczenia go w bibliotece dokumentów. Po wysłaniu na serwer dokument jest przechowywany w niezaszyfrowanej formie, aby możliwe było zindeksowanie jego zawartości na potrzeby aplikacji SharePoint. Inaczej mówiąc, w celu udostępnienia wyszukiwania pełno tekstowego, choć żadne konto użytkownika nie będzie miało bezpośredniego dostępu do tej zawartości w formie niezaszyfrowanej.

Aplikacja MOSS 2007 oferuje kilka nowych funkcji, które mogą pomóc w implementacji efektywnych zasad bezpieczeństwa bez zwiększania kosztów związanych zarządzaniem. Co więcej, funkcje te są bardzo elastyczne, dzięki czemu można tak spersonalizować pewne ustawienia, aby użytkownicy mieli dostęp wyłącznie do informacji, które są im niezbędne. Na pasku bocznym „A SQL Server Authentication Provider” zamieszczono prosty przykład.

Do początku strony