Onderwerp

Open standaarden

Welke open standaarden het platform per onderwerp volgt, zodat inrichting, gegevens en bewijs leesbaar blijven buiten het huidige product, en hoe het de standaarden van de lijst ‘pas toe of leg uit’ toepast.

Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas

Domein

Strategie & aanbod

Volgt uit

Functies

Verwant

Wat het is

Open standaarden houden inrichting, gegevens en bewijs leesbaar buiten het huidige product. Dit onderwerp legt per onderwerp vast welke open standaarden en de-factostandaarden het platform volgt, met hun beheerder, hun gebruik in het platform en hun plaats op de lijsten van Forum Standaardisatie, en hoe het platform de lijst ‘pas toe of leg uit’ toepast.

Waarom zo

Eigen formaten en maatwerkkoppelingen zijn soms sneller gemaakt, maar maken koppelen, controleren en later overstappen duurder. Met open standaarden is een onderdeel later te vervangen zonder de rest opnieuw te bouwen. Een standaardnaam is wel geen bewijs van uitwisselbaarheid: uitbreidingen van leveranciers gaan niet vanzelf mee, en of een overstap lukt, toont pas de proef met export en herstel elders.

Dat het platform per onderwerp open standaarden volgt, welke dat zijn en hoe het de lijst ‘pas toe of leg uit’ toepast, is vastgesteld. De versies, profielen en het precieze gebruik zijn een voorstel, net als de uitwerking per standaard van die lijst.

Uitspraken

3 vastgesteld9 voorstellen

Alle 9 voorstellen vaststellen

Waarom open standaarden

VastgesteldOntwerpbesluit#

Het platform volgt per onderwerp vaste open standaarden, zodat inrichting, gegevens en bewijs leesbaar blijven buiten het huidige product en een onderdeel later te vervangen is zonder de rest opnieuw te bouwen.

Onderwerp	Open standaarden
Uitvoering en inrichting	Kubernetes-API, OCI Image en Distribution Specification, Container Network Interface, Container Storage Interface, Gateway API, de OpenGitOps-principes, YAML en JSON, Git, Serverless Workflow en CloudEvents
Identiteit, toegang en verbindingen	SPIFFE, OpenID Connect, OAuth, SAML, LDAP, WebAuthn en FIDO2, JSON Web Token, `X.509`, ACME, TLS, HTTPS en SSH
Cryptografie en vertrouwde opstart	AES, SHA-2, ML-KEM en ML-DSA, PKCS#11, TPM 2.0, UEFI Secure Boot en de RATS-architectuur
Softwareketen	SLSA, in-toto-attestaties, CycloneDX, SPDX, Sigstore en CVE
Bewaking, logboeken en tijd	OpenTelemetry, het Prometheus-formaat voor metingen, Syslog, CEF, SNMP, sFlow, Redfish, gRPC en NTP
Opslag en gegevens	De S3-interface met Object Lock, NFS, SMB, SQL en NVM Express
Datacenternetwerk	IEEE 802.1Q, 802.1AX en 802.1AE, IPv4, OSPF, BGP, BFD, TCP-AO, EVPN, VXLAN, DSCP en ECN, DNS en DHCP

Toelichting

Of een overstap werkelijk lukt, toont pas de proef met export en herstel elders, de toets Overdraagbaarheid en afbouw; zie ook overdraagbaar door open standaarden. Afgewezen: eigen formaten en maatwerkkoppelingen, die soms sneller gemaakt zijn, maar koppelen, controleren en later overstappen duurder maken. Kaders en normen zoals BIO2, ISO/IEC 27002:2022 en NIST SP 800-53 bepalen de beveiligingseisen; die staan bij de beveiligingsbaseline.

VastgesteldUitgangspunt#

Naast open standaarden volgt het platform enkele de-factostandaarden, zoals de S3-interface voor objectopslag, Git, het Prometheus-formaat voor metingen, CEF en sFlow. Zij zijn zo breed ondersteund dat zij voor koppelen en overstappen een vergelijkbare rol vervullen. Een gemeenschappelijke interface maakt de uitbreidingen erop niet gelijk: S3-compatibiliteit garandeert bijvoorbeeld niet dezelfde onveranderbaarheid bij een andere leverancier.

VoorstelRegel#

Een vermelding van een standaard beschrijft het in het ontwerp voorziene gebruik. Dat de gekozen producten en versies de standaard ondersteunen, bevestigt de leverancier bij de acceptatie van het onderdeel waarin zij worden ingezet.

Toelichting

Een standaardnaam alleen is geen bewijs van uitwisselbaarheid; zie de ontwerpkeuze Open standaarden en overdraagbare configuratie.

Standaarden per onderwerp

VoorstelWaarde#

Voor uitvoering en inrichting gebruikt het platform deze standaarden, in deze versies en voor dit gebruik.

Standaard	Beheerder	Gebruik in het platform	Forum Standaardisatie
Kubernetes-API	CNCF	Opensourcestandaard met één gestandaardiseerde interface voor clusters, naamruimten, rechten, netwerkbeleid en quota; de standaardinrichting en de clusterdefinities zijn Kubernetes-objecten in versiebeheer. Uitbreidingen van OpenShift en operators vallen daarbuiten en zijn niet zonder meer overdraagbaar.	—
OCI Image en Distribution Specification (1.1)	Open Container Initiative	Formaat van containerbeelden en interface van de containerregistry; handtekeningen, onderdelenlijsten en herkomst staan als artefact bij het beeld, in het oude bundelformaat.	—
Container Network Interface (CNI)	CNCF	Aansluiting van werklasten op het clusternetwerk en op gedeclareerde netwerken.	—
Container Storage Interface (CSI)	CNCF	Koppelvlak voor blok- en bestandsopslag aan clusters, met de momentopnamen waarop de back-up voortbouwt; CSI is zelf geen back-upformaat. Ook de tijdelijke koppeling van bestaande netwerkopslag bij de overgang loopt via CSI, zonder gegevens te verplaatsen.	—
Gateway API	Kubernetes (SIG Network)	Beschrijving van verkeersregels op laag 7 in het dienstennetwerk.	—
OpenGitOps-principes (1.0)	CNCF	Werkwijze voor de gewenste inrichting: declaratief, versiebeheerd en onveranderbaar, automatisch opgehaald en doorlopend vergeleken.	—
YAML (1.2) en JSON (RFC 8259)	YAML-project; IETF	Formaat van dienstbeschrijvingen, clusterdefinities en beleid in versiebeheer.	JSON: aanbevolen
Git	Git-project	De-factostandaard. Versiebeheer van platform en toepassingen, met ondertekende vastleggingen.	—
Serverless Workflow (1.0)	CNCF	Beschrijving van werkstromen voor werkstromen als dienst, uitgevoerd door OpenShift Serverless Logic vanaf groeipadstap 4. De standaard maakt een werkstroom niet vanzelf overdraagbaar; een overstap wordt vooraf beproefd.	—
CloudEvents (1.0)	CNCF	Formaat van de gebeurtenissen die functies en werkstromen starten.	Pas toe of leg uit, als NL GOV-profiel

VoorstelWaarde#

Voor identiteit, toegang en verbindingen gebruikt het platform deze standaarden, in deze versies en voor dit gebruik.

Standaard	Beheerder	Gebruik in het platform	Forum Standaardisatie
SPIFFE	CNCF	Identiteit van draaiende software, herkenbaar binnen en buiten het platform; basis van de kortlevende certificaten in het dienstennetwerk.	—
OpenID Connect (1.0)	OpenID Foundation	Aanmelding van medewerkers en beheerders via de toegangsvoorziening; identiteit voor ondertekenen zonder sleutel.	Pas toe of leg uit, als OpenID.NLGov
OAuth (2.0, RFC 6749)	IETF	Toegangstokens voor beheerinterfaces en dashboards.	Aanbevolen; het NL GOV-profiel: pas toe of leg uit
SAML (2.0)	OASIS	Aanmelding voor onderdelen die geen OpenID Connect ondersteunen.	Pas toe of leg uit
LDAP (versie 3)	IETF	Aanmelding van het servermanagement via de directory.	Aanbevolen
WebAuthn en FIDO2 (passkeys)	W3C; FIDO Alliance	Phishingbestendige tweede factor voor platformrollen.	—
JSON Web Token (RFC 7519)	IETF	Vorm van de applicatie-identiteit voor systemen die geen certificaat kunnen controleren.	—
`X.509` (RFC 5280)	IETF	Certificaten van de eigen certificaatvoorziening voor diensten, knooppunten en toepassingen.	Aanbevolen
ACME (2.0, RFC 8555)	IETF	Automatische uitgifte van certificaten voor namen die van buiten bereikbaar zijn.	Pas toe of leg uit
TLS (1.3 en 1.2)	IETF	Versleuteling van verbindingen van toepassingen, API’s en beheer: 1.3 in het dienstennetwerk, 1.2 als ondergrens voor beheerinterfaces en koppelingen.	Pas toe of leg uit
HTTPS (RFC 9110)	IETF	Web- en beheerinterfaces en API’s; standaard via poort 443, daarnaast onder meer 6443 voor de cluster-API’s, 8443 voor beheerinterfaces en 8200 voor het geheimenbeheer.	Pas toe of leg uit, met HSTS
SSH (versie 2, RFC 4251)	IETF	Beheertoegang via de toegangsgateway en ondertekening van vastleggingen in versiebeheer.	Aanbevolen

VoorstelWaarde#

Voor cryptografie en vertrouwde opstart gebruikt het platform deze standaarden, in deze versies en voor dit gebruik.

Standaard	Beheerder	Gebruik in het platform	Forum Standaardisatie
AES (FIPS 197)	NIST	Versleuteling in rust van clustergegevens en schijven.	Aanbevolen
SHA-2 (ISO/IEC 10118-3)	ISO/IEC; NIST	Inhoudskenmerken van containerbeelden en onderdelen; basis van de handtekeningen in de softwareketen.	Aanbevolen
FIPS 140-3	NIST	Niet gekozen: het platform draait niet in FIPS-modus.	—
ML-KEM (FIPS 203) en ML-DSA (FIPS 204)	NIST	Quantumveilige sleuteluitwisseling, hybride in TLS 1.3 waar de producten haar bieden, en quantumveilige handtekeningen in een volgende versie van het geheimenbeheer.	—
PKCS#11 (3.x)	OASIS	Koppeling van het geheimenbeheer met een hardwaresleutelmodule voor ontgrendeling en sleutels.	—
TPM 2.0 (ISO/IEC 11889)	Trusted Computing Group	Sleutels voor schijfversleuteling en meting van de opstart op iedere server.	—
UEFI Secure Boot	UEFI Forum	Alleen ondertekende firmware en opstartsoftware.	—
RATS-architectuur (RFC 9334)	IETF	Attestatie op afstand als voorwaarde voor sleutelvrijgave bij gevoelige verwerking.	—

VoorstelWaarde#

Voor de softwareketen gebruikt het platform deze standaarden, in deze versies en voor dit gebruik.

Standaard	Beheerder	Gebruik in het platform	Forum Standaardisatie
SLSA (1.2)	OpenSSF	Eisen aan het bouwproces en de herkomstverklaring.	—
in-toto-attestaties	CNCF	Formaat van herkomst en onderdelenlijst als ondertekende verklaring bij het beeld.	—
CycloneDX (ECMA-424)	OWASP; Ecma International	Formaat van de onderdelenlijst (SBOM) van eigen software.	—
SPDX (ISO/IEC 5962)	Linux Foundation	Formaat van de onderdelenlijsten die leveranciers meeleveren; de analysevoorziening leest beide formaten.	—
Sigstore (bundel en transparantielogboek)	OpenSSF	Ondertekening zonder langlevende sleutel, met een eigen transparantielogboek; vanaf groeipadstap 2.	—
CVE	CVE-programma	Eenduidige aanduiding van kwetsbaarheden in scans, meldingen en uitzonderingen.	—

VoorstelWaarde#

Voor bewaking, logboeken en tijd gebruikt het platform deze standaarden, in deze versies en voor dit gebruik.

Standaard	Beheerder	Gebruik in het platform	Forum Standaardisatie
OpenTelemetry (OTLP)	CNCF	Metingen, logboeken en sporen van toepassingen.	—
Prometheus-formaat voor metingen	CNCF	De-factostandaard. Metingen op ieder cluster, de samengevatte metingen in het vlootbeheer en de exporters voor apparatuur.	—
Syslog (RFC 5424)	IETF	Doorsturen van logboeken van apparatuur, netwerk en opslag naar de SIEM.	—
CEF	—	De-factostandaard. Formaat van beveiligingsmeldingen naar de SIEM.	—
SNMP (versie 3)	IETF	Bewaking van switches, firewalls en verkeersverdeling; alleen versie 3, met authenticatie en versleuteling.	Aanbevolen
sFlow (versie 5)	sFlow.org	De-factostandaard. Steekproeven van netwerkverkeer van de leaves voor de netwerkweergave van het SOC.	—
Redfish (DSP0266)	DMTF	Bewaking van het servermanagement.	—
gRPC	CNCF	Doorlopende telemetrie van de switches.	—
NTP (versie 4, RFC 5905)	IETF	Tijd voor alle onderdelen.	Aanbevolen

VoorstelWaarde#

Voor opslag en gegevens gebruikt het platform deze standaarden, in deze versies en voor dit gebruik.

Standaard	Beheerder	Gebruik in het platform	Forum Standaardisatie
S3-interface, met Object Lock	—	De-factostandaard. Objectopslag voor toepassingen, back-ups en logboeken; onveranderbare kopieën met Object Lock.	—
NFS (versie 4, RFC 8881)	IETF	Tijdelijke koppeling van bestaande netwerkopslag bij de overgang van bestanden.	—
SMB (versie 3)	Open specificatie	Tijdelijke koppeling van bestaande gedeelde mappen bij dezelfde overgang.	—
SQL (ISO/IEC 9075)	ISO/IEC	Vraagtaal van de beheerde databases.	Aanbevolen
NVM Express	NVM Express	Aansluiting van de schijven in alle servertypen.	—

VoorstelWaarde#

Voor het datacenternetwerk gebruikt het platform deze standaarden, in deze versies en voor dit gebruik.

Standaard	Beheerder	Gebruik in het platform	Forum Standaardisatie
IEEE 802.1Q (VLAN)	IEEE	Scheiding van verkeerssoorten op de serveraansluiting.	—
IEEE 802.1AX (LACP)	IEEE	Bundeling van de twee poorten van iedere server; de spreiding over de twee leaves van het rek regelt EVPN-multihoming met ESI.	—
IEEE 802.1AE (MACsec)	IEEE	Versleuteling van de verbinding tussen de datacenters AM4 en AM2.	—
IPv4 (TCP/IP)	IETF	Adresplan van de eerste levering en van het interne platformverkeer.	Aanbevolen (TCP/IP); IPv6: pas toe of leg uit
OSPF (versie 2, RFC 2328)	IETF	Routering in de onderlaag van de fabric.	—
BGP (RFC 4271, met RFC 4760)	IETF	Uitwisseling van EVPN-routes in de fabric en route-aankondiging vanuit clusters.	—
BFD (RFC 5880)	IETF	Detectie van verbindingsuitval binnen een seconde; dat is niet de omschakeltijd.	—
TCP-AO (RFC 5925)	IETF	Authenticatie van de BGP-sessies; OSPF gebruikt een eigen authenticatie met HMAC-SHA.	—
EVPN (RFC 7432, 8365, 9135, 8584 en 9014)	IETF	Besturing van de overlay: aankondiging van adressen en routering tussen segmenten, ook voor de gerouteerde koppeling tussen de cellen, en multihoming met ESI voor de dubbele aansluiting op een leaf-paar. RFC 9014, voor interconnectie op laag 2, dekt die gerouteerde koppeling niet.	—
VXLAN (RFC 7348)	IETF	Encapsulatie van de segmenten over de onderlaag.	—
DSCP (RFC 2474) en ECN (RFC 3168)	IETF	Verkeersklassen en melding van overbelasting in de fabric.	—
DNS en DHCP	IETF	Namen en adressen uit de RWS-naamdienst.	—; DNSSEC staat wel op de lijst ‘pas toe of leg uit’

De lijst ‘pas toe of leg uit’

VastgesteldRegel#

Het platform past iedere standaard van de lijst ‘pas toe of leg uit’ van Forum Standaardisatie toe binnen haar functionele toepassingsgebied, of legt uit waarom niet; de lijst ‘aanbevolen’ is niet verplicht. Een afwijking legt de architect vast in een ontwerpbesluit, met de uitleg die het beleid vraagt. Standaarden voor functies die het platform niet zelf levert, beoordeelt de diensteigenaar van de dienst die zo’n functie aanbiedt.

Toelichting

Zulke functies zijn e-mail, websites, internetroutering, draadloze netwerken, documenten en vakinhoudelijke gegevens; biedt een dienst op het platform bijvoorbeeld een publieke website aan, dan beoordeelt haar diensteigenaar de standaarden daarvoor. Dit volgt uit het principe volg overheidsbrede kaders en ontwikkelingen.

VoorstelWaarde#

Voor iedere standaard van de lijst ‘pas toe of leg uit’ die binnen het bereik van het platform valt, liggen de stand en de verdere uitwerking vast. Toegepast betekent: in het ontwerp voorzien; de werking wordt bij de oplevering aangetoond.

Standaard	Stand	Uitwerking
TLS (1.3 en 1.2)	Toegepast, maar niet op protocollen zonder TLS, zoals BGP, OSPF, NTP, DNS en het opslagprotocol.	Per pad vastleggen welke verbindingen TLS gebruiken, hoe de overige apart zijn beveiligd en welke als uitzondering gelden.
ACME (2.0)	Toegepast.	—
HTTPS en HSTS (RFC 9110 en RFC 6797)	HTTPS toegepast op alle web- en beheerinterfaces; HSTS voorzien in de ingang van ieder cluster.	HSTS vastleggen in de standaardinrichting van de clusters, als annotatie op iedere route, en in de web- en beheerinterfaces; opnemen in de baseline.
Authenticatiestandaarden: OpenID.NLGov en SAML	OpenID Connect en SAML toegepast.	De toegangsvoorziening en de aangesloten diensten toetsen aan het profiel OpenID.NLGov; een afwijking vastleggen als uitleg.
NL GOV Assurance profile for OAuth 2.0	OAuth 2.0 toegepast.	Het profiel toepassen op API’s waarvoor het platform toegang namens gebruikers verleent, zoals die van het portaal; per API vastleggen.
NL GOV profile for CloudEvents (1.1)	CloudEvents gebruikt voor functies en werkstromen.	Het profiel toepassen op gebeurtenissen die met andere organisaties worden uitgewisseld; vastleggen bij de uitwerking van groeipadstap 4.
OpenAPI Specification (3.0) en REST-API Design Rules (2.2)	Voorzien voor de API’s die het platform zelf aanbiedt; de API-catalogus van het ontwikkelaarsportaal ontsluit ze vanaf groeipadstap 4.	Die API’s, zoals die van catalogus en portaal, beschrijven met OpenAPI 3 en ontwerpen volgens de REST-API Design Rules; teams die via de dienst applicatieverkeer en ketenkoppelingen API’s aanbieden, volgen dezelfde regels.
IPv6	De eerste levering heeft een IPv4-adresplan; dual-stack in het dienstennetwerk is een Technology Preview.	IPv6 aan de rand invoeren in groeipadstap 3; voor het interne verkeer van de fabric en de clusters de uitleg vastleggen waarom het IPv4 blijft.
DNSSEC	Geërfd van netwerkbeheer.	In de dienstafspraak met netwerkbeheer vastleggen dat de DNS-zone van iedere van buiten bereikbare naam met DNSSEC is ondertekend.
Digikoppeling	Ketenkoppelingen lopen via de dienst applicatieverkeer en ketenkoppelingen.	Voor koppelingen met andere overheidsorganisaties per aansluiting vastleggen of Digikoppeling van toepassing is.
STIX en TAXII (2.1)	Operationele en tactische dreigingsinformatie geërfd van het SOC; strategische dreigingsinformatie valt niet onder het SOC.	In de dienstafspraak met het SOC vastleggen welke dreigingsinformatie het platform ontvangt.
NEN-ISO/IEC 27001 en 27002	De lijst noemt versie 2013; het platform volgt ISO/IEC 27002:2022, zoals de Cyberbeveiligingsregeling sector overheid voorschrijft.	De uitleg voor versie 2022 is vastgelegd; nieuwe versies volgen via de jaarlijkse herziening van de baseline.

Verwijzen hiernaar

Onderwerpen 4

Ontwerpkeuzes 1

Open standaarden en overdraagbare configuratie