# Säkerhet hos LightInventory

> Var dina data finns, vilken Google-åtkomst vi ber om, hur inloggning, roller och manipulationssäker historik fungerar och vilka leverantörer vi använder.

Source: https://www.lightinventory.com/sv/sakerhet · Last updated: 2026-10-30

Dina lagerdata stannar i ditt eget Google Kalkylark. LightInventory läser och skriver den filen åt dig, sparar ingen kopia av innehållet på våra servrar och lagrar bara det som behövs för att driva ditt konto. Den här sidan förklarar exakt hur det fungerar, vad vi skyddar mot och var gränserna går.

> **Note:** LightInventory är under utveckling och ännu inte allmänt tillgängligt. Den här sidan beskriver systemet som det är utformat. Den gör inga anspråk på granskningar, certifieringar eller en historik över drifttid, eftersom inget av det finns ännu.

## Var dina data finns

Affärsdata (artiklar, platser, lagerrörelser, priser, anteckningar, förslag som väntar på godkännande och värdena före och efter i din historik) finns enbart i kalkylark i ditt Google-konto. Våra servrar läser in cellvärden i minnet för att visa sidor, jämföra ändringar, skapa exporter och skriva dina uppdateringar. Värdena sparas inte i vår databas, våra loggar eller våra felrapporter. En automatiserad testsvit kontrollerar att ingen tabell, loggrad eller felhändelse innehåller cellvärden.

Vi lagrar de data som behövs för att driva ditt konto:

| Vad vi lagrar | Varför | Skydd |
|---|---|---|
| Användare, profiler, organisationer, medlemskap, roller, inbjudningar (bara en hash av varje inbjudningstoken) | Inloggning och teamhantering | Krypterat i vila av databasleverantören |
| Inloggningsfaktorer: publika nycklar för nyckelkoder, TOTP-hemligheter, hashade återställningskoder | Multifaktorautentisering | TOTP-hemligheter är dessutom kuvertkrypterade med nycklar i en tjänst för nyckelhantering |
| Google-uppdateringstoken för det anslutna kalkylarket | Läsa och skriva din fil | Kuvertkrypterad; skickas aldrig till webbläsaren och skrivs aldrig till loggar |
| Kalkylarkets metadata: fil-ID, flik-ID:n, schemaversion, låsläge | Hitta och kontrollera din fil | Innehåller inga cellvärden |
| Radfingeravtryck (nyckelbaserade hashvärden för varje rad) | Upptäcka ändringar som görs direkt i kalkylarket | Nyckelbaserade, så de kan inte omvandlas tillbaka till värdena |
| Hashkedja för granskning: sekvensnummer, post-ID:n, hashvärden, aktörs-ID, typ av åtgärd, tid | Bevisa att din historik är oförändrad | Innehåller inga värden |
| Faktureringsreferenser från vår betalningsleverantör | Prenumerationer och fakturor | Innehåller inga kortnummer |
| Säkerhetshändelser: inloggningsförsök, behörighetsfel, IP-adress, webbläsare | Upptäcka missbruk | IP-adressen tas bort efter 90 dagar, händelserna raderas efter 1 år |

Vårt eget system körs i **London**. Databasen (Supabase, region `eu-west-2`), applikationsservrarna (Vercel, region `lhr1`) samt våra krypteringsnycklar och historikförankringar (Google Cloud, region `europe-west2`) är alla låsta dit. Transaktionell e-post är det enda dokumenterade undantaget, som beskrivs under [infrastruktur och underbiträden](#infrastruktur-och-underbiträden).

## Den Google-åtkomst vi ber om

LightInventory ber Google om två saker. Vid inloggning med Google ber appen om din grundläggande profil: `openid`, `email` och `profile`. När du ansluter ett kalkylark ber den separat om en enda Drive-behörighet, `drive.file`.

Enkelt uttryckt låter `drive.file` en app arbeta enbart med de filer du skapar med den eller väljer åt den. Google beskriver det som åtkomst till filer ”that you open with an app or that the user shares with an app while using the Google Picker API” (filer som du öppnar med en app eller som användaren delar med appen via Google Picker API) ([Omfång för Google Drive API](https://developers.google.com/workspace/drive/api/guides/api-specific-auth?hl=sv)). Google klassar det som ett icke-känsligt omfång.

Vad det betyder för dig:

- LightInventory kan inte lista, öppna eller söka i resten av din Google Drive. En fil som du aldrig har skapat med LightInventory eller valt i Googles filväljare är osynlig för appen.
- Vi ber aldrig om det bredare omfånget `spreadsheets` eller något omfång för hela Drive.
- Efter varje medgivande kontrollerar vi att Google gav exakt den åtkomst vi bad om.
- Du kan när som helst ta bort åtkomsten från ditt Google-konto. Läs [Ta bort LightInventorys Google-åtkomst](/sv/hjalp/data-och-integritet/ta-bort-google-atkomst).

Bara personen som ansluter kalkylarket ger den här åtkomsten, och den personen måste äga filen. Dina teammedlemmar läggs aldrig till i filen hos Google. De arbetar via appen, med de roller du ger dem.

## Inloggning och sessioner

Varje användare loggar in med två faktorer, i alla planer, varje gång en session startar.

1. **Första faktorn:** inloggning med Google, eller e-post och lösenord. Lösenord måste ha minst 12 tecken och kontrolleras mot listor över läckta lösenord. Inloggning med Google räknas bara som första faktor, aldrig som båda.
2. **Andra faktorn:** en nyckelkod, som är standard och står emot nätfiske, eller en TOTP-kod från en autentiseringsapp. Varje användare registrerar minst två metoder och får 10 återställningskoder för engångsbruk.

För ägare och administratörer krävs nätfiskeresistent inloggning som standard, så TOTP är avstängt för de rollerna om inte ägaren ändrar inställningen. Hårdvarunycklar fungerar som nyckelkoder. En e-postlänk kan återställa ett lösenord, men den ersätter aldrig den andra faktorn.

Multifaktorautentiseringen kontrolleras på två oberoende ställen: i vår serverkod och i databasens egna åtkomstregler. En session som bara har klarat den första faktorn kan inte läsa någonting, inte ens om den anropar databasen direkt.

| Sessionsinställning | Värde |
|---|---|
| Utloggning efter inaktivitet | 60 minuter |
| Maximal sessionslängd | 24 timmar |
| Ny verifiering med andra faktorn för känsliga åtgärder | Inom de senaste 5 minuterna |
| Misslyckade försök med andra faktorn före spärr | 10, med fördröjningar från 30 sekunder till 1 timme |

Känsliga åtgärder omfattar rolländringar, faktureringsändringar, anslutning eller frånkoppling av ett kalkylark, exporter, massångring, ändringar av inloggningsmetoder och radering av organisationen. Du kan se dina aktiva sessioner och avsluta vilken som helst av dem. Vi mejlar dig när en ny enhet loggar in, när en inloggningsmetod läggs till eller tas bort och när återställningskoder används.

## Roller, platser och godkännanden

Varje organisation har fem roller: ägare, administratör, godkännare, redigerare och läsare. Redigerare och läsare kan begränsas till specifika platser, så att ett butiksteam bara ser och ändrar sitt eget lager.

| Behörighet | Ägare | Administratör | Godkännare | Redigerare | Läsare |
|---|---|---|---|---|---|
| Visa artiklar, lager och historik | Ja | Ja | Ja | Egna platser | Egna platser |
| Registrera lagerrörelser | Ja | Ja | Ja | Egna platser | Nej |
| Godkänna begäranden | Ja | Ja | Ja, inte sina egna | Nej | Nej |
| Massångring | Ja | Ja | Nej | Nej | Nej |
| Hantera medlemmar | Ja | Ja | Nej | Nej | Nej |
| Ansluta kalkylarket, radera organisationen | Ja | Nej | Nej | Nej | Nej |

Behörigheterna läses i realtid vid varje begäran, så om du tar bort någon eller ändrar personens roll gäller det vid personens nästa åtgärd. Varje begäran nekas om inte en regel tillåter den. Varje roll förklaras i [Team och roller](/sv/hjalp/team-och-roller).

Godkännanden är valfria. När de är aktiverade kan en organisation kräva godkännande för ändringar som prisändringar eller lagerjusteringar. Den föreslagna ändringen skrivs till en skyddad flik i ditt kalkylark, och ingen kan godkänna sin egen begäran. Läs mer i översikten över [ändringshistoriken](/sv/funktioner/andringshistorik).

## Historik där manipulation upptäcks

Varje ändring som görs via LightInventory skrivs som en historikpost i en skyddad `Log`-flik i ditt kalkylark, i samma uppdatering till Google som själva ändringen. Lagersaldot redigeras aldrig som en siffra. Det beräknas från en lista över lagerrörelser där rader bara läggs till, och att ångra en ändring innebär en ny, motsatt post i stället för en radering.

Att manipulation upptäcks betyder att verifieringen visar det om någon ändrar eller tar bort en tidigare post. Det betyder inte att ändringen är omöjlig. Så här fungerar det:

- **En nyckelbaserad kedja.** Varje post får en kod som beräknas från postens innehåll och föregående posts kod, med HMAC-SHA256 och en hemlig nyckel för din organisation som bara LightInventory har. Om en post ändras bryts kedjan från den punkten. Eftersom nyckeln är hemlig kan ingen i tysthet räkna om koderna efter en ändring.
- **En kopia av kedjan, utan värden.** Vi sparar kedjans koder, aldrig dina värden, i en databastabell som inte tillåter uppdateringar eller raderingar.
- **Dagliga förankringar utanför vår databas.** En gång om dagen skrivs ett enda fingeravtryck av varje organisations senaste position i kedjan till en Google Cloud Storage-bucket med en låst lagringspolicy på 7 år. När policyn väl är låst kan den inte förkortas eller tas bort. En angripare som kunde ändra vår databas skulle ändå inte kunna skriva om förankringarna.
- **Verifiering varje natt.** Varje natt, och närhelst ägaren begär det, räknar vi om kedjan från din `Log`-flik och jämför den med vår kopia och den senaste förankringen. Om något inte stämmer ser alla medlemmar en integritetsvarning, och ägaren och administratörerna får ett mejl.

Gränsen går vid ägarskapet. Ägaren till en Google-fil kan alltid redigera, låsa upp, kopiera eller radera den; Google tillåter inte att någon utesluts. Kedjan kan inte stoppa det, men den gör det synligt. Google registrerar också vår apps skrivningar under ägarens konto, eftersom vi skriver med ägarens behörighet. Vår `Log` registrerar den faktiska teammedlemmen.

## Ändringar gjorda direkt i kalkylarket

Som standard är dina hanterade flikar skyddade så att bara ägaren kan redigera dem i Google Kalkylark, och filens redigerare kan inte dela den vidare. Ett valfritt strikt lås gör filen skrivskyddad i Google tills ägaren medvetet låser upp den.

Eftersom ägaren alltid kan göra ändringar upptäcker LightInventory dem också. Varje gång appen läser ditt kalkylark jämför den varje rad med dess sparade fingeravtryck. En bakgrundskontroll körs också för organisationer som ingen tittar på. När en rad har ändrats utanför appen registrerar appen det med en så god tillskrivning som möjligt utifrån Googles versionsdata och tillämpar sedan organisationens policy: blockera ändringen tills en ägare eller administratör godtar eller återställer den, godta och logga den, eller vänta med den tills den godkänts. Ändringar av tidigare lagerrörelser eller historikposter flaggas alltid.

## Kryptering och hemligheter

- **Under överföring:** all trafik använder HTTPS. Webbläsare instrueras att bara använda HTTPS (HSTS med preload), och våra sidor använder en strikt Content Security Policy.
- **I vila:** vår databas krypteras i vila av sin leverantör. Ditt kalkylark lagras och krypteras av Google.
- **Token och nycklar:** Google-uppdateringstoken, TOTP-hemligheter och varje organisations historiknycklar krypteras med AES-256-GCM med en ny nyckel per post. Den nyckeln skyddas i sin tur av en huvudnyckel i Google Cloud KMS i London, som aldrig lämnar KMS och roteras varje år. KMS körs i ett separat molnprojekt med egna åtkomstkontroller, och våra servrar når det utan några sparade långlivade inloggningsuppgifter.
- **Ingen supportåtkomst till ditt kalkylark.** Det finns ingen funktion som låter vår personal logga in som du, och inget supportverktyg som öppnar ditt kalkylark. Åtkomst till vår produktionsdatabas kräver två personer och loggas.

## Infrastruktur och underbiträden

| Leverantör | Roll | Region |
|---|---|---|
| Supabase | Databas och autentisering (endast systemdata) | London (`eu-west-2`) |
| Vercel | Applikationshosting och brandvägg; nätverk för innehållsleverans (CDN) | Funktioner i London (`lhr1`); globalt CDN |
| Google Cloud | Nyckelhantering och historikförankringar (endast systemdata) | London (`europe-west2`) |
| Resend | Transaktionell e-post (inbjudningar, säkerhets- och faktureringsmeddelanden) | USA |
| Stripe | Fakturering och betalningar | Inte låst till en region |
| Cloudflare | DNS med DNSSEC, och CAPTCHA i inloggningsformulär | Globalt nätverk |

Googles API:er för Kalkylark och Drive behandlar ditt kalkylark som din egen leverantör. E-post vi skickar innehåller aldrig dina lagerdata. För leverantörer i USA omfattas överföringarna av EU-US Data Privacy Framework med det brittiska tillägget (UK Extension), eller av standardavtalsklausuler.

Vårt personuppgiftsbiträdesavtal är utformat för att ge kunder minst 30 dagars varsel om ett nytt underbiträde och rätt att invända. Den fullständiga listan över underbiträden och avtalet publiceras vid lanseringen.

## Rapportera en sårbarhet

Om du hittar ett säkerhetsproblem kan du mejla **support@lightinventory.com** med stegen för att återskapa det. Gå inte in i andras data och stör inte tjänsten, och kontakta oss innan du gör någon aktiv testning, eftersom våra villkor inte tillåter säkerhetstester utan tillstånd. Våra kontaktuppgifter för säkerhetsforskare finns också i maskinläsbar form i [security.txt](/.well-known/security.txt). En fullständig policy för ansvarsfullt avslöjande publiceras före lanseringen.

## Status

LightInventory förbereder lanseringen. Före lanseringen omfattar planen ett externt penetrationstest av inloggning, kundisolering, Google-auktorisering, webhooks och injektion i kalkylark, samt en fullständig självutvärdering mot OWASP Application Security Verification Standard 5.0. Den här sidan kompletteras med de oberoende bedömningarna när de finns. Fram till dess beskriver den utformning, inte certifiering.

Se [vad LightInventory lagrar](/sv/hjalp/data-och-integritet/vad-vi-lagrar) för den fullständiga listan och [priser](/sv/priser) för vad varje plan innehåller.
