Hoe veilig is jouw webapplicatie? 7 eisen die je moet toepassen

De beveiliging van webapplicaties heeft helaas niet altijd de hoogste prioriteit, maar is nu echt een MUST geworden! Bevat de applicatie persoonsgegevens, dan ben je mogelijk in overtreding als de applicatie onvoldoende beveiligd is…  Mocht er een datalek optreden, dan ben jij als eigenaar van de gegevens verantwoordelijk. De gevolgen kunnen groot zijn, niet alleen financieel, maar ook op het gebied van mogelijke reputatieschade.

Bij Interpulse hebben we veel verschillende webapplicaties ontwikkeld waarbij voorheen beveiligingsfunctionaliteiten overboord werden gegooid om redenen als wat heb ik daar aan?, wat voor waarde levert dat op? of totaal niet praktisch…  Nu wordt dit altijd direct vanaf de start opgepakt: ‘security by design‘!

Wat moet er toegepast worden om veilig te zijn?

Het beveiligen van data is op verschillende niveaus te realiseren, het is bijvoorbeeld mogelijk om een goed slot op te hangen, maar je kunt ook een kluis opzetten met 5 verschillende sloten. Onderstaande beveiligingstoepassingen zijn naar ons idee erg verstandig om toe te passen. Mocht er in je applicatie iets niet geregeld zijn, leg dit dan eens voor bij je webbouwer.

Database encryptie op persoonlijke gegevens

Encryptie is het versleutelen van informatie zodat deze gegevens niet leesbaar zijn zonder in het bezit te zijn van een sleutel. Persoonlijke gegevens die tot misbruik kunnen leiden of impact kan hebben op de privacy van personen moet versleuteld worden. Denk aan NAW gegevens, e-mail adressen en zeker ook bankgegevens en andere (zeer) gevoelige data. Mocht iemand de database in bezit krijgen, dan hebben ze met deze encryptie nog niets bruikbaars in handen.

Wachtwoord – alleen instelbaar door gebruiker

In veel applicaties wordt een gebruiker van het systeem aangemaakt door een beheerder. Bij de gebruiker wordt een wachtwoord door de beheerder ingesteld, waarna deze (vaak op een onveilige manier) aan de gebruiker wordt verstrekt. In dit geval zijn er minimaal 2 personen op de hoogte van het wachtwoord.

Veel veiliger is het om bij het aanmaken van een gebruiker automatisch een e-mail te versturen. In de e-mail is een link opgenomen welke verwijst naar een locatie waar hij of zij zelf een wachtwoord kan instellen. De link is eenmalig te gebruiken en heeft een houdbaarheid van bijvoorbeeld 2 dagen.

Wachtwoord – hashing

Het veilig opslaan van wachtwoorden is noodzakelijk. In het geval van password hashing wordt een wachtwoord ‘gehashed’ (versleuteld) opgeslagen in de database. Ook ontwikkelaars of andere beheerders van de applicatie kunnen het wachtwoord niet achterhalen. Want zeg nu zelf, gebruik jij altijd een ander wachtwoord?

Wachtwoord – sterkte afdwingen

Wachtwoorden zijn vaak slecht gekozen. Dwing de gebruiker een veilig wachtwoord te kiezen dat voldoet aan minimale eisen.

Wachtwoord – verloop

De meningen over het laten verlopen van een wachtwoord lopen nog wat uiteen, maar wij adviseren periodiek (minimaal 1x per jaar) een wachtwoord te laten verlopen. De gebruiker moet dan opnieuw een veilig wachtwoord kiezen, wat bij voorkeur niet teveel lijkt op eerder gekozen wachtwoorden.

Bevestigen nieuw IP adres en topografische blokkades

Bevat je applicatie veel bijzondere persoonsgegevens, dan kan het verstandig zijn om IP-adressen te laten bevestigen. Stel dat je inlogt vanaf een niet bekende locatie, dan wordt er een e-mail verzonden naar het e-mailadres van de gebruiker waarna deze de locatie kan bevestigen. Alternatief of aanvulling kan zijn de ip-adressen vanuit bepaalde werelddelen of landen te blokkeren. Want waarom zo iemand vanuit Roemenië in moeten loggen op je webapplicatie?

Two factor authentication (aanbevolen!)

Two factor authenticatie (ook wel Multi factor authentication genoemd) is een extra stap tijdens het login proces. Two factor authentication vereist twee of meer authenticatiemiddelen. In de praktijk blijkt het verliezen van inloggegevens door de gebruiker zelf het grootste risico. Deze methode zorgt ervoor dat je niets hebt aan alleen gebruikersnaam en wachtwoord.

Allereerst moet gebruikersnaam en het wachtwoord worden ingevoerd, daarnaast (2e factor) moet de mobiele telefoon geraadpleegd worden. Zonder mobiele telefoon kan je niet verder.

Wij adviseren hierin het gebruik van een Authenticator app. Hiermee kan een code gegenereerd worden op de smartphone, die vervolgens ingevuld moet worden. Er zijn overigens verschillende implementaties mogelijk. Voor bepaalde doelgroepen werkt bijvoorbeeld de traditionele SMS beter, omdat deze toegankelijker in gebruik is.

Single Sign On (SSO)

SSO maakt het mogelijk om eenmalig in te loggen, waarna gebruikers automatisch toegang krijgen tot meerdere applicaties. Mocht je Microsoft Office 365 gebruiken, dan kan deze bijvoorbeeld gebruikt worden om ook automatisch in te loggen bij een maatwerk applicatie. Er kan dan centraal bepaald worden of iemand nog mag inloggen, wel zo fijn als een medewerker het bedrijf verlaat of een nieuwe medewerker aangesteld wordt. Bijkomend voordeel van SSO is dat een deel van eerdergenoemde beveiligingstoepassingen al voorhanden is, want dit wordt centraal geregeld door Microsoft. Wij raden SSO dan ook sterk aan.

Wij zijn blij dat beveiliging een belangrijk onderdeel is geworden en dat opdrachtgevers de waarde inzien van een veilige webapplicatie. Heb je nog vragen over het goed beveiligen van je applicatie, stel ze gerust!