Systemy PAM i zasada najniższych przywilejów vs. „zła wola” użytkowników

„Zła wola” użytkowników to jedno z najtrudniejszych do zapobiegnięcia zagrożeń, które spędzają sen z powiek pracownikom działów bezpieczeństwa. Administratorzy systemów, administratorzy baz danych, administratorzy sieci – to najczęściej osoby bardzo wysokiego zaufania. Zaangażowane w budowę i rozwój infrastruktury, często posiadają kluczową wiedzę dotyczącą działania całego środowiska informatycznego i są niezbędne do zapewnienia ciągłości jego działania. Niestety, w pewnych sytuacjach, gdy współpraca na linii administrator – pracodawca nie układa się najlepiej, pracownicy, którzy w założeniu odpowiedzialni są za bezpieczeństwo infrastruktury, mogą stać się dla niej największym zagrożeniem.

Oczywiście, nie chodzi tutaj o to by stygmatyzować administratorów IT. Ich praca jest kluczowa dla każdej organizacji, dlatego tak istotne jest, by dostarczyć działom bezpieczeństwa odpowiednie narzędzia, które zapewnią komfort pracy i bezpieczeństwo tym pracownikom, którzy „złej woli” nie przejawiają.

Trzy filary zarządzania dostępem uprzywilejowanym.

Zrozumiałe jest, że w pracy administratorów IT dostęp do kont uprzywilejowanych jest niezbędny. Co jednak istotne – dostęp ten może być uregulowany i usystematyzowany. Możliwe jest opracowanie takich procedur, wspartych odpowiednimi narzędziami, które pozwolą administratorom wykonywać swoje obowiązki, przy jednoczesnym zapewnieniu bezpiecznego i możliwego do rozliczenia dostępu uprzywilejowanego.

Kwestią podstawową jest zarządzanie hasłami. Sprawa jest prosta przy kontach imiennych – zarówno kontach słabych, jak i kontach uprzywilejowanych. Odpowiednie polityki pozwalają wymusić na użytkownikach zmianę hasła w odpowiednich odstępach czasowych. Co jednak zrobić z kontami współdzielonymi? Co zrobić z kontami wbudowanymi? Co zrobić z kontami systemowymi i serwisowymi? Te wszystkie krytyczne konta o bardzo wysokich przywilejach (często chronione kluczami zamiast haseł), również muszą być w jakiś sposób zarządzane. Jednak 6 miesięczne hasło na koncie root trudno nazwać „dobrą praktyką”.

Ten właśnie problem związany z zarządzaniem hasłami kont uprzywilejowanych, jest adresowany przez pierwszy z trzech filarów wszystkich systemów PAM. Automatyczna rotacja hasłami i kluczami SSH jest niezbędna do utrzymania właściwego poziomu bezpieczeństwa infrastruktury. Co więcej – jeżeli hasła są zarządzane przez dedykowany system, to w zasadzie nie muszą być znane administratorom. Istotne jest to, by mogli nawiązać sesję do konta o wysokich przywilejach, nie sama znajomość hasła. I to jest właśnie podstawa każdego systemu PAM – pozwolić na nawiązanie sesji do systemu docelowego z użyciem konta w odpowiednim poziomie uprawnień, ale bez ujawniania hasła.

Jednak hasła (i klucze) to nie wszystko. Co z kontrolą dostępu? Czy każdy kto zostaje administratorem w organizacji, powinien mieć automatycznie dostęp do wszystkich jej sekretów? Czy nie wskazane byłoby zdefiniowanie dla tych nowych pracowników (o jednak zdecydowanie mniejszym poziomie zaufania) wyłącznie dostępów do tych zasobów, które nie są krytyczne dla działania przedsiębiorstwa? Czy nie wskazany byłby w tej pierwszej fazie nadzór i wydawanie zgód na dostęp do określonych kont wysoko uprzywilejowanych?

Ten obszar pokrywa drugi filar systemów PAM, czyli kontrola dostępu. Mówimy tutaj o sytuacji, w której nowy pracownik albo też kontraktor, który ma wykonać określoną pracę, musi zawnioskować o dostęp do określonego konta i określonego zasobu. Taki wniosek rozpatrywany jest każdorazowo, analogicznie jak jakikolwiek inny wniosek, który przechodzi przez dowolny system zgłoszeniowy. Jeżeli nie ma przesłanek, które wskazują, że dany dostęp jest niepożądany, wówczas może on zostać danemu pracownikowi zaakceptowany. Co więcej – właściwie zaprojektowany system PAM, pozwala administratorom składać wnioski o dostęp wyłącznie do tych kont i zasobów, które są w obszarze ich odpowiedzialności. W dużym uproszczeniu – nie ma potrzeby, żeby administratorzy systemów Linux, wnioskowali o dostęp do systemów Windows. Tym sposobem system PAM zwiększa bezpieczeństwo infrastruktury dwojako – z jednej strony mówimy o pełnej rozliczalności użycia kont uprzywilejowanych i współdzielonych przez pracowników (czyli wiadome jest kto używał jakiego konta, w jakim systemie i kiedy miało to miejsce), a także pozwala wymusić ręczną akceptację każdorazowego dostępu przy szczególnie krytycznych systemach lub przy nieszczególnie zaufanych pracownikach.

Możliwe jest zatem oddzielenie użytkowników od haseł, możliwe jest pełne ich rozliczenie z dostępów. Pozostaje jeszcze jeden aspekt. Kiedy już administrator zostanie do danego systemu wpuszczony, to wskazane jest jednak, żeby wiedzieć jakie działania tam prowadzi. Naturalnie, do dyspozycji są logi systemowe, które zawierają mniej lub więcej informacji na temat aktywności użytkownika w systemie. Jednak czy nie lepszy byłby podgląd takiej sesji? Możliwość obserwowania na żywo operacji wykonywanych przez tego wysoko uprzywilejowanego użytkownika? Czy nie warto mieć tych sesji zarchiwizowanych, żeby móc odnaleźć ewentualny błąd lub pomyłkę?

To właśnie ten trzeci filar systemów PAM – rejestracja sesji. I nie ukrywam, że naturalną reakcją każdego pracownika jest opór przed rejestrowaniem aktywności. Jest to bardzo zrozumiałe, ponieważ nikt nie chce być śledzony, a tym bardziej nagrywany. Natomiast warto mieć na uwadze, że mówimy tu o kontach i systemach o wyjątkowym znaczeniu dla organizacji. Nikt już nie jest zaskoczony kamerami na terenie zakładu pracy ani nawet w pomieszczeniach biurowych. Z tej samej perspektywy należy rozważać rejestrację sesji uprzywilejowanych. Jest to również element ochrony dla administratorów pracujących z kontami o wysokich uprawnieniach i przede wszystkim w ten sposób należy do tego aspektu podchodzić.

Zasada najniższego przywileju – uzupełnienie PAM.

Systemy PAM, opierając się na trzech opisanych powyżej filarach, adresują kilka podstawowych problemów związanych z rozliczalnością użytkowników, zarządzaniem hasłami, rejestracją aktywności. Naturalnie żaden z tych aspektów nie chroni wprost przed „złą wolą” użytkowników, bo jednak zalogowany do systemu docelowego administrator na koncie uprzywilejowanym, ma wystarczające uprawnienia by podjąć dowolne działania, niemniej – przy wdrożonym systemie PAM – zawsze będzie możliwe zidentyfikowanie osoby odpowiedzialnej za incydent (z uwagi na pełną rozliczalność również przy wykorzystaniu kont współdzielonych), a także możliwe będzie zweryfikowanie w jaki sposób to działanie zostało wykonane (poprzez odtworzenie sesji). Te dwa aspekty będą jednak działać zniechęcająco na użytkownika o niecnych zamiarach, a jego poziom determinacji musi być znacznie wyższy niż w sytuacji, gdy najdzie go ochota na zrobienie „psikusa”, w ramach zamanifestowania swojego niezadowolenia.

Wszystko to jednak nie zmienia faktu, że odpowiednio zdeterminowany użytkownik, będzie mógł się wykazać „złą wolą”. Przyczyną są uprawnienia konta, z którego administrator korzysta. Nawet jeśli ma wykonać określoną czynność, to najczęściej i tak korzysta z konta o pełnych uprawnieniach w ramach systemu operacyjnego. I jest to całkowicie zrozumiałe z perspektywy wygody pracy, mniej z perspektywy bezpieczeństwa.

Podstawowy koncept zasady najniższego przywileju polega na tym, żeby określone konto (czy to współdzielone, czy też imienne) posiadało taki poziom uprawnień, który pozwala wykonać zadaną pracę. Łatwiej o tej koncepcji mówi się z perspektywy ról użytkowników niż z perspektywy kont systemowych. Wyobraźmy sobie pracownika działu handlowego. Jego aktywność (w kontekście systemów informatycznych) sprowadza się do wykorzystania określonych aplikacji, które są dopuszczone w organizacji. Będzie to zapewne system CRM, będzie to przeglądarka internetowa, będzie to arkusz kalkulacyjny, system prezentacyjny, edytor tekstu. Zatem z perspektywy bezpieczeństwa – nie ma uzasadnienia dla pracownika o takiej roli, żeby korzystał z aplikacji, które nie są wymagane do tego, by mógł produktywnie wykonywać swoje zadania. I o ile domyślnie systemy operacyjne pozwalają definiować poziom uprawnień użytkownika na pewnym poziomie ogólności, tak uszczegółowienie tych aplikacji pożądanych/niepożądanych bywa dość trudne. Sprawa się komplikuje jeszcze bardziej, kiedy któraś z aplikacji wymaga uprawnień administracyjnych – wówczas konto użytkownika, musi posiadać takie uprawnienia, a to z perspektywy bezpieczeństwa jest niebywale ryzykowne.

Dlatego tak istotne jest rozważenie narzędzia wspomagającego wdrożenie zasady najniższego przywileju. Jasne i klarowne określenie aplikacji, które mogą być przez pracownika wykorzystywane. Jeżeli zachodzi taka potrzeba, to nadanie określonej aplikacji wyższego poziomu uprawnień. I wyłączenie z użycia (zablokowanie uruchomienia) czegokolwiek, co użytkownik ściągnie z Internetu albo przyniesie na pamięci flash. I co prawda operuję tutaj przykładem pracownika, który nie jest administratorem IT, ale zasadę tę można też zastosować przy systemach serwerowych. Konto administratora baz danych powinno mieć uprawnienia administracyjne dla narzędzia bazodanowego, a już niekoniecznie do narzędzia pozwalającego zakładać lokalnych użytkowników. Granulacja poziomu uprawnień jest kluczowa dla zwiększenia poziomu bezpieczeństwa całej infrastruktury, ponieważ pozwala ograniczyć funkcjonalność kont wyłącznie do dedykowanych czynności i kompromitacja jednego z tych kont, będzie mniej krytyczna niż konta o pełnych uprawnieniach administracyjnych. Jednocześnie, dla administratora przejawiającego „złą wolę” będzie to kolejny próg utrudniający wykonanie złośliwych działań i ponownie – jego poziom determinacji będzie musiał być bardzo wysoki.

„Zła wola” administratora vs. jego determinacja.

W zasadzie wszystkie systemy bezpieczeństwa starają się chronić infrastrukturę IT przed działaniem „złej woli” użytkowników. Łatwiej oczywiście, kiedy ten użytkownik jest poza infrastrukturą i próbuje ją spenetrować od zewnątrz. Wówczas można stosować ochronę, która jest odpowiedzią na pewne schematy zachowań, zwłaszcza że intruz najczęściej nie zna środowiska od wewnątrz. Sprawa z użytkownikami będącymi wewnątrz organizacji wygląda nieco inaczej. Administratorzy IT znają środowisko, z którym pracują na co dzień i znają systemy bezpieczeństwa, które to środowisko chronią. Mają więc ułatwione zadanie w omijaniu tych zabezpieczeń. Dlatego tak kluczowe jest oddzielenie administratorów od pewnych kluczowych informacji (hasła) i regulowanie dostępu do krytycznych zasobów. Ważne jest także rejestrowanie tego co dzieje się w tych sesjach uprzywilejowanych i wreszcie, nadanie każdemu z kont takich uprawnień, żeby tylko określone czynności mogły być wykonane.

I przyznaję – brzmi to jak utrudnianie życia administratorom. Niestety, tak właśnie działają systemy bezpieczeństwa. Rzadko wprowadzają udogodnienia, najczęściej komplikują i utrudniają. Ich zadaniem nadrzędnym jest zniechęcenie użytkownika, by nie podejmował działań na szkodę organizacji. Co prawda niemożliwe jest pełne zabezpieczenie się przed „złą wolą”, ale można tak podnosić próg determinacji niezbędnej do wykonania aktu „złej woli”, żeby nikomu się nie chciało tego aktu podejmować.