Als je digitale producten ontwikkelt, zoals websites en applicaties, krijg je te maken met standaarden en wetgeving waar jouw klant aan moet voldoen. Als het gaat om (web)toegankelijkheid voor mensen met een beperking is per 28 juni de nieuwe Wet Toegankelijke Producten en Diensten in werking getreden. Voor veel technische standaarden geldt al langer een verplichting of 'Pas toe of leg uit'-beleid. In dit artikel, opgesteld door Rootnet, partner van Dutch Digital Agencies, staan die standaarden op een rij en laten ze zien wat jij als ontwikkelaar kunt (en moet) doen.
Het Forum Standaardisatie heeft online een lijst met IT-standaarden waar gemeenten, provincies, rijk, waterschappen en alle uitvoeringsorganisaties aan moeten voldoen. Voor alle andere organisaties in de publieke sector geldt het gebruik van de ‘Pas toe of leg uit’. Een deel van deze standaarden heeft betrekking op websites en applicaties. Via de website internet.nl kun je eenvoudig controleren aan welke IT-standaarden een website voldoet. Scoor je hier geen 100%? Dan is er werk aan de winkel!
Websites en applicaties kunnen op het oog prima functioneren wanneer deze niet 100% voldoen aan de open standaarden van internet.nl, maar schijn bedriegt. Organisaties volgen deze standaarden en wanneer de website of applicatie van jouw klant daarvan afwijkt liggen lastige problemen op de loer. Bijvoorbeeld omdat deze toch niet voor iedereen bereikbaar blijkt. Of dat er simpelweg veiligheidsmaatregelen ontbreken. We lichten er een aantal toe.
Modern adres (IPv6)
Al in de jaren ‘90 was het duidelijk dat er een tekort ging ontstaan aan IPv4-adressen, het Internet Protocol waarmee het internet werkt. Sinds '98 is dan ook begonnen met de uitrol van de veel grotere pool aan IPv6 adressen. Deze dien je naast elkaar te gebruiken. Uiteindelijk zal, mede door het tekort, het IPv4 gebruik afnemen . Zonder IPv6 is jouw website dan niet meer bereikbaar.
Ondertekende domeinnaam (DNSSEC)
DNS is verantwoordelijk voor het vertalen van een domeinnaam naar een IP-adres van de server waar een website host. Bevind je je op een onveilig netwerk, dan kunnen DNS-vertalingen worden onderschept en vervalst. Om dit te voorkomen gebruik je DNSSEC, een sleuteltechniek waardoor een computer kan controleren of een DNS-vertaling legitiem is.
Beveiligde verbinding (HTTPS)
Het is nu bijna ondenkbaar om geen beveiligde verbinding (HTTPS) aan te bieden, webbrowsers gaan hier van uit. Bij de implementatie van TLS (voorheen SSL) dien je wel op te letten. Je gebruikt een moderne versie, 1.2 of 1.3. Oudere versies maken je website onbereikbaar voor moderne browsers of krijgen een waarschuwing. Kijk voor een uitgebreidere test op https://www.ssllabs.com/ssltest/
Ook headers als HSTS spelen een rol. Deze dwingt namelijk een browser altijd gebruik te maken van de beveiligde verbinding. Zonder deze forcering kan verkeer, zoals je username en wachtwoord, alsnog onveilig over het internet en worden onderschept.
Beveiligingsopties
De beveiligingsopties in het overzicht van internet.nl zijn niet allemaal verplicht. Een website werkt prima zonder. Maar ze beschermen wel degelijk, vooral op het moment dat het fout gaat. De X-Frame-Options header voorkomt dat de website mag worden geframed in een andere website. De Content-Security-Policy omschrijft vanaf welke bronnen een website content mag inladen. Bij een slechte post of hack voorkom je dus kwaadaardige content dat elders is gehost.
Met Referrer-Policy bepaal je of, en welke, gegevens worden meegegeven aan de website die een bezoeker bekijkt nadat deze van jullie website af komt. Vreemd dat dit gebeurt? Het is (helaas) standaard gedrag. Daarom doe je er goed aan dit te beperken met waarden als: no-referrer of same-origin.
Security.txt
Deze beveiligingsoptie krijgt recent meer aandacht en is ook voor de eerdergenoemde doelgroep verplicht. Het betreft een txt bestand die je plaatst bij je website . Hierin staan de contactgegevens waar een eventuele hacker of onderzoeker melding kan doen van risico's op de website. Dit moet volgens een specifiek format en regel je bij voorkeur centraal voor al jouw klanten of websites.
Route-autorisatie (RPKI)
Van alle standaarden kun je als ontwikkelaar hier misschien nog wel het minst aan doen. Je hostingpartner moet dit op orde hebben om te voorkomen dat verkeer naar zijn servers kan worden omgeleid door kwaadwillenden. Gelukkig is dit onderdeel bij de meeste aanbieders wel op orde.
Ook voor e-mailverkeer gelden standaarden. Wanneer je ze niet implementeert heeft dit vrijwel altijd impact op het kunnen afleveren e-mail aan ontvangers. Berichten belangen linea recta in de SPAMfolder of komen überhaupt niet aan.
In de e-mailtest van internet.nl zie je dat ook hier het gebruik van IPv6, DNSSEC, TLS en RPKI essentieel is. Maar aanvullend is het gebruik van DMARC, DKIM en SPF.
SPF
Met SPF specificeer je via een DNS-record welke servers (IP-adressen) e-mail mogen versturen namens een domeinnaam. Hierin benoem je, logischerwijs de e-mailserver van de organisatie, maar bijvoorbeeld ook een webserver, facturatiesysteem en mailingsysteem. Als de ontvangende partij van een e-mailbericht ziet dat de verzendende mailserver niet via SPF is vrijgegeven, dan zal het bericht een negatieve beoordeling krijgen en waarschijnlijk worden gezien als SPAM.
DKIM
Met DKIM kun je controleren of de afzender van een e-mailbericht is wie hij claimt te zijn. Als eigenaar van een domeinnaam publiceer je een publieke DKIM-sleutel via een DNS-record. De uitgaande mailserver krijgt een private DKIM-sleutel waarmee hij ieder e-mailbericht kan ondertekenen.
Alle ontvangende mailservers controleren vervolgens of de DKIM-handtekening van een e-mailbericht past bij de gepubliceerde sleutel in de DNS van een domeinnaam. Wanneer deze niet bij elkaar passen dan is er hoogstwaarschijnlijk spraken van een SPAM-bericht.
DMARC
Middels DMARC geef je via een DNS-record instructies aan een ontvangende mailserver over wat deze moet doen wanneer SPF en/of DKIM-checks falen. Als eigenaar van een domeinnaam kun je bijvoorbeeld opgeven dat dergelijke berichten van jouw domeinnamen als niet-legitiem moeten worden gezien en moeten worden tegengehouden. Je kunt via een DMARC ook aangeven hier rapportages over te willen ontvangen. Zo kun je monitoren welk e-mailverkeer namens jouw domeinnaam is tegengehouden.
Scoren jouw websites of die van jouw opdrachtgevers geen 100% in deze tests? Dan is actie vereist. Steeds meer organisaties zijn zich hiervan bewust, maar vinden het lastig dit te implementeren. Het managed hosting platform van Rootnet is ontworpen om standaard aan deze, en vele andere compliance, eisen te voldoen. Wil jij een extra USP voor bij de volgende aanbesteding? Of überhaupt je digitale producten naar de nieuwste standaarden trekken? Dat is gelukkig makkelijker dan je denkt: Rootnet staat voor je klaar .
DDA: Nederlandse Digitaliseringsstrategie biedt kansen voor een betere digitale overheid
