Beveiligingsdocumentatie

Dit document geeft een uitgebreid overzicht van het beveiligingsraamwerk voor de producten en diensten van Identum, inclusief eADM en eFeide. Onze beveiliging is gebaseerd op de beste praktijken in de industrie, robuuste operationele procedures en een toewijding om klantgegevens te beschermen.

Ontwikkelings- en ontwerpfilosofie

Ons ontwikkelingsproces wordt geleid door een 'veiligheid eerst'-mentaliteit, waarbij de basisprincipes van moderne cyberbeveiliging worden geïntegreerd.

"Privacy door ontwerp"

Identum ontwikkelt zijn oplossingen met Privacy by design als basisfilosofie. De 7 principes zijn:

Proactief niet reactief; preventief niet corrigerend
Privacy als standaardinstelling
Privacy ingebed in ontwerp
Volledige functionaliteit - Positieve som, geen nulsom
End-to-end beveiliging - Volledige bescherming gedurende de hele levenscyclus
Zichtbaarheid en transparantie - Houd het open
Respect voor de privacy van gebruikers - Houd het gebruikersgericht

Voor de eindklant betekent dit dat onze oplossingen standaard veilig zijn; privacy is ingebouwd in de oplossing en hoeft niet te worden geconfigureerd.

Zero trust

Het zero trust-principe in de context van identiteits- en toegangsbeheer (IAM) is een beveiligingsmodel en -strategie die is gebaseerd op het concept dat geen enkele gebruiker of apparaat, binnen of buiten het netwerk van de organisatie, ooit de facto vertrouwen mag worden gegund. In plaats van ervan uit te gaan dat alles achter de firewall veilig is, vereist zero trust dat alle toegang continu wordt geverifieerd en geautoriseerd.

Hier volgen enkele belangrijke aspecten van het zero trust-principe in verband met eADM:

Identiteitsverificatie: Elk verzoek om toegang tot het systeem vereist een strikte verificatie van de identiteit van de gebruiker of het apparaat. Dit wordt vaak geïmplementeerd met behulp van sterke authenticatiemethoden, zoals multi-factor authenticatie (MFA).
Minimalisering van toegang: gebruikers krijgen alleen toegang tot de middelen die ze nodig hebben om hun taken uit te voeren (het principe van minimale rechten). Toegangsrechten zijn vaak gedetailleerd en dynamisch, en worden aangepast op basis van de behoeften en het gedrag van de gebruiker. Dit geldt zowel voor de toegang van gebruikers tot eADM als voor de toegangsrechten die het systeem aan andere gebruikers toekent. Doorgaans is op behoeften gebaseerd toegangsbeheer (ABAC of JIT) beter geschikt voor gevoelige systemen dan bijvoorbeeld op rollen gebaseerd accountbeheer (RBAC).
Continue monitoring: Alle activiteiten worden gemonitord en geanalyseerd om verdacht of ongewoon gedrag op te sporen. Dit kan onder meer betrekking hebben op ongebruikelijke toegangspatronen of pogingen om toegang te krijgen tot gevoelige gegevens.
Gegevensbescherming: Hoewel identiteits- en toegangsbeheer van cruciaal belang is, richt zero trust zich ook sterk op de bescherming van gegevens. Dit omvat het versleutelen van gegevens zowel tijdens het transport als in rust, evenals het beveiligen van de toegang tot opgeslagen gegevens op basis van behoefte.

De implementatie van zero trust in eADM is van cruciaal belang om organisaties te beschermen tegen beveiligingsrisico's door de aannames van traditionele beveiligingsmodellen ter discussie te stellen.

Gegevensminimalisatie

Gegevensminimalisatie houdt in dat de hoeveelheid verzamelde, verwerkte en opgeslagen persoonsgegevens en gevoelige gegevens wordt beperkt tot wat strikt noodzakelijk is voor het uitvoeren van legitieme taken. Dit principe is een belangrijk onderdeel van de Algemene Verordening Gegevensbescherming (AVG) en andere wetgeving op het gebied van gegevensbescherming, en helpt het risico op datalekken en schendingen van de privacy te verminderen.

Beperkte verzameling: Alleen gegevens die nodig zijn voor specifieke functies of diensten mogen worden verzameld. Zo importeert eADM standaard geen salarisgegevens, alleen als dit nodig is voor de individuele klant.
Kortere bewaartermijnen: gegevens mogen alleen worden bewaard zolang er een operationele of wettelijke verplichting bestaat. eADM heeft een beleid voor gegevensbewaring dat gegevens automatisch verwijdert of anonimiseert wanneer dat nodig is. Standaard hanteert eADM een bewaartermijn van 365 dagen voor gedeactiveerde gebruikers, maar dit kan per klant worden aangepast.
Geaggregeerde gegevens in plaats van individuele gegevens: Waar mogelijk moeten gegevens worden geanonimiseerd of geaggregeerd, zodat de verwerking niet op individuele identificatie is gebaseerd.
Toegangscontrole en minimaal privilege: Door strikte toegangscontrole te implementeren, wordt ervoor gezorgd dat alleen bevoegd personeel toegang heeft tot persoonsgegevens en dat gebruikers alleen de rechten krijgen die ze nodig hebben.
Doel en transparantie van gegevens: Duidelijke richtlijnen over waarom en hoe gegevens worden gebruikt, beperkt tot de minst ingrijpende manieren om die doelen te bereiken, dragen bij aan gegevensminimalisatie.
Pseudonimisering: Als identificeerbare gegevens moeten worden gebruikt, kan pseudonimisering (het gebruik van aliassen voor gegevens) helpen om de identiteit van personen te beschermen en de gevolgen van mogelijke gegevenslekken te beperken.

Door deze principes toe te passen, kan een eADM gegevensminimalisatie in uw organisatie ondersteunen, waardoor persoonsgegevens beter worden beschermd, terwijl tegelijkertijd wordt voldaan aan wettelijke vereisten en de privacy van gebruikers wordt bevorderd.

Werking en "Basisprincipes voor ICT-beveiliging"

Op operationeel vlak hebben we ons veiligheidsbeleid gebaseerd op de basisprincipes voor ICT-beveiliging van de Noorse nationale veiligheidsdienst.

Identificeer en breng apparaten, software, gebruikers en toegangsbehoeften in kaart

Overzicht en controle van hoe lang we gebruikersgegevens bewaren, en routines voor verwijdering.
Toegang moet altijd op het minimumniveau worden toegekend; niemand mag meer toegang hebben dan nodig is om zijn werk te kunnen doen.
Zie de secties over toegang voor toegangsniveaus voor systeemgebruikers in AD, G Suite en M365.

Beschermen en onderhouden

Zorg voor een veilige ICT-architectuur en bescherm het netwerk van de onderneming. Controleer de gegevensstroom.
Houd controle over identiteiten en toegangen.
Alle wachtwoorden moeten worden opgeslagen in een wachtwoordkluis. Wachtwoorden mogen niet worden hergebruikt. Alle wachtwoorden en toegangen zijn persoonlijk.
Als u toegang krijgt tot een klantensysteem, moeten het wachtwoord en de gebruikersnaam worden verwijderd wanneer de taak is voltooid.
Bescherm gegevens in rust en tijdens het transport.
Bewaar cruciale informatie over gedeactiveerde gebruikers in eFeide en eADM om te voorkomen dat gebruikersnamen en andere unieke identificatiegegevens opnieuw worden gebruikt.
Na een bepaalde periode worden logbestanden, persoonlijke gegevens en de toegangs-/rechtenhistorie van een gebruiker automatisch verwijderd.

Bekende kwetsbaarheden en bedreigingen detecteren en verwijderen

In overeenstemming met het eerste basisprincipe van 'privacy by design' streven we er actief naar om kwetsbaarheden in ons systeem op te sporen. Daarom voeren we jaarlijks penetratietests uit op onze oplossingen. Deze worden uitgevoerd door de beveiligingsexperts van Visma. Meer informatie vindt u onder 'Penetratietests'.
De dreigingsanalyse wordt uitgevoerd in samenwerking met het Nationaal Cyber Security Centrum (NCSC). Identum wordt beschouwd als kritieke infrastructuur en ontvangt meldingen van het NCSC wanneer er beveiligingslekken en exploits worden ontdekt in serversystemen, software en andere IT-systemen. Identum voert voortdurend dreigingsanalyses uit op basis van informatie van het NCSC. Relevante beveiligingslekken worden continu gepatcht zodra we hiervan op de hoogte zijn.
Alle Identum-servers, zowel in productie- als testomgevingen, worden wekelijks bijgewerkt. Dit geldt voor het besturingssysteem, geïnstalleerde apps en andere software. Daarnaast worden eFeide en eADM ook op zondag bijgewerkt, in overeenstemming met 14-daagse ontwikkelingssprints. Identum heeft een speciale medewerker die hiervoor verantwoordelijk is. Na het patchen/updaten worden alle systemen getest om de volledige functionaliteit te garanderen. Er is gekozen voor zondag vanwege de lage belasting en het lage gebruik op zondag. eFeide wordt niet bijgewerkt in verband met het begin van het schooljaar en examens, met uitzondering van operationeel kritieke updates.

Behandelen en herstellen

Alle ongewenste incidenten met betrekking tot veiligheid of privacy worden geregistreerd in een apart register, met vermelding van tijd, plaats, betrokken personen, genomen maatregelen en follow-up. De procedures zijn vastgelegd in het interne noodplan van Identum. Klanten worden op de hoogte gebracht van zowel interne als externe ongewenste incidenten volgens de Service Level Agreement (SLA). De procedures zijn vastgelegd in het interne noodplan van Identum. Indien relevant worden dreigingsanalyses van het NCSC met klanten gedeeld.

Identum heeft een overeenkomst voor hulp van Visma's eigen cyberbeveiligingsgroep als het bedrijf wordt aangevallen, gehackt of als de gegevensbeveiliging op een andere manier wordt bedreigd. Visma zal dan een responsteam samenstellen dat verantwoordelijk is voor het afhandelen van de situatie, het onder controle krijgen ervan en het herstellen van de getroffen systemen.

Systeembewaking en bedreigingsbeheer

Sinds 01.02.2023 is Identum AS een volledige dochteronderneming van Visma AS en onderworpen aan de routines van Visma voor cyberbeveiliging, monitoring en bedreigingsbeheer. Visma maakt gebruik van Sentinel One (SentinelOne | AI-Powered Enterprise Cybersecurity Platform) voor Managed Detection and Response (MDR). Sentinel One voert continu monitoring uit van de servers, clients, eindpunten en computers van medewerkers van Identum. Alle incidenten worden geregistreerd en geëvalueerd, en bedreigingen worden automatisch actief opgevolgd door het Security Operations Centre (SOC)-team van Visma.

In geval van een voldoende ernstig beveiligingsincident of een aanval wordt Identum door Visma op de hoogte gebracht; zij hebben een 24/7/365-respons en zullen maatregelen nemen nog voordat Identum op de hoogte wordt gebracht. Als het incident/de aanval als kritiek wordt beoordeeld of gericht is op een specifieke klant, wordt de klant onmiddellijk op de hoogte gebracht en opgenomen in het team dat het incident afhandelt. De normale meldingsdienst voor onze klanten verloopt via e-mail; in dergelijke gevallen ontvangt u ook een telefoontje.

Achterdeur en toegang als de normale login niet werkt

Identum heeft zijn eigen "break glass"-accounts in onze bedrijfsomgeving. Als de normale login voor onze medewerkers om een of andere reden niet werkt, kunnen deze accounts worden gebruikt om toegang tot het systeem te verlenen of te herstellen. Deze achterdeur wordt niet gebruikt bij normale werkzaamheden en alle logins worden gemonitord met onmiddellijke melding. In gevallen waarin de aanmelding van de klant bij eADM niet werkt (bijvoorbeeld als de AAD van de klant niet werkt en SSO daardoor buiten gebruik is), kan Identum tijdens de periode dat de klant downtime ondervindt, overschakelen naar een andere aanmelding, bijvoorbeeld van Entra ID SSO naar aanmelding met ID-porten.

Penetratietesten

Identum maakt deel uit van het PENTEST 2.0-programma van Visma. Continue tests worden geactiveerd op basis van daadwerkelijke risicosignalen, in plaats van op basis van verstreken tijd. De tests worden nu aangestuurd door gegevens van andere diensten in het Application Security Programme van Visma (Software Composition Analysis, Static Application Security Testing, Dynamic Application Security Testing, External Attack Surface Mapping) en door deskundige beoordelingen van het eigen penetratietestteam van Visma. Onze klanten zijn uiteraard vrij om hun eigen penetratietests uit te voeren, met of zonder hulp van door de klant gekozen derde partijen.

Exploitatie en hosting

De oplossingen van Identum zijn cloudgebaseerd en worden beheerd en onderhouden in Entra ID via onze operationele partner Microsoft, met redundantie, externe back-up en load balancing. We hebben twee Entra ID-omgevingen: in Østfold voor Noorse klanten en in Gävle, Zweden, voor EU-klanten. De uptime-garantie is 99,9% (zie onze SLA). Identum is verantwoordelijk voor het besturingssysteem en de software, terwijl Microsoft zorgt voor de werking van de hardware, communicatie, offsite back-up, redundantie en firewall. Alleen medewerkers met technische verantwoordelijkheid bij Identum of noodzakelijk operationeel personeel bij Microsoft hebben toegang tot de serveromgeving. Dit gebeurt via Teamviewer-clients met MFA. Identum heeft een uitgebreide SLA-overeenkomst met Microsoft met een responstijd van 10 minuten tijdens kantooruren en 1 uur daarbuiten.

De enige firewallpoorten die over het algemeen openstaan voor inkomend verkeer zijn poorten 80/443 voor het gebruik van Teamviewer, webclients en API-clients. Al het verkeer naar poort 80 wordt automatisch doorgestuurd naar 443, zodat de communicatie plaatsvindt via een versleutelde lijn via TLS. Alle webservices/pagina's, zowel intern als extern, zijn beveiligd met SSL-certificaten van Digicert.

Patches en updates

Het patchen van systemen, componenten, servers, databases enz. gebeurt elke zondag. Identum heeft hiervoor een speciale afdeling. Identum is gedefinieerd als kritieke infrastructuur en ontvangt meldingen van het National Cyber Security Centre (NCSC) wanneer er beveiligingslekken en exploits worden ontdekt in serversystemen, software en andere IT-systemen. Identum voert voortdurend dreigingsanalyses uit op basis van informatie van het NCSC. Relevante beveiligingslekken worden continu gepatcht zodra we hiervan op de hoogte zijn. Het updaten van systemen, componenten, servers, databases, enz. gebeurt ook elke zondag. Identum maakt standaard geen gebruik van bètafuncties of bètaversies.

Encryptie

De servers van Identum worden gehost in de Entra ID-cloud en maken daarom gebruik van standaard server-side encryptie van alle gegevens tijdens opslag. De encryptiesleutels worden automatisch beheerd door het Entra ID-platform (server-side encryptie van door Entra ID beheerde schijven - Entra ID Virtual Machines). De communicatie tussen de servers, clients, webbrowsers en systemen van derden van Identum wordt end-to-end versleuteld via TLS 1.2 met 2048-bits versleuteling, en de certificaten worden uitgegeven door Digicert. Deze worden geïnstalleerd en onderhouden door de leden van ons operationele team die de nodige toegang hebben tot de servers en de Digicert-service. Ze worden vervangen/hebben een geldigheidsduur volgens de industrienormen (12 maanden). Databases, back-ups en besturingssystemen worden ook versleuteld. Bovendien worden alle gebruikersgegevens versleuteld. In eADM en eFeide worden alle systeemwachtwoorden (geheimen) beveiligd met Rijndael AES 256-bits encryptie. Wachtwoorden voor gebruikers worden opgeslagen in onze LDAP-database, die gebruikmaakt van standaard Active Directory-technologie en ze daarom gehasht en versleuteld opslaat. Bij het overbrengen van wachtwoorden (geheimen) wordt altijd end-to-end-encryptie via TLS gebruikt.

Gegevensscheiding en -scheiding

Klantgegevens worden logisch gescheiden met behulp van een unieke klant-ID, waardoor elke klant effectief als een afzonderlijk domein wordt behandeld. Deze architectuur weerspiegelt het multi-tenantmodel van Microsoft Entra,
, waarbij logische grenzen ervoor zorgen dat elke klant binnen een op zichzelf staande omgeving bestaat.
Alle gegevenstabellen zijn gekoppeld aan deze unieke ID en elk API-verzoek moet deze sleutel als verplichte parameter bevatten. Door deze op domeinen gebaseerde grenzen af te dwingen, zorgt het systeem ervoor dat
authenticatie, autorisatie en gegevensopslag strikt beperkt blijven tot de specifieke klant. Dit garandeert dat gegevens geïsoleerd en veilig blijven, waardoor blootstelling tussen klanten wordt voorkomen.

Beheerders kunnen door Identum alleen toegang krijgen tot meer dan één instantie van eADM, en de beheerder kan anderen niet dezelfde toegang toekennen. Het wordt aanbevolen om dergelijke toegang altijd te verlenen met een vervaldatum.

Back-up en herstel

Er wordt elke 10 minuten een back-up gemaakt van de databases; van de productieomgeving als geheel wordt dagelijks een back-up gemaakt. Back-ups worden niet opgeslagen in de productieomgeving, maar in een fysiek gescheiden omgeving. Om zowel de kwaliteit als de inhoud van back-ups te controleren en gegevensherstel te testen, wordt de testomgeving van Identum altijd gemaakt op basis van back-ups. De testomgeving is een volledige kopie van de productieomgeving. Dit gebeurt minimaal elke 14 dagen.

Continuïteitsplan

Indien nodig kan de volledige bedrijfs-/serveromgeving binnen zes uur volledig worden hersteld, hetzij in dezelfde omgeving, hetzij in een secundaire omgeving (bijvoorbeeld als de primaire omgeving het slachtoffer is van een DDOS-aanval). Het is ook mogelijk om individuele klanten te herstellen vanuit een back-up. Dit kan zowel worden gedaan als er fouten optreden in verband met upgrades of technische wijzigingen aan de oplossing, als wanneer de klant moet herstellen, bijvoorbeeld na een import van corrupte gegevens uit het bronsysteem. Dit kan worden aangevraagd via de klantenservice van Identum, en dergelijke verzoeken worden behandeld als een niveau A-fout volgens de op dat moment geldende Service Level Agreement van de klant. Als Identum zelfstandig besluit dat de volledige serveromgeving of een specifieke klant moet worden hersteld, wordt de klant hiervan op de hoogte gesteld, hetzij via de meldingsdienst in eADM, hetzij telefonisch.

Preventieve maatregelen

Identum heeft, net als andere Visma-bedrijven, zijn eigen procedures voor risicobeoordeling, risicobeperking en risicobeheer. Risico's worden geïdentificeerd en beoordeeld op basis van ernst en waarschijnlijkheid (risicobeoordeling). Voor elk risico moet er een preventief plan (risicobeperking) en een behandelingsplan (risicobeheer) zijn voor het geval het risico zich daadwerkelijk voordoet. Dit materiaal maakt deel uit van de interne beveiligingsdocumentatie van Identum. Dit is uiteraard geen openbare informatie. Zie ook paragraaf 3 "Systeemmonitoring en bedreigingsbeheer" en paragraaf 5 "ISO27001 en Visma Cloud Delivery Model".

Gevolgen van downtime voor eADM

Als eADM niet beschikbaar is, blijven alle accounts in de organisatie functioneren zoals voorheen, met alle rechten en toegangen. Zolang eADM niet beschikbaar is, worden er geen accounts aangemaakt/bijgewerkt/gedeactiveerd/verwijderd en worden er geen toegangen/licenties verleend/gewijzigd/verwijderd door eADM. Het blijft mogelijk om dit handmatig te doen in het individuele doelsysteem.

Gevolgen van downtime voor eFeide

Als eFeide, het gebruikersbeheersysteem (BAS) voor de FEIDE-directory, niet beschikbaar is, blijft FEIDE-login gewoon werken zoals voorheen. Alleen als SIKT (het Noorse agentschap voor gedeelde diensten in onderwijs en onderzoek, https://sikt.no/ ) niet beschikbaar is, is FEIDE-login niet beschikbaar. Als eFeide niet beschikbaar is, zijn de functionaliteit voor wachtwoordbeheer, internettoegangsbeheer en MFA-beheer van FEIDE-accounts niet beschikbaar.

Gevolgen van downtime voor bronsystemen

Als een bronsysteem niet beschikbaar is, worden eADM en eFeide uiteraard niet bijgewerkt met nieuwe brongegevens. De gegevensstroom van eADM en eFeide naar doelsystemen blijft ongewijzigd. Voorbeelden hiervan zijn wachtwoordwijzigingen, wijzigingen in groep-/teamlidmaatschap, rollen en rechten. Wanneer het bronsysteem weer beschikbaar is, verwerken eADM en eFeide alle brongegevens opnieuw, zodat alle wachtende gebruikers enz. de benodigde accounts en toegangen krijgen.

Gevolgen van downtime op doelsystemen

Als een doelsysteem voor een kortere of langere periode niet beschikbaar is, worden wijzigingen in een exportwachtrij geplaatst. Wanneer het doelsysteem weer beschikbaar is, wordt de wachtrij verwerkt. Voorbeelden van wijzigingen die in de exportwachtrij worden geplaatst, zijn attribuutwijzigingen (bijvoorbeeld de naam van een gebruiker), wachtwoorden, lidmaatschap van groepen/teams, rollen en toegangsrechten. In eADM wordt geregistreerd wanneer wijzigingen in de exportwachtrij zijn geplaatst en naar de verschillende doelsystemen zijn verzonden.

Kennisgeving

Identum heeft verschillende soorten meldingen over fouten, downtime of andere incidenten die een negatieve invloed hebben op de dienstverlening:

Automatische systeemmelding → Het systeem stuurt na elke voltooide synchronisatie een statusrapport met algemene informatie. Daarnaast geeft het systeem een melding als de synchronisatie stopt, bijvoorbeeld als gevolg van beschadigde gegevens of als een doelsysteem niet reageert. Het is ook mogelijk om uw eigen meldingscriteria in te stellen, via e-mail of sms, bijvoorbeeld als een gebruiker beheerdersrechten krijgt. eADM kan worden ingesteld om automatisch een melding te versturen in geval van foutmeldingen voor individuele gebruikers, bijvoorbeeld als een update mislukt in een doelsysteem (op voorwaarde dat het doelsysteem dit ondersteunt!).
Handmatige melding → Identum heeft een eigen meldingslijst met e-mail en sms voor alle beheerders in eADM en/of eFeide. Deze lijst wordt gebruikt om incidenten te melden die een negatieve invloed hebben op een of meer klanten. Zowel algemene als specifieke problemen worden gemeld, in overeenstemming met de SLA.
Houd er rekening mee dat klanten die over hun eigen monitoringsystemen beschikken, via API verbinding kunnen maken met de logboeken in eADM en automatisch doorlopende logboeken met meldingen, updates en fouten kunnen extraheren.

Foutmeldingen

Alle fouten die door de klant worden ontdekt, kunnen rechtstreeks aan Identum worden gemeld via een formulier dat beschikbaar is voor beheerders in eFeide en eADM. Dit geldt voor alle soorten fouten, zowel fouten met het systeem als meldingen van privacygerelateerde incidenten en maatregelen. Alle privacygerelateerde incidenten worden behandeld als een fout van niveau A volgens de overeengekomen service level agreement (SLA). Alle incidenten worden afgehandeld volgens de basisprincipes voor ICT-beveiliging, paragraaf 4.-4.4. eADM en eFeide hebben ook een ingebouwde functionaliteit om suggesties voor verbetering in te dienen. Alle voorstellen worden continu beoordeeld.

Informatiebeveiliging

AVG en privacy

Als basisprincipe voor het importeren van brongegevens in onze systemen importeren we alleen gebruikers en gebruikersgegevens die verder moeten worden verwerkt. Als een werknemer geen account in AD heeft, filteren we dit uit zodat het helemaal niet in onze systemen wordt geïmporteerd. Guardian-gegevens worden niet gebruikt bij het importeren in Feide-directory's. Alleen relevante gebruikersgegevens worden geïmporteerd; we importeren bijvoorbeeld het dienstverbandpercentage (dat relevant kan zijn in verband met het toewijzen van licenties), maar geen salarisgegevens. Het is belangrijk om te benadrukken dat de brongegevenssystemen (HRM en SAS) voorrang hebben. Wanneer een gebruiker in HRM wordt aangemaakt, wordt deze ook in eADM aangemaakt. Wanneer een gebruiker wordt gedeactiveerd of uit het systeem wordt verwijderd, worden de bijbehorende gegevens ook verwijderd, volgens de regels die in eADM zijn ingesteld. Zo kan bijvoorbeeld worden geautomatiseerd dat gebruikers eerst worden gedeactiveerd en vervolgens na een bepaalde periode uit het systeem worden verwijderd.

De veiligheid en privacy in eADM zijn volledig afhankelijk van het feit of de klant goede routines heeft voor het registreren en uitschrijven van gebruikers uit hun bronsystemen. Een veelgehoorde klacht van beheerders als het gaat om de levenscyclus van gebruikersaccounts is dat "iedereen het merkt als iemand begint, maar niemand het merkt als iemand vertrekt". Daardoor loopt u het risico dat oude gebruikersaccounts en persoonlijke gegevens lang blijven liggen. De oplossing hiervoor is een goede set regels in eADM die ervoor zorgt dat gegevens die niet moeten worden opgeslagen, worden verwijderd, bijvoorbeeld wanneer de gebruiker wordt gedeactiveerd, met verlof gaat, overlijdt of ontslag neemt. eADM automatiseert dit en zorgt ervoor dat alle gebruikersaccounts automatisch worden verwijderd of dat de nodige ontvangers worden geïnformeerd wanneer er iets handmatig moet worden gedaan. Via berichtensjablonen kunnen IT, operations en admin worden geïnformeerd wanneer apparatuur moet worden ingeleverd of wanneer toegangen moeten worden gewijzigd of verwijderd. Alle gebruikers hebben een login voor de gebruikersinterface en iedereen kan op elk moment alle gegevens zien die voor zijn of haar eigen gebruiker zijn geregistreerd.

In verband met de AVG en privacy kunnen eindgebruikers hun gegevens bekijken in een privacygedeelte waar we ook vermelden waar de gegevens vandaan komen, met wie ze contact moeten opnemen als er iets niet klopt of als ze de gegevens willen laten verwijderen. De oplossingen van Identum voldoen aan alle vereisten voor de norm voor informatiebeveiliging. Zie bijlage 9 in het contract voor de gegevensverwerkingsovereenkomst van Identum AS. Wij hanteren het principe dat wij ons aanpassen aan onze klanten, in plaats van dat zij zich aan ons moeten aanpassen. Als onze standaardgegevensverwerkingsovereenkomst niet voldoet aan de behoeften van de klant, passen wij ons aan en gebruiken we de overeenkomst die de klant wenst.

Subverwerkers

Raadpleeg het Visma Trust Centre voor informatie over onze hostingproviders en gegevensverwerkers:

https://www.visma.com/trust-centre-products/identum

ISO27001 en het Visma Cloud Delivery Model

Sinds 01.02.2023 is Identum AS een volledige dochteronderneming van Visma AS en daarmee onderworpen aan hun kwaliteitssysteem en leveringsmodel zoals hier beschreven: Het Visma Cloud Delivery Model (VCDM) beschrijft onze aanpak voor het ontwikkelen, leveren en exploiteren van clouddiensten. Het beschrijft aspecten van hoe we moeten worden georganiseerd, hoe we moeten werken (processen), evenals technische vereisten en best practices die nodig zijn voor een succesvolle levering van clouddiensten. Meer informatie over VCDM is te vinden op: Het Visma Cloud Delivery Model (VCDM). Het model is gebaseerd op een reeks kernprincipes en richt zich op DevOps en Continuous Delivery. VCDM heeft de volgende auditverklaring en certificeringen:

ISAE 3402 SOC 1 type II
ISO 27001

Het Visma-beveiligingsprogramma en het Visma-architectuur- en technologieprogramma zijn geïntegreerd in het Visma Cloud Delivery Model. Ons informatiebeveiligingsbeheersysteem (ISMS) is gecertificeerd volgens ISO 27001 en wordt jaarlijks gecontroleerd door een onafhankelijke IT-auditor. Daarnaast wordt het vermogen van Visma om te voldoen aan ISMS en het kwaliteitsmanagementsysteem in VCDM gecontroleerd door een onafhankelijk auditkantoor in overeenstemming met ISAE 3402. Deze uitgebreide controle wordt ook jaarlijks uitgevoerd en wordt samengevat in een ISAE 3402 Type II-rapport. Onze aanpak voor het doorvoeren van veranderingen is continue integratie en continue implementatie (CI/CD). De methodologie evolueert voortdurend op het gebied van technologie, competentie en procedures. Op dit moment betekent dit dat wijzigingen continu worden geverifieerd en geïmplementeerd in onze staging-omgeving. Daar worden handmatige tests uitgevoerd, zowel intern in de ontwikkelingsafdeling als door vakexperts. Voor uitgebreidere wijzigingen maken we ook gebruik van pilotklanten die de wijzigingen gedurende een bepaalde periode in de normale bedrijfsvoering testen voordat ze voor alle klanten worden vrijgegeven. Https://www.visma.com/trust-centre Visma Cloud Delivery Model.

Wijzigingen en updates

Wijzigingen en updates leiden over het algemeen niet tot downtime. Als dit toch gebeurt, wordt dit uitgevoerd in vooraf gedefinieerde servicevensters en gemeld in overeenstemming met de SLA. We hebben een gemeenschappelijk, automatisch upgradeproces voor alle omgevingen. Frequente en kleine updates zorgen voor een laag risico op fouten bij elke wijziging. We maken steeds vaker gebruik van upgrades die direct in de productieomgeving worden geïmplementeerd, maar verborgen achter feature toggles, zodat de functionaliteit pas wordt geactiveerd wanneer deze klaar is voor de klant. In combinatie met geautomatiseerde tests zorgt dit voor een hoge stabiliteit, minder fouten en een snelle uitrol van nieuwe functies. Updates worden op verschillende manieren gecommuniceerd, afhankelijk van de omvang en reikwijdte van de wijziging:

Kleine wijzigingen, zoals bugfixes die geen invloed hebben op de klant of de gebruiker, worden gemeld via een update van de release notes.
Gemiddelde wijzigingen, zoals wijzigingen of toevoegingen aan werkprocessen of schermen, worden aangekondigd in release notes, meldingen op de startpagina, bijgewerkte gebruikersdocumentatie en op de Visma Community.
Grote veranderingen, zoals nieuwe belangrijke functionaliteiten of een ingrijpende wijziging in een werkproces, kunnen bovendien worden ondersteund door webinars en/of bijgewerkte e-learning.

Bij grote wijzigingen die training en/of configuratie van het systeem vereisen, betrekken we de klant bij het implementeren van de wijziging. De omvang hiervan varieert afhankelijk van het soort wijziging. Onze strategie voor het omgaan met eventuele fouten die tijdens updates kunnen optreden, is 'roll-forward'. Dit betekent dat we de fout willen corrigeren en updaten met een nieuwe versie, in plaats van terug te rollen. Alleen in uitzonderlijke gevallen en bij ernstige fouten is het relevant om terug te rollen.

Beveiliging en toegangsbeheer

Identum exploiteert zijn software voornamelijk via webapplicaties: https://mega.efeide.no, https://mega.eadm.no en https://mega.eADM.se. Alle toegang tot de webapplicaties wordt beveiligd door een captcha, gebruikersnaam en wachtwoord, evenals 2FA-authenticatie. De klant kan deze portalen zelf gebruiken voor administratie en selfservice, maar dan met andere toegangsrechten (zie het gedeelte over toegangsbeheer). We raden al onze klanten aan om authenticatie met MFA in te schakelen en we eisen dat alle toegang tot al onze systemen op beheerdersniveau met MFA gebeurt. We bieden aanmelding via gebruikersnaam/wachtwoord met MFA, ID-porten of SSO met Entra ID. Als SSO wordt gebruikt, eisen we dat de toegang wordt beveiligd op het niveau van afdelingsmanager en hoger. Het is een belangrijk principe om geen hogere toegang te verlenen dan nodig is.

We raden u daarom aan om restrictief te zijn met het verlenen van toegang op beheerdersniveau. Voor het overgrote deel van de dagelijkse werkzaamheden is toegang op servicedesk-niveau voldoende. Voor gebruikers die alleen een specifieke taak moeten uitvoeren, bijvoorbeeld het beheren van wachtwoorden voor een afdeling, is superuser-toegang voldoende. Alleen absoluut noodzakelijk personeel mag beheerdersrechten voor het systeem hebben, en dit moet als tijdelijk worden beschouwd. Dit principe beperkt de toegang tot persoonlijke gegevens en de mogelijkheden om toegangsrechten of bevoegdheden toe te kennen. Alle wijzigingen die via de webinterface worden uitgevoerd, worden automatisch geregistreerd. De klant wordt routinematig op de hoogte gebracht in geval van ongewenste incidenten, naast het dagelijkse statusrapport van onze systemen.

We benadrukken dat we aanbevelen om de toegang tot eFeide en eADM te beveiligen met tweefactorauthenticatie voor alle gebruikers met beheerdersrechten; deze functionaliteit maakt deel uit van de oplossingen. Ons beleid voor toegangsbeheer houdt in dat gebruikers geen hoger toegangsniveau moeten krijgen dan ze dagelijks nodig hebben; een hoger toegangsniveau wordt beoordeeld op basis van de behoefte. Beheerdersrechten mogen alleen worden toegekend aan een select aantal gebruikers die een training in het gebruik van het systeem hebben gevolgd. Een voorbeeld hiervan is dat de eerstelijnsondersteuning bij de klant toegang heeft tot de servicedesk, terwijl alleen de derdelijnsondersteuning toegang heeft tot het systeem op beheerdersniveau. Identum raadt al onze klanten aan dit beleid te volgen bij het opstellen van regels voor automatisch of handmatig toegangsbeheer tot bedrijfssystemen, derde partijen, enz. via eADM.

Intern personeel

Dit geldt ook voor de eigen medewerkers van Identum. Medewerkers krijgen alleen de toegang die nodig is voor hun functie en rol. Wanneer medewerkers het bedrijf verlaten, wordt alle toegang onmiddellijk ingetrokken. Identum maakt geen gebruik van hulp van externe derde partijen en hanteert een beleid waarbij alleen medewerkers die actief betrokken zijn bij de werking en gebruikersondersteuning van de oplossing toegang hebben tot de gegevens van klanten. De verschillende toegangsniveaus en rollen binnen Identum zijn duidelijk gedefinieerd en worden regelmatig gecontroleerd en getest op hun noodzaak in overeenstemming met ISO27001. Alle wijzigingen die in het systeem worden aangebracht, worden op dezelfde manier geregistreerd als de eigen gebruikers van de klant. Als een medewerker van Identum dus toegang verleent tot een bedrijfssysteem bij een klant, wordt dit geregistreerd in de geschiedenis van de gebruiker die de toegang heeft gekregen. Het is niet mogelijk om gebruikersgegevens tussen de verschillende instanties in de gebruikersinterface te kopiëren, alleen sjablonen en regelsets.

Toegangscontrole

Zowel eFeide als eADM ondersteunen verschillende methoden voor gebruikersaanmelding, waaronder tweefactorauthenticatie. We bieden (uiteraard) FEIDE-aanmelding, ID-porten, ADFS/LDAP, SSO met Entra ID/EntraID, SSO met Google Workspace en andere SAML2.0-autorisatieoplossingen. We verwachten van klanten dat ze SSO-aanmelding met MFA beveiligen; het wordt afgeraden om toegang tot eADM en eFeide zonder tweefactorauthenticatie te verlenen, zelfs niet op het niveau van werknemers/afdelingsmanagers. Op servicedesk- en beheerdersniveau eisen we van onze klanten dat ze SSO met MFA beveiligen of als alternatief ID-porten gebruiken. Toegang tot het systeem kan automatisch worden verleend op basis van regelsets of handmatig voor de individuele gebruiker. We raden aan om beheerders alleen handmatig en op basis van behoeften toegang te verlenen. Toegang kan met of zonder vervaldatum worden verleend en het systeem heeft een oplossing voor zowel actieve als passieve toegangscontrole op bepaalde tijdstippen. De verschillende toegangsniveaus kunnen worden beheerd op groeps-, rol- en persoonlijk niveau. Zo kan de aanmelding bij de gebruikersinterface voor eFeide zo worden geregeld dat iedereen die toegang heeft tot persoonlijke gegevens van andere gebruikers, zich moet aanmelden met tweefactorauthenticatie, terwijl studenten (die alleen hun eigen gegevens kunnen zien) zich kunnen aanmelden zonder tweefactorauthenticatie.

Werknemers

Het systeem houdt er ook rekening mee dat één en dezelfde gebruiker verschillende rollen kan hebben in verschillende afdelingen, met verschillende behoeften en toegangsrechten. Een medewerker kan alle beschikbare informatie over zichzelf bekijken en zijn wachtwoord wijzigen. Een afdelingsmanager ziet alleen zijn medewerkers. Als een gebruiker afdelingsmanager is en tegelijkertijd op een ander niveau in de organisatie werkzaam is, heeft deze gebruiker alleen beheerdersrechten voor de afdeling waar hij/zij afdelingsmanager is. In de andere afdeling heeft hij/zij alleen gewone medewerkerstoegang. De zes rollen bieden toegang tot functionele gebieden, onderliggende informatie en functionaliteit.

Geschiedenis, logboeken en toegangsbeoordeling in eADM

eADM registreert alle wijzigingen die op objectniveau worden aangebracht, d.w.z. voor gebruikers, groepen en afdelingen. De logboeken zijn beschikbaar voor iedereen met beheerdersrechten in de oplossing. Zowel wijzigingen die afkomstig zijn van bronsystemen als wijzigingen die in eADM worden aangebracht, worden geregistreerd. Het systeem registreert ook alle gegevens die naar de verschillende bronsystemen worden verzonden, zodat u een volledig overzicht hebt van welke gegevens waarheen zijn geëxporteerd. Alle vermeldingen worden gelogd met object-ID, datum/tijd, de reden voor de wijziging, wie de wijziging heeft uitgevoerd als het een handmatige wijziging betreft, de vorige waarde en de nieuwe waarde. Alle wijzigingen in de systeeminstellingen zelf worden ook gelogd. Dit betekent alle wijzigingen in regelsets, synchronisatiesjablonen, berichtenstromen, toegangscontroles en workflows. Alle logboeken worden opgeslagen, versleuteld en digitaal en fysiek beveiligd volgens dezelfde normen als de andere gegevens van Identum. Logboeken kunnen door geen enkele gebruiker worden gewijzigd, ook niet door Identum's eigen "superduper" beheerdersrol. Logboeken kunnen worden geëxporteerd voor verwerking in systemen van derden. Alle incidenten, logboeken enz. kunnen worden ingesteld om een melding per e-mail of sms te activeren wanneer ze zich voordoen. Het systeem kan bijvoorbeeld melding maken van specifieke foutmeldingen in verband met export naar gevoelige systemen of wanneer een gebruiker zich aanmeldt met een IP-adres buiten een bepaald geografisch gebied.

Registratie van wijzigingen in gebruikersgegevens, rechten en toegangen

In de gebruikersinterface van eADM kan men ook alle toegangen en licenties zien die aan een gebruiker zijn toegewezen, zowel in eADM als in bijbehorende doelsystemen. De geschiedenis laat zien wanneer een toegang of licentie is toegewezen, of deze automatisch is toegekend op basis van een reeks regels of handmatig door een gebruiker. Men kan zien waartoe een gebruiker toegang heeft in een case-/archiefsysteem en om welk type toegang het gaat. eFeide registreert alle wijzigingen in rechten, naast wijzigingen in gebruikersgegevens en wachtwoorden. Als een toegang wordt verleend op basis van een reeks regels, kan men verder nagaan wie de wijziging in de regels heeft aangebracht die de toegang heeft geactiveerd.

Beveiligings- en wachtwoordlogboeken

Beveiligingslogging in eADM registreert alle inlogpogingen, zowel geautoriseerde als ongeautoriseerde, met vermelding van wie, tijd, locatie (IP), type authenticatie en status. Daarnaast worden alle foutmeldingen geregistreerd, met vermelding van methode (bijv. type API-oproep), tijd, gebruiker en IP. Alle wachtwoordwijzigingen worden geregistreerd, met tijd- en datumstempel, hoe de wachtwoordwijziging is doorgevoerd, wie de wachtwoordwijziging heeft geïnitieerd, of het wachtwoord verder is geëxporteerd naar andere doelsystemen, en met eventuele foutmeldingen.

Toegang door derden

De klant bepaalt zelf via de gebruikersinterface wie toegang heeft tot klantgegevens in eADM. De gegevensstroom naar doelsystemen wordt geregeld via synchronisatiesjablonen, waarbij de klant zelf bepaalt welke gegevens aan elke individuele derde partij worden getoond/overgedragen. eADM staat derde partijen niet toe om naar eigen goeddunken gegevens uit het systeem op te halen, tenzij de klant deze toegang specifiek verleent via de API. Zie ook het punt over "Penetratietesten".

Wachtwoordbeheer

In eADM en eFeide worden alle systeemwachtwoorden (geheimen) beveiligd met Rijndael AES 256-bits encryptie. Wachtwoorden voor gebruikers worden opgeslagen in onze LDAP-database, die gebruikmaakt van standaard Active Directory-technologie en ze daarom gehasht en versleuteld opslaat. Bij het overdragen van wachtwoorden (geheimen) wordt altijd end-to-end-encryptie via TLS gebruikt. Dit geldt voor alle gegevensoverdracht van en naar de oplossing. Wachtwoorden zijn niet toegankelijk voor gebruikers in eADM of eFeide, of het nu gaat om de werknemers zelf, afdelingsmanagers of beheerders. De enige uitzondering zijn de initiële wachtwoorden, omdat deze natuurlijk leesbaar en afdrukbaar moeten zijn en naar de werknemer moeten worden verzonden. Na de eerste aanmelding wordt dit wachtwoord gewijzigd en versleuteld opgeslagen. Vanaf dat moment kan niemand het meer zien; het kan alleen worden gewijzigd. Initiële wachtwoorden voor gebruikers worden aangemaakt in eADM/eFeide wanneer een gebruikersaccount wordt aangemaakt. Het wachtwoord wordt gegenereerd volgens regelsets die zijn opgesteld op basis van de eisen van de klant, bijvoorbeeld 16 tekens, hoofdletter, minimaal 1 speciaal teken.

Wanneer een gebruikersaccount wordt aangemaakt in doelsystemen zoals AD, Entra ID of bedrijfssystemen, kunnen de gebruikers worden aangemaakt met hetzelfde initiële wachtwoord. Dit wordt versleuteld overgedragen. Wachtwoorden kunnen in onze oplossingen worden gewijzigd en in realtime naar de doelsystemen worden overgedragen. Er kunnen vereisten worden ingesteld dat gebruikers hun initiële wachtwoord moeten wijzigen bij het inloggen op Entra ID, AD en Google voordat ze mogen inloggen. Identum heeft een oplossing om wachtwoorden te resetten via sms of via authenticatie via ID-porten, en we raden ID-porten ten zeerste aan. Alle wachtwoordwijzigingen worden geregistreerd, met tijd- en datumstempel, hoe de wachtwoordwijziging is uitgevoerd, wie de wachtwoordwijziging heeft geïnitieerd, of het wachtwoord verder is geëxporteerd naar andere doelsystemen, en met eventuele foutmeldingen. In eADM kunnen afdelingsmanagers wachtwoorden voor hun medewerkers wijzigen, hetzij door een nieuw wachtwoord toe te wijzen, hetzij door een gegenereerd wachtwoord via sms naar de medewerker te sturen als er een mobiel telefoonnummer voor de gebruiker is geregistreerd.

We raden echter aan dat werknemers dit zelf doen via het portaal voor vergeten wachtwoorden. Servicedeskgebruikers en beheerders in eADM kunnen wachtwoorden voor alle gebruikers wijzigen, door een nieuw wachtwoord toe te wijzen of een gegenereerd wachtwoord via sms naar de werknemer te sturen als er een mobiel telefoonnummer voor de gebruiker is geregistreerd. We raden echter aan dat werknemers dit zelf doen via het portaal voor vergeten wachtwoorden. In eFeide kunnen leraren wachtwoorden voor leerlingen wijzigen, schoolbeheerders kunnen wachtwoorden voor leerlingen en leraren op hun school wijzigen en gemeentelijke beheerders kunnen wachtwoorden voor alle gebruikers wijzigen. Feide ondersteunt geen gedwongen wachtwoordwijziging.

Beveiliging en Feide-diensten

In eFeide kunnen beheerders het inloggen met MFA voor bepaalde Feide-diensten voor werknemers beheren. Vereisten voor MFA voor Feide-diensten kunnen zowel individueel als voor hele scholen worden ingesteld. Een tweefactormethode is wat een gebruiker gebruikt om zijn identiteit te bewijzen wanneer een Feide-dienst tweefactorauthenticatie vereist. Feide heeft vier verschillende tweefactorauthenticatiemethoden beschikbaar: aanmelden via ID-porten, code via sms, codeblad en authenticatorclient (MS Authenticator of Google Authenticator). Welke Feide-diensten met MFA moeten worden beveiligd, is aan de individuele klant; onze vuistregel is dat alle Feide-diensten waar persoonlijke informatie over leerlingen en/of werknemers wordt opgeslagen, met MFA moeten worden beveiligd. Een cloudgebaseerd schooladministratiesysteem is een voorbeeld van een systeem dat naar onze mening met tweefactorauthenticatie moet worden beveiligd.

Export van persoonsgegevens naar doelsystemen

Zowel eADM als eFEIDE bevatten persoonsgegevens en men moet voorzichtig zijn met welke gegevens naar welke doelsystemen worden geëxporteerd. Een vuistregel is dat u alleen de minimale hoeveelheid gegevens moet exporteren die het doelsysteem nodig heeft. Daarnaast moet een behoefteanalyse worden uitgevoerd voor gegevens zoals nationale identiteitsnummers, privécontactgegevens, salarisinformatie, enz.

Gebruik van nationale identiteitsnummers in Active Directory

Wij raden aan om, indien een nationaal identiteitsnummer wordt gebruikt als uniek identificatiekenmerk in AD (bijvoorbeeld in de kenmerken employeeID of employeeNumber), dit te versleutelen (hiervoor is in beide systemen functionaliteit beschikbaar) of te verbergen, zodat alleen beheerders deze kenmerken kunnen bekijken: Hoe gebruikerskenmerken in Active Directory te verbergen.

Gebruik van nationale identiteitsnummers in Entra ID / Entra ID

We raden het gebruik van nationale identiteitsnummers als uniek identificatiekenmerk in Entra ID af, omdat dit veld niet kan worden beschermd of verborgen. Gebruik in plaats daarvan personeelsnummers of een andere unieke nummerreeks.

Samenvatting voor AI en zoeken

Dit document beschrijft het uitgebreide beveiligingskader voor de eADM- en eFeide-producten van Identum. Het behandelt de ontwikkelingsfilosofieën 'Privacy by Design' en 'Zero Trust', ISO 27001-certificering via het Visma Cloud Delivery Model en veilige hosting in Microsoft Entra ID. Het kader omvat continue monitoring van bedreigingen door het SOC van Visma, jaarlijkse penetratietests, robuuste back-up- en noodherstelplannen en gedetailleerd beleid voor versleuteling, toegangscontrole en GDPR-conforme gegevensverwerking.