Beveiligingspraktijken

Gevoelige velden die in de platformdatabase worden opgeslagen, worden met AES-256-GCM versleuteld voordat ze naar schijf worden geschreven.

Wat	Hoe
Tenant API-sleutels (Anthropic, OpenAI-compat., SMTP)	AES-256-GCM, MASTER_ENCRYPTION_KEY
Gebruikerswachtwoord-hashes	bcrypt (cost 12)
BYOD-verbindingsstrings	AES-256-GCM, MASTER_ENCRYPTION_KEY
IMAP / e-mail-kanaalcredentials	AES-256-GCM, MASTER_ENCRYPTION_KEY
Databasebestanden op schijf	Gevoelige velden worden vóór opslag op applicatieniveau versleuteld (AES-256-GCM, per-tenant AAD, sleutels in HashiCorp Vault).

• Alle publieke endpoints uitsluitend via HTTPS; HTTP wordt omgeleid naar HTTPS (Apache HSTS-header).
• Minimale TLS-versie: TLS 1.3 (TLS 1.0 / 1.1 uitgeschakeld).
• Widget widget.js wordt geserveerd met Access-Control-Allow-Origin: *, maar de chat-API-endpoints valideren widget_key + origin-allowlist.
• Interne serviceaanroepen (Redis, MySQL op localhost) communiceren via de loopback-interface. Geen data verlaat de host onversleuteld.

Het volgende back-upschema is van toepassing op de platform-database en tenant-databases:

Item	Frequentie	Bewaarperiode	Locatie
Platform-DB (einstein_saas_platform)	Dagelijks, 's nachts (UTC, geautomatiseerd)	7 dagelijkse back-ups (roterend)	Lokaal volume + versleutelde offsite-replica
Tenant-DBs (einstein_saas_tenant_*)	Dagelijks, 's nachts (UTC, geautomatiseerd)	7 dagelijkse back-ups (roterend)	Lokaal volume + versleutelde offsite-replica
Geüploade bestanden / documentopslag	Dagelijks, 's nachts (UTC, geautomatiseerd)	7 dagelijkse back-ups (roterend)	Lokaal volume + versleutelde offsite-replica

Back-ups draaien per database via mysqldump --single-transaction, worden gecomprimeerd en met age versleuteld opgeslagen, gerepliceerd naar een apart offsite-volume, en elke run wordt gecontroleerd op een niet-lege dump en gelogd met succes-/mislukkingsstatus.

Back-uparchieven worden in rust versleuteld met age (X25519 / ChaCha20-Poly1305); de ontsleutelingssleutel wordt los van de archieven bewaard. Velden met kolomniveau-versleuteling (AES-256-GCM) blijven versleuteld binnen elk archief. Herstelbaarheid wordt geverifieerd met een geautomatiseerde maandelijkse restore-test.

4.1 Rolgebaseerde toegangscontrole (RBAC)

Elke portalgebruiker krijgt een rol toegewezen. Rollen bevatten granulaire permissies (51+ individuele vlaggen). Het platform past permissiecontroles server-side toe op elk API-endpoint.

4.2 Tweefactorauthenticatie

• 2FA via TOTP (RFC 6238 — Google Authenticator, Authy, etc.) is verplicht voor de owner-rol en wordt afgedwongen bij inloggen.
• Accounteigenaren kunnen 2FA verplicht stellen voor alle teamleden via het instellingenpaneel.
• Back-up herstelcodes worden gegenereerd bij inschrijving en moeten veilig worden opgeslagen door de gebruiker.

4.3 Tenant-isolatie

Authenticatie vereist een tenant-context (slug-gebaseerde login). Sessietokens zijn beperkt tot één tenant. Cross-tenant resource-toegang wordt voorkomen op de applicatielaag door verplichte tenant_id-filters op alle queries.

Significante acties op platform-resources worden vastgelegd in de tabel audit_log (platform-database). Elke invoer bevat:

• Actor: gebruikers-ID, rol en tenant-ID.
• Actie: werkwoord (aanmaken, bijwerken, verwijderen, inloggen, exporteren, …).
• Resource: entiteitstype en ID.
• Metadata: gewijzigde veldnamen en oud/nieuw waarden (gevoelige velden geredigeerd).
• Tijdstempel: opgeslagen in UTC (ISO 8601).
• IP-adres: bron-IP van het verzoek.

Auditlog-vermeldingen worden 2 jaar bewaard. Het log is append-only op applicatieniveau.

Een dedicated insert-only databasegebruiker (einstein_audit_writer) wordt gebruikt voor auditschrijfbewerkingen, waardoor wijziging of verwijdering van loginvoeren door de applicatiedatabasegebruiker wordt voorkomen.

6.1 CVE-monitoring

Composer-afhankelijkheden worden bij elke deploy-pipeline gemonitord via <code>composer audit</code>. Kritieke CVE's in runtime-afhankelijkheden worden binnen <strong>7 dagen</strong> na publicatie gepatcht; CVE's met hoge ernst binnen <strong>30 dagen</strong>.

6.2 Patchcyclus

• OS-beveiligingspatches: toegepast tijdens het wekelijkse onderhoudsvenster (zondag 02:00–04:00 UTC).
• PHP-runtime: bijgehouden op de nieuwste stabiele minor-versie van de actieve branch (momenteel PHP 8.2.x).
• Webserver: Apache 2.4.x — bijgehouden met distributie-beveiligingsupdates.

6.3 Responsible Disclosure

Externe beveiligingsonderzoekers worden uitgenodigd kwetsbaarheden te melden via ons gecoördineerde openbaarmakingsbeleid. Lees het responsible disclosure-beleid →

Component	Detail
Hostingregio	EU — Nederland
Productieserver	dev01-aionized (Ubuntu)
Webserver	Apache 2.4 (mod_rewrite, mod_ssl)
Runtime	PHP 8.2+
Database	MySQL / MariaDB (platform + per-tenant)
Cache / sessies	Redis (loopback, password-protected)
Grensoverschrijdende datatransfers	Standaard geen. Optionele cloud-AI-aanroepen (Anthropic/OpenAI-compat.) zijn gebruikerstoestemming-gebonden en gedekt door Standaardcontractbepalingen.