Identity governance vormt een belangrijke basis binnen een gelaagde securitystrategie. Voor interne gebruikers hebben de meeste moderne organisaties dit vandaag goed onder controle. Voor hun externe populatie is dat echter veel minder vaak het geval.
Denk aan leveranciers, contractors en gebruikers aan de zijde van partners die een zekere mate van selfservice nodig hebben om efficiënt te kunnen werken. Tegelijk moeten er duidelijke beperkingen zijn die ervoor zorgen dat zij nooit toegang krijgen tot informatie of functionaliteiten die uitsluitend voor interne gebruikers bestemd zijn.
In dit artikel bekijken we hoe we deze uitdaging hebben aangepakt bij een overheidsinstantie met ongeveer 1.700 gebruikers. Met behulp van midPoint realiseerden we een oplossing die deze lacune opvulde zonder een tweede product toe te voegen aan het bestaande identity-landschap van de organisatie.
Een leveranciersportaal buiten de governance perimeter
MidPoint vormde al de ruggengraat van de interne IGA-processen van onze klant. Toegangsaanvragen, goedkeuringen, provisioning en alle gebruikelijke governanceprocessen verliepen al via het platform.
Voor leveranciers gebruikte de organisatie echter een afzonderlijk, standalone leveranciersportaal dat los van midPoint werd aangekocht en beheerd. Het deed wat het moest doen: managers aan leverancierszijde konden er toegangsaanvragen indienen en de toegang van hun eigen medewerkers beheren.
Het probleem was dat deze oplossing buiten de governanceperimeter viel die de organisatie ondertussen had opgebouwd. Dat betekende twee platformen om te licentiëren, te onderhouden, te patchen en te integreren. Daarnaast waren er ook twee omgevingen die moesten worden toegelicht tijdens audits. En vooral: er waren twee plaatsen waar moest worden bepaald wie waarvoor toegang kreeg.
Vanuit de wens om de operationele efficiëntie te verhogen stelde de klant ons een logische vraag: “Kan midPoint dit niet ook afdekken?”
De organisatie wilde het beheer van leveranciers onderbrengen in het platform dat zich intern al had bewezen. Zo konden twee parallelle governance-modellen worden vervangen door één centrale aanpak voor het beheer van identiteiten en toegangsrechten.
Dezelfde structuur, aparte dimensies
Met een stevige basis in midPoint kozen we voor de meest logische aanpak: het bestaande platform verder uitbreiden. De bestaande tree die interne afdelingen, businessunits en rapporteringslijnen modelleerde, bleef daarbij volledig ongewijzigd.
Daarnaast introduceerden we een afzonderlijke, parallelle tree voor leveranciers. In dit model krijgt elke leverancier zijn eigen branch.
Net in die scheiding schuilt de kracht van de oplossing. Ze maakt het mogelijk om per tree te bepalen wat wel en niet is toegestaan. De interne tree behield het volledige governancemodel dat de klant al gebruikte, terwijl de supplier tree werd voorzien van een eigen, bewust beperkter pakket aan regels en mogelijkheden.
Een manager aan leverancierszijde bevindt zich bovenaan zijn of haar eigen branch. Binnen die context beschikt die persoon over vergelijkbare beheermogelijkheden als een interne manager. Het verschil zit in de reikwijdte van die bevoegdheden. Een supplier manager kan nooit acties uitvoeren buiten zijn of haar eigen branch.
Dankzij deze parallelle trees kunnen dezelfde beleidsregels, processen en governanceprincipes worden hergebruikt, terwijl interne en externe organisaties duidelijk van elkaar gescheiden blijven. Dat zorgt voor meer gebruiksgemak, eenvoudiger beheer en een sterker governancekader.
Hoe midPoint’s standaardfunctionaliteiten een efficiënte uitbreiding mogelijk maakten.
-
- Multi-tree organisatiestructuur
Interne gebruikers en leveranciers worden ondergebracht in afzonderlijke branches binnen de standaard organisatiestructuur van midPoint. Ze bestaan naast elkaar binnen dezelfde omgeving, zonder dat er aparte systemen nodig zijn. - Gedelegeerd beheer
Het concept van ‘managers’ wordt hergebruikt, waarbij hun administratieve bevoegdheden gekoppeld zijn aan de organisatienodes waarvoor ze verantwoordelijk zijn. Externe leveranciersmanagers zijn beperkt tot hun eigen branch binnen de tree. Hierdoor kunnen zij gebruikers aanmaken, raadplegen, wijzigen en verwijderen binnen hun eigen organisatorische scope. - Gecureerde aanvraagcatalogi
Leveranciersgebruikers krijgen nooit interne rollen te zien in hun aanvraagprocessen. Enkel de rollen die expliciet voor het leveranciersportaal beschikbaar zijn gemaakt, worden getoond. Deze rollen worden niet verborgen achter extra permissiecontroles; ze bestaan eenvoudigweg niet binnen de externe tree. - Gescheiden autorisatiebeleid
Hetzelfde principe geldt voor zichtbaarheid en beheerrechten. Leveranciers hebben uitsluitend inzicht in gebruikers, organisatienodes en aanvragen binnen hun eigen subtree.
- Multi-tree organisatiestructuur
Dankzij deze aanpak kon de klant het standalone leveranciersportaal uitfaseren, waardoor afzonderlijke licentie- en onderhoudskosten verdwenen. Door deze consolidatie functioneren beide trees vandaag binnen één gedeeld platform.Toegangsgovernance, beleidsregels en audittrails worden nu centraal beheerd en geregistreerd in één systeem.
Daarnaast zorgt de verhoogde zichtbaarheid voor een duidelijkere afbakening van wat leveranciers wel en niet mogen beheren. De organisatie kan de scope van leveranciers nauwkeurig definiëren en afdwingen. En omdat die scope helder is vastgelegd, profiteren leveranciers eveneens van de voordelen: leveranciersmanagers krijgen echte selfservice-mogelijkheden, zonder dat daarvoor hetzelfde vertrouwensniveau nodig is als bij interne managers.
Belangrijkste inzichten
De grootste uitdaging zat in het correct definiëren van de scope. Dat is meteen ook de belangrijkste les die we met andere implementatoren willen delen. Het kan verleidelijk zijn om het bestaande model voor interne managers simpelweg te hergebruiken voor leveranciers.
Op conceptueel niveau klinkt dat logisch: een manager is tenslotte een manager. Toch is het cruciaal om goed na te denken over welke rechten en rollen beschikbaar mogen zijn voor externe gebruikers.
In de praktijk heeft een leveranciersmanager inderdaad een deel van dezelfde bevoegdheden nodig als een interne manager: aanvragen goedkeuren, eigen gebruikers beheren, rollen toewijzen, enzovoort. Maar altijd binnen duidelijk afgebakende grenzen.
- Leveranciersmanagers kunnen uitsluitend rollen aanvragen die expliciet beschikbaar zijn gemaakt voor het leveranciersportaal. De interne rollencatalogus is niet alleen afgeschermd, maar volledig onzichtbaar.
- De organisatorische zichtbaarheid werd beperkt tot de eigen branch van de leverancier. In tegenstelling tot interne managers kunnen zij niet door de bredere tree navigeren.
- Het model voor gedelegeerd beheer moet worden afgebakend per organisatorische branch. Een globale definitie van het begrip “manager” biedt onvoldoende garanties voor een correcte scope-afbakening.
Het grootste deel van de ontwerpinspanning ging naar het correct definiëren van deze grenzen. Daarom raden we andere implementatoren sterk aan om hierover vroeg in het traject na te denken, en niet pas tijdens de afwerkingsfase.
Zodra deze uitdaging was aangepakt, lag de weg open naar een efficiënt en gebruiksvriendelijk selfserviceportaal voor leveranciers. We konden onze klant een uitbreiding van hun bestaande platform bieden, in plaats van een extra oplossing die opnieuw geïntegreerd en beheerd moest worden. Het resultaat sluit naadloos aan op de bestaande infrastructuur en governance-aanpak van de organisatie.
