O dokumencie IDA Authentication Policy

2008-06-03 00:00:00 +0100


Dokument IDA Authentication Policy został opublikowany w ramach projektu Interchange of Data between Administrations (IDA). Jego celem jest standardyzacja procedur, w tym mechanizmów technicznych, na potrzeby systemów używanych w administracji publicznej Unii Europejskiej. Autorem dokumentu Authentication Policy jest firma Siemens, zaś sam dokument jest poświęcony metodologii tworzenia polityk uwierzytelnienia użytkowników tych systemów w sposób odpowiadający wadze prowadzonych przez nie procedur.

Podstawowym założeniem dokumentu jest racjonalna równowaga pomiędzy wagą przetwarzanej informacji, a siłą mechanizmów zabezpieczających. Waga informacji jest określana przez jej klauzulę tajności, w sposób zbliżony do polskich przepisów o informacji niejawnej, tyle że operującą na klauzulach europejskich. Dokument posługuje się miejscami nieco hermetycznym systemem pojęciowym, ale przy odrobinie dobrej woli łatwo można rozszyfrować np. "sectoral application" jako dowolną aplikację, z której korzystają użytkownicy, a "telematic network" jako po prostu Internet.

Analizowany jest proces składający się z następujących kroków, których celem jest uprawnione uzyskanie dostępu do informacji przetwarzanej w systemie:

  1. Faza rejestracji użytkownika, podczas której jest potwierdzana jego tożsamość i zostają mu przekazane dane uwierzytelniające ("electronic credentials"). Odbywa się to w następujących krokach:
    1. Weryfikacja i potwierdzenie faktycznej ("real-world") tożsamości podmiotu.
    2. Przekazanie tokenu użytkownika, przy czym przez token IDA rozumie klucz prywatny, PIN lub inne tego typu dane. Token jest "czymś co użytkownik posiada i nad czym ma kontrolę" i sam z siebie nie daje dostępu do systemu, dopóki nie zostanie zakończony proces rejestracji. "Dostarczenie tokenu" może np. polegać na wygenerowaniu klucza prywatnego w systemie użytkownika przez odpowiednią aplikację webową.
    3. Dostarczenie danych uwierzytelniających ("electronic credentials"), związanych z tokenem i poświadczonych przez urząd rejestrujący, które umożliwiają dokonanie uwierzytelnienia w systemie. W szczególności może to być na przykład certyfikat X.509, bilet Kerberosa czy "biletu" SAML ("SAML assertion").
  2. Faza uwierzytelnienia ("electronic authentication"), podczas której potwierdzana jest tożsamość użytkownika zadeklarowana przez niego przy dostępie do systemu. Odbywa się to za pomocą dowodu posiadania danych uwierzytelniających ("proof of posession").

Terminologia stosowana w opisie powyższego procesu stoi na wysokim poziomie abstrakcji ze względu na staranie autorów by zachować neutralność technologiczną. Widać wyraźnie, że starają się oni pozostać w zgodzie zarówno z terminologią stosowaną przy uwierzytelnieniu za pomocą podpisu cyfrowego jak i za pomocą protokołów federacji tożsamości takich jak SAML.

W opisie procesu uwierzytelnienia ("authentication") autorzy wyraźnie podkreślają, że nie obejmuje on autoryzacji, czyli określenia szczegółowego zakresu uprawnień podmiotu. Określenie uprawnień powinno być realizowane przez oddzielny proces autoryzacji ("authorisation"), który potwierdzi czy uwierzytelniony już użytkownik np. Jan Kowalski ma prawo czytać dokumenty zastrzeżone dla grupy X czy nie. Jest to problem, którego różne rozwiązania w e-Deklaracjach i ZUS wygenerowały sporo dyskusji (patrz "Co poświadcza certyfikat czyli brak autoryzacji w ZUS").

Różne procedury potwierdzania tożsamości oraz uwierzytelnienia charakteryzują się różnym poziomem pewności co do deklarowanej tożsamości użytkownika ("level of assurance in the asserted identity"). Oczywiście, intuicyjnie zawsze pożądany jest jak najwyższy poziom pewności. Niestety, co do zasady, im wyższy poziom pewności, tym bardziej procedura jest bardziej skomplikowana, czasochłonna i kosztowna.

Stąd autorzy zakładają stosowanie poziomu pewności odpowiedniego do ryzyka szkód wywołanych błędnym uwierzytelnieniem ("appropriate level of assurance"). Jest to osiągnięte przez wybór technologii, która spełnia określone warunki na minimalnym wymaganym poziomie, odpowiednim dla określonego poziomu pewności. Innymi słowy, zastosowany mechanizm uwierzytelnienia nie może być zbyt słaby w stosunku do wymagań procedury administracyjnej, nie może też być zbyt wymagający bo wygeneruje nieracjonalne koszty. Musi być po prostu - odpowiedni ("appropriate").

Wybór mechanizmów spełniających ten postulat odbywa się przez zbudowanie polityki uwierzytelnienia ("authentication policy") dopasowanej do konkretnego zastosowania (np. aplikacji). Budowanie polityki odbywa się w następujących krokach:

  1. Przeprowadzenie oceny ryzyka ("rapid risk assessment") dla danej aplikacji lub systemu. Obejmuje to określenie potencjalnych zagrożeń dla systemu i strat przez nie spowodowanych w przypadku ich zajścia.
  2. Wyznaczenie odpowiedniego poziomu pewności uwierzytelnienia wymaganego dla systemu na podstawie wyznaczonych zagrożeń w celu zminimalizowania prawdopodobieństwa ich zajścia.
  3. Wybór konkretnych procedur i technologii, które na minimalnym wymaganym poziomie zapewniają wyznaczony poziom pewności.
  4. Podpisanie umów o wzajemnej uznawalności mechanizmu uwierzytelnienia (krok specyficzny dla IDA).
  5. Weryfikacja, czy wdrożony system lub procedura istotnie zapewnia wymagany poziom pewności.
  6. Cykliczne powtarzanie oceny bezpieczeństwa systemu stosownie do postępu technologicznego.

W dalszej części dokument IDA proponuje się szczegółową procedurę realizacji poszczególnych kroków.

Poziom pewności uwierzytelnienia ("authentication assurance levels") jest zdefiniowana jako wypadkowa dwóch czynników:

Na przykład, mamy mechanizmy potwierdzenia tożsamości o różnym poziomie pewności (przykład nie pochodzi z IDA):

  1. najniższy - weryfikacja adresu email, zaufanie do tożsamości zadeklarowanej przez użytkownika,
  2. niski - obraz dowodu osobistego osoby przesłany faksem,
  3. średni - ksero dowodu osobistego z własnoręcznym podpisem przesłane listem poleconym,
  4. wysoki - osobiste stawiennictwo z dowodem osobistym.

Powyższy przykład obrazuje różne poziomy pewności dla mechanizmu potwierdzenia tożsamości na etapie rejestracji użytkownika (pochodzi z polityk certyfikacji I-IV niekwalifikowanego drzewa Certum).

Z różnymi poziomami zaufania wiąże się oczywiście różny koszt ich realizacji, który rośnie on wraz ze wzrostem pewności. Z tego powodu nie można zawsze stosować najwyższego poziomu pewności i należy dostosować go do wymagań systemu. Dokument IDA Authentication Policy uwzględnia to posługując się pojęciem "odpowiedniego poziomu pewności" oraz postulując wybór takiego rozwiązania technicznego, które realizuje ten odpowiedni poziom w "minimalnym wymaganym stopniu". IDA definiuje cztery poziomy pewności numerowane od 1 (najniższy) do 4 (najwyższy).

Dalsza część dokumentu poświęcona jest na szczegółową analizę ryzyka, która opieraja się o europejskie klauzule informacji niejawnej i prowadzi do wyznaczenia odpowiednich poziomów pewności dla poszczególnych klauzul. Fragmenty mocno przywiązane do europejskiej praktyki urzędowej można jednak łatwo zastąpić wyliczeniami dostosowanymi do lokalnych potrzeb.

Interesujące zestawienie stanowi katalog ryzyk ("identification of risks"), opisujący czternaście pozycji, które zgodnie z polską terminologią właściwiej byłoby określić "zagrożeniami" (PN-I-02000:2002) i które zawierają takie pozycje jak np. "kradzież tokenu", "uzyskanie danych uwierzytelniających dla fikcyjnej tożsamości" czy "przekazanie danych uwierzytelniających dla istniejącej tożsamości nieuprawnionej osobie". W dalszej części następuje określenie rodzajów szkód ("damages") oraz definicja poziomów szkodliwości ("impact") i prawdopodobieństwa ich wystąpienia ("likelihood").

Za pomocą mapy ryzyka (bardziej/mniej szkodliwe vs bardziej/mniej prawdopodobne) określa się odpowiednie poziomy pewności mające spowodować, że ryzyko zajścia poszczególnych zagrożeń stanie się akceptowalnie małe. Ze względu na to, że dokument porusza się cały czas w kontekście mechanizmów uwierzytelnienia dla zdalnego połączenia do systemu teleinformatycznego dla niektórych kombinacji o najwyższym współczynniku prawdopodobieństwa-szkodliwości w ogóle zabrania się dokonywania takich połączeń.

Katalog mechanizmów uwierzytelnienia branych pod uwagę zawiera następujące tokeny (pamiętamy cały czas o definicji "tokenu" opisanej powyżej):

  1. Hasła lub kody PIN
  2. Hasła jednorazowe z generatorów sprzętowych (np. SecurID, SafeWord)
  3. "Programowe" klucze kryptograficzne, czyli klucze przechowywane w systemie operacyjnym lub nośnikach pamięciowych, zabezpieczone hasłem
  4. "Sprzętowe" klucze kryptograficzne, przechowywane w kartach elektronicznych zapewniających ochronę przed nieuprawnionym użyciem (PIN) oraz skopiowaniem.

Dokument nie przedstawia konkretnej propozycji polityki uwierzytelnienia, ponieważ nie operuje na żadnej konkretnej aplikacji. Oferuje natomiast gotowe arkusze pozwalające na mapowanie ryzyka w przypadku aplikacji o znanych założeniach, oraz przykład ogólnego określenia zasad korzystania z systemu, mogący stać się podstawą do zbudowania własnej polityki.

Źródło: