Przewodnik po pojęciach związanych z pakietem Microsoft BHOLD Suite

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

Pakiet Microsoft BHOLD Suite rozszerza te możliwości MIM przez dodanie kontroli dostępu opartej na rolach. Funkcja 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 obejmuje usługi i narzędzia, które upraszczają modelowanie relacji ról w organizacji. Związek BHOLD mapuje te role na prawa i w celu sprawdzenia, 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 MIM, zapewniając bezproblemowe środowisko dla użytkowników końcowych i pracowników IT.

Ten przewodnik pomaga zrozumieć, jak pakiet BHOLD współpracuje MIM i obejmuje następujące tematy:

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

Pakietu BHOLD nie zaleca się w przypadku nowych wdrożeń. Usługa Azure AD udostępnia teraz przeglądydostępu, które zastępują funkcje kampanii zaświadczeń BHOLD i zarządzanie uprawnieniami, 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 do danych (DAC, discretionary access control). 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 DAC zazwyczaj powoduje mnóstwo grup zabezpieczeń, niektóre odzwierciedlają strukturę organizacyjną, inne reprezentujące grupowania funkcjonalne (takie jak typy zadań lub przypisania projektu), a inne, które składają się z prowizoryczne kolekcje użytkowników i urządzeń, które są połączone w bardziej tymczasowych celach. W przypadku rozwoju organizacji zarządzanie członkostwem w tych grupach staje się coraz trudniejsze. 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 nierzadko zdarzają się błędy, błędy, które mogą utrudniać bezpieczeństwo projektu lub produktywność.

MIM zawiera funkcje, które pomagają rozwiązać 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 proliferating grup, które niekoniecznie są ze sobą powiązane w ustrukturyzowany sposób.

Jednym ze sposobów znacznego zmniejszenia tego rozpowszechnienia jest wdrożenie kontroli dostępu opartej na rolach (RBAC). RBAC nie wypiera DAC. RBAC opiera się na kontroli DAC przez zapewnienie struktury do klasyfikowania użytkowników i zasobów IT. Dzięki temu można jawnie ująć ich relacje i prawa dostępu, które są odpowiednie zgodnie z tą klasyfikacją. Na przykład przez przypisanie do użytkownika atrybutów, które określają stanowisko użytkownika i przypisania projektu, użytkownikowi można przyznać dostęp do narzędzi potrzebnych do pracy użytkownika i danych, które użytkownik musi współtwolić w konkretnym projekcie. Gdy użytkownik zakłada inne zadanie i różne przypisania projektu, zmiana atrybutów określających stanowisko użytkownika i projekty automatycznie blokuje dostęp do zasobów wymaganych tylko dla poprzednich pozycji użytkowników.

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), można łatwo przypisać odpowiednie prawa do określonych ról i nadal zapewniać odpowiednie prawa wszystkim użytkownikom, którzy pełnią również rolę bardziej inkluzywną. Na przykład w szpitalach wszyscy pracownicy medyczni mogą mieć prawo do wyświetlania dokumentacji pacjentów, ale tylko lekarzom (podroli roli medycznej) można nadawać prawo do wprowadzania leków dla pacjenta. Analogicznie, użytkownikom należącym do roli klerowej można odmówić dostępu do dokumentacji pacjentów z wyjątkiem rejestrów rozliczeniowych (roli podrzędnej roli klerowej), którym można przyznać dostęp do tych części rekordów pacjentów, które są wymagane do rozliczania pacjenta za usługi świadczone przez szpital.

Dodatkową korzyścią z kontroli dostępu na podstawie ról jest możliwość definiowania i wymuszania rozdzielenia obowiązków (SoD). Dzięki temu organizacja może definiować kombinacje ról, które przyznają uprawnienia, które nie powinny być przechowywane przez tego samego użytkownika, tak aby określony użytkownik nie mógł mieć przypisanych ról, które umożliwiają mu inicjowanie płatności i autoryzowanie płatności, na przykład. RBAC zapewnia możliwość automatycznego wymuszania takich zasad, a nie konieczności oceniania efektywnej implementacji zasad dla per-user basis.

Obiekty modelu roli BHOLD

Pakiet BHOLD umożliwia określanie i organizowanie ról w organizacji, mapowanie użytkowników na role oraz mapowanie odpowiednich uprawnień na role. Ta struktura jest nazywana modelem roli i zawiera i łączy pięć typów obiektów:

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

Jednostki organizacyjne

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

Ważne

Jednostek organizacyjnych w modelu roli BHOLD nie należy mylić z jednostkami organizacyjnymi w Active Directory Domain Services (AD DS). Zazwyczaj struktura jednostki organizacyjnej w PChN 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 mają strukturę BHOLD reprezentującą strukturę hierarchiczną rzeczywistej organizacji, podobną do poniższej:

przykładowy wykres organizacyjny

W tym przykładzie model roli byłby organizacyjnymjednoczości organizacyjnej dla całej firmy (reprezentowanej przez prezesa, ponieważ nie należy do jednostki mororganizalnej) lub do tego celu można użyć głównej jednostki organizacyjnej BHOLD (która zawsze istnieje). Jednostki organizacyjne reprezentujące oddziały firmy, na których siedzibą są wiceprezesi, zostaną umieszczone w firmowej jednostce organizacyjnej. 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, zostaną 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 podlega 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 sposób użycia jednostek organizacyjnych do grupowania partnerów sprzedaży według typu klienta:

organizacja przykładowego projektu

W tym przykładzie każdy partner sprzedaży będzie należeć do dwóch jednostek organizacyjnych: jednej reprezentującej miejsce współpracownika w strukturze zarządzania organizacji i jednej reprezentującej bazę klientów tego współpracownika (sprzedaż detaliczna lub firmowa). Do każdej jednostki organizacyjnej można przypisać różne role, którym z kolei można przypisać 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 można zapobiec dziedziczeniu określonych ról, zapewniając, że konkonowana rola jest skojarzona tylko z odpowiednimi jednostkami organizacyjnymi.

Jednostki Organizacyjne można utworzyć w Pakiecie BHOLD za pomocą portalu sieci Web 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. Jednak w niektórych przypadkach może być konieczne skojarzenie roli z użytkownikiem poza jednostkami Organizacyjnymi, do których należy użytkownik. W związku z tym użytkownik może zostać przypisany bezpośrednio do roli, a także uzyskać role z jednostki Organizacyjnej, do której należy użytkownik.

Jeśli użytkownik nie jest aktywny w organizacji (na przykład podczas opuszczania firmy na potrzeby urlopu medycznego), można go zawiesić, co oznacza odwołanie wszystkich uprawnień użytkownika bez usuwania go z modelu roli. Po powrocie do obowiązków użytkownik może zostać ponownie uaktywniony, co przywraca wszystkie uprawnienia przyznane przez role użytkownika.

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

Użytkowników można tworzyć bezpośrednio w pchnie BHOLD bez korzystania z usługi FIM Synchronization Service. 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 uzyskanie dostępu do zasobów IT bez dodawana 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 z poszczególnymi użytkownikami. Dzięki temu można przyznać każdemu użytkownikowi uprawnienia wymagane do wykonywania obowiązków użytkownika, zmieniając jego role, zamiast oddzielnie udzielać lub odmawiać uprawnień użytkownika. W związku z tym przypisywanie 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 do uzyskiwania 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ą aprowowane dla aplikacji docelowych. Dzięki temu RBAC może być używany razem z istniejącymi aplikacjami, które nie są przeznaczone do używania ról lub do zmiany definicji ról, aby spełnić potrzeby zmiany modeli biznesowych bez konieczności modyfikowania samych aplikacji. Jeśli aplikacja docelowa jest przeznaczona do używania ról, można skojarzyć role w modelu roli BHOLD z odpowiadającymi im rolami aplikacji, traktując role specyficzne dla aplikacji jako uprawnienia.

W PCHN można przypisać rolę do użytkownika przede wszystkim za pośrednictwem dwóch mechanizmów:

  • Przypisanie roli do jednostki organizacyjnej (jednostki organizacyjnej), której użytkownik jest członkiem
  • Przypisanie roli bezpośrednio do użytkownika

Rola przypisana do nadrzędnej jednostki organizacyjnej opcjonalnie może być dziedziczona przez jej członkowskie jednostki organizacyjne. Gdy rola jest przypisana do jednostki organizacyjnej lub dziedziczona przez nie, 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 być aktywowana dla każdego użytkownika lub członka jednostki organizacyjnej, aby stała się skuteczna dla tego użytkownika lub członków jednostki organizacyjnej. Dzięki temu można przypisać użytkownikom podzbiór ról skojarzonych z jednostką organizacyjną, zamiast automatycznie przypisywać wszystkie role jednostki organizacyjnej do wszystkich członków. Ponadto role mogą mieć datę rozpoczęcia i zakończenia, a limity mogą być umieszczane na procencie użytkowników w jednostce organizacyjnej, dla której rola może być efektywna.

Na poniższym diagramie pokazano, jak można przypisać poszczególnym użytkownikom rolę w PChN:

przypisanie roli

Na tym diagramie rola A jest przypisywana do jednostki organizacyjnej jako rola dziedziczona, a więc jest dziedziczona przez jej członkowskie jednostki organizacyjne i wszystkich użytkowników w tych jednostkach organizacyjnych. Rola B jest przypisywana jako proponowana rola dla jednostki organizacyjnej. Należy ją aktywować, aby można było autoryzować użytkownika w jednostce organizacyjnej z uprawnieniami roli. Rola C jest efektywną rolą, więc jej uprawnienia są natychmiast stosowane do wszystkich użytkowników w jednostce organizacyjnej. Rola D jest połączona bezpośrednio z użytkownikiem, więc jej uprawnienia są natychmiast stosowane do tego użytkownika.

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

Uprawnienia

Uprawnienie w PCHN odpowiada autoryzacji zaimportowane z aplikacji docelowej. Oznacza to, że gdy BHOLD jest skonfigurowany do pracy z aplikacją, otrzymuje listę autoryzacji, które można połączyć Z rolami. Na przykład gdy Active Directory Domain Services (AD DS) jest dodawany do BHOLD jako aplikacja, otrzymuje listę grup zabezpieczeń, które jako uprawnienia BHOLD, mogą być połączone z rolami w PChN.

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

Aplikacje

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

Tworzenie modelu roli pakietu BHOLD Suite

Aby ułatwić opracowywanie modelu roli, pakiet BHOLD Suite udostępnia narzędzie Generator modeli, które jest łatwe w użyciu 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 roli. Informacje na temat tworzenia tych plików można znaleźć w dokumentacji technicznej 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, które są połączone z jednostką organizacyjną, ale muszą być aktywowane dla określonych użytkowników
  • Role własności, które przyznają 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 do utworzenia początkowego modelu roli. Nie można go użyć do zmodyfikowania istniejącego modelu roli w bazie danych BHOLD.

Gdy generator modeli utworzy te role w modelu roli, można wyeksportować model roli do bazy danych pakietu BHOLD w postaci pliku XML.

Zaawansowane funkcje BHOLD

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

  • Kardynalność
  • Rozdzielenie obowiązków
  • Uprawnienia dostosowywalne kontekstowo
  • Autoryzacja oparta na atrybutach
  • Elastyczne typy atrybutów

Kardynalność

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

Rolę można skonfigurować w taki sposób, aby ograniczyć następujące możliwości:

  • 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 możliwości:

  • Maksymalna liczba ról, które można połączyć z uprawnieniem
  • Maksymalna liczba użytkowników, którzy mogą uzyskać uprawnienia

Możesz skonfigurować użytkownika w taki sposób, aby ograniczał następujące możliwości:

  • Maksymalna liczba ról, które można połączyć z użytkownikiem
  • Maksymalna liczba uprawnień, które można przypisać do użytkownika za pomocą przypisań ról

Rozdzielenie obowiązków

Podział obowiązków (SoD, Separation of duties) to zasada biznesowa, 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 mieć możliwości zażądania płatności i autoryzowania płatności. Zasada SoD umożliwia organizacjom wdrożenie systemu kontroli i sald w celu zminimalizowania ich narażenia na ryzyko związane z błędami lub błędami pracownika.

BHOLD implementuje SoD, umożliwiając definiowanie niezgodnych uprawnień. Gdy te uprawnienia są zdefiniowane, BHOLD wymusza SoD, uniemożliwiając tworzenie ról, które są połączone z niezgodnymi uprawnieniami, czy są połączone bezpośrednio lub za pośrednictwem dziedziczenia, i uniemożliwiając użytkownikom przypisanie wielu ról, które po połączeniu, można udzielić niezgodnych uprawnień, ponownie przez przypisanie bezpośrednie lub za pośrednictwem dziedziczenia. Opcjonalnie można przesłonić konflikty.

Uprawnienia dostosowywalne kontekstowo

Tworząc uprawnienia, które mogą być automatycznie modyfikowane na podstawie atrybutu obiektu, można zmniejszyć łączną liczbę uprawnień, które trzeba zarządzać. Uprawnienia kontekstowe umożliwiają zdefiniowanie formuły jako atrybutu uprawnień, który modyfikuje sposób stosowania uprawnień przez aplikację skojarzoną 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 do folderu) na podstawie tego, czy użytkownik należy do jednostki organizacyjnej zawierającej pełnoetatowych pracowników, czy pracowników kontraktowych. Jeśli użytkownik zostanie przeniesiony z jednej jednostki organizacyjnej do innej, nowe uprawnienie zostanie automatycznie zastosowane i stare uprawnienie zostanie dezaktywowane.

Formuła CAP może odpytować 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 na podstawie atrybutów użytkownika. Na przykład można połączyć rolę z jednostką organizacyjną, która stanie się aktywna dla użytkownika tylko wtedy, gdy stanowisko użytkownika jest takie sam jak stanowisko w regułę 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, która spełnia regułę ABA roli. Reguły mogą być łączone, dzięki czemu rola jest 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 rolę może przypisać nie więcej niż dwóch użytkowników, a jeśli reguła ABA aktywowałaby 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 PChN jest wysoce rozszerzalny. Można zdefiniować nowe typy atrybutów dla takich obiektów jak użytkownicy, jednostki organizacyjne (jednostki organizacyjne) i role. Atrybuty mogą mieć wartości, które są liczbami całkowitymi, wartościami logicznymi (tak/nie), alfanumerycznymi, datą, godziną i adresami e-mail. Atrybuty można określić jako pojedyncze wartości lub listę wartości.

Zaświadczanie

Pakiet BHOLD udostępnia narzędzia, za pomocą których można sprawdzić, czy poszczegółowi użytkownicy otrzymali odpowiednie uprawnienia do wykonywania swoich zadań biznesowych. Administrator może użyć portalu dostarczonego przez moduł zaświadczenia BHOLD, aby zaprojektować proces zaświadczenia i zarządzać tym procesem.

Proces zaświadczenia jest prowadzony w ramach kampanii, w których osoby odpowiedzialne za przeprowadzanie kampanii mają możliwość uzyskania dostępu do aplikacji zarządzanych przez odpowiedzialność BHOLD oraz czy mają odpowiednie uprawnienia w tych aplikacjach. Właściciel kampanii jest wyznaczony do nadzorowania kampanii i zapewnienia, że kampania została przeprowadzona prawidłowo. Kampanię można utworzyć raz lub cyklicznie.

Zazwyczaj kierownikiem, 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, jest menedżer. Można automatycznie wybierać grupy użytkowników, którzy mają atest w kampanii, na podstawie atrybutów użytkowników. Można też zdefiniować listę użytkowników w pliku, który mapuje każdego użytkownika, który ma zostać atestowany w kampanii na akcję.

Po rozpoczęciem kampanii firma BHOLD wysyła wiadomość e-mail z powiadomieniem do właściciela i właściciela kampanii, a następnie wysyła okresowe przypomnienia, aby pomóc im utrzymać postęp w kampanii. Użytkownicy są kierowani do portalu kampanii, w którym widzą listę użytkowników, za których są oni odpowiedzialni, oraz role przypisane do tych użytkowników. Następnie użytkownicy mogą potwierdzić, czy są odpowiedzialni za każdego z wymienionych użytkowników, i zatwierdzić lub odmówić praw dostępu poszczególnych użytkowników na liście.

Właściciele kampanii używają również portalu do monitorowania postępu kampanii, a działania związane z kampanią są rejestrowane, dzięki czemu właściciele kampanii mogą analizować akcje, które zostały wykonane 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 zawiera rozbudowany zestaw wbudowanych raportów oraz kreator, za pomocą których można tworzyć raporty niestandardowe zarówno podstawowe, jak i zaawansowane. Po uruchomieniu raportu można natychmiast wyświetlić wyniki lub zapisać je w pliku 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 programu Microsoft Office dla formatów plików programu Word, Excel i PowerPoint.

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

Wbudowane raporty obejmują następujące kategorie:

  • Administracja
  • Zaświadczanie
  • Formanty
  • Wewnętrzne Access Control
  • 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ć raporty niestandardowe i wbudowane.

Podczas tworzenia raportu kreator przeprowadzi Cię przez proces dostarczania następujących parametrów:

  • Identyfikowanie informacji, w tym nazwy, opisu, kategorii, użycia i odbiorców
  • Pola do wyświetlania w raporcie
  • Zapytania określające, które elementy mają być analizowane
  • Kolejność sortowania wierszy
  • Pola używane do łamania raportu na sekcje
  • Filtry uściśliwają elementy zwracane 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 trwającą synchronizację danych z pakietem BHOLD. Łącznik zarządzania dostępem współpracuje z usługą FIM Synchronization Service w celu przenoszenia danych między bazą danych BHOLD Core, MIM metaverse oraz docelowymi aplikacjami i magazynami tożsamości.

Poprzednie wersje klasy BHOLD wymagały wielu administratorów MA do kontrolowania przepływu danych między 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 pakiecie MIM, które zapewniają transfer danych bezpośrednio między pakietem BHOLD i MIM.

Następne kroki