Conceptenhandleiding voor Microsoft BHOLD Suite

met Microsoft Identity Manager 2016 (MIM) kunnen organisaties de volledige levenscyclus van gebruikersidentiteiten en de bijbehorende referenties beheren. Het kan worden geconfigureerd om identiteiten te synchroniseren, certificaten en wachtwoorden centraal te beheren en gebruikers in heterogene systemen in te richten. Met MIM kunnen IT-organisaties de processen definiëren en automatiseren die worden gebruikt om identiteiten te beheren, van het maken tot het buiten gebruik stellen.

Microsoft BHOLD Suite breidt deze mogelijkheden van MIM uit door op rollen gebaseerd toegangsbeheer toe te voegen. Met BHOLD kunnen organisaties gebruikersrollen definiëren en de toegang tot gevoelige gegevens en toepassingen beheren. De toegang is gebaseerd op wat geschikt is voor deze rollen. BHOLD Suite bevat services en hulpprogramma's die het modelleren van de rolrelaties binnen de organisatie vereenvoudigen. BHOLD wijst deze rollen toe aan rechten en om te controleren of de roldefinities en bijbehorende rechten correct worden toegepast op gebruikers. Deze mogelijkheden zijn volledig geïntegreerd met MIM en bieden een naadloze ervaring voor zowel eindgebruikers als IT-medewerkers.

Deze handleiding helpt u te begrijpen hoe BHOLD Suite werkt met MIM en behandelt de volgende onderwerpen:

• Op rollen gebaseerd toegangsbeheer
• Attestation
• Rapporten
• Connector voor toegangsbeheer

BHOLD wordt niet aanbevolen voor nieuwe implementaties. Microsoft Entra-id biedt nu toegangsbeoordelingen, die de BHOLD Attestation-campagnefuncties vervangen, en rechtenbeheer, dat de functies voor toegangstoewijzing vervangt.

Op rollen gebaseerd toegangsbeheer

De meest voorkomende methode voor het beheren van gebruikerstoegang tot gegevens en toepassingen is via discretionair toegangsbeheer (DAC). In de meest voorkomende implementaties heeft elk belangrijk object een geïdentificeerde eigenaar. De eigenaar heeft de mogelijkheid om anderen toegang tot het object te verlenen of te weigeren op basis van individuele identiteit of groepslidmaatschap. In de praktijk resulteert DAC meestal in een overvloed aan beveiligingsgroepen, sommige die de organisatiestructuur weerspiegelen, andere die functionele groeperingen vertegenwoordigen (zoals taaktypen of projecttoewijzingen), en andere die bestaan uit geïmproviseerde verzamelingen gebruikers en apparaten die zijn gekoppeld voor meer tijdelijke doeleinden. Naarmate organisaties groeien, wordt het lidmaatschap van deze groepen steeds moeilijker te beheren. Als een werknemer bijvoorbeeld wordt overgedragen van het ene project naar het andere, moeten de groepen die worden gebruikt om de toegang tot de projectassets te beheren, handmatig worden bijgewerkt. In dergelijke gevallen is het niet ongebruikelijk dat er fouten optreden, fouten die de projectbeveiliging of productiviteit kunnen belemmeren.

MIM bevat functies die helpen dit probleem te verhelpen door geautomatiseerde controle te bieden over groep- en distributielijstlidmaatschap. Dit heeft echter geen betrekking op de intrinsieke complexiteit van prolifererende groepen die niet noodzakelijkerwijs op een gestructureerde manier aan elkaar zijn gerelateerd.

Een manier om deze verspreiding aanzienlijk te verminderen, is door op rollen gebaseerd toegangsbeheer (RBAC) te implementeren. RBAC verplaatst DAC niet. RBAC bouwt voort op DAC door een framework te bieden voor het classificeren van gebruikers en IT-resources. Hiermee kunt u hun relatie en de toegangsrechten expliciet maken die geschikt zijn volgens die classificatie. Door bijvoorbeeld gebruikerskenmerken toe te wijzen die de functie en projecttoewijzingen van gebruikers opgeven, kan de gebruiker toegang krijgen tot hulpprogramma's die nodig zijn voor de taak van de gebruiker en gegevens die de gebruiker nodig heeft om bij te dragen aan een bepaald project. Wanneer de gebruiker uitgaat van een andere taak en andere projecttoewijzingen, wordt de toegang tot de resources die alleen nodig zijn voor de vorige functie van de gebruiker, automatisch geblokkeerd door het wijzigen van de kenmerken die de functie en projecten van de gebruiker opgeven.

Omdat rollen op hiërarchische wijze in rollen kunnen worden opgenomen (de rollen van verkoopmanager en verkoopvertegenwoordiger kunnen bijvoorbeeld worden opgenomen in de meer algemene rol van verkoop), is het eenvoudig om de juiste rechten toe te wijzen aan specifieke rollen en toch nog steeds de juiste rechten te bieden aan iedereen die de meer inclusieve rol deelt. In een ziekenhuis kan bijvoorbeeld al het medisch personeel het recht krijgen om patiëntendossiers in te zien, maar alleen artsen (een subrol van de medische rol) kunnen het recht krijgen om recepten voor de patiënt in te voeren. Op dezelfde manier kunnen gebruikers die behoren tot de administratieve rol, de toegang tot patiëntendossiers worden geweigerd, met uitzondering van factureringsmedewerkers (een subrol van de administratieve rol), die toegang kunnen krijgen tot die gedeelten van een patiëntenrecord die de patiënt moeten factureren voor services die door het ziekenhuis worden geleverd.

Een extra voordeel van RBAC is de mogelijkheid om scheiding van taken (SoD) te definiëren en af te dwingen. Hierdoor kan een organisatie combinaties van rollen definiëren die machtigingen verlenen die niet door dezelfde gebruiker mogen worden gehouden, zodat aan een bepaalde gebruiker geen rollen kunnen worden toegewezen waarmee de gebruiker bijvoorbeeld een betaling kan initiëren en een betaling kan autoriseren. RBAC biedt de mogelijkheid om een dergelijk beleid automatisch af te dwingen in plaats van de effectieve implementatie van het beleid per gebruiker te evalueren.

BHOLD-rolmodelobjecten

Met BHOLD Suite kunt u rollen binnen uw organisatie opgeven en organiseren, gebruikers toewijzen aan rollen en de juiste machtigingen toewijzen aan rollen. Deze structuur wordt een rolmodel genoemd en bevat vijf typen objecten en verbindt deze:

• Organisatie-eenheden
• Gebruikers
• Rollen
• Machtigingen
• Toepassingen

Organisatie-eenheden

Organisatie-eenheden (OrgUnits) zijn de belangrijkste middelen waarmee gebruikers worden georganiseerd in het BHOLD-rolmodel. Elke gebruiker moet tot ten minste één OrgUnit behoren. (Wanneer een gebruiker wordt verwijderd uit de laatste organisatie-eenheid in BHOLD, wordt de gegevensrecord van de gebruiker verwijderd uit de BHOLD-database.)

Belangrijk

Organisatie-eenheden in het BHOLD-rolmodel moeten niet worden verward met organisatie-eenheden in Active Directory Domain Services (AD DS). Normaal gesproken is de structuur van de organisatie-eenheid in BHOLD gebaseerd op de organisatie en het beleid van uw bedrijf, niet op de vereisten van uw netwerkinfrastructuur.

Hoewel dit niet vereist is, zijn organisatie-eenheden in de meeste gevallen gestructureerd in BHOLD om de hiërarchische structuur van de werkelijke organisatie weer te geven, vergelijkbaar met de onderstaande:

In dit voorbeeld zou het rolmodel een organisatieganizatinale eenheid voor het bedrijf als geheel (vertegenwoordigd door de president, omdat de president geen deel uitmaakt van een mororganizationalganizatinal-eenheid), of de BHOLD-hoofdorganisatie-eenheid (die altijd bestaat) voor dat doel kunnen worden gebruikt. OrgUnits die de bedrijfsafdelingen vertegenwoordigen onder leiding van de vice-presidenten, worden in de bedrijfsorganisatie-eenheid geplaatst. Vervolgens worden organisatie-eenheden die overeenkomen met de marketing- en verkoopdirecteuren toegevoegd aan de organisatie-eenheden marketing en verkoop en organisatie-eenheden die de regionale verkoopmanagers vertegenwoordigen, in de organisatie-eenheid voor de verkoopmanager in de regio Oost. Verkoopmedewerkers, die geen andere gebruikers beheren, worden lid van de organisatie-eenheid van de verkoopmanager van de regio Oost. Houd er rekening mee dat gebruikers lid kunnen zijn van een organisatie-eenheid op elk niveau. Een administratieve assistent, die geen manager is en rechtstreeks rapporteert aan een vice-president, zou bijvoorbeeld lid zijn van de organisatie-eenheid van de vice-president.

Naast het vertegenwoordigen van de organisatiestructuur kunnen organisatie-eenheden ook worden gebruikt om gebruikers en andere organisatie-eenheden te groeperen op basis van functionele criteria, zoals voor projecten of specialisatie. In het volgende diagram ziet u hoe organisatie-eenheden worden gebruikt om verkoopmedewerkers te groepeert op basis van klanttype:

In dit voorbeeld behoort elke verkoopmedewerker tot twee organisatie-eenheden: een die de plaats van de medewerker in de beheerstructuur van de organisatie vertegenwoordigt en een die het klantenbestand van de medewerker vertegenwoordigt (detailhandel of bedrijf). Aan elke organisatie-eenheid kunnen verschillende rollen worden toegewezen die op hun beurt verschillende machtigingen kunnen krijgen voor toegang tot de IT-resources van de organisatie. Daarnaast kunnen rollen worden overgenomen van bovenliggende organisatie-eenheden, waardoor het proces voor het doorgeven van rollen aan gebruikers wordt vereenvoudigd. Aan de andere kant kan worden voorkomen dat specifieke rollen worden overgenomen, zodat een specifieke rol alleen wordt gekoppeld aan de juiste organisatie-eenheden.

OrgUnits kunnen worden gemaakt in BHOLD Suite met behulp van de BHOLD Core-webportal.

Gebruikers

Zoals hierboven vermeld, moet elke gebruiker deel uitmaken van ten minste één organisatie-eenheid (OrgUnit). Omdat organisatie-eenheden het belangrijkste mechanisme zijn voor het koppelen van een gebruiker aan rollen, behoort een bepaalde gebruiker in de meeste organisaties tot meerdere OrgUnits om het gemakkelijker te maken om rollen aan die gebruiker te koppelen. In sommige gevallen kan het echter nodig zijn om een rol te koppelen aan een gebruiker, afgezien van orgunits waartoe de gebruiker behoort. Daarom kan een gebruiker rechtstreeks worden toegewezen aan een rol en rollen verkrijgen van de OrgUnits waartoe de gebruiker behoort.

Wanneer een gebruiker niet actief is binnen de organisatie (bijvoorbeeld voor medisch verlof), kan de gebruiker worden opgeschort, waardoor alle machtigingen van de gebruiker worden ingetrokken zonder de gebruiker uit het rolmodel te verwijderen. Wanneer de gebruiker weer in dienst is, kan deze opnieuw worden geactiveerd, waardoor alle machtigingen die door de rollen van de gebruiker zijn verleend, worden hersteld.

Objecten voor gebruikers kunnen afzonderlijk worden gemaakt in BHOLD via de BHOLD Core-webportal, of door de Access Management Connector met de FIM-synchronisatieservice te gebruiken om gebruikersgegevens te importeren uit bronnen zoals Active Directory Domain Services of HR-toepassingen.

Gebruikers kunnen rechtstreeks in BHOLD worden gemaakt zonder de FIM-synchronisatieservice te gebruiken. Dit kan handig zijn bij het modelleren van rollen in een preproductie- of testomgeving. U kunt ook toestaan dat externe gebruikers (zoals werknemers van een onderaannemer) rollen krijgen en zo toegang krijgen tot IT-resources zonder dat ze worden toegevoegd aan de werknemersdatabase; Deze gebruikers kunnen echter geen gebruik maken van de selfservicefuncties van BHOLD.

Rollen

Zoals eerder vermeld, worden machtigingen onder het model voor op rollen gebaseerd toegangsbeheer (RBAC) gekoppeld aan rollen in plaats van aan afzonderlijke gebruikers. Dit maakt het mogelijk om elke gebruiker de machtigingen te geven die nodig zijn om de taken van de gebruiker uit te voeren door de rollen van de gebruiker te wijzigen in plaats van de gebruikersmachtigingen afzonderlijk toe te kennen of te weigeren. Als gevolg hiervan vereist de toewijzing van machtigingen niet langer deelname van de IT-afdeling, maar kan in plaats daarvan worden uitgevoerd als onderdeel van het beheer van het bedrijf. Met een rol kunnen machtigingen worden samengevoegd voor toegang tot verschillende systemen, rechtstreeks of via het gebruik van subrollen, waardoor de noodzaak van IT-betrokkenheid bij het beheren van gebruikersmachtigingen verder wordt verminderd.

Het is belangrijk op te merken dat rollen een functie zijn van het RBAC-model zelf; meestal worden rollen niet ingericht voor doeltoepassingen. Hierdoor kan RBAC worden gebruikt naast bestaande toepassingen die niet zijn ontworpen om rollen te gebruiken of om de roldefinities te wijzigen, zodat wordt voldaan aan de behoeften van het wijzigen van bedrijfsmodellen zonder dat de toepassingen zelf moeten worden gewijzigd. Als een doeltoepassing is ontworpen om rollen te gebruiken, kunt u rollen in het BHOLD-rolmodel koppelen aan bijbehorende toepassingsrollen door de toepassingsspecifieke rollen als machtigingen te behandelen.

In BHOLD kunt u een rol toewijzen aan een gebruiker, voornamelijk via twee mechanismen:

• Door een rol toe te wijzen aan een organisatie-eenheid (organisatie-eenheid) waarvan de gebruiker lid is
• Door een rol rechtstreeks toe te wijzen aan een gebruiker

Een rol die is toegewezen aan een bovenliggende organisatie-eenheid kan optioneel worden overgenomen door de bijbehorende lid-organisatie-eenheden. Wanneer een rol wordt toegewezen aan of overgenomen door een organisatie-eenheid, kan deze worden aangewezen als een effectieve of voorgestelde rol. Als het een effectieve rol is, krijgen alle gebruikers in de organisatie-eenheid de rol toegewezen. Als het een voorgestelde rol is, moet deze worden geactiveerd voor elke gebruiker of lid organisatie-eenheid om van kracht te worden voor de leden van die gebruiker of organisatie-eenheid. Dit maakt het mogelijk om gebruikers een subset van de rollen toe te wijzen die zijn gekoppeld aan een organisatie-eenheid, in plaats van automatisch alle rollen van de organisatie-eenheid toe te wijzen aan alle leden. Daarnaast kunnen rollen begin- en einddatums krijgen en kunnen limieten worden gesteld aan het percentage gebruikers binnen een organisatie-eenheid waarvoor een rol effectief kan zijn.

In het volgende diagram ziet u hoe aan een afzonderlijke gebruiker een rol kan worden toegewezen in BHOLD:

In dit diagram wordt rol A toegewezen aan een organisatie-eenheid als een over te nemen rol en dus overgenomen door de lid organisatie-eenheden en alle gebruikers binnen die organisatie-eenheden. Rol B wordt toegewezen als een voorgestelde rol voor een organisatie-eenheid. Deze moet worden geactiveerd voordat een gebruiker in de organisatie-eenheid kan worden geautoriseerd met de machtigingen van de rol. Rol C is een effectieve rol, zodat de machtigingen onmiddellijk van toepassing zijn op alle gebruikers in de organisatie-eenheid. Rol D is rechtstreeks gekoppeld aan de gebruiker en de machtigingen zijn dus onmiddellijk van toepassing op die gebruiker.

Bovendien kan een rol worden geactiveerd voor een gebruiker op basis van de kenmerken van een gebruiker. Zie Autorisatie op basis van kenmerken voor meer informatie.

Machtigingen

Een machtiging in BHOLD komt overeen met een autorisatie die is geïmporteerd uit een doeltoepassing. Dat wil dus, wanneer BHOLD is geconfigureerd om te werken met een toepassing, ontvangt deze een lijst met autorisaties die BHOLD aan rollen kan koppelen. Wanneer bijvoorbeeld Active Directory Domain Services (AD DS) als een toepassing wordt toegevoegd aan BHOLD, ontvangt deze een lijst met beveiligingsgroepen die als BHOLD-machtigingen kunnen worden gekoppeld aan rollen in BHOLD.

Machtigingen zijn specifiek voor toepassingen. BHOLD biedt één uniforme weergave van machtigingen, zodat machtigingen kunnen worden gekoppeld aan rollen zonder dat rolbeheerders de implementatiedetails van de machtigingen hoeven te begrijpen. In de praktijk kunnen verschillende systemen een machtiging op verschillende manieren afdwingen. De toepassingsspecifieke connector van de FIM-synchronisatieservice naar de toepassing bepaalt hoe machtigingswijzigingen voor een gebruiker aan die toepassing worden verstrekt.

Toepassingen

BHOLD implementeert een methode voor het toepassen van op rollen gebaseerd toegangsbeheer (RBAC) op externe toepassingen. Dat wil dus, wanneer BHOLD is ingericht met gebruikers en machtigingen van een toepassing, kan BHOLD deze machtigingen koppelen aan gebruikers door rollen toe te wijzen aan de gebruikers en vervolgens de machtigingen aan de rollen te koppelen. Het achtergrondproces van de toepassing kan vervolgens de juiste machtigingen toewijzen aan de gebruikers op basis van de rol-/machtigingstoewijzing in BHOLD.

Het BHOLD Suite-rolmodel ontwikkelen

Om u te helpen bij het ontwikkelen van uw rolmodel, biedt BHOLD Suite modelgenerator, een hulpprogramma dat zowel eenvoudig te gebruiken als uitgebreid is.

Voordat u Modelgenerator gebruikt, moet u een reeks bestanden maken die de objecten definiëren die modelgenerator gebruikt om het rolmodel te maken. Zie Microsoft BHOLD Suite Technical Reference (Technische naslaginformatie over Microsoft BHOLD Suite) voor meer informatie over het maken van deze bestanden.

De eerste stap bij het gebruik van de BHOLD-modelgenerator is het importeren van deze bestanden om de basisbouwstenen in ModelGenerator te laden. Wanneer de bestanden zijn geladen, kunt u vervolgens criteria opgeven die modelgenerator gebruikt om verschillende klassen van rollen te maken:

• Lidmaatschapsrollen die zijn toegewezen aan een gebruiker op basis van de OrgUnits (organisatie-eenheden) waartoe de gebruiker behoort
• Kenmerkrollen die zijn toegewezen aan een gebruiker op basis van de kenmerken van de gebruiker in de BHOLD-database
• Voorgestelde rollen die zijn gekoppeld aan een organisatie-eenheid, maar moeten worden geactiveerd voor specifieke gebruikers
• Eigendomsrollen die een gebruiker controle verlenen over organisatie-eenheden en rollen waarvoor geen eigenaar is opgegeven in de geïmporteerde bestanden

Belangrijk

Schakel bij het uploaden van bestanden het selectievakje Bestaand model behouden alleen in testomgevingen in. In productieomgevingen moet u Modelgenerator gebruiken om het eerste rolmodel te maken. U kunt deze niet gebruiken om een bestaand rolmodel in de BHOLD-database te wijzigen.

Nadat Modelgenerator deze rollen in het rolmodel heeft gemaakt, kunt u het rolmodel vervolgens exporteren naar de BHOLD-database in de vorm van een XML-bestand.

Geavanceerde BHOLD-functies

In eerdere secties werden de basisfuncties van op rollen gebaseerd toegangsbeheer (RBAC) in BHOLD beschreven. In deze sectie vindt u een overzicht van aanvullende functies in BHOLD die de implementatie van RBAC van uw organisatie kunnen verbeteren. Deze sectie bevat een overzicht van de volgende BHOLD-functies:

• Kardinaliteit
• Scheiding van taken
• Machtigingen die kunnen worden aangepast aan de context
• Autorisatie op basis van kenmerken
• Flexibele kenmerktypen

Kardinaliteit

Kardinaliteit verwijst naar de implementatie van bedrijfsregels die zijn ontworpen om het aantal keren te beperken dat twee entiteiten aan elkaar kunnen worden gerelateerd. In het geval van BHOLD kunnen kardinaliteitsregels worden ingesteld voor rollen, machtigingen en gebruikers.

U kunt een rol configureren om het volgende te beperken:

• Het maximum aantal gebruikers waarvoor een voorgestelde rol kan worden geactiveerd
• Het maximum aantal subrollen dat aan de rol kan worden gekoppeld
• Het maximum aantal machtigingen dat aan de rol kan worden gekoppeld

U kunt een machtiging configureren om het volgende te beperken:

• Het maximum aantal rollen dat aan de machtiging kan worden gekoppeld
• Het maximum aantal gebruikers dat de machtiging kan krijgen

U kunt een gebruiker configureren om het volgende te beperken:

• Het maximum aantal rollen dat aan de gebruiker kan worden gekoppeld
• Het maximum aantal machtigingen dat aan de gebruiker kan worden toegewezen via roltoewijzingen

Scheiding van taken

Scheiding van taken (SoD) is een zakelijk principe dat probeert te voorkomen dat personen de mogelijkheid krijgen om acties uit te voeren die niet beschikbaar mogen zijn voor één persoon. Een werknemer mag bijvoorbeeld geen betaling kunnen aanvragen en de betaling autoriseren. Het principe van SoD stelt organisaties in staat om een systeem van controles en saldi te implementeren om hun blootstelling aan risico's door fouten of wangedrag van werknemers te minimaliseren.

BHOLD implementeert SoD door u incompatibele machtigingen te laten definiëren. Wanneer deze machtigingen zijn gedefinieerd, dwingt BHOLD SoD af door te voorkomen dat rollen worden gemaakt die zijn gekoppeld aan incompatibele machtigingen, ongeacht of deze rechtstreeks of via overname zijn gekoppeld, en door te voorkomen dat gebruikers meerdere rollen krijgen toegewezen die, indien gecombineerd, incompatibele machtigingen zouden verlenen, opnieuw door directe toewijzing of overname. Conflicten kunnen eventueel worden overschreven.

Machtigingen die kunnen worden aangepast aan de context

Door machtigingen te maken die automatisch kunnen worden gewijzigd op basis van een objectkenmerk, kunt u het totale aantal machtigingen verminderen dat u moet beheren. Met context-aanpasbare machtigingen (CAPs) kunt u een formule definiëren als een machtigingskenmerk waarmee wordt gewijzigd hoe de machtiging wordt toegepast door de toepassing die aan de machtiging is gekoppeld. U kunt bijvoorbeeld een formule maken waarmee de toegangsmachtiging voor een bestandsmap wordt gewijzigd (via een beveiligingsgroep die is gekoppeld aan de toegangsbeheerlijst van de map) op basis van het feit of een gebruiker deel uitmaakt van een organisatie-eenheid (organisatie-eenheid) die fulltime of contractmedewerkers bevat. Als de gebruiker van de ene organisatie-eenheid naar een andere wordt verplaatst, wordt de nieuwe machtiging automatisch toegepast en wordt de oude machtiging gedeactiveerd.

Met de CAP-formule kunt u een query uitvoeren op de waarden van kenmerken die zijn toegepast op toepassingen, machtigingen, organisatie-eenheden en gebruikers.

Autorisatie op basis van kenmerken

Een manier om te bepalen of een rol die is gekoppeld aan een organisatie-eenheid (organisatie-eenheid) wordt geactiveerd voor een bepaalde gebruiker in de organisatie-eenheid, is het gebruik van op kenmerken gebaseerde autorisatie (ABA). Met ABA kunt u een rol alleen automatisch activeren wanneer aan bepaalde regels op basis van de kenmerken van een gebruiker wordt voldaan. U kunt bijvoorbeeld een rol koppelen aan een organisatie-eenheid die alleen actief wordt voor een gebruiker als de functie van de gebruiker overeenkomt met de functie in de ABA-regel. Dit elimineert de noodzaak om handmatig een voorgestelde rol voor een gebruiker te activeren. In plaats daarvan kan een rol worden geactiveerd voor alle gebruikers in een organisatie-eenheid die een kenmerkwaarde hebben die voldoet aan de ABA-regel van de rol. Regels kunnen worden gecombineerd, zodat een rol alleen wordt geactiveerd wanneer de kenmerken van een gebruiker voldoen aan alle ABA-regels die voor de rol zijn opgegeven.

Het is belangrijk te weten dat de resultaten van ABA-regeltests worden beperkt door kardinaliteitsinstellingen. Als de kardinaliteitsinstelling van een regel bijvoorbeeld aangeeft dat niet meer dan twee gebruikers een rol kunnen krijgen toegewezen en als een ABA-regel anders een rol voor vier gebruikers activeert, wordt de rol alleen geactiveerd voor de eerste twee gebruikers die slagen voor de ABA-test.

Flexibele kenmerktypen

Het systeem van kenmerken in BHOLD is zeer uitbreidbaar. U kunt nieuwe kenmerktypen definiëren voor objecten zoals gebruikers, organisatie-eenheden (organisatie-eenheden) en rollen. Kenmerken kunnen worden gedefinieerd om waarden te hebben die gehele getallen, Booleaanse waarden (ja/nee), alfanumeriek, datum, tijd en e-mailadressen zijn. Kenmerken kunnen worden opgegeven als enkele waarden of een lijst met waarden.

Attestation

De BHOLD Suite biedt hulpprogramma's die u kunt gebruiken om te controleren of individuele gebruikers de juiste machtigingen hebben gekregen om hun zakelijke taken uit te voeren. De beheerder kan de portal van de BHOLD Attestation-module gebruiken om het attestation-proces te ontwerpen en te beheren.

Het attestation-proces wordt uitgevoerd door middel van campagnes waarin campagnestewards de mogelijkheid en middelen krijgen om te controleren of de gebruikers waarvoor ze verantwoordelijk zijn, de juiste toegang hebben tot door BHOLD beheerde toepassingen en juiste machtigingen binnen die toepassingen hebben. Een campagne-eigenaar wordt aangewezen om toezicht te houden op de campagne en ervoor te zorgen dat de campagne correct wordt uitgevoerd. Een campagne kan eenmaal of op terugkerende basis worden gemaakt.

Normaal gesproken is de beheerder van een campagne een manager die de toegangsrechten bevestigt van gebruikers die behoren tot een of meer organisatie-eenheden waarvoor de manager verantwoordelijk is. Stewards kunnen automatisch worden geselecteerd voor de gebruikers die worden getest in een campagne op basis van gebruikerskenmerken, of de stewards voor een campagne kunnen worden gedefinieerd door ze op te geven in een bestand waarin elke gebruiker die in de campagne wordt getest, wordt toegewezen aan een steward.

Wanneer een campagne begint, stuurt BHOLD een e-mailmelding naar de campagnestewards en -eigenaar en stuurt ze vervolgens periodieke herinneringen om hen te helpen de voortgang van de campagne te behouden. Stewards worden omgeleid naar een campagneportal, waar ze een lijst kunnen zien van de gebruikers waarvoor ze verantwoordelijk zijn en de rollen die aan deze gebruikers zijn toegewezen. De stewards kunnen vervolgens bevestigen of ze verantwoordelijk zijn voor elk van de vermelde gebruikers en de toegangsrechten van elk van de vermelde gebruikers goedkeuren of weigeren.

Campagne-eigenaren gebruiken de portal ook om de voortgang van de campagne te controleren en campagneactiviteiten worden geregistreerd, zodat campagne-eigenaren de acties kunnen analyseren die in de loop van de campagne zijn uitgevoerd.

Rapporten

De BHOLD-rapportagemodule biedt u de mogelijkheid om informatie in het rolmodel te bekijken via verschillende rapporten. De BHOLD-rapportagemodule biedt een uitgebreide set ingebouwde rapporten, plus een wizard die u kunt gebruiken om zowel eenvoudige als geavanceerde aangepaste rapporten te maken. Wanneer u een rapport uitvoert, kunt u de resultaten onmiddellijk weergeven of de resultaten opslaan in een Microsoft Excel-bestand (.xlsx). Als u dit bestand wilt weergeven met Microsoft Excel 2000, Microsoft Excel 2002 of Microsoft Excel 2003, kunt u het Microsoft Office-compatibiliteitspakket voor Word-, Excel- en PowerPoint-bestandsindelingen downloaden en installeren.

U gebruikt de module BHOLD-rapportage voornamelijk om rapporten te maken die zijn gebaseerd op de huidige rolgegevens. Forefront Identity Manager 2010 R2 heeft een rapportagemogelijkheid voor de FIM-service die is geïmplementeerd in de System Center Service Manager Data Warehouse om rapporten te genereren voor het controleren van identiteitswijzigingen. Zie de documentatie forefront Identity Manager 2010 en Forefront Identity Manager 2010 R2 in de technische bibliotheek voor Forefront Identity Management voor meer informatie over FIM-rapportage.

De volgende categorieën worden behandeld in de ingebouwde rapporten:

• Beheer
• Attestation
• Besturingselementen
• Naar binnen Access Control
• Logboekregistratie
• Model
• Statistieken
• Werkstroom

U kunt rapporten maken en toevoegen aan deze categorieën, of u kunt uw eigen categorieën definiëren waarin u aangepaste en ingebouwde rapporten kunt plaatsen.

Wanneer u een rapport bouwt, wordt u stapsgewijs begeleid bij het opgeven van de volgende parameters:

• Identificerende informatie, waaronder naam, beschrijving, categorie, gebruik en doelgroep
• Velden die moeten worden weergegeven in het rapport
• Query's die aangeven welke items moeten worden geanalyseerd
• Volgorde waarin rijen moeten worden gesorteerd
• Velden die worden gebruikt om het rapport op te splitsen in secties
• Filters om de elementen te verfijnen die in het rapport worden geretourneerd

In elke fase van de wizard kunt u een voorbeeld van het rapport bekijken zoals u het tot nu toe hebt gedefinieerd en opslaan als u geen extra parameters hoeft op te geven. U kunt ook teruggaan naar de vorige stappen om parameters te wijzigen die u eerder in de wizard hebt opgegeven.

Connector voor toegangsbeheer

De module BHOLD Suite Access Management Connector ondersteunt zowel initiële als doorlopende synchronisatie van gegevens in BHOLD. De Access Management Connector werkt met de FIM-synchronisatieservice om gegevens te verplaatsen tussen de BHOLD Core-database, de MIM-metaverse en doeltoepassingen en identiteitsarchieven.

In eerdere versies van BHOLD waren meerdere CA's vereist om de gegevensstroom tussen MIM- en tussenliggende BHOLD-databasetabellen te beheren. In BHOLD Suite SP1 kunt u met de Access Management Connector beheeragents (MA's) in MIM definiëren die rechtstreeks gegevensoverdracht tussen BHOLD en MIM mogelijk maken.

Volgende stappen

• Installatiehandleiding voor BHOLD
• BHOLD-referentie voor ontwikkelaars
• Versiegeschiedenis van BHOLD