Sikkerhed hos LightInventory

Dine lagerdata bliver i dit eget Google Sheets-ark. LightInventory læser og skriver i filen på dine vegne, gemmer ingen kopi af indholdet på vores servere og opbevarer kun det, der er nødvendigt for at drive din konto. Denne side forklarer præcis, hvordan det fungerer, hvad vi beskytter mod, og hvor grænserne går.

Hvor dine data ligger

Forretningsdata (varer, placeringer, lagerbevægelser, priser, noter, forslag til godkendelse og værdierne før og efter i din historik) ligger kun i regneark i din Google-konto. Vores servere læser celleværdier ind i hukommelsen for at vise sider, sammenligne ændringer, lave eksporter og skrive dine opdateringer. Disse værdier gemmes ikke i vores database, vores logfiler eller vores fejlrapporter. En automatiseret testpakke kontrollerer, at ingen tabel, loglinje eller fejlhændelse indeholder celleværdier.

Vi gemmer de data, der er nødvendige for at drive din konto:

Vores eget system kører i London. Databasen (Supabase, region eu-west-2), applikationsserverne (Vercel, region lhr1) samt vores krypteringsnøgler og forankringer af historikken (Google Cloud, region europe-west2) er alle fastlagt dertil. Transaktionsmails er den ene dokumenterede undtagelse, beskrevet under infrastruktur og underdatabehandlere.

Den Google-adgang, vi beder om

LightInventory beder Google om to ting. Ved login med Google beder appen om din grundlæggende profil: openid, email og profile. Når du forbinder et regneark, beder den separat om én tilladelse til Drev, drive.file.

Med almindelige ord lader drive.file en app arbejde kun med de filer, du opretter med den eller vælger til den. Google beskriver det som adgang til filer, “that you open with an app or that the user shares with an app while using the Google Picker API” (som du åbner med en app, eller som brugeren deler med en app via Google Picker API) (Google Drive API scopes). Google klassificerer det som et ikke-følsomt omfang.

Hvad det betyder for dig:

• LightInventory kan ikke vise, åbne eller søge i resten af dit Google Drev. En fil, du aldrig har oprettet med LightInventory eller valgt i Googles filvælger, er usynlig for appen.
• Vi beder aldrig om det bredere omfang spreadsheets eller noget omfang med adgang til hele Drev.
• Efter hver tildeling kontrollerer vi, at Google har givet præcis den adgang, vi bad om.
• Du kan til enhver tid fjerne adgangen fra din Google-konto. Se Fjern LightInventorys adgang til Google.

Kun den person, der forbinder regnearket, giver denne adgang, og den person skal eje filen. Dine teammedlemmer føjes aldrig til filen i Google. De arbejder gennem appen med de roller, du giver dem.

Login og sessioner

Alle brugere logger ind med to faktorer, på alle planer, hver gang en session starter.

1. Første faktor: login med Google eller en e-mail og en adgangskode. Adgangskoder skal være på mindst 12 tegn og kontrolleres mod lister over lækkede adgangskoder. Login med Google tæller kun som første faktor, aldrig som begge.
2. Anden faktor: en adgangsnøgle, som er standard og modstår phishing, eller en TOTP-kode fra en godkendelsesapp. Hver bruger tilmelder mindst to metoder og får 10 gendannelseskoder til engangsbrug.

For Ejere og Administratorer kræves phishingresistent login som standard, så TOTP er slået fra for disse roller, medmindre ejeren ændrer indstillingen. Hardwarebaserede sikkerhedsnøgler fungerer som adgangsnøgler. Et link i en e-mail kan nulstille en adgangskode, men det erstatter aldrig den anden faktor.

Godkendelse med flere faktorer kontrolleres to uafhængige steder: i vores serverkode og i databasens egne adgangsregler. En session, der kun har bestået første faktor, kan ikke læse noget, heller ikke hvis den kalder databasen direkte.

Følsomme handlinger omfatter rolleændringer, ændringer af fakturering, at forbinde eller afbryde et regneark, eksporter, samlede fortrydelser, ændringer af loginmetoder og sletning af organisationen. Du kan se dine aktive sessioner og afslutte enhver af dem. Vi sender dig en e-mail, når en ny enhed logger ind, når en loginmetode tilføjes eller fjernes, og når gendannelseskoder bruges.

Roller, placeringer og godkendelser

Hver organisation har fem roller: Ejer, Administrator, Godkender, Redaktør og Læser. Redaktører og Læsere kan begrænses til bestemte placeringer, så et butiksteam kun ser og ændrer sin egen beholdning.

Tilladelser læses direkte ved hver anmodning, så når nogen fjernes eller får en anden rolle, har det virkning fra vedkommendes næste handling. Alle anmodninger afvises, medmindre en regel tillader dem. Hver rolle er forklaret i Team og roller.

Godkendelser er valgfrie. Når de er slået til, kan en organisation kræve godkendelse af ændringer som prisændringer eller lagerreguleringer. Den foreslåede ændring skrives til en beskyttet fane i dit regneark, og ingen kan godkende sin egen anmodning. Læs mere i oversigten over revisionssporet.

Manipulationssikker historik

Hver ændring, der foretages gennem LightInventory, skrives som en historikpost i en beskyttet Log-fane i dit regneark, i den samme Google-opdatering som selve ændringen. Beholdningen redigeres aldrig som et tal. Den beregnes ud fra en liste over bevægelser, der kun kan tilføjes til, og en fortrydelse er en ny, modsat post og ikke en sletning.

Manipulationssikker betyder, at hvis nogen ændrer eller fjerner en tidligere post, viser kontrollen det. Det betyder ikke, at ændringen er umulig. Sådan fungerer det:

• En kæde med nøgle. Hver post får en kode, der beregnes ud fra dens indhold og den forrige posts kode med HMAC-SHA256 og en hemmelig nøgle for din organisation, som kun LightInventory har. Ændres én post, brydes kæden fra det punkt. Fordi nøglen er hemmelig, kan ingen i det stille beregne koderne igen efter en ændring.
• En kopi af kæden, uden værdier. Vi gemmer kædens koder, aldrig dine værdier, i en databasetabel, der afviser opdateringer og sletninger.
• Daglige forankringer uden for vores database. Én gang om dagen skrives ét samlet fingeraftryk af hver organisations seneste position i kæden til en Google Cloud Storage-bucket med en låst opbevaringspolitik på 7 år. Når politikken er låst, kan den ikke forkortes eller fjernes. En angriber, der kunne ændre vores database, ville stadig ikke kunne omskrive disse forankringer.
• Kontrol hver nat. Hver nat, og når ejeren beder om det, genberegner vi kæden ud fra din Log-fane og sammenligner den med vores kopi og den seneste forankring. Hvis noget ikke stemmer, ser alle medlemmer en integritetsadvarsel, og Ejeren og Administratorer får en e-mail.

Grænsen er ejerskab. Ejeren af en Google-fil kan altid redigere, låse op, kopiere eller slette den; Google tillader ikke, at nogen udelukkes. Kæden kan ikke forhindre det, men den gør det synligt. Google registrerer også vores apps skrivninger under ejerens konto, fordi vi skriver med ejerens tilladelse. Vores Log registrerer det faktiske teammedlem.

Ændringer foretaget direkte i arket

Som standard er dine styrede faner beskyttet, så kun ejeren kan redigere dem i Google Sheets, og filens redaktører kan ikke dele den videre. En valgfri streng lås gør filen skrivebeskyttet i Google, indtil ejeren bevidst låser den op.

Fordi ejeren altid kan foretage ændringer, opdager LightInventory dem også. Hver gang appen læser dit ark, sammenligner den hver række med dens gemte fingeraftryk. En kontrol i baggrunden kører også for organisationer, som ingen har åbne. Når en række er ændret uden for appen, registrerer appen det med den bedst mulige tilskrivning ud fra Googles revisionsdata og anvender derefter din organisations politik: bloker ændringen, indtil en Ejer eller Administrator godtager eller gendanner den, acceptér og log den, eller hold den tilbage til godkendelse. Ændringer af tidligere bevægelser eller historikposter markeres altid.

Kryptering og hemmeligheder

• Under overførsel: al trafik bruger HTTPS. Browsere får besked på kun at bruge HTTPS (HSTS med preload), og vores sider bruger en streng Content Security Policy.
• I hvile: vores database er krypteret i hvile af udbyderen. Dit regneark opbevares og krypteres af Google.
• Tokens og nøgler: Google-opdateringstokens, TOTP-hemmeligheder og hver organisations historiknøgler krypteres med AES-256-GCM med en ny nøgle pr. registrering. Den nøgle er igen beskyttet af en hovednøgle i Google Cloud KMS i London, som aldrig forlader KMS og roteres hvert år. KMS kører i et separat cloudprojekt med egne adgangskontroller, og vores servere når den uden nogen gemt, langtidsholdbar legitimation.
• Ingen supportadgang til dit ark. Der findes ingen funktion, hvor vores medarbejdere kan logge ind som dig, og intet supportværktøj, der åbner dit regneark. Adgang til vores produktionsdatabase kræver to personer og logges.

Infrastruktur og underdatabehandlere

Googles Sheets- og Drive-API'er behandler dit regneark som din egen udbyder. De e-mails, vi sender, indeholder aldrig dine lagerdata. For udbydere med base i USA er overførsler dækket af EU-US Data Privacy Framework med den britiske udvidelse (UK Extension) eller af standardkontraktbestemmelser.

Vores databehandleraftale er udformet til at give kunder mindst 30 dages varsel om en ny underdatabehandler og ret til at gøre indsigelse. Den fulde liste over underdatabehandlere og aftalen offentliggøres ved lanceringen.

Rapportér en sårbarhed

Hvis du finder et sikkerhedsproblem, så skriv til support@lightinventory.com med trinene til at genskabe det. Undlad at tilgå andres data eller forstyrre tjenesten, og kontakt os før enhver aktiv test, fordi vores vilkår ikke tillader sikkerhedstest uden tilladelse. Vores kontaktoplysninger til sikkerhedsforskere er også offentliggjort i maskinlæsbar form i security.txt. En fuld politik for ansvarlig offentliggørelse udgives før lanceringen.

Status

LightInventory gør klar til lancering. Før lanceringen omfatter planen en ekstern penetrationstest af login, adskillelse mellem kunder, Google-autorisation, webhooks og injektion i regneark samt en fuld selvevaluering efter OWASP Application Security Verification Standard 5.0. Denne side tilføjer disse uafhængige vurderinger, når de findes. Indtil da beskriver den design, ikke certificering.

Se hvad LightInventory gemmer for den fulde liste, og priser for, hvad hver plan omfatter.