Definiowanie ról na potrzeby funkcji Privileged Access Management

  • Artykuł

Za pomocą funkcji Privileged Access Management (PAM) można przypisać użytkowników do uprzywilejowanych ról, które mogą oni aktywować w razie potrzeby dla dostępu just in time. Te role są definiowane ręcznie i ustanawiane w środowisku bastionu. W tym artykule przedstawiono proces podejmowania decyzji o tym, które role mają być zarządzane za pomocą funkcji Privileged Access Management, oraz sposób definiowania ich przy użyciu odpowiednich uprawnień i ograniczeń.

Ważne

Model w tym artykule jest przeznaczony tylko dla izolowanych środowisk usługi Active Directory korzystających MIM PAM. W przypadku środowisk hybrydowych zobacz zamiast tego wskazówki w modelu dostępu przedsiębiorstwa.

Najprostszym sposobem definiowania ról funkcji Privileged Access Management jest skompilowanie wszystkich informacji w arkuszu kalkulacyjnym. Utwórz listę ról i użyj kolumn do określenia wymagań i uprawnień ładu.

Wymagania dotyczące ładu różnią się w zależności od istniejących zasad tożsamości i dostępu lub wymagań dotyczących zgodności. Parametry do zidentyfikowania dla każdej roli mogą obejmować:

  • Właściciel roli.
  • Użytkownicy kandydują, którzy mogą pełnić tę rolę
  • Uwierzytelnianie, zatwierdzanie lub kontrolki powiadomień, które powinny być skojarzone z korzystaniem z roli.

Uprawnienia roli są zależne od zarządzanych aplikacji. W tym artykule jako przykładowa aplikacja jest używana usługa Active Directory, w której uprawnienia dzielą się na dwie kategorie:

  • Potrzebne do zarządzania samą usługą Active Directory (np. do konfigurowania topologii replikacji)

  • Potrzebne do zarządzania danymi przechowywanymi w usłudze Active Directory (np. do tworzenia użytkowników i grup)

Identyfikowanie ról

Rozpocznij od zidentyfikowania wszystkich ról, które mają być zarządzane za pomocą funkcji PAM. W arkuszu kalkulacyjnym każda potencjalna rola będzie miała swój własny wiersz.

Aby znaleźć odpowiednie role, rozważ każdą aplikację w zakresie zarządzania:

  • Czy aplikacja znajduje się w warstwie 0, 1 czy 2?
  • Jakie uprawnienia wpływają na poufność, integralność lub dostępność aplikacji?
  • Czy aplikacja ma zależności od innych składników systemu? Czy na przykład ma zależności od baz danych, sieci, infrastruktury zabezpieczeń, wirtualizacji lub platformy hostingu?

Określ sposób grupowania tych zagadnień dotyczących aplikacji. Wymagane są role, które mają wyraźne granice i dają tylko wystarczające uprawnienia do wykonywania typowych zadań administracyjnych w aplikacji.

Należy zawsze projektować role dla przypisania z najmniejszymi uprawnieniami. Może to być oparte na bieżących (lub planowanych) obowiązkach organizacyjnych dla użytkowników i obejmować uprawnienia wymagane ze względu na obowiązki użytkownika. Może to również obejmować uprawnienia, które upraszczają operacje bez zwiększania ryzyka.

Inne zagadnienia z zakresu uprawnień, które ma zawierać rola, są następujące:

  • Jak wiele osób pracuje z określoną rolą? Jeśli jest to tylko jedna osoba, rola może być zbyt ściśle zdefiniowana, aby była przydatna, lub zdefiniowano określone obowiązki danej osoby.

  • Jak wiele ról ma dana osoba? Czy użytkownicy będą mogli wybrać odpowiednią rolę dla swojego zadania?

  • Czy populacja użytkowników i sposób ich interakcji z aplikacjami będzie zgodny z funkcją Privileged Access Management?

  • Czy jest możliwe oddzielenie administracji i inspekcji, aby użytkownik z rolą administracyjną nie mógł wymazać rekordów inspekcji swoich działań?

Ustanawianie wymagań roli dotyczących ładu

Po zidentyfikowaniu ról kandydujących rozpocznij wypełnianie arkusza kalkulacyjnego. Utwórz kolumny dla wymagań istotnych dla Twojej organizacji. Niektóre wymagania, które należy wziąć pod uwagę, to:

  • Kto jest właścicielem roli, który będzie odpowiedzialny za dalsze definiowanie roli, wybieranie uprawnień i obsługę ustawień ładu roli?

  • Kim są posiadacze roli (użytkownicy), którzy będą wykonywać obowiązki lub zadania związane z rolą?

  • Jaka metoda dostępu (omówiona w następnej sekcji) będzie odpowiednia dla posiadaczy roli?

  • Czy jest wymagane ręczne zatwierdzanie przez właściciela roli, gdy użytkownik aktywuje swoją rolę?

  • Czy jest wymagane powiadomienie, gdy użytkownik aktywuje swoją rolę?

  • Czy użycie tej roli powinno spowodować wygenerowanie alertu lub powiadomienia w systemie SIEM na potrzeby śledzenia?

  • Czy jest konieczne ograniczanie możliwości logowania użytkowników aktywujących rolę tylko do komputerów, na których jest wymagany dostęp w celu wykonywania obowiązków związanych z rolą oraz weryfikacja hosta jest wystarczająca do zabezpieczenia uprawnień lub poświadczeń przed ich nieprawidłowym użyciem?

  • Czy wymagane jest zapewnienie osobom pełniącym rolę dedykowanej administracyjnej stacji roboczej?

  • Które uprawnienia aplikacji (zobacz przykładową listę dla usługi AD poniżej) są skojarzone z tą rolą?

Wybieranie metody dostępu

W systemie zarządzania dostępem uprzywilejowanym może być wiele ról z przypisanymi do nich uprawnieniami. Może się tak zdarzyć, jeśli różne społeczności użytkowników mają odrębne wymagania dotyczące ładu dostępu. Na przykład organizacja może zastosować inne zasady dla swoich pełnoetatowych pracowników, a inne dla zewnętrznych pracowników IT z innej organizacji.

W niektórych przypadkach użytkownik może zostać trwale przypisany do roli. W takim przypadku nie muszą żądać ani aktywować przypisania roli. Przykłady scenariuszy stałych przypisań obejmują:

  • Zarządzane konto usługi w istniejącym lesie.

  • Konto użytkownika w istniejącym lesie z poświadczeniami zarządzanymi poza usługą PAM. Może to być konto "break glass". Konto typu break glass może wymagać roli, takiej jak "Konserwacja domeny/kontrolera domeny", aby rozwiązać problemy takie jak problemy z zaufaniem i kondycją kontrolera domeny. W przypadku konta włamań rola zostanie trwale przypisana przy użyciu fizycznie zabezpieczonego hasła.

  • Konto użytkownika w lesie administracyjnym, który uwierzytelnia się przy użyciu hasła. Może to być użytkownik, który potrzebuje trwałych uprawnień administracyjnych przez całą całą 7 dni w roku i loguje się z urządzenia, które nie obsługuje silnego uwierzytelniania.

  • Konto użytkownika w lesie administracyjnym z kartą inteligentną lub wirtualną kartą inteligentną (na przykład konto z kartą inteligentną w trybie offline potrzebną do rzadkich zadań konserwacji).

Delegowanie uprawnień usługi Active Directory

System Windows Server podczas tworzenia nowych domen automatycznie tworzy grupy domyślne, takie jak „Administratorzy domeny”. Te grupy ułatwiają rozpoczęcie pracy i mogą być przydatne dla mniejszych organizacji. Większe organizacje lub organizacje, które wymagają większej izolacji uprawnień administracyjnych, powinny opróżnić te grupy i zastąpić je grupami, które zapewniają precyzyjne uprawnienia.

Jednym z ograniczeń grupy Administratorzy domeny jest to, że jej członkami nie mogą być osoby z domeny zewnętrznej. Innym ograniczeniem jest to, że przyznaje ona uprawnienia do trzech osobnych funkcji:

  • Zarządzanie samą usługą Active Directory
  • Zarządzanie danymi przechowywanymi w usłudze Active Directory
  • Umożliwianie zdalnego logowania do komputerów przyłączonych do domeny

W miejsce grup domyślnych, takich jak Administratorzy domeny, utwórz nowe grupy zabezpieczeń, które zapewniają tylko niezbędne uprawnienia. Następnie należy użyć MIM, aby dynamicznie dostarczać konta administratorów z tymi członkostwem w grupach.

Uprawnienia zarządzania usługami

W poniższej tabeli przedstawiono przykłady uprawnień, które warto dodać do ról służących do zarządzania usługą AD.

Rola Opis
Konserwacja domeny/kontrolera domeny Członkostwo w grupie Domena\Administratorzy umożliwia rozwiązywanie problemów i zmienianie systemu operacyjnego kontrolera domeny. Operacje takie jak podszycie się pod nowy kontroler domeny do istniejącej domeny w lesie i delegowanie roli usługi AD.
Zarządzanie wirtualnymi kontrolerami domeny Zarządzanie maszynami wirtualnymi kontrolerów domeny za pomocą oprogramowania do zarządzania wirtualizacją. To uprawnienie można przyznać za pośrednictwem pełnej kontroli nad wszystkimi maszynami wirtualnymi w narzędziu do zarządzania lub funkcji kontroli dostępu na podstawie ról.
Rozszerzanie schematu Zarządzanie schematem, w tym dodawanie nowych definicji obiektów, zmienianie uprawnień do obiektów schematu i zmienianie domyślnych uprawnień schematu dla typów obiektów.
Tworzenie kopii zapasowej bazy danych usługi Active Directory Wykonywanie kopii zapasowej całej bazy danych usługi Active Directory, w tym wszystkich kluczy tajnych powierzonych kontrolerowi domeny i domenie.
Zarządzanie relacjami zaufania i poziomami funkcjonalności Tworzenie i usuwanie relacji zaufania z zewnętrznymi lasami i domenami.
Zarządzanie lokacjami, podsieciami i replikacją Zarządzanie obiektami topologii replikacji usługi Active Directory, w tym modyfikowanie lokacji i podsieci, oraz obiektami linków lokacji, a także inicjowanie operacji replikacji.
Zarządzanie obiektami zasad grupy Tworzenie, usuwanie i modyfikowanie obiektów zasad grupy w domenie.
Zarządzanie strefami Tworzenie, usuwanie i modyfikowanie stref DNS oraz obiektów w usłudze Active Directory.
Modyfikowanie jednostek organizacyjnych warstwy 0 Modyfikowanie jednostek organizacyjnych warstwy 0 i obiektów znajdujących się w usłudze Active Directory.

Uprawnienia zarządzania danymi

W poniższej tabeli przedstawiono przykłady uprawnień, które należy uwzględnić w rolach do zarządzania danymi w u usługi AD lub korzystania z nich.

Rola Opis
Modyfikowanie administracyjnej jednostki organizacyjnej warstwy 1 Modyfikowanie jednostek organizacyjnych zawierających obiekty administracyjne warstwy 1 w usłudze Active Directory.
Modyfikowanie administracyjnej jednostki organizacyjnej warstwy 2 Modyfikowanie jednostek organizacyjnych zawierających obiekty administracyjne warstwy 2 w usłudze Active Directory.
Zarządzanie kontami: tworzenie/usuwanie/przenoszenie Modyfikowanie kont użytkowników standardowych.
Zarządzanie kontami: resetowanie/odblokowywanie Resetowanie haseł i odblokowywanie kont.
Grupa zabezpieczeń: tworzenie/modyfikowanie Tworzenie i modyfikowanie grup zabezpieczeń w usłudze Active Directory.
Grupa zabezpieczeń: usuwanie Usuwanie grup zabezpieczeń w usłudze Active Directory.
Zarządzanie obiektami zasad grupy Zarządzanie wszystkimi obiektami zasad grupy w domenie lub lesie, które nie mają wpływu na serwery warstwy 0.
Przyłączony komputer/administrator lokalny Lokalne uprawnienia administracyjne do wszystkich stacji roboczych.
Przyłączony serwer/administrator lokalny Lokalne uprawnienia administracyjne do wszystkich serwerów.

Przykładowe definicje ról

Wybór definicji ról zależy od warstwy serwerów zarządzanych. Zależy to również od wyboru zarządzanych aplikacji. Aplikacje, takie Exchange lub produkty dla przedsiębiorstw innych firm, takie jak SAP, często będą wprowadzać własne dodatkowe definicje ról dla administracji delegowaowej.

W poniższych sekcjach znajdują się przykłady dla typowych scenariuszy przedsiębiorstwa.

Warstwa 0 — las administracyjny

Role odpowiednie dla kont w środowisku bastionu mogą być następujące:

  • Dostęp awaryjny do lasu administracyjnego
  • Administratorzy z czerwonymi kartami: użytkownicy, którzy są administratorami lasu administracyjnego
  • Użytkownicy, którzy są administratorami lasu produkcyjnego
  • Użytkownicy, którym zostały delegowane ograniczone prawa administracyjne do aplikacji w lesie produkcyjnym

Warstwa 0 — las produkcyjny przedsiębiorstwa

Role odpowiednie do zarządzania kontami i zasobami lasu produkcyjnego warstwy 0 mogą być następujące:

  • Dostęp awaryjny do lasu produkcyjnego
  • Administratorzy zasad grupy
  • Administratorzy serwera DNS
  • Administratorzy infrastruktury PKI
  • Administratorzy topologii i replikacji usługi AD
  • Administratorzy wirtualizacji serwerów warstwy 0
  • Administratorzy magazynu
  • Administratorzy ochrony przed złośliwym oprogramowaniem dla serwerów warstwy 0
  • Administratorzy programu SCCM dla warstwy 0
  • System Center Operations Manager administratorzy warstwy 0 Operations Manager
  • Administratorzy kopii zapasowych dla warstwy 0
  • Użytkownicy kontrolerów poza pasmem i kontrolerów zarządzania płytą główną (w przypadku maszyny KVM lub zarządzania lights-out) połączonych z hostami warstwy 0

Warstwa 1

Role na potrzeby zarządzania serwerami i tworzenia ich kopii zapasowych w warstwie 1 mogą być następujące:

  • Konserwacja serwera
  • Administratorzy wirtualizacji dla serwerów warstwy 1
  • Konto skanera zabezpieczeń
  • Administratorzy ochrony przed złośliwym oprogramowaniem dla serwerów warstwy 1
  • Administratorzy programu SCCM dla warstwy 1
  • System Center Operations Manager dla warstwy 1 Operations Manager
  • Administratorzy kopii zapasowych dla serwerów warstwy 1
  • Użytkownicy kontrolerów poza pasmem i kontrolerów zarządzania płytą główną (w przypadku maszyny KVM lub zarządzania lights-out) połączonych z hostami warstwy 1

Ponadto role służące do zarządzania aplikacjami przedsiębiorstwa w warstwie 1 mogą być następujące:

  • Administratorzy DHCP
  • Administratorzy programu Exchange
  • Administratorzy programu Skype dla firm
  • Administratorzy farmy programu SharePoint
  • Administratorzy usługi w chmurze, np. witryny sieci Web firmy lub publicznego serwera DNS
  • Administratorzy systemów HCM, finansowych lub prawnych

Warstwa 2

Role dla użytkowników innych niż użytkownicy administracyjni i role na potrzeby zarządzania komputerami mogą być następujące:

  • Administratorzy kont
  • Pomoc techniczna
  • Administratorzy grup zabezpieczeń
  • Pomoc techniczna dla stacji roboczych na miejscu

Następne kroki