Beveiligingsbeleid

1. Aanpak

VERA kan namens jou berichten plaatsen, versturen en geld uitgeven, dus de belangrijkste beveiligingseigenschap is niet cryptografisch: het is dat VERA niet zonder jou handelt. Externe acties worden vastgelegd als voorstellen en pas uitgevoerd nadat jij ze hebt goedgekeurd, of volgens een automatiseringsregel die je zelf hebt ingesteld. De goedkeuringsstap wordt afgedwongen in het codepad dat acties uitvoert en staat niet alleen in het beleid.

Het tweede principe: inloggegevens zijn de kroonjuwelen. VERA bewaart tokens voor platforms die geld kunnen overmaken, naar een publiek kunnen publiceren en de accounts van een bedrijf kunnen inzien. Die worden versleuteld met een sleutel die los staat van al het andere, en worden nooit teruggetoond in de interface of weggeschreven naar logbestanden.

2. Wat er is geregeld

Al het onderstaande is vandaag al in het product geïmplementeerd.

• Versleuteling tijdens overdracht. Al het verkeer verloopt via HTTPS. In productie worden gewone HTTP-verzoeken aan de edge permanent omgeleid naar HTTPS, en wordt HTTP Strict Transport Security ingesteld met een max-age van twee jaar, includeSubDomains en preload.
• Versleuteling van opgeslagen geheimen. Inloggegevens van connectoren en API-sleutels worden versleuteld met AES-256-GCM, een geauthenticeerd versleutelingsalgoritme, zodat een gemanipuleerde versleutelde tekst niet wordt ontsleuteld in plaats van gewijzigde gegevens op te leveren. De sleutel is een aparte waarde waarvan de validatie bij het opstarten in productie vereist dat die aanwezig, uniek en voldoende lang is.
• Wachtwoordbeveiliging. Wachtwoorden worden gehasht met bcrypt met een work factor van 12 en worden nooit in leesbare vorm opgeslagen of gelogd. Er geldt een minimale lengte. E-mailverificatie is vereist voordat een account met wachtwoord kan inloggen.
• Sessiebeheer. Sessies zijn ondertekende JSON Web Tokens met een intrekkingsteller die bij elk geauthenticeerd verzoek wordt gecontroleerd aan de hand van de database. Door die teller te verhogen worden alle uitgegeven sessies in één keer ongeldig. Daardoor zorgen het resetten van een wachtwoord, „afmelden op alle apparaten” en het opschorten van een account er daadwerkelijk voor dat actieve sessies worden beëindigd, in plaats van alleen nieuwe sessies te voorkomen.
• Wachtwoordherstel en verificatie. Resetlinks zijn eenmalig te gebruiken, verlopen na 1 uur, worden beperkt door een wachttijd tussen verzendingen en trekken bij gebruik alle sessies in. Verificatielinks verlopen na 24 uur. Een resetverzoek verraadt nooit of er een account bestaat.
• Snelheidsbeperking. Inloggen, registreren, wachtwoordherstel en AI-acties zijn onderworpen aan rate limiting met duurzame fixed-window-tellers die in de database worden bewaard, zodat limieten blijven gelden na het herstarten van processen en over alle instanties heen van toepassing zijn in plaats van alleen binnen één instantie.
• Tenantisolatie. Elke query is beperkt tot het geauthenticeerde account. Een mislukte eigendomscontrole wordt zelf ook als beveiligingsgebeurtenis vastgelegd.
• Teamrollen en gebruikersplekken. Een zakelijk account kan meerdere personen bevatten. Elk lid wordt uitgenodigd door de accounthouder, accepteert met eigen inloggegevens in plaats van een gedeelde login en krijgt een rol toegewezen waarvan de rechten op de server worden gecontroleerd, niet alleen in de interface worden weergegeven. Leden kunnen worden gedeactiveerd, waardoor hun toegang wordt afgesloten terwijl hun naam behouden blijft op de records die zij hebben ingediend. Inzendingen van medewerkers, zoals uitgaven en kilometers, worden toegeschreven aan het account dat ze heeft verstuurd.
• Administratief toegangsbeheer. De interne beheerconsole is alleen toegankelijk voor een expliciete lijst van toegestane operators die in de omgeving is geconfigureerd. Elke handeling van een operator wordt vastgelegd in een administratief auditlogboek waaraan alleen kan worden toegevoegd, met daarin wie wat deed bij welk account.
• Audittrail. Elk voorstel, elke goedkeuring, wijziging, afwijzing, uitvoering en mislukking wordt vastgelegd in een auditlog per account waaraan alleen kan worden toegevoegd, samen met beveiligingsgebeurtenissen zoals wachtwoordwijzigingen, ingetrokken sessies, opschortingen en vernieuwde offertelinks. Geheimen, tokens en wachtwoordhashes zijn bewust uitgesloten.
• HTTP-beveiligingsheaders. Een Content Security Policy die scripts, stijlen, frames en formulierdoelen beperkt; X-Frame-Options DENY en frame-ancestors none tegen clickjacking; X-Content-Type-Options nosniff; een referrerbeleid strict-origin-when-cross-origin; en een Permissions-Policy ingesteld op camera=(), microphone=(self), geolocation=(self). Microfoon en locatie zijn alleen toegestaan voor VERA's eigen pagina's, nooit voor een ingesloten derde partij, en werken pas nadat je de browser toestemming geeft voor de functie die erom vraagt.
• Integriteit van webhooks. Inkomende webhooks worden vóór verwerking gecontroleerd aan de hand van het ondertekeningsschema van elke provider, waaronder Stripe-handtekeningen, de HMAC-header van Meta, de HMAC van Jobber, de handtekeningsleutel van Square en het speciale verificatietoken van QuickBooks. Leveringen worden ontdubbeld op event-id, zodat een herhaalde levering een effect niet twee keer kan toepassen.
• Bescherming tegen server-side request forgery. Wanneer het product een URL ophaalt die jij opgeeft, zoals een winkeldomein of een website om te analyseren, wordt het adres gevalideerd op schema en poort en door elk IP-adres waarnaar het verwijst op te zoeken, waarbij loopback-, privé-, link-local-, carrier-grade NAT- en cloudmetadatabereiken worden geweigerd. Redirects worden zo afgehandeld dat een openbare host een verzoek niet kan doorsturen naar een interne host.
• Beveiliging van openbare links. Links naar offertes voor klanten gebruiken 256 bits cryptografisch veilige willekeur. Eigenaren kunnen een link opnieuw genereren, waardoor de oude link direct ongeldig wordt en er een onomkeerbare vingerafdruk van wordt vastgelegd voor audit. Mislukte tokenopzoekingen worden afgeremd, zodat het endpoint niet systematisch kan worden afgezocht, en tokens worden gemaskeerd overal waar ze anders in logs of beheerweergaven zouden verschijnen.
• Integratierechten volgens het principe van minimale rechten. Integraties vragen alleen de machtigingen (scopes) aan die hun functies nodig hebben, en een aantal is bewust alleen-lezen, waaronder QuickBooks Online en Jobber. Factuuranalyses gebruiken een afzonderlijke, beperkte alleen-lezen sleutel van de betaalprovider, zodat een analyseweergave de factureringsstatus nooit kan wijzigen.
• Isolatie van betaalgegevens. Kaartnummers bereiken VERA nooit. De betaling wordt geïnd via de gehoste checkout van Stripe en beheerd via het betalingsportaal van Stripe, zodat de systemen van VERA geen deel uitmaken van het pad van kaarthoudergegevens.
• Standaard veilig geconfigureerd. De opstartvalidatie weigert in productie te draaien met het sessiegeheim voor ontwikkeling, zonder sessiegeheim of zonder een speciale encryptiesleutel voor geheimen, en waarschuwt voor half geconfigureerde integraties die ongemerkt zouden mislukken.
• Dagelijkse versleutelde back-ups. Van de productiedatabase wordt één keer per dag een dump gemaakt, die met AES256 wordt versleuteld voordat hij de machine verlaat waarop hij is gemaakt, en apart van de databaseprovider wordt opgeslagen. Elke run zet de zojuist gemaakte versleutelde kopie vervolgens terug in een tijdelijke database en mislukt als dat terugzetten mislukt of een lege database oplevert, zodat een back-up pas meetelt zodra die is teruggezet. Back-ups worden 30 dagen bewaard en het point-in-time herstel van de databaseprovider zelf dekt de uren daartussen.
• Opschorting van het account. Een gecompromitteerd of misbruikt account kan worden opgeschort. Daarmee wordt elk geauthenticeerd toegangspunt geweigerd en worden actieve sessies ingetrokken, zonder dat er gegevens worden verwijderd en zonder dat dit onomkeerbaar is.

3. Wat er nog niet is geregeld

Dit zijn maatregelen waar een beveiligingsbeoordelaar redelijkerwijs naar zou vragen. VERA heeft ze momenteel niet. We noemen ze, in plaats van een lezer uit de bovenstaande sectie te laten afleiden dat ze aanwezig zijn.

• Geen certificeringen. VERA heeft geen SOC 2 Type I- of Type II-audit doorlopen, is niet ISO 27001-gecertificeerd, heeft geen HIPAA-programma voor business associates en is zelf niet beoordeeld op PCI DSS. De verwerking van betaalkaarten is volledig uitbesteed aan Stripe.
• Geen multifactorauthenticatie. VERA biedt momenteel geen tweefactorauthenticatie, authenticator-apps, hardwaresleutels of passkeys. Als je inlogt met Google, profiteer je van de meervoudige verificatie die je op je Google-account hebt ingesteld; dat is op dit moment de sterkste beschikbare optie.
• Geen single sign-on. Er is geen SAML- of OIDC-enterprise-SSO en geen SCIM-provisioning.
• Geen gebruikersbeheer via een directory. Teamleden worden binnen VERA uitgenodigd en beheerd. Er is geen automatische provisioning of deprovisioning vanuit een identiteitsprovider, dus als je iemand uit je eigen directory verwijdert, verliest die persoon daarmee niet de toegang tot VERA. Je moet diegene ook in VERA deactiveren.
• Geen onafhankelijke penetratietest of bugbountyprogramma. VERA heeft geen penetratietest door een derde partij laten uitvoeren en heeft geen betaald bugbountyprogramma.
• Geen door de klant beheerde encryptiesleutels. Encryptiesleutels worden beheerd door VERA. Een eigen sleutel meebrengen (bring-your-own-key) is niet mogelijk.
• Geen keuze voor de locatie van gegevensopslag. Gegevens worden verwerkt in de Verenigde Staten. Er is geen optie voor hosting in de EU of in een andere regio.
• Geen back-uparchief voor de lange termijn. Dagelijkse back-ups worden 30 dagen bewaard. Er is geen maandelijks of jaarlijks archief, geen derde kopie op een externe locatie en geen herstel van een afzonderlijk account vanuit een back-up: bij een herstel wordt de volledige database teruggezet, dus het is een reactie op een incident en geen herstelservice voor klanten.
• Geen 24/7 beveiligingsbewaking. Er is geen dag en nacht bemand security operations center, geen formeel bereikbaarheidsrooster dat aan klanten wordt gepubliceerd en geen inbraakdetectieproduct naast de hierboven genoemde maatregelen op applicatieniveau.
• Geen uptimegarantie. VERA biedt geen service level agreement. Zie de Gebruiksvoorwaarden.

4. Infrastructuur

VERA draait als een gecontaineriseerde Next.js-applicatie op Node.js, uitgerold vanuit een multi-stage build die een zelfstandige runtime-image oplevert, met een beheerde PostgreSQL-database. Er is een health-endpoint beschikbaar voor platformmonitoring.

Geüploade foto's, gegenereerde afbeeldingen en geïmporteerde documenten worden als gecodeerde gegevens opgeslagen in de applicatiedatabase en niet in een aparte objectopslagdienst. Er is dus geen afzonderlijk geconfigureerde bucket die per ongeluk openbaar leesbaar kan blijven, en het betekent ook dat de bestandsopslag dezelfde versleuteling in rust krijgt die de databaseprovider toepast.

Hosting, beveiliging op netwerkniveau en fysieke beveiliging worden geleverd door de platformaanbieders die op de Lijst van subverwerkers staan, onder hun eigen beveiligingsprogramma's. VERA beheert geen eigen datacenters.

5. Monitoring en incidentrespons

Applicatie- en foutlogging draait in productie, en de interne operationsconsole toont de systeemstatus, de status van achtergrondtaken, mislukte integraties en een beveiligingspaneel dat onder meer de achterstand rapporteert van offertelinks die nog een verouderd tokenformaat gebruiken.

Als we op de hoogte raken van een beveiligingsincident dat klantgegevens raakt, onderzoeken we het, beperken we het en beoordelen we welke gegevens erbij betrokken waren. Voor persoonsgegevens die namens een zakelijke klant worden verwerkt, informeert VERA de getroffen klant zonder onnodige vertraging en binnen 72 uur nadat we ervan op de hoogte zijn geraakt, zoals vereist door de Verwerkersovereenkomst. Meldingen aan toezichthouders en aan betrokkenen zijn de verantwoordelijkheid van de verwerkingsverantwoordelijke, en wij bieden daarbij ondersteuning.

VERA publiceert momenteel geen statuspagina of openbare incidentgeschiedenis.

6. Een kwetsbaarheid melden

Meld beveiligingsproblemen via support@meetmyvera.com met als onderwerpregel “Security report”. Geef voldoende details om het probleem te reproduceren: de betrokken URL of functie, de stappen en de impact die het volgens jou heeft. Versleutelde correspondentie is welkom; vraag erom en we regelen het.

We streven ernaar een melding binnen 3 werkdagen te bevestigen en binnen 10 werkdagen een beoordeling te geven. We houden je op de hoogte terwijl we aan een oplossing werken en laten je weten wanneer die live gaat. Als je dat wilt, vermelden we je graag publiekelijk.

7. Verantwoorde openbaarmaking en vrijwaring

Als je te goeder trouw en binnen de onderstaande grenzen onderzoek doet naar de beveiliging van VERA, ondernemen we geen juridische stappen tegen je en beschouwen we je onderzoek als geautoriseerd onder de toepasselijke wetgeving inzake computercriminaliteit. We vragen je om:

• Test alleen je eigen account. Gebruik een account dat je zelf hebt aangemaakt. Bekijk, wijzig of bewaar geen gegevens van een andere klant. Kom je per ongeluk gegevens van iemand anders tegen, stop dan, sla ze niet op en laat ons weten wat er is gebeurd.
• Voorkom schade. Geen denial of service, geen load- of stresstests, geen spam, geen social engineering van onze medewerkers of klanten en geen fysieke aanvallen.
• Gebruik geen geautomatiseerde scanners op grote schaal. Agressief geautomatiseerd scannen is niet te onderscheiden van een aanval en leidt ertoe dat je wordt afgeremd of geblokkeerd.
• Geef ons tijd. Meld het probleem vertrouwelijk en geef ons een redelijke termijn om het op te lossen voordat je het openbaar maakt. Standaard gaan we uit van 90 dagen; meestal zijn we veel sneller, en we laten het je weten als iets meer tijd nodig heeft.
• Geen afpersing. Details achterhouden totdat er betaald wordt, is geen beveiligingsmelding. VERA heeft geen betaald bountyprogramma en kan geen beloning bieden.

8. Jouw deel

Gebruik een sterk, uniek wachtwoord en kies bij voorkeur voor inloggen met Google als je Google-account meervoudige authenticatie heeft ingeschakeld, omdat VERA die zelf nog niet aanbiedt.

Deel je inloggegevens niet. Geef iedereen die VERA nodig heeft een eigen geautoriseerd account door diegene uit te nodigen en een rol toe te wijzen, in plaats van een login uit te delen: de gedeelde login van een accounthouder geeft volledige toegang, inclusief facturatie en elk gekoppeld platform, en zorgt ervoor dat uit het activiteitenlogboek niet meer blijkt wie iets daadwerkelijk heeft gedaan. Deactiveer een lid zodra die geen toegang meer nodig heeft.

Geef integraties alleen toegang waar je de functie nodig hebt, en ontkoppel de integraties die je niet meer gebruikt. Genereer een nieuwe offertelink als die is doorgestuurd naar een plek die je niet bedoelde. Bekijk je audittrail als er iets niet klopt, en laat het ons weten via support@meetmyvera.com als je ongeautoriseerde toegang vermoedt.