Oversatt med KI fra den engelske versjonen datert 30. oktober 2026. Les originalen
Sikkerhet i LightInventory
Hvor dataene dine ligger, hvilken Google-tilgang vi ber om, hvordan innlogging, roller og historikk som avslører manipulering, fungerer, og hvilke leverandører vi bruker.
Sist oppdatert 30. oktober 2026
Lagerdataene dine blir i ditt eget regneark i Google Regneark. LightInventory leser og skriver den filen på dine vegne, beholder ingen kopi av innholdet på serverne våre og lagrer bare det som trengs for å drive kontoen din. Denne siden forklarer nøyaktig hvordan det fungerer, hva vi beskytter mot, og hvor grensene går.
Hvor dataene dine ligger
Forretningsdata (varer, plasseringer, lagerbevegelser, priser, notater, forslag til godkjenning og verdiene før og etter i historikken din) ligger bare i regneark i Google-kontoen din. Serverne våre leser celleverdier inn i minnet for å vise sider, sammenligne endringer, lage eksporter og skrive oppdateringene dine. Disse verdiene lagres ikke i databasen vår, i loggene våre eller i feilrapportene våre. En automatisert testpakke kontrollerer at ingen tabell, loggrad eller feilhendelse inneholder celleverdier.
Vi lagrer de dataene som trengs for å drive kontoen din:
| Hva vi lagrer | Hvorfor | Beskyttelse |
|---|---|---|
| Brukere, profiler, organisasjoner, medlemskap, roller, invitasjoner (bare en hash av hvert invitasjonstoken) | Innlogging og teamadministrasjon | Kryptert ved lagring av databaseleverandøren |
| Innloggingsfaktorer: offentlige nøkler for passnøkler, TOTP-hemmeligheter, hashede gjenopprettingskoder | Autentisering med flere faktorer | TOTP-hemmeligheter er i tillegg konvoluttkryptert med nøkler som oppbevares i en nøkkeladministrasjonstjeneste |
| Google-oppdateringstoken for det tilkoblede regnearket | Lese og skrive filen din | Konvoluttkryptert; sendes aldri til nettleseren og skrives aldri til logger |
| Metadata om regnearket: fil-ID, fane-ID-er, skjemaversjon, låsemodus | Finne og kontrollere filen din | Inneholder ingen celleverdier |
| Radfingeravtrykk (hasher med nøkkel av hver rad) | Oppdage endringer gjort direkte i regnearket | Med nøkkel, så de kan ikke regnes tilbake til verdiene |
| Hashkjede for revisjon: sekvensnumre, oppførings-ID-er, hasher, aktør-ID, handlingstype, tidspunkt | Bevise at historikken din er uendret | Inneholder ingen verdier |
| Faktureringsreferanser fra betalingsleverandøren vår | Abonnementer og fakturaer | Inneholder ingen kortnumre |
| Sikkerhetshendelser: innloggingsforsøk, avviste tilganger, IP-adresse, nettleser | Oppdage misbruk | IP-adressen fjernes etter 90 dager, hendelser slettes etter 1 år |
Vårt eget system kjører i London. Databasen (Supabase, region eu-west-2), applikasjonsserverne (Vercel, region lhr1) og krypteringsnøklene og forankringene av historikken (Google Cloud, region europe-west2) er alle låst dit. Transaksjonell e-post er det ene dokumenterte unntaket, beskrevet under infrastruktur og underdatabehandlere.
Google-tilgangen vi ber om
LightInventory ber Google om to ting. Når du logger inn med Google, ber appen om den grunnleggende profilen din: openid, email og profile. Når du kobler til et regneark, ber den separat om én tillatelse i Disk: drive.file.
Enkelt sagt lar drive.file en app bare arbeide med filene du oppretter med den eller velger for den. Google beskriver det som tilgang til filer «som du åpner med en app, eller som brukeren deler med en app mens Google Picker API brukes» (Google Drive API scopes). Google klassifiserer det som et ikke-sensitivt omfang.
Hva det betyr for deg:
- LightInventory kan ikke liste opp, åpne eller søke i resten av Google Disk-en din. En fil du aldri har opprettet med LightInventory eller valgt i Googles filvelger, er usynlig for appen.
- Vi ber aldri om det bredere omfanget
spreadsheetseller noe omfang for hele Disk. - Etter hver tillatelse kontrollerer vi at Google ga nøyaktig den tilgangen vi ba om.
- Du kan når som helst fjerne tilgangen fra Google-kontoen din. Se Fjern LightInventorys tilgang til Google.
Bare personen som kobler til regnearket, gir denne tilgangen, og den personen må eie filen. Teammedlemmene dine legges aldri til i filen hos Google. De jobber via appen, med rollene du gir dem.
Innlogging og økter
Alle brukere logger inn med to faktorer, i alle planer, hver gang en økt starter.
- Første faktor: innlogging med Google, eller e-post og passord. Passord må ha minst 12 tegn og kontrolleres mot lister over lekkede passord. Innlogging med Google teller bare som første faktor, aldri som begge.
- Andre faktor: en passnøkkel, som er standard og motstår phishing, eller en TOTP-kode fra en autentiseringsapp. Hver bruker registrerer minst to metoder og får 10 gjenopprettingskoder til engangsbruk.
For eiere og administratorer kreves phishing-sikker innlogging som standard, så TOTP er slått av for disse rollene med mindre eieren endrer innstillingen. Fysiske sikkerhetsnøkler fungerer som passnøkler. En e-postlenke kan tilbakestille et passord, men den erstatter aldri den andre faktoren.
Autentisering med flere faktorer kontrolleres to uavhengige steder: i serverkoden vår og i databasens egne tilgangsregler. En økt som bare har bestått første faktor, kan ikke lese noe, selv om den kaller databasen direkte.
| Øktinnstilling | Verdi |
|---|---|
| Utlogging etter inaktivitet | 60 minutter |
| Maksimal øktlengde | 24 timer |
| Ny andre faktor for sensitive handlinger | I løpet av de siste 5 minuttene |
| Mislykkede forsøk med andre faktor før sperring | 10, med forsinkelser fra 30 sekunder til 1 time |
Sensitive handlinger omfatter rolleendringer, endringer i fakturering, tilkobling eller frakobling av et regneark, eksport, massetilbakestillinger, endringer i innloggingsmetoder og sletting av organisasjonen. Du kan se de aktive øktene dine og avslutte hvilken som helst av dem. Vi sender deg en e-post når en ny enhet logger inn, når en innloggingsmetode legges til eller fjernes, og når gjenopprettingskoder brukes.
Roller, plasseringer og godkjenninger
Hver organisasjon har fem roller: eier, administrator, godkjenner, redigerer og leser. Redigerere og lesere kan begrenses til bestemte plasseringer, slik at et butikkteam bare ser og endrer sin egen beholdning.
| Funksjon | Eier | Administrator | Godkjenner | Redigerer | Leser |
|---|---|---|---|---|---|
| Se varer, beholdning og historikk | Ja | Ja | Ja | Egne plasseringer | Egne plasseringer |
| Registrere bevegelser | Ja | Ja | Ja | Egne plasseringer | Nei |
| Godkjenne forespørsler | Ja | Ja | Ja, ikke sine egne | Nei | Nei |
| Massetilbakestilling | Ja | Ja | Nei | Nei | Nei |
| Administrere medlemmer | Ja | Ja | Nei | Nei | Nei |
| Koble til regnearket, slette organisasjonen | Ja | Nei | Nei | Nei | Nei |
Tillatelser leses direkte ved hver forespørsel, så når noen fjernes eller får endret rolle, gjelder det fra deres neste handling. Hver forespørsel avvises med mindre en regel tillater den. Hver rolle er forklart under Team og roller.
Godkjenninger er valgfrie. Når de er slått på, kan en organisasjon kreve godkjenning for endringer som prisendringer eller lagerjusteringer. Den foreslåtte endringen skrives til en beskyttet fane i regnearket ditt, og ingen kan godkjenne sin egen forespørsel. Les mer i oversikten over revisjonssporet.
Historikk som avslører manipulering
Hver endring som gjøres via LightInventory, skrives som en historikkoppføring i en beskyttet Log-fane i regnearket ditt, i samme oppdatering til Google som selve endringen. Beholdningen redigeres aldri som et tall. Den beregnes ut fra en liste over bevegelser der rader bare legges til, og en tilbakestilling er en ny, motsatt oppføring, ikke en sletting.
At historikken avslører manipulering, betyr at kontrollen viser det hvis noen endrer eller fjerner en tidligere oppføring. Det betyr ikke at endringen er umulig. Slik fungerer det:
- En kjede med nøkkel. Hver oppføring får en kode som beregnes ut fra innholdet og koden til forrige oppføring, med HMAC-SHA256 og en hemmelig nøkkel for organisasjonen din som bare LightInventory har. Endres én oppføring, brytes kjeden fra det punktet. Fordi nøkkelen er hemmelig, kan ingen i det stille beregne kodene på nytt etter en endring.
- En kopi av kjeden, uten verdier. Vi har kjedens koder, aldri verdiene dine, i en databasetabell som avviser oppdateringer og slettinger.
- Daglige forankringer utenfor databasen vår. Én gang i døgnet skrives ett enkelt fingeravtrykk av den siste kjedeposisjonen for alle organisasjoner til en Google Cloud Storage-bøtte med en låst oppbevaringsregel på 7 år. Når regelen er låst, kan den ikke forkortes eller fjernes. En angriper som kunne endre databasen vår, ville likevel ikke kunne skrive om disse forankringene.
- Kontroll hver natt. Hver natt, og når eieren ber om det, beregner vi kjeden på nytt ut fra
Log-fanen og sammenligner den med kopien vår og den siste forankringen. Hvis noe ikke stemmer, ser alle medlemmer en integritetsadvarsel, og eieren og administratorene får en e-post.
Grensen er eierskapet. Eieren av en fil i Google kan alltid redigere, låse opp, kopiere eller slette den; Google lar ingen utestenge eieren. Kjeden kan ikke hindre det, men den gjør det synlig. Google registrerer også appens skrivinger under eierens konto, fordi vi skriver med eierens tillatelse. Vår Log registrerer det faktiske teammedlemmet.
Endringer gjort direkte i regnearket
Som standard er fanene appen administrerer, beskyttet slik at bare eieren kan redigere dem i Google Regneark, og personer med redigeringstilgang til filen kan ikke dele den videre. En valgfri streng lås gjør filen skrivebeskyttet i Google til eieren bevisst låser den opp.
Fordi eieren alltid kan gjøre endringer, oppdager LightInventory dem også. Hver gang appen leser regnearket ditt, sammenligner den hver rad med det lagrede fingeravtrykket. En bakgrunnskontroll kjører også for organisasjoner som ingen ser på. Når en rad er endret utenfor appen, registrerer appen det med best mulig tilskrivning ut fra Googles revisjonsdata, og bruker deretter organisasjonens regel: blokker endringen til en eier eller administrator godtar eller gjenoppretter den, godta og loggfør den, eller hold den tilbake for godkjenning. Endringer i tidligere bevegelser eller historikkoppføringer flagges alltid.
Kryptering og hemmeligheter
- Under overføring: all trafikk bruker HTTPS. Nettlesere får beskjed om bare å bruke HTTPS (HSTS med preload), og sidene våre bruker en streng Content Security Policy.
- Ved lagring: databasen vår er kryptert ved lagring av leverandøren. Regnearket ditt lagres og krypteres av Google.
- Tokener og nøkler: Google-oppdateringstokener, TOTP-hemmeligheter og hver organisasjons historikknøkler krypteres med AES-256-GCM med en ny nøkkel per registrering. Den nøkkelen beskyttes igjen av en hovednøkkel i Google Cloud KMS i London, som aldri forlater KMS og roteres hvert år. KMS kjører i et eget skyprosjekt med egne tilgangskontroller, og serverne våre når den uten noen lagret, langvarig påloggingsinformasjon.
- Ingen kundestøttetilgang til regnearket ditt. Det finnes ingen funksjon som lar de ansatte våre logge inn som deg, og ikke noe kundestøtteverktøy som åpner regnearket ditt. Tilgang til produksjonsdatabasen vår krever to personer og loggføres.
Infrastruktur og underdatabehandlere
| Leverandør | Rolle | Region |
|---|---|---|
| Supabase | Database og autentisering (bare systemdata) | London (eu-west-2) |
| Vercel | Applikasjonsdrift og brannmur; innholdsleveringsnettverk | Funksjoner i London (lhr1); globalt CDN |
| Google Cloud | Nøkkeladministrasjon og forankringer av historikken (bare systemdata) | London (europe-west2) |
| Resend | Transaksjonell e-post (invitasjoner, sikkerhets- og faktureringsvarsler) | USA |
| Stripe | Fakturering og betalinger | Ikke låst til en region |
| Cloudflare | DNS med DNSSEC, og CAPTCHA på innloggingsskjemaer | Globalt nettverk |
Googles API-er for Regneark og Disk behandler regnearket ditt som din egen leverandør. E-poster vi sender, inneholder aldri lagerdataene dine. For leverandører i USA dekkes overføringer av EU-US Data Privacy Framework med UK Extension, eller av standard personvernbestemmelser (standard contractual clauses).
Databehandleravtalen vår er utformet for å gi kunder minst 30 dagers varsel om en ny underdatabehandler og rett til å protestere. Den fullstendige listen over underdatabehandlere og avtalen publiseres ved lansering.
Rapporter en sårbarhet
Hvis du finner et sikkerhetsproblem, sender du en e-post til support@lightinventory.com med trinnene for å gjenskape det. Ikke skaff deg tilgang til andres data eller forstyrr tjenesten, og kontakt oss før all aktiv testing, fordi vilkårene våre ikke tillater sikkerhetstesting uten tillatelse. Kontaktopplysningene våre for sikkerhetsforskere er også publisert i maskinlesbar form i security.txt. En fullstendig retningslinje for ansvarlig varsling publiseres før lansering.
Status
LightInventory gjør seg klar for lansering. Før lansering omfatter planen en ekstern penetrasjonstest av innlogging, isolasjon mellom kunder, Google-autorisasjon, webhooks og injeksjon via regneark, samt en full egenvurdering mot OWASP Application Security Verification Standard 5.0. Denne siden får disse uavhengige vurderingene når de finnes. Inntil da beskriver den utforming, ikke sertifisering.
Se hva LightInventory lagrer for den fullstendige oversikten, og priser for hva hver plan inkluderer.