Zarządzanie tożsamością oraz rozwiązania zabezpieczeń Red Hat zaprojektowane są aby:

• Uprościć zarządzanie informacjami identyfikacyjnymi w złożonych środowiskach heterogenicznych.
• Wnieść korzyści modelu programowania open source do tożsamości korporacyjnej i infrastruktury zabezpieczeń.
• Utorować drogę do zintegrowanej kontroli tożsamości i zabezpieczeń jako że procesy i rozwiązania nadal rozwijają się.

Na podstawie opracowania Seana Cottera. Menadżera Produktu, Red Hat Directory and Security Products

Sprostanie wyzwaniu

Wyzwania dotyczące zarządzania tożsamością i zabezpieczenia są znane wszystkim organizacjom niezależnie od typu i wielkości:

• Problemy użytkownika z hasłami, dostępem, poufnością i zabezpieczeniami przerywają codzienna pracę i nadal stanowią wysoki procent kosztów IT.
• Rozszerzenie dostępu do większej ilości użytkowników z ogromnie zróżnicowanymi potrzebami i rolami wymaga elastycznych systemów do zarządzania informacjami o użytkownikach podczas obniżania kosztów administracyjnych przypadających na jednego użytkownika.
• Niska skalowalność, brak niezawodności oraz niedoskonała współpraca między systemami zarządzania użytkownika w środowiskach heterogenicznych prowadzą do nieprzewidywalnych opóźnień we wdrożeniu aplikacji o kluczowym znaczeniu dla firmy
• Wydatki związane z coraz bardziej złożonymi wymogami dotyczącymi nadzoru i zgodności mnożą się kiedy dane użytkownika oraz prawa dostępu nie mogą być szybko i dokładnie pobrane bądź zmodyfikowane. W ekosystemie open source, któremu przewodzi Red Hat, rozwiązanie zarządzania tożsamością musi:
• Upraszczać zarządzanie coraz bardziej złożonych środowisk.
• Zapewniać korzyści modelu programowania open source wszystkim elementom wdrożenia korporacyjnego
• Zapewnić pewną drogę do zintegrowanej kontroli tożsamości i zabezpieczeń jako że procesy, systemy oraz rozwiązania firm niezależnych rozwijają się.

Red Hat i Netscape

Red Hat nabył kluczowe technologie Netscape Security Services w grudniu 2004 i wypuszcza na rynek Red Hat® Directory Server oraz Red Hat Certificate System w czerwcu 2005. W rezultacie, Red Hat może obecnie zaoferować klientom dojrzałe, powszechnie wdrażane produkty korporacyjne, które kładą podwaliny pod kompletne rozwiązanie zarządzania tożsamością. Odrodzone jako produkty Red Hat Directory and Security, technologie Netscape i ekipa obsługi technicznej nabyte przez Red Hat mają wspólną historię począwszy od końca lat 90tych, kiedy inżynierowie Netscape stworzyli LDAP, SSL oraz inne podstawowe technologie internetowe i wbudowali je w innowacyjne produkty serwerowe. Osiągnięcia, którymi przyczyniają się do architektury open source Red Hat to między innymi:

• Lata doświadczeń związanych z wielkimi wdrożeniami dla setek organizacji i milionów użytkowników w dziedzinie administracji rządowej, edukacji oraz przemysłu.
• Wypuszczenie silnika enkrypcji Network Security Services (NSS) oraz powiązanych technologii Netscape w środowisko open source takie jak projekty Mozilla.
• Okresowe uprawomocnienia NSS z Sun Microsystems według FIPS 140-1, wymóg dla wszystkich wdrożeń rządowych, które dotyczą oprogramowania kryptograficznego.
• Okresowe uprawomocnienia Red Hat Certificate System według Common Criteria, również wymóg rządowy.

Tożsamość i zabezpieczenia Red Hat - Zarządzanie

Na dłuższą metę, Produkty Red Hat Directory and Security są spozycjonowane, aby zapewnić następujące korzyści kluczowe wszystkim klientom Red Hat:

• Wykorzystywana wartość w całej infrastrukturze open source
• Partycypacja w ekosystemie od niezależnych producentów oprogramowania i sprzętu (ISV, IHV) oraz otoczenia
• Zwiększone przyjęcie dzięki konstrukcji opartej na standardach oraz rozszerzonym opcjom

Z wypuszczeniem na rynek Red Hat Directory Server i Red Hat Certificate System w czerwcu 2005, Red Hat zaczęło rozbudowywać elementy tożsamości i zabezpieczeń Architektury Open Source. Produkty te są zwięźle streszczone poniżej. Pozostała część niniejszego dokumentu nakreśla pewne typowe scenariusze wdrożenia oraz dostarcza więcej szczegółów dotyczących funkcji kluczowych.

Red Hat Directory Server:

Tożsamość skalowalna

Red Hat Directory Server (dawniej Netscape Directory Server) zapewnia dojrzałą, wysoce skalowalną oraz niezawodną pamięć danych zaprojektowaną, aby odpowiedzieć na dwa pytania dotyczące próby użytkownika uzyskania dostępu do jakiegokolwiek systemu.

• Uwierzytelnienie: Kim jesteś?
• Autoryzacja: Co możesz zrobić?

Red Hat Directory Server umożliwia odpowiednie oraz aktualne uwierzytelnienie i dostęp do zasobów i aplikacji wszystkim użytkownikom w organizacji stosując opartą na standardach, wysoce skalowalną, wysokowydajną strukturę serwera. Dodatkowo,Red Hat Directory Server:

• Udoskonala codzienną pracę użytkownika poprzez wspieranie uproszczonej kontroli dostępu opartej na jednorazowym logowaniu.
• Centralizuje dane użytkownika i upraszcza zarządzanie, zatem obniża koszty.
• Dostarcza bogaty zestaw narzędzi, SDK i API, wspomagających szybkieprogramowanie.
• Ułatwia zgodność z Sarbanes-Oxley (SOX), Federal Information Processing Standard (FIPS) 201, oraz innymi dyrektywami.

Red Hat wydał rdzeń kodu podstawowego Directory Server w środowisku open source poprzez projekt Fedora Direktory Server w czerwcu 2005. Pozostała część kodu serwera włącznie z oprogramowaniem administracyjnym, będzie wypuszczona na rynek do końca 2005 roku.

Red Hat Certificate System:
uproszczone zabezpieczenie

Red Hat Certificate System (dawniej Netscape Certificate Management System) zapewnia wysoce skalowalne, łatwe w zarządzaniu całościowe cyfrowe rozwiązanie uwierzytelniające, które jest dostosowane, do udzielenia odpowiedzi na trzecie kluczowe pytanie dotyczące zarządzania tożsamością dla wielu wysoce chronionych organizacji biznesowych i rządowych.

• Zapewnienie: Czy jesteś tym, kim mówisz, że jesteś?

Poprzez znaczne uproszczenie doświadczenia użytkownika jeśli chodzi o rejestrację, system zarządzania kartą smartcard, który jest wbudowany w Red Hat Certificate System może obniżyć koszty tak, by rozwiązania kart smartcard o średnim oraz wysokim zabezpieczeniu były w zasięgu finansowym dla organizacji, które wcześniej nie mogły sobie na nie pozwolić. Dodatkowo,Red Hat Certificate System:

• Wspomaga inne systemy zarządzania tożsamością oparte na standardach dla organizacji o średnich do wysokich potrzebach bezpieczeństwa.
• Kładzie podwaliny pod zgodność z HSPD#12/FIPS 201.
• Zapewnia wysoką skalowalność sprawdzoną w dużych wdrożeniach.
• Jest w trakcie recertyfikacji FIPS 140-2 i Common Criteria dla podstawowych elementów wsparcia wdrożeń rządowych.

Wsparcie procesów zarządzania tożsamością

Zarządzanie tożsamością dotyczy kilku różnych procesów:

• Rejestracja oraz provisioning zazwyczaj ma miejsce raz.
• Wydanie danych uwierzytelniających zazwyczaj ma miejsce okresowo.
• Zarządzanie cyklem życia tożsamości oraz danych uwierzytelniających występuje w trybie ciągłym dopóki konto użytkownika nie zostanie zablokowane bądź usunięte.

Rejestracja i Provisioning

Pierwszy etap zarządzania tożsamością to założenie tożsamości poprzez zebranie oraz zweryfikowanie informacji o nowym użytkowniku. Obecnie, produkty Red Hat Directory and Security wykorzystują otwarte standardy, by wesprzeć wiele form integracji za pomocą nowych bądź istniejących już systemów lub procesów, takich jak:

• Adaptacja procesów rejestracji pomaga organizacjom przestrzegać stosownej polityki dotyczącej różnych typów użytkowników oraz procedur.
• Synchronizacja i integracja danych użytkownika z innych katalogów i baz danych zapewnia poprawne przeniesienie do wszystkich stosownych systemów informacji o użytkowniku zdobytych poprzez rejestrację. Integracja Windows Sync jest dostępna z pudełka. Wymagania dla synchronizacji z bazami danych takimi jak Oracle czy PeopleSoft zazwyczaj różnią się za każdym wdrożeniem i zasadniczo wymagają wpisywania skryptów przy użyciu PerLDAP lub innych narzędzi. Przykładowe skrypty dostępne są jako część LDAP SDK.
• Provisioning zapewnia mechanizmy dodawania nowych użytkowników do katalogu przedsiębiorstwa (na przykład w wyniku wywiadu bezpośredniego lub poprzez niestandardowe skrypty do synchronizacji baz danych)
• Logowanie i nadzór pozwalają na weryfikację danych i decyzji związanych z procesem rejestracji po fakcie.

Nadchodzące wersje będą wspierać dodatkowe formy integracji z oprogramowaniem firm niezależnych według FIPS 201 i innych powiązanych standardów:

• Integracja z oprogramowaniem organizacji pracy, wspierająca dostosowywalne, weryfikowalne procesy rejestracji.
• Integracja z urządzeniami biometrycznymi wspierająca mechanizmy zbierania, przechowywania oraz stosowania danych biometrycznych.

Wydanie uwierzytelnienia

Nowo zarejestrowani użytkownicy potrzebują danych uwierzytelniających takich jak hasła, autentykacja Kerberos, certyfikaty lub znaki identyfikacyjne dostępu, by zyskać dostęp do:

• Fizycznych lokacji takich jak laboratoria czy biura
• Dostępu online do zasobów takich jak serwery czy aplikacje

Obecnie, produkty Red Hat Directory and Security wspierają wydanie, integrację oraz zarządzanie szerokim zakresem danych uwierzytelniających takich jak:

• Nazwy użytkownika i hasła
• Autentykacja Kerberos poprzez SASL GSS/API
• Certyfikaty (dane uwierzytelniające PKI)
• Karty elektroniczne smartcard

Red Hat Certificate System i Red Hat Directory Server zapewniają w pełni zintegrowane rozwiązanie zarządzania PKI oraz kartą smartcard które karty smartcard Personal Identity Verification (PIV) będą mogły swobodnie włączyć.

Zarządzanie cyklem życia

Obecnie produkty Red Hat Directory and Security wspierają kluczowe technologie wymagane do zarządzania tożsamościami i ich danymi uwierzytelniającymi od chwili, kiedy użytkownik rejestruje się po raz pierwszy przez cały okres jego egzystencji w organizacji. Produkty te obejmują:

• Lightweight Directory Access Protocol (LDAP):
• Uwierzytelnienie i kontrola dostępu, włącznie ze wsparciem NIS, PAM, SSH, oraz innymi aplikacjami systemowymi
• Portale self-service
• Weryfikacja certyfikatu
• Certificate Revocation Lists (CRLs)
• Respondent Online Certificate Status Protocol (OCSP)
• Integracja z pocztą, www i innymi aplikacjami z udostępnionym LDAP.
• Adresowanie dla klientów takich jak Outlook i Thunderbird
• Przechowywanie preferencji dla serwerów
• Uwierzytelnienie do stron www
• Synchronizacja z pamięcią danych użytkownika (taka jak Windows Active Directory) zapewnia, że zmiany w danych użytkownika w jednej lokacji przenoszone są poprawnie do innych lokacji.
• Red Hat Management Console zapewnia spójny GUI administrujący architekturę serwerową zarówno Red Hat Directory Server jak i Red Hat Certificate System:
• Funkcje serwera mogą być administrowane zdalnie
• Zmiana konfiguracji, danych, schematu bez przestoju
• Konfiguracja dostępu do serwera, monitorowanie informacji poprzez LDAP
• Aplikacje www ułatwiają dostarczenie dostępu internetowego do katalogu oraz informacji o certyfikacie przez interfejsy książki telefonicznej, schematu organizacyjnego oraz mapowania.

Nadchodzące wersje produktów Red Hat Directory and Security będą tworzyć na tym fundamencie funkcje self-service, hasła, zarządzania polityką oraz opcje nadzoru.

Red Hat Directory Server: scenariusze wdrożenia

Red Hat Directory Server jest projektowany i testowany już niemal dekadę, by wspierać złożone, rozprowadzane na całym świecie wdrożenia katalogu o wymaganiach wysokiej dostępności. Wdrożenia katalogu o wysokiej dostępności stosują zazwyczaj replikację multi-master, by zapewnić następujące korzyści strategiczne:

• Kopie główne rezydują na wielu serwerach.
• Serwery master mogą być ulokowane w różnych centrach danych, na różnych obszarach geograficznych.
• Zmiany danych mogą być dokonywane na najbliższym serwerze a następnie przenoszone do innych serwerów.
• Failover zapewnia ciągłość usługi.
• Automatyczne rozwiązywanie konfliktów upraszcza administrację.

Oto podstawowe elementy replikacji multi-master:

Następujące scenariusze dostarczają uproszczone przykłady stosowania replikacji multi-master w rozprowadzanych wdrożeniach katalogu.

Scenariusz: Aplikacja korporacyjna o wysokiej szybkości wyszukiwania i aktualizacji

Wiele stron handlu elektronicznego stosuje katalogi LDAP do obsługi wysokiej szybkości zarówno kwerend klienta jak również zmian informacji o poszczególnych klientach. Poniższy diagram obrazuje dwa serwery master oraz różne repliki tylko do odczytu. Aktualizacje oraz zapytania wyszukiwania są cykliczne jak następuje;

• Równoważnik obciążenia kwerendy skierowuje zapytania wyszukiwania do replik tylko do odczytu.
• Równoważnik obciążenia aktualizacji (sprzęt bądź oprogramowanie) skierowuje żądania aktualizacji bezpośrednio do jednego z serwerów master.

Równoważniki obciążenia mogą być implementowane do sprzętu bądź oprogramowania lub jako pojedynczy węzeł uniwersalny. W tym scenariuszu serwery master mogą się skoncentrować na szybkich odpowiedziach na żądania aktualizacji oraz na replikowaniu ich do innych serwerów, podczas gdy repliki częściej rozpatrują zapytania wyszukiwania.

Scenariusz: Stosowanie koncentratorów i replik w sieci globalnej

Organizacje globalne obsługują biura rozproszone pod względem geograficznym. W zależności od tego, jakiego rodzaju działalność organizacja prowadzi i i na jakim obszarze, potrzeby i struktura katalogów lokalnych mogą znacznie się różnić. By dostarczać usługi katalogowe możliwie najskuteczniej, serwery master i koncentratory mogą być uporządkowane, by odpowiadać za rozprowadzane modele zapytań jakrównież failover i usuwanie skutków katastrof.

W powyżej zilustrowanym uproszczonym scenariuszu, trzy serwery master obsługują trzy regiony, gdzie skoncentrowani są pracownicy. Serwery te scalają informacje z całej firmy z różnorodnych baz danych i innych źródeł używanych przez uwierzytelnionych użytkowników i administratorów na całym świecie. Takie serwery master mogłyby równie dobrze posiadać własne repliki aby rozpatrywać lokalne obciążenie kwerend, ale ten poziom szczegółu nie jest pokazany. Biura europejskie są również ulokowane w trzech głównych centrach. Katalog hub w Londynie obsługuje repliki w Monachium i w Paryżu. Kwerendy lokalne skierowywane są do replik lokalnych, podczas gdy mniej częste żądania aktualizacji skierowywane są do serwerów master w US w celu propagacji w całej globalnej infrastrukturze. Biuro w Tokio nie potrzebuje koncentratora. Jego katalog bezpośrednio komunikuje się z serwerem master w Atlancie.

Scenariusz: Replikacja multi-master i failover w serwerach regionalnych

Replikacja multi-master jest powszechnie stosowana jako część strategii failover. W poniższym przykładzie geograficznie rozproszone serwery sieciowe i pocztowe obsługują klientów lokalnych i normalnie komunikują się ze swoim najbliższym serwerem master. Jeśli serwer master nie odpowie, serwery, które normalnie obsługuje automatycznie przełączają do serwera w następnym regionie. W ten sposób geograficzne równoważenie obciążenia może być połączone z failover oraz z usuwaniem skutków katastrof.

Red Hat Directory Server: Główne zagadnienia techniczne

Uwierzytelnienie

Red Hat Directory Server wspiera szeroki wachlarz standardów i technologii uwierzytelnienia takich jak:

• Nazwa użytkownika i hasło, Digest MD5
• Loginy Systemu Operacyjnego przez NIS lub PAM
• Bilety protokołu Kerberos poprzez SASL/GSSAPI
• Uwierzytelnienie PKI na podstawie certyfikatów TLS (SSL) X.509
• Impersonacja (proxy) wielopoziomowych aplikacji klienckich

Dodatkowo klienci mogą pisać plug-in’y stosując wytrzymały i dobrze udokumentowany plug-in API dla praktycznie każdego dotychczasowego systemu lub aplikacji bazy danych takich jak Oracle. Wbudowane uprawnienia zarządzania hasłem obejmują:

• Synchronizację tożsamości z Windows Active Directory
• Ochrona przed złamaniem zabezpieczenia – próby zalogowania się, zablokowanie konta
• Ochrona przed złamaniem zabezpieczenia – minimalna długość, brak „trywialnych” haseł* historia hasła.
• Możliwość przechowywania haseł (clear, crypt, SHA1)

Kontrola autoryzacji/dostępu

Red Hat Directory Server jest również niezwykle elastycznym, precyzyjnym mechanizmem kontroli dostępu z możliwością swobodnej konfiguracji. Dostęp może być kontrolowany na podstawie kryteriów zewnętrznych lub grup i ról oraz w sposób hierarchiczny dostosowany do wymagań użytkownika. Dostęp może być ustalony dla całego Drzewa Informacji Katalogu (DIT) , dla poddrzew lub indywidualnych wpisów i może się różnić dla poszczególnych atrybutów wewnątrz wpisu. Na przykład, polityka hasła może być ustalona na całym DIT, potem może być zastąpiona poddrzewem lub nawet indywidualnym użytkownikiem na podstawie specjalnych potrzeb. W ten sposób hasła do wysoce wrażliwych aplikacji będą musiały spełniać bardziej rygorystyczne wytyczne i częściej być zmieniane, i tak dalej. Red Hat Directory Server może być również używany do przechowywania informacji o kontroli dostępu urządzeń, serwerów oraz innych źródeł. Kontrola dostępu może bazować na przynależności do użytkownika bądź grupy, ID lub nazwie domeny, porze dnia i na wielu innych kryteriach.

Elastyczna administracja

Rzadko jest konieczne wznowienie działania serwera. Większość zmian konfiguracji, importowanie i eksportowanie, zmiany schematów i indeksowanie mągą być wykonywane na bieżąco bez przestoju. Ustawienia konfiguracji są przechowywane w specjalnym poddrzewie c=config, co oznacza, że można mieć do nich dostęp oraz można je wyszukiwać za pomocą kwerend standardu LDAP. Informacje o monitorowaniu są przechowywane w poddrzewie cn=monitor tak, że status czy statystyka dotycząca kwestii takich jak liczba wątków w użyciu w jakimkolwiek podanym czasie mogą być pobierane poprzez kwerendy standardu LDAP. Produkt posiada wbudowane wsparcie SNMP, zatem informacje dotyczące zmiennych takich jak miejsce na dysku mogą być monitorowane zdalnie. Jak omówiono powyżej, najbardziej powszechne zadania administracyjne mogą być wykonywane za pomocą Red Hat Management Console, aplikacji Java, która umożliwia administratorom wykonywanie zadań administracyjnych zdalnie. Administratorzy mogą również używać plików konfiguracyjnych lub narzędzi linii poleceń do celów administracji zdalnej.

Grupy, role i klasa usług

Grupa statyczna składa się z pojedynczego wpisu, który zawiera listę wpisów składowych. Grupa dynamiczna pozwala na filtrowanie wpisów, które zawierają poszczególny atrybut i włączyć je w pojedynczą grupę. Drzewo katalogu porządkuje informacje hierarchicznie. Hierarchia ta jest sama w sobie mechanizmem grupowania, chociaż nie jest dostosowana dla zmieniających się organizacji. Role ujednolicają statyczne i dynamiczne grupy. Każdy wpis przyporządkowany danej roli zawiera obliczony atrybut, który wyszczególnia wszystkie role, do których należy wpis. Aplikacja kliencka może sprawdzić przynależność roli poprzez wyszukiwanie atrybutu, który jest obliczony przez katalog i dlatego zawsze aktualny. Role są zaprojektowane tak, by były bardziej skuteczne i prostsze w użyciu dla aplikacji. Na przykład, aplikacje mogą raczej lokalizować role wpisu niż wybierać grupę i przeglądać listę elementów. Klasa usług (CoS) pozwala współużytkować atrybuty pomiędzy wpisami w sposób niewidoczny dla aplikacji. Za pomocą Klasy Usług (Cos), niektóre wartości atrybutów mogą nie być przechowywane z samym wpisem. Zamiast tego generowane są one przez klasę usług logic gdy wpis wysyłany jest do aplikacji klienckiej. Na przykład, katalog z reguły zawiera tysiące wpisów, które wszystkie współużytkują wspólny atrybut facsimileTelephoneNumber. Tradycyjnie, aby zmienić numer faksu, trzeba by było zaktualizować każdy wpis osobno, to sporo pracy dla administratorów którzy ryzykują utratę niektórych z nich. Z klasą usług (CoS) można generować atrybut dynamicznie. Atrybut facsimileTelephoneNumber jest przechowywany w jednym miejscu a każdy wpis wskazuje to miejsce, by podać wartość ich atrybutowi fax number. Dla aplikacji atrybuty te pokazują się dokładnie tak samo jak inne atrybuty mimo faktu, iż nie są przechowywane w samych wpisach.

Niezawodność i skalowalność

By zapewnić niezawodność, skalowalność oraz geograficzną dystrybucję, Red Hat Directory Server wspiera 4-drożną replikację multi-master oraz łączenie łańcuchowe. Wsparcie replikacji multi-mater omówione jest powyżej w sekcji Scenariusze Directory Server i obejmuje wsparcie przez sieci WAN o słabej bądź nieciągłej łączności. Łączenie łańcuchowe wiąże się z możliwością tworzenia specjalnego wpisu w poddrzewie katalogu. Wszystkie próby wykonywania operacji LDAP pod tym wpisem wysyłane są do zdalnego urządzenia, gdzie wpis ten jest faktycznie przechowywany. Łączenie łańcuchowe może być stosowane zarówno do równoważenia obciążenia jak i by umożliwić geograficzną dystrybucję danych tak, by pozostały fizycznie blisko zasobów, które najczęściej potrzebują dostępu.

Narzędzia i SDK

Następujące SDK Mozilli stosowane są w szerokim zakresie w tworzeniu oprogramowania.

• Open source Mozilla LDAP C SDK (obejmuje narzędzia linii poleceń np.: idapsearch)
• Mozilla LDAP Java SDK
• Narzędzia Standard Perl dla LDAP działają
• PerLDAP (http://www.perldap.org/)
• Perl-LDAP (http://ldap.perl.org/)

Następujące dodatkowe SDK dla produktów LDAP również będą działały bez zarzutu:

• Java Naming i Directory Infrastructure (JNDI)
• PHP LDAP
• Python LDAP

Inne narzędzia obejmują wsparcie dla:

• Testowania obciążenia i wydajności
• Analizy protokołu dostępu
• Ethereal (sniffera sieciowego open source)

Plug-in API

Wiele adaptacji, jak również funkcji standardowych stosują Plug-In API (C/C++). Plug-in’y mogą być stosowane, by:

• Zaplanować działanie, które wykonuje Directory Server zanim serwer przetworzy działanie LDAP (Filtry). Na przykład, można napisać standardową funkcję, by sprawdzić poprawność danych zanim serwer wykona na tych danych operację LDAP.
• Zaplanować działanie, które wykonuje Directory Server po tym jak serwer pomyślnie zakończy operację LDAP (Triggery). Na przykład, można przesyłać pocztę do klienta po tym jak operacja
  LDAP jest pomyślnie ukończona.
• Zdefiniować operacje rozszerzone jak określono w protokole LDAP v3.
• Zapewnić alternatywne reguły dopasowania podczas porównywania pewnych wartości atrybutów.

Red Hat Certificate System: Scenariusze rejestracji

Red Hat Certificate System zapewnia w pełni zintegrowane,całościowe rozwiązanie do stosowania oraz zarządzania cyfrowymi ID, które obejmuje:

• Certificate Authority (CA)
• System zarządzania kartami smartcard/organ ds. rejestracji użytkowników
• System archiwizacji klucza prywatnego
• Respondent Online Certificate Status Protocol (OSCP)
• Klienckie oprogramowanie pośrednie

Począwszy od paru lat temu w AOL/Netscape aż do teraz po przejęciu przez Red Hat produkty z rodziny Directory and Security Products skupiają udoskonalenia użyteczności jak również całościową integrację

dla użytkowników i administratorów. W wyniku tych starań, Red Hat Certificate System znacznie obniżyło koszty wdrożenia i zarządzania PKI.

1. Niższe koszty konstruowania programu. Wszystkie elementy kompletnego rozwiązania PKI są opracowywane przez jedną ekipę.
2. Niższe koszty oprogramowania. Ponieważ wszystkie elementy kompletnego rozwiązania są częścią jednorazowej subskrypcji Red Hat, oprogramowanie zasadniczo kosztuje mniej w porównaniu z kosztami oprogramowania zakupionego oddzielnie.
3. Niższe koszty wsparcia i administracji. Przełom w użyteczności zapewnionej przez zintegrowane zarządzanie kartą elektroniczną przynoszą korzyści zarówno użytkownikom jak administratorom.

W skrócie, Red Hat Certificate System redukuje koszty, które aż do teraz nękały różne poziomy zabezpieczenia PKI.

Red Hat Certificate System stosuje Red Hat Directory Server jako wewnętrzną bazę certyfikatów wykorzystując jej replikację, łączenie łańcuchowe i możliwości failover, by wspierać klonowanie CA oraz geograficzną dystrybucję. Red Hat Certificate System zawiera również Enterprise Security Client, małą aplikację kliencką dostępna dla Red Hat Enterprise Linux, Windows, i Mac OS X co znacznie upraszcza użytkownikowi rejestrację karty smartcard. Zarówno stosowany do obsługiwania certyfikatów oprogramowania, kart smartcard jak i specjalnych tokenów takich jak karty Personal Identity Verification (PIV) wymienionych do użytku przez Federalne agencje według FIPS 201, Red Hat Certificate System wspiera szereg scenariuszy rejestracji i wymagań zarzadzania cyklem życia. Scenariusze rejesracji przedstawione poniżej opsują trzy wdrożenia, które spełniają wymagania niskiego, średniego i wysokiego zabezpieczenia oraz demonstrują sposób podejścia Red Hat do PKI.

Scenariusze rejestracji: Tożsamości klienta niskie zabezpieczenie

Pierwszy scenariusz przedstawia klienta używającego interfejsu sieciowego w celu zażądania certyfikatu stosującego nazwę bądź hasło. Żądanie zawiera klucz publiczny, którego odpowiadający klucz prywatny pozostaje w komputerze użytkownika.

Scenariusze rejestracji: Tożsamości partnera, średnie zabezpieczenie

Scenariusz ten przedstawia partnera lub użytkownika extranetu uzyskującego nowe dane uwierzytelniające PKI dla karty smartcard.

Użytkownik wkłada nieaktywowaną kartę smartcard rozpowszechnianą przez organizację prowadzącą Red Hat Certificate System.

1. Na sprzęcie użytkownika Enterprise Security Client wykrywa zdarzenie włożenia karty, kontaktuje się z CA oraz pobiera okno HTML użytkownika zprojektowane przez organizację, aby spełnić wymagania wstępnej rejestracji.
2. Użytkownik wypełnia wymagane informacje, przyporządkowuje PIN do karty i klika przycisk Wyślij.
3. CA sprawdza wersję apletu i aktualizuje ją jeśli zachodzi taka konieczność, następnie weryfikuje informacje rejestracyjne względem Red Hat Directory Server lub jakiegokolwiek innego systemu wymaganego przez politykę organizacji.
4. Applet karty generuje klucz publiczny i prywatny oraz wysyła klucz publiczny do CA. Klucz prywatny pozostaje na karcie.
5. CA formułuje certyfikat, publikuje go do katalogu i wysyła do karty smartcard.
6. Użytkownik jest teraz gotowy do używania silnego uwierzytelnienia klienta SSL.

Cały proces trwa tylko minutę lub dwie. Partner jest teraz gotowy do użycia karty w celu silnego uwierzytelnienia klienta SSL do stron www extranetu. Karta smartcard nie jest związana z określoną osobą dopóki ktoś nie użyje jej w procesie rejestracji. Organizacja wydająca dane uwierzytelniające może dostosować informacje rejestracyjne według tego, jaki poziom zabezpieczenia wymaga jej polityka. Na przykład numer telefonu lub hasło jednorazowe może być wymagane. Kradzież nieaktywowanej karty nie pomaga potencjalnemu oszustowi chyba że rejestracja zależy wyłącznie od informacji, które znajdują się na karcie. Organizacja planująca wdrożenie musi oszacować zagrożenie bezpieczeństwa i zażądać stosownych informacji i weryfikacji, aby zakończyć rejestrację. Bezpieczna komunikacja pomiędzy Certificate Authority a kartą smartcard jest możliwa dzięki używaniu kluczy symetrycznych oraz protokołu Protocol Data Units (PDU) zdefiniowanego przez Global Platform smartcard protocol. Scenariusz rejestracji zaprojektowany jest, by zapewnić silne uwierzytelnienie do stron www przy relatywnie niskich kosztach wdrożenia. Jeśli organizacja używa danych uwierzytelniających PKI dla podpisanej cyfrowo i zaszyfrowanej poczty mailowej oraz innych zadań szyfrowania wysokiego bezpieczeństwa, które wymagają archiwizacji klucza prywatnego, następny scenariusz zapewnia najwyższy poziom zabezpieczenia i elastyczności zarządzania.

Scenariusz rejestracji: Tożsamości pracownika, wysokie zabezpieczenie

Scenariusz ten przedstawia pracownika uzyskującego nowe dane uwierzytelniające PKI o wysokim zabezpieczenie dla karty smartcard. Scenariusz ten mógłby potencjalnie być zintegrowany z bardziej złożonym procesem rejestracji wymagającym bezpośredniej interakcji, gromadzenia informacji biometrycznych oraz kontroli tła jak również wydania danych uwierzytelniających karty smartcard. Proces przedstawiony na poprzedniej stronie funkcjonuje tak:

1. Użytkownik wkłada nieaktywowaną kartę smartcard rozpowszechnianą przez organizację prowadzącą Red Hat Certificate System.
2. The Enterprise Security Client na sprzęcie użytkownika wykrywa zdarzenie włożenia karty, kontaktuje się z CA oraz pobiera okno HTML użytkownika zaprojektowane przez organizację, aby spełnić wymagania wstępnej rejestracji.
3. Użytkownik wypełnia wymagane informacje, przyporządkowuje PIN do karty i klika przycisk Wyślij.
4. System przetwarzania kart smartcard działa jak policjant drogowy dla komunikacji między wewnętrznym elementem przetwarzającym a kartą. Na tym etapie sprawdza wersję apletu i aktualizuje ją jeśli zachodzi taka konieczność, następnie weryfikuje informacje rejestracyjne względem katalogu lub jakiegokolwiek innego systemu wymaganego przez politykę organizacji.
5. System archiwizacji klucza (DRM na rysunku) generuje parę kluczy szyfrujących, archiwizuje prywatny klucz szyfrujący oraz bezpiecznie wysyła go do apletu na karcie razem z kluczem publicznym.
6. Applet karty generuje parę kluczy podpisujących i wysyła klucz publiczny do CA w żądaniu certyfikatu.
7. CA formułuje certyfikat, publikuje go do katalogu i wysyła do karty smartcard.

Użytkownik jest teraz gotowy do używania silnego uwierzytelnienia klienckiego SSL. Kroki 8, 9 i 10 ilustrują trwający proces stosowania certyfikatu oraz kontroli statusu. Za każdym razem gdy użytkownik podpisuje bądź szyfruje pocztę mailową lub uwierzytelnia do serwera, stosowana aplikacja sprawdza status certyfikatu za pomocą respondenta OCSP. CRL stosowane przez respondenta OCSP jest stale aktualizowana przez Certificate Manager gdyż certyfikaty są unieważniane. Tak jak w poprzednim scenariuszu, bezpieczna komunikacja pomiędzy Certificate Manager a kartą smartcard możliwa jest dzięki stosowaniu kluczy symetrycznych oraz protokołu Protocol Data Units (PDU) zdefiniowanego przez protokół Global Platform smartcard protocol. Ten scenariusz rejestracji zaprojektowany jest, by zapewnić silne uwierzytelnienie i szyfrowanie dla aplikacji o wysokim bezpieczeństwie wymagających wysokiego poziomu zabezpieczenia i niezawodnego systemu archiwizacji klucza prywatnego. Mógłby potencjlnie zawierać wiele respondentów OCSP, klonowanych globalnie rozmieszczonych CA lub pod-CA jak również modułów zabezpieczeń sprzętu (HSM) firm niezależnych i innego specjalnego oprzyrządowania.

Główne zagadnienia techniczne:

Red Hat Certificate System

Architektura

Oto główne elementy Red Hat Certificate System:

• Certificate Authority (CA):
• Wydaje cyfrowe certyfikaty X.509 oraz CRL
• Publikuje certyfikaty do katalogu LDPA.
• Token (Smartcard) Processing System (TPS):
• Wspiera karty Globar Platform & tokeny programowe
• Funkcje jak organ ds. Rejestracji użytkownika, z którym bezpośrednio komunikuje się klient
• Data Recovery Manager (DRM):
• Bezpieczne repozytorium dla kopii zapasowych/odtworzenia klucza prywatnego użytkownika
• Zatwierdzenie odtworzenia typu multi-person z możliwością konfiguracji
• Respondent Online Certificate Status Protocol (OCSP) Odpowiada na żądania OCSP weryfikacji ważności certyfikatu w czasie rzeczywistym
• Token Key Service (TKS): Zarządza kluczami symetrycznymi do zabezpieczania komunikacji między podsystemami a kartami smartcard
• Enterprise Security Client (ESC): Oprogramowanie klienckie dla Red Hat Enterprise Linux, Windows XP, i Mac OS X.

Zobacz Scenariusze Rejestracji powyżej, aby uzyskać więcej informacji na temat interakcji między tymi elementami.

Innowacje karty smartcard

W ostatnich latach rozwój Red Hat Certificate System skupia się na uproszczeniu rejestracji i innych aspektów zarządzania kartą smartcard. To pierwszy produkt, który zapewnia rozwiązanie kompletnie zintegrowanego całościowego zarządzania PKI i kartą smartcard.. Podczas rejestracji Enterprise Security Client wyświetla stronę HTML kontrolowaną przez wewnętrzny element przetwarzający. Wszelkie aspekty rejestracji są całkowicie dostosowywalne. Elastyczność ta pozwala organizacjom na dostosowywanie poziomu zabezpieczenia (i budżetu) wymaganego do rejestracji według zmieniających się wymagań zabezpieczenia każdego zasobu czy roli. Jak tylko użytkownik aktywuje zarejestrowaną kartę, będzie mógł natychmiast użyć jej do uwierzytelniania do stron WWW lub podpisywania lub szyfrowania poczty elektronicznej. Inżynierowie Red Hat wnieśli kod do aplikacji open source takich jak Firefox i Thunderbird tak, by mogły wykrywać zdarzenia wkładania i wyjmowania karty oraz odpowiednio reagować. Red Hat planuje również zintegrowanie ESC oraz pokrewnych możliwości zarządzania kartą smartcard Enterprise Linux®..

Sprawdzanie statusu certyfikatu online

Wdrożenia Red Hat Certificate System o wysokim zabezpieczeniu muszą zapewnić sposób sprawdzenia, czy podany certyfikat jest wciąż ważny za każdym razem, gdy jest używany. Jednym sposobem, w jaki produkty PKI spełniają ten wymóg to Certificate Revocation Lists (CRL), czyli listy certyfikatów wydawane przez CA, które zostały unieważnione lub już nie są ważne z jakiegoś innego powodu. Red Hat Certificate System wspiera CRL. Jednak, CRL mogą stać się całkiem obszerne, co zazwyczaj spowalnia czas reakcji aplikacji próbujących je użyć. protokół Online Certificate Status Checking (OCSP) protocol umożliwia aplikacjom zgodnym z OCSP określenie stanu Certyfikatu włącznie ze statusem unieważnienia bez bezpośredniego sprawdzenia CRL. Zamiast tego CRL opublikowane jest przez CA do organu zatwierdzającego, który jest również zwany respondentem OCSP. Respondent OCSP dokonuje zazwyczaj sprawdzenia aplikacji szybciej niż bezpośredniego sprawdzenia CRL. Respondent OCSP dostarczony przez Red Hat Certificate System zapewnia wystarczająco szybką reakcję dla większości wdrożeń.

Skalowalność i wydajność

Red Hat Certificate System zawiera Red Hat Directory Directory Server jak i jego bazę certyfikatów, może zatem w pełni korzystać ze znakomitej skalowalności i wydajności tego produktu. Oprócz wieloletniego obsługiwania bardzo dużych wdrożeń o wysokim zabezpieczeniu dla rządu i przemysłu, Red Hat Certificate System demonstruje następujące osiągnięcia w testach laboratoryjnych

• Wydał ponad 12 milionów certyfikatów z jednego serwera w niecałe 35 dni (~14,000 certyfikatów/godzinę) Jednocześnie publikował do Directory Server i archiwizował klucze prywatne
• Unieważnił 10% certyfikatów dając w rezultacie CRL o 1.2 miliona wpisów
• Wygenerował CRL w niecałe 30 minut

Wysoka dostępność i usuwanie skutków katastrof

Red Hat Certificate System używa Red Hat Directory Server wewnętrznie, aby ułatwić solidną strukturę klonowania i failover. CA, DRM, oraz respondent OCSP mogą wszystkie być klonowane. Funkcja ta prawie całkowicie eliminuje nieplanowane przestoje klonując jeden bądź więcej podsystemów dostępnych dla failover. Źródła danych dla systemów klonowanych są replikowane, zatem dane są płynnie współużytkowane między bazami podsystemów. Urządzenie główne i sklonowane obiekty są zazwyczaj instalowane na różnych sprzętach za równoważnikiem obciążenia. Kiedy ma miejsce awaria, równoważnik obciążenia niewidocznie przekierowuje wszystkie żądania do klona, który wciąż działa bez przerywania usługi.

Narzędzia i SDK

Red Hat Certificate System zawiera Java SDK, aby ułatwić integrację infrastruktury PKI z innymi aplikacjami korporacyjnymi. Zawiera obszerną dokumentację dotyczącą tworzenia plug-in’ów na przykład do samoładowania istniejących mechanizmów uwierzytelniania czy uruchamiania billingu, gdy certyfikat jest opublikowany. Aby wykonywać rutynowe zadania związane ze zdalnym zarządzaniem, administratorzy mogą stosować albo Red Hat Management Console albo szereg nadzędzi administracyjnych i testowych linii poleceń.

Wsparcie rządowe (US)

Wcześniejsza wersja silnika enkrypcji Network Security Services (NSS) stosowana zarówno w Red Hat Directory Server jak i w Red Hat Certificate System, była certyfikowana według FIPS 140-1 poziomy 1 i 2. FIPS 140-1 Poziom 3 wymaga zewnętrznego HSM. Red Hat jest zaangażowane w trwającą certyfikację HSM z kilkoma sprzedawcami. W roku 2005 recertyfikacja FIPS 140-2 dla NSS jest już bardzo zaawansowana. Wcześniejsza wersja Red Hat Certificate System to NIAP Certyfikowana według Common Criteria CIMC (Certificate Issuance and Management Components) Profil Zabezpieczenia, poziom oceny 4 Rozszerzona. W roku 2005 rozpoczyna się przygotowanie recertyfikacji Common Criteria. Red Hat Certificate System stosowany jest do wydawania certyfikatów akceptowanych przez agencję Federal Bridge, mechanism węzła komunikacyjnego stosowanego przez agencje rządowe, by zapewnić rozpoznanie własnych CA. Aktualny produkt w pełni wspiera wymagania techniczne Federal Bridge włącznie z rozszerzeniem założeń a dla certyfikatu CA rozszerzeniem założeń mappingu. Red Hat Certificate System jest zgodny z normami opublikowanymi przez grupę roboczą Public Key Infrastructure (X.509) (PKIX) i wspiera wydawanie certyfikatów w rozszerzeniach Windowsa dla Windows Smartcard Logon, które wymagane są dla wielu wdrożeń rządowych. Aby być zgodnym z GSA E-Authentication Initiative, Red Hat planuje również dodać do przyszłych wersji wsparcie dla SAML