Huidige versie van 24 dec 2025 om 11:19

Versie	datum	Auteur	Versie informatie
0.1	20 april 2016	Dirk Linden	Initiële versie
1.0	9 augustus 2016	Dirk Linden	Commentaar Marianne Mulder verwerkt en definitief gemaakt
1.1	1 augustus 2017	Dirk Linden	Aanvullingen op 3.2, 4.3.1.2 en 8.3.2
1.2	10 juli 2019	Jordy van den Elshout	Review gehele document. Belangrijkste wijzingen: scope, wachtwoordbeleid, back-up retentie, eisen logging & monitoring, interval leveranciersbeoordeling en eisen voor leveranciersonafhankelijkheid.
1.3	31 mei 2022	Jordy van den Elshout	Review gehele document, waarbij met name aanscherpingen en aanvullingen zijn gemaakt. Daarnaast inhoudelijke wijzigingen en aanvullingen m.b.t. wachtwoordcomplexiteit, authenticatie met 2FA en sleutels, scheiding in netwerken en encryptie(sleutels).
1.4	19 april 2023	Jordy van den Elshout	Aanscherpingen n.a.v. onduidelijkheden en vragen aan het IBP-kernteam, zoals m.b.t. toegang testomgeving voor het ontwikkelteam.
1.5	14 februari 2024	Jordy van den Elshout	Aanscherpingen n.a.v. onduidelijkheden en vragen aan het IBP-kernteam, zoals domeinnaambeheer, authenticatie(uitgifte), geoblocking en gebruik extern verwijderbare media. ‘Tag- en accountbeleid’ hierin verwerkt.
1.6	12 juni 2025	Iris van den Brink	Totale review nav ISO27001:2022 transitie
1.7	2 okt 2025	Dirk Linden	Diverse aanpassingen, oa verduidelijking OTAP beleid

Goedkeuring

Dit beleid is goedgekeurd door de onderstaande personen:

Naam	Functie	Versie	Datum
MT		1.5	24-4-2024
Dirk Linden	CTO	1.6	12-6-2025
Dirk Linden	CTO	1.7	19-11-2025
MT		1.7

Document Classificatie

Classificatie	Beschrijving
Vertrouwelijk	Mag worden gedeeld op basis van “Need to Know”

Inleiding

IT speelt een cruciale rol in de informatievoorziening binnen Kennisnet. Onder informatievoorziening verstaan we het dynamische samenspel van mensen, processen en technologie die gezamenlijk de informatiebehoeften van de organisatie ondersteunen. In dit kader richt IT zich voornamelijk op de technische systemen die dit proces mogelijk maken. Het beleid van Kennisnet met betrekking tot IT is vastgelegd in dit document. Dit document richt zich uitsluitend op de beleidskeuzes, terwijl de uitwerking in specifieke maatregelen te vinden is in de verschillende processen, procedures en werkinstructies op de daarvoor afgesproken locaties.

Verantwoorde inzet van IT en goede zorg voor informatieveiligheid gaan hand in hand. Veel van de beleidskeuzes in dit IT-beleid zijn daarom geïnspireerd door maatregelen uit de ISO norm voor informatiebeveiliging: ISO27001. IT inzet conform dit IT-beleid is daarmee een voorwaarde voor succesvolle certificering op deze norm.

Het beleid dient te worden gevolgd. Waar dit niet mogelijk is, moet expliciet toestemming gevraagd worden aan de CTO. De CTO beoordeeld en accordeert de uitzondering na raadpleging van met het IBP-kernteam en eventuele andere belanghebbenden. Indien de CTO een uitzondering aanvraagt, dient deze te worden voorgelegd aan de Directeur Operations. De uitzondering wordt expliciet vastgelegd, waarbij ook een evaluatiemoment voor de uitzondering wordt vastgelegd.

Doelgroep

De primaire doelgroep van dit document bestaat uit de personen binnen Kennisnet die verantwoordelijk zijn voor de ontwikkeling of het beheer van IT van Kennisnet. Binnen Kennisnet valt alle IT onder de verantwoordelijkheid van de directeur operations (DO).

Het IT-beleid wordt bij voorkeur jaarlijks (en ten minste elke drie jaar) herzien door de Chief Technology Officer (CTO) en DO. De CTO is verantwoordelijk voor het IT-beleid en stelt de inhoudelijke kaders voor, welke door de DO, namens het MT, worden uitgedragen als beleid. Het IBP-kernteam heeft een adviserende rol bij het wijzigen van het IT-beleid. Wanneer wijzigingen in dit beleid grote gevolgen kan hebben voor de praktijk, dan worden (managers van) uitvoerende teams geconsulteerd om te waarborgen dat het beleid geïmplementeerd kan worden. Het IT-beleid wordt vastgesteld door het Management Team van Kennisnet (MT).

De domeinmanagers zijn binnen hun domein verantwoordelijk voor de implementatie en uitvoer van het IT-beleid. Dit betekent ook dat zij moeten zorgdragen dat mensen binnen hun domein, bijvoorbeeld productmanagers, bij totstandkoming van diensten en andere werkzaamheden zich houden aan het IT-beleid.

Scope

Het IT-beleid heeft betrekking op:

Het Kennisnet kantoor;
Externe locaties met infrastructuur van Kennisnet zoals een datacenter/OCC;
Alle medewerkers (intern en extern) van Kennisnet;
De diensten van Kennisnet;
De diensten die Kennisnet voor derden levert;
Leveranciers van Kennisnet;
Alle informatiesystemen, netwerken, servers en devices die worden gebruikt voor Kennisnetvoorzieningen of werkzaamheden.

Structuur

Het IT-beleid bestaat uit verschillende aandachtsgebieden. Voor elk aandachtsgebied zijn de volgende elementen beschreven:

Doel: hierin worden de doelstellingen van dat stuk beleid vastgelegd;
Uitgangspunten: deze geven de kaders en context aan waarbinnen wordt gewerkt;
Beleid: hierin staat het beleid uitgewerkt in deelonderwerpen van het aandachtsgebied.

Beheer

Doel

Het beheer van IT binnen Kennisnet moet de niet functionele kwaliteit (zoals veiligheid en continuïteit) van operationele IT waarborgen.

Uitgangspunten

Alle IT die door (medewerkers van) Kennisnet wordt ingezet moet worden beheerd, inzet van onbeheerde IT is niet toegestaan.
Beheer moet volgens een herhaalbare, controleerbare en overdraagbare werkwijze worden uitgevoerd;
Er mag geen of slechts beperkte afhankelijkheid zijn van specifieke personen, kennis of technologie;
Er moet een gecontroleerde inbeheername zijn; de overgang van ontwikkeling naar beheer is aan expliciete voorwaarden gebonden;
Domeinnaambeheer dient georganiseerd te zijn om veiligheid van de IT te beschermen; ook wanneer domeinnamen worden beëindigd of overgedragen.
IT moet vanuit beheer worden beschermd om beschikbaarheid, integriteit en vertrouwelijkheid te waarborgen.
Er moet een responsible disclosure procedure zijn om externen staat te stellen kwetsbaarheden te melden

Beleid

Intern en extern beheer

Het beheer wordt hoofdzakelijk intern uitgevoerd door de afdeling Exploitatie, echter het beheer kan ook extern door leveranciers uitgevoerd worden. Al het beheer dient, zowel intern als extern, volgens dit beleid uitgevoerd te worden.

IT die niet door Kennisnet wordt beheerd – zoals BYOD of gratis/persoonlijk gebruikte tools/voorzieningen – blijft onder beheer van de eigenaar; inzet is alleen toegestaan volgens het beleid ‘Aanvaardbaar gebruik van bedrijfsmiddelen’ (vooraf goedgekeurde tools).

Voorwaarden voor inbeheername

Van alle IT moet minimaal worden vastgelegd:

Wie de eigenaar is van het systeem (de verantwoordelijke)
Onder welk domein het valt
Wie de productmanager, technisch specialist en aangewezen architect is
Wat de BIV-classificatie is (welk niveau van betrouwbaarheid, integriteit en vertrouwelijkheid is van toepassing)
Of het een kritieke dienst is (beschikbaarheidsniveau is hoog)

Alleen IT die aan (minimale) voorwaarden voldoet, kan en mag in beheer genomen worden:
De diensteigenaar dient de tijdens de voorbereidingsfase de (minimale) voorwaarden op te vragen bij de afdeling Exploitatie. Deze stelt de voorwaarde vast op basis van dit IT-beleid en deze worden vastgelegd in het product realisatiedocument. Op basis van deze eisen zal bij inbeheername worden gecontroleerd.
Er moet aantoonbaar worden voldaan aan de, op het Certificeringsschema IBP ROSA gebaseerde, IB maatregelen die voortkomen uit de BIV-classificatie van de applicatie.

Domeinnaambeheer

Er dient een proces voor domeinnaambeheer te zijn waarin minimaal is vastgelegd:

Welke rollen en verantwoordelijkheden er zijn
Op welke wijze de registratie, beëindiging en overdracht plaatsvindt
Aan welke beveiligingseisen domeinnamen moeten voldoen, ook wanneer deze niet gebruikt worden (‘geparkeerde domeinnamen’)

Het proces moet ervoor zorgen dat:
Domeinnamen zijn beveiligd conform het beleid
Strikte procedures worden gevolgd bij beëindiging en overdracht van domeinnamen

Gedocumenteerde bedieningsprocedures

Beheerders moeten toegang hebben tot gedocumenteerde procedures.

Deze procedures moeten ervoor zorgen dat:

Beheerwerkzaamheden altijd op dezelfde wijze uitgevoerd worden;
Beheerwerkzaamheden door meerdere personen uitgevoerd kunnen worden, onafhankelijk van zeer specifieke kennis.

Documentatie moet juist en actueel zijn en de status ervan bekend zijn.

Kloksynchronisatie

De klokken van alle productiesystemen binnen Kennisnet moeten worden gesynchroniseerd met dezelfde referentietijdbron, die maximaal stratum 3 mag zijn.

Logging en monitoring

Er dient logging plaats te vinden om (gevoelige) gebeurtenissen te kunnen registreren en beoordelen. Het doel van logging is het mogelijk maken van (forensisch) onderzoek na een incident of calamiteit en het kunnen instellen van alarmering en monitoring.

Voor systemen waar logging in plaatsvindt of wordt opgeslagen, gelden de volgende eisen:

Logfaciliteiten en informatie in logbestanden moeten worden beschermd tegen vervalsing en onbevoegde toegang;
De kwaliteit van logging dient te voldoen aan best practices (bijvoorbeeld OWASP Logging cheat sheet).

Gebeurtenissen die ten minste gelogd moeten worden zijn:

Toegang tot de IT-toepassingen moeten centraal worden gelogd; in geval van persoonsgegevens ook het lezen en wijzigen daarvan;
Configuratie- en autorisatiewijzigingen dienen centraal te worden gelogd;
Het gebruik van speciale toegangsrechten moet worden gelogd;
De toegang tot broncode moet gelogd worden;
Voor voorzieningen die Kennisnet aanbiedt, moet applicatielogging plaatsvinden in lijn met de IB maatregelen in Joget.

De wijze waarop logbestanden beoordeeld worden, dient te zijn vastgelegd en moet voldoen aan de volgende eisen:

Logbestanden moeten regelmatig worden beoordeeld;
Waar mogelijk moet gebruikt worden gemaakt van automatische controle op afwijkende patronen (frequentie, oorsprong, etc.);
Er moet een afweging worden gemaakt om te bepalen welke logging met een hogere frequentie en prioriteit beoordeeld moet worden; hierbij dient logging van toegang en wijzigingen altijd hoge prioriteit hebben.

Gebruik van systeemhulpmiddelen

Beheer van IT wordt vaak uitgevoerd met behulp van zogenaamde ‘beheertools’. Dit zijn systeemhulpmiddelen die in staat zijn om beveiligingsmaatregelen van toepassingen en systemen te omzeilen.

Hiervoor gelden de volgende regels:

Gebruik van systeemhulpmiddelen moet herleidbaar zijn naar natuurlijke personen. Dit betekent dat gebruik hiervan moet worden gelogd. Daarnaast dient er extra aandacht te worden besteed aan het toepassen van identificatie, autorisatie en authenticatie conform dit IT-beleid.
Gebruik van systeemhulpmiddelen moet beperkt zijn tot het laagst aantal betrouwbare bevoegde gebruikers dat praktisch haalbaar is. Dit betekent dat autorisatie tot het gebruik beperkt is tot medewerkers van Exploitatie, en deze autorisatie expliciet gegeven dient te worden.

Capaciteit

Het gebruik van IT moet worden gemonitord en afgestemd om (toekomstige) capaciteitseisen en prestaties te kunnen waarborgen. Op basis van de classificatie voor beschikbaarheid dienen de maatregelen voor ‘Capaciteit beheer’ - conform het Certificeringschema ROSA IBP – hiervoor te worden ingevuld. De daadwerkelijke monitoring van de capaciteit wordt door Exploitatie uitgevoerd.

Continuïteit

Voor alle IT moet zijn vastgelegd wat de effecten zijn op de continuïteit van de bedrijfsvoering bij de uitval van dit specifieke onderdeel. Het onderdeel wordt daarmee als wel of niet kritiek voor de bedrijfsvoering aangemerkt. Dat betekent dat elke applicatie gekoppeld moet zijn aan een dienst. Wanneer een applicatie een hoge beschikbaarheid kent, is de dienst kritiek.

Op basis van deze analyse moeten passende maatregelen getroffen zijn om de continuïteit van de dienstverlening van Kennisnet te waarborgen.

Serverbeheer

Beheer op servers en middleware mag alleen worden uitgevoerd onder verantwoordelijkheid van Exploitatie. Dit beheer omvat minimaal de volgende elementen:

Installatie en onderhoud van hardware in het geval van fysieke servers
Installatie en updaten van software
Configuratiewijzigingen
Inrichten en onderhoud monitoring

Daar waar iemand anders dan Exploitatie dergelijke werkzaamheden moet uitvoeren, dient dit te worden gedaan onder verantwoordelijkheid van een Exploitatie medewerker welke de kwaliteit van de werkzaamheden waarborgt.

Configuratiebeheer

Er moet beheer plaatsvinden ten aanzien van netwerk, voorziening, hardware- en softwareconfiguraties:
Kennisnet laptops dienen bij ingebruikname te worden voorzien van een standaardconfiguratie;
Hard- en software configuraties dienen te worden geborgd, bewaakt en waar mogelijk uitgerold te worden middels continuous configuration automation tools;
Configuratiewijzigingen dienen te voldoen aan het beleid ten aanzien van wijzigingsbeheer;
Beveiligingsconfiguraties moeten risico gestuurd ontworpen worden;

Voor beveiligingsconfiguraties dient de wijzigingsprocedure aanvullende eisen te bevatten.

Wijzigingsbeheer

Veranderingen in informatieverwerkende faciliteiten en -systemen dienen te worden beheerst. Wijzigingsbeheer moet daarom voorzien in de expliciete vraag of de verandering impact heeft op veiligheid (informatiebeveiliging en privacy) en continuïteit van de IT.

Er dient een gedocumenteerde wijzigingsprocedure aanwezig te zijn en gevolgd te worden, waarin ten minste het volgende is opgenomen:

Het plannen en testen van veranderingen;
Een formele goedkeuringsprocedure;
Communicatie aan de betrokken personen;
Uitwijk- en herstelprocedures voor niet-succesvolle veranderingen.
Classificatie van de wijziging en daaruit volgend eisen met betrekking tot vastlegging en herleidbaarheid.

Incidentbeheer

Er dient een incidentproces zijn waarin ten minste is vastgelegd: de betrokken rollen, het meldingsmechanisme en de wijze waarop continue verbetering gewaarborgd is.

Back-up

Regelmatig moet een back-up van informatie, software en systeemafbeeldingen worden gemaakt, welke ook bruikbaar is om te worden teruggezet voor Disaster Recovery. De maximale tijd tussen back-ups mag niet langer zijn dan de RPO die is volgt uit de BIV-classificatie van de applicatie of voorziening. Voor de back-ups die ten behoeve van Disaster Recovery worden gemaakt geldt een retentietijd van 30 dagen. Back-ups dienen (automatisch) gewist te worden wanneer de retentietijd is verlopen.

Voor het herstellen van individuele items geldt als uitgangspunt dat dit altijd binnen de toepassing zelf gebeurt met bijvoorbeeld versiebeheer, archivering of de prullenbak. De back-up is niet bedoeld om invulling te geven aan (wettelijke) bewaartermijnen. Dat moet binnen de toepassing worden opgelost.

Voor alle IT moet (a.d.h.v. de BIV) zijn vastgelegd:

De recovery point objective (RPO): naar welk punt in de tijd moet je terug kunnen? (gegevensverlies)
De recovery time objective (RTO): hoe snel moet het weer in de lucht zijn? (down time)
De version retention objective (VRO): hoe veel versies van de back-up en hoe lang deze worden bewaard? Standaard is dit 30 dagen.
- Office 365 betreft een uitzondering: in een risicoanalyse is vastgesteld dat voor de Office 365 suite een langere VRO gewenst is, daarom is deze ingesteld op 13 maanden.
De geographic redundancy objective (GRO): hoe vaak en op welke afstand wordt er een off-site back-up gemaakt? Standaard elke 24 uur en minimaal op 10 km afstand.
Wanneer het terugzetten van back-up wordt getest en hoe deze test is verlopen (evaluatie). Deze informatie wordt gebruikt binnen de herstelprocedure.

Deze waardes gelden onder normale omstandigheden. In geval van calamiteiten kan hiervan afgeweken worden.

Verwijderbare media

Gegevens op verwijderbare media zijn meestal vertrouwelijk of geheim. Daarom moeten deze ten alle tijden beschermd zijn tegen onbevoegde toegang, misbruik of corruptie. Daarnaast kan verwijderbare media Malware verspreiden. Daarom gelden voor verwijderbare media de volgende regels:

Er moet een gedocumenteerde procedure zijn voor het verwijderen en afvoeren van verwijderbare media, die minimaal voorziet in eisen ten aanzien van het onherstelbaar verwijderen van de inhoud;
Er moeten gedocumenteerde procedures zijn voor de opslag en het gebruik van verwijderbare media, die maatregelen bevatten om gegevensverlies en misbruik te voorkomen;
Verwijderbare media die worden vervoerd:
- Dienen zelf beveiligd te zijn door middel van versleuteling;
- Dienen alleen vervoerd te worden door een Kennisnet medewerker of daartoe bevoegde beheerders of koeriers- en transportdiensten.
Extern verwijderbare media (zoals een USB-stick of Hot-pluggable Storage) waarvan de herkomst onbekend is of gebruikt is door een onbekend apparaat, mogen niet (meer) gebruikt worden.

Opslag van broncode

Onder broncode wordt verstaan zowel de broncode van de software zelf als de (broncode van) door Kennisnet gemaakte libraries en configuraties.

De opslag van broncode moet voldoen aan de volgende regels:

Broncode moet in een centrale repository worden opgeslagen;
Waar technisch mogelijk mag de broncode niet worden opgeslagen op productieservers waar de software zelf draait;
De toegang tot broncode moet beperkt zijn tot Exploitatie medewerkers en andere medewerkers die dit voor hun werk nodig hebben; de productowner (eigenaar van de broncode) bepaalt voor wie dit van toepassing is.

Technische beveiligingsmaatregelen

Er dienen technische en organisatorische maatregelen getroffen te worden ter bescherming van systemen van Kennisnet. Deze maatregelen moeten er ten minste voor zorgen dat:

Systemen beschermd zijn tegen virussen en malware;
Berichtenverkeer beschermd is tegen onbevoegde toegang, wijziging of spam;
Voorzieningen die informatie versturen via openbare netwerken beschermd zijn (bijvoorbeeld door versleutelde verbindingen, server identificatie).

Bescherming van systemen tegen virussen en malware bestaat ten minste uit de volgende elementen:

Gebruikersapparatuur dient voorzien te zijn van een (up-to-date) anti-malware programma. Voor beheerde laptops dient Interne Automatisering dit te verzorgen, bij BYOD is de gebruiker hiervoor verantwoordelijk.
Uploads van bestanden moeten door beheer worden gemonitord en bij verdachte bestanden geblokkeerd
Medewerkers moeten regelmatig worden gewezen op risico’s op malwarebesmetting, zoals via phishingmails, onveilige bijlagen of schadelijke websites Er moeten mailfilters worden toegepast om verdacht mailverkeer te monitoren en blokkeren. Deze filters worden regelmatig geactualiseerd.

Het kantoornetwerk dient beschermt te worden tegen malafide verkeer door middel van webfiltering. Er dient aan de hand van de volgende uitganspunten bepaald te worden welke webfiltering wordt toegepast:

Toegang tot aanstootgevende, illegale of potentieel schadelijke websites dient te worden geblokkeerd
Toegang tot het Kennisnetnetwerk vanuit risicovolle IP-adressen dient te worden geblokkeerd
Webfiltering wordt periodiek herzien op basis van dreigingsinformatie en gebruikspatronen

Afstemming van testen/toetsen

Testen en toetsen die impact zouden kunnen hebben op de continuïteit en integriteit van de voorziening, zoals capaciteitstesten, veiligheidstesten en audits, moeten altijd in overleg met Exploitatie en dienstverantwoordelijke worden uitgevoerd. Hiermee wordt de continuïteit en integriteit van dienstverlening beschermd.

Beheer van technische kwetsbaarheden

Het is belangrijk dat kwetsbaarheden (tijdig) worden opgemerkt. Beheerders en verantwoordelijken van systemen moeten kwetsbaarheden melden als incident, niet alleen direct oplossen. Dat geldt ook wanneer een beveiligingsincident zich voordoet.

Er dienen (al dan niet automatisch) actief en regelmatig interne toetsen uitgevoerd te worden op beveiligingsmaatregelen, bekende kwetsbaarheden, code kwaliteit en code actualiteit.

Personen die kwetsbaarheden in Kennisnet systemen ontdekken, moeten deze kunnen melden via een vaste laagdrempelige procedure zonder angst dat Kennisnet juridische stappen onderneemt naar aanleiding van de melding. Waar IT is ontsloten via het internet, moet deze procedure daarom in de vorm van de ‘responsible disclosure’ procedure (onderdeel van het contractenraamwerk) kenbaar gemaakt worden in de footer van de publieke pagina. We volgen “Coordinated Vulnerability Disclosure: de leidraad” van het NSCS en het template van responsibledisclosure.nl om invulling te geven aan het proces.

Toegangsbeveiliging

Doel

Het doel van toegangsbeveiliging is het beschermen van bedrijfsmiddelen tegen ongeoorloofde toegang, wijziging, vernietiging en openbaring. Dit geldt in het bijzonder voor vertrouwelijke en geheime gegevens zoals persoonsgegevens.

Uitgangspunten

Identificatie, authenticatie en autorisatie moeten plaatsvinden volgens vooraf gestelde regels;
Uitgifte van authenticatiemiddelen dient op een veilige en gecontroleerde manier te gebeuren;
Toegang tot gegevens en systemen van Kennisnet dient standaard te worden geblokkeerd tenzij dit expliciet is toegelaten (default deny);
Vaste medewerkers moeten altijd een Kennisnet-account krijgen en gebruiken; externe medewerkers alleen wanneer zij toegang moeten hebben tot interne systemen;
Er dient alleen toegang te worden verleend tot die gegevens en systemen die nodig zijn voor de uitoefening van taken en verantwoordelijkheden (least privilege);
Alle verleende toegang moet regelmatig worden herzien;
Verleende toegang moet worden afgesloten wanneer deze niet meer noodzakelijk is;
Alle acties en gebeurtenissen welke gevolg zijn van gebruikershandelingen moeten tot een natuurlijk persoon kunnen worden herleid;
Acties waarbij speciale toegangsrechten zijn vereist moeten kunnen worden teruggeleid naar een natuurlijk persoon, specifiek tijdstip en locatie;
Wachtwoorden dienen voldoende sterk te zijn, regelmatig te worden heroverwogen en veilig te worden opgeslagen en gecommuniceerd;

Beleid

Identificatie

Identificatie is het vaststellen en registreren van iemands identiteit, bijvoorbeeld aan de hand van een geldig legitimatiebewijs zoals een paspoort. Identificatie dient plaats te vinden bij indiensttreding van een medewerker of bij de start van de opdracht van een ingehuurd persoon.

Verantwoordelijkheid van identificatie van vaste medewerkers en stagiaires ligt bij P&O.
Verantwoordelijkheid voor de identificatie van externen ligt bij de broker partij via welke de persoon wordt ingehuurd.

Registratie van natuurlijke personen

Alleen van vaste medewerkers en personen die door Kennisnet worden ingehuurd dient de natuurlijk persoon te worden geverifieerd en geregistreerd.

Verantwoordelijkheid van registratie van vaste medewerkers en stagiaires ligt bij P&O.
Verantwoordelijkheid voor de registratie van externen ligt bij de manager die de medewerker inhuurt.

Registratie van accounts

Accounts dienen alleen door bevoegde personen of afdelingen aangevraagd te worden, bij één vast loket;
- Accountaanvraag dient altijd bij de Servicedesk ingediend te worden;
- Accountaanvraag voor vaste medewerkers dient vanuit P&O te komen;
- Accountaanvraag voor externe medewerkers dient namens de verantwoordelijke manager door de Controller gedaan te worden en alleen wanneer zij toegang moeten hebben tot interne systemen.
Accounts/toegang van medewerkers met een tijdelijke overeenkomst moeten altijd een einddatum hebben;
Omwille van gecontroleerd accountbeheer moeten toepassingen wanneer mogelijk alléén ontsloten worden door middel van de centrale accountdatabase (binnen Kennisnet is dat de Active Directory);
Gebruikersnamen en e-mailadressen mogen niet worden hergebruikt bij het registreren van accounts

Alleen wanneer het niet mogelijk is om een toepassing via de centrale accountdatabase te ontsluiten zijn systemen met een eigen accountdatabase toegestaan (in de praktijk ook wel decentrale systemen genoemd).- Hiervoor geldt het volgende beleid:
Voor elke accountdatabase moet een verantwoordelijke worden vastgelegd;
Voor elke accountdatabase moeten accountuitgifte en mutaties plaats vinden conform een gedocumenteerde procedure of werkinstructie;
Er moet door de systeemverantwoordelijke aangetoond kunnen worden dat accountuitgifte en mutaties conform de afgesproken procedure hebben plaatsgevonden.

Herleidbaarheid van accounts tot individuele gebruikers

Toegangsrechten moeten altijd herleidbaar zijn tot individuele gebruikers:

Individuele accounts zijn strikt persoonlijk en mogen onder geen beding gedeeld worden;
Wanneer individuele identificatie niet mogelijk is en alleen groepsidentificatie kan worden toegepast dan moet dit door de Security Officer goedgekeurd worden en moet dit worden vastgelegd in documentatie.

Gedeelde accounts zijn alleen toegestaan als dit technisch niet anders kan of deze maatregel niet in verhouding staat tot het afgedekte risico, dit ter beoordeling van de Security Officer;
Groepsaccounts/gedeelde accounts (zoals FAB account) behoren strikt toe aan een selecte groep gebruikers. Wanneer een gebruiker deze groep verlaat dient de groep de wachtwoorden te vervangen door iets wat alleen deze groep heeft of kent.

Uitschrijven

Gebruikersaccounts moeten worden afgesloten:
- Wanneer deze binnen 30 dagen na aanmaken niet in gebruik is genomen
- Wanneer een medewerker de organisatie verlaat;
- Wanneer er (vermoeden van) misbruik van het account gemaakt is;
- Direct na het aflopen van de contracttermijn van een externe medewerker of wanneer deze niet meer nodig blijkt te zijn;
Gebruikersaccounts dienen verwijderd te worden;
- In de centrale accountdatabase dient het account 42 dagen na uitdiensttreding verwijderd te worden;
- In systemen met een eigen accountdatabase dient het account zo snel mogelijk (maar maximaal 6 maanden) na uitdiensttreding verwijderd te worden;
- De gebruikersnaam en het e-mailadres kunnen wel worden bewaard om hergebruik te voorkomen.
Eventueel nog in bezit zijnde fysieke authenticatie middelen moeten bij opzegging van autorisatie of gebruikersaccount geretourneerd worden.

Authenticatie

Authenticatie is het verifiëren van iemands identiteit. Authenticatie kan op verschillende manieren plaatsvinden, bijvoorbeeld door een wachtwoord, pincode, beveiligingssleutel of certificaat. Als verzamelterm hiervoor wordt “authenticatiemiddelen” gebruikt.

Voor toegang tot applicaties met een hoge integriteit en of vertrouwelijkheid (niveau hoog van de BIV-classificatie), wordt minimaal een twee factor authenticatie vereist. Voor toegang tot beheerapplicaties wordt ook twee factor authenticatie vereist.

Uitgifte van authenticatiemiddelen

Alle authenticatiemiddelen zijn geheim en in principe voor slechts één persoon toegankelijk.

De verstrekking van authenticatiemiddelen moet daarom veilig gebeuren, dus alleen persoonlijk toegankelijk voor de betreffende gebruiker en door altijd gebruik te maken van versleuteling bij het versturen en opslaan. De gebruiker moet na uitgifte zelf hun eigen authenticatiemiddelen beheren en is verantwoordelijk voor de bescherming en geheimhouding daarvan.

Uitgifte van een authenticatiemiddel voor initiële toegang, dient digitaal via de verantwoordelijke manager of persoonlijk door de servicedesk te gebeuren nadat de identiteit is vastgesteld.

Uitgifte van authenticatiemiddelen van een groepsaccount dient via een daarvoor bedoelde wachtwoordkluis te gebeuren.

Wanneer het gebruikte authenticatiemiddel een sleutelpaar betreft (bijvoorbeeld voor inloggen met SSH), gelden de volgende eisen:

De private key van het sleutelpaar moet door de medewerker zelf worden aangemaakt en beveiligd;
De medewerker dient alleen de public key te publiceren, zodat deze aan de juiste systemen toegevoegd kan worden voor toegang;
De private key dient ten alle tijden beveiligd te zijn met een tweede factor, iets ‘wat men weet’ of ‘wat men is’.

Initiële wachtwoorden

Initiële wachtwoorden zijn wachtwoorden of pincodes die worden verstrekt voor de allereerste toegang of ingebruikname van IT. Hiervoor geldt het volgende beleid:

Initiële wachtwoorden moeten voldoen aan het wachtwoordbeleid;
Initiële wachtwoorden moeten bij eerste gebruik worden gewijzigd;
Initiële wachtwoorden dienen een beperkte levensduur te hebben, in ieder geval niet langer dan 14 dagen;
Initiële wachtwoorden (onderdeel van default/standaard configuratie) van nieuwe hardware/software producten moeten voor inproductiename gewijzigd worden.

Wachtwoordbeleid

Dit wachtwoordbeleid geldt voor alle voorzieningen van Kennisnet. Voor wachtwoorden van beheerders, technische accounts en processen/services gelden aanvullende, alleen verzwarende, eisen, welke zijn vastgelegd in de procedures van Exploitatie.

De volgende wachtwoordeisen gelden en worden waar mogelijk technisch afgedwongen:

Wachtwoorden moeten minimaal 12 tekens bevatten, met minstens drie van de volgende vier elementen:
- Kleine letters
- Hoofdletters
- Cijfers
- Speciale karakters
Wachtwoorden bevatten niet meer dan twee herhaalde of drie opeenvolgende tekens (bijv. 'aaa', '1234abcd').
Wachtwoorden mogen niet bekend zijn in databases van gelekte wachtwoorden
Wachtwoorden zijn strikt persoonlijk en mogen niet worden gedeeld;
Het wachtwoord mag niet herleidbaar zijn naar de eigenaar van het account (geen namen, adressen, bedrijfsnamen, etc);

Het wachtwoord moet uniek zijn en mag dus niet gelijk zijn aan een wachtwoord wat voor andere systemen en/of doeleinden wordt gebruikt.

Gebruikers moet elk jaar gevraagd worden om hun wachtwoord te heroverwegen. Gebruikers worden geacht hun wachtwoorden direct aan te passen indien: zij er notie van hebben dat hun wachtwoord ergens gelekt is of er andere aanwijzingen zijn dat het wachtwoord onvoldoende sterk is. Waar mogelijk wordt dit ook technisch afgedwongen.

Inlogprocedure

Onder de inlogprocedure wordt dat proces verstaan waar een persoon geïdentificeerd en geauthentiseerd wordt. Hieraan worden de volgende eisen gesteld:

Bij foutieve invoer mag de procedure niet aangeven welk gegeven correct of incorrect is
De procedure moet bescherming bieden tegen zogenaamde brute force aanvallen
De procedure moet succesvolle en niet succesvolle pogingen registreren
De procedure moet teruggeven wanneer voor het laatst succesvol is ingelogd
Het wachtwoord dient gemaskeerd te worden bij invoer en kan enkel tijdelijk door de gebruiker weergegeven worden.
Een sessie als het gevolg van succesvol inloggen moet beperkt zijn tot maximaal 8 uur

Beheer van autorisatie

Autorisatie is de toestemming of bevoegdheid om een bepaalde handeling te mogen verrichten. Autorisatie dient beheerd te worden in lijn met onderstaande eisen:

Elk systeem, omgeving (denk aan SharePoint site, Teams kanaal of Viva Engage community) en document dient een eigenaar te hebben, deze kent de autorisaties/rechten toe;
Autorisaties/rechten moeten waar mogelijk aan rollen toegekend worden, bij voorkeur niet aan individuele gebruikers;
Het verlenen van autorisaties moet altijd met goedkeuring van de document-, omgeving- of systeemeigenaar;
Toegangsrechten moeten regelmatig (minimaal jaarlijks) worden beoordeeld door of in opdracht van de verantwoordelijke;
Toegangsrechten dienen in de volgende gevallen direct te worden aangepast:
- Wanneer de medewerker van functie verandert;
- Wanneer een project afloopt;
- Wanneer (externe) medewerkers niet meer bij het project betrokken zijn.
  
  Speciale toegangsrechten kennen een scherper beleid. Onder speciale toegangsrechten verstaan wij root en admin accounts. Hiervoor gelden de volgende aanvullende eisen:
Speciale toegangsrechten (zoals root- of adminrechten) worden uitsluitend toegekend aan een daartoe bestemd individueel account, dat specifiek voor beheerdoeleinden is aangemaakt. Dit beheeraccount mag niet gebruikt worden voor niet-beheer werkzaamheden.
Waar alle speciale toegangsrechten alleen zijn toegekend aan individuele accounts (geen root account meer) dienen er twee individuele accounts te zijn met de hoogste toegangsrechten.
Daar waar het niet mogelijk is om twee accounts met de hoogste toegangsrechten te hebben (denk bijvoorbeeld aan SaaS diensten), dient het ‘root-wachtwoord’ te worden vastgelegd in een speciaal daarvoor bedoelde kluis (digitaal of fysiek) waartoe minimaal twee mensen van Exploitatie toegang hebben.
Het gebruik van speciale toegangsrechten dient te worden gelogd.

Eisen aan applicaties met betrekking tot toegang

De eigenaar van een dienst is verantwoordelijk voor de toegangsbeveiliging van onderliggende applicaties en daarmee voor het inregelen van de toegang in lijn met dit beleid. Daarnaast gelden de volgende aanvullende regels:

De toegangsbeveiliging van de applicaties binnen een voorziening dient in overeenstemming te zijn met de BIV-classificatie van informatie/bedrijfsmiddelen;
De toegangsbeveiliging van een applicatie moet voorzien in verschillende typen autorisaties om deze te kunnen beperken naar de rollen en verantwoordelijkheden van gebruikers (least privilege moet mogelijk zijn);
De toegangsbeveiliging van een applicatie moet waar mogelijk gekoppeld zijn aan het centrale systeem voor authenticatie en autorisatie binnen Kennisnet;
- Toegang voor beheerders dient niet afhankelijk te zijn van een dienst van derden
Een applicatie dat authenticatiemiddelen verwerkt mag deze niet ongevraagd in platte tekst op het beeldscherm tonen;
Authenticatiemiddelen moeten gemaskeerd worden opgeslagen;
Autorisatie en authenticatie moeten gebruiksvriendelijk zijn;
Wanneer speciale (administratieve/beheer-) toegang wordt verleend dient het systeem daarvan een melding aan de gebruiker te maken bij het inloggen of het anderszins zichtbaar/herkenbaar te maken;
Standaard is het niet toegestaan om derde-partij-oplossingen toegang te geven tot applicaties; deze mogen uitsluitend de minimale profielinformatie (bijv. unieke ID, naam, rol) ontvangen die nodig is voor authenticatie en autorisatie.

Gegevensmaskering

Gegevensmaskering moet worden toegepast om gevoelige informatie te beschermen tegen ongeautoriseerde toegang, met name tijdens ontwikkeling, testen en verwerking van niet-productiegegevens. Het doel is om de herleidbaarheid van persoonsgegevens en geheime bedrijfsinformatie te minimaliseren.

Maskering is verplicht bij geheime (persoons) gegevens in:

Test- en ontwikkelomgevingen;
Logging en monitoring, uitgezonderd logging waar herleidbaarheid tot een persoon noodzakelijk is;
Onderzoeksgegevens

Er wordt een passende maskeringstechniek gekozen op basis van de situatie waar deze voor wordt ingezet. In de volgende situaties dienen standaard onderstaande technieken te worden gebruikt:

Statische gegevensmaskering bij gegevensmigratie naar niet-productieomgevingen;
Tokenisatie of pseudonimisering bij structurele gegevensvervanging.

Hardware

Doel

Hardware moet beschermd zijn tegen bedreigingen zoals diefstal, onbevoegde wijziging en uitval.

Uitgangspunten

Alle ingezette hardware dient een eigenaar te hebben welke verantwoordelijk is voor het beheer van deze hardware;
Hardware moet worden beschermd tegen interceptie, verstoring, diefstal of schade;
Hardware moet correct worden onderhouden om de continue beschikbaarheid en integriteit ervan te waarborgen;
Verwijdering of hergebruik van hardware dient gecontroleerd te gebeuren om datalekken en licentiefraude te voorkomen.

Beleid

In het beleid wordt onderscheid gemaakt tussen gebruikersapparatuur, Kennisnet hardware en bekabeling.

Gebruikersapparatuur

Onder gebruikersapparatuur wordt apparatuur verstaan welke door individuen worden gebruikt om de netwerken en systemen van Kennisnet te benaderen. Denk hierbij bijvoorbeeld aan laptops en smartphones. Kennisnet onderscheidt hierin twee categorieën: beheerde apparaten (de zogenaamde Kennisnet laptops) en bring-your-own-device (BYOD). Hiervoor geldt het volgende beleid:

Er moeten gebruiksregels en beveiligingseisen ten aanzien van gebruikersapparatuur beschreven staan in het beleid ‘Aanvaardbaar gebruik van bedrijfsmiddelen’;
Medewerkers dienen zich te houden de gebruiksregels;
Medewerkers dienen hun BYOD apparatuur te voorzien van de beschreven beveiligingseisen;
Kennisnet laptops dienen door beheer te worden voorzien van de voorgeschreven beveiligingsmaatregelen;
Installatie van software op Kennisnet laptops dient niet te worden beperkt.

Kennisnet hardware

Onder Kennisnet hardware wordt alle hardware verstaan die niet onder gebruikersapparatuur valt. Denk hierbij aan servers, printers, switches en wireless access points. Hiervoor geldt het volgende beleid:

Hardware moet zo worden geplaatst en beschermd dat risico’s van bedreigingen en gevaren van buitenaf, alsook de kans op onbevoegde toegang wordt verkleind;
Waar mogelijk moet dergelijke apparatuur in een afgesloten ruimte met beperkte toegang worden geplaatst;
Server- en netwerkapparatuur moet worden beschermd tegen stroomuitval/ontregelingen;
Kennisnet hardware mag niet zonder voorafgaande goedkeuring van de Domeinmanager Exploitatie worden geplaatst, meegenomen of verplaatst.

Bekabeling

Voedings- en telecommunicatiekabels voor het versturen van gegevens of die informatiediensten ondersteunen, moeten worden beschermd tegen interceptie, verstoring of schade. Hiervoor geldt het volgende beleid:

Waar mogelijk moet toegang tot bekabeling (patchkast, meterkast e.d.) afgesloten zijn

Registratie van hardware

Alle Kennisnet hardware en gebruikersapparatuur - die door Kennisnet wordt uitgegeven - moet geregistreerd zijn en een eigenaar hebben.

Onderhoud van hardware

Alle bovengenoemde hardware moet correct worden onderhouden om de continue beschikbaarheid en integriteit ervan te waarborgen.

Er moeten gedocumenteerde aanwijzingen zijn voor het correcte onderhoud van de hardware. Gebruikers van BYOD moeten gewezen worden op hun verantwoordelijkheid om correct onderhoud uit te voeren conform de instructies van de leverancier van hun apparaat.

Veilig verwijderen of hergebruiken van hardware

Alle hardware die opslagmedia (zoals geheugen of een harde schijf) bevat, moet bij verwijdering of hergebruik expliciet worden gewist. Er moet worden gecontroleerd dat deze geen gevoelige gegevens en in licentie gegeven software meer bevat, voordat de hardware definitief wordt verwijderd of hergebruikt. Hiervoor geldt het volgende beleid:

Alle hardware moet volgens een vastgestelde procedure worden afgevoerd of opnieuw ingezet voor andere doeleinde

Netwerk

Doel

Het doel van dit beleid is om de integriteit en veiligheid van de netwerken, aangesloten systemen en informatie van Kennisnet te waarborgen.

Uitgangspunten

Gebruikers mogen alleen toegang krijgen tot die netwerken, waarvoor zij specifiek geautoriseerd zijn.
In de Kennisnet netwerken dienen maatregelen te worden getroffen om groepen IT-voorzieningen, gebruikers en informatiesystemen te scheiden, ter bescherming van ongeautoriseerde toegang door andere netwerkgebruikers.
Toegang tot kantoorapplicaties moet laagdrempelig zijn, maar wel alleen vanuit landen met zakelijke noodzaak en afgewogen o.b.v. het risico.

Beleid

Kennisnet onderscheidt drie typen gebruikers:

Gasten – Iedereen die geen arbeids- of inhuurovereenkomst heeft met Kennisnet.
Medewerkers – Iedereen die op basis van een contractrelatie werkzaamheden voor Kennisnet verricht. Dit omvat vaste medewerkers, gedetacheerden en medewerkers van gecontracteerde leveranciers.
Beheerders – Aangewezen medewerkers van de afdeling Voorzieningen - Domein Exploitatie. Medewerkers van leveranciers die in opdracht van Domein Exploitatie beheerwerkzaamheden verrichten.

Om scheiding tussen deze gebruikers en systemen mogelijk te maken, dient er netwerkzonering geïmplementeerd te zijn. Hierbij onderscheidt Kennisnet vier typen zoneringen:

Gasten; dit is voor iedereen toegankelijk en geeft alleen internettoegang.
Kantoor; dit is bedoeld voor medewerkers van Kennisnet. Voor toegang tot dit netwerk is een Kennisnet account vereist.
Beheer; dit is bedoeld voor beheertoegang zoals managementinterfaces en beheerapplicaties. Alleen toegankelijk met een Kennisnet account met VPN toegang.
Server; dit is bedoeld voor communicatie met en onderling tussen servers. Deze heeft geen (directe) internettoegang en is niet direct toegankelijk voor gebruikers.

Actueel overzicht

Kennisnet moet te allen tijde beschikken over een actueel overzicht van de in gebruik zijnde netwerken.

Elk netwerk heeft een verantwoordelijke (eigenaar), die de volgende zaken minimaal heeft vastgelegd:

Welke zone het betreft;
Welke beveiligingsmechanismen zijn geïmplementeerd.

Andere zaken worden niet op netwerkniveau gedocumenteerd, want:

Dienstverleningsniveaus worden afgeleid van bovenliggende diensten.
Beheereisen worden gebruikt bij aanschaf van netwerkapparatuur of diensten en worden op dat moment bepaald.

Beveiliging van netwerken

Kantoor applicaties moeten indien mogelijk direct op het internet aangeboden worden, zodat deze op eenvoudig en laagdrempelig gebruikt kunnen worden. Wanneer dit niet op een veilige wijze kan – bv. door het ontbreken van twee factor authenticatie – dan is een VPN-verbinding verplicht. Om de netwerken (achter deze applicaties) te beveiligen, geldt het volgende beleid:

Toegang tot netwerken van Kennisnet (gastennetwerken hier buitenbeschouwing gelaten) dient alleen mogelijk te zijn met expliciete toestemming;
Elke applicatie of voorziening moet zijn eigen netwerk hebben of dient geïsoleerd te zijn binnen een gedeeld netwerk;
Verschillende netwerken en de verschillende typen netwerken moeten fysiek en/of logisch van elkaar gescheiden zijn;
Verbinding tussen verschillende netwerken dient standaard niet mogelijk te zijn (impliciet deny) en dienen ingesteld te zijn op basis van ‘least privilege’: alleen benodigde routeringen en of open poorten zijn ingesteld.
- Servers dienen standaard geen internettoegang te hebben. Mocht dit wel van cruciaal belang zijn voor de werking, dan dient dit gefilterd (alleen geselecteerde bronnen) of via een beveiligde proxy plaats te vinden.
Toegang tot het beheernetwerk moet altijd over een beveiligde/versleutelde verbinding lopen;
Netwerken en netwerkdiensten moeten passend op basis van zonering beveiligd worden door technische maatregelen zoals firewalls en hardening.

Geoblocking

Geoblocking moet worden toegepast om het aanvalsoppervlak van de computersystemen van Kennisnet te verkleinen.

Vanwege het verschil in risicofactoren, wordt er een onderscheid gemaakt tussen VPN- en beheertoegang en de kantoorapplicaties (Office 365 suite):

VPN-toegang en Office 365-toegang voor beheerders dient alleen toegankelijk te zijn vanuit Nederland. Voor werkvakantie kan door personeelszaken een tijdelijke ontheffing aangevraagd worden.
Toegang tot kantoorapplicaties dient alleen toegankelijk te zijn voor landen binnen de Europese Economische Ruimte en landen die expliciet zijn goedgekeurd door het IBP-kernteam. Landen met een rood of oranje reisadvies worden altijd geblokkeerd. Het IBP-kernteam dient een lijst van toegestane en geblokkeerde landen te beheren.

Ontwikkeling

Doel

Het doel van dit beleid is om de kwaliteit van onder verantwoordelijkheid van Kennisnet ontwikkelde software en systemen te waarborgen.

Uitgangspunten

De samenhang in informatievoorzieningen van Kennisnet moet worden gewaarborgd door alle dienstontwikkeling onder architectuur te laten plaatsvinden.
Ontwikkeling van software en systemen binnen Kennisnet dient uitgevoerd te worden volgens een vastgesteld proces.
Er moeten maatregelen worden genomen om de risico’s, zoals productieverstoringen en datalekken, naar aanleiding van softwareontwikkeling te mitigeren.

Beleid

Architectuur

Om de structuur en samenhang van de verschillende onderdelen van de informatievoorziening binnen Kennisnet te waarborgen dient er gewerkt te worden onder architectuur. Daarvoor heeft Kennisnet een eigen architectuur, die o.a. de Referentie Onderwijs Sector Architectuur (ROSA) moet volgen. Alle dienst ontwikkelingen moeten aan deze architecturen worden getoetst.

Ontwikkelproces

Voor het ontwikkelen van software en systemen moeten richtlijnen en procedures zijn vastgesteld en op ontwikkelactiviteiten binnen Kennisnet worden toegepast. Deze bevatten minimaal:

Een vastgesteld ontwikkelproces;
Eisen met betrekking tot veilig coderen;
Eisen met betrekking tot de kwaliteit van software en systemen;
Eisen met betrekking tot testen;
Eisen met betrekking tot documentatie;
Eisen met betrekking tot het beheer van broncode;
Principes voor ontwikkelen van veilige software en waarborging van privacy.

Testen

Tijdens de ontwikkeling en bij oplevering wordt de beveiliging van de software getest conform het testbeleid. Het testen moet risicogebaseerd worden uitgevoerd. Dienstverantwoordelijke moet passende testen (laten) uitvoeren om de beveiliging van de voorziening te waarborgen bij ontwikkeling (denk aan pentesten).

OTAP-omgeving

Productieomgevingen en productiegegevens moeten worden beschermd tegen compromittering door ontwikkel- en testactiviteiten. Om dit te waarborgen worden binnen Kennisnet gescheiden ontwikkel-, test-, acceptatie- en productieomgevingen (OTAP) gehanteerd.

Algemene principes

Voorzieningen en software die door Kennisnet worden ontwikkeld, maken gebruik van gescheiden ontwikkel-, test-, acceptatie- en productieomgevingen.
De acceptatieomgeving functioneert als een quasi-productieomgeving en kent dezelfde beveiligings- en toegangscontroles als productie; alleen ontwikkel- en testomgevingen mogen qua IB-maatregelen afwijken van productie.
Op productie en acceptatie worden uitgebreide logging- en monitoringvoorzieningen toegepast, zodat foutanalyse en debugging kunnen plaatsvinden zonder directe server- of databasetoegang.
Ontwikkelaars en testers krijgen alleen, indien noodzakelijk, shell-toegang tot testomgevingen. Zij hebben nooit toegang tot acceptatie- of productieomgevingen.
Acceptatie- en productieomgevingen worden altijd beheerd door Exploitatie.
Persoonsgegevens of andere gevoelige gegevens mogen niet worden gebruikt in ontwikkel-, test- of acceptatieomgevingen. Als een kopie van productiegegevens noodzakelijk is voor acceptatie of test, dan moeten deze vooraf worden geanonimiseerd of gemaskeerd volgens het gegevensmaskeringsbeleid. Sandbox- en kwalificatieomgevingen worden als productie beschouwd wanneer zij publiek of extern toegankelijk zijn, omdat zij vanaf het internet benaderbaar zijn en dus dezelfde beveiliging vereisen.

Omgeving	Wie mag erin?	Wie mag erin?	Toegangsvorm	Voorwaarden
Ontwikkel	Ontwikkelaars	Ontwikkelaars	Volledig toegang (IDE, shell,)	* Alleen representatieve dummydata
Test	* Ontwikkelaars Testers Beheerders	Ontwikkelaars, testers, exploitatie	* Systeemtoegang (shell) voor ontwikkelaars en testers (indien nodig). Applicatietoegang via gebruikers accounts.	* Alleen synthetische of geanonimiseerde data Logging op systeemniveau.
Acceptatie	* Testers Beheerders	* (Functioneel) beheerders Testers.	* Applicatietoegang via gebruikersaccounts. Systeemtoegang (shell) alleen voor exploitatie.	* Geen persoonsgegevens of andere gevoelige gegevens (vertrouwelijkheidsniveau Hoog). Toegang tot data via normale applicatietoegang. Logging en monitoring gelijk aan productie. Alleen exploitatie mag configureren.
Productie	* Eindgebruikers via normale applicatietoegang Beheerders	* (Functioneel) beheerders Testers niet Eindgebruikers via normale applicatietoegang.	* Applicatietoegang via gebruikersaccounts (MFA aanbevolen). Systeemtoegang via bastion/jump hosts (MFA verplicht).	* Alleen hier zijn persoonsgegevens toegestaan. Logging en monitoring verplicht op separate omgeving. Toegang tot data via normale applicatietoegang Toegang periodiek gereviewd.
Sandbox (eindgebruikers)	* Eindgebruikers Beheerders	* Eindgebruikers Exploitatie (beheer).	* Applicatietoegang via gebruikersaccounts (MFA aanbevolen). Geen beheertoegang voor eindgebruikers.	* Alleen demo/synthetische data. Toegang tot data via normale applicatietoegang Beheer door exploitatie. Regelmatig opschonen.
Kwalificatie	* Testers Beheerders	* Testers, functioneel beheerders, exploitatie.	Applicatietoegang en beheer door exploitatie.	* Kwalificatieomgevingen volgen hetzelfde beveiligingsniveau als productie wanneer zij publiek of extern toegankelijk zijn; in andere gevallen geldt minimaal het beveiligingsniveau van acceptatie. Geen persoonsgegevens. Toegang tot data via normale applicatietoegang

Voor aangekochte software waarvan de ontwikkeling door leveranciers plaatsvindt en waarbij gebruikersacceptatietesten worden uitgevoerd, geldt dat minimaal een scheiding tussen acceptatie- en productieomgeving aanwezig moet zijn. De afspraken rondom acceptatie- en productieomgevingen zijn onverkort van toepassing.

Leveranciersmanagement

Doel

Het doel van leveranciersmanagement is het beheersen van risico’s die voortvloeien uit het gebruik van producten of diensten van leveranciers, met bijzondere aandacht voor risico’s voor informatiebeveiliging en continuïteit.

Uitgangspunten

Dit beleid geldt voor leveranciers waar mogelijk sprake is van toegang tot gegevens of computersystemen van Kennisnet
Leveranciers moeten voldoen aan vooraf gestelde doelstellingen en eisen, afgestemd op het type dienstverlening en het risicoprofiel
De prestaties van leveranciers worden regelmatig geëvalueerd, inclusief de naleving van gemaakte afspraken over informatiebeveiliging en continuïteit
De afhankelijkheid van een specifieke leverancier moet minimaal zijn

Beleid

Vastleggen van doelstellingen en eisen

Voorafgaand aan het aangaan van een leveranciersrelatie moeten doelstellingen en eisen worden vastgesteld die aansluiten op het type dienstverlening en het risicoprofiel van de leverancier. Deze eisen hebben betrekking op zowel de kwaliteit van de dienstverlening als op informatiebeveiliging.

De diensteigenaar is verantwoordelijk voor het vastleggen van deze doelstellingen en eisen. De eisen en doelstellingen moeten worden afgestemd op:

de afhankelijkheid van de leverancier, en
de gevolgen voor de continuïteit van de dienstverlening van Kennisnet, en
indien van toepassing, de BIV-classificatie van de geleverde applicatie,.

Voor iedere leverancier moet worden vastgelegd:
Kwaliteitseisen en prestatie-indicatoren van de leverancier en haar dienstverlening
Of de dienstverlening van de leverancier wel of niet kritiek is voor de continuïteit van (de dienstverlening van) Kennisnet.

Afhankelijk van het type dienstverlening en de aard van de toegang tot gegevens of computersystemen, gelden aanvullende beveiligingseisen:
Voor leveranciers die ICT-diensten of applicaties leveren, worden beveiligingseisen vastgesteld op basis van de BIV-classificatie van de dienst, in lijn met het Certificeringsschema IBP ROSA.
Voor leveranciers die uitsluitend personen leveren met toegang tot informatie(systemen), gelden eisen met betrekking tot persoonsregistratie, geheimhouding en het gebruik van persoonlijke accounts.
Voor leveranciers die beheer uitvoeren of fysieke toegang hebben tot infrastructuur of datacenters, gelden aanvullende eisen die passen bij de risico’s die uit hun rol voortvloeien.
Voor leveranciers van hardware en software worden eisen gesteld aan de veiligheid van de producten en de wijze waarop ondersteuning wordt verleend.
Voor leveranciers die in opdracht van Kennisnet persoonsgegevens verwerken, is een verwerkersovereenkomst verplicht waarin de noodzakelijke afspraken zijn opgenomen over beveiliging, verantwoordelijkheden en naleving van de AVG.

Monitoren en beoordelen van leveranciers

Leveranciers moeten regelmatig worden beoordeeld op deze doelstellingen en eisen
- Niet kritiek: bij aangaan of verlenging contract
- Wel kritiek: minimaal één keer per jaar
Voor alle leveranciers dient binnen Kennisnet expliciet een verantwoordelijke aangewezen te zijn die de dienstverlening periodiek evalueert en risico's evalueert bij wijzing aan de dienstverlening.
Leveranciers moeten wijzigingen in dienstverlening doorgeven aan Kennisnet
- Dergelijke wijzigingen moeten worden beoordeeld op de mogelijke impact op informatiebeveiliging, continuïteit en afgesproken dienstverlening.
- De beoordeling dient plaats te vinden door of onder regie van de verantwoordelijke diensteigenaar
- Deze meld- en beoordelingsverplichting moet, waar relevant, expliciet worden opgenomen in de overeenkomst of bijbehorende SLA.

Beperking afhankelijkheid leverancier

Om ongewenste afhankelijkheid van leveranciers te voorkomen, gelden de volgende eisen:

Gegevens binnen een voorziening moeten beschikbaar zijn door middel van (koppeling met) open standaarden.
Kennis van de configuratie is niet alleen bekend bij de leverancier, maar ook bij Kennisnet of derden
Voor kritieke diensten is een exit-strategie vastgelegd en juridisch beoordeeld

Cryptografie

Doel

Kennisnet past cryptografie toe op gegevens(dragers) en netwerkverbindingen voor het beschermen van vertrouwelijkheid, integriteit en beschikbaarheid van informatie en onweerlegbaarheid ervan.

Uitgangspunten

Cryptografie moet rekening houden met de classificatie van gegevens en systemen, risicobeoordeling en de daaruit volgende benodigde bescherming.
Versleutelde gegevens moeten beschermd worden tegen verlies in het geval van gecompromitteerde of verloren sleutels.
Het gebruik van cryptografie moet in overeenstemming zijn met van toepassing zijnde wet- en regelgeving.
Risico’s die voortkomen uit versleuteling worden beheerst met maatregelen

Beleid

Verplichte versleuteling

Kennisnet verplicht versleuteling in de volgende gevallen:

Gegevens met classificatie ‘Geheim’ moeten bij transport altijd worden versleuteld (door middel van kanaal of berichtversleuteling). De opslag moet versleuteld zijn wanneer de gegevens buiten de bron (de beveiligde omgeving) worden verwerkt.
Transportkanalen die onder het beheer van Kennisnet vallen (waarover mogelijk vertrouwelijke of geheime gegevens verstuurd worden) moeten zijn versleuteld.
Alle werkplekken en draagbare media (gegevensdragers en mobiele apparatuur zoals laptops en smartphones) die mogelijk vertrouwelijke of geheime gegevens bevatten moeten worden versleuteld.

Indien versleuteling niet verplicht is (zoals bij transport van openbare informatie) wordt dit wel aanbevolen.

Sleutelbeheer

Er moet een systeem voor sleutelbeheer zijn, bestaande uit procedures en werkinstructies, voor het gebruik en beheer van sleutels. Deze moeten minimaal het volgende bevatten:

Het aanmaken van sleutels voor verschillende systemen en toepassingen;
Aanvraag en gebruik van sleutelcertificaten;
Opslag, verspreiding en toegang van sleutels;
Wijzigen, updaten en intrekken van sleutels;
Back-up, herstel en vernietiging van sleutels;
Logging en auditing van aan sleutelbeheer gerelateerde activiteiten.

Wet- en regelgeving

Kennisnet moet regelmatig de van toepassing zijnde wet- en regelgeving evalueren. Het gebruik van cryptografie dient rekening te houden met de belangrijkste punten uit wet- en regelgeving. Gebruikers moeten richtlijnen krijgen voor de volgende specifieke gevallen:

Wanneer overheden verzoeken om toegang tot informatiedragers; voornamelijk bij het passeren van de landsgrens of een (strafrechtelijk) onderzoek;
Wanneer gereisd wordt naar het buitenland; enkele landen kennen (export) beperkingen aan cryptografie, met name voor zeer geavanceerde cryptografie en niet standaardproducten.

Beperking van de risico’s voortkomend uit versleuteling

Sleutels dienen waar mogelijk op een centrale plaats opgeslagen en beheerd te worden. Wanneer dit niet mogelijk is, wordt hier een overzicht van bijgehouden;
- Gebruik van persoonlijke sleutels voor versleuteling van gegevens van Kennisnet is niet toegestaan, louter voor persoonlijke gegevens.
Sleutels moeten te allen tijde opgevraagd kunnen worden door de Security Officer;
- Voor persoonlijke private-sleutels geldt een uitzondering, die mogen alleen bij de persoon zelf bekend zijn en blijven.
Versleuteling moet zoveel mogelijk door het gegevensverwerkende systeem worden toegepast en zo min mogelijk de verantwoordelijkheid zijn van de eindgebruiker.

Fysieke beveiliging

Doel

Fysieke beveiliging moet passende beveiliging bieden van ruimtes waar zich IT-middelen bevinden.

Uitgangspunten

Er dienen fysieke beveiligingszones te worden gedefinieerd welke beveiligd worden op een wijze die passend is bij de informatievoorzieningen die zich in de zone kunnen bevinden;
Toegang tot de verschillende zones dient beperkt te worden, passend bij de informatievoorzieningen die zich in de zone kunnen bevinden;

Beleid

Fysieke beveiligingszones

Het Kennisnetkantoor en externe locaties waar hardware van Kennisnet staat moeten worden ingedeeld in fysieke beveiligingszones. Deze zonering moet rekening houden met de informatievoorziening die zich in de betreffende ruimte bevindt.

Beveiliging van de fysieke omgeving

Het Kennisnet kantoor en externe locaties waar servers van Kennisnet geplaatst zijn, dienen voorzien te zijn van een alarmsysteem. De CTO bepaalt welke aanvullende beveiligingsmaatregelen passend zijn voor de verschillende zones. Er dient een proces ten aanzien van de uitvoering van fysieke beveiliging te zijn vastgelegd in het 'Handboek Administratieve Organisatie'.

Fysieke toegangsbeveiliging

Er moet een sleutelplan zijn alsmede een proces voor het uitgeven, beheren en innemen van toegang/sleutels. In dit sleutelplan moet rekening worden gehouden met de beveiligingszones en de informatievoorziening die zich in een zone kan bevinden.

@@ Regel 5: / Regel 5: @@
 |
 |}
-__NUMBEREDHEADINGS__
 '''Inhoud'''

IT-Beleid: verschil tussen versies

Huidige versie van 24 dec 2025 om 11:19

Document geschiedenis

Revisies

Goedkeuring

Document Classificatie

Inleiding

Doelgroep

Scope

Structuur

Beheer

Doel

Uitgangspunten

Beleid

Intern en extern beheer

Voorwaarden voor inbeheername

Domeinnaambeheer

Gedocumenteerde bedieningsprocedures

Kloksynchronisatie

Logging en monitoring

Gebruik van systeemhulpmiddelen

Capaciteit

Continuïteit

Serverbeheer

Configuratiebeheer

Wijzigingsbeheer

Incidentbeheer

Back-up

Verwijderbare media

Opslag van broncode

Technische beveiligingsmaatregelen

Afstemming van testen/toetsen

Beheer van technische kwetsbaarheden

Toegangsbeveiliging

Doel

Uitgangspunten

Beleid

Identificatie

Registratie van natuurlijke personen

Registratie van accounts

Herleidbaarheid van accounts tot individuele gebruikers

Uitschrijven

Authenticatie

Uitgifte van authenticatiemiddelen

Initiële wachtwoorden

Wachtwoordbeleid

Inlogprocedure

Beheer van autorisatie

Eisen aan applicaties met betrekking tot toegang

Gegevensmaskering

Hardware

Doel

Uitgangspunten

Beleid

Gebruikersapparatuur

Kennisnet hardware

Bekabeling

Registratie van hardware

Onderhoud van hardware

Veilig verwijderen of hergebruiken van hardware

Netwerk

Doel

Uitgangspunten

Beleid

Actueel overzicht

Beveiliging van netwerken

Geoblocking

Ontwikkeling

Doel

Uitgangspunten

Beleid

Architectuur

Ontwikkelproces

Testen

OTAP-omgeving

Leveranciersmanagement

Doel

Uitgangspunten

Beleid

Vastleggen van doelstellingen en eisen