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] sponsorowanego przez NSA [3]. operacyjnego z wielopoziomowym pod koniec lat 90 w ramach projektu SELinux 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 sieciowe jest XML (Extensible Markup Language). semantycznej przez automaty
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 strategia [4]. celu 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 Na rys. 4 przedstawiono sekwencj przypadku uwierzytelnienia w domen docelowej.. Elementy funkcjonalne architektury nych elementach fizycznych w 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) (2) trust User Strore IdentityProvider (3) STS (X509) STS (SAML) trust (7) (6) ACP STS X509 (5) ACP SAML (4) ACP SAML (1) ACP X509 (8) WIL SAML WSP truststore (18) (10) WIL STS X509 (9) WIL SAML + Request PEP (11) WSC (16) Audit Log Store (19) (17) (12) PIP (13) PolicyStore internet (14) (15) PDP PAP Rysunek 5. WI Asseco Poland w scenariuszu u do informacji przebiegu procesów: (1) proces na kom autoryzacji jest 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 pr Web Service Provider) 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 a autoryzacji zabiera ok 1,5[s] realizacji procesu autoryzacji. e wykonano wielokrotnie Wykres 2. Czas autoryzacji Z z domeny Java (framework JAX-WS 2.1/2.2 i Metro 2.0/2.1), gdzie e i 4. Wnioski pod okres pierwszej realizacji. yniki efektywna. Opracowane implementacje PWB poddano badawczym konsorcjum i krajowym (BUMAR Elektronika). W czerwcu 2012r odowisku
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