Czy wiesz, czym jest kontrola dostępu? cz. II

W ostatnim artykule poruszyliśmy wiele zagadnień dotyczących kontrola dostępu. W dzisiejszym też znajdziesz parę z nich, dalej będę poruszał ten temat. Mam nadzieję, że wyciągniesz jak najwięcej z poniższego tekstu.

Dobre Praktyki dotyczące konta

Onboarding/offboarding

• Onboarding to proces, który zawiera wszystkie niezbędne kroki do wykonania po zatrudnieniu nowej osoby. Są to na przykład przekazanie laptopa, karty do biura czy stworzenie konta i nadanie mu uprawnień. Naprawdę można by tu wymieniać i wymieniać – w prostych słowach jest to wszystko, co nowa osoba przychodząca do biura powinna mieć. Onboarding powinien też zawierać szkolenie odpowiednie do stanowiska, ale i szkolenia z bezpieczeństwa informacji. Dodatkowo dobrą praktyką jest podpisanie odpowiedniego NDA na początku współpracy oraz zawarcie tam informacji, jak będzie to wyglądać po jej zakończeniu. Na zakończenie współpracy mamy proces Offboardingu, czyli odwrotność powyższego. Zabieramy laptopa, wyłączamy konto i tak dalej, i tak dalej.

Recertyfikacja

• Konta użytkowników przechodzą przez certyfikacje. Recertyfikacja to taki proces, który sprawdza, czy konto dalej jest w użytku. I tak możesz ustawić taką politykę, by po 90 dniach, jeśli konto jest nieużywane przez nikogo, automatycznie było blokowane. Moim zdaniem jest to za długi okres i powinno się konto blokować już po 15 dniach. Zapytasz pewnie, dlaczego akurat po 15? Ano każdemu się zdarza dwutygodniowy urlop. Wyłączanie konta osoba na urlopie to zbyt duży nakład pracy na odblokowywanie takich kont. Ale jeśli jakiegoś pracownika ma nie być miesiąc i dłużej, to konto powinno pozostać w stanie zablokowanym. Ma to za cel uniknąć ataków na konto lub też phishingu z konta osoby na urlopie itp. Jak dobrze wiesz, bezpieczeństwo polega na zmniejszaniu ryzyka, a nie jego wykluczaniu. Więc w tym wypadku zmniejszamy ryzyko i nakłady pracy w razie gdyby miał wystąpić incydent bezpieczeństwa. Co mi się już parę razy zdarzyło, zanim taka polityka powstała.

Standaryzacja nazewnictwa

• Standaryzacja nazewnictwa powinna być ustawiana zarówno w kontach użytkowników, jak i w nazwach urządzeń. Ponieważ tylko wtedy, gdy ustawimy nazwy kont według jakiegoś standardu (np. imie.nazwisko), będziemy w stanie wyłapać, czy powstało konto bez naszej wiedzy. Dlatego działy IT, bezpieczeństwa i HR powinny z sobą współpracować. Tak, aby IT miało aktualne listy pracowników i mogło wykryć, czy zostały stworzone niepożądane konta. To samo tyczy się nazw Group czy Distribution list, czy też nazw serwerów i komputerów. Zasada jest ta sama, pozwala to na wykrycie niepożądanych kont czy komputerów wpiętych do sieci i przeczesujących zasoby w celu znalezienia złotego Graala ;). Przy ilości komputerów rzędu dziesięciu w małej firmie nie jest to problem, ale gdy komputerów robi się sto i więcej, zarządzanie nimi i badanie bezpieczeństwa staje się coraz bardziej skomplikowane.
• Zarządzanie Kontem, czyli regularna kontrola kont, czy foldery się backupują. Czy użytkownik zmienił swoje hasło. Wszelkie usuwanie nadmiarowych kont. Na przykład kont osób, które już odeszły. I tak dalej i tak dalej
• Kontrola za pomocą lokalizacji – dostęp można tylko otrzymać z danej lokalizacji.

Modele kontroli dostępu

Zależnie od tego, jaki model kontroli wybierzemy, tak zostaną zaaplikowane kontrole dostępu. Głównymi modelami są:

• Discretionary Access Control
• Mandatory Access Control
• Role-based Access Control
• Rule-based Access Control
• Group-based Access Control
• Attribute-based Access Control

Discretionary Access Control DAC (DACL)

Discretionary Access Control to rodzaj modelu, w którym decyzja o tym, kto będzie miał dostęp, jest podjęta na podstawie DACL, czyli Discretionary Access Control List. DACL to lista użytkowników bądź grup, które mają dostęp do zasobów. DACL określa, jaki jest zakres tego dostępu, na przykład uprawnienia do pliku.

W DACL każdy wpis określamy skrótem ACE, czyli access control entry. W systemie Windows mamy SID przypisany do konta sid ten podczas generowania Access token jest przypisywany właśnie w nim wraz z grupami, do których jest przypisany użytkownik. Następnie Access token jest porównywany z DACL, by potwierdzić, jaki użytkownik ma dostęp do danego pliku.

Mandatory Access Control MAC model

W wypadku Mandatory Access Control każdy obiekt przypisany jest do pewnego poziomu takiego jak restricted, secret czy top secret. Dane w organizacji są określone za pomocą classification labels odpowiednio do tego, jak bardzo są wrażliwe. Dla przykładu dane mogą być podzielone w następujący sposób: publiczne, zastrzeżone, sekretne, super sekretne 😉 .

W takim wypadku dostęp do danego zasobu określany jest po naszej naklejeczce. Musisz jednak pamiętać, że osoba mająca wyższe uprawnienia ma dostęp do wszystkich poniżej. Co znaczy, że jeśli masz ustawione „sekretne”, to będziesz miał dostęp do danych zastrzeżonych jak i do publicznych. W AIP (Azure Information Protection) mamy te classification labels – jeszcze z tego nie korzystałem, jak masz może jakieś ciekawe materiały odnośnie tego, to podrzuć w komentarzu, z chęcią się zapoznam (oczywiście poza instrukcjami od MS).

Klasyfikacja Informacji naklejeczki – Label classification

Mamy dwa główne podziały w naklejeczkach. Podział pierwszy:

1. Top secret: Dane o najwyższej randze, ich wyciek może spowodować upadek organizacji. I to szybki.
2. Secret: Drugi z kolei, wyciek tych danych może powodować poważne problemy dla organizacji.
3. Confidential: Trzeci z kolei. Wyciek takich danych powoduje straty, choć nie są już one tak duże, jak w poprzednich przypadkach.
4. Restricted: W tym wypadku są to dane, którymi niekoniecznie chcemy się dzielić ze światem, ale jak już wyciekną, nie spowodują większych problemów.
5. Unclassified: Jeśli nie jest przypisana żadna z powyższych naklejek, to mamy niesklasyfikowane dane i z automatu staja się one danymi publicznymi. Czyli do wglądu dla każdego.

I teraz podział drugi, dużo częściej spotykam się z wykorzystaniem tego modelu:

• Confidential: Najwyższy poziom. Wyciek tych danych to ogromne, gigantyczne, wszechogarniające zagrożenie dla organizacji 🙂
• Private: Drugi od góry, wyciek to duże zagrożenie.
• Sensitive: Jak wypłynie, to nie będzie przyjemnie, ale da się przeżyć.
• Public: No i znowu publiczne dane.

Role-based Access Control RBAC

W wypadku Role-based Access Control dostęp jest nadawany przez system za pomocą przynależności do danej roli. Rola to taki obiekt, do którego z góry przypisane są uprawnienia. Na przykład księgowa w firmie ma uprawnienia z racji bycia księgową do danych zawierających informacje o wypłacie wszystkich w firmie, bo np. robi przelewy.

A pracownik z innego działu już takich informacji nie ma. No i teraz osoba przychodząca na stanowisko do robienia przelewów zostaje przypisana do takiej właśnie roli w systemie, która to daje jej dostęp do informacji, jakie przelewy ma zrobić.

Role-based Access Control

Kontrola dostępu według zasad występuje głównie na urządzeniach, na przykład na routerach. Tutaj za pomocą określonych przez nas reguł możemy zezwalać na ruch bądź też go zabraniać. I w wypadku routera, gdy dodamy wpis do ACL, jest on sprawdzany na wyjściu i wejściu z routera, gdzie dopuszcza on dany ruch bądź nie.

Group-based Access Control

Group-based Access Control jest bardzo przydatne w AD i w AAD. Za pomocą group-based AC możemy sobie zautomatyzować procesy np. onboardingu i offboardingu. Załóżmy, że przychodzi nowa osoba do działu księgowości i potrzebuje standardowej grupy uprawnień, która mają wszyscy tamtejsi pracownicy.

No i teraz, jeśli masz wszystko skonfigurowane odpowiednio, wystarczy, że użytkownik zostanie otagowany jako księgowy, a następnie zostanie dodany do odpowiednich grup, które nadadzą odpowiednie standardowe uprawnienia. Nie polecam nadawać uprawnień do jednej dużej grupy, lecz wydzielić kilka mniejszych i dodać osobę do każdej z nich, jeśli to konieczne.

Attribute-based Access Control

No i jak każda powyższa, tak i ta kontrola dostępu wyraża się w swojej nazwie. Uprawnienia są Ci nadawane poprzez atrybuty. Dla przykładu może posłużyć Condition Access w Azure.

Kontrole dostępu i Bezpieczeństwo bazy danych

Bazy danych często przechowują wrażliwe dane tak o samej organizacji, jak i ich klientach. Jako bezpiecznicy musimy zadbać o to, by te dane były bezpiecznie in transit i at rest ;).

• Role – Wiele baz danych korzysta z rozwiązania nadawania uprawnień za pomocą roli. Na przykład w MS SQL Serwer sysadmin dostaje pełne uprawnienia, a jeśli dostaniesz uprawnienia discadmin, masz już tylko dostęp tylko do plików, a nie do wszystkich ustawień bazy. Domyślasz się, którą opcje należy wybrać ? 🙂
• Uprawnienia – Z uprawnieniami jest tak, jak we wszystkich systemach: less is more ;). Przynajmniej dla Ciebie jako bezpiecznika. Zawsze trzymasz się zasady least privilege.
• Szyfrowanie – Musisz pamiętać, że zazwyczaj te dane są wrażliwe i muszą być szyfrowane tak w spoczynku, jak i w ruchu.
• Audyt – I jeden z kluczowych tematów w bezpieczeństwie, czyli audyt. Musi być on wykonywany systematycznie i rzetelnie.

Podsumowanie

Uff na dziś koniec. Znowu kolejna garść kontroli, choć dzisiaj bardziej od technicznej strony. Wiem, wiem, że nie było wykorzystania w praktyce, ale, jak widzisz, pokazałem Ci parę przykładów. Dalej zastanawiam się nad rozwiązaniem tego za pomocą kursu all in one, jak poruszyłem we wcześniejszych artykułach.

Nadal czekam na potwierdzenie większej ilości chętnych na tego typu rozwiązanie, ponieważ nakład pracy z mojej strony byłby potężny: dużo środowisk do przygotowania plus przejście od A do Z przez przykładowy case startupu do zabezpieczenia – sam rozumiesz ;).

Pozdrawiam – Pusz ????