Zes lagen die elke omgeving standaard krijgt

Al het verkeer tussen browser, app en API loopt over TLS 1.3, of over TLS 1.2 met alleen moderne ciphers (AES-GCM of ChaCha20-Poly1305). Certificaten per omgeving komen van Actalis, een Italiaanse uitgever, en worden automatisch aangevraagd en vernieuwd. HSTS staat aan; oudere protocollen (TLS 1.0/1.1) en zwakke ciphers zijn uitgeschakeld.

Interne verbindingen (app ↔ database, app ↔ Redis) lopen binnen een afgeschermd Docker-netwerk op de server. Ports voor Postgres of Redis zijn nooit vanaf het internet bereikbaar.

De schijf van de databaseserver is bij onze hostingpartij volledig versleuteld. Dat geldt voor alle databases: die van elke omgeving en onze eigen beheerdatabase. De bestanden die je uploadt en onze back-ups staan bij de aanbieder van de objectopslag ook versleuteld opgeslagen.

Daarbovenop versleutelen wij gevoelige velden per veld, met AES-256-GCM: de wachtwoordkluis (wachtwoord, gebruikersnaam en notitie), TOTP-sleutels, sleutels en tokens van koppelingen, private keys van certificaten, telefoonnummers van gebruikers, klanten en contactpersonen, de IBAN en de boekingsregel van bankmutaties, handtekeningen en het vertrekadres voor ritten.

Elke omgeving heeft daarvoor een eigen willekeurige datasleutel. Die is gewikkeld met een hoofdsleutel die als bestand op de server staat, met een offline kopie: niet in de platformconfiguratie, niet in een database en niet in een back-up. Wie een kopie van de databases en van de back-ups heeft, kan deze velden daarmee niet ontsleutelen, ook niet met de platformconfiguratie erbij. Dat geldt voor back-ups vanaf 30 september 2026; in oudere back-ups hangt de sleutel van deze velden nog af van een geheim in de platformconfiguratie, en die back-ups verdwijnen na hun bewaartermijn. Zoeken op een telefoonnummer of IBAN gaat via een aparte sleutel (een blind index); zoeken op een deel van een nummer kan daardoor niet.

Namen, adressen, e-mailadressen, facturen en vrije tekst zijn niet per veld versleuteld, zodat zoeken, rapporteren en de fiscale bewaarplicht werken. Die vallen wel onder de versleuteling van de schijf bij de hostingpartij. Wachtwoorden om mee in te loggen worden niet versleuteld maar gehasht; zie hieronder.

Tweestapsverificatie verplicht voor elke gebruiker van je omgeving, voor medewerkers van administratiekantoren en voor beheerders in ons beheerpaneel. Wie nog geen tweede factor heeft ingesteld, wordt na het inloggen eerst naar het instellen gestuurd.

• TOTP. Elke app die zulke codes maakt werkt, ook een Europese of open-source app, zoals Proton Authenticator of Aegis. RFC 6238 met 30s-cycle, replay-preventie via lastTotpStep.
• Passkeys / WebAuthn. In je omgeving kun je daarnaast inloggen met Touch ID, Windows Hello of een hardware-key (YubiKey e.d.). Het klantportaal werkt alleen met passkeys, met een pincode of biometrie op het apparaat. Medewerkers van administratiekantoren en beheerders in ons beheerpaneel kunnen met een passkey inloggen in plaats van met een authenticator-app: de passkey is dan hun tweede factor. Een passkey toevoegen of verwijderen vraagt hun wachtwoord.

Rate-limiting per IP-adres: na 10 mislukte inlogpogingen binnen 15 minuten gaat inloggen 15 minuten dicht. Per account moet er na vijf mislukte pogingen steeds langer tussen zitten, zonder dat iemand anders jouw account op slot kan zetten. Wachtwoorden worden gehasht met Argon2id.

Een sessie in je omgeving vervalt na 12 uur zonder gebruik, en uiterlijk 7 dagen na het inloggen. Je kunt sessies per apparaat intrekken; een nieuw wachtwoord maakt alle andere sessies ongeldig.

Wijzigingen in je omgeving komen in het auditlog: facturen, betalingen, bank, gebruikers en rollen, instellingen en koppelingen, maar ook het dagelijkse werk zoals klanten, contactpersonen, taken, werkbonnen en offertes. Per regel staat erin:

• Wie het deed (naam en e-mailadres zoals ze op dat moment waren)
• Wat er gebeurde, met een korte samenvatting
• Op welk object
• Wanneer, en vanaf welk IP-adres en welke browser

Gewoon lezen wordt niet gelogd. Wel in het log: de volledige export van je omgeving, de AVG-export van een klant, een export van uren, projecten of werkbonnen, en het tonen van een wachtwoord uit de kluis. Bekijkt een administratiekantoor jouw gegevens via het portaal, dan komt dat ook in jouw log: één regel per medewerker per uur, en elke download apart. Zoeken wij voor een AVG-verzoek naar een persoon en komt die in jouw administratie voor, dan zie je dat ook in je log.

Een beheerder in je omgeving kan het log inzien. Gewone regels en aanmeldingen blijven 12 maanden; handelingen rond facturen, betalingen, bank, uren en ritten, en bewijs zoals contracten, offertes en ondertekeningen, 7 jaar. Het log is niet technisch beschermd tegen wijzigen: het opruimen haalt oude regels weg, en van een vertrokken medewerker verdwijnt het e-mailadres en wordt de naam na 7 jaar vervangen.

Elke nacht een back-up van elke database, in objectopslag bij Worldstream in Nederland, een andere partij dan de server. Elke back-up wordt versleuteld voor een publieke sleutel; de privésleutel om hem te openen bewaren wij offline, dus ook de server zelf kan een back-up niet lezen. Of de laatste back-up van jouw omgeving versleuteld was, staat in de beveiligingsverklaring, die een beheerder in je omgeving downloadt onder Instellingen.

Ook de bestanden die je uploadt (bonnen, factuur-PDF's, contract-scans) krijgen elke nacht zo'n versleutelde kopie. Een bestand dat daarna per ongeluk wordt verwijderd of overschreven, staat in die kopie nog even lang als een back-up.

Back-ups blijven 30 dagen bewaard, en nooit korter dan 7 dagen. Op verzoek zetten we een omgeving terug naar een van die back-ups. Een tijdstip tussen twee back-ups kan niet: wat na de laatste back-up is ingevoerd, zit er niet in.

Anders dan bij shared-schema multi-tenancy (waar één misplaatst WHERE-clausule data van andere tenants lekt) heeft elke Jema One-klant een eigen database. Een query kan niet bij een andere database. Er is geen "andere klant" in dezelfde database om per ongeluk te selecteren. De databases draaien wel op dezelfde databaseserver: de scheiding zit in de database, niet in de hardware.

Redis (voor rate-limiting en nonces) gebruikt per tenant een key- prefix; S3-uploads zitten in een tenant-subprefix. Modules die niet in je pakket zitten, zijn ook op de server dicht.

Er zijn twee ontwikkelaars. Elke codewijziging wordt vóór ze naar productie gaat door de andere ontwikkelaar nagekeken (vier ogen).

Er zijn vier beheerders. Zij werken alleen via ons beheerpaneel, met verplichte tweestapsverificatie, en hebben geen toegang tot de server, de database of de sleutels.

Om geen verkeerd beeld te geven:

• Er is geen tweede, actief draaiende kopie van de app of de database. De server draait wel als virtuele machine met high availability: valt de hardware uit, dan start hij automatisch opnieuw op een andere host, in een ander datacenter in dezelfde regio. Bij een fout in de software of de database zelf helpt dat niet; dan zetten we de laatste back-up terug, en dat is nog niet als oefening getest.
• Er is geen externe pentest gedaan. Wel testen we zelf dat omgevingen niet bij elkaar kunnen.
• De beschikbaarheid meten we vanaf 1 november 2026, met Uptime Kuma op een eigen server buiten het datacenter van de app: elke minuut per omgeving. Voor Professional en Enterprise geldt dan een SLA van 99,9% per maand (artikel 6 van de algemene voorwaarden). Daarvoor meten we hem niet.

Per maatregel staat de stand in de beveiligingsverklaring, die je als beheerder downloadt onder Instellingen, in elk pakket.