...
Je moet hiermee logica rekening houden in de opzet en toekenning van de rollen binnen de toepassing en haar beheer. Hierbij is het van belang dat de toegang die in de rollen vervat zit, altijd tweedelig is: de vertrouwelijkheids- en integriteitseisen gaan bepalen wie waartoe toegang zal kunnen krijgen.
| Info |
|---|
ACM |
Relatie van de kwaliteitskenmerken met zwakke, resp. sterke identificatie
...
De exacte requirements hiervoor staan opgelijst in het Overzicht en integratie van de maatregelen.
| Info |
|---|
Combinatie van Vertrouwelijkheid, Integriteit en Beschikbaarheid |
5.1.2.1.4. Integriteit van de gegevens betrokken in het identificatieproces
...
In de praktijk komt dit neer op het versleutelen van informatie. Meer details hierover vind je in het Beleidsdocument “Cryptografie”. De exacte controles op het gebied van versleuteling staan beschreven in het Beleidsdocument
Cryptografie.
| Info |
|---|
Key Management as a Service |
Beveiliging van de opgeslagen identiteiten
De personen die toegang kunnen krijgen tot een toepassing of een systeem, moet je ook ergens opslaan. De database waar deze informatie opgeslagen is, moet je adequaat beschermen. De informatie van welke identiteiten er bestaan en waartoe deze toegang hebben in een bepaalde toepassing, is informatie van klasse 3 voor Vertrouwelijkheid en klasse 4 voor Integriteit. De maatregelen die hierop van toepassing zijn, staan beschreven in het Organisatiedocument. Deze informatieklasse geldt voor zowel de Vertrouwelijkheid als de Integriteit. Hiermee moet je garanderen dat de gebruikerslijst vertrouwelijk en integer blijft. Dit helpt om eventuele cyberaanvallen tegen specifieke profielen of gebruikers tegen te gaan.
| Info |
|---|
Identity Management |
Alternatieve methodes
Je mag alternatieve methodes gebruiken om een persoon te identificeren. Je moet je er wel van vergewissen dat dit even veilig verloopt als de hierboven beschreven methodes.
Dit verifieer je met de verantwoordelijke voor Informatieveiligheid van je entiteit die dit overlegt met de CISO. Als er aan deze methodes (rest)risico’s verbonden zijn, moet het topmanagement deze ook in de mate van het mogelijke mitigeren of accepteren.
De normen waaraan je moet voldoen komen, zoals hierboven beschreven, overeen met klasse 3 voor vertrouwelijkheid en klasse 4 voor integriteit.
...
De gegevens die gelinkt zijn aan het identificatieproces moeten even beschikbaar zijn als de toepassing of het proces waarvoor ze dienen. Om de toegang tot een toepassing te kunnen garanderen, moeten deze gegevens leesbaar en verwerkbaar zijn tijdens de operationele werking van de toepassing.
Hou hier ook zeker rekening met piekmomenten, zowel qua gebruik als qua tijdsgevoeligheid. Het Organisatiedocument.
Als je gebruik maakt van een identificatieproces onafhankelijk van je eigen toepassing, moet dat uiteraard ook aan deze voorwaarden voldoen.
...
Authenticatie is het deelproces waarbij een individu zijn identiteit bewijst.
Om dit te doen heb je in de eerste plaats een authentieke bron nodig, een gecontroleerd en betrouwbaar identiteitsregistratieproces dat toelaat de identiteit van een individu te registreren.
...
Categorieën, types en status van accounts
Elk van de onderstaande account categorieën en types zijn volledige gedocumenteerd in: Policy documenten (vb. gebruiks- en paswoord policies) Gebruikers documentatie.
Account categorieën
Gebruikersaccount(s) zijn accounts die gebruikt worden voor reguliere eindgebruikerstoegangen voor informatieverwerking tot en met [KLASSE Klasse 4].
Geprivilegieerd(e) account(s) zijn accounts waaraan met potentieel geprivilegieerde toegangen worden verleend. Een geprivilegieerde toegang is een toegang die de gebruiker (van het account) de mogelijkheid geeft om Informatie van [Klasse 5] (minimaal) in te kijken.
De beschikbaarheid en/of gedrag van de gegevensverwerking te beïnvloeden.
...
Persoonlijk(e) account(s) zijn accounts met een rechtstreekse relatie tot één individu.
Vb. Reguliere gebruikersaccounts
Gedeeld(e) account(s) zijn accounts die gedeeld kunnen worden onder verschillende individuen. Deze accounts hebben ALTIJD een relatie tot een uniek individu via een rol: Toepassingsbeheerder.
Toepassingsaccount(s) zijn accounts gebruikt worden als authenticatie voor toepassingen onderling. Deze accounts hebben ALTIJD een relatie tot een uniek individu via een rol: Toepassingsbeheerder.
Systeemaccount(s) zijn accounts die deel uitmaken van het resultaat van installatie van het betrokken systeem. Deze accounts zijn ook gekend als built-in account(s)
Status van een account
Een account is actief wanneer het technisch de mogelijkheid biedt om gebruikt te worden als authenticatiemiddel
De criteria om een actief account te beschouwen zijn afhankelijk van de vorm waarin het account werd aangeleverd
Een account is inactief wanneer het op basis van de criteria uitgesloten werd als actief account. Een account kan bvb tijdelijk geblokkeerd (disabled) of slechts gebruikt tijdens bepaalde uren (bvb kantooruren).
Controlemaatregel
Inventarisatie van alle bestaande accounts, inclusief het type en bijhorende categorie met volgende indicatoren. Op basis hiervan kunnen bijkomende maatregelen worden ingevuld:
Slapend(e) account(s): Het account is niet meer gemotiveerd indien het niet werd gebruikt in de laatste 13 maand. De status actief, of inactief heeft geen invloed op de status
Ongemotiveerd(e) account(s): Het account is niet gekoppeld aan een gevalideerd identiteit van een fysiek persoon
Systemen kunnen technisch gezien ook gebruikt worden als identiteiten. In IAM-context koppelen we accounts steeds aan een fysiek persoon
Het is toegestaan koppeling te maken via een toepassing, waarachter onrechtstreeks gekoppeld een fysiek persoon, onder vorm van een ‘toepassingsbeheerder’. Deze koppeling kan dan geregistreerd worden via de CMDB
Inactief(ve) account(s): De accounts zijn technisch niet in staat deel te nemen aan een authenticatie proces. Ongecontroleerd(e) account(s): Het account voldoet niet aan de minimale technische vereisten van de paswoordpolicy die werd toegekend aan de account categorie of –type:
Leeftijd van het paswoord
Complexiteit van het paswoord
Omkeerbare encryptie van het paswoord
Geen paswoord
…
Provisioning
Provisioning is het deelproces dat wordt gebruikt voor alle activiteiten die leiden tot het verstrekken van een account aan een geïdentificeerd persoon. Afhankelijk van de implementatie van het proces worden accounts actief of inactief aangeleverd aan de rechtmatige persoon. Bij de aanlevering van inactieve accounts zorgt het provisioning proces voor een geautoriseerd en gedocumenteerd activatie (sub)proces.
Provisioning van actieve accounts is toegelaten tot en met informatie [klasse 2]
Account factoren worden gescheiden aangeleverd aan de rechtmatige gebruiker
De-provisioning
De-provisioning is het deelproces dat ervoor zorgt dat een account niet langer ter beschikking voor een eindgebruiker als bruikbaar authenticatiemiddel.
...
Bij zowel de Belgische federale als bij de Vlaamse overheid ligt de focus op (multi)factor-authenticatie, terwijl we regelmatig ook geconfronteerd worden met terminologie zoals tweefactor-authenticatie en tweetraps-authenticatie. Ze worden gemakkelijk door elkaar gehaald gezien ze alle drie baseren op dezelfde beginselen. Maar de verschillen zitten hem in de details. Zoals reeds aangegeven ligt het identificatieproces aan de basis van een succesvolle implementatie van een betrouwbare authenticatie: Om toegang te verlenen tot een toepassing, dienst of netwerk, moet het achterliggende systeem weten dat de persoon die zich aanmeldt ook daadwerkelijk degene is die als wie hij zich voordoet.
Gezien in de meeste implementaties van multifactor-authenticatie men refereert naar 2 factoren is het niet ongewoon om het synoniem tweefactor-authenticatie te gebruiken.
Wat verstaat men onder factoren?
Onderstaande eenvoudige richtlijnen kunnen hierbij meer duidelijkheid brengen.
Een factor is een van onderstaande:
...
Voor de validatie tot toegang voor een gebouw zal het toegangscontrole systeem de toegang enkel valideren op iets dat in het bezit is van de gebruiker Bij de toegang tot het werkstation door middel van een gebruiker ID en paswoord zal de controle enkel gevalideerd worden op basis van iets wat de gebruiker weet
| Info |
|---|
Merk op: In bovenstaande voorbeelden is er geen enkele garantie dat de gebruiker effectief ook de identiteit is, waaraan de toegang werd toegekend. Dit onderstreept het belang voor de organisatie dat gebruikers op de hoogte worden gebracht, hoe deze |
Eén-factor authenticatie en de paswoord problematiek
Het probleem bij het gebruik van enkelvoudige factoren, is dat deze niet altijd voldoende garantie biedt om een identiteit te verifiëren. Als derden deze factor weten te misbruiken (het wachtwoord achterhalen of de badge ontvreemden), dan kan deze zich als de persoon, gekoppeld aan het authenticatiemiddel (account) voordoen en zich onrechtmatig toegang verlenen.
Bij de factorauthenticatie op basis van wat je bent (biometrische authenticatie) is misbruik minder evident, maar niet ondenkbaar. Bovendien is de beschikbare technologie niet altijd in staat om de identiteit gegarandeerd vast te stellen (misleiding gezichtsherkenning d.m.v. foto).
Om een betere garantie te geven bij het afschermen van informatie is het sterk geadviseerd om minimaal bijkomende maatregelen te nemen die het risico op misbruik kan verminderen. Bij sommige informatieklassen worden deze bijkomende maatregelen onvoldoende geacht en vraagt men expliciet om een identiteit te valideren op basis bijkomende authenticatie maatregelen op basis van meerdere factoren
...
Multifactor baseert zich bij de validatie van een identiteit op meerdere factoren door deze te combineren in het authenticatieproces. Het bekendste voorbeeld van het toepassen van een multifactor-authenticatie is de creditcard (iets wat je hebt) en de bijhorende pincode (iets wat je kent). Het authenticatie proces gebruikt daarbij twee factoren om de identiteit van een gebruiker vast te stellen.
| Info |
|---|
Merk op: Gebruiker ID en paswoord bevinden zich beide in dezelfde factor klasse (iets dat je weet) en worden dus niet beschouwd als multifactor. |
Tweetraps met één factor
Een belangrijk concept hierbij is dat multifactor uitgaat van twee los van elkaar bestaande factoren. Een toegangscode op bijvoorbeeld een smartphone (App en SMS) naast een reguliere wachtwoordtoegang, is volgens de definitie geen 'echte' multifactor-authenticatie, omdat er gebruik wordt gemaakt van één factor: iets wat je kent.
...
Een alternatief hiervoor is werken met federatie, waarbij je de identificatie en authenticatie aan een derde partij toevertrouwt. Dit wil vooral zeggen dat je de data die hiermee gepaard gaat niet zelf beheert. Als je dit doet, moet je er wel zeker van zijn dat die derde partij alle noodzakelijke controles in plaats heeft gezet om de data te beschermen. Dit dek je idealiter ook contractueel af.
Voorbeelden Bekende voorbeelden van deze techniek is om aan te melden met een account van een social media platform, bijvoorbeeld Facebook.
Dit zijn slechts enkele voorbeelden van maatregelen die je kunt nemen om paswoorden te beveiligen. Je mag er uiteraard andere en meer nemen. Doe dit in overleg met de verantwoordelijke over Informatieveiligheid binnen je entiteit.
...
Hier is de link met de informatieklasse van de toepassing of het proces evenzeer belangrijk. De authenticatie moet kunnen gebeuren terwijl de toepassing functioneel is. Welke controles hiervoor kunnen gelden, staat beschreven in het Beleidsdocument Toegangsbeheer. Als je gebruik maakt van een authenticatieproces onafhankelijk van je eigen toepassing, moet dat uiteraard ook aan deze voorwaarden voldoen.
Logbestanden bijhouden
De logbestanden voor de gebeurde authenticaties moet beschikbaar zijn in lijn met de termijnen van het bijhouden van de operationele logs van de toepassing. De geldende legale termijn moet je hierbij ook respecteren. Deze zijn uiteraard sterk afhankelijk van de operationele context. De langste termijn is bepalend.
...
Daarnaast, maakt men op basis van de behoeften gespecifieerd in deze toegangsbeleidslijnen (access policies) een set van (workflow) processen die de organisatie gebruikt om het toegangsbeheer operationeel uit te baten. Deze workflow processen kunnen worden geautomatiseerd (Voorbeeld: Vo webIDM)
Volgende elementen zijn noodzakelijk in het toegangsbeheer vanaf informatieklasse 2 voor Vertrouwelijkheid en Integriteit of afhankelijk van de klassen van de verwerkte informatie binnen de doeltoepassing of dienst.
| Info |
|---|
Opmerking: Toegangsbeheer voor beheersactiviteiten, verschillend van reguliere toegangen voor eindgebruikers worden apart behandeld in het Privileged access management of PAM proces. Deze omvatten de beheerstoegangen tot achterliggende infrastructuur, platform of softwarecomponenten |
Attributen van het toegangsbeheer
Volgende attributen zijn aanwezig in het toegangsbeheer om een auditeerbaar proces te garanderen:
Beschikbare informatie bij de verwerking van een toegang
Basis attributen van het verzoek tot toegang (Datum, tijd, aanvrager, volgnummer, …)
Onderwerp, als referentie naar het individu die de toegang wenst te gebruiken.
Motivatie van het verzoek
Bevestiging van motivatie
Basis attributen van de validatie van de toegang (Datum, tijd, …)
Identiteit van de persoon die de goedkeuring(en) geeft.
(Optioneel: bijkomende opmerkingen)
Vervaldag van het toegangsrecht, afhankelijk van de klasse van de verwerkte informatie binnen de dienst of toepassing
Periodiek herhaalde (her)validatie van een recht, afhankelijk van de klasse van de verwerkte informatie binnen de dienst of toepassing
| Info |
|---|
Opmerking(en):
|
Actoren(rollen) bij de verwerking van een toegang
Onderwerp: Identiteit van het individu die toegang tot de verwerking wenst te gebruiken.
Validator: Identiteit van een individu die de voorwaarden tot de gevraagde toegang bevestigen (valideren) tijdens het verwerkingsproces
De verwerking van autorisaties voor zichzelf is hierbij uitgesloten
De autorisatie voor actoren die deze rol opnemen is opgenomen in het toegangsbeheersysteem en gevalideerd door de organisatie
Hiërarchisch leidinggevende Functioneel leidinggevende Functioneel verantwoordelijke
Toepassingsbeheerder
Security Officer
Toegangsbeheerder: Identiteit van het individu die de toegangsverzoeken operationeel verwerkt
Elke erkende gebruiker van het toegangsbeheer proces
Self-service baseert zich steeds op een sterke authenticatie
Identiteit van een individu die het toegangsbeheerproces voor anderen administratief verwerken.
De verwerking van toegangen voor zichzelf is hierbij uitgesloten
De autorisatie voor actoren die deze rol opnemen is opgenomen in het toegangsbeheersysteem en gevalideerd door de organisatie.
Auditor: Identiteit van een individu die controle uitvoert op alle aspecten van het verwerkingsproces.
Alle verwerkingsinformatie van het toegangsbeheer (audit trails) zijn beschikbaar en zijn enkel in te kijken door het individu
De autorisatie voor actoren die deze rol opnemen is opgenomen in het toegangsbeheersysteem en gevalideerd door de organisatie.
...
5.1.2.3.3. Integriteit van het authenticatieproces
Soll/Ist 6
Met Soll/Ist bedoelen we twee processen:
...
Voorbeeld:
Eén manier om dit in te richten is met de Identiteitsbeheer-bouwsteen (IDM). Dat proces verloopt voorlopig deels automatisch. IDM legt je als tool geen frequentie op, die heb je dus wel zelf onder controle.
| Info |
|---|
Ist-proces vs. De-provisioning |
Een rol toekennen
Je gebruikt de Soll-matrix als leidraad en kent enkel een rol toe aan een geïdentificeerd persoon. Als blijkt dat een aanvraag tot toegang niet strookt met de bestaande Soll en de aanvraag gerechtvaardigd is, pas je de Soll aan en laat je hem opnieuw valideren door de toepassingseigenaar. Afhankelijk van de informatieklasse van de data, zowel qua Vertrouwelijkheid als qua Integriteit, moet de identificatie van de persoon strenger zijn. Dit staat beschreven in het hoofdstuk Identificatie als maatregel.
5.1.2.3.4. Integriteit van de gegevens betrokken in het authenticatieproces
Validatie
Het is belangrijk om in de hierboven beschreven processen voldoende controles te voorzien om de integriteit van de gebruikte gegevens te borgen. Dat gaat dan om:
...
5.1.2.3.5. Beschikbaarheid van het autorisatieproces
Link met de informatieklasse
Het autorisatieproces om een gebruiker te autoriseren moet even beschikbaar zijn als de toepassing waartoe deze gebruiker zich wil laten autoriseren. Als je gebruik maakt van een autorisatiesysteem onafhankelijk van je eigen toepassing, moet dat uiteraard ook aan deze voorwaarden voldoen.