Zapewnienie współpracy międzydomenowej z wykorzystaniem metod etykietowania

Przedstawione zostały implementacje dwóch sposobów etykietowania: gdy etykieta dokumentu zawarta jest w oddzielnym pliku oraz gdy etykieta zawarta jest w ramach dokumentu. Pierwsza z implementacji umożliwia tworzenie etykiety bezpieczeństwa dla plików dowolnego typu. Druga daje możliwość tworzenia wiadomości zgodnej ze standardem NFFI (ang. NATO Friendly Force Information).

Współpraca między systemami wiąże się jednoznacznie z wymianą posiadanych przez nie zasobów. Ze względu na różny poziom wrażliwości dokumentów oraz zakres dostępu użytkowników istnieje konieczność wprowadzenia mechanizmu odpowiedzialnego za selektywne udostępnianie zasobów informacyjnych. Jednym z mechanizmów wspierających bezpieczne korzystanie z informacji i usług jest etykietowanie danych.

Etykieta jest zbiorem właściwości związanych z opisywanym zasobem, a jej zawartość uzależniona jest od zastosowania. Informacje zawarte w etykiecie mogą być wykorzystywane do określenia kontroli dostępu, środków ochrony, wskazania referencji, a także przydatne podczas katalogowania i archiwizacji.

Etykieta po raz pierwszy została wprowadzona w celu realizowania mechanizmu ścisłej kontroli dostępu MAC (ang. Mandatory Access Control). Przydzielanie dostępu do obiektu odbywa się na podstawie porównania uprawnień użytkownika z etykietą obiektu. Większość opracowanych do tej pory systemów etykietowania dotyczy etykietowania plików będącymi dokumentami XML (ang. Extensible Markup Language).

Wyróżnia się trzy sposoby etykietowania przedstawione na rysunku 1. W pierwszym z nich (a) etykieta dokumentu zawarta jest w oddzielnym pliku. W tym przypadku, w przeciwieństwie do dwóch następnych, konieczne jest umieszczenie w etykiecie informacji o tym, jakiego dokumentu dotyczy (informacji wiążącej z dokumentem). W drugim przypadku etykieta zawarta jest w ramach dokumentu (b). Trzeci przypadek (c) jest niejako przeciwieństwem drugiego. Ten sposób etykietowania polega na tym, że to dokument zawarty jest w ramach etykiety.

Rys. 1. Sposoby etykietowania informacji

W artykule przedstawione zostały implementacje dwóch spośród trzech wyżej omówionych sposobów etykietowania. Pierwsza z nich realizuje sposób (a) i umożliwia tworzenie etykiety bezpieczeństwa dla dowolnej wiadomości. Druga z implementacji daje możliwość tworzenia wiadomości zgodnej ze standardem NFFI (ang. NATO Friendly Force Information). Standard przewiduje zawarcie etykiety wewnątrz wiadomości NFFI, zatem jest ona adaptacją sposobu (b).

Stworzone oprogramowanie do generowania etykiety bezpieczeństwa obsługuje dowolny typ wiadomości. Wygenerowana etykieta zawiera metadane oraz jednoznaczne przypisanie jej do określanego zasobu poprzez zawarcie w niej identyfikatora URI (ang. Uniform Resource Identifier) pliku oraz jego skrótu. Dodatkowo zapewniona jest jej integralność oraz niezaprzeczalność utworzenia, poprzez zastosowanie podpisu cyfrowego zgodnego ze standardem XML DSIG (ang. Digital Signature).

Druga z opracowanych implementacji jest usługą webową, która umożliwia przetworzenie zasobów informacyjnych pochodzących z usługi położenia wojsk własnych BFT (ang. Blue Force Tracking). Informacja o położeniu wojsk oraz informacja etykietująca zawarte są w ramach wiadomości utworzonej zgodnie ze standardem NFFI. Poszczególne pola w pojedynczej wiadomości NFFI zostały opisane  metadanymi (elementami etykiety) znajdującymi się również wewnątrz tej wiadomości. Metadane wskazują poziom tajności danych pól wiadomości NFFI. Umieszczenie etykiety w ramach wiadomości jest zgodne ze standardem zawartym w [3].

Etykietowanie zasobów informacyjnych

Zasoby przechowywane i przesyłane w systemach ze względu na swoją różnorodną treść powinny posiadać ograniczenia dotyczące ich udostępniania. Dla określenia poziomu ochrony owych zasobów konieczna jest ich klasyfikacja, określająca ważność zasobu. Na jej podstawie możliwe jest stwierdzenie, czy dane zasoby informacyjne mogą być udostępniane wszystkim użytkownikom, czy też ograniczonej
grupie posiadającej odpowiednie uprawnienia.

Przypisanie poziomu wrażliwości każdemu z zasobów bądź też poszczególnym jego elementom umożliwia podjęcie decyzji, czy mogą być one współdzielone przez konkretnych użytkowników posiadających określony poziom dostępu. Konieczne jest więc, aby klasyfikacja danych była na tyle szczegółowa, aby w łatwy sposób możliwe było przypisanie danym odpowiadającej im klasy.

Poziom wrażliwości wyznaczony w procesie klasyfikacji danych powinien być przypisany do zasobu. Można tego dokonać za pomocą etykiety. Na jej podstawie odbywa się udostępnianie, bądź też nie, danego zasobu użytkownikom posiadającym odpowiedni poziom dostępu.

Etykietowanie danych ma szczególne znaczenie w przypadku wymiany informacji w środowisku wielodomenowym. Środowiskiem wielodomenowym nazywamy system, w którego skład wchodzą systemy heterogeniczne często o odrębnych poziomach wrażliwości oraz innych politykach bezpieczeństwa. Praca owych systemów polega na współdziałaniu oraz współdzieleniu zasobów. Etykieta informacji przesyłanych miedzy domenami powinna zawierać:

• poziom wrażliwości zasobu bądź poszczególnych jego części, określający możliwość jej udostępniania,
• identyfikator polityki pozwalający określić, który organ odpowiedzialny jest za oznakowanie zasobu oraz według jakich zasad został określony jego poziom wrażliwości. Pozostałe elementy etykiety uzależnione są od jej zastosowania.

W przypadku etykiety bezpieczeństwa powinna ona zawierać wszelkie niezbędne informacje umożliwiające określenie, w jaki sposób powinny być obsługiwane dane oraz jaka powinna być ich droga transmisji bez posiadania informacji o jej treści. Jest to szczególnie ważne w przypadku informacji szyfrowanych. Informacje zawarte w etykiecie mogą być wykorzystane do kontroli dostępu, określenia  środków ochronnych oraz ustalenia obsługi ograniczeń komunikacji określonych przez politykę bezpieczeństwa [4,5]. Etykieta bezpieczeństwa zasobów wykorzystywana jest w celu ustalenia sposobu obsługi danych przekazywanych między systemami (użytkownikami). System etykietowania ma za zadanie umożliwić wygodne współdzielenie zaszyfrowanych zasobów oraz stworzyć przejrzystą strukturę, w której użytkownicy pełniący określone funkcje mają dostęp do ściśle określonych informacji.

Opis implementacji etykiety bezpieczeństwa

Koncepcja dedykowanej etykiety bezpieczeństwa

Etykieta zasobu informacyjnego powinna spełniać określone wymagania, aby zapewnić maksymalną funkcjonalność oraz bezpieczeństwo. Ważną wymaganą cechą, którą powinna posiadać etykieta jest jej wszechstronność zastosowania. Musi istnieć możliwość tworzenia etykiety dla każdego typu zasobu bez względu na sposób jego opisu.

Podstawowymi elementami etykiety, jak już wspomniano wcześniej, jest poziom wrażliwości zasobu oraz identyfikator polityki bezpieczeństwa domeny, z której dany zasób pochodzi. Etykieta powinna być opatrzona skrótem, który uniemożliwia przypadkową bądź zamierzoną modyfikację treści etykiety oraz podpisem cyfrowym autora. Dodatkowo może ona zawierać skrót i podpis elektroniczny całego  dokumentu. Umożliwia to rozróżnienie między podpisem zasobu wskazującym autorstwo oraz podpisem na etykiecie, który wskazuje organ, który dokonał klasyfikacji dokumentu. Etykieta prócz informacji dotyczących bezpieczeństwa powinna również zawierać podstawowy opis dokumentu, który opisuje tzn. tytuł, autora, krótki opis zawartości, ID zasobu, jego rozmiar oraz typ (rys. 2). Informacje zawarte w etykiecie powinny być wystarczające dla określenia grupy użytkowników, którzy mogą mieć dostęp do danego zasobu.

Etykieta bezpieczeństwa zasobu jest oddzielnym plikiem XML, dlatego też konieczne jest jednoznaczne określenie współzależności obu elementów. Zostało to zapewnione poprzez zawarcie wśród elementów znajdujących się w etykiecie „odniesienia”, które będzie wskaźnikiem URI odnoszącym się do danego zasobu. Dodatkowym potwierdzeniem, iż dana etykieta dotyczy owego zasobu jest umieszczona w niej wartość skrótu pliku.

Rys. 3. Powiązanie etykiety z dokumentem

Opis etykiety w RDF

RDF (Resource Description Framework)[6] jest strukturą służącą do reprezentacji zasobów w sieci. Zadaniem RDF jest zapewnienie łatwo przetwarzanej treści zasobów przez programy komputerowe. Dzięki temu, zastosowanie języka RDF do opisu etykiety zasobu, umożliwia stworzenie systemu, w którym decyzje o udostępnianiu zasobów będą podejmowane przez serwery, na podstawie weryfikacji informacji zawartych w etykiecie bezpieczeństwa oraz uprawnień użytkowników.

Rys. 4. Graf RDF etykiety

RDF pozwala opisać zasoby określając ich właściwości oraz przypisując im odpowiadające wartości. Umożliwia to przedstawienie zasobu w postaci grafu, składającego się z wierzchołków oraz nazwanych połączeń między nimi reprezentujących zasoby oraz ich właściwości i wartości.

Proces generowania etykiety

Program generujący dedykowaną etykietę bezpieczeństwa został napisany jako aplikacja Java i posiada łatwy do obsługi interfejs graficzny, który umożliwia w prosty sposób wprowadzenie wszystkich parametrów wejściowych. Utworzona etykieta dla dokumentów dowolnego typu zapisywana
jest w postaci pliku XML.

Program na podstawie podanych parametrów dokonuje obliczenia skrótu pliku, jego podpisania, uzupełnienia danych dotyczących pliku i stworzenia etykiety, która następnie zostaje podpisana zgodnie ze standardem W3C XML Signature (rys. 5).

Rys. 5. Procedura generowania etykiety

Etykieta tworzona jest na podstawie informacji uzupełnionych przez użytkownika odnośnie konkretnego pliku. Na ich podstawie oraz właściwości pliku, wypełniana jest część etykiety zawierająca informacje dotyczące pliku. Podpis pliku dokonywany jest przy użyciu klucza wskazanego przez użytkownika. Do etykiety dołączana jest także informacja o identyfikatorze polityki bezpieczeństwa. Proces tworzenia etykiety zależny jest od typu pliku. W przypadku plików XML, najpierw sprawdzane jest czy dokument nie jest opatrzony już podpisem, wówczas nie jest konieczne, a wręcz niewskazane tworzenie ponownego jego podpisu. W przypadku braku podpisu, jest on tworzony według standardu W3C XML Signature. Dla plików innych typów, część etykiety związana z podpisem pliku ma postać odmienną, ustaloną w dokumencie XML Schema etykiety.

Na koniec etykieta zostaje podpisana według standardu XML Signature [7], który zawiera skrót, podpis oraz dane dotyczące certyfikatu autora podpisu. Do podpisu etykiety może być wykorzystany odrębny klucz, bądź ten sam co do podpisu pliku.

Wykonanie oprogramowania

Postać etykiety została określona w XML Schema. Nie ma w niej określonej części dotyczącej podpisu, ponieważ jest on dodawany przez narzędzia biblioteki javax.xml. crypto.dsig [8].

List.1. Zawartość wygenerowanej etykiety

Na podstawie Schemy, wykorzystując JAXB (Java Architecture for XML Binding) [9], tworzone są obiekty danych klas, które następnie za pomocą serializacji zamieniane są na XML. Dla wskazanego pliku określany jest typ Mime, ogólny typ pliku, jego rozmiar i w przypadku plików image oraz video ich rozdzielczość.

Ważną własnością pliku, dla którego tworzymy etykietę oraz samej etykiety jest ich integralność. Integralność jest cechą określającą, że dane nie uległy zmianie w nieautoryzowany sposób od czasu ich utworzenia. Metodą zapewniającą integralność jest wykorzystanie funkcji skrótu. Funkcja
skrótu jest to funkcja jednokierunkowa, która przyporządkowuje wiadomości o dowolnej długości wartość, o stałym rozmiarze, na podstawie której nie jest możliwe określenie zawartości wiadomości.

Prócz integralności etykiety konieczne jest również zapewnienie niezaprzeczalności jej utworzenia, gwarantujące możliwość potwierdzenia autora etykiety stanowiąc dowód pochodzenia danych, który jest weryfikowalny przez stronę trzecią. Mechanizmem zapewniającym niezaprzeczalność jest podpis cyfrowy, wykorzystujący algorytmy kryptograficzne funkcji skrótu i szyfrowania asymetrycznego oraz  klucze, których długości gwarantują bezpieczeństwo informacji.

Możliwymi do wyboru w programie algorytmami podpisu cyfrowego dla plików nie będących plikami XML są:

• MD2withRSA,
• MD5withRSA,
• SHA1withDSA,
• SHA1withRSA.

Owe algorytmy są bowiem wspierane przez usługę kryptograficzną Signature w wybranym dostawcy - Bouncy Castle [10].

W celu stworzenia podpisu pobierany jest klucz prywatny oraz powiązany z nim certyfikat.
Program sprawdza aktualność każdego certyfikatu oraz w przypadku zabezpieczenia hasłem poprawność wprowadzonego hasła. Obsługiwanymi rozszerzeniami plików kluczy są .pem i .p12.

W przypadku, gdy plikiem dla którego tworzona jest etykieta jest plik XML, po rozpoznaniu jego typu jest on pobierany jako Document DOM. Obiekt Document stanowi w DOM ogólny sposób reprezentowania dokumentów XML. W związku, że pliki XML bardzo często posiadają już podpis,  sprawdzane jest czy istnieje już w dokumencie węzeł Signature. Jeśli plik posiada podpis jest on  pobierany i wstawiany w odpowiednie miejsce etykiety.

Konsorcjum W3C stworzyło standard dotyczący podpisu plików XML: XML Signature zwany też XML-DSIG. Dlatego też w przypadku braku podpisu pliku XML będzie on generowany według tego standardu podobnie jak podpis etykiety, będącej plikiem XML. Do tworzenia podpisu XML została wykorzystana biblioteka javax.xml.crypto.dsig, która umożliwia automatyczne tworzenie podpisu według standardu W3C.

Opis implementacji informacji etykietujących w ramach wiadomości tworzonych zgodnie ze standardem NFFI

Opis koncepcji systemu BFT

System BFT (ang. Blue Force Tracking) składa się z naziemnych sensorów śledzących i na bieżąco automatycznie przedstawiających informację drogą służbową o położeniu jednostek oraz ich statusie. Informacje przekazywane są w czasie zbliżonym do rzeczywistego. Śledzonymi obiektami są na ogół pojazdy oraz przemieszczający się żołnierze wojsk koalicyjnych, jednakże śledzenie samolotów z  wykorzystaniem BFT jest również możliwe. Technicznie nic nie stoi na przeszkodzie, żeby BFT zostało zastosowane nie tylko do śledzenia wojsk własnych, ale także jednostek wojsk przeciwnika.

Pełna automatyzacja przetwarzania danych BFT jest podstawową koncepcją systemu FFTS (ang. Friendly Force Tracking System). Zakłada się [3], że urządzenia BFT będą automatycznie generować dane, dzięki czemu możliwe będzie ograniczenie działania czynnika ludzkiego do zarządzania, konfiguracji oraz kontroli.

Opis formatu wiadomości NFFI

Wiadomości NFFI zawierają dane obiektu, dotyczące jednostki (wojskowej) - może ona odpowiadać pojedynczemu żołnierzowi, grupie żołnierzy, a nawet kolumnie czołgów. Wiadomość NFFI może być pusta (brak obiektu), zawierać jeden obiekt lub dane o wielu obiektach. Obiekt składa się z czterech sekcji zaprezentowanych na rysunku 6.

Rys. 6. Struktura wiadomości NFFI

• Dane pozycji (ang. positionalData Section) – podstawowe dane identyfikacyjne pozycji obiektu. Zawierają zestaw elementów, które razem tworzą minimum porcji danych pozycjonujących jeden obiekt. Każdy obiekt wchodzący w skład etykiety NFFI musi zawierać tę sekcję.
• Dane identyfikacyjne (ang. identificationData Section) – elementy tej grupy mają za zadanie zapewnić identyfikację jednostek skojarzonych z danymi zawartymi w sekcji Danych pozycji. Zgodnie z definicją schematu NFFI ta sekcja jest sekcją opcjonalną.
• Dane operacyjne statusu (ang. operStatusData Section) – zapewniają informacje o statusie operacyjnym jednostek („śladów”) powiązanych z danymi z sekcji Danych pozycji. Wszystkie elementy tej sekcji są opcjonalne.
• Dane szczegółowe (ang. detailData Section) – uruchomienie tej sekcji wykorzystywane jest w celu przeprowadzenia w przyszłości informacji charakterystycznych dla mniejszych społeczności producentów i konsumentów. Szczegółowe dane dotyczące tej sekcji muszą być określone dla każdego zastosowania (przez każdą grupę interesów).

Na rysunku 7 przedstawione zostały funkcjonalności składowych sekcji, które są zgodne z przedstawioną legendą. Koordynaty (szerokość geograficzna, długość geograficzna, wysokość), położenie, prędkość oraz nachylenie są elementami, którym można nadać wartość atrybutu, mówiącego o dokładności wartości wskazanej przez element. Szerokość oraz długość geograficzna są elementami wymaganymi i podczas tworzenia wiadomości NFFI konieczne jest ich nadanie, natomiast nadanie wartości ich dokładności jest opcjonalne. W przypadku pozostałych elementów, którym można nadawać wartość atrybutu, zarówno samo ich wywołanie, jak i nadanie im wartości dokładności jest opcjonalne.

Rys. 7. Struktura sekcji Danych pozycji

Sekcje: Danych identyfikacyjnych, Danych operacyjnych statusu oraz Danych szczegółów są sekcjami opcjonalnymi. Ich struktura przedstawiona została kolejno na rysunkach 8, 9 i 10.

Rys. 8. Struktura sekcji danych identyfikacyjnych

Rys. 9. Struktura sekcji danych operacyjnych statusu

Rys. 10. Struktura sekcji danych operacyjnych statusu

Zawartość poszczególnych pól opisana została w [3] oraz [11]. Z punktu widzenia implementacji informacji etykietujących nie ma konieczności poznania znaczenia wszystkich pól wiadomości NFFI. Struktury wszystkich sekcji przedstawione zostały w celu przedstawienia ogólnego poglądu, w jaki sposób wyglądać powinna wiadomość.

Z punktu widzenia etykietowania informacji istotne są atrybuty dołączone do każdej sekcji, które umożliwiają identyfikację zastosowanej polityki bezpieczeństwa, wrażliwość danych zawartych w sekcjach oraz informacje dotyczące wrażliwości sekcji. Zastosowano poniżej wymienione atrybuty.

• Identyfikator zastosowanej polityki bezpieczeństwa — określa zakres dostępności wiadomości. Przykłady stosowanych oznaczeń: NATO, NATO/EAPC, NATO/PFP, NATO/EU, NATO/RUSSIA, NATO/UKRAINE.
• Klasyfikacja bezpieczeństwa — klasyfikacja poziomu wrażliwości informacji zawartych w ramach danej sekcji. Stosowane oznaczenia: UNMARKED, UNCLASSIFIED, RESTRICTED, CONFIDENTIAL, SECRET i TOP SECRET.
• Kategoria — wskazuje na dodatkowe, specyficzne wartości dotyczące wrażliwości sekcji etykiety. Może zawierać również informacje dotyczące kontroli rozpowszechniania lub oznaczyć informację, do której kontrola dostępu nie jest wykonywana automatycznie. Przykłady oznaczeń: ATOMAL, CRYPTO, SIOP, SIOP ESI, EXCLUSIVE, INTELLIGENCE, LOGISTICS, OPERATIONS.

Opis implementacji usługi webowej generującej wiadomość NFFI oraz jej integracji w ramach demonstratora technologicznego

Opisany format etykiety zgodny jest z zaproponowanym przez NC3A [3] opisem XML Schema wiadomości NFFI. Podczas implementacji tworzenia wiadomości NFFI w formacie XML wykorzystane zostały obiekty klas wytworzone automatycznie przez jedno z narzędzi środowiska JAXB. Podobnie jak przy pierwszej implementacji również i przy tej skorzystano z operacji szeregowania, która dokonała zamiany obiektów klas na dokument XML.

Pierwsza faza implementacji objęła wytworzenie programu, który lokalnie generował wiadomość NFFI składającą się tylko z wymaganych pól oraz parametrów etykiety. Wygenerowany program przetworzony został na Web Service o takich samych właściwościach. Usługa uruchamiana na lokalnym serwerze GlassFish umożliwiła utworzenie i zapisanie wiadomości NFFI do pliku. Zapytanie przesłane do usługi w postaci komunikatu SOAPRequest przedstawione zostało w listingu List. 2,

List. 2. Komunikat SOAP Request przesłany do usługi tworzenia wiadomości NFFI

natomiast utworzona wiadomość wraz z informacjami etykietującymi zaprezentowana została w listingu List. 3.

List. 3. Utworzona wiadomość NFFI

Można zauważyć, że jednym z atrybutów pola positionalData (dane pozycji) „śladu” utworzonego w ramach
wiadomości jest secClassification. Jego wartość została ustawiona na SECRET, dlatego informacje zawarte polu danych pozycji powinny być udostępniane jedynie tym użytkownikom, którzy mają równy lub wyższy poziom uprawnień.

Następnie podjęta została próba integracji usługi w ramach demonstratora technologicznego. Jednym z rozważanych scenariuszy było umieszczenie autonomicznej usługi odpowiedzialnej za nadanie danych etykietujących. Scenariusz ten przedstawiony został na rysunku 11.

Rys.11. Demonstrator SOA uzupełniony o usługę Nadania Informacji Etykietującej

Użytkownik chcący skorzystać z usługi pozycjonowania wojsk własnych BFT, po uwierzytelnieniu (1,2) przesyła zapytanie wraz ze swoim certyfikatem do usługi BFT (3). Certyfikat użytkownika podlega sprawdzeniu (4,5). Jeżeli jest ważny, wówczas BFT odwołuje się do bazy danych (6), w której zawarte są informacje dotyczące obiektów wojskowych. Tworzona jest wiadomość NFFI (7), a następnie dodawane są dane etykietujące (8,9). PWP (usługa Punktu Wymuszenia Polityki) sprawdza czy wrażliwość danych, których dotyczy zapytanie nie jest większa od uprawnień użytkownika.

Jeżeli użytkownik posiada wymagane uprawnienia PWP, przekazuje wiadomość do użytkownika.
Przedstawiony poniżej pierwszy z rozważanych scenariuszy, choć wydaje się spełniać wszystkie wymagania, ma pewne wady. Zadaniem Usługi Nadania Informacji Etykietującej byłoby w tym przypadku uzupełnienie wiadomości NFFI o pola etykietujące. Postawiono pytanie, czy nie lepiej przebudować usługę BFT tak, żeby to ona podczas tworzenia wiadomości NFFI automatycznie umożliwiała nadawanie
informacji etykietującej. Takie podejście byłoby zgodne ze standardem zawartym w [3].

Wstępna wersja standardu nie uwzględniała tworzenia pól umożliwiających etykietowanie, dlatego autor usługi BFT przy tworzeniu wiadomości NFFI nie uwzględnił możliwości tworzenia tych pól w ramach wiadomości. Wówczas wymiana informacji w celu udostępnienia użytkownikowi wiadomości NFFI byłaby szybsza i pozbawiona redundantnego wywołania Usługi Nadania Informacji Etykietującej.

Schemat wywołania usługi byłby wówczas następujący. Użytkownik po uwierzytelnieniu (1,2) odwołuje się do usługi BFT (3), która po sprawdzeniu ważności certyfikatu (4,5) tworzy wiadomość NFFI (6,7) wraz z etykietą. Utworzona wiadomość przekazywana jest do Usługi Punktu Wymuszenia Polityki, który decyduje o tym, czy wiadomość może zostać udostępniona użytkownikowi (10).

Wady i zalety implementacji

Zaletą implementacji generującej etykietę bezpieczeństwa jest możliwość tworzenia etykiety dla zasobów o dowolnym typie. Zawarte w etykiecie informacje pozwalają na weryfikację dostępu do zasobu użytkownikom posiadającym odpowiadające im poziomy wrażliwości, a także zapewniają jej integralność i niezaprzeczalność utworzenia. Etykietowanie jest mechanizmem ułatwiającym kontrolę dostępu do plików, dzięki przypisanej zasobowi etykiecie możliwe jest odczytanie jego poziomu wrażliwości, bez konieczności znajomości treści zasobu. Etykiety ułatwiają również wyszukiwanie plików, ze względu na zawarty w nich opis zasobów, oraz zapewniają ich integralność.

Wszelkie zmiany dokonane w dokumencie wiążą się ze stworzeniem nowej etykiety bezpieczeństwa, gdyż mogą się one przyczynić do zmiany poziomu wrażliwości pliku. Niedopasowanie etykiety do zmienionego pliku wiąże się z nieprawidłowym skrótem zawartym w etykiecie.

Ze względu na wymianę zasobów między domenami konieczne jest, aby zawarty w etykiecie poziom wrażliwości był jednakowo interpretowany przez obydwie strony. Klasyfikacja danych w obydwu domenach musi odbywać się według jednakowych zasad, bądź musi być ustalony sposób ich translacji. W przeciwnym przypadku informacja o poziomie wrażliwości będzie niewłaściwie odczytana i zasób może
zostać udostępniony osobom do tego nieupoważnionym. Możliwym w tym przypadku rozwiązaniem jest stworzenie mechanizmu odpowiedzialnego za translację poziomów wrażliwości według zasad dotyczących wymiany informacji zawartych w politykach bezpieczeństwa domen. Istotne jest zatem zawarcie w etykiecie informacji o zastosowanej polityce bezpieczeństwa. Kolejnym problemem napotkanym w implementacji generowania etykiety bezpieczeństwa było bezpośrednie powiązanie etykiety z plikiem. Ze względu na możliwość zmiany lokalizacji zasobu, zmienia się jego URI, dlatego dla pewnego sprawdzenia przyporządkowania etykiety do pliku konieczne jest porównanie skrótu zawartego w etykiecie oraz skrótu zasobu.

W przypadku dodawania informacji etykietującej do wiadomości NFFI znaczącą zaletą tego rozwiązania jest fakt, że zaproponowane rozwiązanie integrowane w ramach demonstratora technologicznego jest zgodne ze standardem i umożliwia etykietowanie informacji podczas wymiany z systemami innych domen. Umiejscowienie dodania informacji etykietującej w ramach usługi BFT w znacznie mniejszym stopniu zwiększa nakład informacji na wiadomość niż w przypadku zastosowania dodatkowej usługi etykietującej. Jest to znaczna zaleta rozwiązania, jednakże takie podejście umożliwia zastosowanie etykietowania tylko w celu klasyfikacji poziomów tajności poszczególnych pól wiadomości NFFI oraz zaznaczeniu, jakie państwo odpowiedzialne jest za ustanowienie polityki bezpieczeństwa dla wiadomości.
Wadą mechanizmu etykietowania dla obu implementacji jest fakt, iż wytworzone etykiety (lub dodanie informacji etykietującej w ramach NFFI) powodują zajęcie dodatkowych zasobów oraz obciążenie sieci.

Wnioski

Stworzony program generujący dedykowaną etykietę bezpieczeństwa umożliwia tworzenie etykiety dla dowolnego typu plików, wyróżniając pliki XML, dla których podpis pliku tworzony jest według standardu XML DSIG. Etykieta posiada podstawowe informacje dotyczące opisu pliku, zapewnia integralność pliku oraz integralność i niezaprzeczalność utworzenia etykiety. W miarę potrzeb użytkownika, możliwa jest późniejsza modyfikacja programu w celu uzupełnienia etykiety o dodatkowe informacje. Kolejnym etapem rozwijania programu będzie stworzenie oprogramowania w postaci usługi sieciowej umożliwiającej generowanie pojedynczych etykiet oraz wspólnej etykiety dla paczki przesyłanych plików.

Implementacja usługi webowej pozwala na tworzenie wiadomości NFFI wraz z polami umożliwiającymi etykietowanie. Praca nad integracją usługi dodawania informacji etykietującej do wiadomości NFFI doprowadziła do wniosku o konieczności modyfikacji usługi pozycjonowania wojsk własnych BFT. Modyfikacja usługi BFT umożliwi klasyfikowanie poziomów wrażliwości przesyłanych wiadomości w ramach współpracy z systemami domen innych państw. W przypadku budowy rzeczywistego systemu SOA na bazie demonstratora SOA należy zmodyfikować pozostałe usługi wchodzące w skład systemu, aby umożliwiały pełne wykorzystanie możliwości etykietowania.

Przedstawione w artykule implementacje etykietowania zasobów informacyjnych mogą być  wykorzystywane w rzeczywistych systemach, np. przez element brzegowy sieci IEG (ang. Information Exchange Gateway), które służą do filtracji ruchu pomiędzy heterogenicznymi domenami o różnych
poziomach wrażliwości. Zrealizowane implementacje są komplementarne do wprowadzonych już bazowych funkcjonalności IEG, np. uwierzytelnienia, autoryzacji, weryfikacji certyfikatów. W dalszej pracy dotyczącej etykietowania zasobów należałoby stworzyć mechanizmy odpowiedzialne za weryfikację dostępu do zasobów na podstawie informacji zawartych w stworzonych etykietach oraz poziomu dostępu użytkowników, a także translację poziomów wrażliwości w przypadku innych zasad klasyfikacji danych zawartych w domenowych politykach bezpieczeństwa.

AUTOR

Joanna Cichocka

Wojskowa Akademia Techniczna, Wydział Elektroniki, Instytut Telekomunikacji

Bartosz Jasiul, Grzegorz Kantyka

Wojskowy Instytut Łączności, Zakład Systemów C4I

LITERATURA