Przewodnik po pojęciach dotyczących pakietu Microsoft BHOLD Suite

  • Artykuł

Microsoft Identity Manager 2016 (MIM) umożliwia organizacjom zarządzanie całym cyklem życia tożsamości użytkowników i skojarzonymi poświadczeniami. Można ją skonfigurować do synchronizowania tożsamości, centralnego zarządzania certyfikatami i hasłami oraz aprowizacji użytkowników w systemach heterogenicznych. Dzięki programowi MIM organizacje IT mogą definiować i automatyzować procesy używane do zarządzania tożsamościami od tworzenia do wycofania.

Pakiet Microsoft BHOLD Suite rozszerza te możliwości programu MIM przez dodanie kontroli dostępu opartej na rolach. Pakiet BHOLD umożliwia organizacjom definiowanie ról użytkowników i kontrolowanie dostępu do poufnych danych i aplikacji. Dostęp jest oparty na tym, co jest odpowiednie dla tych ról. Pakiet BHOLD zawiera usługi i narzędzia, które upraszczają modelowanie relacji ról w organizacji. Usługa BHOLD mapuje te role na prawa i sprawdzić, czy definicje ról i skojarzone prawa są prawidłowo stosowane do użytkowników. Te możliwości są w pełni zintegrowane z programem MIM, zapewniając bezproblemowe środowisko dla użytkowników końcowych i pracowników IT.

Ten przewodnik pomaga zrozumieć, jak pakiet BHOLD Działa z programem MIM i obejmuje następujące tematy:

  • Kontrola dostępu oparta na rolach
  • Zaświadczanie
  • Raportowanie
  • Łącznik zarządzania dostępem

Usługa BHOLD nie jest zalecana w przypadku nowych wdrożeń. Microsoft Entra identyfikator udostępnia teraz przeglądy dostępu, które zastępują funkcje kampanii zaświadczania BHOLD oraz zarządzanie upoważnieniami, które zastępują funkcje przypisywania dostępu.

Kontrola dostępu oparta na rolach

Najczęstszą metodą kontrolowania dostępu użytkowników do danych i aplikacji jest użycie uznaniowej kontroli dostępu (DAC). W większości typowych implementacji każdy znaczący obiekt ma zidentyfikowanego właściciela. Właściciel ma możliwość udzielenia lub odmowy dostępu do obiektu innym osobom w oparciu o indywidualną tożsamość lub członkostwo w grupie. W praktyce funkcja DAC zwykle powoduje mnóstwo grup zabezpieczeń, niektóre odzwierciedlające strukturę organizacyjną, inne reprezentujące grupy funkcjonalne (takie jak typy zadań lub przypisania projektów), a inne składające się z prowizorycznych kolekcji użytkowników i urządzeń połączonych w celu uzyskania bardziej tymczasowych celów. W miarę rozwoju organizacji członkostwo w tych grupach staje się coraz trudniejsze do zarządzania. Jeśli na przykład pracownik zostanie przeniesiony z jednego projektu do innego, grupy używane do kontrolowania dostępu do zasobów projektów muszą zostać zaktualizowane ręcznie. W takich przypadkach nie jest rzadkością, że popełniane są błędy, które mogą utrudniać bezpieczeństwo projektu lub produktywność.

Program MIM zawiera funkcje, które pomagają wyeliminować ten problem, zapewniając automatyczną kontrolę nad członkostwem w grupie i na liście dystrybucyjnej. Nie dotyczy to jednak wewnętrznej złożoności proliferacji grup, które niekoniecznie są ze sobą powiązane w sposób ustrukturyzowany.

Jednym ze sposobów znacznego zmniejszenia tego rozprzestrzeniania się jest wdrożenie kontroli dostępu opartej na rolach (RBAC). Kontrola dostępu oparta na rolach nie wypiera DAC. Kontrola dostępu oparta na rolach opiera się na DAC, zapewniając platformę do klasyfikowania użytkowników i zasobów IT. Dzięki temu można jawnie określać ich relacje i prawa dostępu, które są odpowiednie zgodnie z tą klasyfikacją. Na przykład, przypisując do atrybutów użytkownika, które określają stanowisko użytkownika i przypisania projektu, użytkownik może mieć dostęp do narzędzi potrzebnych do zadania użytkownika i danych, które użytkownik musi współtworzyć w określonym projekcie. Gdy użytkownik zakłada inne zadanie i różne przypisania projektu, zmieniając atrybuty, które określają tytuł zadania użytkownika i projekty automatycznie blokują dostęp do zasobów wymaganych tylko dla użytkowników poprzedniej pozycji.

Ponieważ role mogą być zawarte w rolach w sposób hierarchiczny ( na przykład role kierownika sprzedaży i przedstawiciela sprzedaży mogą być zawarte w bardziej ogólnej roli sprzedaży), łatwo jest przypisać odpowiednie prawa do określonych ról, a jednocześnie zapewnić odpowiednie prawa wszystkim, którzy mają bardziej inkluzywną rolę. Na przykład w szpitalu wszyscy pracownicy medyczni mogą mieć prawo do wyświetlania dokumentacji pacjentów, ale tylko lekarze (podrola roli medycznej) mogą mieć prawo do wprowadzania recept dla pacjenta. Podobnie użytkownicy należący do roli duchownej mogą odmówić dostępu do rejestrów pacjentów z wyjątkiem urzędników rozliczeniowych (podroli roli duchownej), którzy mogą mieć dostęp do tych części zapisów pacjentów, które są wymagane do rozliczania pacjenta za usługi świadczone przez szpital.

Dodatkową korzyścią z kontroli dostępu opartej na rolach jest możliwość definiowania i wymuszania podziału obowiązków (SoD). Dzięki temu organizacja może definiować kombinacje ról, które udzielają uprawnień, które nie powinny być przechowywane przez tego samego użytkownika, dzięki czemu określony użytkownik nie może mieć przypisanych ról, które umożliwiają użytkownikowi inicjowanie płatności i autoryzację płatności, na przykład. Kontrola dostępu oparta na rolach umożliwia automatyczne wymuszanie takich zasad zamiast oceniania efektywnej implementacji zasad dla poszczególnych użytkowników.

Obiekty modelu ról BHOLD

Za pomocą pakietu BHOLD można określać i organizować role w organizacji, mapować użytkowników na role i mapować odpowiednie uprawnienia do ról. Ta struktura jest nazywana modelem ról i zawiera pięć typów obiektów i łączy je z nimi:

  • Jednostki organizacyjne
  • Użytkownicy
  • Role
  • Uprawnienia
  • Aplikacje

Jednostki organizacyjne

Jednostki organizacyjne (OrgUnits) są głównymi metodami, za pomocą których użytkownicy są zorganizowani w modelu roli BHOLD. Każdy użytkownik musi należeć do co najmniej jednej organizacji OrgUnit. (W rzeczywistości, gdy użytkownik zostanie usunięty z ostatniej jednostki organizacyjnej w usłudze BHOLD, rekord danych użytkownika zostanie usunięty z bazy danych BHOLD).

Ważne

Jednostki organizacyjne w modelu roli BHOLD nie powinny być mylone z jednostkami organizacyjnymi w Active Directory Domain Services (AD DS). Zazwyczaj struktura jednostki organizacyjnej w usłudze BHOLD jest oparta na organizacji i zasadach firmy, a nie na wymaganiach infrastruktury sieciowej.

Chociaż nie jest to wymagane, w większości przypadków jednostki organizacyjne są ustrukturyzowane w usłudze BHOLD, aby reprezentować hierarchiczną strukturę rzeczywistej organizacji, podobnie jak poniżej:

przykładowy schemat organizacyjny

W tym przykładzie model roli będzie jednostki organizacyjnejganizatinal dla korporacji jako całości (reprezentowany przez prezydenta, ponieważ prezydent nie jest częścią jednostki mororganizacjialganizatinal) lub głównej jednostki organizacyjnej BHOLD (która zawsze istnieje) może być używana do tego celu. OrgUnits reprezentujący działy korporacyjne kierowane przez wiceprezesów zostaną umieszczone w jednostce organizacyjnej korporacyjnej. Następnie jednostki organizacyjne odpowiadające dyrektorom ds. marketingu i sprzedaży zostaną dodane do jednostek organizacyjnych marketingu i sprzedaży, a jednostki organizacyjne reprezentujące regionalnych menedżerów sprzedaży zostaną umieszczone w jednostce organizacyjnej dla menedżera sprzedaży w regionie wschodnim. Współpracownicy działu sprzedaży, którzy nie zarządzają innymi użytkownikami, będą członkami jednostki organizacyjnej menedżera sprzedaży w regionie wschodnim. Należy pamiętać, że użytkownicy mogą być członkami jednostki organizacyjnej na dowolnym poziomie. Na przykład asystent administracyjne, który nie jest menedżerem i raportuje bezpośrednio do wiceprezesa, będzie członkiem jednostki organizacyjnej wiceprezesa.

Oprócz reprezentowania struktury organizacyjnej jednostki organizacyjne mogą być również używane do grupowania użytkowników i innych jednostek organizacyjnych zgodnie z kryteriami funkcjonalnymi, takimi jak projekty lub specjalizacja. Na poniższym diagramie przedstawiono sposób użycia jednostek organizacyjnych do grupowania skojarzeń sprzedaży zgodnie z typem klienta:

przykładowa organizacja projektu

W tym przykładzie każdy współpracownik sprzedaży będzie należeć do dwóch jednostek organizacyjnych: jeden reprezentujący miejsce współpracownika w strukturze zarządzania organizacji i jeden reprezentujący bazę klientów współpracownika (sprzedaż detaliczną lub firmową). Do każdej jednostki organizacyjnej można przypisać różne role, które z kolei mogą mieć przypisane różne uprawnienia dostępu do zasobów IT organizacji. Ponadto role mogą być dziedziczone z nadrzędnych jednostek organizacyjnych, upraszczając proces propagacji ról do użytkowników. Z drugiej strony określone role mogą nie być dziedziczone, zapewniając, że określona rola jest skojarzona tylko z odpowiednimi jednostkami organizacyjnymi.

Narzędzia OrgUnits można utworzyć w pakiecie BHOLD za pomocą portalu internetowego BHOLD Core.

Użytkownicy

Jak wspomniano powyżej, każdy użytkownik musi należeć do co najmniej jednej jednostki organizacyjnej (OrgUnit). Ponieważ jednostki organizacyjne są głównym mechanizmem kojarzenia użytkownika z rolami, w większości organizacji dany użytkownik należy do wielu jednostek Organizacyjnych, aby ułatwić kojarzenie ról z tym użytkownikiem. W niektórych przypadkach może być jednak konieczne skojarzenie roli z użytkownikiem poza wszelkimi jednostkami organizacyjnymi, do których należy użytkownik. W związku z tym użytkownik może być przypisany bezpośrednio do roli, a także uzyskać role z organizacji, do których należy użytkownik.

Jeśli użytkownik nie jest aktywny w organizacji (na przykład z dala od urlopu medycznego), użytkownik może zostać zawieszony, co spowoduje odwołanie wszystkich uprawnień użytkownika bez usuwania użytkownika z modelu roli. Po powrocie do obowiązku użytkownik może zostać ponownie aktywowany, co spowoduje przywrócenie wszystkich uprawnień przyznanych przez role użytkownika.

Obiekty dla użytkowników można tworzyć indywidualnie w usłudze BHOLD za pośrednictwem portalu internetowego BHOLD Core lub za pomocą łącznika zarządzania dostępem z usługą FIM Synchronization Service w celu zaimportowania informacji o użytkownikach z takich źródeł, jak Active Directory Domain Services lub aplikacji zasobów ludzkich.

Użytkownicy można tworzyć bezpośrednio w usłudze BHOLD bez korzystania z usługi fiM Synchronization Service. Może to być przydatne podczas modelowania ról w środowisku przedprodukcyjnym lub testowym. Można również zezwolić użytkownikom zewnętrznym (takim jak pracownicy podwykonawcy) na przypisywanie ról, a tym samym na dostęp do zasobów IT bez dodawania ich do bazy danych pracowników; jednak ci użytkownicy nie będą mogli korzystać z funkcji samoobsługi BHOLD.

Role

Jak wspomniano wcześniej, w modelu kontroli dostępu opartej na rolach (RBAC) uprawnienia są skojarzone z rolami, a nie poszczególnymi użytkownikami. Dzięki temu można nadać każdemu użytkownikowi uprawnienia wymagane do wykonywania obowiązków użytkownika, zmieniając role użytkownika, a nie oddzielnie udzielając lub odmawiając uprawnień użytkownika. W związku z tym przypisanie uprawnień nie wymaga już udziału działu IT, ale zamiast tego może być wykonywane w ramach zarządzania firmą. Rola może agregować uprawnienia dostępu do różnych systemów, bezpośrednio lub za pomocą podroli, co jeszcze bardziej zmniejsza potrzebę zaangażowania IT w zarządzanie uprawnieniami użytkowników.

Należy pamiętać, że role są funkcją samego modelu RBAC; zazwyczaj role nie są aprowidowane w aplikacjach docelowych. Dzięki temu kontrola dostępu oparta na rolach może być używana wraz z istniejącymi aplikacjami, które nie są przeznaczone do używania ról lub zmiany definicji ról, muszą spełniać potrzeby zmiany modeli biznesowych bez konieczności samodzielnego modyfikowania aplikacji. Jeśli aplikacja docelowa jest przeznaczona do używania ról, można skojarzyć role w modelu ról BHOLD z odpowiednimi rolami aplikacji, traktując role specyficzne dla aplikacji jako uprawnienia.

W usłudze BHOLD można przypisać rolę użytkownikowi przede wszystkim za pomocą dwóch mechanizmów:

  • Przypisując rolę do jednostki organizacyjnej (jednostki organizacyjnej), której użytkownik jest członkiem
  • Przypisując rolę bezpośrednio do użytkownika

Rola przypisana do nadrzędnej jednostki organizacyjnej opcjonalnie może być dziedziczona przez jednostki organizacyjne członka. Gdy rola jest przypisywana lub dziedziczona przez jednostkę organizacyjną, może zostać wyznaczona jako efektywna lub proponowana rola. Jeśli jest to efektywna rola, wszyscy użytkownicy w jednostce organizacyjnej mają przypisaną rolę. Jeśli jest to proponowana rola, musi zostać aktywowana dla każdego użytkownika lub jednostki organizacyjnej członka, aby obowiązywać dla członków tego użytkownika lub jednostki organizacyjnej. Dzięki temu można przypisać użytkownikom podzbiór ról skojarzonych z jednostką organizacyjną, a nie automatycznie przypisywać wszystkie role jednostki organizacyjnej do wszystkich członków. Ponadto role mogą mieć daty rozpoczęcia i zakończenia, a limity można umieszczać na procentach użytkowników w jednostce organizacyjnej, dla których rola może być skuteczna.

Na poniższym diagramie pokazano, jak można przypisać rolę poszczególnych użytkowników w usłudze BHOLD:

przypisanie roli

Na tym diagramie rola A jest przypisywana do jednostki organizacyjnej jako roli dziedziczonej, dlatego jest dziedziczona przez jednostki organizacyjne członków i wszystkich użytkowników w tych jednostkach organizacyjnych. Rola B jest przypisywana jako proponowana rola dla jednostki organizacyjnej. Należy ją aktywować, aby użytkownik w jednostce organizacyjnej mógł zostać autoryzowany przy użyciu uprawnień roli. Rola C jest efektywną rolą, więc jej uprawnienia są stosowane natychmiast do wszystkich użytkowników w jednostce organizacyjnej. Rola D jest połączona bezpośrednio z użytkownikiem, więc jego uprawnienia mają zastosowanie natychmiast do tego użytkownika.

Ponadto rolę można aktywować dla użytkownika na podstawie atrybutów użytkownika. Aby uzyskać więcej informacji, zobacz Autoryzacja oparta na atrybutach.

Uprawnienia

Uprawnienie w usłudze BHOLD odpowiada autoryzacji zaimportowanej z aplikacji docelowej. Oznacza to, że gdy usługa BHOLD jest skonfigurowana do pracy z aplikacją, otrzymuje listę autoryzacji, które usługa BHOLD może połączyć z rolami. Na przykład po dodaniu Active Directory Domain Services (AD DS) do aplikacji BHOLD otrzymuje listę grup zabezpieczeń, które jako uprawnienia pakietu BHOLD mogą być połączone z rolami w usłudze BHOLD.

Uprawnienia są specyficzne dla aplikacji. Usługa BHOLD zapewnia jeden, ujednolicony widok uprawnień, dzięki czemu uprawnienia mogą być skojarzone z rolami bez konieczności zrozumienia szczegółów implementacji uprawnień przez menedżerów ról. W praktyce różne systemy mogą wymuszać uprawnienia inaczej. Łącznik specyficzny dla aplikacji z usługi FIM Synchronization Service do aplikacji określa, w jaki sposób są udostępniane zmiany uprawnień dla użytkownika.

Aplikacje

BHOLD implementuje metodę stosowania kontroli dostępu opartej na rolach (RBAC) do aplikacji zewnętrznych. Oznacza to, że gdy usługa BHOLD jest aprowizowana z użytkownikami i uprawnieniami z aplikacji, usługa BHOLD może skojarzyć te uprawnienia z użytkownikami, przypisując role do użytkowników, a następnie łącząc uprawnienia z rolami. Proces w tle aplikacji może następnie mapować odpowiednie uprawnienia do swoich użytkowników na podstawie mapowania ról/uprawnień w usłudze BHOLD.

Tworzenie modelu roli pakietu BHOLD Suite

Aby ułatwić opracowywanie modelu roli, pakiet BHOLD Suite udostępnia generator modeli, narzędzie, które jest zarówno łatwe w użyciu, jak i kompleksowe.

Przed użyciem generatora modeli należy utworzyć serię plików, które definiują obiekty używane przez generator modelu do konstruowania modelu ról. Aby uzyskać informacje o sposobie tworzenia tych plików, zobacz Dokumentacja techniczna pakietu Microsoft BHOLD Suite.

Pierwszym krokiem przy użyciu generatora modeli BHOLD jest zaimportowanie tych plików w celu załadowania podstawowych bloków konstrukcyjnych do generatora modeli. Po pomyślnym załadowaniu plików można określić kryteria używane przez generator modeli do tworzenia kilku klas ról:

  • Role członkostwa przypisane do użytkownika na podstawie organizacji (jednostek organizacyjnych), do których należy użytkownik
  • Role atrybutów przypisane do użytkownika na podstawie atrybutów użytkownika w bazie danych BHOLD
  • Proponowane role połączone z jednostką organizacyjną, ale muszą być aktywowane dla określonych użytkowników
  • Role własności, które zapewniają użytkownikowi kontrolę nad jednostkami organizacyjnymi i rolami, dla których właściciel nie jest określony w importowanych plikach

Ważne

Podczas przekazywania plików zaznacz pole wyboru Zachowaj istniejący model tylko w środowiskach testowych. W środowiskach produkcyjnych należy użyć generatora modeli, aby utworzyć początkowy model roli. Nie można jej użyć do modyfikowania istniejącego modelu roli w bazie danych BHOLD.

Po utworzeniu tych ról w modelu roli generator modelu można wyeksportować model ról do bazy danych BHOLD w postaci pliku XML.

Zaawansowane funkcje pakietu BHOLD

W poprzednich sekcjach opisano podstawowe funkcje kontroli dostępu opartej na rolach (RBAC) w usłudze BHOLD. W tej sekcji opisano dodatkowe funkcje pakietu BHOLD, które mogą zapewnić zwiększone bezpieczeństwo i elastyczność implementacji kontroli dostępu opartej na rolach w organizacji. Ta sekcja zawiera omówienie następujących funkcji pakietu BHOLD:

  • Kardynalność
  • Rozdzielenie obowiązków
  • Uprawnienia do dostosowywania kontekstu
  • Autoryzacja oparta na atrybutach
  • Elastyczne typy atrybutów

Kardynalność

Kardynalność odnosi się do implementacji reguł biznesowych, które mają na celu ograniczenie liczby dwóch jednostek, które mogą być ze sobą powiązane. W przypadku pakietu BHOLD można ustanowić reguły kardynalności dla ról, uprawnień i użytkowników.

Możesz skonfigurować rolę, aby ograniczyć następujące kwestie:

  • Maksymalna liczba użytkowników, dla których można aktywować proponowaną rolę
  • Maksymalna liczba podroli, które można połączyć z rolą
  • Maksymalna liczba uprawnień, które można połączyć z rolą

Możesz skonfigurować uprawnienie, aby ograniczyć następujące elementy:

  • Maksymalna liczba ról, które mogą być połączone z uprawnieniem
  • Maksymalna liczba użytkowników, którym można udzielić uprawnień

Możesz skonfigurować użytkownika, aby ograniczyć następujące kwestie:

  • Maksymalna liczba ról, które mogą być połączone z użytkownikiem
  • Maksymalna liczba uprawnień, które można przypisać użytkownikowi za pomocą przypisań ról

Rozdzielenie obowiązków

Rozdzielenie obowiązków (SoD) jest zasadą biznesową, która ma na celu uniemożliwienie osobom uzyskania możliwości wykonywania działań, które nie powinny być dostępne dla jednej osoby. Na przykład pracownik nie powinien mógł zażądać płatności i autoryzować płatności. Zasada SoD umożliwia organizacjom wdrożenie systemu kontroli i sald w celu zminimalizowania narażenia na ryzyko związane z błędami pracowników lub wykroczeniami.

System BHOLD implementuje soD, umożliwiając definiowanie niezgodnych uprawnień. Po zdefiniowaniu tych uprawnień usługa BHOLD wymusza soD, zapobiegając tworzeniu ról połączonych z niezgodnymi uprawnieniami, niezależnie od tego, czy są one połączone bezpośrednio, czy za pośrednictwem dziedziczenia, i uniemożliwiając użytkownikom przypisywanie wielu ról, które w połączeniu udzielałoby niezgodnych uprawnień, ponownie przez bezpośrednie przypisanie lub dziedziczenie. Opcjonalnie konflikty mogą być zastępowane.

Uprawnienia do dostosowywania kontekstu

Tworząc uprawnienia, które można automatycznie modyfikować na podstawie atrybutu obiektu, można zmniejszyć całkowitą liczbę uprawnień, którymi trzeba zarządzać. Uprawnienia do dostosowania kontekstu (CAPs) umożliwiają zdefiniowanie formuły jako atrybutu uprawnień, który modyfikuje sposób stosowania uprawnień przez aplikację skojarzona z uprawnieniem. Można na przykład utworzyć formułę, która zmienia uprawnienia dostępu do folderu plików (za pośrednictwem grupy zabezpieczeń skojarzonej z listą kontroli dostępu folderu) na podstawie tego, czy użytkownik należy do jednostki organizacyjnej (jednostki organizacyjnej) zawierającej pracowników pełnoetatowych lub kontraktowych. Jeśli użytkownik zostanie przeniesiony z jednej jednostki organizacyjnej do innej, nowe uprawnienie zostanie automatycznie zastosowane i stare uprawnienie zostanie zdezaktywowane.

Formuła CAP może wykonywać zapytania dotyczące wartości atrybutów, które zostały zastosowane do aplikacji, uprawnień, jednostek organizacyjnych i użytkowników.

Autoryzacja oparta na atrybutach

Jednym ze sposobów kontrolowania, czy rola połączona z jednostką organizacyjną (jednostką organizacyjną) jest aktywowana dla określonego użytkownika w jednostce organizacyjnej, jest użycie autoryzacji opartej na atrybutach (ABA). Za pomocą usługi ABA można automatycznie aktywować rolę tylko wtedy, gdy są spełnione określone reguły oparte na atrybutach użytkownika. Można na przykład połączyć rolę z jednostką organizacyjną, która stanie się aktywna dla użytkownika tylko wtedy, gdy stanowisko użytkownika jest zgodne z tytułem zadania w regule ABA. Eliminuje to konieczność ręcznego aktywowania proponowanej roli dla użytkownika. Zamiast tego rolę można aktywować dla wszystkich użytkowników w jednostce organizacyjnej, którzy mają wartość atrybutu spełniającą regułę ABA roli. Reguły można łączyć, aby rola została aktywowana tylko wtedy, gdy atrybuty użytkownika spełniają wszystkie reguły ABA określone dla roli.

Należy pamiętać, że wyniki testów reguł ABA są ograniczone przez ustawienia kardynalności. Jeśli na przykład ustawienie kardynalności reguły określa, że nie więcej niż dwóch użytkowników może mieć przypisaną rolę, a jeśli reguła usługi ABA w przeciwnym razie aktywuje rolę dla czterech użytkowników, rola zostanie aktywowana tylko dla dwóch pierwszych użytkowników, którzy przechodzą test ABA.

Elastyczne typy atrybutów

System atrybutów w usłudze BHOLD jest wysoce rozszerzalny. Można zdefiniować nowe typy atrybutów dla takich obiektów jak użytkownicy, jednostki organizacyjne (jednostki organizacyjne) i role. Atrybuty można zdefiniować tak, aby miały wartości całkowite, wartość logiczną (tak/nie), alfanumeryczne, datę, godzinę i adresy e-mail. Atrybuty można określić jako pojedyncze wartości lub listę wartości.

Zaświadczanie

Pakiet BHOLD udostępnia narzędzia, których można użyć do sprawdzania, czy indywidualni użytkownicy otrzymali odpowiednie uprawnienia do wykonywania swoich zadań biznesowych. Administrator może użyć portalu udostępnionego przez moduł zaświadczania BHOLD do projektowania procesu zaświadczania i zarządzania nim.

Proces zaświadczania odbywa się za pomocą kampanii, w których stewardzy kampanii mają możliwość i umożliwiają sprawdzenie, czy użytkownicy, dla których są odpowiedzialni, mają odpowiedni dostęp do aplikacji zarządzanych przez usługę BHOLD i poprawne uprawnienia w tych aplikacjach. Właściciel kampanii jest wyznaczony do nadzorowania kampanii i zapewnienia, że kampania jest prowadzona prawidłowo. Można utworzyć kampanię jednorazową lub cykliczną.

Zazwyczaj stewardem kampanii będzie menedżer, który będzie potwierdzał prawa dostępu użytkowników należących do co najmniej jednej jednostki organizacyjnej, za którą jest odpowiedzialny menedżer. Stewardów można automatycznie wybrać dla użytkowników testowanych w kampanii na podstawie atrybutów użytkownika lub stewardów kampanii można zdefiniować, wymieniając ich w pliku mapowanym na każdego użytkownika testowanego w kampanii na stewarda.

Po rozpoczęciu kampanii usługa BHOLD wysyła wiadomość e-mail z powiadomieniem do stewardów kampanii i właściciela kampanii, a następnie wysyła okresowe przypomnienia, aby pomóc im utrzymać postęp w kampanii. Stewardzy są kierowani do portalu kampanii, w którym mogą zobaczyć listę użytkowników, dla których są odpowiedzialni, oraz role przypisane do tych użytkowników. Stewardzy mogą następnie potwierdzić, czy są odpowiedzialni za każdego z wymienionych użytkowników i zatwierdzić lub odrzucić prawa dostępu każdego z wymienionych użytkowników.

Właściciele kampanii używają również portalu do monitorowania postępu kampanii, a działania kampanii są rejestrowane, aby właściciele kampanii mogli analizować działania podjęte w trakcie kampanii.

Raportowanie

Moduł raportowania BHOLD umożliwia wyświetlanie informacji w modelu roli za pomocą różnych raportów. Moduł raportowania BHOLD udostępnia rozbudowany zestaw wbudowanych raportów, a także kreatora, którego można użyć do tworzenia zarówno podstawowych, jak i zaawansowanych raportów niestandardowych. Po uruchomieniu raportu można natychmiast wyświetlić wyniki lub zapisać wyniki w pliku programu Microsoft Excel (.xlsx). Aby wyświetlić ten plik przy użyciu programu Microsoft Excel 2000, Microsoft Excel 2002 lub Microsoft Excel 2003, możesz pobrać i zainstalować pakiet zgodności pakietu Microsoft Office dla formatów plików Word, Excel i PowerPoint.

Moduł raportowania BHOLD jest używany głównie do tworzenia raportów opartych na bieżących informacjach o rolach. Aby wygenerować raporty dotyczące inspekcji zmian informacji o tożsamości, program Forefront Identity Manager 2010 R2 ma możliwość raportowania dla usługi FIM, która jest implementowana w System Center Service Manager Data Warehouse. Aby uzyskać więcej informacji na temat raportowania programu FIM, zobacz dokumentację forefront Identity Manager 2010 i Forefront Identity Manager 2010 R2 w bibliotece technicznej forefront Identity Management.

Kategorie objęte wbudowanymi raportami obejmują następujące elementy:

  • Administracja
  • Zaświadczanie
  • Formanty
  • Access Control do wewnątrz
  • Rejestrowanie
  • Model
  • Statystyki
  • Przepływ pracy

Możesz tworzyć raporty i dodawać je do tych kategorii lub definiować własne kategorie, w których można umieszczać niestandardowe i wbudowane raporty.

Podczas tworzenia raportu kreator wykonuje kroki przez podanie następujących parametrów:

  • Identyfikowanie informacji, w tym nazwy, opisu, kategorii, użycia i odbiorców
  • Pola do wyświetlenia w raporcie
  • Zapytania określające, które elementy mają być analizowane
  • Kolejność sortowania wierszy
  • Pola używane do dzielenia raportu na sekcje
  • Filtry umożliwiające uściślinie elementów zwracanych w raporcie

Na każdym etapie kreatora możesz wyświetlić podgląd raportu zgodnie z definicją do tej pory i zapisać go, jeśli nie musisz określać dodatkowych parametrów. Możesz również wrócić do poprzednich kroków, aby zmienić parametry określone wcześniej w kreatorze.

Łącznik zarządzania dostępem

Moduł łącznika zarządzania dostępem do pakietu BHOLD obsługuje zarówno początkową, jak i bieżącą synchronizację danych z usługą BHOLD. Łącznik zarządzania dostępem współpracuje z usługą synchronizacji programu FIM w celu przenoszenia danych między bazą danych BHOLD Core, metaverse programu MIM i aplikacjami docelowymi oraz magazynami tożsamości.

Poprzednie wersje usługi BHOLD wymagały wielu wystąpień MA do sterowania przepływem danych między tabelami baz danych MIM i pośrednimi tabelami baz danych BHOLD. W pakiecie BHOLD Suite SP1 łącznik zarządzania dostępem umożliwia definiowanie agentów zarządzania (MA) w programie MIM, którzy zapewniają transfer danych bezpośrednio między usługą BHOLD a programem MIM.

Następne kroki