Säkerhet

Datalagring inom EU

All produktionsdata lagras hos Supabase (Postgres) i EU — konkret i Stockholm. Utgående e-post går genom avsändardomäner verifierade inom EU. Vi lagrar ingen kunddata hos tjänster utanför EU.

Applikationen körs på Vercel med exekveringsregionen låst till Stockholm (arn1) — samma ort som databasen. Det gäller API-anrop, serverrenderade sidor och det routinglager som förnyar inloggningssessionen. Ingen del av koden som behandlar personuppgifter körs alltså utanför EU.

Statiska filer — bilder, typsnitt, skript — levereras som vanligt från ett globalt innehållsnät, eftersom de är samma för alla och inte innehåller några uppgifter om er.

BankID-inloggning

Inloggning sker med svensk BankID. E-postinloggning finns kvar som ett permanent alternativ — alla ledamöter har inte svenskt personnummer, och den vägen får inte stängas.

Signering av protokoll

Protokoll signeras i dag genom att undertecknaren bekräftar signeringen i sin inloggade session. Identitetsbeviset är alltså den inloggning som redan är verifierad, och bekräftelsen registreras med undertecknare, roll och tidsstämpel. ABL 8:24 kräver att protokollet signeras av den som fört det och minst en justeringsman — den kontrollen görs i databasen, inte bara i gränssnittet.

Vi gör inte anspråk på att detta är en Avancerad Elektronisk Signatur (AES) under eIDAS. Signering med BankID, som är en AES, är nästa steg och är inte aktiverad i produktion ännu.

Oavsett metod hash-binds protokollets innehåll mot signaturen. Signaturen registreras bara om innehållets hash är exakt den som låstes när protokollet gick till signering — redigeras protokollet i efterhand måste det låsas upp, vilket nollar hashen och ogiltigförklarar de signaturer som fanns.

Extra verifiering vid känsliga åtgärder

Vissa åtgärder kräver mer än en giltig inloggning. För dem begär vi en färsk verifiering med säkerhetsnyckel eller enhetens egen biometri (WebAuthn), som gäller en kort stund och sedan förfaller. Det tydligaste exemplet: att läsa ut en aktieägares personnummer ur aktieboken kräver alltid ett sådant steg — en behörig roll räcker inte, och en session som legat öppen sedan i morse räcker inte heller.

PII-kryptering

Känsliga personuppgifter — i första hand personnummer i aktiebok och BankID-signaturbevis — krypteras innan de skrivs till databasen (Supabase/Postgres). Klartext finns aldrig i klientbundlar; dekryptering sker endast server-side när det krävs för en specifik förfrågan.

Hash-kedjad audit av aktiebok

Varje förändring i aktieboken — nyemission, överlåtelse, splittring, inlösen — skrivs som en oföränderlig post i en SHA-256-hash-kedja. Varje post länkar till hashen av föregående post, så att en revisor i efterhand kan verifiera att kedjan inte är manipulerad. Det här är vårt försvar mot ABL 5:7 (om styrelsens personliga ansvar för aktiebokens riktighet).

Tenant-isolering

Varje organisation isoleras via en tenant_id-kolumn i databasen (Postgres). Alla läsåtkomster passerar Row Level Security (RLS)-policyer som verifierar att den inloggade användaren har en aktiv medlemskap-roll i det specifika tenant. Skrivningar sker uteslutande via granskade databasfunktioner (RPC:er) som upprepar samma kontroll. Server-side kontroller i API-routes upprepar verifieringen ytterligare en gång — vi förlitar oss aldrig på client claims ensamma.

Behörighet på dokumentnivå

Tenant-isoleringen avgör vilket rum du når. Inom rummet styrs varje dokument dessutom av sin egen synlighet — internt, delat eller konfidentiellt — och ett konfidentiellt dokument kan dessutom begränsas till utpekade personer eller roller. Regeln tillämpas både i databasens läspolicy och i den funktion som skapar dokumentet, alltså i två oberoende lager. En revisor kan därmed få se det revisorn ska se utan att få se resten.

Extern åtkomst till datarum

Ett datarum kan delas med någon utanför organisationen — en rådgivare, en motpart i en affär — utan att den personen får ett konto. Länken innehåller en engångsnyckel som hashas direkt när den når servern; nyckeln i klartext hamnar aldrig i en databasfråga, en loggrad eller en aktivitetspost.

En ogiltig länk — okänd, utgången, återkallad, eller till ett rum som låsts — ger exakt samma neutrala svar som varje annat felutfall. Sidan avslöjar alltså aldrig om en viss nyckel har funnits. Varje visning och nedladdning loggas med tidsstämpel.

Granular audit-spårning

Varje mutation (skapa, ändra, ta bort) på dokument, möten, aktiebok, beslut och åtgärder loggas som en rad i databasens audit_logs, med aktör, tidsstämpel och vad som ändrades, skriven av samma databasfunktion som utför själva ändringen. Loggarna är tillgängliga för administratörer och revisorer med rätt roll.

Rate limiting och idempotens

Alla skriv-endpoints kräver en x-idempotency-key header — samma begäran kan göras om utan att skapa dubbletter. Varje autentiserad skrivning passerar dessutom en rate-limit per användare, och de anrop som kostar mest eller är känsligast har snävare egna gränser: AI-anrop, BankID, Stripe checkout och publika delningslänkar. Läsningar begränsas inte — de kan inte förändra något.

Säkerhetsfrågor

Hittar du ett säkerhetsproblem? Skriv till security@boardapp.ai. Vi svarar inom 48 timmar, även på helger.