Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Program Microsoft Identity Manager 2016 (MIM) umożliwia organizacjom zarządzanie całym cyklem życia tożsamości użytkowników i skojarzonymi z nimi 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. Usługa 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 oraz sprawdza, czy definicje ról i skojarzone prawa są poprawnie przypisane użytkownikom. 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 działa pakiet BHOLD z programem MIM i zawiera 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ń. Identyfikator Entra firmy Microsoft udostępnia teraz przeglądy dostępu, które zastępują funkcje kampanii zaświadczania BHOLD i 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 kontrola dostępu według uznania (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 na podstawie indywidualnej tożsamości lub członkostwa w grupie. W praktyce funkcja DAC zwykle powoduje wiele grup zabezpieczeń, niektóre odzwierciedlające strukturę organizacyjną, inne reprezentujące grupowanie funkcjonalne (takie jak typy zadań lub przypisania projektów), a inne, które składają 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 niczym niezwykłym, że błędy mogą utrudniać bezpieczeństwo lub wydajność projektu.
Program MIM zawiera funkcje, które pomagają rozwiązać ten problem, zapewniając automatyczną kontrolę nad członkostwem w grupach i listach dystrybucyjnych. Nie dotyczy to jednak wewnętrznej złożoności proliferacji grup, które nie muszą być ze sobą powiązane w sposób ustrukturyzowany.
Jednym ze sposobów znacznego zmniejszenia tej proliferacji jest wdrożenie kontroli dostępu opartej na rolach (RBAC). Kontrola dostępu oparta na rolach nie powoduje wyeliminowania kontroli dostępu opartego na dyskrecji. RBAC opiera się na DAC, zapewniając ramy do klasyfikowania użytkowników i zasobów IT. Dzięki temu można jawnie ustawić ich relację i prawa dostępu, które są odpowiednie zgodnie z tą klasyfikacją. Na przykład, przypisując użytkownikowi atrybuty, które określają stanowisko pracy i przydziały projektowe, użytkownik może otrzymać dostęp do narzędzi potrzebnych do wypełniania swoich obowiązków oraz danych, które musi dostarczyć w ramach określonego projektu. Gdy użytkownik przyjmuje inne stanowisko i różne przydziały projektowe, zmiana atrybutów określających tytuł stanowiska użytkownika i projekty automatycznie blokuje dostęp do zasobów wymaganych tylko dla poprzedniego stanowiska użytkownika.
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 urzędniczej mogą mieć odmówiony dostęp do rejestrów pacjentów z wyjątkiem pracowników działu rozliczeń (podroli roli urzędniczej), którzy mogą mieć dostęp do tych części rejestrów pacjentów, które są wymagane do rozliczania pacjenta za usługi świadczone przez szpital.
Dodatkową zaletą kontroli dostępu opartej na rolach (RBAC) jest możliwość definiowania i wymuszania rozdzielenia 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 zainicjowanie płatności i autoryzowanie płatności, na przykład. Kontrola dostępu oparta na rolach umożliwia automatyczne wymuszanie takich zasad zamiast oceniania efektywnej implementacji zasad na podstawie poszczególnych użytkowników.
Obiekty modelu ról BHOLD
Pakiet BHOLD umożliwia określanie i organizowanie ról w organizacji, mapowanie użytkowników na role i mapowanie odpowiednich uprawnień 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 jednostki Organizacyjnej. (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 usługach Active Directory Domain Services (AD DS). Zazwyczaj struktura jednostki organizacyjnej w usłudze BHOLD jest oparta na organizacji i zasadach twojej 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:
W tym przykładzie wzorcowa jednostka pełniłaby rolę jednostki organizacyjnej dla całej korporacji (reprezentowaną przez prezesa, ponieważ prezes nie jest częścią żadnej jednostki organizacyjnej), albo do tego celu mogłaby być używana główna jednostka organizacyjna BHOLD (która zawsze istnieje). Jednostki organizacyjne reprezentujące działy korporacyjne kierowane przez wiceprezesów zostaną umieszczone w jednostce organizacyjnej korporacji. 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 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 administracyjny, który nie jest menedżerem i będzie zgłaszał się bezpośrednio wiceprezesowi, 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, jak używać jednostek organizacyjnych do grupowania przedstawicieli handlowych zgodnie z typem klienta.
W tym przykładzie każdy współpracownik sprzedaży należy do dwóch jednostek organizacyjnych: jednego reprezentującego miejsce współpracownika w strukturze zarządzania organizacji i jednego reprezentującego bazę klienta współpracownika (sprzedaż detaliczną lub firmową). Każda jednostka organizacyjna może mieć przypisane różne role, które z kolei mogą mieć przypisane różne uprawnienia dostępu do zasobów IT organizacji. Ponadto role można dziedziczyć z nadrzędnych jednostek organizacyjnych, upraszczając proces propagowania 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.
Jednostki organizacyjne 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 organizacji, aby ułatwić kojarzenie ról z tym użytkownikiem. W niektórych przypadkach jednak może być konieczne skojarzenie roli z użytkownikiem poza wszystkimi 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 służby 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 BHOLD za pośrednictwem portalu internetowego BHOLD Core lub za pomocą łącznika zarządzania dostępem z usługą synchronizacji FIM w celu zaimportowania informacji o użytkownikach z takich źródeł, jak usług Active Directory Domain Services lub aplikacje kadrowe.
Użytkownicy można tworzyć bezpośrednio w usłudze BHOLD bez korzystania z usługi synchronizacji programu FIM. Może to być przydatne podczas modelowania ról w środowisku przedprodukcyjnym lub testowym. Możesz 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 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 dodatkowo 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ą przypisywane aplikacjom docelowym. Dzięki temu kontrola dostępu oparta na rolach może być używana razem z istniejącymi aplikacjami, które nie są zaprojektowane do używania ról, oraz umożliwia zmianę definicji ról, aby dostosować się do zmieniających się modeli biznesowych, bez konieczności modyfikowania samych aplikacji. Jeśli aplikacja docelowa jest przeznaczona do używania ról, możesz 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 jego jednostki organizacyjne członkowskie. 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, należy ją aktywować, aby każdy użytkownik lub członek jednostki organizacyjnej stał się skuteczny 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 umieścić na procentach użytkowników w jednostce organizacyjnej, dla której rola może być skuteczna.
Na poniższym diagramie przedstawiono sposób przypisywania roli poszczególnych użytkowników w usłudze BHOLD:
Na tym diagramie rola A jest przypisywana do jednostki organizacyjnej jako rola dziedziczna, i dlatego jest dziedziczona przez jednostki organizacyjne członkowskie oraz wszystkich użytkowników w tych jednostkach organizacyjnych. Rola B jest przypisywana jako proponowana rola dla jednostki organizacyjnej. Musi zostać aktywowany, zanim użytkownik w jednostce organizacyjnej będzie mógł być autoryzowany z uprawnieniami roli. Rola C jest efektywną rolą, więc jej uprawnienia mają zastosowanie natychmiast do wszystkich użytkowników w jednostce organizacyjnej. Rola D jest połączona bezpośrednio z użytkownikiem i dlatego 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 gdy usługi Active Directory Domain Services (AD DS) są dodawane do usługi BHOLD jako aplikacja, otrzymuje listę grup zabezpieczeń, które jako uprawnienia BHOLD mogą być połączone z rolami w usłudze BHOLD.
Uprawnienia są specyficzne dla aplikacji. Pakiet BHOLD zapewnia pojedynczy, ujednolicony widok uprawnień, dzięki czemu uprawnienia mogą być skojarzone z rolami bez konieczności rozumienia szczegółów implementacji uprawnień przez menedżerów ról. W praktyce różne systemy mogą wymuszać uprawnienie inaczej. Łącznik specyficzny dla aplikacji z usługi FIM Synchronization Service do aplikacji określa sposób, w jaki zmiany uprawnień dla użytkownika są przekazywane tej aplikacji.
Aplikacje
Usługa BHOLD implementuje metodę stosowania kontroli dostępu opartej na rolach (RBAC) do aplikacji zewnętrznych. To znaczy, że gdy BHOLD zostanie wyposażony w użytkowników oraz uprawnienia pochodzące z aplikacji, może przyporządkować te uprawnienia do użytkowników poprzez przypisanie ról tym użytkownikom, a następnie połączenie uprawnień z rolami. Proces w tle aplikacji może następnie przypisywać odpowiednie uprawnienia użytkownikom na podstawie mapowania uprawnień przypisanych do ról w BHOLD.
Opracowywanie modelu ról systemu BHOLD Suite
Aby ułatwić opracowywanie modelu ról, 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 modeli do konstruowania modelu ról. Aby uzyskać informacje o sposobie tworzenia tych plików, zobacz Dokumentacja techniczna pakietu Microsoft BHOLD Suite.
Pierwszym krokiem korzystania z 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 utworzenia kilku klas ról:
- Role członkostwa przypisane do użytkownika w oparciu o jednostki Organizacyjne (jednostki organizacyjne), 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 zaimportowanych 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żywać do modyfikowania istniejącego modelu roli w bazie danych BHOLD.
Po utworzeniu tych ról przez Model Generator w modelu ról, można następnie 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 w usłudze BHOLD, które mogą zapewnić zwiększone bezpieczeństwo i elastyczność implementacji kontroli dostępu opartej na rolach organizacji. Ta sekcja zawiera omówienie następujących funkcji usługi 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 kwestie:
- Maksymalna liczba ról, które można połączyć 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
Separacja obowiązków (SoD) to zasada biznesowa, która ma na celu zapobieganie uzyskaniu możliwości wykonywania działań, które nie powinny być dostępne dla jednej osoby. Na przykład pracownik nie powinien mieć możliwości zażądania płatności i autoryzowania płatności. Zasada SoD umożliwia organizacjom wdrożenie systemu kontroli i równowagi w celu zminimalizowania narażenia na ryzyko wystąpienia błędu pracownika lub wykroczenia.
Usługa BHOLD implementuje soD, umożliwiając definiowanie niezgodnych uprawnień. Po zdefiniowaniu tych uprawnień, usługa BHOLD wymusza zasadę SoD, zapobiegając tworzeniu ról związanych z niezgodnymi uprawnieniami, niezależnie od tego, czy są one połączone bezpośrednio, czy za pośrednictwem dziedziczenia, oraz uniemożliwiając przypisywanie użytkownikom wielu ról, które łącznie nadawałyby niezgodne uprawnienia, zarówno poprzez bezpośrednie przypisanie, jak i dziedziczenie. Opcjonalnie konflikty można przesłaniać.
Uprawnienia do dostosowywania kontekstu
Tworząc uprawnienia, które można automatycznie modyfikować na podstawie atrybutu obiektu, można zmniejszyć łączną 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 staje się aktywna dla użytkownika tylko wtedy, gdy tytuł zadania użytkownika jest zgodny z tytułem zadania w regule ABA. Eliminuje to konieczność ręcznego aktywowania proponowanej roli dla użytkownika. Zamiast tego można aktywować rolę 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 ABA w przeciwnym razie aktywuje rolę dla czterech użytkowników, rola zostanie aktywowana tylko dla dwóch pierwszych użytkowników, którzy przejdą 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, logiczne (tak/nie), alfanumeryczne, daty, godziny 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 sprawdzenia, czy poszczególne użytkownicy otrzymali odpowiednie uprawnienia do wykonywania zadań biznesowych. Administrator może używać portalu udostępnionego przez moduł zaświadczania BHOLD do projektowania procesu zaświadczania i zarządzania nim.
Proces poświadczania odbywa się za pomocą kampanii, w których steward kampanii otrzymuje możliwość i środki do zweryfikowania, czy użytkownicy, za których są odpowiedzialni, mają odpowiedni dostęp do aplikacji zarządzanych przez BHOLD i poprawne uprawnienia w tych aplikacjach. Właściciel kampanii jest wyznaczony do nadzorowania kampanii i zapewnienia prawidłowego przeprowadzenia kampanii. Można utworzyć kampanię jednorazową lub cykliczną.
Zazwyczaj stewardem kampanii będzie menedżer, który będzie potwierdzać prawa dostępu dla użytkowników należących do co najmniej jednej jednostki organizacyjnej, za którą jest odpowiedzialny. Stewardzy mogą być automatycznie wybierani dla użytkowników testowanych w kampanii na podstawie atrybutów użytkownika lub stewardów kampanii można zdefiniować, wyświetlając je w pliku, który mapuje 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. Następnie stewardzy mogą 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 pośrednictwem różnych raportów. Moduł raportowania BHOLD udostępnia obszerny zestaw wbudowanych raportów, a ponadto zawiera 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 programu 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 tożsamości, program Forefront Identity Manager 2010 R2 ma możliwość raportowania dla usługi FIM, która jest implementowana w magazynie danych programu System Center Service Manager. Aby uzyskać więcej informacji na temat raportowania programu FIM, zobacz dokumentację programu Forefront Identity Manager 2010 i Forefront Identity Manager 2010 R2 w bibliotece technicznej programu Forefront Identity Management.
Kategorie objęte wbudowanymi raportami obejmują następujące elementy:
- Administracja
- Zaświadczanie
- Sterowanie
- Kontrola dostępu do wewnątrz
- Logowanie
- Model
- Statystyka
- 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 prowadzi przez dostarczanie następujących parametrów:
- Identyfikowanie informacji, w tym nazwy, opisu, kategorii, użycia i odbiorców
- Pola, które mają być wyświetlane 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żna wyświetlić podgląd raportu zgodnie z definicją do tej pory i zapisać go, jeśli nie trzeba 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ł BHOLD Suite Access Management Connector 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 repozytoriami tożsamości.
Poprzednie wersje pakietu BHOLD wymagały wielu agentów zarządzania MA do kontrolowania przepływu danych między MIM a 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 zapewniających transfer danych bezpośrednio między usługą BHOLD i programem MIM.