Bezpieczeństwo danych w systemie Lotus Notes

Ze względu na sposób wykorzystania Notes zarówno w biznesie, bankowości, jak i administracji, zasadnicze znaczenie ma zachowanie poufności danych i ochrona ich przed niepowołanym dostępem lub modyfikacją.

Ze względu na sposób wykorzystania Notes zarówno w biznesie, bankowości, jak i administracji, zasadnicze znaczenie ma zachowanie poufności danych i ochrona ich przed niepowołanym dostępem lub modyfikacją.

Analizując warstwową strukturę systemu zabezpieczeń można wyróżnić poziomy takie jak:

  • identyfikacja - oparta na standardzie X.400 i X.500. Każdy obiekt ma przypisany unikalny identyfikator-plik zawierający nazwę obiektu, certyfikat, klucz publiczny/prywatny, klucze do szyfrowania, numer licencji.

  • prawa dostępu do baz danych:

  • No access - użytkownik ma zabroniony dostęp;

  • Depositor - użytkownik może wprowadzić nowy dokument na zasadzie depozytu, bez możliwości przeglądania zawartości bazy;

  • Reader - użytkownik może przeglądać i odczytywać treść dokumentów w bazie;

  • Author - użytkownik ma prawa takie jak Reader, a dodatkowo może tworzyć własne dokumenty i je modyfikować;

  • Editor - użytkownik ma prawa takie jak Author, a dodatkowo może edytować wszystkie dokumenty w bazie;

  • Designer - użytkownik ma prawa takie jak Editor, a dodatkowo może tworzyć i modyfikować warstwę projektową;

  • Manager - użytkownik ma prawa takie jak Designer, a dodatkowo może definiować prawa dostępu dla innych obiektów oraz skasować całą bazę;

  • poufność danych - mechanizmy zabezpieczjące przed niepowołanym odczytaniem informacji poprzez ograniczenie

    dostępu do form (FORMS) czy też do tablic (VIEWS);

  • weryfikacja źródła informacji - procedura weryfikacji wiarygodności dokumentu oparta na podpisie elektronicznym;

  • szyfrowanie - Notes używa kombinacji pojedynczego (symetrycznego) i podwójnego (niesymetrycznego) klucza szyfrującego. Do niektórych funkcji wykorzystywana jest technologia Public Key Encryption opracowana przez RSA Data Security Inc. Do szyfrowania indywidualnych wiadomości Notes używają algorytmu pojedynczego klucza RC2 (na terenie Stanów Zjednoczonych RC4).
Użytkownik musi spełnić wiele warunków determinujących możliwość korzystania z zasobów serwera Notes. Aby można było otworzyć jakąkolwiek bazę trzeba najpierw uzyskać dostęp do serwera. W tym celu system ustala tożsamość użytkownika na podstawie informacji zawartych w identyfikatorze. Najistotniejsze z nich to nazwa obiektu, hasło oraz certyfikaty. Ten ostatni uprawnia do korzystania z usług serwera pod warunkiem, że nazwa obiektu nie znajduje się na liście "Not access server" zabraniającej dostępu. Sama nazwa obiektu wykorzystywana jest przy określaniu dostępu do bazy.

Proces ustalania tożsamości można porównać do procedury przekraczania granicy: aby wjechać do innego państwa należy okazać paszport (identyfikator) z aktualną wizą (certyfikatem). Ponadto nasze nazwisko (nazwa obiektu) nie powinno się znajdować na czarnej liście osób, dla których wstęp jest zabroniony.

Identyfikator użytkownika może być przechowywany na dysku lokalnym stacji roboczej. Jest to wygodne, ale zarazem nie stwarza pełnego bezpieczeństwa. System Lotus Notes (jak zresztą żaden inny) nie jest w stanie rozróżnić kto fizycznie obsługuje komputer. Zatem dowolna osoba, jeżeli będzie miała dostęp do tej stacji, będzie mogła dotrzeć do informacji na zasadach jakie zostały przyznane w danym identyfikatorze. Pewniejszym rozwiązaniem jest przechowywanie pliku na dyskietce. Daje to dodatkową zaletę, że użytkownik nie jest wtedy na stale przywiązany do jednej stacji.

Po przyznaniu połączenia rozpoczyna się kolejny etap w drodze do danych. Następna bariera związana jest już z konkretną bazą. Jest to lista kontroli dostępu (Access Control List). Na niej zdefiniowane są obiekty uprawnione do korzystania z zasobów tej bazy. Sposób korzystania określony jest poprzez omówione wcześniej prawa dostępu. Dalsza selekcja może być uregulowana poprzez dostęp do form lub tablic dokumentów, czy też na niższym poziomie - do wybranych dokumentów.

Wskazany dokument może być jeszcze dodatkowo zabezpieczony. Można określić jakie porcje informacji będą widoczne w czasie odczytu, jakie w czasie edycji, lub jakie pola będą niedostępne w wyniku ich zaszyfrowania.

Luki w systemie zabezpieczeń?

Jak z tego wynika system dostarcza szerokie spektrum zabezpieczeń dostepu do danych. Należy jednak pamietać o pewnych lukach. Choć system zabezpieczeń ma zwartą konstrukcję w warstwie obsługi serwera, to w lokalnym trybie dostępu jest on zdecydowanie mniej restrykcyjny. Być może jest to celowe zamierzenie twórców tego systemu, ponieważ dzięki temu nie ma zagrożenia nieodwracalnego odcięcia się od danych. Dlatego właśnie cecha ta nie powinna być traktowana jako wada.

O lokalnym trybie dostępu do danych mówimy wtedy, gdy baza umieszczona jest na dysku twardym używanej stacji roboczej, gdy pracujemy na stacji działającej jako serwer Notes lub gdy serwer Lotus Notes działa jako aplikacja na serwerze plików, np. w systemie NetWare. W ostatnim przypadku występuje sytuacja taka jak w przypadku stacji roboczej. Jeśli mamy prawo do odczytu informacji z serwera plików, to możemy skopiować bazę na dysk lokalny. Należy jednak pamiętać o tym, że po skopiowaniu bazy danych można modyfikować tylko jej kopię. Baza źródłowa umieszczona na serwerze pozostanie nie zmieniona.

Niebiezpieczeństwo dotyczy raczej możliwości dotarcia do informacji, których z poziomu Reader'a nie można byłoby odczytać. Omija się w ten sposób zabezpieczenia na poziomie Form i Views. Jeżeli jednak administrator pamięta o takim niebezpieczeństwie, to może udostępnić plik tylko wybranym użytkownikom wykorzystując system zabezpieczeń serwera plików. Gdy z bazy mają korzystać wszyscy użytkownicy sieci, a zaledwie część z nich ma mieć dostęp do tajnych informacji, to jedynym rozwiązaniem w takim przypadku jest szyfrowanie określonych pól bazy.

Inną sytuacją wymagającą ostrożności jest obsługa certyfikatów. Użytkownik może podsunąć do certyfikowania identyfikator wygenerowany przez siebie z nazwą obiektu, która jest zdefiniowana na Listach Kontroli Dostępu (ACL) jako Manager. Listę ACL można odczytać mając prawo Reader. Jeżeli administrator nie sprawdzi co certyfikuje, to daje użytkownikowi wytrych do bazy. Mowa jest tu oczywiście o celowym działaniu w celu oszukania systemu zabezpieczeń. Pozytywną cechą w tym wypadku jest fakt (z pozoru niewygodny), iż nie da się zmienić nazwy użytkownika bez rozpoczęcia procesu rejestracji od nowa. Czyli tak, jak nie da się wkleić nowego zdjęcia w paszporcie.

Na podstawie powyższych przykładów można wysunąć wniosek, iż chociaż z pozoru system zabezpieczeń ma pewne luki, to pamietając o jego potencjalnych zagrożeniach można go tak przygotować, aby właściwe osoby mogły korzystać tylko z udostępnionych im danych.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200