Към съдържанието
LightInventory

Преведено с ИИ от английската версия от 30 октомври 2026 г.. Прочетете оригинала

Сигурност в LightInventory

Къде са данните ви, какъв достъп до Google искаме, как работят входът, ролите и историята, разкриваща манипулации, и кои доставчици използваме.

Последна актуализация: 30 октомври 2026 г.

Данните за наличностите ви остават във вашата собствена Google Таблица. LightInventory чете и записва в този файл от ваше име, не пази копие от съдържанието му на нашите сървъри и съхранява само това, което му е нужно, за да поддържа профила ви. Тази страница обяснява точно как работи това, от какво се защитаваме и къде са границите.

Къде се намират данните ви

Бизнес данните (артикули, местоположения, складови движения, цени, бележки, предложения за одобрение и стойностите преди и след в историята ви) се намират само в таблици във вашия профил в Google. Нашите сървъри зареждат стойностите на клетките в паметта, за да показват страници, да сравняват промени, да създават експорти и да записват вашите актуализации. Тези стойности не се записват в нашата база данни, в дневниците ни или в отчетите ни за грешки. Автоматизиран набор от тестове проверява, че нито една таблица, ред от дневник или събитие за грешка не съдържа стойности на клетки.

Съхраняваме данните, нужни за поддържането на профила ви:

Какво съхранявамеЗащоЗащита
Потребители, профили, организации, членства, роли, покани (само хеш на всеки токен за покана)Вход и управление на екипаШифровани в покой от доставчика на базата данни
Фактори за вход: публични ключове на ключовете за достъп, TOTP тайни, хеширани кодове за възстановяванеМногофакторно удостоверяванеTOTP тайните са допълнително шифровани с плик (envelope encryption) с ключове, пазени в услуга за управление на ключове
Токен за обновяване от Google за свързаната таблицаЧетене и запис във вашия файлШифрован с плик; никога не се изпраща към браузъра и не се записва в дневници
Метаданни на таблицата: идентификатор на файла, идентификатори на разделите, версия на схемата, режим на заключванеНамиране и проверка на файла виНе съдържат стойности на клетки
Отпечатъци на редовете (хешове с ключ на всеки ред)Засичане на редакции, направени директно в таблицатаС ключ, така че от тях не могат да се възстановят стойностите
Одитна верига от хешове: поредни номера, идентификатори на записи, хешове, идентификатор на извършителя, вид действие, часДоказване, че историята ви е непромененаНе съдържа стойности
Данни за фактуриране от доставчика ни на платежни услугиАбонаменти и фактуриНе съдържат номера на карти
Събития, свързани със сигурността: опити за вход, откази на достъп, IP адрес, браузърОткриване на злоупотребиIP адресът се премахва след 90 дни, събитията се изтриват след 1 година

Собствената ни система работи в Лондон. Базата данни (Supabase, регион eu-west-2), сървърите на приложението (Vercel, регион lhr1) и ключовете ни за шифроване и котвите на историята (Google Cloud, регион europe-west2) са закрепени там. Единственото документирано изключение са транзакционните имейли, описани в раздела Инфраструктура и подизпълнители.

Достъпът до Google, който искаме

LightInventory иска от Google две неща. При вход с Google иска основния ви профил: openid, email и profile. Когато свържете таблица, иска отделно едно разрешение за Диск: drive.file.

Казано просто, drive.file позволява на едно приложение да работи само с файловете, които създавате с него или избирате за него. Google го описва като достъп до файлове, „които отваряте с приложение или които потребителят споделя с приложение, докато използва Google Picker API“ (Обхвати на Google Drive API). Google го класифицира като нечувствителен обхват.

Какво означава това за вас:

  • LightInventory не може да изброява, отваря или търси в останалата част от вашия Google Диск. Файл, който никога не сте създали с LightInventory и не сте избрали в инструмента на Google за избор на файлове, е невидим за него.
  • Никога не искаме по-широкия обхват spreadsheets или обхват за целия Диск.
  • След всяко предоставяне на достъп проверяваме дали Google е върнал точно достъпа, който сме поискали.
  • Можете да премахнете достъпа по всяко време от своя профил в Google. Вижте Отнемане на достъпа на LightInventory до Google.

Този достъп дава само човекът, който свързва таблицата, и той трябва да е собственик на файла. Членовете на екипа ви никога не се добавят към файла в Google. Те работят през приложението, с ролите, които им дадете.

Вход и сесии

Всеки потребител влиза с два фактора, във всеки план, при всяко започване на сесия.

  1. Първи фактор: вход с Google или имейл и парола. Паролите трябва да са поне 12 знака и се проверяват спрямо списъци с изтекли пароли. Входът с Google се брои само за първи фактор, никога и за двата.
  2. Втори фактор: ключ за достъп, който е по подразбиране и е устойчив на фишинг, или TOTP код от приложение за удостоверяване. Всеки потребител регистрира поне два метода и получава 10 еднократни кода за възстановяване.

За собствениците и администраторите по подразбиране се изисква вход, устойчив на фишинг, затова TOTP е изключен за тези роли, освен ако собственикът не промени настройката. Хардуерните ключове за сигурност работят като ключове за достъп. Връзка по имейл може да нулира парола, но никога не замества втория фактор.

Многофакторното удостоверяване се проверява на две независими места: в сървърния ни код и в собствените правила за достъп на базата данни. Сесия, която е преминала само първия фактор, не може да прочете нищо, дори ако се обърне директно към базата данни.

Настройка на сесиятаСтойност
Изход след неактивност60 минути
Максимална продължителност на сесията24 часа
Ново потвърждение с втори фактор за чувствителни действияПрез последните 5 минути
Неуспешни опити с втори фактор преди блокиране10, със забавяния от 30 секунди до 1 час

Чувствителните действия включват промени на роли, промени във фактурирането, свързване или разкачване на таблица, експорти, групови отмени, промени в методите за вход и изтриване на организацията. Можете да виждате активните си сесии и да прекратите всяка от тях. Изпращаме ви имейл, когато влезе ново устройство, когато бъде добавен или премахнат метод за вход и когато бъдат използвани кодове за възстановяване.

Роли, местоположения и одобрения

Всяка организация има пет роли: собственик (Owner), администратор (Admin), одобряващ (Approver), редактор (Editor) и наблюдател (Viewer). Редакторите и наблюдателите могат да бъдат ограничени до определени местоположения, така че екипът на един магазин да вижда и променя само своите наличности.

ВъзможностСобственикАдминистраторОдобряващРедакторНаблюдател
Преглед на артикули, наличности и историяДаДаДаСвоите местоположенияСвоите местоположения
Записване на движенияДаДаДаСвоите местоположенияНе
Одобряване на заявкиДаДаДа, без собственитеНеНе
Групова отмянаДаДаНеНеНе
Управление на членоветеДаДаНеНеНе
Свързване на таблицата, изтриване на организациятаДаНеНеНеНе

Разрешенията се проверяват наживо при всяка заявка, така че премахването на някого или промяната на ролята му влиза в сила при следващото му действие. Всяка заявка се отказва, освен ако правило не я разрешава. Всяка роля е обяснена в Екип и роли.

Одобренията не са задължителни. Когато са включени, организацията може да изисква одобрение за промени като редакции на цени или корекции на наличности. Предложената промяна се записва в защитен раздел във вашата таблица и никой не може да одобри собствената си заявка. Научете повече в прегледа на одитната следа.

История, разкриваща манипулации

Всяка промяна, направена през LightInventory, се записва като запис в историята в защитен раздел Log във вашата таблица, в същата актуализация към Google като самата промяна. Наличността никога не се редактира като число. Тя се изчислява от списък с движения, в който само се добавя, а отмяната е нов, обратен запис, а не изтриване.

История, разкриваща манипулации, означава, че ако някой промени или премахне минал запис, проверката ще го покаже. Това не означава, че промяната е невъзможна. Ето как работи:

  • Верига с ключ. Всеки запис получава код, изчислен от съдържанието му и кода на предходния запис, с HMAC-SHA256 и таен ключ за вашата организация, който пази само LightInventory. Промяната на един запис разваля веригата от тази точка нататък. Тъй като ключът е таен, никой не може незабелязано да изчисли кодовете отново след редакция.
  • Копие на веригата, без стойности. Пазим кодовете на веригата, никога вашите стойности, в таблица на базата данни, която отхвърля промени и изтривания.
  • Ежедневни котви извън нашата база данни. Веднъж на ден един отпечатък на последната позиция във веригата на всяка организация се записва в хранилище (bucket) на Google Cloud Storage със заключена политика за съхранение от 7 години. След заключване тази политика не може да бъде съкратена или премахната. Нападател, който би могъл да промени нашата база данни, пак не би могъл да пренапише тези котви.
  • Нощна проверка. Всяка нощ, а и когато собственикът поиска, изчисляваме отново веригата от вашия раздел Log и я сравняваме с нашето копие и с последната котва. Ако нещо не съвпада, всеки член вижда предупреждение за целостта, а собственикът и администраторите получават имейл.

Границата е собствеността. Собственикът на файл в Google винаги може да го редактира, отключи, копира или изтрие; Google не позволява никой да бъде изключен. Веригата не може да спре това, но го прави видимо. Google също така записва действията на нашето приложение под профила на собственика, защото записваме с неговото разрешение. Нашият Log записва действителния член на екипа.

Редакции, направени директно в таблицата

По подразбиране управляваните раздели са защитени така, че само собственикът да може да ги редактира в Google Таблици, а редакторите на файла не могат да го споделят по-нататък. По избор строго заключване прави файла само за четене в Google, докато собственикът съзнателно не го отключи.

Тъй като собственикът винаги може да прави промени, LightInventory също ги засича. Всеки път, когато приложението чете таблицата ви, то сравнява всеки ред със съхранения му отпечатък. За организации, които никой не разглежда, се изпълнява и проверка във фонов режим. Когато ред е променен извън приложението, приложението го записва с възможно най-точното посочване на извършителя по данните за ревизиите на Google и след това прилага правилата на вашата организация: блокира промяната, докато собственик или администратор не я приеме или не възстанови предишното състояние, приема я и я записва в дневника или я задържа за одобрение. Редакциите на минали движения или записи в историята винаги се отбелязват.

Шифроване и тайни данни

  • При пренос: целият трафик използва HTTPS. Браузърите получават указание да използват само HTTPS (HSTS с preload), а страниците ни използват строга политика за сигурност на съдържанието (Content Security Policy).
  • В покой: базата ни данни е шифрована в покой от нейния доставчик. Вашата таблица се съхранява и шифрова от Google.
  • Токени и ключове: токените за обновяване от Google, TOTP тайните и ключовете за историята на всяка организация се шифроват с AES-256-GCM с нов ключ за всеки запис. Този ключ на свой ред е защитен с главен ключ в Google Cloud KMS в Лондон, който никога не напуска KMS и се сменя всяка година. KMS работи в отделен облачен проект със собствен контрол на достъпа, а сървърите ни се свързват с него без съхранени дълготрайни идентификационни данни.
  • Без достъп на поддръжката до таблицата ви. Няма функция, с която служителите ни да влизат от ваше име, и няма инструмент за поддръжка, който да отваря таблицата ви. Достъпът до продукционната ни база данни изисква двама души и се записва.

Инфраструктура и подизпълнители

ДоставчикРоляРегион
SupabaseБаза данни и удостоверяване (само системни данни)Лондон (eu-west-2)
VercelХостинг на приложението и защитна стена; мрежа за доставка на съдържаниеФункции в Лондон (lhr1); глобална CDN
Google CloudУправление на ключове и котви на историята (само системни данни)Лондон (europe-west2)
ResendТранзакционни имейли (покани, известия за сигурността и фактурирането)САЩ
StripeФактуриране и плащанияБез фиксиран регион
CloudflareDNS с DNSSEC и CAPTCHA във формулярите за входГлобална мрежа

API интерфейсите на Google Таблици и Google Диск обработват таблицата ви като ваш собствен доставчик. Имейлите, които изпращаме, никога не съдържат данни за наличностите ви. За доставчиците със седалище в САЩ преносът на данни е обезпечен от Рамката за защита на данните между ЕС и САЩ с разширението за Обединеното кралство или от стандартни договорни клаузи.

Нашето споразумение за обработване на данни е изготвено така, че да дава на клиентите поне 30 дни предварително известие за нов подизпълнител и право на възражение. Пълният списък с подизпълнители и споразумението ще бъдат публикувани при старта.

Докладване на уязвимост

Ако откриете проблем със сигурността, пишете на support@lightinventory.com и опишете стъпките за възпроизвеждането му. Моля, не достъпвайте данни на други хора и не нарушавайте работата на услугата, а преди каквото и да е активно тестване се свържете с нас, защото условията ни не позволяват тестване на сигурността без разрешение. Данните ни за контакт за изследователи по сигурността са публикувани и в машинночетим вид в security.txt. Пълна политика за отговорно разкриване ще бъде публикувана преди старта.

Статус

LightInventory се подготвя за старт. Планът преди старта включва външен тест за проникване, обхващащ входа, изолацията между клиентите, оторизацията с Google, уебкуките и инжектирането в таблици, както и пълна самооценка спрямо OWASP Application Security Verification Standard 5.0. Тази страница ще добави тези независими оценки, когато са налични. Дотогава тя описва проектирането, а не сертифициране.

Пълния списък ще намерите в Какво съхранява LightInventory, а какво включва всеки план – в цените.