Jacek Jarmakiewicz (1,2), Tomasz Podlasek (1)

(1)

(2) Wojskowa Akademia Techniczna

autoryzacji w federacji systemów

informacyjnych z mechanizmami *

Zaprezentowano wyniki realizacji pr : zweryfikowanie koncepcji podsystemu

(PWB)

tworzonej przez instytucje administracji publicznej oraz zbadanie efektywn poufnej wymiana informacji

o ch poziomach . W wyniku

temów C4I

i Asseco Poland. PWB zapewnia

federacji systemów informacyjnych

. PWB jest

po etapie testowa

NC3A .

1. Wprowadzenie

MLS (MultiLevel Security) to cecha systemu

informacyjnego, z wykorzystaniem której zapewniono

w latach 70 [1,2] operacyjnego z wielopoziomowym

pod koniec lat 90 w ramach projektu SELinux

sponsorowanego przez NSA [3].

i

sterowany jest

uprawnienia

federacyjnych systemach informacyjnych ma szerszy

charakter od implementacji w systemach operacyjnych,

identyczne i opis jako „no read up”, i „no write down”.

i rmacje jego uprawnie .

y, mechanizm

wraz ze swoimi

serwisami do sieci Internet. Podobnie nternecie podmioty prywatne.

Na fny wirtualne sieci prywatne.

W celu efektywnego instytucji publicznych, firm i organizacji

mechanizmy . A

semantycznej przez automaty

sieciowe jest XML (Extensible Markup Language).

z wykorzystaniem zapór (firewall)

. Jest wiele sposobów a

, . W tym przypadku

ik zdalny musi s

certyfikatów, wpisów w LDAP) dynamiczna.

Innym,

informacji ponad zaporami sieciowymi jest nim HTTP. Z wykorzystaniem HTTP

w warstwie aplikacyjnej

uwierzytelniani z wykorzy autoryzowani do zasobów poprzez

elementy funkcjonalne XACML (eXtensible Access Control Markup Language).

Dla celów ów do zasobów informacyjnych w XACML

w ramach standardów organizacji OASIS opracowano elementy funkcjonalne

stosowanie polityki w stosunku do

i sprawdzenie t ci w wyniku procesu uwierzytelnienia

z wykorzystania mechanizmów OASIS WS-Security tj. tokenów i certyfikatów cyfrowych (zgodnie

z profilami o ).

2. Architektura systemu federacyjnego z mechanizmami

D e zasobów informacyjnych tworzenia

systemów federacyjn odanowych skonfederowanych

celu

[4].

strategia

poziomów ochrony (zgodnie z poli eksploatowane

procedurami [5-7].

e dzy odizolowanymi od siebie

jako [8]:

MILS (Multiple Independent Level Security) -

poziomach ochrony [9-11];

MLS – [11-13].

MILS MLS

Rysunek 1

Mandatory Access Control), administrator

witej kontroli nad

administratora

administratora danych .

federacyjny z mechanizmami MLS

polityk

iega si

z by

(schemat jaki DAC - Discretionary Access

Control).

Rysunek 2. Architektura fizyczna testowa federacji systemów informacyjnych z mechanizmami

W ramach prac projektowych w konsorcjum Systemów C4I) z Asseco Poland

Podsystem Wielopoziomowego B (PWB) dla federacji systemów

[14]:

elementach funkcjonalnych zaimplementowanych wg architektury XACML w zakresie

realizacji autoryzacji i obo [4];

ug webowych (Service Oriented Architecture) [15,16];

OASIS

WS-Trust opartej Security

Token Service);

mechanizmach uwierzytelniania

certyfikacji z wykorzystaniem standardu ITU-T X.509;

zapewnieniu ami

webowymi z wykorzystaniem asercji SAML zabezpieczonych funkcjami kryptografii

niesymetrycznej;

zgodnie z wzorcami [17-19];

ewidencjonowania wydawanych zasobów informacyjnych w dziennikach kancelarii

elektronicznych.

Architektura fizyczna (rys.2) PWB jest zrealizowana w oparciu o elementy, które

Elementy procesami autoryzacji w domenie informacyjnej: PEP (Policy

Enforcement Point) i Serwer Proxy, PDP (Policy Decision Point), PAP (Policy Administration

Point), PS (Policy Store).

federacji. W PS dane polityki

informacyjnych W PDP podejm

o zatwierdzeniu/odrzuceniu /odmowie wydania informacji

przez brokera wydawania informacji z bazy danych. Decyzja w PDP jest

podejmowana na

federacyjnych. Decyzja autoryzacji zwracana jest do PEP - Serwera Proxy (który

Elementy uwierzytelniania

oparte na PKI - Central

Authority Public Key Infrastructure STS - SAML,

X.509). PWB

, relacje zaufania i uprawnienia

w systemie informacyjnym.

w ramach w systemach informacyjnych.

Relacjami zaufania ustanowionymi z wykorzystaniem CA PKI/STS w ramach domen

informacyjnych .

i us zdefiniowani w CA PKI domen, którzy y X.509,

rozpatrywane przez elementy autoryzacji w W ramach

i p relacja

zgodnie z uprawnieniami.

Serwer bazy danych/Broker bezpiecznej wymiany etykietowanej ej wraz

z funkcjami szyfrowania i deszyfrowania informacji w BD oraz bezpiecznej wymiany

.

/przechowywania informacji

o wykorzystaniu zasobów informacyjnych w federacji systemów.

onych polityk

w drodze umów

.

Na rys. 3 oraz relacje powi zania

elementami. W domenie elementy funkcjonalne:

WSP (WEB Service Provider) - Serwerem

do informacji etykietowanych;

WSC (WEB Service Client) - aplikacja kliencka dla oraz

STS. Z wykorzystaniem z PWB;

Truststore - Baza ze zbiorem zaufanych certyfikatów X.509, która jest jedna, wspólna dla

pojedynczej domeny;

Keystore - Baza ze zbiorem certyfikatów X.509, która jest dedykowana

WSP i STS.

Komponenty :

Identity Provider -

STS (X.509) - komponent odpowiedzialny za uwierzytelnienie klientów w domenie

z wykorzystaniem certyfikatów X.509. Po poprawnym uwierzytelnieniu wystawiany jest

STS (SAML) - komponent odpowiedzialny za uwierzytelnienie klientów w domenie

z

SAML.

Rysunek 3. Diagram komponentów architektury funkcjonalnej PWB w domenie informacyjnej

Komponenty (XACML):

PEP - odpowiedzialn ;

PDP -

PAP - odpowiedzialn

Element serwisu katalogu sieciowego, LDAP Server - u

o

Element Bazy danych etykietowanych, DataBroker - Komponent odpowiedzialny za

etykietowanie zasobów informacyjnych [17] .

W ramach PWB

bazodanowymi

lub

w systemie PWB . Elementy funkcjonalne architektury

nych elementach fizycznych w

Na rys. 4 przedstawiono sekwencj

przypadku uwierzytelnienia w domen

docelowej.

Rysunek 4. Diagram sekwencji

informacyjnej PWB (1 scenariusz badawczy)

W przypadku pozytywnej weryfikacji w procesie uwierzytelniania

elowej (Target Service).

(informacji

W przypadku pozytywnym zwrotnie wydawana jest informacji. W takim przypadku

i szyfruje z wykorzystaniem klucza publicznego w relacji

( ) i kier procesów z rys. 4

.

w postaci diagramu

na rys. 5 wymienianych

zaimplementowanych systemów PWB (implementacja PWB – implementacja PWB Asseco

Poland). PWB

w domenie Asseco Poland.

cmp Konfig 4 PWB Component Model

ACP (ACP CA)

STS (X509) STS (SAML)

WSP

User Strore

truststore

PEP

PDP

PIP PolicyStore

PAP

Audit Log StoreWSC

IdentityProv ider

(5) ACP SAML

(7)

(3)

(19)

trust(6) ACP STS X509

(8) WIL SAML

trust

(4) ACP SAML

(2)

(11)(9) WIL SAML + Request

(18)

(1) ACP X509

(17)

(13)

(15)(14)

(12)

(16)

(10) WIL STS X509

internet

Rysunek 5. WI – Asseco Poland w scenariuszu u

do informacji

autoryzacji jest

przebiegu procesów:

(1) proces na kom

wraz z certyfikatem X.509;

(3) serwer katalogu LDAP zwraca komunikat o uwierzytelnieniu;

wystawienia

domeny macierzystej;

(8) w przypadku pozytywnej weryfikacji na podstawie asercji SAML, wydany zostaje nowy

Web Service Provider)

pr

jest podpisa

(14,15) w punkcie PDP wykonywana jest walidac

z

3. federacji systemów

informacyjnych

W ramach przedstawiono

i autoryzacji w federacji systemów informacyjnych.

[20] autoryzacji.

przebiegu scenariuszy zawarto przy okazji prezentacji architektury systemu PWB w punkcie 2

(rysunek 4 i 5) zaimplementowanych mechanizmów

realizowanych w federacji systemów:

1. Pierwszy scenariusz dotyczy autoryzacji do lokalnych zasobów informacyjnych PWB

w domenie macierzystej . . W procesie

weryfikowany jest

certyfikatem X.509 i tokenem do bazy informacji wra

XACML.

2. Drugi scenariusz dotyczy autoryzacji do zasobów informacyjnych w domenie

j sieci systemu federacyjnego (Asseco Poland).

z domeny. N z tokenem i z

z informacjami o Autoryzacja realizowana jest przez

elementy XACML DataBroker sprawdza u

zaetykietowanych informacyjnych.

Na wykresie 1 przedstawiono pomiary czasu realizacji procesu autoryzacji w macierzystej

domenie PWB .

Wykonano 60 pomiarów procesu autoryzacji. Z analizy wyników czasu autoryzacji

wy pomiary c

300[ms].

enariuszach pomiarowych.

Przy pierwszej autoryzacji proces trwa

[s]. ej

1 sekundy.

Czas pierwszej autoryzacji jest prawie 3- y jest to

Java i wykorzystanych frameworków, w którym zaimplementowano

PWB

ników w celu ich interpretacji, badania zrealizowano

zwrotnej.

W przypadk

Wykres 1. Czas autoryzacji w domenie macierzystej PWB

Na wykresie 2 przedstawiono wyniki pomiarów czasu au

w 60 autoryzacji

w przypadku przydzielania zasobów

Asseco Pola 150[ms]. Podobnie jak w poprzednim scenariuszu

badawczym realizacja za pierwszym razem trwa

znaczenie e wykonano wielokrotnie

a autoryzacji zabiera ok 1,5[s]

realizacji procesu autoryzacji.

Wykres 2. Czas autoryzacji z domeny

Z

Java (framework JAX-WS 2.1/2.2 i Metro 2.0/2.1), gdzie

e

i okres pierwszej realizacji.

4. Wnioski

–

pod yniki

efektywna.

Opracowane implementacje PWB poddano odowisku

badawczym konsorcjum i krajowym (BUMAR Elektronika). W czerwcu 2012r

implementacji PWB zosta

IABG (Niemcy) i [21].

Opisane przez konsorcjum

w .

*)

ch 2010-2012 jako projekt rozwojowy

Literatura

1. J.P.Anderson, Computer security Technology Planning Study, Project No. 6917, Electronic

System Division, AFSC, Bedford Massachusetts, 1972

2. D.E.Bell, L.J.La Padula, Secure Computer System: Unified exposition and Multics

interpretation, Project No. 522B, Mitre Corporation Bedford Massachusetts, 1976

3. National Security Agency, http://www.nsa.gov/research/selinux/

4. eXtensible Access Control Markup Language 3 (XACML) Version 2.0, OASIS Standard, 2005

5. stemów i sieci teleinformatycznych, wskazówki i zalecenia, DBBT=801A,

SKW BBTI, 2006

6. DBBT-801B, SKW BBTI, 2008

7. Zalecenia nych

DBBT804A, SKW BBTI 2009

8. P.Popadrowski, Architektura referencyjna Pod ,

ACP- , 2011

9. J.Rushby, Separation and Integration in MILS (The MILS Constitution), sponsored by US Air

Force Research Laboratory Computer Science Laboratory SRI International 2008

10. C.Boettcher, R.DeLong, J.Rushby, W.Sifre, The MILS Integration Approach to Secure

Information Sharing, IEEE Xplore 2008

11. L.Sauer, M.Maschino, J.Morrow, M.Mayhew, Towards Achieving Cross Domain Information

Sharing in SOA-enabled Environment Using MILS and MLS Technology, MILCOM IEEE

2009

12. J.Luo, M.Kang, An Infrastructure for Multi-Level Secure Service-Oriented Architecture (MLS-

SOA) Using the Multiple Single-Level Approach, NavalResearch Lab, 2009

13. Multi-Level Security Strategies for the Federal Government, LARSTAN Business Reports

2004

14. , Projekt

techniczny prototypu PWB, Prototyp podsystemu zapewnienia wielopoziomowego

, -ACP, 2011

15. G.Banakhani, J.Busch, C,Dumas,R.Fiske, B.Holden, H.Laegreid, R.Malewicz, D.Marco-

Mompel, V.Rodgiguez-Herola, WEB Trends and Technologies and NNEC Core Enterprise

Services –v.2.0, NATO C3 Agency, Hague 2006

16. A.Singhal, T.Winograd, K.Scarfone, Guide to Secure Web Services, Recommendations of the

National Institute of Standards and Technology, NIST U.S. Dep. Of Commerce, 2007

17. Projekt standardu tworzenia atrybutów i etykietowania danych.

-ACP, 2010

18. L.S.Oudkerk, NATO profile for the XML confidentiality label syntax, NATO C3 Agency, Ref.

Doc. 2903, 2009

19. S.Oudkerk, NATO profile for the binding of metadata to data objects, NATO C3 Agency, Ref.

Doc. 2977, 2010

20. Web Services Quality Factors Version 1.0, OASIS, 2011

21. http://www.diit.wp.mil.pl/pl/26.html