Document toolboxDocument toolbox

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]

image-20240215-135626.png

Beschrijving van de naamconventie

Parameter

Beschrijving

Mogelijke waardes

Waarde beschrijving

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

  1. O: gebruikers die eigenaar zijn van de applicatie en zelf het beheer doen

  2. D: een gedelegeerde partij die het beheer van een applicatie in opdracht doet

Enkel de applicatie-eigenaar kan bepalen wie een gedelegeerde partij is.

  • O

  • D

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.

OVO-code

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.

 

  • ADM

  • TNI

  • OPS

  • NPA

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):

  • Aangemaakte accounts om de applicatie te beheren en te onderhouden.

  • Aangemaakte reconcile accounts die beheerd worden in twee specifieke reconcile safes (zie "Safe design voor een reconcile account").

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:

  1. 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

  2. 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

image-20240215-135246.png

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

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

  • WIN

  • UX

  • AWS

  • AZR

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

Toegangsbeleid

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.

  • AO

  • MA

  • SA

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:

  • Reden van toegang dient ingevuld te worden

  • Changenummer dient ingevuld te worden

  • Audit logging en sessie opname

  • Rapporteringsmogelijkheden

Secure Access (SA): Deze accounts hebben een zeer restrictief toegangsbeleid met volgende maatregelen:

  • Alle elementen die aanwezig zijn binnen het Motivated Access beleid

  • De toegang dient goedgekeurd te worden door een derde (= approver)

  • De toegang is beperkt in de tijd

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.

  • N

  • L

  • R

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.

  • ACR (Standaard)

  • AC (bij AWS)

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

Parameter

Beschrijving

Voorbeeld

Username

Gebruiksvriendelijke naam van het Windows domein account.

DomainAdmin

Address (FQDN)

Fully Qualified Domain Name (FQDN) van het Windows domain.

windowsdomeinnaam.vlaanderen.be 

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

Parameter

Beschrijving

Voorbeeld

Username

Gebruiksvriendelijke naam van het Windows local account.

Administrator

Address (FQDN)

Fully Qualified Domain Name (FQDN) van de Windows server.

servernaam.vlaanderen.be 

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

Parameter

Beschrijving

Voorbeeld

Username

Gebruiksvriendelijke naam van het Linux account.

Root

Address (FQDN)

Fully Qualified Domain Name (FQDN) van de Linux server.

servernaam.vlaanderen.be

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

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.

https://[UwAWSAccountID].signin.aws.amazon.com/console

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

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.

GlobalAdmin@81039.vlaanderen.be

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

Parameter

Beschrijving

Mogelijke waardes

Waarde beschrijving

Context

Beschrijft de rol die een gebruiker krijgt binnen een safe.

 

  • %user

  • %approver

  • %auditor

 

%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.