Rozdział 23 Współistnienie i migracja ze środowisk innych producentów


Cel nr 1: udostępnienie pojedynczego podpisu



Pobieranie 134.08 Kb.
Strona2/3
Data02.05.2016
Rozmiar134.08 Kb.
1   2   3

Cel nr 1: udostępnienie pojedynczego podpisu


Jak uprzednio wspomniano, pojedynczy podpis (SSO – Single Sign-On) to zdolność użytkowników do jednokrotnego uwierzytelnienia się (dowodzenia swojej tożsamości) dla wszystkich usług dostępnych w sieci.

Każde przedsiębiorstwo korzystające z systemów komputerowych może zyskać na posiadaniu zdolności SSO:



  • Użytkownicy są bardziej produktywni, jeśli usunie się przeszkody pomiędzy nimi i zasobami, z których mają prawo korzystać.

  • Sieci mogą być zarządzane przez mniejszą liczbę administratorów dzięki konsolidacji informacji sieciowych.

  • Bezpieczeństwo sieci jest zwiększone dzięki bezpiecznym protokołom uwierzytelniania i eliminacji najczęściej występującego zagrożenia bezpieczeństwa sieci: zapisywania haseł przez użytkowników.

Chociaż pojedynczy podpis potencjalnie może przynieść duże korzyści wszystkim zaangażowanym stronom, jednak nigdy nie był w pełni zaimplementowany, z wyjątkiem kilku przedsiębiorstw, które skonsolidowały się z pomocą jakiegoś produktu SSO klasy mainframe, jak np. Resource Access Control Facility (RACF) firmy IBM, lub CA – Top Secret firmy Computer Associates.

Pełna zdolność do SSO jest już obsługiwana w jednorodnym środowisku Microsoftu (patrz rysunek 23.2), składającym się wyłącznie z systemów Windows 2000 Server i Professional oraz większości aplikacji BackOffice (inaczej .NET Enterprise Servers). Jednakże nie powinno to zaskakiwać, gdy wiemy o ścisłej integracji dostępnej już we wcześniejszych aplikacjach serwerowych Microsoftu i systemie operacyjnym Windows NT 4 Server.

Rysunek 23.2

Aby uzyskać dostęp do zestawu wszystkich aplikacji serwerowych Microsoftu będzie oczywiście potrzebne tylko jedno logowanie



Client

Klient

File and Print Services

Usługi plikowe i drukowania

Remote Access

Dostęp zdalny

Other App

Inna aplikacja

Znacznie ważniejsze powinny być zamierzenia Microsoftu dotyczące wprowadzenia SSO w sieciach składających się z platform różnych producentów. Elastyczność ta ma być osiągnięta przez obsługę opartych na standardach protokołów uwierzytelniania, oraz za pomocą służących do połączeń między systemami produktów Microsoftu, dostosowanych do opcji i wyzwań większości najpopularniejszych platform systemowych innych producentów.

Mówiąc dokładniej, Windows 2000 Server z Active Directory udostępnia oparty na standardach pojedynczy podpis w sieciach niejednorodnych, dzięki wbudowanej implementacji protokołów Kerberos i SSL. Lecz znowu jest to tylko fragment całego obrazu: jak wspomniano w poprzednim podrozdziale, ostatecznym celem Microsoftu jest uczynienie z Active Directory najlepszego narzędzia wybieranego do roli punktu wymiany w dużych, wieloplatformowych środowiskach. Wobec tego Microsoft dąży do scenariusza w niedalekiej przyszłości, w którym cała linia produktów Microsoftu nie tylko pozwoli klientom typu przedsiębiorstw rozszerzyć korzyści z SSO na całą swoją sieć, lecz również pozwoli ustanowić Active Directory jako jedną z najlepszych platform pośredniczących za pomocą MMS pomiędzy zasadniczo odmiennymi systemami. Ponownie omawiając swoje wsparcie dla obsługi SSO w sieciach mieszanych Microsoft zakłada, iż usługa Active Directory będzie obecna i używana w centrum firmy (patrz rysunek 23.3).

Rysunek 23.3

Microsoft w ten sposób wyobraża sobie udostępnienie pojedynczego podpisu (Single Sign-On) we współpracy z innymi systemami operacyjnymi



Via (Kerberos, NTLM...)

Przez (Kerberos, NTLM...)

Multiple vendors

Klienty WWW różnych producentów

SSO za pomocą Kerberosa


Protokół Kerberos opiera się na idei biletów — pakietów zaszyfrowanych danych, wydawanych przez zaufany autorytet o nazwie Centrum dystrybucji kluczy (KDC – Key Distribution Center). Bilet poręcza za tożsamość użytkownika i przenosi inne informacje (jak np. dane zabezpieczeń). KDC dostarcza bilety wszystkim użytkownikom w swoim obszarze pełnomocnictw (obszar — realm — jest poprawnym terminem Kerberosa). W systemie Windows 2000 Server każdy DC Active Directory jest KDC i każda domena stanowi jeden obszar.

Działanie protokołu Kerberos jest proste, jak widać z rysunku 23.4. Podczas logowania użytkownik uwierzytelnia się w KDC, które dostarcza użytkownikowi początkowy bilet (tzw. bilet przyznający bilety, TGT – Ticket Granting Ticket). Gdy użytkownik chce skontaktować się z zasobem sieciowym, jego sesja użytkownika przedstawia TGT w DC i żąda biletu dla określonego zasobu (ST – Service Ticket). Użytkownik prezentuje ST zasobowi, który wówczas zezwala użytkownikowi na dostęp.

Zastosowana przez Microsoft implementacja protokołu Kerberos w Windows 2000 jest w pełni zgodna ze specyfikacją Internet Engineering Task Force (IETF) dla Kerberosa v5 (RFC 1510). To z kolei pozwala domenom Active Directory współpracować bezpośrednio ze zgodnymi ze standardami implementacjami Kerberosa innych firm (jak np. TrustBroker firmy CyberSafe), pozwalając przez to na SSO pomiędzy Windows 2000 Server i sieciach wielu producentów, używających systemów operacyjnych MacOS, AIX, Digital Unix, HP-UX, IRIX, NetWare, Solaris, SunOS, Tandem i MVS/ESA (Multiple Virtual Storage/Enterprise System Architecture), pod warunkiem że również implementują obsługę Kerberosa w wersji 5.

Rysunek 23.4

Podstawowe działanie protokołu Kerberos – uwierzytelnianie użytkowników

1. Sends TGT ...

1. Wysłanie TGT i żądanie od KDC biletu sesji do docelowego serwera

2. Present session ticket...

2. Prezentacja biletu sesji podczas konfiguracji połączenia

3. Verifies session...

3. Serwer weryfikuje bilet sesji wydany przez KDC

Application Server

Serwer aplikacji (docelowy)

Key Distribution Center (KDC)

Centrum dystrybucji kluczy (KDC)

Client

Klient

Windows 2000 DC

Kontroler domeny Windows 2000

Wskazówka

Dla współpracy Kerberosa dostępne są jedynie typy szyfrowania DES-CBC-MD5 i DES-CBC-CRC, zaś najbardziej powszechnym błędem w tej współpracy jest asymetria zegarów (uwierzytelnianie między obszarami Kerberosa może powieść się jedynie przy dokładnej synchronizacji zegarów systemowych — dopuszczalna jest różnica dwóch minut). Więcej informacji o funkcjonowaniu Kerberosa Czytelnik może znaleźć w rozdziale 14.

Ustanowienie relacji zaufania między Windows 2000 Server i innymi platformami za pomocą Kerberosa jest całkiem proste. Administrator tworzy relację zaufania pomiędzy KDC w różnych obszarach i dla odnośników pomiędzy obszarami udostępnione zostają bilety. Administrator Windows 2000 Server tworzy konto użytkownika, na które odwzorowani będą użytkownicy z drugiego systemu. Po dokonaniu tego prawa i przywileje zewnętrznych użytkowników są zarządzane przez konta użytkowników Active Directory, za pomocą tych samych narzędzi administracyjnych, które stosowane są dla macierzystych użytkowników Active Directory.

Odnośniki pomiędzy obszarami w środowisku niejednorodnym są podobne jak w jednorodnych sieciach Windows 2000 Server (zwane również zaufaniami – trusts). Gdy użytkownik w drugim systemie potrzebuje dostępu do zasobu sieciowego w domenie Windows 2000 Server, jego sesja użytkownika żąda biletu do zasobu. KDC, widząc że zasób mieści się w domenie Active Directory, odsyła użytkownika do DC Active Directory i poręcza za tożsamość użytkownika. DC Active Directory następnie przypisuje tożsamość użytkownika do odpowiadającego mu konta i wydaje użytkownikowi bilet, który ten następnie przedstawia w zasobie. Dla użytkowników Windows 2000 Server, którzy chcą skorzystać z zasobu w innym systemie, proces zachodzi w odwrotnej kolejności, aczkolwiek procedury administracyjne używane w drugim systemie mogą być różne.

Praca w niejednorodnym środowisku powoduje nieuniknioną utratę prostoty zarządzania, ponieważ pewne czynności administracyjne, które zachodziły w Windows 2000 Server w sposób niewidoczny, muszą być wykonane ręcznie przy łączeniu z sieciami niejednorodnymi. Na przykład, w przeciwieństwie do Windows 2000 Server, przy nawiązaniu zaufania w środowisku niejednorodnym administrator musi ręcznie synchronizować klucze pomiędzy DC Active Directory i KDC drugiego systemu. Podobnie, administrator traci korzyści z posiadania pojedynczego zestawu narzędzi administracyjnych i pojedynczego magazynu danych związanych z SSO. Zamiast tego, w najlepszym przypadku pojedynczy zestaw narzędzi i pojedynczy magazyn informacji związanych z SSO istnieje dla każdej platformy. Jednakże zdolność do bezpośredniego udostępniania zasobów stanowi oczywiście zysk dla klientów firmy i często jest warta dodatkowych nakładów pracy administracyjnej.


SSO za pomocą kluczy publicznych


Obecnie nie wszyscy użytkownicy komputerów przedsiębiorstwa korzystają z wewnętrznych połączeń w celu dostępu do sieci. Dzisiejsze środowiska komputerowe firm muszą w coraz większym stopniu obsługiwać użytkowników, którzy łączą się z siecią przedsiębiorstwa przez sieć publiczną (najczęściej Internet). Odpowiedzią SSO Microsoftu na te potrzeby jest protokół zabezpieczeń SSL (Secure Sockets Layer).

SSL jest w stanie używać cyfrowych certyfikatów jako podstawy uwierzytelniania. Zdecydowanie zalecam użycie tej opcji, ponieważ cyfrowy certyfikat jest obecnie jedynym stosunkowo bezpiecznym i opierającym się na standardach dostępnym dowodem tożsamości. Certyfikat cyfrowy to zabezpieczony przed manipulacjami pakiet danych wydany przez Urząd certyfikacji (CA – Certificate Authority). CA udostępnia klucz publiczny i poręcza za fakt, iż wymieniona osoba lub serwer jest właścicielem klucza publicznego. W trybie używanym przez SSO klient i serwer WWW wymieniają certyfikaty, a następnie używają zawartych w nich kluczy publicznych do wymiany informacji, jak np. kluczy szyfrujących sesji. Pozwala to uwierzytelnić obu użytkowników, ponieważ jeśli którykolwiek z nich nie jest faktyczną tożsamością wymienioną w przedstawionym przez siebie certyfikacie, wówczas nie będzie w stanie odszyfrować danych wysłanych przez drugą stronę.

Wszystkie składniki potrzebne aby udostępnić SSO za pomocą SSL są zawarte w systemie Windows 2000 Server i w pełni zintegrowane z architekturą zabezpieczeń Windows 2000 Server. Do zarządzania cyfrowymi certyfikatami służy infrastruktura kluczy publicznych Windows 2000 Server (PKI – Public Key Infrastructure), która zawiera dwa składniki:


  • Usługi certyfikatów — pozwalają administratorom wydawać i wycofywać certyfikaty.

  • Active Directory — udostępnia położenie CA i informacje o zasadach, oraz umożliwia publikację informacji o wycofanych certyfikatach.

Bazujący na SSL pojedynczy podpis Microsoftu jest w pełni znormalizowany, więc powinien współpracować z innymi produktami zgodnymi ze standardem. Obsługuje on SSL v3, najpowszechniej używaną wersję protokołu SSL, która została zgłoszona do IETF pod nazwą protokołu Transport Level Security (TLS). Microsoft Internet Explorer, Netscape Communicator i większość pozostałych przeglądarek WWW obsługuje ten standard i aktywnie wspiera przyjęcie TLS przez IETF.

PKI systemu Windows 2000 Server obsługuje certyfikaty cyfrowe używające standardu ISO X.509 v3, który jest niemal powszechnym standardem certyfikatów cyfrowych. Pozwala, na przykład, systemowi Windows 2000 Server korzystać z certyfikatów cyfrowych wydanych przez VeriSign, Thawte, BelSign i większość dobrze znanych CA.


Wiele innych zastosowań kluczy publicznych

SSL reprezentuje jedynie jeden z możliwych scenariuszy wykorzystania cyfrowych certyfikatów. Na przykład, Windows 2000 pozwala obecnie na logowanie za pomocą kart inteligentnych (Smart Card) zawierających certyfikat cyfrowy X.509 v3; certyfikaty cyfrowe mogą być użyte do tworzenia w łączach nie zabezpieczonych tuneli pomiędzy bezpiecznymi sieciami za pomocą protokołów L2TP/PPTP (Layer 2 Tunneling Protocol/Point-to-Point Tunneling Protocol) i (lub) IP Security (IPSec).

PPTP jest rozwiązaniem własnym Microsoftu, podczas gdy L2TP i IPSEC przeszły przez IETF. L2TP stanowi połączenie własnych technologii PPTP Microsoftu i L2F (Layer 2 Forwarding) firmy Cisco. Jak można się spodziewać, protokół L2TP jest intensywnie wspierany przez Microsoft i Cisco, podczas gdy reszta rynku jest nieco mniej skłonna do zastosowania L2TP — lecz wygląda na to, że większość firm jest obecnie w trakcie dodawania obsługi L2TP.



Administratorzy dysponują znaczącą elastycznością w konfigurowaniu użycia danych zabezpieczeń PKI w sieci na potrzeby własnych firm. Na przykład, poniższe decyzje to zaledwie kilka z możliwych:

  • Ustalić poprzez Internetowe usługi informacyjne (IIS), do czego dany certyfikat może być wykorzystany. Na przykład, certyfikaty mogą służyć jedynie do uwierzytelniania w serwerze WWW, lub służyć jako podstawa pełnego logowania w sieci.

  • Skojarzyć poszczególne certyfikaty z poszczególnymi kontami użytkowników lub ustalić, iż wszystkie certyfikaty pochodzące z określonego CA przypisane są do pojedynczego konta użytkownika Active Directory.

  • Pozwolić na użycie w firmie certyfikatów wydawanych przez zewnętrzny CA lub przez CA oparty na Windows 2000 w firmie.

Kontrolą dostępu można zarządzać łatwo i wydajnie ponieważ, mimo iż certyfikaty cyfrowe służą do początkowego uwierzytelnienia użytkownika, punktem kontrolnym dostępu do zasobów sieciowych pozostaje konto użytkownika. Po uwierzytelnieniu użytkownika Active Directory przypisuje certyfikat do odpowiedniego konta użytkownika i używa zwykłych poświadczeń zabezpieczeń użytkownika by ustalić, czy użytkownik ten ma prawo dostępu do określonych zasobów sieciowych. Eliminuje to potrzebę synchronizacji wielu kopii przywilejów użytkownika.

Bezpieczeństwo sesji jest całkiem wysokie, ponieważ szyfrowanie jest częścią implementacji protokołu SSL. Pozwala to określić w przedsiębiorstwie preferowany poziom szyfrowania dla dostępu do sieci przez WWW i ustalać ten poziom na początku sesji. Implementacja SSL w Windows 2000 Server istnieje w dwóch wersjach z powodu praw eksportowych USA: wersji na Amerykę Północną (128-bitowa) i wersji międzynarodowej (56-bitowej) do użytku poza Ameryką Północną. Wersja północnoamerykańska udostępnia 40-bitowe i 128-bitowe wersje kryptoalgorytmów RC2 i RC4; 512-, 768- i 1024-bitowe wersje RSA oraz 56-bitowe szyfrowanie DES (Data Encryption Standard). Wersja międzynarodowa udostępnia 40-bitowe RC2 i RC4 oraz 512-bitowe szyfrowanie RSA. Z powodu złagodzenia praw eksportowych USA, pozwalających obecnie wszystkim za wyjątkiem kilku krajów objętych embargiem na dostęp do szyfrowania na poziomie komercyjnym, większość firm może obecnie przejść do wersji północnoamerykańskiej przez uzyskanie (lub pobranie z WWW) Windows 2000 High Encryption Pack od Microsoftu.


SSO za pomocą Host Integration Server


Jeśli nie dysponujemy żadnym sposobem dosięgnięcia zamierzonych klientów za pomocą protokołów SSL lub Kerberos, w ostateczności możemy posłużyć się Microsoft Host Integration Server 2000 (dawniej znanym pod nazwą SNA Server). Podobnie jak jego poprzednik, Host Integration Server 2000 pracuje w połączeniu z niektórymi z wiodących protokołów zabezpieczeń hostów, zaimplementowanych przez RACF, ACF2 i CA-Top Secret, aby udostępnić SSO pomiędzy sieciami bazującymi na Windows NT Server i Windows 2000 Server a środowiskami komputerów głównych MVS/ESA.

W przypadku SNA Server, pojedynczy podpis w systemie zabezpieczeń MVS był uzyskiwany przez zainstalowanie własnego rozwiązania SecurPass firmy Proginet w odpowiednich komputerach głównych, ponieważ SNA Server był dostarczany razem z SecurPass firmy Proginet i te dwa produkty współpracowały ze sobą w duecie. Dla synchronizacji haseł z AS/400 trzeba było zwrócić się do firmy Open Universal Software, która sprzedaje dostawcę zabezpieczeń niezbędnego do obsługi OS/400 V2R3 i starszych.

SecurPass udostępnia usługi synchronizacji haseł, które zapewniają identyczność poświadczeń zabezpieczeń użytkownika w obu systemach (czyli synchronizację dwukierunkową haseł). SecurPass wykonuje również uzgadnianie haseł (password harmonization) — przy zmianie hasła użytkownika w jednym systemie, sprawdzane jest z regułami haseł w obu systemach przed akceptacją. Zapewnia to wybór do roli ogólnych zasad haseł zasad silniejszych z pary Windows NT i IBM, oraz zabezpiecza przed zagrożeniem jednego systemu przez słabe hasła z drugiego.

Taka synchronizacja haseł pozwala SNA Server dokonywać wypełniania haseł — to znaczy, gdy dostawca zabezpieczeń systemu mainframe żąda uwierzytelnienia, SNA Server dostarcza hasło użytkownika Windows NT (które jest dzięki synchronizacji identyczne z hasłem użytkownika w systemie mainframe) przez automatyczne logowanie 3270 lub 5250.

W systemie Host Integration Server 2000 Microsoft zdecydował się zaimplementować własne SSO (przez co program SecurPass stał się zbędny) dla systemów zabezpieczeń komputerów głównych RACF, ACF/2 i Top Secret. Jednakże Host Integration Server 2000 pozwala jedynie na prostą jednokierunkową synchronizację haseł z Active Directory do środowiska komputera głównego. Aby uzyskać dwukierunkową synchronizację haseł trzeba poszukać rozwiązań innych producentów — niestety, o ile wiem obecnie nie są dostępne żadne tego typu produkty.




1   2   3


©absta.pl 2019
wyślij wiadomość

    Strona główna