Autorisatie

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:

  1. De functioneel beheerder en procesbegeleider maken samen de afweging.
  2. Indien nodig wordt het proces aangepast en stelt de proces-eigenaar deze vast.
  3. Indien nodig worden de autorisaties aangepast en stelt de systeem-eigenaar deze vast.
  4. 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: 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: Zeker weten wie wat mag

Afgelopen tijd heb ik samengewerkt met onze Functionaris Gegevensbescherming aan het IAA-beleid. Deze formuleert uitgangspunten en principes voor identificatie, authenticatie en autorisatie. Het bleek dat we best nauwkeurig mensen rechten geven binnen applicaties, maar zonder een onderlegger voor onze functioneel beheerders en zonder breed afgesproken standpunten. Komende blogs ga ik hier op in en deze is dus de eerste in de reeks.

Wat verstaan we onder IAA?

Identificatie, Authenticatie en Autorisatie zijn stappen in het proces voor toegangscontrole. Dit is het proces om toegang te krijgen tot ons netwerk, onze applicaties en functionaliteiten daarbinnen. Het ziet er op toe dat de juiste personen toegang hebben tot gegevens.

Identificatie

Identificatie is het kenbaar maken van de identiteit van een persoon of een systeem. Om de identiteit op een zinvolle manier te kunnen gebruiken, is het noodzakelijk dat elke toegepaste identiteit uniek is. In de regel gebeurt dat door aan iedere gebruiker van onze ICT-omgeving en aan elk geautomatiseerd proces een unieke gebruikersnaam toe te kennen.

Authenticatie

Authenticatie is het vaststellen van de juistheid van de opgegeven identiteit. Dat kan een persoon of systeem aannemelijk maken met:

  • Iets wat alleen jij kent (een wachtwoord).
  • Iets wat alleen jij hebt (een certificaat, een sleutel, een mobiel of token voor extra code, een pasje met een chip).
  • Iets wat alleen jij bent (biometrische kenmerken zoals vingerafdruk of iris).

Als een combinatie van bovenstaande manieren gebruikt wordt, dan spreekt men van sterke of meervoudige authenticatie. Idealiter wordt hier pas om gevraagd als er binnen een applicatie gevoelige gegevens opgeroepen worden of waardevolle transacties gedaan worden.

Bijvoorbeeld: het bekijken van een rooster van een student kan al na inloggen met alleen een wachtwoord, maar voor het bekijken van zijn begeleidingsdossier zou een extra code gevraagd worden. Dit wordt ‘step-up’ authenticatie genoemd.

Autorisatie

Autorisatie is het uitdelen van een recht op functionaliteit om met een set gegevens iets te doen: toegang om ze te lezen, te wijzigen of te beheren (het recht om rechten uit te delen). Bij dit proces hoort ook het muteren of intrekken van zo’n recht. In de praktijk worden deze rechten gekoppeld aan rollen en krijgt een individu een rol met de daarbij behorende rechten toegewezen.

Zie onderstaand model aan de hand van het motto: “Je identiteit kenbaar maken, aantonen en gebruiken.”

20181111IAAPosterLageResolutie

In hoge resolutie hier te downloaden.

Wat verwachten we van IAA nu en straks?

We verwachten nu al:

  • Dat IAA de vertrouwelijkheid van de informatie kan borgen en ervoor moet zorgen dat alleen de personen voor wie de informatie bedoeld is er toegang toe hebben. Hiermee wordt tevens het vertrouwen in de ICT-omgeving vergroot en in het geval van persoonsgegevens helpt het privacy realiseren.
  • Dat IAA beleid en de afgeleide richtlijnen gecontroleerde toegang tot applicaties en gegevens daarbinnen waarborgt. Soms impliceert dit ook toegangscontrole tot fysieke locaties (bijvoorbeeld het datacenter, ruimtes met netwerkcomponenten en stroomvoorziening, examenlokalen of de kantoren waar examens opgeslagen zijn).
  • Dat IAA hoge eisen stelt aan de houding en gedrag van onze medewerker.

We verwachten dat in de toekomst:

  • Het gebruik van pseudoniemen voor onze deelnemers toe zal nemen. Dit zijn lange reeksen karakters die uniek zijn per deelnemer en inschrijving. Als school weten wij welk pseudoniem bij welke deelnemer hoort. Externe partijen echter werken alleen met het pseudoniem zonder dat ze weten welke ‘persoon’ er achter zit. Tegelijkertijd hebben ze wel de zekerheid dat het een deelnemer van ons is. Deelnemers kunnen zo digitaal lesmateriaal gebruiken of examens maken zonder dat de leverancier ervan teveel persoonsgegevens krijgt.
  • We steeds strikter toezien op de naleving van het IAA-beleid. De bewustwording dat het onbeperkt gegevens verzamelen en koppelen negatieve gevolgen kan hebben voor een individu en dus de maatschappij, motiveert steeds meer om formeel om te gaan met IAA.
  • Dat we in breder verband meer diensten zullen leveren aan personen met een digitale identiteit van een andere organisatie. Nu doen we dat al voor externe studenten door ze te voorzien van wifi, middels Eduroam of ze in de regio op weg te helpen, middels Route35. Een ander voorbeeld is toegang tot onze publieke taken voor andere EU burgers.
  • Dat sterke authenticatie de standaard inlogmethode zal worden voor netwerktoegang en voor applicaties die geen ‘step-up’ authenticatie ondersteunen.

Scope van IAA

Dit beleid is van toepassing op alle toegang tot informatie. Doorgaans wordt informatie digitaal opgeslagen, maar dit beleid is ook van toepassing op papieren (analoge) informatie. De scope is daarom:

  • Alle applicaties en systemen van de onderwijsinstelling of diensten die informatie bevatten of transporteren. De applicatielijst zoals deze bij ons in TopDesk beheerd wordt middels de softwarekaarten geldt in deze als bron.
  • Alle ruimtes waar informatie bewaard wordt, aangezien soms fysieke toegang tot een ruimte impliciet toegang geeft tot (analoge) informatie.

Mijn volgende blog zal gaan over de principes voor Identificatie.