Sdílet prostřednictvím

Průvodce koncepty sady Microsoft BHOLD

  • Článek

Microsoft Identity Manager 2016 (MIM) umožňuje organizacím spravovat celý životní cyklus identit uživatelů a jejich přidružených přihlašovacích údajů. Dá se nakonfigurovat tak, aby synchronizoval identity, centrálně spravoval certifikáty a hesla a zřizovat uživatele v heterogenních systémech. S MIM můžou IT organizace definovat a automatizovat procesy používané ke správě identit od vytvoření až po vyřazení z provozu.

Microsoft BHOLD Suite rozšiřuje tyto možnosti MIM přidáním řízení přístupu na základě role. BHOLD umožňuje organizacím definovat role uživatelů a řídit přístup k citlivým datům a aplikacím. Přístup je založený na tom, co je pro tyto role vhodné. BHOLD Suite obsahuje služby a nástroje, které zjednodušují modelování vztahů rolí v rámci organizace. BHOLD mapuje tyto role na práva a ověřuje, jestli jsou definice rolí a přidružená práva správně použity na uživatele. Tyto funkce jsou plně integrované s MIM a poskytují bezproblémové prostředí pro koncové uživatele i pracovníky IT.

Tato příručka vám pomůže pochopit, jak BHOLD Suite funguje s MIM, a probírá následující témata:

  • Řízení přístupu na základě role
  • Attestation
  • Generování sestav
  • Konektor pro správu přístupu

BHOLD se nedoporučuje pro nová nasazení. Microsoft Entra ID teď poskytuje kontrolu přístupu, která nahrazuje funkce kampaně ověření identity BHOLD a správu nároků, která nahrazuje funkce přiřazení přístupu.

Řízení přístupu na základě role

Nejběžnější metodou řízení přístupu uživatelů k datům a aplikacím je volitelné řízení přístupu (DAC). Ve většině běžných implementací má každý významný objekt identifikovaného vlastníka. Vlastník má možnost udělit nebo odepřít přístup k objektu ostatním na základě individuální identity nebo členství ve skupině. DaC v praxi obvykle vede k množství skupin zabezpečení, z nichž některé odrážejí organizační strukturu, jiné představují funkční seskupení (například typy úloh nebo přiřazení projektů) a další, které se skládají z provizorních kolekcí uživatelů a zařízení propojených pro dočasné účely. S tím, jak organizace rostou, je stále obtížnější spravovat členství v těchto skupinách. Pokud je například zaměstnanec převeden z jednoho projektu do jiného, skupiny, které se používají k řízení přístupu k prostředkům projektů, musí být aktualizovány ručně. V takových případech není neobvyklé, že dojde k chybám, které mohou bránit zabezpečení projektu nebo produktivitě.

MIM obsahuje funkce, které pomáhají tento problém zmírnit tím, že poskytují automatickou kontrolu nad členstvím ve skupinách a distribučním seznamu. Tím se však neřeší vnitřní složitost množitelných skupin, které spolu nemusí být strukturovaně spojeny.

Jedním ze způsobů, jak toto šíření výrazně snížit, je nasazení řízení přístupu na základě role (RBAC). Řízení přístupu na základě role nevytěsňuje DAC. RBAC staví na DAC tím, že poskytuje rámec pro klasifikaci uživatelů a IT prostředků. To vám umožní explicitně nastavit jejich vztah a přístupová práva, která jsou v souladu s touto klasifikací vhodná. Například přiřazením atributů uživatele, které určují pracovní pozici uživatele a přiřazení projektu, může být uživateli udělen přístup k nástrojům potřebným pro úlohu uživatele a datům, které uživatel potřebuje k přispívání do konkrétního projektu. Když uživatel předpokládá jinou úlohu a různá přiřazení projektu, změna atributů, které určují název úlohy uživatele a projekty, automaticky zablokuje přístup k prostředkům požadovaným pouze pro předchozí pozici uživatele.

Vzhledem k tomu, že role mohou být v rolích hierarchicky obsaženy (například role obchodního manažera a obchodního zástupce mohou být obsaženy v obecnější roli prodeje), je snadné přiřadit příslušná práva ke konkrétním rolím a přesto poskytovat odpovídající práva všem, kteří sdílejí inkluzivnější roli. Například v nemocnici by všichni zdravotníci mohli mít právo na prohlížení záznamů o pacientech, ale pouze lékaři (podrole lékařské role) mohou mít právo zadávat recepty pro pacienta. Podobně by uživatelům, kteří patří do administrativní role, mohl být odepřen přístup k záznamům pacientů s výjimkou fakturačních úředníků (dílčí role úředníka), kterým by mohl být udělen přístup k těm částem záznamů o pacientech, které jsou potřeba k fakturaci za služby poskytované nemocnicí.

Další výhodou RBAC je schopnost definovat a vynucovat oddělení povinností (SoD). To umožňuje organizaci definovat kombinace rolí, které udělují oprávnění, která by neměla mít stejný uživatel, aby konkrétnímu uživateli nebylo možné přiřadit role, které uživateli umožňují například zahájit platbu a autorizovat platbu. RBAC poskytuje možnost vynucovat takovou zásadu automaticky, místo aby bylo nutné vyhodnocovat efektivní implementaci zásad na základě jednotlivých uživatelů.

Objekty modelu rolí BHOLD

Se sadou BHOLD suite můžete určit a uspořádat role v rámci vaší organizace, mapovat uživatele na role a mapovat příslušná oprávnění k rolím. Tato struktura se nazývá model rolí a obsahuje a propojuje pět typů objektů:

  • Organizační jednotky
  • Uživatelé
  • Role
  • Oprávnění
  • Aplikace

Organizační jednotky

Organizační jednotky (OrgUnits) jsou hlavními prostředky, kterými jsou uživatelé uspořádáni v modelu rolí BHOLD. Každý uživatel musí patřit alespoň do jedné orgUnit. (Ve skutečnosti se při odebrání uživatele z poslední organizační jednotky v BHOLD odstraní jeho datový záznam z databáze BHOLD.)

Důležité

Organizační jednotky v modelu rolí BHOLD by neměly být zaměňovány s organizačními jednotkami v Active Directory Domain Services (AD DS). Struktura organizačních jednotek v BHOLD je obvykle založena na organizaci a zásadách vaší firmy, nikoli na požadavcích síťové infrastruktury.

I když to není nutné, ve většině případů jsou organizační jednotky strukturovány v BHOLD, aby představovaly hierarchickou strukturu skutečné organizace, podobně jako následující:

Ukázkový organizační diagram

V tomto příkladu by byl model organizačníganizatinální jednotka pro společnost jako celek (reprezentovaná prezidentem, protože prezident není součástí mororganizačníganizatinální jednotky) nebo by se k tomuto účelu mohla použít kořenová organizační jednotka BHOLD (která vždy existuje). Organizační jednotky, které reprezentují podnikové divize v čele s viceprezidenty, budou umístěny v organizační jednotce společnosti. Dále se organizační jednotky odpovídající marketingovým a prodejním ředitelům přidají do organizačních jednotek marketingu a prodeje a organizační jednotky představující regionální manažery prodeje budou umístěny do organizační jednotky pro manažera prodeje ve východní oblasti. Obchodníci, kteří nespravují jiné uživatele, by se stali členy organizační jednotky manažera prodeje východní oblasti. Všimněte si, že uživatelé můžou být členy organizační jednotky na libovolné úrovni. Například administrativní asistent, který není manažer a je přímo podřízen viceprezidentovi, by byl členem organizační jednotky viceprezidenta.

Kromě reprezentace organizační struktury je možné organizační jednotky použít také k seskupování uživatelů a dalších organizačních jednotek podle funkčních kritérií, například pro projekty nebo specializaci. Následující diagram znázorňuje, jak by se organizační jednotky používaly k seskupit přidružení prodeje podle typu zákazníka:

ukázková organizace projektu

V tomto příkladu by každý přidružený k prodeji patřil do dvou organizačních jednotek: jedna představuje místo přidruženého pracovníka ve struktuře řízení organizace a druhá představující zákaznickou základnu přidruženého spolupracovníka (maloobchodní nebo firemní). Každá organizační jednotka může mít přiřazené různé role, kterým je zase možné přiřadit různá oprávnění pro přístup k IT prostředkům organizace. Role se navíc dají dědit z nadřazených organizačních jednotek, což zjednodušuje proces šíření rolí mezi uživatele. Na druhou stranu je možné zabránit dědění konkrétních rolí a zajistit tak, aby konkrétní role byla přidružena pouze k příslušným organizačním jednotkám.

OrgUnits lze vytvořit v sadě BHOLD pomocí webového portálu BHOLD Core.

Uživatelé

Jak je uvedeno výše, každý uživatel musí patřit alespoň do jedné organizační jednotky (OrgUnit). Vzhledem k tomu, že organizační jednotky jsou hlavním mechanismem při přidružování uživatele k rolím, ve většině organizací patří daný uživatel do několika organizačních jednotek, aby bylo snazší přidružit role k houževnatým uživatelům. V některých případech však může být nutné přidružit roli k uživateli kromě všech organizačních jednotek, ke kterým uživatel patří. V důsledku toho může být uživatel přiřazen přímo k roli a také získávat role z organizačních jednotek, do nichž uživatel patří.

Pokud uživatel není aktivní v rámci organizace (například když je pryč kvůli lékařské dovolené), může být pozastaven, čímž se odvolá všechna oprávnění uživatele, aniž by se uživatel odebral z modelu rolí. Po návratu do služby může být uživatel znovu aktivován, čímž se obnoví všechna oprávnění udělená rolemi uživatele.

Objekty pro uživatele je možné vytvářet jednotlivě v BHOLD prostřednictvím webového portálu BHOLD Core nebo pomocí konektoru pro správu přístupu a synchronizační služby FIM k importu informací o uživatelích z takových zdrojů, jako jsou Active Directory Domain Services nebo aplikace lidských zdrojů.

Uživatele je možné vytvářet přímo v BHOLD bez použití synchronizační služby FIM. To může být užitečné při modelování rolí v předprodukčním nebo testovacím prostředí. Můžete také povolit, aby externím uživatelům (například zaměstnancům subdodavatele) byly přiřazeny role a tím udělen přístup k IT prostředkům bez přidání do databáze zaměstnanců. tito uživatelé však nebudou moci používat samoobslužné funkce BHOLD.

Role

Jak už jsme uvedli, v modelu řízení přístupu na základě role (RBAC) jsou oprávnění přidružená k rolím, nikoli k jednotlivým uživatelům. To umožňuje udělit každému uživateli oprávnění požadovaná k plnění povinností uživatele tím, že změníte role uživatele místo samostatného udělení nebo odepření oprávnění uživatele. V důsledku toho už přiřazení oprávnění nevyžaduje účast oddělení IT, ale může být provedeno v rámci správy firmy. Role může agregovat oprávnění pro přístup k různým systémům, a to buď přímo, nebo prostřednictvím podrolí, což dále snižuje potřebu zapojení IT do správy uživatelských oprávnění.

Je důležité si uvědomit, že role jsou funkcí samotného modelu RBAC. role se obvykle nezřizují pro cílové aplikace. To umožňuje používat RBAC společně se stávajícími aplikacemi, které nejsou navržené tak, aby používaly role nebo aby měnily definice rolí tak, aby odpovídaly potřebám změn obchodních modelů, aniž by bylo nutné upravovat samotné aplikace. Pokud je cílová aplikace navržená tak, aby používala role, můžete role v modelu rolí BHOLD přidružit k odpovídajícím aplikačním rolím tím, že s rolemi specifickými pro aplikaci zacházíte jako s oprávněními.

V BHOLD můžete přiřadit roli uživateli především pomocí dvou mechanismů:

  • Přiřazením role organizační jednotce (organizační jednotce), jejímž je uživatel členem
  • Přiřazením role přímo uživateli

Roli přiřazenou nadřazené organizační jednotce můžou volitelně zdědit její členské organizační jednotky. Když organizační jednotce přiřadíte roli nebo ji zdědíte, můžete ji označit jako platnou nebo navrhovanou roli. Pokud se jedná o efektivní roli, přiřadí se všem uživatelům v organizační jednotce. Pokud se jedná o navrhovanou roli, musí být aktivována pro každého uživatele nebo člena organizační jednotky, aby byla platná pro členy daného uživatele nebo organizační jednotky. To umožňuje přiřazovat uživatelům podmnožinu rolí přidružených k organizační jednotce místo automatického přiřazení všech rolí organizační jednotky všem členům. Kromě toho je možné rolím přidělovat počáteční a koncové datum a omezení je možné nastavit na procento uživatelů v organizační jednotce, pro které může být role platná.

Následující diagram znázorňuje, jak lze jednotlivým uživatelům přiřadit roli v BHOLD:

přiřazení role

V tomto diagramu je role A přiřazena organizační jednotce jako děditelná role, a proto je zděděna jejími členskými organizačními jednotkami a všemi uživateli v rámci těchto organizačních jednotek. Role B se přiřadí jako navrhovaná role pro organizační jednotku. Musí se aktivovat, aby bylo možné autorizovat uživatele v organizační jednotce s oprávněními role. Role C je efektivní role, takže její oprávnění platí okamžitě pro všechny uživatele v organizační jednotce. Role D je propojená přímo s uživatelem, takže její oprávnění se na daného uživatele vztahují okamžitě.

Kromě toho je možné pro uživatele aktivovat roli na základě atributů uživatele. Další informace najdete v tématu Autorizace na základě atributů.

Oprávnění

Oprávnění v BHOLD odpovídá autorizaci importované z cílové aplikace. To znamená, že když je BHOLD nakonfigurovaný pro práci s aplikací, obdrží seznam autorizací, které BHOLD může propojit s rolemi. Například při přidání Active Directory Domain Services (AD DS) do BHOLD jako aplikace obdrží seznam skupin zabezpečení, které mohou být jako oprávnění BHOLD propojeny s rolemi v BHOLD.

Oprávnění jsou specifická pro aplikace. BHOLD poskytuje jednotné zobrazení oprávnění, takže oprávnění je možné přidružit k rolím, aniž by správci rolí museli rozumět podrobnostem implementace oprávnění. V praxi můžou různé systémy vynucovat oprávnění odlišně. Konektor specifický pro aplikaci ze synchronizační služby FIM k aplikaci určuje, jak se dané aplikaci poskytnou změny oprávnění pro uživatele.

Aplikace

BHOLD implementuje metodu pro použití řízení přístupu na základě role (RBAC) u externích aplikací. To znamená, že když je BHOLD zřízen s uživateli a oprávněními z aplikace, BHOLD může tato oprávnění přidružit k uživatelům přiřazením rolí uživatelům a následným propojením oprávnění s rolemi. Proces aplikace na pozadí pak může namapovat správná oprávnění na své uživatele na základě mapování role/oprávnění v BHOLD.

Vývoj modelu rolí sady BHOLD Suite

Sada BHOLD Suite poskytuje nástroj Generátor modelů, který je snadno použitelný a komplexní, aby vám pomohl s vývojem modelu.

Před použitím generátoru modelů musíte vytvořit řadu souborů, které definují objekty, které Generátor modelů používá k vytvoření modelu rolí. Informace o tom, jak vytvořit tyto soubory, naleznete v tématu Microsoft BHOLD Suite Technical Reference.

Prvním krokem při použití generátoru modelů BHOLD je import těchto souborů, aby se do generátoru modelů načetly základní stavební bloky. Po úspěšném načtení souborů pak můžete zadat kritéria, která generátor modelů použije k vytvoření několika tříd rolí:

  • Role členství, které jsou přiřazené uživateli na základě organizačních jednotek (OrgUnits), do nichž uživatel patří
  • Role atributů přiřazené uživateli na základě atributů uživatele v databázi BHOLD
  • Navrhované role, které jsou propojené s organizační jednotkou, ale musí být aktivované pro konkrétní uživatele
  • Role vlastnictví, které uživatelům udělují kontrolu nad organizačními jednotkami a rolemi, pro které není v importovaných souborech zadán vlastník

Důležité

Při nahrávání souborů zaškrtněte políčko Zachovat existující model pouze v testovacích prostředích. V produkčních prostředích musíte k vytvoření počátečního modelu role použít Generátor modelů. Nemůžete ho použít k úpravě existujícího modelu rolí v databázi BHOLD.

Jakmile Generátor modelů vytvoří tyto role v modelu rolí, můžete model rolí exportovat do databáze BHOLD ve formě souboru XML.

Pokročilé funkce BHOLD

Předchozí části popisují základní funkce řízení přístupu na základě role (RBAC) v BHOLD. Tato část popisuje další funkce V BHOLD, které můžou zajistit lepší zabezpečení a flexibilitu při implementaci RBAC vaší organizace. Tato část obsahuje přehled následujících funkcí BHOLD:

  • Kardinalita
  • Rozdělení povinností
  • Kontextově přizpůsobitelná oprávnění
  • Autorizace na základě atributů
  • Flexibilní typy atributů

Kardinalita

Kardinalita odkazuje na implementaci obchodních pravidel, která jsou navržená tak, aby omezila počet, kolikrát můžou být dvě entity vzájemně propojeny. V případě BHOLD je možné vytvořit pravidla kardinality pro role, oprávnění a uživatele.

Roli můžete nakonfigurovat tak, aby omezila následující:

  • Maximální počet uživatelů, pro které je možné aktivovat navrženou roli
  • Maximální počet dílčích rolí, které lze propojit s rolí
  • Maximální počet oprávnění, která je možné propojit s rolí

Oprávnění můžete nakonfigurovat tak, aby se omezilo následující:

  • Maximální počet rolí, které je možné propojit s oprávněním
  • Maximální počet uživatelů, kterým je možné udělit oprávnění

Uživatele můžete nakonfigurovat tak, aby omezil následující:

  • Maximální počet rolí, které je možné propojit s uživatelem
  • Maximální počet oprávnění, která lze uživateli přiřadit prostřednictvím přiřazení rolí

Rozdělení povinností

Oddělení povinností (SoD) je obchodní princip, který se snaží zabránit jednotlivcům v získání schopnosti provádět akce, které by neměly být dostupné jedné osobě. Zaměstnanec by například neměl mít možnost požádat o platbu a autorizovat ji. Princip SoD umožňuje organizacím implementovat systém kontrol a vyvážení, aby se minimalizovalo jejich vystavení riziku v důsledku chyb nebo prohřešků zaměstnanců.

BHOLD implementuje SoD tím, že umožňuje definovat nekompatibilní oprávnění. Když jsou tato oprávnění definována, BHOLD vynucuje SoD tím, že brání vytváření rolí, které jsou propojené s nekompatibilními oprávněními, ať už jsou propojené přímo nebo prostřednictvím dědičnosti, a brání uživatelům v přiřazení více rolí, které by při kombinaci udělovaly nekompatibilní oprávnění, a to znovu přímým přiřazením nebo prostřednictvím dědičnosti. Volitelně je možné konflikty přepsat.

Kontextově přizpůsobitelná oprávnění

Vytvořením oprávnění, která se dají automaticky upravit na základě atributu objektu, můžete snížit celkový počet oprávnění, která musíte spravovat. Kontextově přizpůsobitelná oprávnění (CAP) umožňují definovat vzorec jako atribut oprávnění, který mění způsob použití oprávnění aplikací přidružených k oprávnění. Můžete například vytvořit vzorec, který změní přístupová oprávnění ke složce souborů (prostřednictvím skupiny zabezpečení přidružené k seznamu řízení přístupu) podle toho, jestli uživatel patří do organizační jednotky (organizační jednotky) obsahující zaměstnance na plný úvazek nebo zaměstnance na základě smlouvy. Pokud se uživatel přesune z jedné organizační jednotky do jiné, nové oprávnění se automaticky použije a staré oprávnění se deaktivuje.

Vzorec CAP se může dotazovat na hodnoty atributů, které byly použity pro aplikace, oprávnění, organizační jednotky a uživatele.

Autorizace na základě atributů

Jedním ze způsobů, jak řídit, jestli je pro konkrétního uživatele v organizační jednotce aktivována role, která je propojená s organizační jednotkou, je použití autorizace na základě atributů (ABA). Pomocí ABA můžete roli automaticky aktivovat jenom při splnění určitých pravidel založených na atributech uživatele. Roli můžete například propojit s organizační jednotkou, která se pro uživatele aktivuje jenom v případě, že pracovní pozice uživatele odpovídá pracovní pozici v pravidle ABA. Tím se eliminuje nutnost ruční aktivace navrhované role pro uživatele. Místo toho je možné roli aktivovat pro všechny uživatele v organizační jednotce, kteří mají hodnotu atributu, která splňuje pravidlo ABA role. Pravidla je možné kombinovat tak, aby se role aktivovala jenom v případě, že atributy uživatele splňují všechna pravidla ABA určená pro roli.

Je důležité si uvědomit, že výsledky testů pravidel ABA jsou omezené nastavením kardinality. Pokud například nastavení kardinality pravidla určuje, že roli nelze přiřadit více než dvěma uživatelům, a pokud by pravidlo ABA jinak aktivovalo roli pro čtyři uživatele, bude tato role aktivována pouze pro první dva uživatele, kteří prošli testem ABA.

Flexibilní typy atributů

Systém atributů v BHOLD je vysoce rozšiřitelný. Můžete definovat nové typy atributů pro takové objekty, jako jsou uživatelé, organizační jednotky (organizační jednotky) a role. Atributy mohou být definovány tak, aby měly hodnoty, které jsou celá čísla, logická hodnota (ano/ne), alfanumerické, datum, čas a e-mailové adresy. Atributy lze zadat jako jednotlivé hodnoty nebo jako seznam hodnot.

Attestation

Sada BHOLD poskytuje nástroje, které můžete použít k ověření, že jednotlivým uživatelům byla udělena příslušná oprávnění k plnění jejich obchodních úkolů. Správce může k návrhu a správě procesu ověření identity použít portál, který poskytuje modul BHOLD Ověření identity.

Proces ověření identity se provádí prostřednictvím kampaní, ve kterých mají správci kampaně příležitost a prostředky k ověření, že uživatelé, za které jsou zodpovědní, mají odpovídající přístup k aplikacím spravovaným společností BHOLD a správná oprávnění v rámci těchto aplikací. Vlastník kampaně je pověřen dohledem na kampaň a zajištěním správného provádění kampaně. Kampaň může být vytvořena jednou nebo opakovaně.

Správcem kampaně je obvykle manažer, který bude osvědčit přístupová práva uživatelů patřících k jedné nebo více organizačním jednotkám, za které je manažer zodpovědný. Správci můžou být automaticky vybráni pro uživatele ověřované v rámci kampaně na základě atributů uživatelů nebo správci kampaně mohou být definováni jejich výpisem v souboru, který mapuje každého uživatele ověřovaného v rámci kampaně na správce.

Když kampaň začne, BHOLD pošle e-mailovou zprávu s oznámením správci kampaně a vlastníkovi kampaně a pak posílá pravidelná připomenutí, která jim pomůžou udržet průběh kampaně. Správci jsou přesměrováni na portál kampaně, kde uvidí seznam uživatelů, za které jsou zodpovědní, a role, které jsou těmto uživatelům přiřazené. Správci pak můžou potvrdit, jestli jsou zodpovědní za každého z uvedených uživatelů, a schválit nebo odepřít přístupová práva každému z uvedených uživatelů.

Vlastníci kampaní také používají portál ke sledování průběhu kampaně a aktivity kampaně se protokolují, aby vlastníci kampaně mohli analyzovat akce provedené v průběhu kampaně.

Generování sestav

Modul generování sestav BHOLD umožňuje zobrazit informace v modelu rolí prostřednictvím různých sestav. Modul BHOLD Reporting poskytuje rozsáhlou sadu předdefinovaných sestav a navíc obsahuje průvodce, pomocí kterého můžete vytvářet základní i pokročilé vlastní sestavy. Při spuštění sestavy můžete okamžitě zobrazit výsledky nebo je uložit do souboru aplikace Microsoft Excel (.xlsx). Chcete-li tento soubor zobrazit pomocí aplikace Microsoft Excel 2000, Microsoft Excel 2002 nebo Microsoft Excel 2003, můžete stáhnout a nainstalovat sadu Microsoft Office Compatibility Pack pro formáty souborů Word, Excel a PowerPoint.

Modul BHOLD Reporting se používá hlavně k vytváření sestav, které jsou založené na aktuálních informacích o rolích. Aby bylo možné generovat sestavy pro auditování změn informací o identitách, Forefront Identity Manager 2010 R2 má funkci generování sestav pro službu FIM, která je implementovaná v System Center Service Manager Data Warehouse. Další informace o vytváření sestav FIM najdete v dokumentaci k produktu Forefront Identity Manager 2010 a Forefront Identity Manager R2 v technické knihovně Forefront Identity Management.

Mezi kategorie zahrnuté v předdefinovaných sestavách patří:

  • Správa
  • Attestation
  • Ovládací prvky
  • Vnitřní Access Control
  • protokolování
  • Modelování
  • Statistika
  • Pracovní postup

Můžete vytvářet sestavy a přidávat je do těchto kategorií, nebo můžete definovat vlastní kategorie, do kterých můžete umístit vlastní a předdefinované sestavy.

Při vytváření sestavy vás průvodce provede zadáním následujících parametrů:

  • Identifikační informace, včetně názvu, popisu, kategorie, použití a cílové skupiny
  • Pole, která se mají zobrazit v sestavě
  • Dotazy, které určují, které položky se mají analyzovat
  • Pořadí řazení řádků
  • Pole používaná k rozdělení sestavy do oddílů
  • Filtry pro upřesnění prvků vrácených v sestavě

V každé fázi průvodce můžete zobrazit náhled sestavy tak, jak jste ji zatím definovali, a pokud nepotřebujete zadávat další parametry, můžete ji uložit. Můžete se také vrátit k předchozím krokům a změnit parametry, které jste zadali dříve v průvodci.

Konektor pro správu přístupu

Modul BHOLD Suite Access Management Connector podporuje počáteční i průběžnou synchronizaci dat do BHOLD. Konektor pro správu přístupu spolupracuje se synchronizační službou FIM k přesouvání dat mezi databází BHOLD Core, metaverse MIM a cílovými aplikacemi a úložišti identit.

Předchozí verze BHOLD vyžadovaly k řízení toku dat mezi MIM a zprostředkujícími databázovými tabulkami BHOLD několik účtů MA. V BHOLD Suite SP1 vám Konektor pro správu přístupu umožňuje definovat agenty pro správu v MIM, kteří zajišťují přímý přenos dat mezi BHOLD a MIM.

Další kroky