Deze pagina beschrijft beveiligingsmaatregelen die momenteel in KeyInOut zijn geïmplementeerd; dit is geen certificering, penetratietestrapport of garantie dat er geen kwetsbaarheden kunnen bestaan.
01Isolatie van werkruimtes
Applicatiegegevens worden beperkt tot de geauthenticeerde werkruimte. Gevoelige queries bevatten de bedrijfs-/werkruimte-ID en rollen beperken functies voor eigenaar en beheerder. Dit ontwerp is bedoeld om het risico te verkleinen dat een gebruiker toegang krijgt tot gegevens van een andere organisatie.
02Ontwerp van QR-codes
QR-labels gebruiken willekeurige, nietszeggende openbare identificaties in plaats van opeenvolgende database-ID’s. Een QR-identificatie geldt niet als autorisatie om privégegevens van de werkruimte te bekijken. Openbare pagina’s voor gevonden sleutels zijn ontworpen om alleen retourinformatie te tonen die de werkruimte bewust heeft ingeschakeld, niet sleutelnamen, houders, locaties, haakposities, retourdatums of overdrachtsstatus.
03Authenticatie en wachtwoorden
Wachtwoorden worden opgeslagen met de wachtwoordhashfuncties van PHP, met Argon2id wanneer beschikbaar. Links voor wachtwoordherstel, e-mailverificatie en uitnodigingen gebruiken tokens met hoge entropie en slaan waar van toepassing hashes van tokens op in plaats van herbruikbare geheimen in platte tekst. Inlogpogingen worden beperkt.
04Sessies en verzoekbescherming
Geauthenticeerde sessies gebruiken versterkte PHP-instellingen zoals HttpOnly-cookies, SameSite-bescherming, secure cookies via HTTPS en regeneratie van sessie-ID’s. Verzoeken die gegevens wijzigen gebruiken CSRF-bescherming. Gevoelige authenticatie-/tokenpagina’s gebruiken beperkende cache- en referrerpolicies.
05Database- en applicatiebescherming
Databasetoegang gebruikt native PDO prepared statements. Door gebruikers beïnvloede uitvoer wordt in HTML-context geëscapet. Kritieke uitgifte-/retourhandelingen gebruiken databasetransacties en rijvergrendeling om race conditions, zoals dubbele uitgifte, te beperken.
06Browser- en transportbeveiliging
KeyInOut is ontworpen voor HTTPS en verstuurt browserbeveiligingsheaders zoals Content Security Policy, HSTS via HTTPS, framebeperkingen en bescherming tegen MIME-sniffing. Applicatie-assets worden lokaal geserveerd in plaats van tijdens runtime afhankelijk te zijn van CDN’s van derden.
07Gegevensminimalisatie
QR-codes bevatten geen sleutelnamen, locaties of houdergegevens. Herinneringsmails beperken bewust de hoeveelheid operationele sleutelinformatie. Door gebruikers aangevraagde werkruimte-exporten sluiten wachtwoordhashes en authenticatietokenhashes uit. KeyInOut verzamelt momenteel geen betaalkaartgegevens.
08Rollen en traceerbaarheid
Werkruimterollen scheiden eigenaar-/beheerfuncties van gewone ledentoegang. Sleuteluitgiftes en -retouren worden vastgelegd in de activiteitengeschiedenis en administratieve acties worden gelogd waar geïmplementeerd. Deze logs ondersteunen verantwoordelijkheid maar vervangen niet de eigen toegangsprocedures van de klant.
09Infrastructuur en geheimen
KeyInOut gebruikt momenteel gehoste infrastructuur voor webapplicatie, database en transactionele e-mail. Gevoelige mailconfiguratie is ontworpen om buiten de openbare webroot te blijven. We blijven de deploymentconfiguratie aanscherpen terwijl de bèta richting productie gaat.
10Een kwetsbaarheid melden
Denk je dat je een beveiligingsprobleem hebt gevonden, mail dan security@keyinout.com met voldoende informatie om het probleem te reproduceren en beoordelen. Vermijd toegang tot gegevens die niet van jou zijn, verstoring van de dienst, destructieve tests of openbare bekendmaking voordat we een redelijke kans hebben gehad om het probleem te onderzoeken en te verhelpen.
Voor privacyvragen die geen beveiligingskwetsbaarheid zijn, gebruik je privacy@keyinout.com.