autoryzacji w federacji systemów informacyjnych z mechanizmami
Transkrypt
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