Definiowanie zasad organizacji na potrzeby zarządzania dostępem do aplikacji w danym środowisku
Po zidentyfikowaniu co najmniej jednej aplikacji, która ma używać identyfikatora Entra firmy Microsoft do zarządzania dostępem, zapisz zasady organizacji w celu określenia, którzy użytkownicy powinni mieć dostęp, oraz wszelkich innych ograniczeń, które powinny zapewnić system.
Wybieranie aplikacji i ich ról w zakresie
Organizacje z wymaganiami dotyczącymi zgodności lub planami zarządzania ryzykiem mają wrażliwe lub krytyczne dla działania firmy aplikacje. Jeśli ta aplikacja jest istniejącą aplikacją w twoim środowisku, być może masz już udokumentowane zasady dostępu dla osób, które "powinny mieć dostęp" do tej aplikacji. Jeśli nie, może być konieczne skonsultowanie się z różnymi uczestnikami projektu, takimi jak zespoły ds. zgodności i zarządzania ryzykiem, aby upewnić się, że zasady używane do automatyzacji decyzji dotyczących dostępu są odpowiednie dla danego scenariusza.
Zbierz role i uprawnienia, które udostępnia każda aplikacja. Niektóre aplikacje mogą mieć tylko jedną rolę, na przykład aplikację, która ma tylko rolę "Użytkownik". Bardziej złożone aplikacje mogą mieć wiele ról do zarządzania za pomocą identyfikatora Entra firmy Microsoft. Te role aplikacji zwykle mają szerokie ograniczenia dostępu użytkownika z tej roli w aplikacji. Na przykład aplikacja, która ma osobę administratora, może mieć dwie role: "Użytkownik" i "Administrator". Inne aplikacje mogą również polegać na członkostwie w grupach lub oświadczeniach w celu bardziej szczegółowego sprawdzania ról, które mogą być udostępniane aplikacji z witryny Microsoft Entra ID w aprowizacji lub oświadczenia wydane przy użyciu protokołów logowania jednokrotnego federacji lub zapisane w usłudze AD jako członkostwo w grupie zabezpieczeń. Na koniec mogą istnieć role specyficzne dla aplikacji, które nie są wyświetlane w identyfikatorze Entra firmy Microsoft — być może aplikacja nie zezwala na definiowanie administratorów w identyfikatorze Entra firmy Microsoft, zamiast tego polegać na własnych regułach autoryzacji w celu zidentyfikowania administratorów. Usługi SAP Cloud Identity Services mają tylko jedną rolę, Użytkownik, dostępną do przypisania.
Uwaga
Jeśli używasz aplikacji z galerii aplikacji Firmy Microsoft Entra, która obsługuje aprowizację, identyfikator Entra firmy Microsoft może zaimportować zdefiniowane role w aplikacji i automatycznie zaktualizować manifest aplikacji przy użyciu ról aplikacji po skonfigurowaniu aprowizacji.
Wybierz role i grupy, które mają być objęte członkostwem w identyfikatorze Entra firmy Microsoft. Na podstawie wymagań dotyczących zgodności i zarządzania ryzykiem organizacje często ustalają priorytety tych ról aplikacji lub grup, które zapewniają uprzywilejowany dostęp lub dostęp do poufnych informacji.
Definiowanie zasad organizacji z wymaganiami wstępnymi i innymi ograniczeniami dostępu do aplikacji
W tej sekcji zapiszesz zasady organizacyjne, których zamierzasz użyć do określenia dostępu do aplikacji. Możesz to zarejestrować jako tabelę w arkuszu kalkulacyjnym, na przykład
| Rola aplikacji | Wymagania wstępne dotyczące dostępu | Osoby zatwierdzające | Domyślny czas trwania dostępu | Rozdzielenie ograniczeń obowiązków | Zasady dostępu warunkowego |
|---|---|---|---|---|---|
| Zachodnia sprzedaż | Członek zespołu sprzedaży | menedżer użytkownika | Przegląd roczny | Nie można uzyskać dostępu do sprzedaży wschodniej | Uwierzytelnianie wieloskładnikowe (MFA) i zarejestrowane urządzenie wymagane do uzyskania dostępu |
| Zachodnia sprzedaż | Każdy pracownik poza sprzedażą | kierownik działu sprzedaży | 90 dni | Nie dotyczy | Uwierzytelnianie wieloskładnikowe i zarejestrowane urządzenie wymagane do uzyskania dostępu |
| Zachodnia sprzedaż | Przedstawiciel ds. sprzedaży nienależących do pracowników | kierownik działu sprzedaży | 30 dni | Nie dotyczy | Uwierzytelnianie wieloskładnikowe wymagane do uzyskania dostępu |
| Sprzedaż wschodnia | Członek zespołu sprzedaży | menedżer użytkownika | Przegląd roczny | Nie można uzyskać dostępu do sprzedaży zachodniej | Uwierzytelnianie wieloskładnikowe i zarejestrowane urządzenie wymagane do uzyskania dostępu |
| Sprzedaż wschodnia | Każdy pracownik poza sprzedażą | kierownik działu sprzedaży | 90 dni | Nie dotyczy | Uwierzytelnianie wieloskładnikowe i zarejestrowane urządzenie wymagane do uzyskania dostępu |
| Sprzedaż wschodnia | Przedstawiciel ds. sprzedaży nienależących do pracowników | kierownik działu sprzedaży | 30 dni | Nie dotyczy | Uwierzytelnianie wieloskładnikowe wymagane do uzyskania dostępu |
Jeśli masz już definicję roli organizacji, zobacz , jak migrować rolę organizacyjną, aby uzyskać więcej informacji.
Określ, czy istnieją wymagania wstępne, standardy, które użytkownik musi spełnić przed uzyskaniem dostępu do aplikacji. Na przykład w normalnych okolicznościach tylko pracownicy pełnoetatowi lub pracownicy w określonym dziale lub centrum kosztów powinni mieć dostęp do aplikacji określonego działu. Ponadto możesz wymagać zasad zarządzania upoważnieniami dla użytkownika z innego działu żądającego dostępu, aby mieć co najmniej jeden dodatkowy osoba zatwierdzająca. Chociaż posiadanie wielu etapów zatwierdzania może spowolnić ogólny proces uzyskiwania dostępu przez użytkownika, te dodatkowe etapy zapewniają odpowiednie żądania dostępu, a decyzje są rozliczane. Na przykład żądania dostępu przez pracownika mogą mieć dwa etapy zatwierdzania, najpierw przez menedżera żądającego użytkownika, a drugi przez jednego z właścicieli zasobów odpowiedzialnych za dane przechowywane w aplikacji.
Określ, jak długo użytkownik, który został zatwierdzony w celu uzyskania dostępu, powinien mieć dostęp i kiedy ten dostęp powinien zostać usunięty. W przypadku wielu aplikacji użytkownik może zachować dostęp na czas nieokreślony, dopóki nie będzie już powiązany z organizacją. W niektórych sytuacjach dostęp może być związany z konkretnymi projektami lub kamieniami milowymi, dzięki czemu po zakończeniu projektu dostęp zostanie automatycznie usunięty. Lub, jeśli tylko kilku użytkowników korzysta z aplikacji za pośrednictwem zasad, możesz skonfigurować kwartalne lub roczne przeglądy dostępu wszystkich użytkowników za pośrednictwem tych zasad, aby zapewnić regularny nadzór.
Jeśli Twoja organizacja zarządza dostępem już za pomocą modelu roli organizacji, zaplanuj przeniesienie tego modelu roli organizacji do identyfikatora Entra firmy Microsoft. Możesz mieć zdefiniowaną rolę organizacyjną, która przypisuje dostęp na podstawie właściwości użytkownika, takiej jak ich stanowisko lub dział. Te procesy mogą zapewnić użytkownikom utratę dostępu w końcu, gdy dostęp nie jest już potrzebny, nawet jeśli nie ma wstępnie ustalonej daty zakończenia projektu.
Sprawdź, czy istnieją rozdzielenie ograniczeń obowiązków. Na przykład możesz mieć aplikację z dwiema rolami aplikacji, Western Sales i Eastern Sales i chcesz mieć pewność, że użytkownik może mieć tylko jedno terytorium sprzedaży naraz. Dołącz listę wszystkich par ról aplikacji, które są niezgodne z twoją aplikacją, aby jeśli użytkownik ma jedną rolę, nie mogą żądać drugiej roli.
Wybierz odpowiednie zasady dostępu warunkowego, aby uzyskać dostęp do aplikacji. Zalecamy analizowanie aplikacji i grupowanie ich w aplikacje, które mają te same wymagania dotyczące zasobów dla tych samych użytkowników. Jeśli jest to pierwsza federacyjna aplikacja logowania jednokrotnego integrująca się z Zarządzanie tożsamością Microsoft Entra na potrzeby zarządzania tożsamościami, może być konieczne utworzenie nowych zasad dostępu warunkowego w celu wyrażenia ograniczeń, takich jak wymagania dotyczące uwierzytelniania wieloskładnikowego (MFA) lub dostępu opartego na lokalizacji. Możesz skonfigurować użytkowników, aby musieli wyrazić zgodę na warunki użytkowania. Aby uzyskać więcej informacji na temat sposobu definiowania zasad dostępu warunkowego, zobacz planowanie wdrożenia dostępu warunkowego.
Określ, jak powinny być obsługiwane wyjątki od kryteriów. Na przykład aplikacja może być zwykle dostępna tylko dla wyznaczonych pracowników, ale audytor lub dostawca może potrzebować tymczasowego dostępu do określonego projektu. Lub pracownik, który podróżuje, może wymagać dostępu z lokalizacji, która jest zwykle zablokowana, ponieważ twoja organizacja nie ma obecności w tej lokalizacji. W takich sytuacjach można również wybrać zasady zarządzania upoważnieniami do zatwierdzenia, które mogą mieć różne etapy lub inny limit czasu lub inną osoba zatwierdzającą. Dostawca, który jest zalogowany jako użytkownik-gość w dzierżawie firmy Microsoft Entra, może nie mieć menedżera, więc zamiast tego żądania dostępu mogą zostać zatwierdzone przez sponsora dla swojej organizacji lub przez właściciela zasobu lub oficera zabezpieczeń.
Ponieważ zasady organizacyjne dla osób, które powinny mieć dostęp, są przeglądane przez uczestników projektu, możesz rozpocząć integrowanie aplikacji z identyfikatorem Entra firmy Microsoft. W ten sposób w późniejszym kroku można przystąpić do wdrażania zasad zatwierdzonych przez organizację na potrzeby dostępu w Zarządzanie tożsamością Microsoft Entra.