autoryzacji w federacji systemów informacyjnych z mechanizmami

autoryzacji w federacji systemów informacyjnych z mechanizmami

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
informacyjnego, z wykorzystaniem której zapewniono
w latach 70 [1,2]
Security)
to
cecha
systemu
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.
fny wirtualne sieci prywatne.
Na
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
systemów federacyjn
e zasobów informacyjnych
tworzenia
odanowych skonfederowanych
celu
[4].
strategia
poziomów ochrony (zgodnie z poli
procedurami
eksploatowane
[5-7].
dzy odizolowanymi od siebie
e
jako [8]:
MILS (Multiple Independent Level Security) poziomach ochrony [9-11];
MLS –
MILS
Rysunek 1
[11-13].
MLS
Mandatory Access Control), administrator
witej kontroli nad
administratora
administratora
danych
.
federacyjny z mechanizmami MLS
polityk
iega si
z
(schemat jaki
Control).
by
DAC - Discretionary Access
Rysunek 2. Architektura fizyczna testowa federacji systemów informacyjnych z mechanizmami
Systemów C4I) z Asseco Poland
W ramach prac projektowych w konsorcjum
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
Authority Public Key Infrastructure
X.509).
PKI - Central
STS - SAML,
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
ip
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
PEP - odpowiedzialn
PDP -
(XACML):
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
i
(
informacji. W takim przypadku
szyfruje z wykorzystaniem klucza publicznego w relacji
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.
) i kier
cmp Konfig 4 PWB Component Model
ACP (ACP CA)
(2)
trust
IdentityProv ider
User Strore
STS (X509)
STS (SAML)
(3)
(6) ACP STS X509
trust
(7)
(5) ACP SAML
(4) ACP SAML
(8) WIL SAML
truststore
WSP
(1) ACP X509
(18)
(10) WIL STS X509
PEP
(9) WIL SAML + Request
(11)
(16)
WSC
(19)
Audit Log Store
(17)
(12)
PIP
PolicyStore
(13)
internet
(14)
(15)
PAP
PDP
WI – Asseco Poland w scenariuszu
Rysunek 5.
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)
z
w
punkcie
PDP
wykonywana
jest
walidac
3.
informacyjnych
federacji systemów
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.
y
jest to
Czas pierwszej autoryzacji jest prawie 3Java i wykorzystanych frameworków, w którym zaimplementowano
PWB
ników w celu
zwrotnej.
W przypadk
ich interpretacji, badania zrealizowano
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
badawczym konsorcjum i krajowym (BUMAR Elektronika). W czerwcu 2012r
odowisku
implementacji PWB zosta
IABG (Niemcy) i
Opisane przez konsorcjum
w
[21].
.
*)
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 (MLSSOA) 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.MarcoMompel, 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