NL: APK voor webhosting – over rijksbrede regie op digitale infrastructuur

1. De huidige inrichting van de digitale regie binnen het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties bereikt haar structurele grenzen.
2. Digitale infrastructuur vereist centrale coördinatie, structurele kennisborging en uitvoerbare functiescheiding tussen regie, uitvoering en toezicht.
3. Tijdelijke taskforces ontberen structurele inhoudelijke analyse die nodig is voor samenhangende besluitvorming en sturing op systeemniveau.
4. Effectieve regie vergt expliciete coördinerende bevoegdheden ten opzichte van traditioneel autonoom opererende ministeries.
5. Het bestaande Expertisecentrum Digitale Data en Cloud vervult reeds zowel beleidsontwikkelende taken als ondersteuning van de uitvoering.

Oplossing: Centrale Digitale Zaken als rijksbrede regiefunctie

Centrale Digitale Zaken binnen het Ministerie van Algemene Zaken wordt verantwoordelijk voor de rijksbrede regie op digitale infrastructuur. Inzichten over WHOIS, RDAP en onderlinge afhankelijkheden binnen digitale ketens worden structureel vertaald naar beleidskaders, normen en concrete borgingsmaatregelen.

Structurele digitale knelpunten vormen een vast agendapunt binnen Centrale Digitale Zaken en worden, waar strategische afwegingen nodig zijn, voorbereid voor besluitvorming op kabinetsniveau.

Met afdelingen voor monitoring, expertisemanagement en kenniswisseling kan het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties de digitale infrastructuur zodanig organiseren dat centrale CIO- en CTO-functies niet permanent operationeel hoeven in te grijpen.

Het Orgaan Digitale Expertise bij BZK bewaakt de inhoudelijke samenhang, voert systeemanalyses uit en levert deskundige ondersteuning ten behoeve van beleidsvorming en uitvoering.

Binnen dit ministerie wordt tevens de Digitale Kenniswisseling gepositioneerd, die structurele samenwerking tussen overheid en bedrijfsleven faciliteert, praktijkervaring bundelt en deze vertaalt naar toepasbare inzichten voor beleid en uitvoering.

Toezicht en handhaving worden ondergebracht bij de Rijksinspectie Digitale Infrastructuur binnen het Ministerie van Economische Zaken.

NB:
– De huidige koers rond de Nederlandse Digitale Dienst staat op gespannen voet met deze inrichting van Centrale Digitale Zaken. Internationale sturing richting ICANN blijft buiten beschouwing en digitale dossiers worden onvoldoende als strategische kernverantwoordelijkheid gepositioneerd.
– Door de gelaagde bestuursstructuur binnen Binnenlandse Zaken vervagen regie en uitvoering structureel.
– Eerdere pogingen tot strategische digitale regie vanuit het Ministerie van Economische Zaken hebben tot beperkte resultaten geleid, maar niet tot structurele Europese cloudontwikkeling.

Tekst – formulering voor experts

In contact met de Rijksoverheid heb ik textforexperts.hostingtool.org aangedragen als alternatief voor losse mediaoptredens van individuele deskundigen. Dit was mede naar aanleiding van de coronaperiode, waarin deskundigen zonder ingebouwd inhoudelijk weerwerk opereerden, met als doel gerichte, terecht consistente kennisdeling op het snijvlak van hosting, DNS en governance.

Voor Nederlandse datacentra ontbreekt het primair niet aan inhoudelijke expertise, maar aan schaalgrootte en bundeling om deze kennis te overzien en inzetbaar te maken.

Cloudoperating ligt ver boven het initiële opleidingsniveau van veel IT-opleidingen.

Bij Amazon Web Services is zelfstandige nascholing door developers en cloudoperators te tijdsintensief, wat om het borgen van praktijkervaring vraagt in structurele handboekkennis.

Hierbij is het noodzakelijk dat het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties uiteenlopende expertisegebieden actief onderscheidt. Zonder duidelijke functiescheiding vervagen expertisegrenzen, wat wederzijds respect en effectieve samenwerking belemmert. Het herkennen en erkennen van specialisme overstijgt het bedieningsniveau.

Aanspreekbaarheid van de registrar

De registrar mag bij registratie en beheer uitgaan van door de aanvrager verstrekte gegevens, tenzij hij weet of redelijkerwijs moet vermoeden dat deze onjuist zijn. Een afgeschermde houdernaam in het .nl-register betekent houdertype particulier, bijvoorbeeld ja21.nl. Zie ook krimpenerwaard.nl.
– domaincontrolregister.org maakt regie mogelijk op organisatieniveau. Zie politieke_partijen.pdf.
– Zie hierbij meteen manageable action points: politieke_partijen_hosting.pdf.
– Zonder kennisoverdracht blijft de registrar beperkt tot een uitvoerende schakel zonder effectieve aanspreekbaarheid.
– ICANN dient, denk ik, bij gTLD-registraties te voorzien in publicatie van gegevens waarvoor op registrar-niveau expliciet autorisatie bestaat. Ik wacht inhoudelijk op de meest gespecialiseerde in de V.S..
– Mijn melding ‘Not yet an error or warning: related.href equals self.href, creating a prohibited self-loop’ komt moeilijk verder: https://github.com/rdap-org/validator.rdap.org/issues/13
– Voor internet.nl zou omgaan met ‘time-out’ wereldwijd ondergrond bieden tegen het maar wegwijzen naar een andere partij.
– Voor internet.nl vind ik een interface-ready tabeldefinitie ook een actiepunt.
– Nederland kan in de rol van early adopter, naar mijn normalisatie inzake de IANA-topdomeinendatabase, toewerken.

E-mailhistorie bij een eenmanszaak (met mandaat)

De e-mailhistorie behorend bij een eenmanszaak is juridisch ondeelbaar verbonden met de natuurlijke persoon van de houder en ontbeert zelfstandige overdraagbaarheid. Toegang tot of gebruik van deze e-mailhistorie door derden is uitsluitend mogelijk op basis van een uitdrukkelijk en herroepbaar mandaat of volmacht van de houder, of op grond van wettelijke uitzonderingen, zoals strafvorderlijke bevoegdheden of een expliciet rechterlijk bevel. Indien de houdernaam overeenkomt met de inschrijving in het Handelsregister, is deactivering op grond van een vermeend niet-bestaande houder niet aan de orde.

Impliciete, niet-afdoende data (casus SIDN)

In de praktijk worden bij het domein amsterdam.amsterdam contact-e-mailadressen gepubliceerd die wel syntactisch valide zijn, maar geen functionerend contactmechanisme vormen. Dit creëert schijn-traceerbaarheid en ondermijnt de transparantie binnen WHOIS/RDAP. Zie: amsterdam.amsterdam
NB: Verder bestaan bij nl.nl onnodige statussen. Die scenario’s vertragen in 2026 nieuwe software.

Bestandsbeheer van Whois (uitgesproken als “who is”); ook van leveranciers

  1. Bestaat de handelsnaam van de registrar / reseller? De registry kan niet verantwoordelijk zijn.
  2. Verzorgt de registrar de ‘abuse’ contact informatie? T.z.t. gaat dit wereldwijd verplicht worden.
  3. Staan de domeinen in servernamen en van de name servers goed op naam?
  4. Staan de IPv4- en IPv6-adresblokken op de gewenste naam?
  5. Is de afkorting ‘B.V.’, volgens wettelijk voorschrift, in hoofdletters en met puntjes?
  6. Is mogelijke vermelding van domeinen bij de KVK juist?

Regelkringen

  1. Is het bestand security.txt ingericht, en op de juiste plaats, voor de white hat hacker?
  2. Gaat e-mail naar de comptabele persoon zonder handmatig doorsturen? Verantwoording?
  3. Gaat e-mail naar de systeembeheerder zonder handmatig doorsturen? Snelle oplossingen?
  4. Is een misbruik / abuse contact ingericht door de Registrar? Optioneel gebruik zoals bij .nl?
  5. Is het menu van de domain provider(s) state-of-the-art? Standaard rapportage voor controle?
  6. Werkt de mijns inziens benodigde driemaandelijkse tuning m.b.v. diverse testtools?

Controles door site-ontwerper

  1. Staat de handelsnaam op de site in het Handelsregister, en dan niet als uitgeschreven?
  2. Staat het KVK-nummer op de site, en is dit nummer juist?

Wet beveiliging netwerk- en informatiesystemen (Wbni)

  1. Regelmatige beoordeling van het opsporen en dichten van beveiligingsgaten;
  2. Wie komen er allemaal binnen en hebt u daar zicht op?
  3. Een doeltreffende reactie op incidenten.

Privacy

  1. Is een privénaam niet onnodig openbaar zichtbaar? Worden ook IP-blokken geaudit?
  2. Staan privacygevoelige gegevens op een server met MySQL poort 3306 open?

Beveiliging

  1. Is HTTPS op de website in orde, ook bij leveranciers?
  2. Is DNSSEC op de name servers, in combinatie met de domain provider, in orde, ook bij leveranciers?
  3. Is DMARC/DKIM/SPF/DANE (adkim=s; aspf=s;) voor e-mail up-to-date?
  4. @www.: ‘v=DMARC1; p=reject;’ ‘v=DKIM1; p=’ ‘v=spf1 -all’ (DDoS aanval kan via wildcard DKIM)
    @www.: ‘v=DMARC1; p=reject;’ [identiek aan zonder www] ‘v=spf1 +a -all’ (www servernaam)
    @www.: ‘v=DMARC1; p=reject;’ ” ‘v=spf1 -all’ (geen DKIM, dan DMARC-reject en zo’n SPF)
  5. Is er behoorlijke inrichting van security headers?
  6. Is e-mail beveiliging getest met een valse afzender?

Instellingen

  1. Werkt HTTP/2 t.b.v. de snelheid?
  2. Zal een niet-ondersteunde PHP-versie snel worden uitgefaseerd?
  3. Zijn er meerdere MX-servernamen/IP’s als uitwijk voor inkomende e-mail?
  4. Is er in de applicatie uitwijk naar een andere uitgaande e-mail service?
  5. Werkt u toe naar geen subdomein www in de URL?

Datacenter(s) etc.

  1. Is het datacenter in drie ‘availability zones’ gebouwd t.b.v. redundantie?
  2. Zijn datacenter/name servers/DNS/applicatie/plug-ins IPv6-klaar?
  3. Is de locatie van het datacenter binnen Nederland?
  4. Inkomende mailservers upgraden naar / vervangen door OpenSSL 1.1 / TLS 1.3.
  5. Zijn applicaties met (Java-)plug-ins (bijv. voor een PDF) getest met OpenSSL 1.1?
  6. Zijn snelle SSD-schijven van toepassing? En mogelijk dedicated processoren?