Invullen van het integratiedossier / safe design
Wanneer er een intakegesprek heeft plaatsgevonden, stuurt de integrator het integratiedossier, ook gekend als het safe design, door naar de klant. Tijdens het intakegesprek overlopen de integrator en de klant dit dossier samen, zodat de klant hier daarna zelfstandig mee aan de slag kan gaan.
Het is de bedoeling dat de klant de kolommen onder “Safe design”, “Toegangsbeleid design”, “Geprivilegieerd accounts informatie” en “To be onboarded” invult. De andere kolommen worden automatisch aangevuld waar nodig. Wanneer het dossier ingevuld is, stuurt de klant dit door naar de integrator die het laat valideren bij het technische team. Indien nodig wordt er feedback gegeven aan de klant. Wanneer dit dossier in orde is kan er een werkaanvraag worden ingevuld met de vermelding van het totaal aantal te onboarden accounts en het referentienummer (PAMINT-XXX). Nadat de werkaanvraag besteld is, kan de onboarding ingepland worden.
Afhankelijk van welke technologie de klant gebruikt, wordt er in één of meerdere tabbladen van het integratiedossier gewerkt.
Hieronder vindt u de inhoudsopgave van alle te doorlopen stappen.
1. Safe design of account safe
Beschrijving
Het safe design gaat over de safe die aangemaakt zal worden. De beschrijving van wat safes zijn, is hier terug te vinden.
Bij PAM wordt er op safe niveau gewerkt. Dit betekent dat, wanneer je toegang hebt tot een safe, je toegang hebt tot alle accounts die in die safe zijn opgeslagen.
Al de aspecten van het safe design vormen tezamen een safe. Bijgevolg heb je een compleet andere safe wanneer je één van deze aspecten aanpast.
Naamconventie: safe name
[Verantwoordelijke]-[OVO-code]-[Team of Applicatie ID]-[Type safe]-[Locatie]
Beschrijving van de naamconventie
Parameter | Beschrijving | Mogelijke waardes | Waarde beschrijving |
---|---|---|---|
Verantwoordelijke | Deze parameter beschrijft de partij die gebruik zal maken van de geonboardde accounts op PAM. Het beschrijft dus
Enkel de applicatie-eigenaar kan bepalen wie een gedelegeerde partij is. |
| Owner (O): Applicatie-eigenaars hebben toegang tot de accounts in de safe en regelen het gebruikersbeheer. Delegated (D): Een gedelegeerde partij heeft toegang tot de accounts in de safe en regelt het gebruikersbeheer. Als jij als applicatie-eigenaar de accounts zelf gebruikt, zijn het owned accounts. Als jij als applicatie-eigenaar de geprivilegieerde accounts niet zelf gebruikt, maar het gebruik ervan bij een andere organisatie ligt, zijn het delegated accounts. |
De OVO-code beschrijft aan welke organisatie, entiteit of klant de aangemaakte safe gelinkt wordt. Indien er verder in het integratiedossier geen OVO-codes vermeld worden bij “Safe Toegang”, is het deze organisatie die de controle over de safe heeft. Bijgevolg bepaalt deze organisatie de gebruikers die toegang hebben tot de accounts in de safe (IDM). Deze partij kan enkel geïdentificeerd worden door een OVO-code. | Alle waarden die aanwezig zijn binnen de VO CMDB | Beschrijving van de OVO-codes kan geraadpleegd worden in de VO CMDB.
U kan uw Organisatie code, kortweg OVO-code, opzoeken via Wegwijs. | |
Team/Applicatie ID | Deze parameter beschrijft tot welk team of welke applicatie de accounts behoren. De applicatie kan enkel geïdentificeerd worden door het toepassingsnummer in CMDB. Dit is de geprefereerde waarde voor deze kolom. Indien de applicatie niet over een toepassingsnummer beschikt, kan men hier een Team ID specifiëren. Een Team ID beschrijft tot welk team de accounts behoren. Deze waarde kan vrij gekozen worden door de aanvrager. | Alle waarden die aanwezig zijn binnen de VO CMDB / Vrije waarde, beperkt tot 5 karakters | Beschrijving van de Applicatie ID's kan geraadpleegd worden in de VO CMDB. / De aanvrager moet een logische verklaring meedelen voor de teams om de verschillen duidelijk aan te geven. Dit moet eveneens een unieke en specifieke waarde zijn. Deze waarde wordt het best in hoofdletters uitgedrukt. |
Type safe | Het type van de safe beschrijft de oorsprong en de aard van de accounts. Enkel de applicatie eigenaar kan deze parameter bepalen.
|
| Administrator account (ADM): Ingebouwde administrator accounts binnen een applicatie. Dit zijn de hoogste geprivilegieerde accounts. Test account (TNI): Geprivilegieerde accounts in uw Test Omgeving. Operationeel account (OPS):
Non Privileged Accounts (NPA): Aangemaakte accounts die enkel leesrechten hebben op de applicatie. |
Safe design voor een reconcile account
Een beslissing is genomen om alle reconcile accounts te centraliseren in twee reconcile safes in plaats van aparte safes te maken voor ieder reconcile account. De redenering is hier dat het PAM-team deze accounts beheerd als onderdeel van de PAM service en deze accounts opgeslagen worden in de safe van Digitaal Vlaanderen. Bijgevolg zou het PAM-team de enige partij mogen zijn die hier toegang tot heeft.
De naamconventie heeft een vast formaat waarbij een opdeling wordt gemaakt tussen Owner en Delegated safes:
De Owner Safe wordt enkel gebruikt voor reconcile accounts die activiteiten uitvoeren op applicaties die tot Digitaal Vlaanderen behoren.
Verantwoordelijke: O
OVO-code: OVO002949
Team/Application ID: 81039
Safe Type: OPS
De Delegated Safe wordt enkel gebruikt voor reconcile accounts die gedelegeerd worden naar Digitaal Vlaanderen door klanten van PAMaaS om activiteiten uit te voeren op hun applicaties.
Verantwoordelijke: D
OVO-code: OVO002949
Team/Application ID: 81039
Safe Type: OPS
Safe design voorbeeld
D-048644-20109-OPS-CE
D: Accounts in deze safe worden gedelegeerd door de eigenaar naar een andere partij.
048644: De partij die verantwoordelijk is voor de accounts wordt geïdentificeerd door de OVO-code 048644.
20109: De accounts zijn actief binnen de applicatie met Applicatie ID 20109.
OPS: De accounts zijn aangemaakt voor operationeel gebruik.
CE: De accounts worden beheerd door de "CE" CPM. Dit is vooral belangrijk voor ons technisch team en is een vaste waarde.
2. Toegangsbeleid design
Beschrijving
Het toegangsbeleid gaat over hoe de accounts in de safe beheert en gebruikt kunnen worden. Als gebruiker van PAMaaS is het belangrijk om te bepalen hoe strikt het toegangsbeleid dient te zijn. Als afnemer van PAMaaS is het belangrijk om te bepalen hoe strikt het toegangsbeleid dient te zijn.
Naamconventie: platform name
[Technologie]-[Toegangsbeleid]-[Type account]-[Locatie]-[Gegevensbeheer]-[Sessiebeheer]
Beschrijving van de naamconventie
Parameter | Beschrijving | Mogelijke waardes | Waarde beschrijving |
---|---|---|---|
Technologie | Deze parameter beschrijft welke technologie de accounts gebruiken om toegang te verkrijgen tot de applicatie. Afhankelijk van welke technologie er gebruikt wordt, zal men in een andere tab van het integratiedossier te werk gaan. |
| AD: Windows domein accounts gedefinieerd in een Active Directory WIN: Lokale Windows accounts gedefinieerd op Windows systemen UX: Lokale Linux accounts met wachtwoord AWS: AWS console of CLI accounts met access keys AZR: Azure console accounts |
Het toegangsbeleid bepaalt in welke mate toegangscontrole van kracht is en hoe de toegang opgevolgd wordt. Dit kan beslist worden op basis van de informatieclassificatie waarbinnen de applicatie zich bevindt. Enkel de applicatie-eigenaar kan bepalen tot welk toegangsbeleid de accounts behoren. |
| Access Only (AO): Deze accounts hebben geen restrictief toegangsbeleid. Er dient enkel een reden van toegang ingevuld te worden. Motivated Access (MA): Deze accounts hebben een toegangsbeleid met volgende maatregelen:
Secure Access (SA): Deze accounts hebben een zeer restrictief toegangsbeleid met volgende maatregelen:
| |
Type account | Het type account beschrijft welk soort account er geonboard dient te worden. Er kan gebruik gemaakt worden van de linked account functionaliteit die het beheer van de eigenlijke accounts mogelijk maakt. |
| Normaal account (N): Dit is een normaal geprivilegieerd account dat gebruikt kan worden door gebruikers. Logon account (L): Een logon account wordt voornamelijk gebruikt binnen AWS/Linux omgevingen waar een gebruiker niet rechtstreeks als root kan inloggen (dit zou niet mogelijk mogen zijn). Een logon account wordt ingeschakeld om een super user verheffing uit te voeren om zo de nodige root user permissies te verkrijgen. Reconcile account (R): Dit is een reconciliatie account dat dient voor het wachtwoordbeheer en -rotatie van de andere normale accounts. Informatie over reconcile accounts is hier terug te vinden. Eén reconcile account per domein volstaat. |
Gegevensbeheer | Het gegevensbeheer geeft weer hoe inloggegevens beheerd worden aan de hand van een beleid (bv. automatische rotatie, etc.). De applicatie-eigenaar beslist hoe inloggegevens van een account beheerd moeten worden. |
| Automatic Change Reconcile (ACR): De inloggegevens van de acounts worden automatisch geverifieerd en geroteerd. Er wordt gebruik gemaakt van een reconcile account dat wachtwoorden gaat roteren in de applicatie en in de vault bij niet-overeenkomstige inloggegevens. Automatic Change (AC): De inloggegevens van de acounts worden automatisch geverifieerd en aangepast. |
3. Geprivilegieerd account informatie
Beschrijving
Een account is binnen PAMaaS een geprivilegieerd account dat gebruikt wordt om toegang te verlenen tot een systeem of applicatie.
Richtlijnen om geprivilegieerde accounts aan te maken zijn hier terug te vinden.
3.1 Windows domain
Parameter | Beschrijving | Voorbeeld |
---|---|---|
Username | Gebruiksvriendelijke naam van het Windows domein account. | DomainAdmin |
Address (FQDN) | Fully Qualified Domain Name (FQDN) van het Windows domain. | |
UserDN | Naam van het domain object. | windowsdomeinnaam\DomainAdmin |
Permitted Remote Machines | Lijst met servers waartoe het account toegang heeft. | server 1 ; server 2 ; server 3 ; … |
Comments | Optionele beschrijving. | Voorbeeld Domain account |
Use reconcile (Account ID) | Verwijst naar het account (in het integratiedossier) dat als reconcile account gebruikt wordt voor de wachtwoordrotatie van het desbetreffend domeinaccount. | AD-0 |
3.2 Windows local
Parameter | Beschrijving | Voorbeeld |
---|---|---|
Username | Gebruiksvriendelijke naam van het Windows local account. | Administrator |
Address (FQDN) | Fully Qualified Domain Name (FQDN) van de Windows server. | |
Comments | Optionele beschrijving. | Voorbeeld local account |
Use reconcile (Account ID) | Verwijst naar het account (in het integratiedossier) dat als reconcile account gebruikt wordt voor de wachtwoordrotatie van het desbetreffend domeinaccount. | WIN-0 |
3.3 Linux
Parameter | Beschrijving | Voorbeeld |
---|---|---|
Username | Gebruiksvriendelijke naam van het Linux account. | Root |
Address (FQDN) | Fully Qualified Domain Name (FQDN) van de Linux server. | |
Comments | Optionele beschrijving. | Voorbeeld Domain account |
Use logon (Account ID) | Verwijst naar het account (in het integratiedossier) dat als logon account gebruikt wordt. Er wordt ofwel gebruik gemaakt van een logon account ofwel van een reconcile account. | UX-0 |
Use reconcile (Account ID) | Verwijst naar het account (in het integratiedossier) dat als reconcile account gebruikt wordt. Er wordt ofwel gebruik gemaakt van een logon account ofwel van een reconcile account. | UX-1 |
3.4 AWS
Parameter | Beschrijving | Voorbeeld |
---|---|---|
Username | Gebruiksvriendelijke naam van het AWS account. | Administrator |
AWS Access Key ID | Een uniek identificatienummer van de AWS Access Key dat gebruikt wordt door APIs tot de AWS console. | AKIAJIPU0000L5LB7OIB |
AWS Address | De account-specifieke URL die gebruikt wordt door IAM users om aan te melden. | |
AWS ARN Role | De gebruiker die veilige toegang heeft tot de AWS Console. | arn:aws:iam::123456789012:user/division_abc/subdivision_xyz/JaneDoe |
Comments | Optionele beschrijving. | Voorbeeld Administrator account |
Use logon | Verwijst naar het account (in het integratiedossier) dat als logon account gebruikt wordt. | AWS-0 |
3.5 Azure
Parameter | Beschrijving | Voorbeeld |
---|---|---|
Username | Gebruiksvriendelijke naam van het Azure account. Deze naam wordt gebruikt om het account aan te maken en wordt gelinkt aan de nodige subscriptie(s). | GlobalAdmin |
User Principal Name | Deze naam vindt u terug bij inloggen op het Azure portaal. | |
Object ID | Wanneer er gebruik gemaakt wordt van de VO tenant dient dit veld niet ingevuld te worden door de klant. De object ID wordt door het PAM-team aangemaakt bij het creëren van de accounts. Wanneer er gebruik gemaakt wordt van een eigen tenant dient die veld wel ingevuld te worden door de klant. | xcxd001-00x0-0x01-0xxx-x0x0x01xx100 |
Subscription User Friendly Name | Gebruiksvriendelijke naam van uw subscriptie. | Subscriptie PRD |
Subscription Technical Name | Technische naam van uw subscriptie. | xcxd001-00x0-0x01-0xxx-x0x0x01xx100 |
Comments | Optionele beschrijving. | Voorbeeld Administrator account |
4. Safe Toegang
Beschrijving
In het integratiedossier heb je de mogelijkheid om bij Safe Toegang per context mee te geven aan welke organisatie de desbetreffende context gelinkt wordt. Dit wordt op safe niveau ingeregeld en niet per account. Als je hier geen organisatie invult, dan zal de organisatie gespecifieerd in de kolom ‘OVO-code’ worden gebruikt en zal de context aan die organisatie gelinkt worden.
5. Recording safe
Naamconventie
R-[Verantwoordelijke]-[OVO-code]-[Team of Applicatie ID]-[Type safe]-[Locatie]
Beschrijving van de naamconventie
De naamconventie van de Opname Safe is dezelfde als bij de Account Safe met een bijkomende prefix "R-" die aangeeft dat deze safe enkel gebruikt wordt om opnames in op te slaan. Binnen deze safes worden er dus geen accounts beheerd. Opname safes worden enkel aangemaakt als een account safe één of meerdere accounts bevat met een managed (MA) of secure access (SA) policy (zie “2. Toegangsbeleid design”). Toegang tot de opname safe wordt verleend aan de personen die de auditor rol hebben verkregen. Meer informatie rond autorisatie tot safes kan geraadpleegd worden in "6. Contexten".
6. Contexten
Beschrijving
Een context bevat de informatie van een safe en de rol voor het type van toegang. Afhankelijk van het toegangsbeleid onderscheiden we drie verschillende rollen die toegang tot safes en dus tot de geprivilegieerde accounts verschaffen.
Naamconventie
[Verantwoordelijke]-[OVO-code]-[Team of Applicatie ID]-[Type safe]%[Context]
Beschrijving van de naamconventie
De naamconventie volgt die van een account safe zonder de "Locatie" parameter en wordt ingevuld door de suffix "Context". Dit maakt het mogelijk om in de toekomst de accounts van de ene naar de andere safe te verplaatsen zonder impact te hebben op de permissies die geconfigureerd zijn binnen VO WebIDM. (Dit kan nodig zijn wanneer een applicatie verplaatst van 'Locatie').
Parameter | Beschrijving | Mogelijke waardes | Waarde beschrijving |
---|---|---|---|
Context | Beschrijft de rol die een gebruiker krijgt binnen een safe.
|
| %user: De gebruiker met deze rol heeft toegang tot alle accounts binnen de safe en kan deze gebruiken om in te loggen op de applicatie. %approver: De gebruiker met deze rol kan alle toegangsaanvragen tot de safe valideren. Dit is enkel van toepassing voor accounts met toegangsbeleid SA. %auditor: De gebruiker met deze rol kan alle activiteit van de accounts in de safe live of achteraf bekijken (bv. opnames raadplegen). De auditor rol die aangemaakt wordt voor de account safe wordt eveneens gebruikt in de opname safe om toegang te verlenen tot de opgenomen sessies. |