Segurança no LightInventory

Os seus dados de inventário ficam na sua própria folha do Google Sheets. O LightInventory lê e escreve nesse ficheiro em seu nome, não guarda nenhuma cópia do respetivo conteúdo nos nossos servidores e armazena apenas o que precisa para gerir a sua conta. Esta página explica exatamente como isso funciona, contra o que o protegemos e onde estão os limites.

Onde ficam os seus dados

Os dados de negócio (artigos, localizações, movimentos de stock, preços, notas, propostas de aprovação e os valores antes e depois no seu histórico) ficam apenas em folhas de cálculo na sua conta Google. Os nossos servidores leem os valores das células para a memória para mostrar páginas, comparar alterações, gerar exportações e escrever as suas atualizações. Esses valores não são guardados na nossa base de dados, nos nossos registos nem nos nossos relatórios de erros. Um conjunto de testes automáticos verifica que nenhuma tabela, linha de registo ou evento de erro contém valores de células.

Guardamos, sim, os dados necessários para gerir a sua conta:

O nosso próprio sistema funciona em Londres. A base de dados (Supabase, região eu-west-2), os servidores da aplicação (Vercel, região lhr1) e as nossas chaves de encriptação e âncoras do histórico (Google Cloud, região europe-west2) estão todos fixados aí. O e-mail transacional é a única exceção documentada, explicada em infraestrutura e subcontratantes.

O acesso ao Google que pedimos

O LightInventory pede duas coisas ao Google. No início de sessão com o Google, pede o seu perfil básico: openid, email e profile. Quando liga uma folha de cálculo, pede separadamente uma única autorização do Drive: drive.file.

Em termos simples, drive.file permite que uma aplicação trabalhe apenas com os ficheiros que cria com ela ou que escolhe para ela. O Google descreve-o como acesso aos ficheiros que abre com uma aplicação ou que o utilizador partilha com uma aplicação enquanto usa a API Google Picker (âmbitos da API Google Drive). O Google classifica-o como um âmbito não sensível.

O que isto significa para si:

• O LightInventory não consegue listar, abrir nem pesquisar o resto do seu Google Drive. Um ficheiro que nunca criou com o LightInventory nem escolheu no seletor de ficheiros do Google é invisível para ele.
• Nunca pedimos o âmbito mais amplo spreadsheets nem qualquer âmbito de acesso a todo o Drive.
• Depois de cada autorização, verificamos se o Google devolveu exatamente o acesso que pedimos.
• Pode remover o acesso em qualquer momento a partir da sua Conta Google. Consulte Revogar o acesso do LightInventory ao Google.

Só a pessoa que liga a folha de cálculo concede este acesso, e essa pessoa tem de ser a proprietária do ficheiro. Os membros da sua equipa nunca são adicionados ao ficheiro no Google. Trabalham através da aplicação, com as funções que lhes atribuir.

Início de sessão e sessões

Todos os utilizadores iniciam sessão com dois fatores, em todos os planos, sempre que uma sessão começa.

1. Primeiro fator: o início de sessão com o Google, ou um e-mail e uma palavra-passe. As palavras-passe têm de ter pelo menos 12 carateres e são verificadas em listas de palavras-passe divulgadas em fugas de dados. O início de sessão com o Google conta apenas como primeiro fator, nunca como ambos.
2. Segundo fator: uma chave de acesso, que é a opção predefinida e resiste ao phishing, ou um código TOTP de uma aplicação de autenticação. Cada utilizador regista pelo menos dois métodos e recebe 10 códigos de recuperação de utilização única.

Para Proprietários e Administradores, o início de sessão resistente ao phishing é obrigatório por predefinição, por isso o TOTP está desativado para essas funções, a menos que o proprietário altere a definição. As chaves de segurança físicas funcionam como chaves de acesso. Uma ligação enviada por e-mail pode repor uma palavra-passe, mas nunca substitui o segundo fator.

A autenticação multifator é verificada em dois locais independentes: no código do nosso servidor e nas próprias regras de acesso da base de dados. Uma sessão que só passou o primeiro fator não consegue ler nada, mesmo que chame diretamente a base de dados.

As ações sensíveis incluem alterações de funções, alterações de faturação, ligar ou desligar uma folha de cálculo, exportações, reversões em massa, alterações aos métodos de início de sessão e a eliminação da organização. Pode ver as suas sessões ativas e terminar qualquer uma delas. Enviamos-lhe um e-mail quando um novo dispositivo inicia sessão, quando um método de início de sessão é adicionado ou removido e quando são usados códigos de recuperação.

Funções, localizações e aprovações

Cada organização tem cinco funções: Proprietário, Administrador, Aprovador, Editor e Leitor. Os Editores e os Leitores podem ser limitados a localizações específicas, para que a equipa de uma loja veja e altere apenas o seu próprio stock.

As permissões são lidas em tempo real em cada pedido, por isso remover alguém ou alterar a sua função produz efeito na ação seguinte dessa pessoa. Todos os pedidos são recusados, a menos que uma regra os permita. Cada função é explicada em Equipa e funções.

As aprovações são opcionais. Quando estão ativadas, uma organização pode exigir aprovação para alterações como edições de preços ou ajustes de stock. A alteração proposta é escrita num separador protegido da sua folha de cálculo, e ninguém pode aprovar o seu próprio pedido. Saiba mais na apresentação do registo de auditoria.

Histórico à prova de adulteração

Cada alteração feita através do LightInventory é escrita como uma entrada de histórico num separador Log protegido dentro da sua folha de cálculo, na mesma atualização do Google que a própria alteração. O stock nunca é editado como um número. É calculado a partir de uma lista de movimentos a que só se acrescentam linhas, e uma reversão é uma entrada nova e oposta, não uma eliminação.

À prova de adulteração significa que, se alguém alterar ou remover uma entrada anterior, a verificação mostra-o. Não significa que a alteração seja impossível. Funciona assim:

• Uma cadeia com chave. Cada entrada recebe um código calculado a partir do seu conteúdo e do código da entrada anterior, com HMAC-SHA256 e uma chave secreta da sua organização que só o LightInventory detém. Alterar uma entrada quebra a cadeia a partir desse ponto. Como a chave é secreta, ninguém consegue recalcular discretamente os códigos depois de uma edição.
• Uma cópia da cadeia, sem valores. Guardamos os códigos da cadeia, nunca os seus valores, numa tabela da base de dados que recusa atualizações e eliminações.
• Âncoras diárias fora da nossa base de dados. Uma vez por dia, uma única impressão digital da posição mais recente da cadeia de cada organização é escrita num bucket do Google Cloud Storage com uma política de retenção bloqueada de 7 anos. Depois de bloqueada, essa política não pode ser encurtada nem removida. Um atacante que conseguisse alterar a nossa base de dados continuaria a não conseguir reescrever essas âncoras.
• Verificação noturna. Todas as noites, e sempre que o proprietário o pedir, recalculamos a cadeia a partir do seu separador Log e comparamo-la com a nossa cópia e com a âncora mais recente. Se algo não corresponder, todos os membros veem um aviso de integridade e o Proprietário e os Administradores recebem um e-mail.

O limite é a propriedade. O proprietário de um ficheiro Google pode sempre editá-lo, desbloqueá-lo, copiá-lo ou eliminá-lo; o Google não permite excluir ninguém disso. A cadeia não consegue impedi-lo, mas torna-o visível. O Google também regista as escritas da nossa aplicação na conta do proprietário, porque escrevemos com a autorização dele. O nosso Log regista o membro da equipa que fez a alteração.

Edições feitas diretamente na folha

Por predefinição, os seus separadores geridos estão protegidos para que só o proprietário os possa editar no Google Sheets, e os editores do ficheiro não o podem partilhar com mais pessoas. Um bloqueio estrito opcional torna o ficheiro só de leitura no Google até o proprietário o desbloquear deliberadamente.

Como o proprietário pode sempre fazer alterações, o LightInventory também as deteta. Sempre que a aplicação lê a sua folha, compara cada linha com a impressão digital guardada. Também é executada uma verificação em segundo plano para as organizações que ninguém está a consultar. Quando uma linha foi alterada fora da aplicação, a aplicação regista-o com a melhor atribuição possível a partir dos dados de revisão do Google e, em seguida, aplica a política da sua organização: bloquear a alteração até um Proprietário ou Administrador a adotar ou restaurar, aceitá-la e registá-la, ou retê-la para aprovação. As edições a movimentos ou entradas de histórico anteriores são sempre assinaladas.

Encriptação e segredos

• Em trânsito: todo o tráfego usa HTTPS. Os navegadores são instruídos a usar apenas HTTPS (HSTS com pré-carregamento), e as nossas páginas usam uma Content Security Policy estrita.
• Em repouso: a nossa base de dados é encriptada em repouso pelo respetivo fornecedor. A sua folha de cálculo é armazenada e encriptada pelo Google.
• Tokens e chaves: os tokens de atualização do Google, os segredos TOTP e as chaves de histórico de cada organização são encriptados com AES-256-GCM, com uma chave nova por registo. Essa chave é, por sua vez, protegida por uma chave mestra no Google Cloud KMS em Londres, que nunca sai do KMS e é rodada todos os anos. O KMS é executado num projeto de nuvem separado, com os seus próprios controlos de acesso, e os nossos servidores acedem-lhe sem qualquer credencial de longa duração armazenada.
• Sem acesso de suporte à sua folha. Não existe nenhuma funcionalidade que permita à nossa equipa iniciar sessão como o utilizador, nem nenhuma ferramenta de suporte que abra a sua folha de cálculo. O acesso à nossa base de dados de produção exige duas pessoas e fica registado.

Infraestrutura e subcontratantes

As API Sheets e Drive do Google processam a sua folha de cálculo enquanto seu próprio fornecedor. Os e-mails que enviamos nunca contêm os seus dados de inventário. No caso dos fornecedores sediados nos EUA, as transferências estão abrangidas pelo Quadro de Privacidade de Dados UE-EUA com a Extensão do Reino Unido, ou por cláusulas contratuais-tipo.

O nosso Acordo de Tratamento de Dados foi concebido para dar aos clientes um aviso prévio de, pelo menos, 30 dias sobre um novo subcontratante e o direito de se oporem. A lista completa de subcontratantes e o acordo serão publicados no lançamento.

Comunicar uma vulnerabilidade

Se encontrar um problema de segurança, envie um e-mail para support@lightinventory.com com os passos para o reproduzir. Pedimos que não aceda a dados de outras pessoas nem perturbe o serviço, e que nos contacte antes de qualquer teste ativo, porque os nossos termos não permitem testes de segurança sem autorização. Os nossos contactos para investigadores de segurança também estão publicados num formato legível por máquina em security.txt. Uma política completa de divulgação responsável será publicada antes do lançamento.

Estado

O LightInventory está a preparar o lançamento. Antes do lançamento, o plano inclui um teste de intrusão externo que abrange o início de sessão, o isolamento entre clientes, a autorização do Google, os webhooks e a injeção em folhas de cálculo, além de uma autoavaliação completa face ao OWASP Application Security Verification Standard 5.0. Esta página vai acrescentar essas avaliações independentes quando existirem. Até lá, descreve a conceção, não uma certificação.

Consulte o que o LightInventory guarda para ver a lista completa, e os preços para saber o que cada plano inclui.