Author Archives: joeldebruijn

IDM bij de Onderwijsgroep Tilburg

Vandaag ben ik te gast bij Surf voor de bijeenkomst “IAA in het MBO”. Mijn collega Merijn van der Schoot presenteerde daar onze IDM (Identiteiten Management) oplossing. Deze regelt accounts en toegang voor ‘joiners’, “movers” en “leavers”. Anderen noemen dat in-, door- en uitstroom. 😉

Hij start vanuit trots, terecht natuurlijk. 😉

Hij schetst de performance: In 15 minuten kan je alles, de pas van een student is in 1 seconde actief, de pasfoto wordt in 1 minuut doorgezet en onze administratie sluit er 100% op aan.

We kwamen niet zomaar op dit punt. IT voorzieningen geven aan personen, kent veel hobbels. Dat uitte zich in veel “Ja maar …”: Wij zijn bijzonder, wij hebben externen, wij hebben mensen niet geadministreerd, wij hebben gasten etc.

Behalve sleutelen aan het IDM is er ook twee jaar gewerkt aan een goed HR-proces. Om vragen op te lossen zoals “Waarom staan mensen onverwacht op de stoep zonder account?”, “Waarom is HR langzaam”, “Wie zijn onze gasten” etc.

Beleidsmatig hadden we natuurlijk onderleggers nodig voor gebruikersnamen, gastaccounts, test- en beheeraccounts etc. Spin-off was verder dat HR ook ontlast werd met ‘gedoe’, aangezien we self-service invoerden.

Voorbeeld van een foutje: Stel een directeur vergeet een contractverlenging te accorderen, vervolgens gaat een account dicht. De medewerker ontdekt dat omdat hij niet kan inloggen en belt de servicedesk. Daar krijgt hij te horen dat z’n contract nog niet verlengd is … Nu wil je dat niet structureel natuurlijk, dus voortaan gaan we aan de voorkant rappelleren. We gaan dan overigens niet handmatig accounts open zetten etc. Maar in de keten wordt in het HR systeem de knop omgezet en een kwartier later werkt alles weer.

Merijn schetst net als hier de visie van een ‘sectorvoorziening’, wat zich uit in een standaard aansluiting.

Red Spider

Vandaag ben ik te gast bij Surf voor de bijeenkomst “IAA in het MBO”. In de derde sessie neemt Roy Dusink ons me in de ontwikkelingen met Red Spider. Recent blogde ik hier daarover. Zelf hecht ik veel waarde aan het samen optrekken met andere instellingen, gezien de kostenbesparing voor dit soort randvoorwaardelijke voorzieningen.

Red Spider is een gebruikersvereniging met nu 11 leden. Mijn instelling is ook lid, actief mag ik wel zeggen. Technisch is het gebaseerd op NetIQ. Al onze identiteit gegevens die we binnen ons applicatielandschap moeten koppelen of extern moeten doorgeven aan de federaties (Entree en SurfConext) zitten hier in.

Uitdagingen:

Op dit moment ontbreekt Access-management in de oplossing.
De gebruikservaring van authenticatie mag beter.
Nieuwe wet en regelgeving (AVG).
De komst van ECK-id.

De visie die de vereniging heeft bevat termen als: naadloze toegang, Privacy-by-Design, Regie op gegevensverstrekking. Waar we van af moeten, vind ik zelf ook, is directe cloud-koppelingen en daarmee tegelijk account-informatie uitwisselen.

Uiteindelijk is het een oproep om gezamenlijk op te trekken als MBO’s om voor identiteiten en toegang een generieke voorziening te krijgen. Niet zozeer alleen voor de leden van de vereniging maar voor allemaal. Daarbij samen optrekkend met Surf en Kennisnet natuurlijk.

Algemene ontwikkelingen IAA bij SURF & Kennisnet

Vandaag ben ik te gast bij Surf voor de bijeenkomst “IAA in het MBO”. In de tweede sessie lopen we de ontwikkelingen langs, HP Köhler neemt ons mee.

MBO is een beetje een aparte sector omdat iedereen aangesloten is op 2 federaties. Entree voor digitale leermiddelen en SurfConext voor identiteiten. Beiden hebben een federatief centraal hub model waarbij de school de identity provider is. Technisch is het een implementatie van de SAML standaard.

Het IAA proces zoals HP dat ziet:

Identificatie: Juridische vaststellen van de identiteit.
Registratie: Administratie van de functie.
Authenticatie: Is hij/zij wie hij zegt te zijn?
Autorisatie: toegang krijgen tot gegevens of functionaliteiten.
Gebruik

De uitgangspunten voor IAA zijn:

Gebruiker centraal en privacy-vriendelijk, met consent.
Gemakkelijk in gebruik en beheer.
Veilig, schaalbaar en betaalbaar.

In het tweede deel praten we door over eduID. Zijn we net ECK-Id aan het doen met nummervoorziening, moeten we al weer nadenken over de opvolger of doorontwikkeling. 😉

Dat lokte dan ook veel vragen uit. Het eerste is slechts een pseudoniem in mijn ogen, dat als attribuut aan een identiteit hangt zodat leveranciers niet weten welke leerling/student het betreft. Het tweede is meer een leven-lang-leren oplossing. Zit dan ook nog in de verkennende fase. De verkenning uit zich bijvoorbeeld in:

Praktische pilot is die van de Edubadge en micro-credentials. Hierin zitten vooral HO/WO instellingen en één MBO. Top van Deltion.
Het eduMij concept: een persoonlijk en levenslang educatie en ontwikkeldossier. Naar analogie van MedMij. Opdrachtgever van eduMij is de ‘informatiekamer’ (MinOCW en de onderwijssectoren).

Zelf ben ik het meest nieuwsgierig naar eduMij, mits de gegevens zich bij de lerende zelf bevinden en niet in één centrale silo.

Wet Digitale Overheid

Vandaag ben ik te gast bij Surf voor de bijeenkomst “IAA in het MBO”. Aangezien ik onlangs wel eens wat geschreven heb over IAA (Identificeren, Authenticeren, Autoriseren) was ik benieuwd naar deze dag.

Barbera Veltkamp opent met de lezing over de Wet Digitale Overheid (WDO) en de betekenis voor dienstverleners in het onderwijs. In deze context praten we dan over ‘inloggen’ bij de overheid. Normaliter horen we het vaakst van MinOCW, maar deze wet loopt natuurlijk langs alles, vandaar vanuit BZK.

Het WDO regelt op hoofdlijnen de toegang tot elektronische dienstverlening middels elektronische identificatie (eID). Voor de overheid zelf natuurlijk maar ook voor publieke dienstverleners. Inloggen bij de overheid met een nieuwe versie van DigiD dus.

Als we inzoomen op WDO:

Uitgangspunten: Veilig, betrouwbaar, gebruiksvriendelijk, eenduidig en beschikbaar.
Dienstverleners moeten dit eID accepteren en daarnaast moet het andere sectorale middelen om in te loggen overbodig maken.
De wet gaat NIET over: interne IT en identificatieprocessen.

De reikwijdte van WDO voor onderwijs is nu beperkt tot hoger onderwijs. Op termijn gaat het echter ook voor MBO gelden. ‘Tegenprestatie’ is dan wel dat scholen gaan betalen als ze meedoen.

Het resultaat is dat dienstverleners, scholen dus, verplicht moeten aansluiten op meer middelen. Het rijtje is dan:

eHerkenning voor rechtspersonen (organisaties/bedrijven).
eIDAS voor EU identificatiemiddelen
DigiD voor de eigen overheid en publieke taken
Private middelen

Alle technische voorzieningen moeten overigens klaar zijn als de wet ingaat. In 2019 behandelt het parlement deze. Op 1 juli gaat de wet in, maar nog niet voor MBO. OCW voert gesprekken over de vertaling naar het onderwijs (saMBO/MBO-Raad). BZK rolt de ICT voorzieningen uit.

Eigen bedenkingen:

Ik ben blij dat voor de MBO sector de invoering gefaseerd gaat. Ben benieuwd naar de komende ervaringen van HO/WO. De wet biedt ruimte uit te breiden naar andere typen organisaties, als iedereen daar aan toe is. Klinkt redelijk, Barbara.
IRMA werd vermeld, maar de veiligheid van deze systemen op nationale schaal vereist een hoger volwassenheidsniveau ‘ondanks wat sommige hoogleraren zeggen’. Ik snap dat iets parallel kan lopen: echt innoveren aan de ene kant en iets implementeren, in productie brengen aan de andere kant.
Allemaal nuttige voorzieningen, maar wat ik nog niet kan inschatten is hoe deze ontwikkeling zich verhoudt tot meer ‘decentrale’ oplossingsrichtingen.
Ik hoop dat we met 60 MBO instellingen niet allemaal per stuk het wiel moeten uitvinden om hier op aan te sluiten. Iedereen met z’n historisch gegroeide applicatie-landschapje, dat ook voor mijn eigen organisatie geldt.

Beleid voor IAA: Kwaliteit

Deze blog is de laatste in de reeks over beleid, uitgangspunten en principes voor identificatie, authenticatie en autorisatie. De zesde is hier te vinden.

Het schrijven van beleid voor IAA zette mij aan het denken. Wanneer is ‘beleid’ goed? Zonder compleet te willen zijn, beleid leek mij goed als:

Het goede doelen dient:
Wat een goed doel is bepaal ik natuurlijk niet zelf of alleen, maar is gekoppeld aan onze strategische doelen als organisatie.
Het concreet is:
Dat blijf ik een uitdaging vinden omdat concreetheid snel kan leiden tot te ‘gedetailleerd’, te ‘smal’, te ‘waan-van-de-dag’ of te ‘operationeel’. Uiteindelijk poog ik om generieke beginselen op te schrijven, die nog uitwerking qua inrichting en dagdagelijks werk behoeven. Terwijl ze wel handreikingen bieden voor anderen om besluiten weloverwogen te nemen.
Het realistisch is:
Ik zoek altijd de balans tussen ‘dogmatisch’ en ‘pragmatisch’ zijn. Beleid mag best een ‘wettisch’ tintje hebben (Gij zult …), maar als je niet uitkijkt diskwalificeer je de huidige situatie compleet. Andersom, als het te pragmatisch is, dan vertrek ik alleen vanuit de huidige situatie en accepteer ik teveel onwenselijke situaties.
Dus voor mij mag beleid best prikkelen en kan het verandering in gang zetten, mits er dan ook maar oog is voor de verandering zelf.

Voor het IAA beleid hebben we daarom gekeken naar:

Geschiktheid

Dit beleid is getoetst en akkoord bevonden door de Functionaris Gegevensbescherming. Daarnaast is het ter review aangeboden bij ons Architectenplatform en een vertegenwoordiging van Functioneel Beheerders. Tot slot heeft het College van Bestuur het aangenomen als bestuursbesluit.

Koppelbaarheid

Beleid moet niet rondzweven als het ware en is op zijn beurt weer onderlegger voor andere documenten. Deze relaties expliciet benoemen helpt in een later stadium weer de borging van het beleid.

Aan wetgeving:
Dit beleid geeft uitvoering aan de algemene verordening gegevensbescherming (EU-AVG- 2016/679).
Aan strategische en tactische documenten:
- Het IBP Beleid en Normenkader.
- Onze Richtlijn voor gebruikersnamen: volgens welke conventies we een uniek account bepalen.
- De richtlijn voor wachtwoorden: welke eisen we aan sterke wachtwoorden stellen.
- Het Reglement “Verantwoord Netwerkgebruik”
- De procedure “Autorisatie tot netwerk en kernsystemen”.
Aan operationele documenten:
- Beheerdocument per kernsysteem: deze bevat een overzicht van de autorisatiematrix van het specifieke kernsysteem en het beheerproces hierop (en nog veel meer natuurlijk).
- De werkinstructies van de processen.

Sommige van deze documenten zijn er nog niet of zijn niet volledig. Beleid schrijven is leuk maar leidt dus altijd tot nog meer werk, merk ik zo.

Onderhoudbaarheid

Dit beleid wordt jaarlijks onderhouden met de volgende cyclus.

Oktober: Peiling stand van zaken realisatie.
December: Evaluatie met stakeholders.
Februari: Concept nieuwe versie bepalen.
April: Vaststelling nieuwe versie.

Beleid voor IAA: Borging

Deze blog is de zesde in de reeks over beleid, uitgangspunten en principes voor identificatie, authenticatie en autorisatie. De vijfde is hier te vinden. Hieronder volgen onze afspraken om te zorgen dat het beleid wordt nageleefd. Het veronderstelt dat een organisatie werkt met proces-eigenaren, procesbegeleiders, een beveiligingsfunctionaris en architecten.

Omgaan met uitzonderingen

Applicatie-eigenaren moeten expliciet toestemming verlenen bij ondergenoemde autorisatie-aanvragen:

Toekennen van rechten die breder zijn dan behorende bij de procesrol of functiebeschrijving.
Toekennen van rechten die afwijken van het ontwerp van het proces of de applicatie.
Aanbrengen van mutaties in de autorisatiematrices, in zoverre deze niet door de leverancier aangepast worden bij nieuwe versies van de applicatie.

De functioneel beheerder:

contacteert de applicatie-eigenaar.
legt deze goed- of afkeuring vast (voor controle en verantwoording).
voert de autorisatie door in de applicatie (voor zover dit niet geautomatiseerd plaatsvindt).

Omgaan met verbeteringen

De balans vinden tussen strikte toegang tot gegevens en het praktisch kunnen uitvoeren van iemands rol is een uitdaging. Ontevredenheid over autorisaties ontstaat soms vanuit de beleving dat ze het dagdagelijkse werk in de weg zitten, tot onnodig vertraging leiden of anderszins de productiviteit in de weg zitten. De volgende vragen helpen de situatie analyseren:

Kan iemand echt zijn werk niet doen of mist de medewerker de vaardigheden of kennis?
Kan iemand zijn werk niet doen omdat de rol die hierbij hoort in het plaatselijke team anders wordt ingevuld dan de standaard?
Zijn de autorisaties niet correct ingericht of mist het systeem functionaliteit?

Om tot overeenstemming te komen worden de volgende stappen voorgesteld:

De functioneel beheerder en procesbegeleider maken samen de afweging.
Indien nodig wordt het proces aangepast en stelt de proces-eigenaar deze vast.
Indien nodig worden de autorisaties aangepast en stelt de systeem-eigenaar deze vast.
Als overeenstemming niet mogelijk is analyseert het architectenplatform het probleem en stelt de oplossingsrichting vast.

Controle

Voor applicaties met een BIV classificatie score hoger dan “Midden” op de onderdelen integriteit en vertrouwelijkheid geldt dat de applicatie-eigenaar verantwoordelijk is voor het onafhankelijk laten controleren (minimaal 2 maal per jaar) van het volgende:

Zijn de autorisaties juist toegekend?
Is er een goedkeuring van de lijnmanager voor alle accounts die voorzien zijn van risicovolle autorisaties?
Is er een goedkeuring van de applicatie-eigenaar voor alle accounts die afwijken van het ontwerp?
Zijn de autorisatie matrices juist: Is de actuele autorisatiematrix zoals overeengekomen met de applicatie-eigenaar. De applicatie-eigenaar is verplicht de autorisatieprocedure te laten toetsen door de beveiligingsfunctionaris.

Het is de verantwoordelijkheid van de locatiebeheerder om 1x jaar de rapportage van uitgegeven (digitale) sleutels en de rol gebaseerde toegang te controleren en voor te leggen aan de beveiligingsfunctionaris.

Rapportage

De controle en verantwoording van autorisaties wordt zoveel als mogelijk ondersteund door rapportages. Dit zijn praktische overzichten wie met welke rol toegang heeft tot een applicatie. Periodiek worden deze aan leidinggevenden voorgelegd ter controle.

Consolidatie

Na de controle worden autorisaties geconsolideerd. Autorisaties zonder verantwoording (verleend buiten de autorisatie matrices en zonder fiat van leidinggevende) worden ingetrokken.

Mijn volgende en laatste blog zal gaan over de kwaliteit van het beleid.

Beleid voor IAA: Rollen

Deze blog is de vijfde in de reeks over beleid, uitgangspunten en principes voor identificatie, authenticatie en autorisatie. De vierde is hier te vinden.

Er zijn meerdere belanghebbenden betrokken bij het IAA proces. Dit kan bekeken worden vanuit drie perspectieven: het proces, het systeem en het team. Daarnaast zijn er ook rollen voor beleid en controle daar op. De uitwerking hieronder verondersteld dat een organisatie werkt met proceseigenaren en -begeleiders (een soort inhoudelijke expert).

Inrichting van het proces

Tijdens het inrichten van het proces wordt er bepaald welke activiteiten uitgevoerd moeten worden. Dit is afhankelijk van het doel van het proces, wet- en regelgeving en praktische aspecten. De volgende twee rollen zijn daar van belang, voor autorisaties.

De proces-eigenaar: Deze is verantwoordelijk voor het vaststellen van het proces en daarin te beleggen proces-rollen.
De proces-begeleider: Beschrijft de taken, bevoegdheden, verantwoordelijkheden van elke rol. Handelingen in detail worden beschreven in de werkinstructies. Deze dienen later als basis voor het bepalen welke functionaliteiten in een systeem gebruikt moeten kunnen worden.

Inrichten van het systeem

Tijdens het inrichten van het systeem wordt bepaald welke onderdelen geconfigureerd moeten worden. De volgende twee rollen zijn daar van belang, voor autorisaties:

De systeem-eigenaar: Deze is verantwoordelijk voor de applicatie inrichting en de bijbehorende autorisaties vereist voor proces-rollen en koppelingen.
De functioneel beheerder: Bundelt de rechten in een systeem tot een systeemrol en volgt procedures conform het inrichting- of beheerdocument voor die applicatie. De rechten op functionaliteiten en specifieke data worden vastgelegd in de autorisatiematrix. Op verzoek van leidinggevenden worden deze rollen aan specifieke medewerkers toegekend.

Inrichten van het team

Tijdens het inrichten van het team wordt bepaald wie welke werkzaamheden verricht. Dit is afhankelijk van de samenstelling van het team en de aanwezige competenties. De volgende twee rollen zijn daarbij van belang, voor autorisaties:

De lijnmanager: Deze is verantwoordelijk voor het fiatteren van aanvragen voor de toekenning van formele rollen en rechten aan zijn/haar medewerkers. De leidinggevende is goed op de hoogte wat deze autorisaties inhouden en welke risico’s er zijn. De leidinggevende neemt bij het fiatteren de regels in acht die de applicatie-eigenaar heeft gesteld.
De medewerker: Weet vanuit zijn rol wat hij/zij moet doen en weet als gebruiker van het systeem welke functionaliteiten ter beschikking staan. Deze is daarom verantwoordelijk voor het juiste en veilige gebruik van de aan hem/haar toegekende autorisaties.

We gebruiken voor het bovenstaande het volgende model:

Steeds is aangegeven welke ‘pet’ je op hebt, wie de hamer heeft (dus de besluiten neemt), wie de pen heeft (dus uitvoert, inricht of beschrijft) en in welke documenten dit terugkomt.

Hoge resolutie is hier te vinden.

Inrichten van de controle

Tijdens het controle werk wordt gepeild in hoeverre alle uitgegeven autorisaties voldoen aan het beleid:

De Informatiemanager: Is verantwoordelijk voor dit IAA beleid en de jaarlijkse verversing ervan.
Coördinator Informatiebeveiliging: Geeft advies voor de applicatie inrichting en toetst deze aan de autorisatie-procedure. Daarnaast voert hij de controles uit.

Mijn volgende blog zal gaan over het borgen van het beleid.

Beleid voor IAA: Principes voor Autorisatie

Deze blog is de vierde in de reeks over beleid, uitgangspunten en principes voor identificatie, authenticatie en autorisatie. De derde is hier te vinden. De specifieke applicaties die hieronder worden vermeld hebben natuurlijk te maken met ons applicatielandschap. Die varieert natuurlijk van organisatie tot organisatie.

Autorisatie beperkt (terecht) de toegang tot informatie, echter soms is dit onwenselijk vanuit het oogpunt van transparantie. We onderscheiden daarom verschillende gebieden met elk hun eigen principes.

Extern publiek informeren: Openbaarheid

De informatie is openbaar en in te zien zonder autorisatie. Het gaat dan om informatie over onze opleidingen ten behoeve van werving, algemene informatie voor ouders en bedrijven, verantwoording over onze publieke taak en webcare. Deze is beschikbaar zonder dat bekend is wanneer een individu deze precies nodig heeft of wil opzoeken. Hij of zij kan deze ten allen tijde ophalen.

Intern publiek informeren: Transparantie

De autorisatie is gebaseerd op het lidmaatschap van een hoofdgroep (leerling, student, medewerker). Het gaat dan om ‘intranet-informatie’, zoals nieuws, evenementen, documenten van algemeen belang, rapportages of besluiten worden gedeeld met alle medewerkers.

Informele samenwerking: Zelf delen

De autorisatie is gebaseerd op het delen van informatie door een naaste collega. Dit kan op eigen initiatief zijn of iemand die hiervoor door zijn leidinggevende is aangewezen. Doorgaans bestaat dit uit Office documenten in een SharePoint Teamsite, een bibliotheek of Yammer (interne social media). De toegang mag laagdrempelig en ad-hoc zijn, en is niet centraal geregeld. Uitzonderingen hierop zijn bijvoorbeeld teamsites voor examens.

Formele samenwerking: Toegang vanuit je rol

De autorisatie is gebaseerd op iemands rol in een proces. Het beheer is centraal geregeld en vastgesteld. Dit geldt voor werken in kernsystemen zoals Afas, EduArte, Proquro, TopDesk en GP Untis. Hier gelden de principes:

Need-to-know, Time-to-know, Place-to-know

Personen krijgen alleen toegang tot functionaliteiten en informatie voor zover dit strikt noodzakelijk is voor het uitvoeren van de aan hen opgedragen werkzaamheden. In de praktijk mogen autorisaties geen belemmering vormen in het kunnen uitvoeren van een functie of procesrol, maar zijn ook geen vanzelfsprekendheid.

Personen krijgen niet langer dan strikt noodzakelijk toegang tot functionaliteiten en informatie voor het uitvoeren van de aan hen opgedragen werkzaamheden, in overeenstemming met hun rol. Autorisaties komen te vervallen bij het wijzigen van functie. Als dit niet automatisch kan, dan dient een kernsysteem hier een beheerproces voor in te richten.

Alle formele rollen worden vastgelegd in een autorisatie-matrix door de functioneel beheerder. In de praktijk is er een autorisatie matrix per applicatie waarin wordt vastgelegd wie (rol en/of context van de identiteit) wat mag (rol/autorisatie). De autorisatiestructuur van een kernsysteem sluit aan bij de goedgekeurde procesbeschrijvingen.

Gebruikers respecteren bij de toegang tot persoonsgegevens de privacy van de betrokkenen conform het IBP beleid en Privacy Reglement. Als toegang tot een ruimte ook toegang tot informatie geeft dan geldt:

De toegang tot ruimtes is gebaseerd op je rol en gekoppeld aan een zoneringsplan.
De locatie beheerder ziet toe op de uitgifte en inname van zowel fysieke als digitale sleutels.

Functie-scheiding

Dit geldt zowel voor het beheer van de autorisaties als het gebruik ervan.

De aanvrager van autorisaties en de uitgever ervan zijn verschillende functionarissen (vier ogen principe)
De samenstelling van rollen/rechten combinaties en de toekenning van autorisaties is dusdanig dat er sprake is van passende functiescheiding voor de eindgebruiker.

BIV classificatie

Een rollen/rechten combinatie is risicovol als een gebruiker (strikt) vertrouwelijke gegevens kan raadplegen of handelingen kan uitvoeren waarmee aanzienlijke schade kan worden oplopen (financieel, tijd, imago, continuïteit). Daarom worden alle informatie houdende applicaties van de onderwijsinstelling aan de BIV classificatie onderworpen (Beschikbaarheid, Integriteit of Vertrouwelijkheid).

Applicaties met een score hoger dan “Midden” op het onderdeel “Vertrouwelijkheid” van de BIV kennen risicovolle rollen, rechten en/of combinaties daarvan. De applicatie-eigenaar stelt in samenwerking met de proceseigenaar vast welke deze zijn. Deze worden schriftelijk vastgelegd voor controle en verantwoording.

Mijn volgende blog zal gaan over de rollen voor IAA.

Beleid voor IAA: Principes voor Authenticatie

Deze blog is de derde in de reeks over beleid, uitgangspunten en principes voor identificatie, authenticatie en autorisatie. De tweede is hier te vinden.

Proportionaliteit

Hoe gevoeliger de gegevens zijn hoe meer we ons er van willen overtuigen dat de persoon werkelijk is wie hij zegt dat hij is. De laagste vorm van authenticatie gebruikt een sterk wachtwoord (conform de richtlijn voor wachtwoorden). Gevoelige (persoons)gegevens worden met een extra maatregel beveiligd (meervoudige authenticatie). Het gebruik van een wachtwoord is dan gecombineerd met bijvoorbeeld een pas, token, sms of een vingerafdruk. Ook bij het gebruik van accounts voor beheer en risicovolle rollen in applicaties met een score “Hoog” op het onderdeel ‘Vertrouwelijkheid’ van de BIV classificatie, wordt gebruikt gemaakt van meervoudige authenticatie.

Voor applicaties in het huidige applicatielandschap die geen meervoudige authenticatie ondersteunen maar dat wel nodig hebben wordt een alternatief gezocht of er worden aanvullende maatregelen getroffen om een gewenst beveiligingsniveau te bereiken.

Gebruiker is de bron

Het wachtwoord is verbonden aan de gebruiker zelf. Wij slaan deze niet zelf op noch mogen onze leveranciers hierover beschikken.

Single sign-on: 1x inloggen

Personen loggen niet apart in op onderdelen van de ICT infrastructuur van de onderwijsinstelling. Na inloggen op de ICT infrastructuur vindt authenticatie op het applicatielandschap verder zoveel mogelijk op de achtergrond plaats ter bevordering van het gebruiksgemak en productiviteit.

Single sign-on brengt een beveiligingsrisico met zich mee, maar weegt niet op tegen het bevorderd gebruiksgemak. Om het beveiligingsrisico te mitigeren worden maatregelen geformuleerd in de “Richtlijn voor wachtwoorden”. Verder worden in het BYOD-beleid en Reglement Verantwoord ICT-gebruik gebruik- en beveiligingsrichtlijnen opgenomen om het risico van gebruikersgedrag te minimaliseren.

Single-Sign-On vereist dat externe systemen koppelbaar zijn. Als dat niet het geval is, geldt het “Comply, or explain” principe. Er wordt dus aan de leverancier gevraagd te voldoen aan onze principes en zijn systeem koppelbaar te maken of anders uitleg te geven. Ons Architectenplatform adviseert in deze, om erna met belanghebbenden een afgewogen besluit mogelijk te maken.

Verantwoord gedrag

Elke gebruiker is verantwoordelijk voor het adequaat afschermen/beveiligen van zijn authenticatiemiddelen (account/wachtwoord, schoolpas, Yubikey). Een goede beveiliging met technische maatregelen vormt natuurlijk een basis, maar het effect ervan gaat grotendeels verloren als men bijvoorbeeld wachtwoorden doorgeeft.

Handhaving van het wachtwoordbeleid

De “Richtlijn voor wachtwoorden” (separaat, tactisch document) voor accounts binnen de ICT infrastructuur van de onderwijsinstelling wordt technisch afgedwongen.

Beheer van de ICT infrastructuur

Authenticatie voor het beheer en services in de ICT infrastructuur vereist strikte beveiligingsmaatregelen. Deze worden continue geactualiseerd conform de standaarden voor beveiliging van de ICT infrastructuur.

Mijn volgende blog zal gaan over de principes voor Autorisatie.

Beleid voor IAA: Principes voor Identificatie

Deze blog is de tweede in de reeks over beleid, uitgangspunten en principes voor identificatie, authenticatie en autorisatie. De eerste is hier te vinden.

We verankeren onze identiteiten.

Het uitgeven van een digitale identiteit is altijd gebaseerd op een externe autoriteit die we vertrouwen:

De manieren voor digitale identificatie die wij zelf bieden (account) zijn verankerd in het tonen van een identiteitsbewijs zoals deze is uitgegeven door een overheid. Dit vindt plaats vóór het aanmaken ervan.
De middelen voor digitale identificatie die zijn uitgegeven door andere organisaties vertrouwen we indien deze zijn aangesloten bij dezelfde federaties als wijzelf. De eisen voor toegang tot de federatie dienen als waarborg.
De middelen voor digitale identificatie van geautomatiseerde processen (het domein van een server) zijn verankerd in het proces van certificering. Partijen die deze certificaten uitreiken kunnen dit alleen als ze voldoen aan de Telecommunicatiewet en aan specifieke eisen. De Autoriteit Consument en Markt ziet hier op toe en vormt zo een waarborg voor ons.

We onderhouden één Identiteit.

Een natuurlijke persoon heeft één identiteit. Het HR systeem (medewerker) of de deelnemersregistratie (cursisten, studenten en leerlingen) geldt als bronsysteem. Uitzonderingen kunnen gemaakt worden voor personen die zowel student als medewerker zijn.

Het aangewezen bronsysteem van een identiteit geldt als bron voor de levenscyclus. Zodra de persoon niet meer actief is bij de onderwijsinstelling wordt zijn/haar identiteit gedeactiveerd (incl. alle autorisaties). De bewaartermijn van (gedeactiveerde) identiteiten, accounts en autorisaties wordt bepaald door de applicatie-eigenaar in samenwerking met de proces-eigenaar. Wetgeving is hierin altijd leidend.

We onderhouden één account.

Een identiteit beschikt over één account voor onze ICT infrastructuur. Een uitzondering wordt gemaakt voor test-, beheer- en service-accounts, die echter wel te herleiden zijn naar een natuurlijk persoon of specifiek systeem.

Accounts voor applicaties worden geautomatiseerd aangemaakt en verwijderd. Voor risicovolle applicaties worden accounts direct gedeactiveerd. Indien dit niet geautomatiseerd kan, dan wordt dit conform een procedure handmatig ingeregeld.
Er worden geen ‘algemene’ accounts gebruikt, die niet gekoppeld zijn aan een persoon.

Context bepaalt autorisatie

De context van een identiteit bepaalt in eerste instantie de autorisatie. Voorbeelden zijn iemands functie en organisatieonderdeel, op basis waarvan basale autorisaties (account uitgifte en autorisaties binnen applicaties) worden toegekend. Naarmate er meer eigenschappen bekend worden (voor strikt organisatorische doeleinden), wordt het verlenen en muteren van autorisaties verder verfijnd en geautomatiseerd.

We gebruiken pseudoniemen in de educatieve contentketen

Om de persoonsgegevens van onze deelnemers te beschermen, als zij gebruik maken van digitaal lesmateriaal of digitale examens bij externe leveranciers, werken we op basis van pseudoniemen. Wij weten bij welke natuurlijke persoon het pseudoniem hoort, de leverancier echter niet.

Mijn volgende blog zal gaan over de principes voor Authenticatie.