Hopp til innholdet
LightInventory

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 lagrerHvorforBeskyttelse
Brukere, profiler, organisasjoner, medlemskap, roller, invitasjoner (bare en hash av hvert invitasjonstoken)Innlogging og teamadministrasjonKryptert ved lagring av databaseleverandøren
Innloggingsfaktorer: offentlige nøkler for passnøkler, TOTP-hemmeligheter, hashede gjenopprettingskoderAutentisering med flere faktorerTOTP-hemmeligheter er i tillegg konvoluttkryptert med nøkler som oppbevares i en nøkkeladministrasjonstjeneste
Google-oppdateringstoken for det tilkoblede regnearketLese og skrive filen dinKonvoluttkryptert; sendes aldri til nettleseren og skrives aldri til logger
Metadata om regnearket: fil-ID, fane-ID-er, skjemaversjon, låsemodusFinne og kontrollere filen dinInneholder ingen celleverdier
Radfingeravtrykk (hasher med nøkkel av hver rad)Oppdage endringer gjort direkte i regnearketMed nøkkel, så de kan ikke regnes tilbake til verdiene
Hashkjede for revisjon: sekvensnumre, oppførings-ID-er, hasher, aktør-ID, handlingstype, tidspunktBevise at historikken din er uendretInneholder ingen verdier
Faktureringsreferanser fra betalingsleverandøren vårAbonnementer og fakturaerInneholder ingen kortnumre
Sikkerhetshendelser: innloggingsforsøk, avviste tilganger, IP-adresse, nettleserOppdage misbrukIP-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 spreadsheets eller 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.

  1. 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.
  2. 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.

ØktinnstillingVerdi
Utlogging etter inaktivitet60 minutter
Maksimal øktlengde24 timer
Ny andre faktor for sensitive handlingerI løpet av de siste 5 minuttene
Mislykkede forsøk med andre faktor før sperring10, 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.

FunksjonEierAdministratorGodkjennerRedigererLeser
Se varer, beholdning og historikkJaJaJaEgne plasseringerEgne plasseringer
Registrere bevegelserJaJaJaEgne plasseringerNei
Godkjenne forespørslerJaJaJa, ikke sine egneNeiNei
MassetilbakestillingJaJaNeiNeiNei
Administrere medlemmerJaJaNeiNeiNei
Koble til regnearket, slette organisasjonenJaNeiNeiNeiNei

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ørRolleRegion
SupabaseDatabase og autentisering (bare systemdata)London (eu-west-2)
VercelApplikasjonsdrift og brannmur; innholdsleveringsnettverkFunksjoner i London (lhr1); globalt CDN
Google CloudNøkkeladministrasjon og forankringer av historikken (bare systemdata)London (europe-west2)
ResendTransaksjonell e-post (invitasjoner, sikkerhets- og faktureringsvarsler)USA
StripeFakturering og betalingerIkke låst til en region
CloudflareDNS med DNSSEC, og CAPTCHA på innloggingsskjemaerGlobalt 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.