Aanpassing en uitbreiding GEMMA architectuurprincipes

Door de, mede vanuit de Common Ground informatiekundige visie, aanbevolen scheiding van processen en gegevens en het verschaffen van toegang tot gegevens uit bronregistraties via moderne API’s is er de behoefte aan een herinrichting van de wijze waarop toegang tot processen en gegevens wordt vormgegeven. Het veel gehanteerde concept van het autoriseren van gebruikers door middel van een rollenstructuur is niet schaalbaar genoeg en voldoet in deze nieuwe inrichting niet meer aan de eisen die gesteld worden vanuit privacy- en informatiebeveiligings wet- en regelgeving. Nieuwe architectuurprincipes en -patronen zijn vereist.

Binnen het project Referentiearchitectuur voor het werken met API’s wordt een moderne inrichting voor het werken met API’s opgezet die gebruik maakt van concepten zoals Zero Trust en Policy Based Access. Deze concepten maken het mogelijk om op een veilige, schaalbare, controleerbare en toekomstvaste wijze toegang te verlenen tot API’s binnen- en buiten de eigen informatievoorziening.

Het ontwikkelen van de nieuwe architectuur wordt gerealiseerd een agile aanpak. De onderstaande set van architectuurprincipes vormen de eerste iteratie van deze principes. Uitgangspunten die gehanteerd zijn bij het definiëren van deze archituurprincipes:

Transitie van platformen naar protocollen
API access op grond van federatieve protocollen
Toekomstige oplossing richting Zero Trust Architectuur
Toegang op basis van policy based access control
Granulariteit van API’s en hiërarchie van policies als onderliggend uitgangspunt.

De projectgroep onderkent dat deze transities een lange doorlooptijd hebben en traditionele en moderne methodes ruime tijd naast elkaar moeten kunnen blijven bestaan.

Ten aanzien van de referentiearchitectuur voor het werken met API’s zijn op een aantal vlakken architectuurprincipes benoemd op de volgende aspecten:

Deze architectuurprincipes worden als aanvulling op de GEMMA principes opgenomen.

De onderstaande principes zijn de eerste conceptversie van de principes voor het (veilig) werken met API’s. Gemeenten en leveranciers worden hierbij uitgenodigd om input te leveren op deze concept principes. Het geven van input in de vorm van suggesties voor aanpassing van de principes of suggesties voor het toevoegen van nieuwe principes kan via het aanmaken van een Github issue of door een email te sturen naar de product owner van de referentiearchitectuur voor het werken met API’s.

Basis op orde

#	Principe	Rationale	Implicatie
B1	Elke IT oplossing is passend binnen het IT- landschap	Een applicatie die afwijkt van de standaarden zorgt voor extra beveiligingsrisico’s, extra onderhoud en breder benodigd specialisme.	Controleren huidige status IT-architectuur onderdeel laten zijn van inkoopprocessen ongeacht de grootte van de IT-oplossing
B2	Data is altijd geclassificeerd	Zonder classificatie is niveau maatregelen van specifieke data sets niet te bepalen.	Controleren huidige status BIV-classificatie beleid opstellen (o.a granulariteit) BIV-classificatie implementatie wijze bepalen BIV-classificatie implementatie verrichten
B3	Elke IT oplossing is voorzien van een baselinetoets en pre DPIA en afhankelijk daarvan een Baseline niveau / risicoanalyse en/of DPIA	Zonder de juiste documentatie per IT oplossing zijn de achtergrond en details niet bekend, waardoor impact op de organisatie, maar ook mogelijke gaps niet bekend zijn.	Controleren van aanwezigheid templates Opstellen van benodigde templates Controleren huidige status Controle proces opzetten voor uitvoering documentatie Borgen van documentatie bij IT oplossing
B4	Beveiligde communicatie is standaard	Inbreuken op integriteit en vertrouwelijkheid zijn niet acceptabel en communicatiebeveiliging dient standaard te zijn tussen interne en externe applicaties.	Controleren huidige status Opstellen van Zero Trust Architectuur (Zero Trust Architectuur) Acties bepalen voor implementatie Zero Trust Architectuur
B5	Veilige software code, minimaal conform Open Web Application Security Project (OWASP) standaarden	Wanneer eigen ontwikkeling plaatsvindt of ontwikkeling is uitbesteed moet dit volgens strakke standaarden gebeuren en moet hier op gecontroleerd worden om een goede score op BIV te realiseren.	Controleren huidige status Softwareontwikkeling beleid opstellen Softwareontwikkeling beleid gebruiken als controle wijze, voor gap analyse Softwareontwikkeling gaps oplossen
B6	Voor beveiliging van communicatie wordt mTLS toegepast	Communicatie tussen Identity Provider en Service Provider (door tussenkomst van de 'user') is beveiligd	De Identity Provider is voorzien van een geldig TLS certificaat. Dat zal van een (in de browsers) bekende root-CA moeten zijn om externe werking te kunnen hebben.

Toegang

#	Principe	Rationale	Implicatie
T1	Toegangsregels (tot welk object dan ook) worden rekening houdend met risicoanalyse op basis van BIV classificatie bepaald.	Bij een minimaal risico, hoeven er vanuit de optiek van efficiency alleen minimale beveiligingsmaatregelen te worden getroffen Identiteiten kunnen zijn: mensen, services, processen, componenten, Robot Processing Automation (RPA), devices, dus zowel ‘human’ als ‘non-human’.	Openbare informatie (C=laag) mag publiek toegankelijk zijn voor raadplegen (niet voor muteren, waar voor openbare informatie I=Hoog geldt).
T2	Toegang tot beveiligde objecten wordt uitsluitend toevertrouwd aan vertrouwde identiteiten	Iedere toegangspoging wordt gerelateerd aan een identiteit van een vertrouwde identity provider.	Of de Identity Provider voert het in-, door- en uitstroomproces van de Service Provider zelf uit, of er is een contractuele relatie tussen Service Provider en Identity Provider. De identiteiten binnen Identity Provider worden (geautomatiseerd via een IAM-voorziening) beheerd vanuit de reguliere in-, door- en uitstroomprocessen van de organisatie.
T3	Toegang vindt alleen plaats na validatie van geldigheid van de identiteit.	Zonder vast te stellen of de gebruiker die wil authentiseren wel gemachtigd is om te authentiseren en zonder de juiste authenticatie mogelijkheden kan de BIV van de IT-oplossing in gevaar komen.	Validatie van de identiteit hangt samen met authenticatie van de digitale identiteit. Identiteiten en accounts zijn voorzien van passende wachtwoorden (lengte prefereert boven complexiteit). Multi-factor authenticatie als extra validatie- & beschermingsmaatregel.
T4	Authenticatie vindt plaats via Single Sign-On na inlog bij een vertrouwde identity provider.	Gebruiksgemak en verlagen beheerlast en risico identiteit management. Separaat inloggen in applicaties, platformen en informatiesystemen is ongewenst.	Federatieve toegang via SAML, OIDC of Oauth. Voor legacy, on-prem systemen kan LDAP worden toegepast.
T5	Wachtwoordbeveiliging is end-of-life	Wachtwoorden zijn per definitie niet voldoende veilig	Onderzoek gebruik van wachtwoorden en stel migratiepad op.
T6	Alle, al dan niet geslaagde, toegangspogingen tot de IT-oplossing worden gelogd.	Logging geeft inzicht in het gebruik, daaruit volgend trends en mogelijke aanvallen. Verder is logging een vereiste om de BIV aspecten te waarborgen.	Identiteit [Id], van Identity Provider [Identity Provider] heeft op datum [D] en tijd [T], toegang gevraagd tot resource [Res]. Identiteit [Id], van Identity Provider [Identity Provider] kreeg op datum [D] en tijd [T], op grond van policy [Pol], versie [Ver] met attributenset [Attr] toegang tot resource [Res].

Policy Based Access Control (PBAC)

#	Principe	Rationale	Implicatie
P1	Er wordt uitsluitend toegang verleend als de toegangsvraag op het moment van aanvraag voldoet aan de policy om toegang te krijgen	Toegang is alleen mogelijk als alle relevante stakeholders daarin toestemmen Verlenen van toegang vergt actuele informatie om dynamiek te ondersteunen	Implementeren Access Governance. Identificeren relevante belanghebbenden Definiëren policy structuur Definiëren Access architectuur
P2	Businessrollen binnen de IAM-voorziening kunnen worden gebruikt als attributen die bij de toegangspoging worden getoetst.	Informatie uit de IAM-voorziening kan worden gebruikt als input voor de keuzes voor toegang.	De kwaliteit van informatie uit de IAM-voorziening moet goed zijn. De koppeling tussen rollen en de externe toegang moet worden onderhouden, i.v.m. consequenties van wijzigingen.
P3	Als er geen policy is gedefinieerd, wordt er geen toegang verleend.	Conform BIO H9, Default deny	Policies moeten expliciet worden vastgesteld Policy enforcement wordt ingericht
P4	Het is niet toegestaan om zonder policyverificatie toegang te krijgen	Discretionary Access Control (BIO H9)	Zie P3
P5	Risicoanalyse / BIV-classificatie zijn onderdeel van de access beslissing, onderdeel van de policy	Policy based access control houdt rekening met diverse attributen en regels die door belanghebbenden zijn vastgesteld	Policies moeten verwijzen naar risico-analyse of BIV-classificatie Ofwel: BIV > policy uitspraken
P6	Betrouwbaarheid van Identity Provider, Identiteit en authenticatieniveau is onderdeel van de access beslissing	Policy based access control houdt rekening met diverse attributen en regels	Bij inlog of toegangspoging wordt authenticatiemiddel en –niveau gevalideerd In Federatieve berichten is Multi Factor Authenticatie-niveau in een claim beschikbaar. Voorkeur voor Stork-claims, te mappen op eIDAS
P7	Alle policies van alle belanghebbenden worden getoetst binnen de toegangsvraag	Policies moeten achtereenvolgens in samenhang werken	Policy engines dwingen achtereenvolgens toepassing van policies af

Federatie

#	Principe	Rationale	Implicatie
F1	Alle intern beheerde identiteiten worden per definitie vertrouwd als onderdeel van eigen beheercontext.	Het HR beheerproces voor alle interne identiteiten is vertrouwd en levert betrouwbare identiteiten en attributen.	De juiste maatregelen zijn ingeregeld om controle van interne identiteiten te borgen.
F2	Alle externe identiteiten krijgen uitsluitend toegang op basis van federatieve verbindingen, op grond van federatieconvenanten of -contracten of vertrouwde, gecontracteerde federatieve frameworks.	Externe identiteiten kunnen afkomstig zijn van diverse bronnen en daarom dient er een standaard manier van toegang verkrijgen te zijn.	Federaties worden aangegaan op instigatie van een eigenaar binnen de bedrijfsvoering Alle externe toegang (dus inkomend en uitgaand) wordt beheerst via security gateways, conform een centraal beheerde security policy Federatieve verbindingen worden regelmatig gecontroleerd op validiteit.
F3	De Identity Provider voldoet aan de AVG voor het beheer van persoonsgegevens.	De basis van een Identity Provider is het verstrekken van een vertrouwde identiteit en de daarbij benodigde persoonsgegevens.	Bepalen welke persoonsgegevens nodig zijn voor de SP Borgen dat de Identity Provider alleen die gegevens doorgeeft Borgen dat de Identity Provider aan de juiste veiligheidsnormen voldoet
F4	De Identity Provider voorziet in digitale identiteiten die via OpenID Connect, Oauth (>= v2) en SAML (>=v2) beschikbaar worden gesteld voor federatieve toegang.	Standaard protocollen moeten worden gebruikt om leverancier lock-in of speciale ontwikkelingen te voorkomen.	Uitsluitend gebruik van moderne federatieve protocollen volgens open industriestandaarden
F5	De Identity Provider beschikt over een multi-factor authenticatiefaciliteit (MFA).	Multi Factor Authenticatie is een extra validatie- & beschermingsmaatregel voor de authenticatie tot de Identity Provider.	Gebruikers kunnen hun Multi Factor Authenticatie kwijtraken wat leidt tot het niet verkrijgen van toegang. Onderzoeken welke Multi Factor Authenticatie mogelijkheden geboden moeten worden.
F6	Uitgangspunt federatieve toegang: Identiteiten worden beheerd door de Identity Provider, services worden geleverd door de Service Provider (ook wel Relying Party genoemd).	De oplossing is verantwoordelijk voor een specifiek deel van de functionaliteiten.	Splitsing van verantwoordelijkheden zorgt voor focus van functionaliteiten.
F7	De Service Provider verleent toegang aan identiteiten die voldoen aan de door de Service Provider opgestelde kaders.	Kaders zorgen voor een lijst met eisen aan de Identity Providers voor toegang verlening.	Kaders moeten worden opgesteld. Consequenties van te strenge kaders moet worden gerealiseerd.
F8	De toegangskaders zijn vastgelegd in een federatiecontract, in een federatieconvenant of in een federatief stelsel (het trust framework, bijv. eIDAS).	Het gebruik van een framework zorgt ervoor dat het voor alle partijen duidelijk is wat zij kunnen verwachten. Daarmee ook wat zij kunnen bieden.	Bij gebruik van specifieke frameworks kunnen daar consequenties aan vastzitten wat betreft mogelijke dienstverlening. Afwijken van frameworks zorgt voor uitsluiting.
F9	De Identity Provider moet voldoen aan de aansluitvoorwaarden mn. kwaliteit in-, door- en uitstroomproces, security-eisen, kosten.	De basis van een Identity Provider is het verstrekken van een vertrouwde identiteit en daar horen strenge eisen bij vanuit de SPs.	De Identity Provider moet bepalen welk niveau van eisen zij gaan invullen en welke SPs zij willen bedienen.
F10	De Service Provider moet voldoen aan de aansluitvoorwaarden mn. privacyborging, doelbinding etc.	Net als bij een Identity Provider zijn er bepaalde eisen waar een Service Provider aan moet voldoen.	SPs moeten duidelijk stellen waarvoor zij de identiteit informatie gebruiken en de consequenties van veranderingen zijn. Consent moet opnieuw worden gevraagd bij de identiteit bij een wijziging.