Bezpieczeństwo z przygodami

Dobra architektura aplikacji to tylko jeden z wielu elementów bezpieczeństwa informacji. Nie mniej ważne jest zadbanie o działania organizacyjne oraz fachowy nadzór administracyjny, świadomy ograniczeń technologii i ludzi.

Dobra architektura aplikacji to tylko jeden z wielu elementów bezpieczeństwa informacji. Nie mniej ważne jest zadbanie o działania organizacyjne oraz fachowy nadzór administracyjny, świadomy ograniczeń technologii i ludzi.

Użytkownicy kojarzą problem bezpieczeństwa z wirusami czy różnego rodzaju złośliwym kodem, który instaluje się bez ich wiedzy i przeszkadza w pracy czy rozrywce. Z punktu widzenia firmy znacznie istotniejsze jest to, by skutecznie zabezpieczyć zasoby informacyjne. Tu, inaczej niż w przypadku wirusów itp., proste rozwiązania nie są zbytnio pomocne. Kradzież informacji, w przeciwieństwie do unieruchamiania systemów lub aplikacji, nie jest łatwa do zautomatyzowania. Bezpieczeństwo informacji zależy bardziej od procedur oraz założeń odnośnie do architektury rozwiązań, niż od tego, jak rozwiązanie zostało zakodowane, czy też ile zawiera błędów. Prostych rozwiązań niestety nie ma.

Bezpieczne powitanie

Pierwszy z wielu problemów to organizacja procesu uwierzytelniania. Wielu producentów aplikacji, wzorując się na Windows, zakłada niekoniecznie słusznie, że administrator systemu powinien mieć największe uprawnienia w aplikacji. Administrator to osoba odpowiadająca za czynności administracyjne - zakładanie kont, nadawanie uprawnień itp. Nie oznacza to, że musi mieć równie szerokie uprawnienia w modułach biznesowych. Użytkownik aplikacji odwrotnie - pracuje z modułami biznesowymi, lecz nie administruje kontami i uprawnieniami. Jeśli taki podział jest zachowany, nie ma pokusy, by osoba wykonywała czynności biznesowe z uprawnieniami administratora.

Hasło powinno być także wystarczająco skomplikowane. Można to ustalić definiując zasady w aplikacji lub systemie operacyjnym. Takie elementy, jak: długość, liczba znaków niealfanumerycznych czy częstotliwość zmian można definiować dowolnie, choć... nie do końca. Jeżeli hasło będzie zbyt skomplikowane, użytkownik zapisze je na kartce i przyklei na monitorze. Jeśli się tego wyraźnie zabroni, użytkownik dostosuje się, poczym... wpisze je do telefonu komórkowego.

Można ten problem obchodzić, ale wciąż nie w pełni skutecznie. W przeciągu ostatnich kilku lat rozwiązania biometryczne potaniały, ale nie stały się przez to bardziej niezawodne. Nadal więc są używane jako dodatkowy mechanizm zabezpieczeń, ale nie jako ich fundament. Znacznie częściej stosowane są jednak karty procesorowe czy generatory haseł jednorazowych. Pojawia się również pytanie, gdzie przechowywać hasło. Praca użytkowników większości aplikacji zaczyna się od zalogowania się w aplikacji, co jednak w wielu przypadkach nie ma sensu, bo można przecież wykorzystać mechanizmy dostarczane przez systemy operacyjne. Problem w tym, że czasami uprawnienia w ramach aplikacji biznesowej są inne niż w systemie operacyjnym. Bywa, że za pomocą jednego identyfikatora korzysta z aplikacji kilka osób, lub też odwrotnie - na jednym terminalu pracuje wiele osób posiadających różne identyfikatory.

Duplikowanie logowania w aplikacji pozwala przechować informacje o szczegółowych uprawnieniach, których próżno szukać w typowych rozwiązaniach katalogowych. Owe typowe rozwiązania można jednak całkiem elegancko dostosować do potrzeb konkretnego rozwiązania. Większość programistów zapomina, że Active Directory, eDirectory, SunOne Directory Server zawierają wyrafinowaną, hierarchiczną bazę danych. Każda encja (np. użytkownik) może być połączona z innymi obiektami i może mieć dostatecznie dużą liczbę "cech dodatkowych", które pozwoliłyby zapisać dowolne elementy wymagane przez aplikację.

Problem istnieje, lecz gdzie indziej. O ile dodawanie cech do katalogu jest proste, to kasowanie już nie. Większość rozwiązań pozwala oznaczyć atrybut jako nieaktywny i stąd właśnie pojawia się opór administratorów systemów operacyjnych przed "grzebaniem w ich katalogu". W związku z tym wraz z Windows 2003 został wprowadzony ADAM - Active Directory Application Mode - specjalny katalog "prywatny" dla poszczególnych aplikacji, który łatwo można usunąć, gdy aplikacja nie jest już wykorzystywana.

Role nie zawsze wystarczą

Inny problem jest związany z organizacją uprawnień. Struktura katalogu pozwala łatwo wyrazić to, że np. dana osoba należy do jednej lub kilku grup. Stąd system może np. sprawdzić, czy ktoś ma prawo otworzyć moduł magazynowy czy finansowo-księgowy. Z punktu widzenia aplikacji istotne jest, czy osoba może wykonać daną operację biznesową, niemającą odpowiednika w API systemu operacyjnego.

Model bezpieczeństwa oparty na rolach często nie wystarcza, a w każdym razie komplikuje rozwiązanie. Przykładowo, jeżeli ktoś jest menedżerem drugiego szczebla i ma prawo do modułu wydatków, może akceptować kwoty do 10 000 USD. Sprzedawca w tym samym systemie ma zupełnie inny limit wydatków, aplikacja musi więc sprawdzać cały ciąg warunków, z których jednym jest właśnie przynależność do grupy. Co jednak będzie, jeśli zmienią się reguły dotyczące limitów kwot?

Próbą rozwiązania tego problemu jest moduł Authorization Manager w Windows 2003 czy Rule Engine w Enterprise Library. Oba mechanizmy pozwalają definiować wyrażenie bazujące na ciągu cech użytkownika - czy należy do określonych grup, ma pewne atrybuty itp. Takie wyrażenie ma przypisaną nazwę, o którą "pyta" aplikacja. W omówionym wyżej przypadku aplikacja pyta moduł: "Podaj wysokość kwoty dla aktualnie zalogowanego użytkownika".

Na to wszystko nakłada się jeszcze pewien problem techniczny. Dane gromadzone są zwykle w relacyjnej bazie danych. Standardowe mechanizmy uprawnień bazy pozwalają ograniczać dostęp "pionowo" - do poszczególnych tabel czy kolumn (ten mechanizm jest rzadko stosowany). Często jednak w firmie praca zorganizowana jest w taki sposób

że osoba jest odpowiedzialna za klienta czy grupę klientów. Wtedy uprawnienia trzeba przypisywać poziomo, do poszczególnych wierszy oznaczających np. transakcje danego klienta. Oczywiście, można sobie z tym poradzić dodając odpowiednie znaczniki do wierszy i np. specjalne widoki, ale jest to dodatkowe utrudnienie dla programisty i potencjalna luka w bezpieczeństwie..

Może z pomocą przyjdą w końcu producenci baz danych? Serwer Oracle od wersji 9 ma mechanizm rozszerzeń "label security" (opcja dla bazy w wersji Enterprise). Pozwala on ustawić reguły i kryteria dostępu do danego wiersza. Definiuje się poziom określający "stopień poufności", a dodatkowo "znacznik projektu", czyli cechę, która określa przynależność danych. W ten sposób można obsłużyć przynajmniej część scenariuszy zabezpieczeń. Dodatkową zaletą takiego podejścia jest to, że programista nie musi martwić się o właściwą konstrukcję zapytań. Serwer baz danych automatycznie wybiera podzbiór danych, które może widzieć użytkownik.

Jeszcze bardziej skomplikowane są mechanizmy uprawnień dla rozwiązań raportowych. Najczęściej przyjmuje się, że użytkownik ma prawo do przeglądania tylko pewnych agregatów, a nie danych szczegółowych. Na przykład może zobaczyć sumę kosztów wynikających z wypłat pensji, ale nie dowie się, ile zarabia konkretna osoba. Większość serwerów OLAP ma możliwość przypisywania uprawnień do poszczególnych wymiarów czy wręcz "wycinków" kostki. Wtedy pojawia się pytanie, jak sensownie definiować takie wymagania.

Najprościej jest ustalać uprawnienia na poziomie raportu, tzn. określony użytkownik może lub nie może go otworzyć i/lub żądać szczegółów. To wymaga, aby osoba definiująca (lub udostępniająca raporty) przewidziała i odpowiednio przypisała prawa. Tu jednak znów pojawia się problem, bo zestawienia często tworzone są ad hoc przez osoby, które o nadawaniu uprawnień nie wiedzą zbyt wiele. Niektóre aplikacje wykorzystują oddzielne kostki OLAP (sterujące), które pośredniczą przy definiowaniu i sprawdzaniu uprawnień.

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

TOP 200