Gdy haseł przybywa

Kolejny problem związany jest z mnogością haseł. Oddzielne identyfikatory dla poszczególnych aplikacji nie są dobrym pomysłem, bo nie dość, że stanowią niewygodę dla użytkowników, to zarządzanie nimi generuje dodatkowe koszty. Jednak również zbytnia centralizacja nie wydaje się panaceum, bo w przypadku wykradzenia hasła postronna osoba uzyskuje dostęp do dużej liczby systemów i zawartych w nich informacji.

Owszem, mechanizmy jednokrotnego logowania (SSO - Single Sign-On) pozwalają uporządkować procesy zarządzania hasłami w firmie. Ale gdy zbyt wielu użytkowników zostanie obdarzonych szerokimi uprawnieniami, dodatkowo przypisanymi do jednego "superkonta" w aplikacji, może się okazać, że bezpieczeństwo informacji jest fikcją. Trzeba zatem mieć świadomość zarówno korzyści, jak i ograniczeń wynikających z zastosowanego rozwiązania, a także uwzględniać je w konstrukcji rozwiązań i procedur. SSO to dobry pomysł, ale rozpatrywanie takiego rozwiązania jako produktu do wdrożenia przez prostą instalację jest nieporozumieniem.

Bywa, że firma decyduje się samodzielnie zdefiniować jednolity mechanizm uwierzytelniania dla wszystkich aplikacji. Może to być np. usługa Web połączona z systemem profili użytkowników i profili aplikacji. W takim wypadku administrator ma swobodę decydowania, jak będą definiowane hasła w każdym systemie i czy będą centralne.

Ciekawe wyzwanie w dziedzinie uwierzytelniania i kontroli uprawnień niosą aplikacje zbudowane zgodnie z filozofią SOA. W takim modelu, z uwagi na brak pojęć sesji czy kontekstu, każde żądanie użytkownika będzie musiało zawierać porcję danych określających login/hasło czy jakiś klucz identyfikujący osobę.

Blaski i cienie DRM

Dotychczasowe rozważania dotyczyły kwestii dostępu do danych, a więc tego, by chronić dane przed niepowołanym dostępem za pośrednictwem aplikacji. Jeśli aplikacja pobierze dane, w większości przypadków użytkownik może z nimi zrobić praktycznie wszystko. Z punktu widzenia bezpieczeństwa jest to problem o tyle istotny, że coraz więcej zadań obróbki danych wykonywanych jest na laptopach, które można łatwo ukraść, by wszelkie zabezpieczenia rozpracować "na spokojnie".

Aby zapobiec łatwej kradzieży informacji tą metodą, powstały rozwiązania umożliwiające osadzanie zabezpieczeń wewnątrz dokumentów zawierających istotne dane. Zabezpieczenia te określają w istocie, co użytkownik może zrobić z ich treścią. Jeśli spojrzeć realnie, do wykorzystania w takim właśnie celu nadają się jedynie dwa rozwiązania. Pierwsze to Microsoft Rights Management Server (do zabezpieczania dokumentów Office i raportów w postaci MHTML), drugie zaś - Adobe LifeCycle Designer, przeznaczony do zabezpieczania treści opublikowanych dokumentów PDF i mechanizmu Adobe Forms.

Nieodłącznym elementem takiego rozwiązania jest przeglądarka pokazująca zabezpieczoną treść i pozwalająca ją edytować. Potrzebny jest także (niezależny od przeglądarki) mechanizm uwierzytelniania i weryfikacji uprawnień do wykonywania określonych operacji, opartych zwykle na koncepcji klucza publicznego i prywatnego.

Sama przeglądarka musi być napisana, tak by w dowolnym momencie jak najmniejsza porcja dokumentu była odbezpieczona. Chodzi o to, aby treść dokumentu nie trafiła do pliku wymiany składowanego przez system operacyjny na dysku komputera. Dodatkowo warto, by nie dało się uzyskać z zewnątrz dostępu do treści, do czego konieczne jest blokowanie określonych funkcji API systemu operacyjnego. Przykładowo, w istniejącej wersji Microsoft RMS przy przeglądaniu zabezpieczonego dokumentu nie działa standardowy mechanizm do zrzucania obrazu, choć już niektóre narzędzia firm trzecich działają prawidłowo.

Problemem jest także sensowne zdefiniowanie uprawnień. W przypadku dokumentów biurowych jest to dosyć naturalne - wystarczy nałożyć ograniczenie edycji, drukowania, dystrybucji itp. Ale systemy DRM są stosowane także do zabezpieczania książek elektronicznych. Tworzenie "publicznego" systemu RMS wymaga, by z jednej strony zabezpieczyć interesy wydawcy, a z drugiej nie utrudniać pracy z taką publikacją jej użytkownikowi.

Paradoksalnie rozwiązania DRM, pomimo teoretycznych zalet, mogą przynieść sporo nowych problemów. Pierwszy to backup. Jeżeli backup tworzony jest dla dokumentów "odbezpieczonych", powstaje dodatkowa kopia tworząca wyłom w bezpieczeństwie danych. Z kolei jeżeli na taśmie zapisany będzie zabezpieczony dokument, to zakładamy, że infrastruktura niezbędna do "odkodowania" będzie cały czas dostępna, co w sytuacji gdy trzeba skorzystać z kopii zapasowej raczej trudno zagwarantować.

Przy okazji warto pamiętać, że systemy DRM są oparte na certyfikatach i każdy z kluczy jest ważny tylko przez ściśle określony czas. Jeśli klucz zostanie zniszczony lub administrator na czas nie wygeneruje nowego klucza, zabezpieczonej treści nie da się odzyskać, chyba że da się rozkodować coś zabezpieczonego kluczem o długości 4096 bitów lub więcej.

Drugi, całkiem realny problem jest związany z pracą offline. W takim przypadku na komputerze trzeba zapisać tokeny pozwalające na dalszą pracę. Aby to jednak było możliwe, trzeba stworzyć metodę jednoznacznej identyfikacji komputera, co w praktyce jest trudne. Na razie nie ma w komputerach działającej "bezpiecznej skrytki", więc system DRM musi działać w warstwie programowej, osłabiając siłę całego rozwiązania.

Do DRM trzeba podchodzić z dystansem, bo pomimo całego zaawansowania nie jest to technologia "magicznie" gwarantująca danym bezpieczeństwo. Jeśli chronione dane są naprawdę coś warte, może się okazać, że aby je zdobyć, wystarczy wejść do firmy z aparatem cyfrowym i sfotografować to, co jest wyświetlane na ekranie monitora. I wcale nie jest to scenariusz marnej powieści kryminalnej.