Säkerhetsbeskrivning

Så skyddar Sverum era handlingar.

Öppet beskrivet: var data finns, vem som behandlar den, hur den krypteras och hur den förstörs. Det enda vi håller för oss själva är det som skulle hjälpa en angripare.

Version 1.3 · 26 oktober 2026 · Sverum AB

Sammanfattning

  • All data lagras i Sverige, hos BeeByte AB.
  • Varje projekt har en egen nyckel, och varje fil en egen. Filer, filnamn, mappnamn, kommentarer och var i filen en kommentar sitter krypteras.
  • Filer krypteras redan i webbläsaren och skrivs aldrig i klartext till disk.
  • Inga lösenord. Inloggning med organisationens konto, eller engångslänk med tvåfaktor för gäster.
  • Behörigheten kontrolleras vid varje anrop. Återkallad åtkomst stänger öppna dokument inom sekunder.
  • En kedjad loggbok visar vem som gjorde vad, och avslöjar om något ändras i efterhand.
  • När ett projekt stängs förstörs nyckeln och filerna blir oläsbara. Ni får ett intyg.

Var data lagras

All kunddata lagras i Sverige. Det gäller databasen, de krypterade filerna, loggboken och alla säkerhetskopior. Driften sker hos BeeByte AB i svenska datacenter.

Inga projektdata - filer, namn, kommentarer eller loggar - skickas till tjänster utanför Sverige. Sverum använder inga analysverktyg, spårare eller externa skript, varken i appen eller på webbplatsen.

E-post skickas genom BeeByte AB:s e-posttjänst i Sverige. Inbjudningar, engångslänkar, aviseringar och loggrapporter innehåller aldrig filinnehåll, filnamn eller kommentarer.

Underleverantörer

Leverantör Uppgift Plats
BeeByte AB Servrar, lagring, säkerhetskopior och e-post Sverige
Microsoft eller Google Inloggning, bara om er organisation väljer det. De tar emot inloggningen, inga projektdata. Enligt ert avtal med dem

Ändringar i listan meddelas kunderna minst 30 dagar i förväg, enligt personuppgiftsbiträdesavtalet.

Kryptering

Sverum använder modern, autentiserad kryptering med 256-bitars nycklar från etablerade och granskade bibliotek. Vi har ingen egen kryptografi.

Nycklar i flera nivåer

  • Varje projekt har en egen nyckel. Den krypterar filnamn, mappnamn, beskrivningar, kommentarer och kommentarernas platser i filerna.
  • Varje filversion har en egen nyckel, som i sin tur är skyddad av projektnyckeln.
  • Projektnycklarna är skyddade av en huvudnyckel som förvaras åtskild från databasen och filerna.

Varje krypterat värde är bundet till sitt sammanhang. En krypterad fil eller ett krypterat namn som flyttas till ett annat projekt, en annan fil eller en annan version går inte att läsa. Ändrade eller avkortade filer avvisas, och innehållets kontrollsumma stäms av vid varje läsning.

Det som inte krypteras med projektnyckeln

Projektets namn, deltagarnas namn och e-postadresser och loggboken krypteras inte med projektnyckeln. De behövs för åtkomstkontroll, loggrapporter och intyget även efter att projektet har stängts. De lagras som all annan data i Sverige och skyddas av behörighetskontroll och krypterade säkerhetskopior. Skriv därför inga hemligheter i projektets namn.

Inte från ände till ände. Servern behöver läsa en fil i arbetsminnet för att visa den, vattenmärka den och kontrollera filtypen. Därför är krypteringen serverbaserad. Klartext skrivs aldrig till disk, och nycklar finns i klartext bara i minnet under en operation och skrivs sedan över.

Nyckelhantering

  • Huvudnyckeln förvaras åtskild från databasen och filerna, och ingår aldrig i samma säkerhetskopia som dem.
  • Huvudnyckeln roteras varje månad. Den gamla nyckeln förvaras krypterad och offline i högst 30 dagar och förstörs sedan.
  • Projektnyckeln kan roteras. Filnycklar, namn, kommentarer och deras platser slås då in på nytt.
  • En automatisk kontroll larmar om en rotation uteblir eller om en gammal nyckel inte förstörts i tid.

Uppladdning

  • Webbläsaren krypterar filen i delar innan den skickas, med en nyckel som är unik för uppladdningen och aldrig skickas över nätet. Även de temporära filer som webbservern skriver innehåller bara krypterad data.
  • Varje del kontrolleras. En del som ändrats, skickats två gånger eller hamnat i fel ordning avvisas.
  • Filtypen avgörs av innehållet, inte av filändelsen. Bara godkända typer tas emot.
  • Behörigheten kontrolleras vid varje del. Ofullständiga uppladdningar raderas efter ett dygn.

Överföring och webbläsare

  • Bara HTTPS med TLS 1.2 eller senare, och HSTS.
  • En strikt Content Security Policy: skript körs bara med en engångsnyckel per anrop, och inga resurser hämtas från andra domäner. Inga CDN:er.
  • Sessionskakor är Secure, HttpOnly och SameSite=Lax, och sessionens innehåll är krypterat.
  • Sverum kan inte bäddas in i andra webbplatser. Filinnehåll skickas med rubriker som förbjuder cachning och isolerar innehållet.

Inloggning och sessioner

  • Inga lösenord. Organisationer loggar in med Microsoft Entra ID, Google eller annan OpenID Connect-leverantör. Era egna regler för tvåfaktor och konton gäller.
  • Gäster utan sådant konto loggar in med en engångslänk som gäller i 10 minuter och är bunden till webbläsaren, plus en tvåfaktorskod (TOTP).
  • Sessioner löper ut efter 15 minuters inaktivitet och senast efter 10 timmar.
  • Känsliga åtgärder kräver ny inloggning, giltig i 5 minuter. Det gäller till exempel att stänga ett projekt, ändra klassning eller nedladdningspolicy, ändra någons roll, ta bort någon ur organisationen och exportera loggar.

Åtkomst och återkallning

  • Need-to-know. Åtkomst ges per projekt, med roll (ägare, redigerare, läsare, extern), valfri begränsning till mappar och valfritt slutdatum. Organisationens ägare läser inte automatiskt allt.
  • Externa är läsare som standard. Inbjudan är bunden till e-postadressen, gäller i 72 timmar och kan användas en gång. En sekretessförbindelse godkänns före första åtkomst och bekräftas med en engångskod som skickas till den inbjudna adressen. Koden gäller i 10 minuter och spärras efter fem felaktiga försök.
  • Kollegor bjuds in till organisationen per e-post med en roll, med samma skydd. Kontot skapas först när inbjudan accepteras, efter inloggning med organisationens egen inloggning för just den adressen. Bara ägare kan ge ägar-, administratörs- eller säkerhetsansvarig-roll, ingen kan höja sin egen roll och organisationen har alltid en ägare.
  • Beställaren kan kräva att nya underkonsulter godkänns innan de får åtkomst.
  • Varje anrop kontrolleras mot databasen, utan cachning. Visaren hämtar innehåll med en kortlivad, signerad nyckel som bara förnyas så länge behörigheten finns kvar.
  • Återkallning når öppna webbläsare direkt och stänger dokumentet inom sekunder, och senast inom en minut. Ett avstängt konto loggas ut på alla enheter.

Visning och nedladdning

  • Dokument visas i webbläsaren med ett vattenmärke: läsarens namn, e-post, IP-adress och tid.
  • Nedladdning är avstängd som standard. Den kan slås på per projekt och roll, och en fil kan bara skärpa projektets val.
  • Nedladdade PDF-filer vattenmärks på varje sida med ett unikt id, så att en läckt kopia kan spåras till sin nedladdning.
  • Uppladdade filer behandlas som opålitliga. Läsningen har gränser för tid, minne och komplexitet, och en fil som inte klarar dem nekas.

Spärrar mot utskrift, kopiering och högerklick är avskräckning, inte skydd. Det som visas på en skärm kan alltid fotograferas. Därför bygger skyddet på behörighetskontroll på servern, och spårbarheten på vattenmärke och loggbok.

Loggbok

  • Loggboken registrerar inloggningar, inbjudningar, öppningar, lästa sidor, aktiv lästid, nedladdningar, ändringar av behörighet och alla nyckelhändelser.
  • Varje händelse länkas kryptografiskt till den föregående. Kedjan verifieras varje timme, och dess senaste länk förankras varje timme utanför databasen och skickas till organisationens säkerhetsansvariga.
  • Appen kan inte ändra eller radera händelser. En ändring i efterhand bryter kedjan och upptäcks.
  • Loggen innehåller aldrig filnamn, kommentarstext eller var i en fil en kommentar sitter. Filer anges med nummer.
  • Beställaren ser en åtkomstlogg för sina projekt, men inte den detaljerade lässpårningen.
  • Loggboken sparas så länge projektet finns, även efter att det har stängts.

Avslut och destruktion

Bara projektets ägare eller organisationens ägare kan stänga ett projekt, efter ny inloggning och genom att skriva projektets namn.

  • Alla versioner av projektnyckeln förstörs, och filerna raderas.
  • Utan nyckeln går varken filer, namn, kommentarer eller deras platser att dekryptera. Även kontrollsummorna tas bort, så att ingen i efterhand kan bekräfta att en viss fil fanns.
  • Ett intyg skrivs i loggboken: tid, vem som stängde, antal filer och versioner, förstörda nycklar och en kontrollsumma över filförteckningen.
  • I säkerhetskopior från tiden före stängningen blir filerna oläsbara när den huvudnyckel som gällde då har förstörts, senast 60 dagar efter stängningen.

Säkerhetskopior

  • Varje dygn tas en säkerhetskopia av databasen och de krypterade filerna.
  • Kopian skyddas med ett eget lösenord och lagras hos BeeByte AB i Sverige, åtskild från driftservern.
  • Huvudnyckeln ingår aldrig i kopian. En säkerhetskopia som hamnar i fel händer innehåller bara krypterad data.
  • Säkerhetskopior sparas i högst 30 dagar och gallras sedan.
  • Varje månad provåterställs den senaste kopian: databasen läses in och loggbokens kedjor verifieras mot förankringarna. Resultatet sparas som protokoll.

Planerat

  • En daglig kontroll som larmar om den senaste kopian är för gammal eller saknas.
  • Automatisk provåterställning i en isolerad miljö.

Utveckling och granskning

  • Inga riktiga kunddata används i utveckling, test eller AI-verktyg, bara syntetiska testdata.
  • Kryptering, behörighet och loggbok täcks av automatiska tester, bland annat för fel nyckel, fel sammanhang, manipulerade och avkortade filer och återkallad åtkomst.
  • Beroenden hålls uppdaterade, och säkerhetsuppdateringar installeras skyndsamt.
  • Statisk kodanalys på högsta nivån, sårbarhetsskanning av beroenden och hela testsviten körs vid varje ändring.
  • Kontrollerna mäts mot ISO/IEC 27001:2022 bilaga A och Säkerhetspolisens vägledningar för informationssäkerhet. Det är en måttstock, inte en certifiering.

Planerat

  • Extern granskning av kryptografin och ett penetrationstest.
  • Två granskare för all kod som rör kryptering, behörighet och loggbok.
  • Huvudnyckeln i en dedikerad nyckeltjänst.

Personuppgifter

Ni är personuppgiftsansvariga för uppgifterna i era projekt, och Sverum AB är personuppgiftsbiträde. Personuppgiftsbiträdesavtalet ingår i avtalet om tjänsten och beskriver behandlingen, säkerhetsåtgärderna och underbiträdena.

Lässpårning är behandling av personuppgifter om hur människor arbetar. Visaren visar alltid att läsningen loggas. Bedömningen av berättigat intresse görs av er som ansvariga, och vi hjälper gärna till med underlag.

Rapportera en sårbarhet

Har ni hittat en sårbarhet? Skriv till security@sverum.se. Beskriv gärna hur felet kan återskapas, och vänta med att publicera tills det är åtgärdat. Testa inte mot andra kunders data.

Kontaktuppgifterna finns också i security.txt.

Fler frågor om säkerheten?

Vi går gärna igenom era krav, er upphandling eller er informationsklassning.