Beveiliging

Waar we op bouwen

De hele werking van een klein bedrijf draait op Stafeta, dus beveiliging is een principe, geen instelling: ons regelboek staat openbaar in de repository (SECURITY.md, docs/THREAT-MODEL.md) en elke wijziging volgt het. De lijst hieronder beschrijft wat er vandaag is – en apart wat nog niet.

Inloggen

• Inloggen in twee stappen voor iedereen, geen optie: een wachtwoord (of Google/Apple) en een code uit een authenticator-app. Geen sms-codes.
• Wachtwoorden: 12–128 tekens, gecontroleerd tegen lijsten met gelekte wachtwoorden, alleen opgeslagen als gezouten hash. Geen gedwongen wachtwoordwissel.
• Gevoelige handelingen (rollen, beleid, export, koppelingen, facturering, verwijdering) vragen een verse code ("step-up").
• Eenmalige herstelcodes; blokkering na 10 mislukte pogingen; botbescherming op de inlogpagina's.
• Sessies duren 7 dagen en verlopen na 24 uur inactiviteit; een login vanaf een nieuw apparaat stuurt een e-mail met een "dit was ik niet"-link.

Gegevens

• Database, bestanden en back-ups in de EU (Supabase, Frankfurt); de bestandsopslag is privé, met kortlevende ondertekende links.
• Rijniveau-beveiliging (RLS) per werkruimte op elke tabel, plus een regel die zonder de tweede stap niets vrijgeeft. Een automatische controle: geen tabel zonder RLS.
• Versleutelde verbindingen overal (HSTS); een content security policy (CSP) op elke pagina.
• Geheimen alleen op de server, elke 90 dagen geroteerd; de browser krijgt geen enkele sleutel. Een lekcontrole bij elke commit.

De grenzen van de AI

• De agent heeft geen verzend-, verwijder- of betaaltool. Hij stelt alleen voor; uitvoering is een aparte stap met goedkeuring van een mens, en de goedkeuring is gebonden aan de exacte inhoud.
• Binnenkomende inhoud (e-mail, berichten, transcripties) bereikt het model alleen als data; een instructie daarin is geen opdracht; een filter en een canary-geheim waken over manipulatie.
• Een run bevraagt met de rechten van de klant zelf en ziet nooit een ander bedrijf of een sleutel. Geen koppeling volgt omleidingen; we verbinden nooit met interne adressen.
• Een kostenrem: een budget per werkruimte, een waarschuwing bij 80%, een stop bij het plafond, een noodschakelaar.

Traceerbaarheid

Inloggebeurtenissen, goedkeuringen, een besluitenlogboek met afwijkende meningen, gastactiviteit op het portaal, kioskgebeurtenissen – alles gelogd en leesbaar voor de eigenaar. Een goedkeuring is gebonden aan de hash van de inhoud en eenmaal bruikbaar.

Controles

Een geautomatiseerde red-teamsuite draait bij elke wijziging (een prompt-injectiecorpus in drie talen, een gesimuleerd gekaapt model, SSRF-regels, scheiding van huurders). Pakketten komen alleen uit releases ouder dan 7 dagen.

Wat er nog niet is – eerlijk

• Nog geen externe penetratietest en geen onafhankelijke certificering (ISO 27001, SOC 2). geplande datum van de externe test.
• Envelopversleuteling van gevoelige velden (een sleutel per huurder) komt in de volgende fase.
• Geen serviceniveau-toezegging (SLA); de back-up-hersteloefening staat op de lanceringschecklist.

Een kwetsbaarheid melden

Vind je een beveiligingsprobleem, schrijf dan naar security@stafeta.ai – adres nog in te stellen (of hello@stafeta.ai). We antwoorden binnen 3 werkdagen, houden je op de hoogte van de oplossing en ondernemen geen stappen tegen onderzoek te goeder trouw. Vragen: open geen gegevens van anderen, doe geen denial-of-service-tests en gebruik geen social engineering. Een bug-bountyprogramma is er nog niet.

Ons incidentdraaiboek: de sleutel direct roteren, de getroffen werkruimte vergrendelen, de logs verzamelen, de klant en – bij persoonsgegevens – de toezichthouder binnen 72 uur informeren.