# Beveiliging bij LightInventory

> Waar je gegevens staan, welke Google-toegang we vragen, hoe inloggen, rollen en de geschiedenis waarin geknoei opvalt werken, en welke providers we gebruiken.

Source: https://www.lightinventory.com/nl/beveiliging · Last updated: 2026-10-30

Je voorraadgegevens blijven in je eigen Google-spreadsheet. LightInventory leest en schrijft dat bestand namens jou, bewaart geen kopie van de inhoud op onze servers en slaat alleen op wat nodig is om je account te laten werken. Deze pagina legt precies uit hoe dat werkt, waartegen we beschermen en waar de grenzen liggen.

> **Note:** LightInventory is in ontwikkeling en nog niet algemeen beschikbaar. Deze pagina beschrijft het systeem zoals het is ontworpen. Ze claimt geen audits, certificeringen of beschikbaarheidscijfers, omdat die er nog niet zijn.

## Waar je gegevens staan

Bedrijfsgegevens (artikelen, locaties, voorraadmutaties, prijzen, notities, goedkeuringsvoorstellen en de waarden ervoor en erna in je geschiedenis) staan alleen in spreadsheets in je Google-account. Onze servers lezen celwaarden in het werkgeheugen om pagina's te tonen, wijzigingen te vergelijken, exports te maken en je wijzigingen te schrijven. Die waarden worden niet opgeslagen in onze database, onze logboeken of onze foutrapporten. Een geautomatiseerde testsuite controleert dat geen enkele tabel, logregel of foutmelding celwaarden bevat.

We slaan wel de gegevens op die nodig zijn om je account te laten werken:

| Wat we opslaan | Waarom | Bescherming |
|---|---|---|
| Gebruikers, profielen, organisaties, lidmaatschappen, rollen, uitnodigingen (alleen een hash van elk uitnodigingstoken) | Inloggen en teambeheer | In rust versleuteld door de databaseprovider |
| Inlogfactoren: openbare passkey-sleutels, TOTP-geheimen, gehashte herstelcodes | Meervoudige authenticatie | TOTP-geheimen zijn daarnaast met envelopversleuteling beveiligd, met sleutels uit een sleutelbeheerdienst |
| Google-vernieuwingstoken voor de gekoppelde spreadsheet | Je bestand lezen en schrijven | Met envelopversleuteling beveiligd; nooit naar de browser gestuurd of in logboeken geschreven |
| Metadata van de spreadsheet: bestands-ID, tabblad-ID's, schemaversie, vergrendelingsmodus | Je bestand vinden en controleren | Bevat geen celwaarden |
| Vingerafdrukken van rijen (hashes met geheime sleutel van elke rij) | Bewerkingen rechtstreeks in de spreadsheet opmerken | Met geheime sleutel, dus niet terug te rekenen naar de waarden |
| Hashketen van de audit: volgnummers, regel-ID's, hashes, actor-ID, type actie, tijdstip | Bewijzen dat je geschiedenis ongewijzigd is | Bevat geen waarden |
| Factuurreferenties van onze betaalprovider | Abonnementen en facturen | Bevat geen kaartnummers |
| Beveiligingsgebeurtenissen: inlogpogingen, mislukte rechtencontroles, IP-adres, browser | Misbruik opsporen | IP-adres na 90 dagen verwijderd, gebeurtenissen na 1 jaar gewist |

Ons eigen systeem draait in **Londen**. De database (Supabase, regio `eu-west-2`), de applicatieservers (Vercel, regio `lhr1`) en onze versleutelingssleutels en geschiedenisankers (Google Cloud, regio `europe-west2`) zijn daar allemaal vastgelegd. Transactionele e-mail is de enige gedocumenteerde uitzondering, beschreven onder [Infrastructuur en subverwerkers](#infrastructuur-en-subverwerkers).

## De Google-toegang die we vragen

LightInventory vraagt Google om twee dingen. Bij inloggen met Google vraagt het om je basisprofiel: `openid`, `email` en `profile`. Als je een spreadsheet koppelt, vraagt het apart om één Drive-recht, `drive.file`.

In gewone woorden laat `drive.file` een app alleen werken met de bestanden die je ermee maakt of ervoor kiest. Google omschrijft het als toegang tot bestanden “that you open with an app or that the user shares with an app while using the Google Picker API”, dus bestanden die je met een app opent of via de Google Picker API met een app deelt ([Google Drive API-bereiken](https://developers.google.com/workspace/drive/api/guides/api-specific-auth?hl=nl)). Google merkt het aan als een niet-gevoelig bereik.

Wat dat voor jou betekent:

- LightInventory kan de rest van je Google Drive niet weergeven, openen of doorzoeken. Een bestand dat je nooit met LightInventory hebt gemaakt of in de bestandskiezer van Google hebt gekozen, is onzichtbaar voor de app.
- We vragen nooit om het bredere bereik `spreadsheets` of om een bereik voor heel Drive.
- Na elke toestemming controleren we of Google precies de toegang heeft gegeven waar we om vroegen.
- Je kunt de toegang op elk moment intrekken vanuit je Google-account. Zie [De Google-toegang van LightInventory intrekken](/nl/help/gegevens-en-privacy/google-toegang-intrekken).

Alleen de persoon die de spreadsheet koppelt, geeft deze toegang, en die persoon moet eigenaar van het bestand zijn. Je teamleden worden in Google nooit aan het bestand toegevoegd. Ze werken via de app, met de rollen die jij ze geeft.

## Inloggen en sessies

Elke gebruiker logt in met twee factoren, in elk abonnement, telkens wanneer een sessie begint.

1. **Eerste factor:** inloggen met Google, of met een e-mailadres en wachtwoord. Wachtwoorden moeten minstens 12 tekens lang zijn en worden gecontroleerd tegen lijsten met gelekte wachtwoorden. Inloggen met Google telt alleen als eerste factor, nooit als allebei.
2. **Tweede factor:** een passkey, die de standaard is en bestand is tegen phishing, of een TOTP-code uit een authenticator-app. Elke gebruiker stelt minstens twee methoden in en krijgt 10 herstelcodes voor eenmalig gebruik.

Voor Eigenaren en Beheerders is phishingbestendig inloggen standaard verplicht, dus TOTP staat voor die rollen uit, tenzij de eigenaar de instelling wijzigt. Hardwarebeveiligingssleutels werken als passkeys. Met een e-maillink kun je een wachtwoord opnieuw instellen, maar die vervangt nooit de tweede factor.

Meervoudige authenticatie wordt op twee onafhankelijke plekken gecontroleerd: in onze servercode en in de toegangsregels van de database zelf. Een sessie die alleen de eerste factor heeft doorlopen, kan niets lezen, ook niet als ze de database rechtstreeks aanroept.

| Sessie-instelling | Waarde |
|---|---|
| Uitloggen na inactiviteit | 60 minuten |
| Maximale sessieduur | 24 uur |
| Nieuwe bevestiging met tweede factor voor gevoelige acties | Binnen de laatste 5 minuten |
| Mislukte pogingen met de tweede factor vóór blokkering | 10, met wachttijden van 30 seconden tot 1 uur |

Gevoelige acties zijn onder meer rolwijzigingen, wijzigingen in facturering, een spreadsheet koppelen of ontkoppelen, exports, bulk terugdraaien, wijzigingen in inlogmethoden en het verwijderen van de organisatie. Je kunt je actieve sessies bekijken en elke sessie beëindigen. We mailen je wanneer een nieuw apparaat inlogt, wanneer een inlogmethode wordt toegevoegd of verwijderd en wanneer herstelcodes worden gebruikt.

## Rollen, locaties en goedkeuringen

Elke organisatie heeft vijf rollen: Eigenaar, Beheerder, Goedkeurder, Bewerker en Lezer. Bewerkers en Lezers kunnen worden beperkt tot bepaalde locaties, zodat een winkelteam alleen de eigen voorraad ziet en wijzigt.

| Mogelijkheid | Eigenaar | Beheerder | Goedkeurder | Bewerker | Lezer |
|---|---|---|---|---|---|
| Artikelen, voorraad en geschiedenis bekijken | Ja | Ja | Ja | Eigen locaties | Eigen locaties |
| Mutaties vastleggen | Ja | Ja | Ja | Eigen locaties | Nee |
| Verzoeken goedkeuren | Ja | Ja | Ja, niet de eigen | Nee | Nee |
| Bulk terugdraaien | Ja | Ja | Nee | Nee | Nee |
| Leden beheren | Ja | Ja | Nee | Nee | Nee |
| De spreadsheet koppelen, de organisatie verwijderen | Ja | Nee | Nee | Nee | Nee |

Rechten worden bij elk verzoek live gelezen, dus iemand verwijderen of een rol wijzigen werkt vanaf de volgende actie van die persoon. Elk verzoek wordt geweigerd, tenzij een regel het toestaat. Elke rol wordt uitgelegd in [Team en rollen](/nl/help/team-en-rollen).

Goedkeuringen zijn optioneel. Staan ze aan, dan kan een organisatie goedkeuring vereisen voor wijzigingen zoals prijswijzigingen of voorraadcorrecties. De voorgestelde wijziging wordt naar een beveiligd tabblad in je spreadsheet geschreven, en niemand kan zijn eigen verzoek goedkeuren. Lees meer in het overzicht van de [audittrail](/nl/functies/audittrail).

## Geschiedenis waarin geknoei zichtbaar wordt

Elke wijziging via LightInventory wordt als geschiedenisregel geschreven in een beveiligd tabblad `Log` in je spreadsheet, in dezelfde Google-update als de wijziging zelf. Voorraad wordt nooit als getal bewerkt. Ze wordt berekend uit een lijst met mutaties waaraan alleen wordt toegevoegd, en terugdraaien is een nieuwe, tegengestelde regel in plaats van een verwijdering.

Geknoei zichtbaar maken betekent dat de controle het laat zien als iemand een eerdere regel wijzigt of verwijdert. Het betekent niet dat de wijziging onmogelijk is. Zo werkt het:

- **Een keten met geheime sleutel.** Elke regel krijgt een code die wordt berekend uit de inhoud en de code van de vorige regel, met HMAC-SHA256 en een geheime sleutel voor je organisatie die alleen LightInventory heeft. Wijzig je één regel, dan breekt de keten vanaf dat punt. Omdat de sleutel geheim is, kan niemand na een bewerking ongemerkt de codes opnieuw berekenen.
- **Een kopie van de keten, zonder waarden.** We bewaren de codes van de keten, nooit je waarden, in een databasetabel die wijzigingen en verwijderingen weigert.
- **Dagelijkse ankers buiten onze database.** Eén keer per dag wordt één vingerafdruk van de laatste ketenpositie van elke organisatie geschreven naar een Google Cloud Storage-bucket met een vergrendeld bewaarbeleid van 7 jaar. Is dat beleid eenmaal vergrendeld, dan kan het niet worden ingekort of verwijderd. Een aanvaller die onze database zou kunnen wijzigen, kan die ankers nog steeds niet herschrijven.
- **Nachtelijke controle.** Elke nacht, en wanneer de eigenaar daarom vraagt, berekenen we de keten opnieuw uit je tabblad `Log` en vergelijken we die met onze kopie en het laatste anker. Klopt er iets niet, dan ziet elk lid een integriteitswaarschuwing en krijgen de Eigenaar en Beheerders een e-mail.

De grens is eigenaarschap. De eigenaar van een Google-bestand kan het altijd bewerken, ontgrendelen, kopiëren of verwijderen; Google staat niet toe dat iemand wordt uitgesloten. De keten kan dat niet tegenhouden, maar maakt het wel zichtbaar. Google registreert de schrijfacties van onze app ook onder het account van de eigenaar, omdat we schrijven met toestemming van de eigenaar. Ons `Log` legt het werkelijke teamlid vast.

## Wijzigingen rechtstreeks in de spreadsheet

Standaard zijn je beheerde tabbladen zo beveiligd dat alleen de eigenaar ze in Google Spreadsheets kan bewerken, en bewerkers van het bestand kunnen het niet verder delen. Een optionele strikte vergrendeling maakt het bestand in Google alleen-lezen tot de eigenaar het bewust ontgrendelt.

Omdat de eigenaar altijd wijzigingen kan aanbrengen, merkt LightInventory ze ook op. Elke keer dat de app je spreadsheet leest, vergelijkt hij elke rij met de opgeslagen vingerafdruk. Voor organisaties die niemand bekijkt, draait ook een controle op de achtergrond. Is een rij buiten de app gewijzigd, dan legt de app dat vast met een zo goed mogelijke toeschrijving op basis van de revisiegegevens van Google, en past daarna het beleid van je organisatie toe: de wijziging blokkeren tot een Eigenaar of Beheerder haar overneemt of de vorige stand herstelt, haar accepteren en vastleggen, of haar aanhouden voor goedkeuring. Bewerkingen van eerdere mutaties of geschiedenisregels worden altijd gemarkeerd.

## Versleuteling en geheimen

- **Onderweg:** al het verkeer gaat via HTTPS. Browsers krijgen de opdracht alleen HTTPS te gebruiken (HSTS met preload), en onze pagina's gebruiken een strikte Content Security Policy.
- **In rust:** onze database wordt in rust versleuteld door de provider. Je spreadsheet wordt opgeslagen en versleuteld door Google.
- **Tokens en sleutels:** Google-vernieuwingstokens, TOTP-geheimen en de geschiedenissleutels van elke organisatie worden versleuteld met AES-256-GCM, met een nieuwe sleutel per gegeven. Die sleutel wordt op zijn beurt beschermd door een hoofdsleutel in Google Cloud KMS in Londen, die KMS nooit verlaat en elk jaar wordt geroteerd. KMS draait in een apart cloudproject met eigen toegangscontroles, en onze servers bereiken het zonder opgeslagen langlevende inloggegevens.
- **Geen supporttoegang tot je spreadsheet.** Er is geen functie waarmee onze medewerkers als jou kunnen inloggen, en geen supporttool die je spreadsheet opent. Toegang tot onze productiedatabase vereist twee personen en wordt vastgelegd.

## Infrastructuur en subverwerkers

| Provider | Rol | Regio |
|---|---|---|
| Supabase | Database en authenticatie (alleen systeemgegevens) | Londen (`eu-west-2`) |
| Vercel | Applicatiehosting en firewall; content delivery network | Functies in Londen (`lhr1`); wereldwijd CDN |
| Google Cloud | Sleutelbeheer en geschiedenisankers (alleen systeemgegevens) | Londen (`europe-west2`) |
| Resend | Transactionele e-mail (uitnodigingen, beveiligings- en factuurmeldingen) | Verenigde Staten |
| Stripe | Facturering en betalingen | Niet aan een regio gebonden |
| Cloudflare | DNS met DNSSEC, en de CAPTCHA op inlogformulieren | Wereldwijd netwerk |

De Sheets- en Drive-API's van Google verwerken je spreadsheet als jouw eigen provider. E-mails die we versturen, bevatten nooit je voorraadgegevens. Voor providers in de VS zijn doorgiften gedekt door het EU-US Data Privacy Framework met de Britse uitbreiding, of door standaardcontractbepalingen.

Onze verwerkersovereenkomst is zo opgezet dat klanten minstens 30 dagen van tevoren bericht krijgen over een nieuwe subverwerker en het recht hebben om bezwaar te maken. De volledige lijst met subverwerkers en de overeenkomst worden bij de lancering gepubliceerd.

## Een kwetsbaarheid melden

Vind je een beveiligingsprobleem, mail dan naar **support@lightinventory.com** met de stappen om het te reproduceren. Open geen gegevens van anderen en verstoor de dienst niet, en neem contact met ons op vóór je actief gaat testen, want onze voorwaarden staan beveiligingstests zonder toestemming niet toe. Onze contactgegevens voor beveiligingsonderzoekers staan ook in machineleesbare vorm in [security.txt](/.well-known/security.txt). Een volledig beleid voor verantwoorde openbaarmaking wordt vóór de lancering gepubliceerd.

## Status

LightInventory bereidt de lancering voor. Vóór de lancering omvat het plan een externe penetratietest van inloggen, scheiding tussen klanten, Google-autorisatie, webhooks en injectie via de spreadsheet, plus een volledige zelfbeoordeling volgens de OWASP Application Security Verification Standard 5.0. Deze pagina vult die onafhankelijke beoordelingen aan zodra ze er zijn. Tot die tijd beschrijft ze het ontwerp, geen certificering.

Zie [wat LightInventory opslaat](/nl/help/gegevens-en-privacy/wat-we-opslaan) voor de volledige lijst, en [prijzen](/nl/prijzen) voor wat elk abonnement bevat.