Functie

Beveiliging die je kunt aanzetten zonder iedereen buiten te sluiten

De meeste beveiligingsmaatregelen sneuvelen op het moment dat ze het werk in de weg zitten. Daarom zijn ze hier zo gebouwd dat je ze stapsgewijs kunt aanzetten, met een bedenktijd, en dat je altijd kunt zien wat er gebeurt. Wat niet onderhandelbaar is, staat standaard aan.

Tweestapsverificatie per rol Noodrem op alle sessies Verzegeld logboek

Inloggen en tweestapsverificatie

Iedereen kiest zijn eigen wachtwoord via een uitnodiging; er wordt nooit een wachtwoord voor iemand bedacht en doorgemaild. Tweestapsverificatie met een authenticatie-app kun je verplicht stellen voor alleen de HR-kant, of voor iedereen, of voor niemand. Standaard staat het uit, want aanzetten mag nooit betekenen dat de helft van je team er de volgende ochtend uit ligt.

Daarom is er een bedenktijd, standaard veertien dagen. Binnen die periode kan iemand nog gewoon werken en wordt hij aangespoord het in te stellen. Daarna komt hij alleen nog bij het instelscherm. Tabletaccounts voor het kioskscherm vallen er nooit onder; dat is een apparaat, geen mens.

Tegen wachtwoorden raden zitten twee onafhankelijke remmen. Er is een limiet per IP-adres, en daarnaast een teller per account die oplopend langer blokkeert. Die tweede is de belangrijkste, want een aanvaller die elke poging vanaf een ander adres doet, glipt anders door de eerste heen. Die teller overleeft ook een herstart van de server.

  • Eigen wachtwoord via een uitnodiging, nooit een toegestuurd wachtwoord
  • Tweestapsverificatie voor niemand, alleen HR of iedereen
  • Bedenktijd van nul tot negentig dagen, standaard veertien
  • Kiosk-tabletaccounts vallen er nooit onder
  • Rem per IP-adres en een oplopende rem per account
  • Vijf verkeerde pincodes op de tablet geven vijftien minuten pauze

Nog een keer bevestigen wie je bent

Voor de zwaarste handelingen is inloggen niet genoeg. Je moet opnieuw bewijzen wie je bent, met je wachtwoord of met een code uit je authenticatie-app. Die bevestiging geldt vijf minuten, zodat je een paar handelingen achter elkaar kunt doen zonder telkens te typen, maar een onbeheerde laptop niet urenlang bruikbaar is.

Dat geldt onder meer voor: iemand een andere rol geven, een inzage-export maken, een ex-medewerker anonimiseren, alle sessies intrekken, een koppeling met een ander systeem opzetten of aanpassen, tijdelijke rechten toekennen, en het terughalen van geparkeerd werk.

  • Wachtwoord of code uit de authenticatie-app
  • Vijf minuten geldig, daarna opnieuw
  • Vereist bij rollen wijzigen en tijdelijke rechten
  • Vereist bij inzage-export en anonimiseren
  • Vereist bij koppelingen en bij de sessie-noodrem

Rechten, tijdelijke rechten en de noodrem

Er zijn tien grove rechten waaraan negentien concrete handelingen hangen. Elke rol heeft een vaste set. Twee daarvan zijn nooit uit te delen als tijdelijk recht: het beheer-recht en het configureren van koppelingen. Dat is de rem op de klassieke escalatietruc, waarbij iemand zichzelf via een omweg beheerder maakt. Niemand kan bovendien een rol uitdelen die gelijk is aan of hoger dan zijn eigen rol.

Soms heeft iemand tijdelijk meer nodig. Daarvoor is er een tijdelijk recht met een looptijd in minuten en een verplichte reden. Er is ook een noodvariant voor het geval er iets echt misgaat; die geeft direct een beveiligingsmelding, een bericht aan de beheerders en een verzegeld bewijs van wat er is gedaan. Beide vervallen vanzelf.

Denk je dat een account of een cookie is gelekt, dan is er de noodrem: in één handeling worden alle bestaande sessies van je organisatie ongeldig. Iedereen moet opnieuw inloggen; wie daarna inlogt houdt gewoon toegang. Je kunt de noodrem daarna weer opheffen.

  • Tien grove rechten, negentien concrete handelingen
  • Beheer en koppelingsconfiguratie zijn nooit tijdelijk uit te delen
  • Geen rol uitdelen die gelijk is aan of hoger dan je eigen rol
  • Tijdelijke rechten met looptijd en verplichte reden
  • Noodtoegang met alarm, bericht en verzegeld bewijs
  • Noodrem die in één klap alle sessies intrekt

Meekijken zonder dat er iemand meekijkt

Er is een beveiligingsscherm met het aantal gebeurtenissen per soort over het afgelopen uur en de afgelopen dag, met een drempelwaarschuwing erbij. Maar een scherm helpt alleen als iemand ernaar kijkt, en dat is zondagnacht meestal niet zo. Daarom draaien er twee taken die zelf melden.

De eerste kijkt elke tien minuten of er een piek zit in beveiligingsgebeurtenissen, over twee tijdvensters, en meldt een vondst bij de beheerders. De tweede kijkt elk kwartier naar geslaagde logins van dezelfde persoon vanaf duidelijk verschillende netwerkblokken binnen korte tijd. Dat is de klassieke aanwijzing voor een overgenomen account.

Die tweede controle werkt bewust zonder een geografische database en zonder een externe dienst: er wordt nergens opgevraagd waar een IP-adres vandaan komt. Ook wordt niet het hele adres opgeslagen maar alleen het blok. Minder precisie, maar ook geen gegevens die naar buiten gaan.

  • Beveiligingsscherm met tellingen per uur en per dag
  • Piekdetectie elke tien minuten, met melding aan de beheerders
  • Verdachte inloglocaties elk kwartier gecontroleerd
  • Geen externe geodatabase, geen externe aanroepen
  • Alleen het netwerkblok wordt bewaard, niet het volledige adres

Een logboek dat je kunt vertrouwen

Elke gevoelige handeling komt in een logboek dat alleen groeit: er is geen weg om een regel te wijzigen of te verwijderen. De database weigert dat zelf, los van de applicatie.

Daar bovenop zit een derde slot. Elke regel bevat een cryptografische verwijzing naar de vorige, en is bovendien verzegeld met een geheim dat niet in de database staat. Wordt er toch een regel gewijzigd, weggehaald of tussengevoegd, dan klopt de keten niet meer en zie je dat. Zonder dat zegel start de tool in productie niet eens op.

Bij menselijke goedkeuringen, zoals verlof goedkeuren, een periode afsluiten of de loonverwerking vrijgeven, komt er nog een verklaring bij: wie besliste wat, wanneer, verzegeld tegen wijziging achteraf. Dat is het verschil tussen "het staat in het log" en "we kunnen het aantonen".

  • Logboek dat alleen groeit, afgedwongen door de database zelf
  • Elke regel verwijst cryptografisch naar de vorige
  • Een zegel dat een aanpassing achteraf aantoonbaar maakt
  • Zonder zegel start de tool in productie niet op
  • Verzegelde verklaringen bij menselijke goedkeuringen

Waar de gegevens staan en hoe

Elke organisatie krijgt een eigen, fysiek gescheiden database. Geen gedeelde tabel met een klantkolom waar één vergeten filter een lek oplevert, maar een aparte database per klant. De servers staan in Nederland.

Gevoelige velden staan versleuteld opgeslagen met een gangbaar sterk algoritme, met een authenticatietag die elke manipulatie zichtbaar maakt. Het gaat om geboortedatum, IBAN, telefoonnummer, adres, postcode en de contactpersoon voor noodgevallen, plus de begeleidingsgegevens bij een ziekmelding. Sleutels kunnen gewisseld worden zonder dat oude gegevens onleesbaar worden.

Uitgaande koppelingen zijn dichtgezet tegen misbruik: een adres moet met https werken en interne of lokale adressen worden geweigerd, zodat een verkeerd ingevuld adres de server niet naar zijn eigen binnenkant kan sturen. Een gedeeld geheim wordt alleen geschreven, nooit teruggetoond.

  • Een eigen, fysiek gescheiden database per organisatie
  • Servers in Nederland
  • Gevoelige velden versleuteld, met detectie van manipulatie
  • Sleutelwissel zonder oude gegevens onleesbaar te maken
  • Uitgaande koppelingen alleen via https, geen interne adressen
  • Gedeelde geheimen worden nooit teruggetoond
Wat het je oplevert

Waar je het aan merkt

Beveiliging die blijft staan

Een bedenktijd zorgt dat aanzetten niemand buitensluit.

Een gestolen cookie is niet genoeg

De zwaarste handelingen vragen een verse bevestiging van je identiteit.

Een knop voor als het misgaat

Alle sessies intrekken kost één handeling en is daarna weer op te heffen.

Meldingen ook als niemand kijkt

Pieken en verdachte logins worden gemeld, niet alleen getoond.

Aantoonbaar wie wat deed

Het logboek is verzegeld, dus een aanpassing achteraf valt op.

Geen buren in je database

Elke organisatie heeft een eigen database, niet een gedeelde tabel.

Vragen

Wat men hierover vraagt

Moet iedereen tweestapsverificatie gebruiken?

Dat bepaal je zelf. Je kunt het verplichten voor de HR-kant, voor iedereen, of voor niemand. Standaard staat het uit, en bij aanzetten geldt een bedenktijd zodat niemand meteen buiten staat.

Wat als een laptop met een openstaande sessie wordt gestolen?

Trek de sessies in met de noodrem. Elke bestaande sessie wordt daarmee in één keer ongeldig en iedereen logt opnieuw in. De handeling zelf vraagt een tweede bevestiging en staat in het logboek.

Kan een beheerder het logboek aanpassen?

De applicatie kent geen weg om een regel te wijzigen of te wissen, en de database weigert het ook. Zou iemand met beheerdersrechten op de database het toch proberen, dan klopt de cryptografische keten niet meer en is dat zichtbaar.

Zijn er onafhankelijke controles gedaan?

Er zijn interne aanvalstesten uitgevoerd op de rollen, de scheiding tussen organisaties en de invoerpaden, en de bevindingen zijn verwerkt. Een certificering zoals ISO 27001 hebben we niet; dat vertellen we liever nu dan in een offerte.

Kijk zelf in het beveiligingsscherm

Maak een gratis omgeving aan, log een paar keer in en bekijk wat er wordt vastgelegd. Dat zegt meer dan een lijst met maatregelen.