Thesis: Domein Architectuur voor het Identity en Access Management Domein

1. Inleiding

1.1 Aanleiding

1.2 Doelstelling

Dit document is de Domein Architectuur voor de afbakening van het materiegebied Identity en Access Management (AIM) van de HHS.

1.3 Doelgroep

Dit document is bedoelt voor:

‘ IT management van de HHS
‘ IT Project managers en Architecten
‘ De Senior Beheerders
‘ Project Specialisten en lezers van de PSA’s en HLD’s.

1.4 Positie van dit document

Het IAM Domein Architectuur document leeft op het niveau tussen de Enterprise Architectuur en de Project Start Architectuur. Dat wil zeggen dat aan de Enterprise Architectuur kant verschillende beslissingen en richting worden gedefinieerd over de befrijfsmodellen van de Haagse, en bijvoorbeeld de informatie inrichting van de Haagse, naar richtingbepalende Architectuur binnen IAM. En aan de project start architectuur kant, de vertaling van die architectuur naar de projectarchitectuur. Te gebruiken om richting aan het project en de inrichting van de oplossing te geven.
De Domein Architectuur IAM legt verbindingen tussen deze bovenstaande stukken.
De kaders van de domein Architectuur IAM beperken zich tot het beschrijven van de onderdelen van het Identity en Access management op de HHS. Deze onderdelen zijn:

‘ De IAM diensten na implementatie
‘ De IAM functies die de IAM diensten voorbrengen
‘ De IAM Identity informatie en entiteiten die door de functies verwerkt worden
Het beschrijven van de IAM domein Architectuur onderdelen is opgenomen in de onderbouwing van in-, en externe standaarden, uitgangspunten en richtlijnen die opgebouwd zijn door de standaarden en/of toepassingen zoals vandaag bij de Haagse bekend. Voor welke personen, applicaties en toepassingen de IAM diensten geschikt worden gemaakt, en welke technieken er gebruikt worden voor bepaalde functies en diensten binnen het IAM domein.
Kenmerken van de Domein Architectuur zijn;
‘ Richtinggevend aan de verdere uitwerking van de architectuur van een business unit of een project, en;
‘ Zorgt voor afstemming met de IT architectuur standaarden en het Management, richtlijnen en standaarden binnen de HHS IT Architectuur, en;
‘ Definieert essenti??le producten, diensten en functies binnen het (IAM) domein en maakt high level keuzes over oplossingsrichtingen, en;
‘ Er zijn aanvullende principes gedefinieerd die voor het AIM domein relevant zijn en die richting geven aan de Project Start Architecturen (PSA) en High Level Designs (HLD).
Afbeelding 1, Overzicht Positie IAM Domein Architectuur

1.5 Randvoorwaarden

1.6 Documentstructuur
Dit document is als volgt opgebouwd:
‘ Hoofdstuk 1 ‘
‘ Hoofdstuk 2 ‘
‘ Enz, enz,

1.7 Brondocumenten
De volgende bron documenten zijn gebruik voor de samenstelling van deze Architectuur
‘ HHS IT-architectuur Kaders (bepalen welk document)
‘ HHS IT- Beleid (bepalen welk document)
‘ HHS Data Classificatie Beleid ‘ Document Referentie: IM121203
‘ HHS Informatie Beveiligingsbeleid ‘ document Referentie IM140401
‘ HHS Account en Authenticatie Beleid 0 document Referentie IT140716
‘ NORA Online
‘ Wikipedia.
‘ ISO ‘ IEC 24760 ‘ Document over begrippen in IAM

1.7.1 HHS IT Architectuur Kader
Omschrijving hier
1.7.2 HHS IT Beleid
Document Omschrijving hier
1.7.3 Data classificatie Beleid
We gebruiken hier de input van het document (IM131203) Classificatie HHS. Auteur Rosanne Pouw.
RLE: Kunnen we de concept versie als bron gebruiken?
1.7.4 Informatie Beveiliging Beleid HHS
We gebruiken hier de input van het document (IM140401 IB Beleid) auteur R. Pouw.
RLE – Kunnen we de concept versie als bron gebruiken?
1.7.5 Account en Authenticatie Beleid HHS
We gebruiken hier de input van het document (IT140716 authenticatie en accountbeleid 0.3) auteur R. Pouw.
RLE – Kunnen we de concept versie 0.3 als bron gebruiken? Dit document beschrijft beleidsuitgangspunten voor authenticatie- en accountmanagement. Hierbij is meegewogen dat De HHs een onderwijsinstelling is: een openbare instelling waarbij enerzijds gegevens en informatie toegankelijk gemaakt wordt terwijl aan de andere kant betrouwbaarheid van onze gegevens en informatie geborgd moet worden.
1.7.6 NORA Online
NORA Online is een wiki
1.7.7 Wikipedia
Omschrijving hier
1.7.8 ISO IEC Repository
Omschrijving hier
1.7.9 Externe Standaarden en Referenties
Deze overige lijst hier opnemen

2. Inleiding Identity en Access Management
2.1 Definitie IAM
Identity management heeft betrekking op het administreren van gegevens van gebruikers en hun autorisaties binnen de context van een organisatie. Nauw gerelateerd aan identity management is access management (toegangscontrole). Dit is het authentiseren en autoriseren van gebruikers om toegang te krijgen tot systemen. Identity management is de basis voor access management en samen worden ze ook wel benoemd als ‘identity & access management’.
Notitie: De termen Identity Management en Identity en Access Management (of IAM) worden regelmatig door elkaar gebruikt op het gebied van Identity en Access Management. In de domein architectuur gaan we IAM als geheel oppakken en behandelen we het privileged Identity management gedeelte.
2.2 Algemene informatie
2.2.1 Identity Management
Identity management (IdM) is het beheren van gebruikersinformatie in ICT omgevingen. De gebruikersinformatie bevat de informatie die de identiteit van een gebruiker authentiseert, en informatie over autorisaties (acties en toegang) op allerlei applicaties, netwerken, websites, ruimtes, enz. Entiteiten die onder dit beheer vallen zijn gebruikers, applicaties en/of hardware.
2.2.2 Access Management
Access Management is het beheer van de toegang voor die gebruikers die toegang tot informatie nodig hebben. Access management is de verwerker/regelaar/transporteur functie van beschikbaar gestelde gebruikers informatie uit te wisselen tussen de daarvoor benodigde betrokkenen.
Het beheer van de toegang is de implementatie en het managen van Authenticate policy(s), Autorisatie policy(s), Adaptive risk, Federation, Single Sign On, High Availability voor sessiesccess Management
2.2.3 Privileged Identity Management
Privileged Identity Management is het beheren van de accounts die speciale (anders dan normale accounts) eisen en richtlijnen hebben, zoals compliance, governance of risk eisen. Het doel is het voorkomen van informatie lekken, door misbruik van deze speciale accounts. Deze accounts zijn accounts met veel rechten op een systeem of in een applicatie (admin level accounts).
Hierbij geldt net als bij niet privileged accounts dat Access Management, Identity Management, Password Management en Account Security ingeregeld moet worden voor accounts die aangemerkt worden als privileged.

2.3 Positionering IAM Domein Architectuur

2.4 Gebruikersperspectief
Halen uit de functionaliteiten en eisen voor gebruikers
2.5 Informatiesysteem perspectief

Afbeelding 2, Informatie Model

2.6 Functionaliteiten
Eventueel deze samenvoegen met diensten beschrijvingen.
2.7 Diensten

Afbeelding 3, Informatie Model

2.8 Terminologie
De IAM taal wordt in dit hoofdstuk omschreven. We hebben verschillende termen uitgeschreven die een verduidelijking geven van wat deze betekenen en hoe ze worden gebruikt. Daarnaast hebben we de termen ingedeeld in hoofdstukken, waarbij bijvoorbeeld onderscheid is aangebracht tussen een term die in IAM algemeen wordt gebruikt en termen die specifiek in een bepaald onderdeel van het IAM systeem worden gebruikt, ofwel alleen in het managen van IAM.
Het is geen alfabetische opsomming geworden. Dit ter bevordering van het gebruik van de termen.
2.8.1 Generieke Termen
IdM – Identity Management – Het geheel aan beleid, verantwoordelijkheden, processen en hulpmiddelen dat organisaties in staat stelt om de identificatie en authenticatie van subjecten te faciliteren, te beheren en te controleren
AM – Access Management – Het geheel aan beleid, verantwoordelijkheden, processen en hulpmiddelen dat organisaties in staat stelt om de toegang tot en het gebruik van objecten (systemen en informatie) te faciliteren, te beheren en te controleren.
Entity ‘ Een entity is een item (zoals we in ITSM configuratie item herkennen). Aan een Entity zijn processen gekoppeld.. Zo kan een Entity ‘ persoon’ een naamsveranderingsproces nodig hebben. Het proces ‘Naam wijzigen’ is van toepassing als een persoon gaat trouwen of scheiden en is een trigger voor het uitreiken van een nieuwe bedrijfspas met nieuwe certificaten en het wijzigen van de eigenschappen van het IT-account. Deze processen vallen binnen de levenscyclus van het IAM systeem
Voorbeelden van entiteiten is de volgende lijst:
Entity Toelichting
Actie Een handeling die een subject met een middel (object) kan uitvoeren, waarop een autorisatie of toegangsregel van toepassing kan worden verklaard
Afdeling Een organisatorische eenheid als onderdeel van de afdelingshi??rarchie van een organisatie
Arbeidsplaats Een unieke positie binnen en afdeling waarop een persoon kan worden geplaatst c.q. te werk gesteld
Autorisatie Een aan een class/ rol/ claim/ clearance verleend recht tot het uitvoeren van een actie op een IT-middel
Bedrijfspas Het persoonsgebonden identiteitsbewijs van personen die een werkrelatie hebben met de organisatie, voorzien van Public Key certificaten
Certificaat Een persoonsgebonden of Server gebonden Public Key ‘ certificaat, dat voor personen ge??nstalleerd is op de bedrijfspas of een andere tokenvorm als drager, eventueel gekoppeld aan het IT account fungeert dit als authenticatiemiddel. Voor IT-componenten wordt het certificaat ge??nstalleerd in een Hardware Security Module (HSM) of als z.g. ‘software certificaat’ in de systeemprogrammatuur.
Criterium Een eigenschap die iets of iemand kan bezitten en relevant is voor het defini??ren van toegangsregels
IT-Account Een persoonsgebonden account waarmee een persoon inlogt.
IT-Middel (object) Een applicatie, fysiek object, service of gegevens, waar de natuurlijke persoon (of IT-component) toegang toe moet hebben om zijn actie uit te kunnen voeren. Middelenbeheer wordt buiten de scope van IAM uitgevoerd, voor zowel IT-componenten als voor gegevens.
Persoon (subject) Een natuurlijke persoon die een formele en geregistreerde relatie heeft met de organisatie
Class / Role Assertion / Clearance Abstractie, die wordt gehanteerd om samenhangende sets van autorisaties te bundelen en die inzicht verschaft ‘uit hoofde waarvan’ personen, waaraan de class / role / assertion / clearance is toegekend, de desbetreffende autorisatie hebben ontvangen.
Vertrouwensniveau, dat een persoon is toegekend en gelijk is aan het maximale classificatieniveau van het te behandelen gegeven of bedrijfsproces: b.v.: Confidentieel, Geheim of Zeer geheim. Het wordt toegekend als resultaat van een veiligheidsonderzoek (AIVD/ MIVD en VOG van gemeente).
IT-component (subject) Een IT-component is een geregistreerd applicatieproces of onderdeel van de IT- infrastructuur, dat toegang kan worden verleend tot de entiteit IT-Middel.
Toegangsregel Beschrijft criteria waaronder bepaalde acties op een middel mogen worden uitgevoerd
Toekenning Koppeling van een rol aan een persoon. Deze koppeling kan gelijk zijn aan de plaatsing van de persoon voor arbeidsplaats gerelateerde rollen, maar hieronder vallen ook de toekenningen van niet-arbeidsplaats gebonden rollen aan personen.
Werkrelatie Een plaatsing c.q. tewerkstelling van een persoon op een arbeidsplaats binnen de organisatie.
Tabel 1, Entity Toelichting
Attribute(s) ‘ Dat zijn de kenmerken of eigenschappen van een Entity. Deze kenmerken kunnen de staat waarin of toestand, uiterlijk en andere aspecten beschrijven. De primaire functie van het begrip attribute in IAM is een correcte en goede beschrijving van een entity. Omdat deze attributes worden gebruikt bij het beschrijven en toetsen van een entity.
Identity ‘ Dit is een (of de) identiteit en/of gedeeltelijke identiteit. Een Identity is opgebouwd uit een set van attributes van een entity. Een entity kan een of meerdere identities hebben, en entities kunnen samen dezelfde Identity hebben.
In een bepaalde omgeving (domein) of toepassing zoals een keten, kan een identity een ‘distinguishing identity’ worden. Dit komt doordat dit wordt gebruikt als unique identity. Als dat zo is wordt dit de ‘Identifier’ genoemd.
Identifier ‘ Een identifier is het unieke (of exclusieve) attribute van een identity, binnen het domein van afkomst. Deze identifier kan ook gebruikt worden buiten het domein van afkomst in het geval van een federatie of trust.
Binnen de Haagse hebben wij gekozen om het ‘person UID’ in CDS op te nemen als Identifier. Dit is een hash based 20 karakters lange exclusieve identifier. Gegevens uit SAP (personeel nummer), of Osiris (studenten nummer), of Burger Service Nummer (BSN) vallen af als Identifier van wege bijvoorbeeld wetgeving, of exclusiviteit.
Domain of origin ‘ (Domein van Afkomst) Is een beschrijving van (bij) een attribute. Dit kan van alles zijn wat betrekking heeft op dat attribute, omdat hier vanuit wordt gegaan dat dit atribute in meerdere domeinen gebruikt kan worden.
Als voorbeeld, als een attrubute niet in het ‘eigen’ domein gebruikt wordt wil het ‘niet beherende domein’ wel meta data over dit attribute ontvangen, als onderdeel van de afspraken tussen die domeinen.
Meta data van een attribute in dit geval kunnen zijn.
‘ Welke en hoeveel waardes er bij dit attribute horen
‘ Welke encoding er gebruikt wordt
‘ Hoe unieke de waardes van het attribute zijn
‘ Wanneer het attribute gemaakt is, en hoelang deze geldig is

2.8.2 Identificatie Termen

Identification – Identificatie is het proces dat vaststelt dat de gepresenteerde identiteit alle informatie bevat die nodig is, zodat het betreffende domein onderscheid maken tussen (de entiteit en de interactie met het domein) de ene entiteit en andere entiteit binnen dat domein.
Vaststellen van de gepresenteerde informatie gebeurd om te bepalen of;
‘ De entiteit reeds in het gebied bekend is, of
‘ De entiteit in aanmerking in het domein bekend te worden
Identificatie kan de identiteit, behorende bij een bepaalde entiteit, gebruiken om te bepalen of:
‘ Een identiteit bestaat reeds voor de entiteit, of
‘ De entiteit overeenkomt met de bekende, gepresenteerde of waargenomen identiteitsgegevens.
‘ De entiteit geassocieerd met de identiteit uniek is.
Verification ‘ Is het verifi??ren van Identity informatie. Dit moet altijd in gedaan worden het geval van nieuwe identiteit informatie, wanneer nieuwe identiteit informatie aan het IAM systeem gepresenteerd wordt. Maar kan ook gebeuren als een Identity register informatie kan verifieerd bij een Identity informatie provider.
Verificatie kan ook vaststellen dat een kenmerk betrekking heeft op het fysieke bestaan van een entiteit, bijvoorbeeld de overeenkomsten met een biometrische controle van de entiteit met een biometrische template die in de identiteit zijn opgenomen.
Note: Verificatie is een onderzoek op de geldigheid van attributen. Dit is niet altijd nodig voor het identificatieproces dat gebruikt kan worden tijdens de interactie met de diensten en de toegang tot de middelen. Maar kan ook gedaan worden door het domein na identificatie, zoals onder andere een taalvoorkeur, een rekeningnummer.
Domain
Identity Information ‘ Identity Information is informatie die betrekking heeft op een bepaalde entiteit in een domein, deze worden ook wel identiteitsgegevens genoemd.
Indien gegeven Identity Information een entiteit van anderen, in de context van een bepaalde use case (zoals tijdens het verificatie proces) voldoende kan onderscheiden, dan is deze Identity Information de onderscheidende identiteit. Wanneer de combinatie van waarden in Identity Information voldoende is, dan is deze identiteitsinformatie is een unique identifier van de entiteit.
Wanneer een nieuwe identiteit wordt gecre??erd voor een entiteit in een domein, kan een Identity Information provider voor het domein bepaalde kenmerken voor de vereiste eigenschappen van de nieuwe identiteit cre??ren (aanmaken). De nieuwe kenmerken kunnen bestaan uit:
Alle benodigde kenmerken voor die Identity om de interactie tussen het domein en de entiteit waarvan de identiteit wordt gecre??erd.
Kenmerken die toekomstige identificatie van de entiteit, eventueel met inbegrip van beschrijving van aspecten van het fysieke kenmerken van informatie heeft
Alle informatie die nodig is voor toekomstige verificatie van de identiteit van de entiteit , of
Een of meerdere

2.8.3 Identiteit Authenticatie Termen
Authentication – Authenticatie is het proces waarbij het systeem nagaat of een gebruiker, een andere computer of applicatie daadwerkelijk is wie hij beweert te zijn. Dit process loopt op het moment op het moment dat er toegang wordt gevraagd op het doelsysteem, applicatie of data.
Authenticated Identity ‘ Vastgestelde (geverifieerde) Identity Information van een entiteit, welke gebruikt wordt om tegen te controleren in het authenticatie proces.
Identity Identification Authority (IIA) ‘ Is een entiteit van een bepaald domein, welke verifieerbare statements kan maken over de attributen van een identity.
Identity Information Provider (IIP) ‘ Is een entiteit welke Identity Information beschikbaar maakt.
Credential ‘ Een Credential is de weergave van een Identity, zoals een gebruikersnaam of een wachtwoord, pin, vingerafdruk, smartcard etc.
Verifier ‘ Is de entiteit welke de verificatie uitvoert.
Relying Party (RP) ‘ Is de entiteit (of partij) die de afhankelijke kant is tijdens de verificatie van identity information van een bepaalde entiteit.
Identity Assertion ‘ Is het maken van een statement (bewering) door een identity information provider (IIP), welke gebruikt wordt door een relying party (RP) tijdens de authenticatie.
Identity Assurance ‘ Is het zekerheidsniveau van de identificatie uitkomst.
Adaptive Risk Score – Is het beoordelen van risico’s tijdens het verificatieproces, en om te bepalen of (of te eisen) dat de gebruiker extra informatie moet leveren voor verdere authenticatie stappen. Een risicoscore kan berekend worden op basis van een IP-adresbereik, de toegang van een nieuw apparaat, sessie idle time, enz.
2.8.4 Identity Management Termen
identity proofing (initial entity Authentication) ‘ Is een bepaalde vorm van authenticatie, welke gebeurd op basis van de correcte beweringen tegen een verifieerbaar identiteitsbewijs. Dat deze vorm wordt uitgevoerd is een voorwaarde tijdens het Enrolment proces.
Enrolment ‘ Is het proces van Inschrijving (niet te verwarren met registratie). Dit kan resulteren in de creatie van een of meer identiteiten voor de ingeschreven entiteit bij het IAM systeem. Juist in dit proces kan een (unieke) Identifier worden gecre??erd, omdat er een uitgebreider gebruikers contact moment is.
De ingevoerde en gemaakte (of gekoppelde) identiteit informatie wordt geregistreerd als de identiteit van de ingeschreven entiteit in een bepaald domein. Het doel van een Enrolment proces is dat de identiteitsgegevens gekozen uit de identiteit bewijs ook worden geregistreerd met deze identiteit op het moment van inschrijving.
Identity Evidence ‘ Met het Identity ‘bewijsmateriaal’ bedoelen we de aangeboden en verzamelde informatie van een aanvrager, die nodig is voor een succesvolle authenticatie. Dergelijke informatie (bewijsmateriaal) kan een deel van de geverifieerde identiteit zijn van de aanvrager.
Identity Register ‘ Is een repository voor het opslaan en uitlezen van Identiteiten voor verschillende Entiteiten. De indexering van een dergelijk register gaat primair op basis van de unique identifier, waarmee we ook aangeven dat er belang is bij een juist register voor het opslaan van Idenities voor een bepaald domein.
Identity Registration – Is het proces om de identiteit informatie in voeren in een IAM systeem voor de entiteiten, waarvan bepaald is dat deze in een Identity register opgenomen dienen te worden. Deze registratie bevat de eerste (basis) registratie van identiteitsgegevens in een dergelijk register, en kan ook geautomatiseerd uitgevoerd worden door bronsystemen te koppelen. Verdere registratie, het verrijken van de registratie, kan gebeuren bij andere contact gelegenheden.
De identity registratie kan zijn voor een bepaalde of onbepaalde duur. Zo kan de wet,- en regelgeving beperkingen opleggen aan de duur van een registratie termijn, bijvoorbeeld hoe wanneer en hoe een registratie termijn kan eindigen.
Tenzij gehinderd door wettelijke voorschriften, moet een onbepaalde registratie te eindigen op een verzoek van, of namens, de entiteit zelf. En Identity information voor verwijdering worden klaargemaakt.
Met de schrapping van alle identiteitsgegevens voor de entiteit, moet de entiteit worden verwijderd uit de identiteit register. Echter, zoals bepaald door een adequaat beleid, kan de HHS enkele identiteitsgegevens voor archiveringsdoeleinden en audit (compliance) doeleinden te behouden en in dit geval, zal de identiteit worden in het levenscyclus stadium de markering ‘gearchiveerd’ krijgen. Het bewaren van een unieke identifier, om hergebruik als een verwijzing naar andere entiteit voorkomen (security compliance).
Reference identity generator ‘ Dit is een Tool die tijdens het enrolment proces een nieuw en unique identifier aanmaakt. Als voorbeeld kan een database systeem een unique nummer aanmaken in een record, en in een tabel plaatsen. Tijdens het generatie proces en deze beschikbaar stellen als unique Identity.
Provisioning ‘ (de-provisioning) ‘ Is de aansturing en uitvoering van het aanmaken en verwijderen van gebruikers toegang daar waar nodig. Dit kan zijn in applicaties (saas en niet saas), op infrastructuur componenten en in toegangssystemen.

2.8.5 Privileged Identity Termen
Privileged Identity Management ‘ Is het beheer van Identiteiten met speciale rechten. Deze worden ook wel (local) Admin of service accounts genoemd. Het doel is om deze identiteiten uit het ‘normale’ IAM beheer te halen, is het feit dat deze rollen extra aandacht en beheer nodig hebben.
Deze moet worden bereikt door een sterker wachtwoord, snellere wijziging van het wachtwoord, danwel het niet vrijgeven van het betreffende wachtwoord in een ww database (zoals keypass). Maar ook het extra veilig (zwaarder encrypten/AES 256) van de ww database die gebruiker wordt in de authenticatie of autorisatie. Kortom privileged IDM is een aparte, maar ge??ntegreerd management oplossing binnen IAM.
Auditing ‘ Het aanleggen van audit trails gebeurd voor identiteiten met meer rechten dan normale gebruikers. Hier wordt nagenoeg alles wat er op basis van dit identiteit gebeurd vastgelegd. Denk hierbij aan session recording, logging, etc. Deze informatie wordt dan gevoegd in een dashboard, rapportages, maar ook een SIEM.
Compliance Reporting ‘ Binnen Privileged identity management is ook voor de diverse compliance eisen een reportage nodig. Enkele compliance regels zijn NIST, PCI DSS en/of SOX. Voor de Haagse hebben we ook onze normale wetgevingen en eisen aan (semi) overheidsinstellingen. Deze rapporten maken het systeem niet compliant maar dragen er wel toe bij om inzicht in die betreffende compliance te verkrijgen.
Access Controls (Just in Time) ‘ Is het controleren van toegang op een bepaald systeem of object voor een Privileged gebruiker of account. Hierbij worden technieken als chaining (stapelen) van controles gebruikt, maar ook het ‘just in time’ koppelen van admin rechten aan een beheerder die daartoe aangewezen is. Dat just in time houd in dat je als beheerder gewoon je normale werk doet als beheerder van een systeem, applicatie, of infrastructuur. Maar op het moment dat je aanpassingen moet maken op het systeem, stoppen van onderdelen, installaties, of rechten wilt aanpassen. Je op dat moment pas de rechten krijgt toegewezen.
2.8.6 Federation Termen
Identity Federation ‘ Identity federation is/zijn afspraken tussen twee of meer domeinen. In deze afspraken is opgenomen hoe identity informatie wordt uitgewisseld en beheerd voor inter-domein gebruik.
Federated Identity ‘ Een Federated Identity is een identity welke geschikt is voor gebruik in meerdere domeinen.
SSO Identity ‘ Een Single Sign-on identity is een identity met een enkele assertion (bewering) die te verifi??ren valt door de relying party van meerdere domeinen.

2.8.7 Privacy Termen
Selective Disclosure ‘ Is een bepaalde (hanteerbaar) principe binnen IAM waarbij een persoon bepaalde vorm van controle heeft over welke informatie er wordt gebruikt tijdens een/het authenticatie (proces).
Minimal Disclosure – Is een bepaalde (hanteerbaar) principe binnen IAM waarbij bij de inrichting van de overdracht van Identity informatie gezocht wordt om te authentiseren met een minimale set aan Identity informatie.
Pseudonym ‘ Een Pseudonym is een identifier, deze identifier heft een minimale set van Identity Information bij zich, maar net voldoende voor de ‘verifier’ om deze te kunnen linken aan een bekende identity.
Anonymity ‘ Is een bepaalde voorwaarde tijdens de identificatie waarbij een entiteit kan worden herkend als ‘voldoende bruikbaar’ voor bepaalde toegang, zonder voldoende identiteitsgegevens om een link naar een bekende identiteit vast te stellen.

2.8.8 Access Management Termen
Authenticatie policy(s) ‘ Die er voor zorgen dat er een seamless authenticatie implementatie kan plaatsvinden voor een gebruiker. En informatie kan leveren aan een management systeem voor security en logging.
Autorisatie policy(s) ‘ Het inregelen van basic (of zware fine-grained) policies wordt beheerd door het autorisatie onderdeel, waardoor deze niet meer in de applicatie (web) opgevangen hoeven worden. Maar centraal en op een ander abstractie niveau worden beheerd.
Session High Availability ‘ Het managen van de beschikbaarheid van de accessmanagement diensten, door sessiesmanagement en failover van sessies te kunnen garanderen.
Attribute/Assertion Based Access Control (ABAC) – Deze vorm van Access Control is een techniek om DAC, RBAC of MAC te kunnen implementeren. In ABAC worden toegangsrechten geassocieerd met een set van regels, die zijn uitgedrukt in meetbare parameters of attributen; die vervolgens worden toegekend aan subjecten die kunnen bewijzen dat zij voldoen aan de regels. ABAC geeft dus toegang tot IT-diensten op basis van een bewering (assertion) over de eigenschappen (attributen) van de aanvrager (subject). De attributen kunnen allerlei formaten of gedaantes hebben: groepen, rollen, clearance levels, context etc. Bepaalde kenmerken worden gebruikt om te bepalen of iemand toegang krijgt zonder de identiteit eerst vast te stellen. Die kenmerken kunnen geborgd zijn in certificaten of tokens uitgegeven door een derde partij.
ABAC is een technologie gebaseerd op SAML om DAC, RBAC of MAC mee te kunnen implementeren. Het is ontwikkeld voor een omgeving, waar de eigenaar van het object de identiteit van het subject niet (exact) kent en is bedoeld voor webservices en internet toepassingen. ABAC is door toepassing van niet-bedrijfsgebonden attributen conventies tevens geschikt voor federatieve toepassingen.
Discretionary Access Control (DAC) – Iedere applicatie, bestand of dataset heeft een eigenaar. Ieder te beveiligen object heeft zijn eigen repository. De data-eigenaar vult de repository voor zijn object met de toegangsrechten van de geautoriseerde subjecten. Bij een functieverandering verwijdert of wijzigt de eigenaar de rechten van het subject. DAC wordt ge??mplementeerd via Access Control Lists (ACL), vaak afgebeeld in applicatie matrices. Toegang tot objecten is gekoppeld aan de identiteit van een subject. Er is dus een directe toegangsrelatie van subject naar object.
Role Base Access Control (RBAC) – Toegang wordt centraal geregeld, aan de hand van vastgestelde regels, die aangeven hoe subjecten en objecten interacteren. Toegang tot objecten wordt verleend op basis van de rol die een subject heeft binnen een organisatie. Omdat er geen directe koppeling is tussen subject en object, wordt RBAC ook wel Non-discretionary Access Control genoemd.
Mandatory Access Control (MAC) – Centraal wordt geregeld, dat subjecten toegang hebben tot gegevens met een classificatie (label) van maximaal het subjectgebonden ‘vertrouwensniveau’ (clearinglevel). Het label is een attribuut dat behoort tot het subject. Elk afzonderlijk dataobject heeft een attribuut. De gezamenlijke repository van de toegangsregels wordt beheerd door de verschillende eigenaren van IT-middelen ??n datasets.

2.8.9 Technische Termen
SAML – Security Assertion Markup Language (SAML) is een op XML gebaseerde standaard voor het uitwisselen van authenticatie- en autorisatiegegevens tussen domeinen.
Voor de introductie van SAML boden fabrikanten leverancierseigen single sign-on oplossingen die niet met elkaar kunnen samenwerken en die vaak cookie-gebaseerd zijn. Het gebruik van dit soort oplossingen blijft vaak beperkt tot enkelvoudige domeinen, omdat cookies in de regel domeingebonden zijn en niet makkelijk uitwisselbaar zijn met andere DNS domeinen.
SAML adresseert deze (inter domein) uitdaging door applicaties af te schermen van de complexiteit van de onderliggende authenticatie- en autorisatiesystemen. SAML maakt single sign-on zonder cookies mogelijk door op een gestandaardiseerde manier gebeurtenissen te beschrijven en deze op een gestandaardiseerde manier uit te wisselen, onafhankelijk van de onderliggende applicaties.
SAML assertions (bewering) kunnen worden uitgewisseld met behulp van diverse technieken, waaronder een SAML-binding voor SOAP over HTTP en pull en push (HTTP POST) methoden. Ook is het gebruik van cookies, om SAML assertions in op te slaan, mogelijk.
Het is belangrijk te onderkennen dat SAML g’?n authenticatieprotocol is. SAML beperkt zich uitsluitend tot het uitwisselen van beweringen over bepaalde authenticatie- en autorisatiegebeurtenissen die hebben plaatsgevonden. Het authenticatieproces en ‘mechanisme valt buiten de scope van het SAML protocol.
OpenId Connect ‘ OpenId connect is een Identity laag(je) bovenop het Oauth (2.0) Protocol. Daarmee is het mogenlijk geworden om
‘ De identiteit van een eind gebruiker te authentiseren door een autorisatie server.
‘ Maar ook het verkrijgen van basis informatie over een eind gebruiker door middel van een REST gebaseerde call.
OpenId connect is de specificatie van een RESTful http API en formatteert de data die verstuurd word op basis van Json.
Oauth – (Open Authorization). Is een open standaard voor autorisatie. Gebruikers kunnen hiermee een programma of website toegang geven tot hun priv??gegevens, die opgeslagen zijn op een andere website, zonder hun gebruikersnaam en wachtwoord uit handen te geven. OAuth maakt gebruik van tokens, waardoor vertrouwelijke gegevens als een gebruikersnaam of wachtwoord niet afgegeven hoeven te worden. Elk token geeft slechts toegang tot specifieke gegevens van ‘?n website voor een bepaalde duur. Zo kan ingesteld worden dat een bepaald programma slechts een jaar toegang (of erder als je wilt vernieuwen) heeft tot de gegevens.
OpenID – OpenID is een gedecentraliseerd authenticatiemechanisme om Single Sign-on op het internet mogelijk te maken. Als iemand gebruikmaakt van OpenID hoeft die persoon voor het inloggen op een website geen gebruikersnaam en wachtwoord te onthouden. Het volstaat om met de OpenID-identiteit in te loggen. De OpenID-identiteit is feitelijk een URL. Als iemand de unieke eigenaar is van die URL, dan kan die URL als digitale identiteit worden gebruikt.
Ws-Federation
Webservices
API ‘ Application Programming Interface – Een API definieert de toegang tot de functionaliteit die er achter schuil gaat. De buitenwereld kent geen details van de functionaliteit of implementatie, maar kan dankzij de API die functionaliteit wel gebruiken. De functionaliteit uit een applicatie bijvoorbeeld.
Een voordeel hiervan is dat met een API meerdere implementaties benaderbaar kunnen zijn, zolang deze maar voldoen aan de API.
REST – Representational State Transfer. Het is een manier om webservices te cre??ren op basis van de bestaande en eenvoudige bouwstenen van het internet. SOAP (Het protocol voor communicatie tussen de applicaties) is vervangen door URL’s voor adressering en de HTTP methodes (GET, POST, DELETE en PUT) voor het aanroepen van de service.
REST heeft in tegenstelling tot SOAP echter geen eigen beveiliging. Beveiliging van de webservice gebeurt op het niveau van de infrastructuur bijvoorbeeld met SSL, een ACL (Access Control List) of een gebruikersnaam en password combinatie.
Json – JavaScript Object Notation is een format (open standard) dat gebruik maakt van tekst die gelezen kan worden door mensen. De tekst bevat ‘attribute’value pairs’ (attribuut omschrijving: en de waarde van het attribuut ) in de regels, zoals {“firstName”: “John”}. Het wordt primair gebruikt in het versturen van data tussen een client en een server situatie. Is een alternatief op XML, en is oorspronkelijk bedacht om real-time en stateful communicatie tussen een browser en een webserver mogelijk te maken zonder het gebruik van Flash of java applets.
BPML2.0 – Business Proces Model and Notation (BPMN) is een standaard voor het modeleren van bedrijfsprocessen dat een grafische weergave geeft om bedrijfsprocessen weer te kunnen geven in een Business Proces Diagram.
Het doel van BPMN is om bedrijfsprocesmanagement te verduidelijken, zowel voor technische als niet-technische gebruikers, door een notatie te gebruiken die intu??tief aanvoelt voor niet-technische gebruikers, maar wel in staat stelt om complexe processemantiek weer te geven.
BPMN wordt dus gebruikt als een gemeenschappelijke taal die de communicatiekloof overbrugt die regelmatig voorkomt tussen het ontwerp en de implementatie van een bedrijfsproces.
XACML – (XML Access Control Markup Language) is een XML taal om policies met betrekking tot toegangscontrole gedetailleerd te beschrijven en uit te wisselen. Het is ontworpen om naadloos te integreren met SAML.
XACML levert flexibiliteit waarmee het mogelijk is om selectief te kunnen defini??ren welke entiteiten (bijv. gebruikers, Webservices) bepaalde privileges hebben op documenten. Deze documenten hoeven niet noodzakelijkerwijs XML documenten te zijn. In de praktijk zal het veel vaker voorkomen dat het documenten betreft van verschillende gangbare formaten zoals HTML, Word of PDF.

2.9 Referentie architectuur

Gegevens model

2.10 Het Framework IAM
Met daarin een beschrijving van de volgende onderdelen:
1) Life Cycle Management
2) De verschillende IAM systemen
3) Controle en signaleringen

2.11 Wat Kan IAM Overzien
Met daarin een beschrijving van de volgende onderdelen:
1) Het managen van trust en federatie
2) Gebruikersmanagement
3) Privileged Identity management
4) Performance en reliability
5) IAM beveiliging
Overzicht van basis Use Cases en Eisen die aan IAM gesteld kunnen worden.

2.12 Het Gebruik van IAM
In dit onderdeel beschrijven we waar we IAM kunnen inzetten, dit zijn geen use cases (functioneel) maar focussed op de technische kant van de use-cases.

3. Huidige situatie
Dit hoofdstuk geeft inzicht in de huidige inrichting van identity en access management en de knelpunten die daarbij spelen.
3.1 Overzicht

Afbeelding 5, Overzicht huidige IDM omgeving

TODO: MFA
Bovenstaand figuur geeft een overzicht van de huidige identity en access management omgeving van de hogeschool. Kenmerkend in deze omgeving is de centrale positionering van de Centrale Directory Service (CDS) die dient als identiteit en account administratie en die bron is voor de provisioning naar de verschillende directories en andere doelomgevingen waar de daadwerkelijke authenticaties en autorisaties plaats vinden. De CDS is gebaseerd op RedHat Directory als LDAP-gebaseerde directory server. Bovenop de CDS is een management tool (Directory Manager) ontwikkeld voor beheerders en een eenvoudige selfservice webapplicatie waarmee gebruikers hun wachtwoord kunnen wijzigen.
De CDS wordt op dit moment gevoed / verrijkt door drie verschillende systemen die dienen als autoritaire bron. Identiteiten van studenten worden aangeleverd uit OSIRIS, het studentadministratiesysteem. Accounts voor medewerkers worden aangeleverd vanuit SAP-HR. Aanvullende gegevens van medewerkers zijn afkomstig uit Planon (het facilitair systeem).
Naast de CDS zijn er nog een aantal andere directories in gebruik. De Active Directory speelt de rol van Account Administratie systeem voor de hele Windows omgeving. Daarnaast is er nog een LDAP Directory, gebaseerd op Oracle Internet Directory, die gebruikt wordt voor authenticaties van een aantal Concern Applicaties en door een aantal authenticatie proxies. Tot slot heeft de Oracle Portal omgeving ook een eigen directory gebaseerd op Oracle Internet Directory, waarin profielinformatie van gebruikers worden geadministreerd.
Er zijn verschillende authenticatie proxies:
1. ADFS, wordt gebruikt voor de authenticatie van de Office365 cloud diensten en als Identity Provider voor de SAML authenticaties die via Asimba verlopen
2. Microsoft Radius, wordt gebruikt voor Eduroam
3. Radiator Radius, wordt gebruikt voor het HHs WIFI netwerk
4. SimpleSamlPhp SAML, wordt gebruikt voor SURF federatie
5. A-Select, wordt gebruikt voor een aantal legacy doelsystemen, zoals Osiris, en als Identity Provider voor de SAML authenticaties die via SimpleSamlPhp verlopen
6. Asimba is een hybride SAML/A-Select product dat gebruikt wordt als bridge tussen A-Select en SAML.
De synchronisatie tussen al deze systemen wordt verzorgd door een provisioningsysteem dat met een aantal producten wordt ingevuld:
1. De Oracle Service Bus, die de gegevens ophaalt uit de bronsystemen en deze verwerkt in de CDS
2. Het product Metamerge Integrator. Dit is feitelijk een soort message broker die ervoor zorgt dat gegevens over identiteiten, inclusief daarbij behorende wachtwoorden, worden opgehaald, vertaald en getransporteerd
3. Microsoft Forefront Identity Manager, die de synchronisatie van het adresboek richting de Office365 cloud diensten voor haar rekening neemt
Tot slot is er nog een extern afgenomen voorziening voor sterke authenticatie door middel van tokens. (Deze is niet in de tekening weergegeven). Deze gebruikt de Active Directory als bron voor de provisioning.
3.2 Knelpunten

3.2.1 Organisatorisch
Een belangrijk probleem in de huidige situatie is dat er geen of nauwelijks vastgesteld informatiebeveiligingsbeleid is waardoor er beveiligingsrisico’s ontstaan. Zo worden accounts soms gedeeld door meerdere gebruikers en er zijn niet-persoonsgebonden accounts. Gegevens worden niet of nauwelijks versleuteld uitgewisseld, en zelfs het wachtwoord wordt niet in alle gevallen versleuteld. Verder geldt dat impliciet gehanteerd beleid niet altijd voor een ieder helder en daarmee gedragen is, zoals bijvoorbeeld het beleid rondom naamgeving van e-mailadressen en accounts.
In de CDS staat een veel groter aantal studentaccounts dan het aantal ingeschreven studenten waardoor additionele kosten en beheerinspanning noodzakelijk zijn. Deels wordt dit veroorzaakt doordat er nog accounts bestaan voor studenten die zich na aanmelding in Studielink uiteindelijk niet hebben ingeschreven. Voor een ander deel heeft dit te maken met het feit dat een account van een uitgeschreven student pas na drie maanden wordt verwijderd. Ook worden de procedures voor het deactiveren en verwijderen van accounts niet altijd of niet tijdig doorlopen.
Op dit moment worden accountnamen gebaseerd op de naam van de gebruiker. Dit betekent dat een naamsverandering potentieel veel impact heeft en leidt tot relatief veel inspanning van beheerders. Naamsveranderingen kunnen bijvoorbeeld optreden bij huwelijken en echtscheidingen, omdat iemand zijn naam bewust verandert maar ook doordat fouten worden gemaakt bij de invoer van gegevens van gebruikers. Daarnaast leidt het gebruik van de naam van de gebruiker in de accountnaam tot privacy issues op het gebied van auditing en monitoring.
In het algemeen is er een probleem met de kwaliteit van de identiteitgegevens. Er wordt onvoldoende gecontroleerd bij invoer of de gegevens correct zijn. Het betreft daarbij niet alleen invoer van gegevens over de identiteit zelf, maar ook gegevens over opleidingen die studenten volgen. Doordat daar onvoldoende discipline bij wordt gehanteerd kunnen dergelijke gegevens ook niet worden gebruikt om autorisaties op te baseren. Problemen met de kwaliteit van gegevens zijn voor een belangrijk deel ook te wijten aan overlappende registraties die niet volledig geautomatiseerd worden gesynchroniseerd.
Het is onduidelijk of en wanneer autorisaties moeten worden verwijderd als een gebruiker een andere rol/functie krijgt. Anderzijds wordt ook niet de volledige levenscyclus van een student ondersteund; op het moment dat hij alleen interesse heeft in een studie dan heeft hij nog geen account. Op het moment dat hij alumnus is heeft hij nergens meer toegang toe, ondanks dat hij in de toekomst potentieel ge??nteresseerd zou kunnen zijn in vervolgopleidingen.
Doordat het beheer en de provisioning van autorisaties niet is ingericht, is toegang tot systemen in de meeste gevallen zwart/wit; je hebt toegang tot alles of je hebt toegang tot niets. Het hebben van een account geeft ook direct toegang tot alle functionaliteit en gegevens. Dit is een veel te grofmazige vorm van toegangscontrole die ertoe leidt dat gebruikers toegang hebben tot zaken waar ze vanuit hun rol eigenlijk geen toegang (meer) toe zouden mogen hebben. Daarnaast is er ook een hele beperkte verscheidenheid van rollen op basis waarvan toegang tot een systeem kan worden bepaald. Zo worden stagiairs behandeld als medewerkers en passen externen al helemaal niet in de aanwezige toegangsstructuur.
Een ander effect van het ontbreken van centraal beheer van autorisaties is dat dit voor een groot deel handwerk is, waarin fouten worden gemaakt en wat arbeidsintensief is. Voor een deel geldt dat andere activiteiten binnen identity management ook niet geautomatiseerd zijn zoals het verwijderen van accounts.
3.2.2 Technisch
E??n van de meest dringende problemen is dat een aantal producten in het landschap reeds de End-Of-Life datum gepasseerd zijn. Voorbeelden hiervan zijn A-Select en de Metamerge versie. Dit heeft tot gevolg dat er onbekende risico’s worden gelopen met betrekking tot de betrouwbaarheid en vertrouwelijkheid van alle systemen die gekoppeld zijn aan het IDM landschap.
Daarnaast is het IDM systeem niet consequent doorgevoerd binnen de organisatie. Er zijn systemen die niet gekoppeld zijn aan de IDM en een eigen gebruikersadministratie voeren, waarop weinig controle is. Voorbeelden hiervan zijn de authenticatie op de Linux systemen, authenticatie op netwerk apparaten en bedrijfsapplicaties als IOLET en DIVIDET.
Identiteit en Account administratie is verspreid over meerdere systemen die onderling geen policies uitwisselen. Dit leidt tot problemen met wachtwoord synchronisatie en wachtwoord policies, als deze ??berhaupt al afdwingbaar zijn.
Er is een groot aantal authenticatie proxies, waarbij er sprake is van een dubbeling van functies. Zo zijn er bijvoorbeeld twee verschillende types Radius server en zijn er twee verschillende SAML systemen. Dit leidt tot een grote beheerlast. Kennis van deze systemen is hierbij zeer problematisch. De HHs is bij een groot deel van de systemen niet in staat om adequaat het beheer te voeren. De meest in het oog springende hier is de AD.
Bepaalde delen van de IDM infrastructuur zijn niet redundant uitgevoerd, A-select is een voorbeeld hiervan. Achterliggende diensten worden wel redundant uitgevoerd vanwege de beschikbaarheid.
Aan de gebruikerskant springt het gebrek aan Single Sign On (SSO) in het oog. Het is in dit landschap zeer lastig om te voorzien in SSO. Daar waar dat wel lukt, is er vaak sprake van een zeer lange keten van elementen om dit te regelen. Dit verhoogt de complexiteit, daar waar er toch al te weinig verstand is van de systemen.
4. Gewenste situatie
4.1 Uitgangspunten IdM

4.1.1 Enrolment proces en proofing
Het Enrolment proces is de start van inhuldigen van een entity’s identity, voor een ‘Haagse Hogeschool Identiteitstermijn’. Dit termijn is gekoppeld aan de rol(rollen) die deze entity krijgt toegewezen tijdens het termijn (contract, afschrijvingsperiode etc) voor de Haagse. Gegeven dat deze entity een rol (of meerdere) vervuld hoed het ook in dat de daarbij behorende attributes in die identity geregistreerd moeten worden. In het geval dat de entity een persoon is zal deze een identity van de Haagse IdP krijgen, en daarmee een abonnee van de Haagse IdP worden.
Het Enrolment proces binnen de Haagse start met het vaststellen en bewijzen dat een entity (persoon, organisatie, systeem, device) de juiste credentials heeft opgegeven. De credentials dienen derhalve te worden bewezen (proofing).
De IAM oplossing van de Haagse moet kunnen verifi??ren en valideren dat een entity’s Identity tijdens het Enrolment proces voldoet aan de vigerende eisen voor identity proofing. Het opslaan van een entity’s identity en het vaststellen van de identifier, credentials en attributes voor de verschillende doeleinden moet onderdeel zijn van een succesvolle bewijslevering, gemeten tegen de verschillende criteria en proofing policies.
Het proofing proces moet worden afgestemd op de waarderingen die de verschillende doel entiteiten (applicaties, data, objecten, systemen) krijgen, in combinatie met het risico’s dat gepaard gaat met het ongeautoriseerd gebruik van een identity waarvoor toegang verleend gaat worden. Met inachtneming dat deze risico’s en waarderingen kunnen veranderen over tijd, waardoor en meer of minder identity proofing uitgevoerd wordt voor toegang.
Nadat het succesvol doorlopen van het Enrolment en proofing proces is afgerond wordt de HHS identity aangemerkt als bruikbaar. Op dit moment kunnen ook de attributes en/of credentials, waartegen een entity geauthentiseerd wordt, ter beschikking worden gesteld binnen de IAM oplossing.
Dit houd in dat er op dat moment credentials (opnieuw/bijgewerkte) worden vastgelegd of uitgevraagd kunnen worden door middel van bijvoorbeeld een digitaal certificaat of een token, verbonden aan een identity. Of dat er een claim (attribute) gemaakt kan worden tegen een identity. Afhankelijk van het soort token welke op dat moment gebruikt wordt zal het IAM systeem een nieuw token aanmaken en deze uitgeven aan de subscriber. Of eisen van de subscriber dat deze (die of datgene welke de claim maakt) een nieuw token meegeeft.

4.1.2 Onderhoud en updates
Nadat een Identity, inclusief de benodigde identity information, is vastgelegd. Is het de gezamenlijke verantwoording van zowel de IAM oplossing, alsmede de subscriber om de identity en identity informatie veilig te houden.
Verder is de subscriber verplicht om de nodige beveiligingsmaatregelen uit te voeren welke zijn vastgelegd in de policy overeenkomsten behorende bij de IAM oplossing. Hiervoor krijgt de subscriber toegang op een beveiligde webpagina. Op deze pagina kan de subscriber de maatregelen uitvoeren en controleren.
4.1.3 Intrekken/Revoken Identity
Het ‘revoken’ van een identity of identity information kan zijn dat de hele identity ingetrokken moet worden, of ten dele moet worden geannuleerd. Bij:
‘ Volledig Intrekken ‘ Is op het moment dat iemand permanent de HHS identity niet langer nodig heeft.
‘ Annuleren van Identity Information ‘ Het moment dat een persoon of device niet langer van die bepaalde resources gebruik, kan of mag maken. Hierbij wordt alleen die informatie geannuleerd die betrekking heeft voor die overeenkomst.

4.1.4 Identity Management Data Functies
4.1.4.1 Data Model en schema
4.1.4.2 Managen van Identity Data

4.1.5 Signalering en Controle

4.1.6 Identity Information Discovery
4.1.7 Identity Information Toegangscontrole
4.1.8 Identity Management Communicatie
4.1.8.1 Real-time en Near Real-time
4.1.8.2 Correlation en Binden
4.1.8.3 Authentication Assurance
4.1.8.3.1 Zekerstellen van Devices Identity en Integriteit
4.1.8.4 Ondersteunen van services die prioriteit vereisen

4.1.9 Identity Management Federation functionaliteiten

4.1.10 Gebruikers behoefte en bescherming van de PII

4.1.11 Beveiliging
4.1.11.1 Systeem en Data Access
4.1.11.2 Systeem en Data Integriteit
4.1.11.3 Data Vertrouwelijkheid
4.1.11.4 Veiligheid tijdens communicatie
4.1.11.5 Management beveiligen
4.1.11.6 Audit en security loggen
4.1.11.7 Beveiligen tegen Ddos
4.1.11.8 IPD en IDS monitoring

4.2 Uitgangspunten AM

4.3 Uitgangspunten Privileged IdM
Zoals ook in de inleiding aangegeven, privileged Identity Management is het beheren van de accounts die speciale (anders dan normale accounts) eisen en richtlijnen hebben, zoals compliance, governance of risk eisen. Het doel is het voorkomen van informatie lekken, door misbruik van deze speciale accounts. Deze accounts zijn accounts met veel rechten op een systeem of in een applicatie (admin level accounts).
Hierbij geld net als bij niet priveleged accounts dat Access Management, Identity Management, Password Management en Account Security ingeregeld moet worden voor accounts die aangemerkt worden als privileged.
Dat betekend dat alle data die we koppelen aan een account dat onder de PIM oplossing komt te vallen, zeer veilig, niet zonder beveiliging, of controle, en het volgen van een aantal succesvolle stappen benaderd en/of gebruikt kan worden. Denk hierbij aan:
‘ Toegang op een systeem of applicatie met Admin rechten
‘ Beheer van wachtwoorden, certificaten, sleutels
‘ Data met de hoogste classificatie

4.3.1 Beheer en organisatie

4.3.1.1 Rapportage
Het PIM systeem moet rapportage kunnen opleveren voor diverse belanghebbende van operationeel personeel, security controleurs tot aan management. Hieronder valt ook de mogelijkheid om custom rapportages op te zetten welke gaan voldoen aan toekomstige eisen voor bijvoorbeeld interval, trending, of branding.
De inhoud van de rapportage moet geschikt zijn voor audit en compliance doeleinden. Hier moeten gegevens worden oplevert welke toespitsen op het ‘admin’ gebruik van de PIM applicatie en server.
4.3.1.2 Rapportage Integratie
Rapportages moeten breed beschikbaar gemaakt kunnen worden. Deze moeten niet alleen beschikbaar zijn op de webpagina of pdf als interface gebruiken, maar ook via API te koppelen zijn aan de ServiceBus of ITSM systeem.
4.3.1.3 Role-based Gebruik
De PIM oplossing moet aansluiten op het role-based access van de HHS, en met name een volledig geautomatiseerde integratie hebben met de gekozen IAM oplossing binnen dit domein. Wat we willen voorkomen is dat we een situatie genereren waarin een persoon zichzelf moet controleren. En om die reden dat er in de basis een scheiding is tussen rollen van de controlerende oplossing.
De Rollen in het PIM systeem voor rapportage moeten minimaal zijn:
‘ PIM Gebruikers ‘ Dit is een beheerder van de Haagse ICT Dienst, of een functioneel beheerder van een van faculteiten.
‘ PIM Administrators ‘ Dit zijn de beheerders van het PIM systeem, diegene die de inrichting doen en het systeem draaiende houden.
‘ PIM Auditors ‘ Dit zijn de controleurs, die gebruikers en administrators kunnen controleren, wat ze waar hebben uitgevoerd binnen het ICT systeem.
4.3.1.4 Interfaces voor Beheerders
Om het benaderen van de beheeromgeving van de PIM oplossing zo flexibel mogelijk te maken moet deze voor de gebruikers (Admins controleurs e.d.) via verschillende interfaces en/of devices beschikbaar zijn. Dit moet zijn via een browser, tablet en smartphone. Deze interfaces moeten out-of-the-box beschikbaar zijn, en specifiek voor dat soort (werkplek, tablet, smartphone) device beschikbaar zijn.
4.3.1.5 Interface styling
De omgeving die gebruikt wordt om de PIM oplossing te benaderen moet eenvoudig te stijlen zijn naar de huisstijl van de Haagse.
4.3.1.6 Dashboard
De PIM oplossing moet een dashboard functie hebben, met een drag-and-drop functionaliteit. Waarbij beheerder van de PIM oplossing voor hun functie eenvoudig de juiste informatie gepresenteerd krijgen op het moment dat ze de oplossing gebruiken.
4.3.1.7 Groepen Gebruik
De PIM oplossing moet het gebruik van groepen ondersteunen, waarbij de rechten voor de groepen alleen beheerd kunnen worden vanuit de PIM oplossing, het moet geen verplichting zijn om te integreren met active directory. De groepen moeten bijvoorbeeld ook te koppelen zijn aan de IAM omgeving.
Rechten voor groepen moeten per groep in te stellen zijn. En gebruikers moeten lid kunnen zijn van meerdere groepen.
4.3.1.8 Folders en Files
De PIM oplossing moet gebruik maken van een herkenbare file en folder structuur (zoals in windows). Zodat data in verschillende folder geplaatst kan worden en specifieke rechten op die folders gezet kunnen worden betreffende hoe en wie deze benaderd mogen worden. Het doel is dat we door middel van deze structuur een representatie van onze organisatie i.c.m. onze te beheren omgeving krijgen.
Het zoeken van informatie binnen files en folder moet vergelijkbaar zijn met het gebruik van de Windows verkenner, zodat informatie binnen de PIM oplossing eenvoudig gevonden kan worden.
4.3.1.9 Wachtwoord management
De PIM oplossing moet via een remote oplossing wachtwoorden centraal en geautomatiseerd kunnen aanpassen van verschillende componenten waar administrators op actief zijn. Voorbeelden daarvan zijn Active Directory, VMware ESX, Oracle, SQL, Linux en Windows systemen en netwerkapparatuur zoals Cisco, HP en Citrix Netscalers.
De Wachtwoord historie van de PIM oplossing moet alle wachtwoord historie kunnen bijhouden om op basis van die waardes te kunnen:
‘ Terughalen indien er een ouder wachtwoord nodig (bijvoorbeeld bij een restore) is om een systeem of applicatie te gebruiken.
‘ Bepalen of er voldoende aanpassingen gemaakt worden met de wachtwoorden ten aanzien van de diverse regelgevingen die we hanteren bij de HHS.

4.3.1.10 Dagelijkse omgang met de Beveiligde data
De PIM oplossing van de HHS gaat de data beveiligen die aangemerkt wordt als data die onder de PIM oplossing komt te vallen. Voor het gebruik van deze beveiliging op deze data hebben we de volgende punten aandacht gevestigd.
‘ Het moet zeer eenvoudig zijn, voor gebruikers van het PIM systeem, om data met de juiste classificatie binnen de PIM oplossing van de HHS onder te brengen.
‘ Het aanmaken en beheren van (het instellen en toepassen van) de beveiliging op de geclassificeerde data moet eenvoudig zijn
‘ Het aanpassen van de beveiliging op de geclassificeerde data moet in bulk, en geautomatiseerd aan te passen zijn.
‘ De beveiliging van geclassificeerde data moet volgens templates kunnen. Zodat de PIM gebruikers de template kunnen gebruiken en de PIM admin de templates kunnen maken en publiceren.
‘ Gebruikers moeten geclassificeerde data eenvoudig binnen teams kunnen delen.
4.3.1.11 Eisen Beheer en Organisatie PIM
De volgende tabel bevat de eisen welke bij de PIM oplossing horen t.a.v. Beheer en Organisatie.
Notitie Omschrijving Eis
Eis.PIM.001 ‘ Beheer en Organisatie – Rapportage De PIM oplossing moet rapportages kunnen opleveren over alle data onderdelen van het systeem. Hierin moeten overzichten gemaakt kunnen worden van de PIM gebruikers en de data binnen de oplossing.
Eis.PIM.001 ‘ Beheer en Organisatie – Rapportage De rapportages moeten gebruikers kunnen worden als onderdeel van de verschillende compliance en regelgevingen. En als zodanig standaard aanwezig zijn, of eenvoudig in elkaar gezet kunnen worden binnen het systeem (configureerbaar).
Eis.PIM.001 ‘ Beheer en Organisatie – Rapportage De rapportage in specifieke vorm moet alle relevante data uitlichten t.a.v. het ‘ admin’ gebruik van de PIM oplossing. De noemen we de admin rapportage van het PIM systeem.
Eis.PIM.001 ‘ Beheer en Organisatie – Rapportage De admin rapportage moet niet gemanipuleerd kunnen worden door de admins van het systeem. Alleen de controleurs van het systeem mogen deze data zien.
Eis.PIM.001 ‘ Beheer en Organisatie – Rapportage De PIM oplossing moet minimaal de volgende gegevens kunnen opgeven.
‘ Welke gebruikers de PIM oplossing gebruiken
‘ Welke beveiligingstemplates er zijn gemaakt en hoe deze worden gebruikt.
‘ Welke afwijkingen beveiligingstemplates hebben ten opzichte van de verschillende wet- en regelgevingen
‘ Welke gebruikers bij welke beveiligde data kunnen en wanneer ze dit hebben gedaan.
Eis.PIM.001 ‘ Beheer en Organisatie – Rapportage De PIM oplossing moet free format (custom) rapportages kunnen aanleggen over alle data die in de PIM database wordt opgeslagen.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Rapportage Integratie De rapportages moeten buiten het standaard kunnen mailen van rapportages naar een inbox. Ook een integratie laag hebben op systeem nivo. Hiermee wordt bedoelt dat er een integratie via webservices en API’s mogelijk moet zijn voor het uitwisselen van gegevens.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Role-Based De PIM oplossing moet role-based ingericht kunnen worden, en volledig kunnen integreren met de tooling binnen het IAM domein.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Role-Based De PIM oplossing moet voorkomen dat een persoon zichzelf moet controleren. Hiervoor moet het ‘4-eye’ principe gebruikt worden.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Role-Based De Rollen in het PIM systeem voor rapportage moeten minimaal zijn:
‘ PIM Gebruikers ‘ Dit is een beheerder van de Haagse ICT Dienst, of een functioneel beheerder van een van faculteiten. Deze gebruikers rol moet verder uitgediept kunnen worden met specifieke taken gekoppeld aan een gebruiker of groep.
‘ PIM Administrators ‘ Dit zijn de beheerders van het PIM systeem, diegene die de inrichting doen en het systeem draaiende houden. Deze admin rol moet verder uitgediept kunnen worden met specifieke taken gekoppeld aan een gebruiker of groep.
‘ PIM Auditors ‘ Dit zijn de controleurs, die gebruikers en administrators kunnen controleren, wat ze waar hebben uitgevoerd binnen het ICT systeem.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Interface Beheer De PIM oplossing moet een webbased beheer interface hebben. En kunnen volstaan met 1 enkele installatie van de webserver. Zodat updates en aanpassingen op een plek uitgevoerd kunnen worden.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Interface Beheer De PIM oplossing moet een tablet interface hebben, dus geoptimaliseerd voor het gebruik met tablets.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Interface Beheer De PIM oplossing moet een smartphone interface hebben, dus geoptimaliseerd voor het gebruik met smartphone applicaties. Voor het uitvoeren van enkele basis beheertaken.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Styling De PIM oplossing moet doormiddel van het maken van een thema en CSS styling aan te passen zijn naar de huisstijl van de Haagse Hogeschool
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Dashboard De Pim oplossing moet een beheerder en gebruikers interface hebben die als de werkplek fungeert voor de toegewezen taken voor die gebruiker. Deze dashboards moeten gevuld kunnen worden met widgets, waardoor er een flexibele oplossing ontstaat voor het toekennen en verwijderen van data en informatie die bij een bepaalde rol hoort.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Groepen gebruik De PIM oplossing moet groepen kunnen voorzien:
‘ Gebruikers moeten lid kunnen zijn van 1 en/of meerdere groepen
‘ Rechten moeten op groepen gezet kunnen worden
‘ Groepen moeten beheerd kunnen worden vanuit de PIM oplossing
‘ Groepen moeten eventueel gekoppeld kunnen worden aan AD
‘ Groepen moeten beheerd kunnen worden vanuit de IAM oplossing, door bijvoorbeeld te koppelen over een api of ldap.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Files en Folders De PIM oplossing moet een heldere structuur kunnen presenteren. Deze moet net zo herkenbaar zijn zoals de bekende file en folder structuur van Windows.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Files en Folders De PIM presentatie structuur moet in te delen zijn naar de organisatie en werkwijze van de HHS en Dienst ICT. Scheidingen moeten kunnen worden aangebracht tussen bijvoorbeeld Linux, Windows en applicatie beheerders.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Files en Folders De PIM oplossing moet rechten kunnen toepassen op de folders, zodat de beveiliging van de data onder die folder specifiek kan worden ingericht naar die eisen en wensen.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Files en Folders De PIM oplossing moet een een goede en makkelijke zoek en vind functie hebben, die alle de relevantie informatie laat zien.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Wachtwoord Management De PIM oplossing moet de wachtwoorden kunnen bijhouden en terughalen van alle systemen en applicaties die we koppelen aan de PIM oplossing.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Dagelijkse omgang met beveiligde data Het moet zeer eenvoudig zijn, voor gebruikers van het PIM systeem, om data met de juiste classificatie binnen de PIM oplossing van de HHS onder te brengen.
‘ De PIM Oplossing moet de data kunnen onderbrengen in het PIM systeem door middel van een copy-paste actie

Eis.PIM.001 ‘ Beheer en Organisatie ‘ Dagelijkse omgang met beveiligde data Het aanmaken en beheren van (het instellen en toepassen van) de beveiliging op de geclassificeerde data moet eenvoudig zijn.
‘ De PIM oplossing moet een zelfde structuur en interface gebruiken om voor individuele stukken data, danwel voor gegroepeerde data de beveiliging in te stellen.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Dagelijkse omgang met beveiligde data Het aanpassen van de beveiliging op de geclassificeerde data moet in bulk, en geautomatiseerd aan te passen zijn.
‘ De PIM oplossing moet snel een eenvoudig, bijvoorbeeld door een selectievakje aan te klikken bij de presentatie van een overzicht in de tool, een selectie kunnen maken.
‘ Deze selectie moet met 1 commando (of klik) de beveiligde data kunnen voorzien van een andere beveiliging.
Eis.PIM.001 ‘ Beheer en Organisatie ‘ Dagelijkse omgang met beveiligde data De beveiliging van geclassificeerde data moet volgens templates kunnen. Zodat de PIM gebruikers de template kunnen gebruiken en de PIM admin de templates kunnen maken en publiceren.
‘ De PIM oplossing moet template beheer hebben voor het aanmaken van de beveiliging voor data of stukken van data.
‘ Admins moeten template kunnen maken, gebruikers niet
‘ Gebruikers moeten de template kunnen gebruiken
‘ Gebruikers moeten verplicht gesteld kunnen worden om een template te gebruiken.

Eis.PIM.001 ‘ Beheer en Organisatie ‘ Dagelijkse omgang met beveiligde data Gebruikers moeten geclassificeerde data eenvoudig binnen teams kunnen delen.
‘ De PIM oplossing moet beveiligde data kunnen delen tussen personen en binnen teams.

Tabel 2, Specifieke Eisen PIM Beheer en Organisatie
4.3.2 Integratie
In dit hoofdstuk zetten we de uitgangspunten uiteen voor het Privileged Identity Management gedeelte in het IAM domein. Integratie gaat over hoe een PIM oplossing moet integreren (b.v. qua veiligheid) binnen de omgeving waar de tool draait, waar de gebruikers van de oplossingen mee te maken krijgen, en hoe technologie??n gebruikt moeten worden t.a.v. de bovenstaande punten.

4.3.2.1 Authentiseren bij PIM met SAML
De PIM oplossing moet zich kunnen opstellen als ISP (Identity Service Provider). En met gebruik van het SAML protocol verbinden aan een IdP (Identity Provider) van de gebruikers. Hiermee kunnen de gebruikers van de PIM oplossing gebruik maken van hun eigen identity.
4.3.2.2 Browsers
De PIM oplossing moet benaderbaar zijn via de meest gangbare webbrowsers. En moet een additionele plug-in gebruiken (PIM plug-in) voor die browser(s), zodat de wachtwoorden die nodig zijn om bij websites in te loggen bij de PIM oplossing blijven. En niet in de browsers eigen functionaliteit of andere plug-ins worden opgeslagen. De PIM plug-in zal dan automatisch de gebruikersnaam en wachtwoord invullen in de webpagina’s die kenbaar zijn gemaakt in met de PIM oplossing.
De PIM oplossing moet de opgeslagen data in een browser van een gebruiker kunnen wissen. Zodat wachtwoorden en historische data worden verwijderd na een bepaalde tijd en bij het afsluiten van de browser. Additionele maatregelen bij de instellingen voor de browser. zoals de functie voor het opslaan van wachtwoorden uitgeschakeld moeten worden.
4.3.2.3 Aanloggen op Operating systemen en Applicaties
Gebruikers die onder de PIM oplossing komen te vallen, moeten vanuit hun eigen werkplek op een operating systeem (RDP, PuTTY, VPN, FTP en andere remote access tools) beheer taken kunnen uitvoeren.
De PIM oplossing moet het aanloggen op dat ‘target’ systeem voor de betreffende persoon kunnen uitvoeren, hierdoor hoeft de gebruiker geen gebruikersnaam en wachtwoord van dat operating systeem in bezit te hebben.
Hiermee automatiseren en centraliseren we het veilig verbinden en aanloggen met operating systemen en applicaties voor gebruikers met meer dan normale ‘user’ rechten.
4.3.2.4 Proxy voor Secure Shell verbindingen
Er zullen oplossingen zijn waarbij de gebruikers een SSH verbinding willen opzetten tussen de gebruiker en een applicatie of systeem welke onder de PIM oplossing valt. In dit geval moet de PIM oplossing een SSH proxy functie beschikbaar stellen. In samenwerking met het netwerkbeheer worden dan deze sessies door de PIM oplossing gestuurd.
De PIM oplossing kan op dit moment de sessie controleren, zoals het aanloggen op een applicatie of server binnen de PIM oplossing, alsmede ook de sessie volgen en deze informatie opslaan voor later gebruik en onderzoek.
4.3.2.5 Sessie Recording
De PIM oplossing moet de sessie van de gebruiker, van het systeem waarop hij/zij aanlogd en welke onder de PIM oplossing valt, kunnen opnemen en opslaan in een video formaat, alsmede het loggen van alle commando’s die ingevoerd worden, kunnen opslaan.
Deze opgenomen en opgeslagen data moet vervolgens automatisch gekoppeld worden bij de beveiliging van de data van het betreffende systeem of applicatie.
De ‘recording data’ mag alleen door bepaalde (gescheiden) rollen binnen de PIM oplossing ingezien worden. Deze data wordt voor bepaalde tijd bewaard en moet ook weer automatisch verwijderd kunnen worden. Dit omdat deze data kan vallen onder bepaalde wet en regelgevingen die gelden voor onderwijsinstellingen.
4.3.2.6 Siem, Splunk en Syslog
Aangezien de het overgrote deel van de SIEM (bv splunk) oplossingen Syslog ondersteunen, moet de PIM oplossing standaard een Syslog formaat ondersteunen om data (audit data en log’s) die we voor analyse willen en moeten opvangen.
De PIM oplossingen moet ook een bepaalde hoeveelheid data zelf kunnen opslaan, bij verstoringen tussen de SIEM en PIM oplossing, zodat er zo klein mogelijke gaten in de analyse ontstaan.
4.3.2.7 Remote Scripts
Binnen de beveiligings configuratie van een target systeem welke onder de PIM oplossing valt, moeten powershell scripts uitgevoerd kunnen worden voor taken, die starten en lopen in situaties zoals;
‘ Voordat een persoon of systeem op het doelsysteem inlogd, kan het wenselijk zijn de logging en auditing vanaf dat moment op hoog wordt gezet.
‘ Nadat een persoon of systeem is uitgelogd. Een voorbeeld in dit geval is als er een localuser wachtwoord is aangepast en de services zou moeten stoppen en starten, of logging moet worden verlaagd naar normaal nivo.
De Remote Scripting moet derhalve uitgevoerd kunnen worden met de eisen die gelden binnen de PIM oplossing, en moeten rechtstreeks kunnen inhaken in het PIM systeem. Deze zijn bijvoorbeeld de controle op de scripts en hoe deze worden uitgevoerd.
4.3.2.8 API (web services)
De PIM oplossing wordt zo veel mogelijk geautomatiseerd, en operaties daarin moeten vanuit andere processen aangeroepen kunnen worden. De PIM oplossing moet derhalve alle operaties via API beschikbaar kunnen stellen aan andere oplossingen, zoals bijvoorbeeld een ESB, een API management systeem. Een must have in deze API integratie is de manier waarop de PIM oplossing integraal onderdeel is van de IAM oplossing.
Aangezien de IAM oplossing door processen gestuurd kan worden, kan met het gebruik van API’s de PIM tool onderdeel worden van de IAM oplossing.
4.3.2.9 Eisen Integratie

Notitie Omschrijving Eis
Eis.PIM.001 ‘ Integratie ‘ Authenticatie De PIM oplossing moet SAML ondersteunen, en;
‘ Zichzelf als ISP kunnen opstellen.
‘ Gebruikers van Haagse PIM moeten met een HHS identity kunnen inloggen.
Eis.PIM.001 ‘ Integratie ‘ Browser De PIM oplossing moet:
‘ Gangbare Browsers ondersteunen
‘ Een eigen plug-in voor die browsers leveren, zodat er PIM beheer i.s.m. de browsers geleverd kan worden.
‘ Eventuele Cache en historische data kunnen wissen en dit van afstand kunnen uitvoeren.
‘ Controleren of de juiste instellingen bij die browser gebruikt worden, daar melding van kunnen maken, en eventueel het gebruik van de PIM oplossing kunnen onderbreken.
‘ Wachtwoorden kunnen uitwisselen met webpagina’s voor PIM gebruikers, voor webpagina’s die onder de PIM oplossing vallen.

Eis.PIM.001 ‘ Integratie – Aanloggen op Operating systemen en Applicaties De PIM oplossing moet het aanloggen op ‘target’ van gebruikers die onder de PIM oplossing vallen kunnen faciliteren:
‘ PIM Gebruikers moeten vanuit hun eigen werkplek kunnen aanloggen op doelsystemen zonder dat zij de wachtwoorden of gebruikersnamen weten waarmee zij aanloggen.
Eis.PIM.001 ‘ Integratie ‘ Proxy voor Secure Shell verbindingen De PIM oplossing moet verbindingen kunnen faciliteren, en koppelen met de IAM oplossing, om beheer te kunnen uitvoeren op target systemen. De PIM oplossing moet:
‘ Kunnen fungeren als SSH proxy systeem
‘ SSH verkeer i.s.m. de firewall kunnen verwerken voor het beheer op de target systemen binnen de PIM oplossing.
‘ Het SSH verkeer kunnen authentiseren bij de IAM oplossing
‘ Het SSH verkeer kunnen autoriseren binnen de PIM oplossing
‘ Het SSH verkeer kunnen monitoren en loggen voor audit, compliance en onderzoeken.
Eis.PIM.001 ‘ Integratie ‘ Sessie Recording De PIM oplossing moet sessie opnames kunnen toepassen wanneer een PIM gebruiker verbinding maakt en werkzaamheden uitvoert op een target systeem. De PIM oplossing moet:
‘ De sessie kunnen opnemen in een gangbaar video formaat
‘ De ingevoerde commando’s kunnen loggen
‘ De opgenomen data van commando’s en schermvideo automatisch kunnen koppelen aan de beveiligingsconfiguratie van een target systeem.
‘ Deze data alleen beschikbaar stellen voor een bepaalde groep personen die deze dat kunnen inzien voor onderzoek. Waarbij deze personen niet de zelfde rechten hebben als normale PIM gebruikers.
‘ Deze opgenomen data ook weer automatisch kunnen verwijderen om zo mee te werken aan wet en regelgevingen voor deze data.
Eis.PIM.001 ‘ Integratie ‘ SIEM / Splunk De PIM oplossing moet minimaal het syslog formaat ondersteunen voor het loggen van data welke gebruikt gaat worden in een SIEM.
‘ Het formaat syslog moet ondersteund worden.
‘ De logging moet voor een bepaalde tijd binnen het eigen systeem opgeslagen kunnen worden.
‘ De logging moet direct geschreven kunnen worden in de bestaande syslog omgeving van de haagse hogeschool.
Eis.PIM.001 ‘ Integratie ‘ Remote Scripting De PIM oplossing moet het draaien van scripts, voor systemen die onder de PIM oplossing vallen, op doelsystemen kunnen beheren.
‘ Scripts moeten gekoppeld kunnen worden aan de beveiligingsconfiguratie van een doelsysteem.
‘ Scripts moeten gestopt/gestart kunnen worden vanuit het PIM systeem.
‘ Loggen en voortgang (succes, failure, stappen etc) over het uitvoeren van de scripts moet in de loggen van de PIM oplossing opgevangen kunnen worden.
Eis.PIM.001 ‘ Integratie ‘ API De PIM oplossing moet alle operaties die de oplossing kan uitvoeren via een API beschikbaar maken.
‘ Via de API moet de oplossing taken kunnen uitvoeren.
‘ Via de API moet de oplossing informatie kunnen opleveren

Tabel 3, Specifieke Eisen PIM Integratie

4.3.3 Compliance
Binnen de PIM oplossing wordt op de volgende wijze omgegaan met relevante wet- en regelgeving, om zodoende te ondersteunen van de verschillende compliance regels.
De PIM oplossing gaat er niet voor zorgen dat de Haagse Hogeschool compliant wordt, maar zorgt ervoor dat de verschillende wet- en regelgevingen en afspraken in het PIM systeem voor de scope van het PIM systeem, geplaatst kunnen worden. En dat het PIM systeem rapporteert ten opzicht van de PIM compliance templates.
De PIM oplossing moet rekening houden met de volgende wetgevingen.
‘ Wet op het Hoger onderwijs en Wetenschappelijk onderzoek
‘ Wet Bescherming Persoonsgegevens
‘ Archiefwet
‘ Auteurswet
‘ Wet Computercriminaliteit
De PIM oplossing moet rekening houden met de volgende verordeningen, overige richtlijnen en afspraken
‘ Europese Verordening Privacy
‘ Integriteitscodes voor wetenschappelijk onderzoek
‘ Studielink afspraken
‘ Aansluitvoorwaarden SURFfederatie / SURFnet.

Templates
De PIM oplossing gaat de verschillende wet en regelgevingen ondersteunen. In de uitvoering betekend dit dat de PIM oplossing gebruik gaat maken van compliance templates die door beheerders van de PIM oplossing eenvoudig geconfigureerd kunnen worden.
Deze templates moeten dan gekoppeld kunnen worden aan de beveiliging configuratie van een doelststeem.
En ter controle moeten de template gemeten kunnen worden qua:
‘ De CRUD operaties op de templates
‘ De status van het template ten opzichte van de verschillende wet en regelgevingen kunnen weergeven en rapporteren
‘ De status van de verschillende doelsystemen ten opzichte van de template kunnen weergeven.

4.3.3.1 Eisen Compliance

Notitie Omschrijving Eis
Eis.PIM.001 ‘ Compliance ‘ Wet en Regelgevingen De PIM oplossing moet de vigerende wet en regelgevingen kunnen ondersteunen en bijdragen aan het compliant zijn van de HHS.
De PIM oplossing moet geautomatiseerd de doelsystemen kunnen voorzien van compliance templates.
Beheerders van de PIM oplossing moeten deze template eenvoudig kunnen inregelen via een beheerders interface.
Gebruikers van de Pim oplossing mogen de templates niet kunnen veranderen.
Eis.PIM.001 ‘ Compliance ‘ Templates De Templates binnen de PIM oplossing moeten:
‘ De CRUD operaties op de templates kunnen bijhouden en uitvoeren.
‘ De status van het template ten opzichte van de verschillende wet en regelgevingen kunnen weergeven en rapporteren
‘ De status van de verschillende doelsystemen ten opzichte van de template kunnen weergeven.
‘ De templates moeten via de API benaderd kunnen worden.
Tabel 4, Specifieke Eisen PIM Compliance

4.3.4 Inrichting
De inrichting van de PIM oplossing wordt specifiek gemaakt in de betreffende PSA voor de keuze van een product (of producten), in deze sectie zijn uitgangspunten opgesteld die worden gebruikt in de betreffende PSA.
4.3.4.1 Backups
De PIM Oplossing moet met zeer regelmatige interval backups kunnen maken van de gegevens die het systeem nodig heeft om te kunnen functioneren.
Het doel van het maken van back-ups van de PIM oplossing is niet om het operating systeem en de tools te kunnen restoren, maar wel de tool instellingen en inrichting, en daarnaast de beveiligingsconfiguratie van de verschillende doelsystemen, logging, scripts en templates.

4.3.4.2 Database Mirror
De PIM oplossingen slaat haar informatie op in een database, deze database moet hoog beschikbaar zijn, en daardoor in een active-active sessie beschikbaar gemaakt worden aan de applicatie server van de PIM oplossing. De mirror optie van de database server moet worden ondersteund, voor;
Beschikbaarheid ‘ Verhoging van de databeschikbaarheid
Continu??teit ‘ voor het maken van Real-time backups, tijdens en voor veranderingen
Performance ‘ Het kunnen ondersteunen van een clustering van de applicatie server met meerdere databases.
Een van de eisen is dat de beveiligingsinformatie niet langer dan xx minuten per jaar, niet beschikbaar is voor de PIM applicatie, deze exacte nummers worden in de PSA voor de toolkeuze, en implementatie PSA meegenomen als uitgangspunten.
4.3.4.3 Exports
De PIM oplossing moet export kunnen maken van beveiligingsinformatie die bij een overgang naar een nieuwe omgeving, ge??mplementeerd kan worden. Enkele voorbeelden zijn;
‘ Een upgrade van dezelfde oplossing, waarbij een in-place upgrade niet mogelijk is.
‘ Een overgang naar een applicatie binnen de PIM oplossing, waarbij er gewisseld wordt van applicatie leverancier
‘ Een calamiteit, waarbij de export gebruik moet worden om beveiligingsinformatie te importeren.
4.3.4.4 Clustering
De PIM oplossing moet het clusteren van de applicatie kunnen ondersteunen, dit doordat we er bijvoorbeeld loadbalancers voor willen kunnen zetten.
4.3.4.5 Eisen Inrichting

Notitie Omschrijving Eis
Eis.IAM.PIM.001
Eis.IAM.PIM.002
Tabel 3, Specifieke Eisen IAM Infrastructuur

4.3.5 Werken als Administrator

4.3.5.1 Authentiek en Exclusiviteit
Het PIM systeem moet kunnen garanderen dat op het moment dat een admin op een doelsysteem is ingelogd, de administrator alleen is ingelogd op dat doelsysteem. Daardoor heeft de administrator de garantie dat de aanpassingen die gelogd worden op het moment dat de admin is ingelogd ook door de betreffende admin gemaakt zijn.
4.3.5.2 PIM Account zoeken
Het PIM systeem moet kunnen zoeken naar accounts die aangemerkt worden als Privileged. De systemen die de HHS onder het PIM gaat laten vallen moeten automatisch onderzocht op accounts die voldoen aan de bepalingen van de PIM Accounts.
Deze Accounts moeten vervolgens automatisch worden ondergebracht en gekoppeld worden aan de beveiligingsconfiguratie en accountmanagement lifecycle, behorende bij die accountsoort.
4.3.5.3 PIM Blijvend Bijwerken
De PIM oplossingen is een omgeving die qua beheer vraagt dat deze regelmatig en juist wordt bijgewerkt. Dit vanwege de systeemveiligheid en omdat er veel andere systemen, applicaties en data afhankelijk zijn van de PIM oplossingen. De Pim oplossing moet makkelijk onderhoudbaar zijn en nagenoeg geen impact hebben op de systemen, data en applicaties die onder de PIM oplossing vallen.
De PIM administrators moeten regelmatig worden geschoold met de functies van het PIM systeem welke worden ingezet bij de Haagse.
4.3.5.4 ongeautoriseerde wachtwoord aanpassingen
Het PIM systeem moet kunnen voorkomen dat er ongeautoriseerde wachtwoord aanpassingen plaatsvinden. Hiermee wordt bedoelt dat de PIM oplossing in de lead moet zijn van aanpassingen van wachtwoorden voor toegang op systemen, data en applicaties die onder de PIM oplossing vallen.
Het Pim systeem moet wachtwoorden kunnen;
‘ Ontdekken dat ze zijn aangepast, zonder tussenkomst van de PIM oplossing
‘ Terugdraaien naar een wachtwoord, zoals in de PIM eisen is vastgelegd
‘ Rapporteren dat het is gebeurd, herhaaldelijke aanpassingen en aangeven wanneer dit niet meer onder controle is.
4.3.5.5 Service Accounts
De PIM oplossing moet alle admin en service accounts onder beheer gaan nemen, van alle data, systemen en applicaties die onder de PIM oplossing komen te vallen.
Met als netto resultaat dat een centrale en eenduidige manier is die de meest sterke beveiliging en controle kan bieden voor het gebruik en beheer voor deze accounts. Hierdoor kan door een selecte groep PIM beheerders eenvoudig toegang worden geregeld voor personen die admin achtige autorisatie nodig hebben op de informatie onder PIM. En blijven de PIM beheerders in controle van de zaken die daarlangs gebeuren.
4.3.5.6 Controle PIM op remote omgevingen
Over het internet, bij de IaaS provider of een applicatie hosting partij
4.3.5.7 Red Envelope Procedure
De PIM oplossing moet een ‘Red Envelope’ procedure ondersteunen. Dit is een vooraf goedgekeurd proces waarin verschillende personen samen geautoriseerd worden om controle over het systeem te verkrijgen. De red envelop procedure geeft deze personen volledig controle over de PIM oplossing.

4.3.5.8 Admin Security Feedback
De Pim oplossing moet de administrators automatisch en met regelmaat voorzien van security feedback. Over hoe zij het PIM systeem gebruiken en banaderen. De reden hiervoor is dat normaal gedrag van personen is om het werken gemakkelijker te maken. Maar in bepaalde gevallen
Moet blijven draaien, maar wel awareness voorzien, inzage in hoe het gebruikt wordt.
4.3.5.9 Eisen Werken als Administrator

Notitie Omschrijving Eis
Eis.IAM.PIM.001
Eis.IAM.PIM.002
Tabel 6, Specifieke Eisen PIM Administratie

4.3.6 Beveiliging Oplossing
4.3.6.1 Encryptie
4.3.6.2 Hashing
SHA-512
4.3.6.3 Two-factor
4.3.6.4 IP restricties
4.3.6.5 Wachtwoord generation en eisen
4.3.6.6 Radius authenticatie
4.3.6.7 Dubbele encryptie van beveiliging data
Nu kan het zijn dat er beveiligingsdata een extra encryptie laag nodig heeft, om verschillende redenen. Zoals de controle op manipulatie van toets uitslagen, of vertrouwelijke gesprekken tussen een Decaan en een Student.
4.3.6.8 Eisen Beveiliging van de oplossing

Notitie Omschrijving Eis
Eis.IAM.PIM.001
Eis.IAM.PIM.002
Tabel 3, Specifieke Eisen IAM Infrastructuur

4.4 Uitgangspunten Beheer

4.5 Gebruikersbehoeften

4.5.1 Wie en IAM
Hierin beschrijven we het bekende gremium van stakeholders en wat hun motivatie is om IAM functionaliteiten in te gaan zetten.

4.6 Eisen IAM
Er heeft binnen de hogeschool geen uitgebreide analyse plaatsgevonden van eisen die specifiek betrekking hebben op Identity en Access management. Er is wel binnen de dienst IT afstemming geweest met een aantal ontwikkelaars en beheerders. Daarnaast is gekeken naar relevante eisen zoals geformuleerd in de algemene norm voor informatiebeveiliging NEN-ISO/IEC 27001:2005 [2], welke een vertaling is van de internationale ISO/IEC norm. Deze laatste biedt een volledig overzicht van relevante eisen die in het algemeen worden gesteld aan informatiebeveiliging van organisaties. We hebben daarom een selectie van uitspraken uit dat document gemaakt die relevant zijn voor de samenstelling van de IAM domein architectuur.
Notitie Omschrijving Eis
Spe.eis.001 Informatie moet worden geclassificeerd met betrekking tot de waarde, wettelijke eisen, gevoeligheid en onmisbaarheid voor de organisatie.
Spe.eis.002 Taken en verantwoordelijkheidsgebieden moeten worden gescheiden om gelegenheid voor onbevoegde of onbedoelde wijziging of misbruik van de bedrijfsmiddelen van de organisatie te verminderen.
Spe.eis.003 Beleid en procedures moeten worden ontwikkeld en ge??mplementeerd om informatie te beschermen die een rol speelt bij de onderlinge koppeling van systemen voor bedrijfsinformatie.
Spe.eis.004 Activiteiten van gebruikers, uitzonderingen en informatiebeveiligingsgebeurtenissen moeten worden vastgelegd in audit-logbestanden. Deze logbestanden moeten gedurende een overeengekomen periode worden bewaard, ten behoeve van toekomstig onderzoek en toegangscontrole.
Spe.eis.005 Logfaciliteiten en informatie in logbestanden moeten worden beschermd tegen inbreuk en onbevoegde toegang.
Spe.eis.006 Activiteiten van systeemadministrators en systeemoperators moeten in logbestanden worden vastgelegd.
Spe.eis.007 Er moet toegangsbeleid worden vastgesteld, gedocumenteerd en beoordeeld op basis van bedrijfseisen en beveiligingseisen voor toegang.
Spe.eis.008 Er moeten formele procedures voor het registreren en afmelden van gebruikers worden vastgesteld, voor het verlenen en intrekken van toegangsrechten tot alle informatiesystemen en -diensten.
Spe.eis.009 De toewijzing en het gebruik van speciale bevoegdheden moeten worden beperkt en beheerst.
Spe.eis.010 De toewijzing van wachtwoorden moet met een formeel beheerproces worden beheerst.
Spe.eis.011 De directie moet de toegangsrechten van gebruikers regelmatig beoordelen in een formeel proces.
Spe.eis.012 Gebruikers moeten goede beveiligingsgewoontes in acht nemen bij het kiezen en gebruiken van wachtwoorden.
Spe.eis.013 Gebruikers moeten bewerkstelligen dat onbeheerde apparatuur afdoende is beschermd.
Spe.eis.014 Gebruikers moet alleen toegang worden verleend tot diensten waarvoor ze specifiek bevoegd zijn.
Spe.eis.015 Er moeten geschikte authenticatiemethoden worden gebruikt om toegang van gebruikers op afstand te beheersen.
Spe.eis.016 Automatische identificatie van apparatuur moet worden overwogen als methode om verbindingen vanaf specifieke locaties en apparatuur te authentiseren.
Spe.eis.017 De fysieke en logische toegang tot poorten voor diagnose en configuratie moet worden beheerst.
Spe.eis.018 Groepen informatiediensten, gebruikers en informatiesystemen moeten op netwerken worden gescheiden.
Spe.eis.019 Voor gemeenschappelijke netwerken, vooral waar deze de grenzen van de organisatie overschrijden, moeten de toegangsmogelijkheden voor gebruikers worden beperkt, overeenkomstig het toegangsbeleid en de eisen van bedrijfstoepassingen.
Spe.eis.020 Toegang tot besturingssystemen moet worden beheerst met een beveiligde inlogprocedure.
Spe.eis.021 Elke gebruiker moet over een unieke identificatiecode beschikken (gebruikers-ID) voor persoonlijk gebruik, en er moet een geschikte authenticatietechniek worden gekozen om de geclaimde identiteit van de gebruiker te verifi??ren.
Spe.eis.022 Systemen voor wachtwoordbeheer moeten interactief zijn en moeten bewerkstelligen dat wachtwoorden van geschikte kwaliteit worden gekozen.
Spe.eis.023 Het gebruik van hulpprogrammatuur waarmee systeem- en toepassingsbeheersmaatregelen zouden kunnen worden gepasseerd moet worden beperkt en moet strikt worden beheerst.
ISO/IEC 24760 controleren op aanvullende eisen
Wachtwoorden End-to-End encrypten.
Tabel 2, Specifieke eisen IAM
4.7 Eisen IAM

Notitie Omschrijving Eis
De Haagse IAM oplossing moet functies en diensten gaan bieden aan verschillende entiteiten, deze zijn:
‘ Haagse Gebruikers en Gebruikers groepen
‘ Organisaties, Federaties, Partners en Individuen
‘ Devices, Applicaties, Systemen en Netwerk elementen
‘ Objecten, zoals applicatie processen, content en data
De Haagse IAM oplossing moet de lifecycle van identiteiten veilig beheren;
Van de eerste aanvraag tot aan het verwijderen.
Bij het zoeken en uitwisselen van identity information, inclusief het veilig uitvragen en uitwisselen van deze informatie tussen verschillende domeinen.
De Haagse IAM oplossing moet de uitvoering en toepassing van de diverse richtlijnen voor audit, beheer en veiligheid van identity information, automatisch kunnen ondersteunen.
De Haagse IAM oplossing moet ondersteuning bieden voor applicaties en systemen die real-time en near real time uitwisseling van gegevens vereisen.
De Haagse IAM oplossing moet, onder bepaalde policy, assertion van anonieme identity information toe kunnen staan.
De Haagse IAM oplossing moet binnen het domein, en in haar eigen systeem, van de Haagse beveiligd gegevens kunnen uitwisselen.
De Haagse IAM oplossing moet buiten het Haagse domein, en buiten haar eigen systeem, beveiligd gegevens kunnen uitwisselen met andere IIP, ISP, IDP en RP’s.
De Haagse IAM oplossing moet self-service oplossingen bieden en ondersteunen, welke het gemakt dienen van gebruikers, zoals;
‘ Single sign-on naar verschillende applicaties.
‘ Voor ‘samengestelde’ services, denk aan vast-mobiel integratie
‘ De controle en afscherming van PII (personal identifiable information).
De Haagse IAM oplossing moet single sign-on bieden voor personen en systemen die aanloggen met Credentials die gekoppeld zijn aan mobiele en vaste device.
‘ Het moet mogelijk zijn om een mobiel device te gebruiken voor het single sign-on aanloggen op verschillende applicaties, data en of andere systemen.
De teksten bij de gewenste situatie uitgangspunten hebben eisen nodig on deze te ondersteunen. Deze zijn hier opgenomen
Life-cycle Management Eisen De Haagse IAM oplossing moet de nodige policies kunnen ondersteunen, uitvoeren en toepassen die horen bij het beheer van de identity information lifecycle. Dit zijn de processen, procedures en policies van het :
‘ Aanvragen van een Identity
‘ Bewijs leveren en zoeken van identity information
‘ Enrolment van de Identity
‘ Wijzigen (CRUD) van identity information
‘ En uitschrijven van een identiteit.
Life-cycle Management – Enrollment proces en proofing Eis De Haagse IAM oplossing moet zeker stellen dat de claimed attributes zo bruikbaar zijn dat deze voldoende geschikt zijn. Zodat deze entity onderscheiden kan worden door middel van deze attributes voor toegang tot de doel entiteiten.
‘ De aanvragen van wie zijn of haar identity word vastgesteld is ook diegene die (of datgene dat) verbonden wordt die identity.
‘ Het moet niet mogelijk zijn dat een entity de vastgestelde identity kan verwerpen, en daarmee een authenticatie kan betwisten.
Life-cycle Management – Enrollment proces en proofing – Bruikbare Identity Information De Haagse IAM oplossing moet borgen dat identity information (attributes, credentials en Identifiers) alleen gebruikt kunnen worden na het succesvol doorlopen van het Enrolment en proofing proces door de betreffende entity.
Life-cycle Management – Enrollment proces en proofing – Bijwerken en uitvragen van credentials De Haagse IAM oplossing moet zorgen voor het beveiligd transport voor het token, van het originating punt tot aan de andere gegadigde. Zodat de confidentialiteit en integriteit geborgd zijn.

Life-cycle Management ‘ Updates en Onderhoud De Haagse IAM oplossing moet een veilige oplossing zijn voor het bewerken en opslaan van identity information data, en de status van die data kunnen bijhouden.
De Haagse IAM oplossing moet een veilige oplossing bieden voor het bijhouden van log informatie over aanpassingen die gemaakt worden op de identity information
De Haagse IAM oplossing moet periodiek controleren wat de status is van de data, en het proces van validatie controleren
De Haagse IAM oplossing moet periodiek de status van een identity controleren.
De Haagse IAM oplossing moet alle updates van identity informatie kunnen uitwisselen met alle applicaties, objecten en devices die deze informatie nodig hebben.
De Haagse IAM oplossing moet gebruikers in staat stellen identity information te updaten en verwijderen, en gebruikers op de hoogte te stellen als deze acties hebben plaatsgevonden.
De Haagse IAM oplossing moet identity information automatisch kunnen verwerken volgens de vigerende wet en regelgeving, zonder tussenkomst van de gebruiker.

Life-cycle Management ‘ Revoken / Intrekken

Tabel 3, Eisen IAM Tooling

4.8 Specifieke eisen IAM – Infrastructuur
In dit hoofdstuk worden de specifieke eisen t.a.v. van de IAM infrastructuur bepaald. Kan/zal gaan over hoe en waar de data benaderd mag worden en door wie.
Items die hier komen te staan zijn niet-functionele eisen (beschikbaarheid, performance, inrichting, management) dus allerlei items die van belang zijn om de IAM applicatie/tool heen, om de functionele kant goed te kunnen laten fungeren. Deze kunnen dan worden overgenomen in de PSA, samengebracht worden met de functionele eisen, en specifiek worden gemaakt. Met als resultaat een implementeerbare oplossing voor dat project.
Notitie: Een Architectuur techniek die daarbij gebruikt kan worden is operationeel modeleren (IBM Global Services Method techniek voor het inrichting van applicaties op infrastructuren). De op te leveren producten zijn een PSA en een HLD.
TODO: infra principes en eisen voor gesprek met Senioren

Notitie Omschrijving Eis
Eis.IAM.INF.001
Eis.IAM.INF.002
Tabel 3, Specifieke Eisen IAM Infrastructuur

4.9 Specifieke Eisen IAM – Informatie Classificatie

To do: Specifieke Eisen Informatie Classificatie overleggen met Rosanna

Notitie Omschrijving Informatie Classificatie Eis
Eis.IAM.ICL.001
Eis.IAM.ICL.002
Tabel 4, Specifieke Eisen IAM Informatie Classificatie

5. Architectuur
5.1 Richtlijnen

Burcht Metafoor verwerken met model, IAM plotten op de BSB in een tabel.

5.1.1 IAM Technieken
In dit onderdeel beschrijven we welke technologie??n we gaan gebruiken binnen het IAM Domein. Denk hierbij aan protocollen (Oauth, Saml) en ook het managen van cookies, php of html, of http header. Onderdeel

Afbeelding 4, IAM Technieken Diagram

5.1.1.1 Gebruik van SAML
Opnemen in de richtinggevende uitspraken:
1. We gebruiken SAML v2.0 voor interne en externe communicatie over de plaatsgevonden authenticaties.
2. Als er saml v2.0 beschikbaar is, maar ook andere protocollen, gaan we eerst saml v2.0 gebruiken.
3. Als er geen saml v2.0 mogelijk is voor communicatie dan kunnen we bij uitzondering ook saml1.0 of ws-federation data uitwisseling opzetten. Hiervoor gebruiken een multi-protocol systeem, en is een additionele goedkeuring nodig van de lijn architect.
Voor het gebruik van SAML: Maak hier een matrix van uitspraken, eisen en richtinggevende uitspraken
‘ Gebruikers willen niet meer inloggen bij de (geld niet alleen voor SaaS) applicatie als zij zichzelf ook al bij de Haagse bekend hebben gemaakt (SSO).
‘ Haagse ICT wil geen gebruikers account informatie en gegevens opslaan bij de SaaS applicatie leverancier, of in de applicatie.
‘ Op het moment dat we een SaaS applicatie willen gebruiken, maar geen additionele account management binnen die applicatie willen bijhouden zetten we SAML in om de applicatie een vertrouwens relatie met het IAM systeem van de Haagse op te laten zetten.

5.1.1.2 Het gebruik van SAML binnen de Haagse
Het gebruik van SAML in de omgeving van de Haagse is weergegeven in dit hoofdstuk. De verschillende rollen die nodig zijn op het moment dat we saml gebruiken en wie er welke data uitwisselen en koppelen is benoemd.
‘ Voor het gebruik van SAML binnen de Haagse gaan we een ‘ cirle of trust’ opzetten. Deze circle is een overeenkomst tussen IdP’s en ISP’s. Waarbij er minimaal 1x een IdP en 1x een ISP aanwezig moeten zijn. Er kunnen wel meerdere ISP met 1 IdP een circle opzetten, of meerdere IdP’s en ISP’s.
‘ Binnen deze circle of trust worden afspraken gemaakt over het versturen en uitwisselen van de berichten tussen de IdP en de ISP. En hoe er gecommuniceerd wordt (use cases).
De volgende tabel is een overzicht van de uitwisselingen van data/informatie en rollen bij het gebruik van een SAML implementatie.
Van IAM Framework ISP IdP
Haagse IAM Framework v
SaaS Applicatie provider v
Opslag van Identity profile v
Beantwoord de Identity profile uitvraag v
Beheerd de beschermde resources (appl.) v
Voert de authenticatie uit v
Wisselen authenticatie data uit v v
Delen metadata v v
Geeft de assertion (bewering) information uit. Over de geauthentiseerde gebruikers v
Bepaald, op basis van de aangeboden bewering, de autorisatie van de gebruiker v
Maakt een mapping van de account attributes van de IdP, op de accounts bij de ISP. v
Tabel 5, SAML Inrichting Rollen en lidmaatschap

5.2 Relatie met uitgangspunten

6. Roadmap en open issues
6.1 Roadmap

Verbeteren van de Huidige Situatie
‘ Organisatie en bedrijfskant
‘ Focus op gebruikers handelingen t.b.v. Selfservice
‘ Automatisering ter ondersteuning van gebruikers (selfservice) processen
‘ Informatie voorziening bijwerken
Opzetten van een IAM Framework
‘ Aanschaf van benodigde product en ondersteuning
‘ Trainen HHS Medewerkers
‘ Privileged IdM Opzetten en inregelen
o Opzetten onderdelen (IdM,AM,PIM) van het IAM framework, integreren in de omgevingen Windows, Linux en Applicaties, incl IaaS provider.
‘ Vervangen producten en diensten opzetten
o Het ‘On Par’ komen met de huidige dienstverlening
o Applicaties die nu niet zijn aangesloten, op de IAM diensten aansluiten.
‘ Beheer van het IAM Framework en de diensten inregelen
o Informatie management en voorziening, monitoring (functioneel en non-functioneel), Service management, beveiliging, onderhoud.
Embedden van IAM diensten
‘ Binnen de Dienst ICT en de applicatie Functioneel Beheerders
‘ Implementatie verbeterde IAM diensten aan bedrijfsapplicaties en informatie voorziening.
‘ Controle en beveiliging verbeteren.
‘ Ontwikkeling nieuwe IAM diensten (onderzoek op de IAM externe markt en haar roadmap, hoe deze op waarde te schatten?).
Op basis van de eerste inschatting verwacht ik dat er een x.x FTE aan technisch en applicatie beheer nodig is. Vraag is waar het functionele beheer komt te liggen en hoe deze wordt ingericht. Controle op compliance en security is nog niet onderzocht ten opzichte van de uitgangspunten.

6.2 Open issues
7. Bijlage I: IT-architectuurkaders
Op 21 februari 2012 heeft het College van Bestuur versie 1.0 van de IT-architectuurkaders formeel vastgesteld. De eerste versie van de IT-architectuurkaders werden vooral afgeleid uit uitspraken in bestaande IT-beleidsdocumenten. Ze bestaan uit een set van algemene uitgangspunten die beschrijven waar de kaders op zijn gebaseerd, en een set van algemene principes die fundamentele keuzen beschrijven rondom de inrichting van IT.
7.1 Uitgangspunten
De volgende tabel is een overzicht van de algemene uitgangspunten die gelden voor de informatie-infrastructuur zijn beschreven in de (bron documenten) IT-architectuurkaders [1] en afgeleid uit uitspraken in bestaand IT-beleid.
Notitie Omschrijving Uitgangspunt
Alg.uit.001 Gebruikers moeten altijd en overal toegang hebben tot hun gegevens en applicaties
Alg.uit.002 Gebruikers moeten eigen apparatuur kunnen gebruiken
Alg.uit.003 Gebruikers moeten voor onderzoek en onderwijs zelf software kunnen installeren om mee te experimenteren
Alg.uit.004 Studenten, docenten en externen moeten de informatievoorziening beleven als een rijke en moderne voorziening
Alg.uit.005 Concern brede informatie moet integraal beschikbaar zij
Alg.uit.006 De informatie-infrastructuur moet duurzaam en effici??nt zijn ingericht
Alg.uit.007 De integriteit en vertrouwelijkheid van informatie moet worden bewaakt
Alg.uit.008 Serviceniveaus moeten expliciet zijn beschreven en worden bewaakt
Alg.uit.009 De informatie-infrastructuur moet maximaal gestandaardiseerd zijn
Alg.uit.010 De informatie-infrastructuur moet toegankelijk zijn voor iedereen
Tabel 6, Algemene Uitgangspunten
7.2 Algemene principes
De algemene principes voor de informatie-infrastructuur zijn ook beschreven in de IT-architectuurkaders:
Notitie Omschrijving Principe
Alg.pri.001 Applicaties zijn webgebaseerd en worden anders gevirtualiseerd
Alg.pri.002 Experimenten vinden plaats gescheiden van de standaardomgeving
Alg.pri.003 Er wordt alleen ondersteuning geboden op software en apparatuur van de hogeschool
Alg.pri.004 Generieke applicaties lopen maximaal ‘?n versie achter
Alg.pri.005 Gegevens worden onderhouden in de bronapplicatie
Alg.pri.006 Applicaties met concernbrede informatie ontsluiten deze via op standaarden gebaseerde interfaces
Alg.pri.007 De identity management omgeving is leidend voor alle authenticaties
Alg.pri.008 Gegevens worden dicht bij de bron beveiligd
Alg.pri.009 Applicaties voor de interne bedrijfsvoering maken gebruik van bewezen oplossingen
Alg.pri.010 IT systemen worden gestandaardiseerd en hergebruikt binnen de gehele organisatie
Alg.pri.011 Alle noodzakelijke integraties vinden plaats conform de hogeschool standaarden
Alg.pri.012 Websites conformeren aan de webrichtlijnen voor toegankelijkheid
Tabel 7, Algemene Principes IT Informatie Architectuur
Het zevende principe (alg.pri.007) heeft specifiek betrekking op IAM en is als volgt gespecificeerd:
‘ De identity management omgeving is leidend voor alle authenticaties
De integriteit en vertrouwelijkheid van informatie moet worden bewaakt. Daarvoor is een eenduidige registratie van alle digitale gebruikers (identiteiten) nodig. Een IAM omgeving biedt die administratie en biedt daarnaast de mechanismen om ervoor te zorgen dat deze ook kunnen gebruikt kunnen worden door doelomgevingen (applicaties), gebruikers (intern en extern) en controle en management functies. Daarnaast biedt een dergelijke omgeving mechanismen die het mogelijk maken dat gebruikers maar eenmalig hoeven in te loggen.
Implicaties zijn:
‘ Er is een centrale IAM omgeving waarin alle identiteiten en rollen worden beheerd
‘ De IAM omgeving propageert gegevens over identiteiten en rollen naar alle doelsystemen
‘ Alle authenticaties maken gebruik van de identiteitsinformatie zoals deze wordt beheerd in de IAM omgeving

Dit hoofdstuk beschrijft de uitgangspunten die gelden voor identity en access management. Deze uitgangspunten zijn ontleend aan de IT-architectuurkaders [1] en aangevuld met eisen die specifiek aan de IAM worden gesteld. Voor deze laatste is een selectie van relevante eisen uit de algemene NEN-ISO/IEC 27001:2005 norm voor informatiebeveiliging gemaakt [2].

/Einde van het Document