Security & audit

Wat wij regelen, wat jij regelt

FixControl draait als cloud-dienst. De zware infrastructuur — TLS-certificaten, JWT key-rotatie, rate-limiting, database-isolatie — beheren wij. Jij hebt aan jouw kant een aantal knoppen voor accountbeveiliging, identity en zichtbaarheid.

Tenant-isolatie

Iedere organisatie (tenant) heeft volledig gescheiden data. Andere FixControl-klanten kunnen jullie issues, e-mails, klantgegevens, codebases of memory-regels niet zien. De afdwinging is gelaagd over authenticatie, applicatie-filters en database-rij-beveiliging, met strict mode verplicht bij boot in hosted productie.

Wat dit betekent in de praktijk:

• Jouw Gmail-tokens leven in een rij die alleen jouw tenant kan lezen.
• Een gebruiker uit een andere tenant kan geen issue van jou opvragen, ook niet via de URL.
• Knowledge-chunks worden nooit cross-tenant doorzocht.
• Ook cross-tenant uitleeshandelingen door FixControl-platformpersoneel gaan via hetzelfde isolatie-pad en worden geaudit.

Audit log

De audit log is tamper-evident. Elke staat-wijziging schrijft een rij met een per-tenant sequence en een hash die geketend is aan de vorige rij. Het wijzigen van een willekeurige rij breekt elke volgende hash, wat een export-en-verifieer-workflow detecteert.

Elke geaudite gebeurtenis legt de actor vast (een gebruiker, API-key of systeem), de eventnaam (bijv. patch.approved), het doel, de tenant en de gewijzigde velden (gevoelige waarden geredacteerd). Bekijk de log onder Settings → Audit.

Standaard retentie: 365 dagen. Audit-export (per tenant, CSV in een ondertekende envelop zodat een externe verifier de keten kan nachecken) is beschikbaar onder Settings → Audit → Export. De platform-admin-export (alle tenants, alleen staff) is NDJSON.

De inbox-row event log (de timeline die je in inbox-detail ziet) is een aparte stroom — operator-UX, geen security-audit. Niet verwarren.

Sessies

• Standaard sessie-duur: 24 uur.
• Uitloggen op dit apparaat: rechtsboven.
• Overal uitloggen (sessies intrekken): Settings → Users → "Revoke sessions" op de gebruiker. Handig wanneer een laptop wordt gestolen of een collega vertrekt.

Signing keys roteren op schema. Ingetrokken sessies werken direct niet meer, ook al is de token-signature verder nog geldig.

Wachtwoorden

Opgeslagen als bcrypt-hashes — geen plain text, niet recoverable. Een vergeten wachtwoord betekent reset.

• Minimaal 8 tekens.
• Geen complexiteits-eisen op letters/cijfers/symbolen, maar triviale wachtwoorden zijn sterk afgeraden.
• MFA: afdwingen via een OIDC IdP (Okta, Azure AD, Google Workspace) — MFA op de lokale wachtwoord-laag wordt bewust niet aangeboden. Zie Gebruikers & identity → OIDC SSO.

Identity

Zie Gebruikers & identity voor de inrichting.

Two-person rule voor destructieve admin-acties

Een catalogus van destructieve operaties (tenant-verwijdering, secret-rotatie, massale deactivatie, wijziging van audit-retentie, etc.) vereist een token dat door één admin wordt uitgegeven en door een ander wordt geconsumeerd:

1. Admin A gaat naar Admin → Approvals en geeft een token uit voor de actie + het doel.
2. Admin A geeft het token aan admin B (out of band, bijv. via Slack-DM).
3. De destructieve call van admin B draagt het token; het systeem consumeert het.
4. Het token is single-use, met een TTL van 10 minuten.

Elke gegate actie is ook rate-limited per admin per actie. Uitgiftes, consumpties, weigeringen en rate-limit hits worden allemaal geaudit.

Bij een incident

Ontdek je verdacht verkeer of een mogelijk gelekt wachtwoord:

1. Trek de sessies in voor het betreffende account (Settings → Users).
2. Reset het wachtwoord of deactiveer de gebruiker.
3. Inspecteer de audit log voor activiteit door dat account in het betreffende venster.
4. Meld het bij ons via /contact — we kunnen dieper kijken in platform-logs en assisteren bij de keten-herverificatie als je dat nodig hebt.

Wat bewust niet wordt ondersteund

• Auto-merge van patches. Een patch wordt geleverd als PR of commit; mergen is een expliciete operator-actie.
• Meerdere IdP's per tenant. Eén OIDC-provider per tenant.
• MFA op de FixControl-wachtwoordlaag. Gebruik OIDC + IdP-afgedwongen MFA.
• BYOK (bring your own encryption key). Wordt vandaag niet aangeboden.
• Cross-tenant analytics. Geen "shared insights"-oppervlak; cross-tenant operaties vereisen platformAdmin en worden geaudit.
• Self-service tenant-verwijdering via API. Loopt via een handmatig support-traject met een bevestigd hold-venster.
• Auto-mapping van SCIM-groepen naar FixControl-rollen. Groepen worden opgeslagen; mapping is een handmatige admin-stap.

Gefaseerde uitrol-filosofie

Elk nieuw automatiseringsoppervlak komt in deze volgorde uit, nooit omgekeerd:

1. Suggested only — AI bereidt voor; operator geeft vrij. Standaard voor elke tenant.
2. Auto-draft, opt-in — AI bereidt het artefact voor; operator geeft nog steeds vrij.
3. Auto-send / auto-apply, opt-in + guarded — vrijgegeven zonder operator-actie; standaard uit. Audit-loud.

Een nieuw automatiseringsniveau is nooit de default voor een bestaande tenant. Jij kiest ervoor.

Veelgestelde vragen

Mogen mijn klanten zien dat ik FixControl gebruik? Niet zichtbaar voor hen — antwoorden komen vanuit jouw eigen support-adres, geen "Powered by"-vermelding.

Worden e-mails uit Gmail bewaard in jullie database? De relevante velden (afzender, onderwerp, body) ja, voor inbox-tracking. Verwijder een issue en de bijbehorende inbound-mail wordt cascade-verwijderd.

Wie van FixControl kan bij mijn data? Een klein support-team, alleen voor expliciet incident-onderzoek, na jouw toestemming. Elke staff-toegang wordt vastgelegd in de audit-keten en verschijnt onder de audit log van jouw tenant.

Is de audit log bestand tegen insider-tampering? De keten-hashing zorgt dat elke wijziging aan een rij elke volgende hash breekt, wat een export-en-verifieer-workflow detecteert. Het export-endpoint is ondertekend, zodat een downstream verifier onafhankelijk kan herchecken.

Kan ik een statisch IP krijgen voor uitgaande webhooks vanuit FixControl? Wordt momenteel niet aangeboden. Uitgaande webhooks dragen een HMAC-handtekening (X-FixControl-Signature), waarmee ontvangers de echtheid cryptografisch verifiëren in plaats van op bron-IP.