Entrar

2026-06-27

Guardar os dados no drive do cliente: a filosofia de design da retenção mínima de dados

Como reduzir o risco de vazamento de informações de um SaaS corporativo.

Explicamos a abordagem de design de manter os dados do lado do cliente e minimizar a retenção no servidor.

Quanto mais se acumula, maior o risco

Quanto mais dados de clientes você acumula nos servidores do provedor do serviço, maior o dano em caso de ataque.

Em contrapartida, se reduz os dados que ficam no servidor, o alcance do impacto em caso de incidente diminui de forma estrutural.

Quanto menos há para proteger, mais simples é a proteção e menos chances há de falhas na verificação.

O ponto de partida é perguntar, no início do desenho, “realmente precisa ficar no servidor?”.

Os dados, no drive do cliente

Se o destino final do relatório diário é uma planilha dentro do próprio Google Drive da empresa que o utiliza, ou seja, a sua, a gestão dos dados volta ao cliente.

O provedor apenas repassa e não faz guarda de longo prazo.

O cliente decide por conta própria quem pode ver, pelas configurações de acesso da sua empresa, e mesmo ao encerrar o contrato os dados continuam em suas mãos.

Um desenho que não toma os dados como refém também traz tranquilidade na adoção.

Delimitar no tempo a retenção no servidor

O servidor guarda apenas os dados temporários do envio até a aprovação. Eles são apagados imediatamente na aprovação.

Se não forem aprovados, deixam de ser acessíveis após 24 horas.

Depois são apagados automaticamente, no mais tardar no dia seguinte, pela exclusão programada diária.

Poder afirmar com clareza que “fica acessível no máximo 24 horas e some, no mais tardar, no dia seguinte” facilita a aprovação na análise de quem vai adotar.

O importante aqui é que a exclusão funcione automaticamente, sem depender de uma ação humana, e que o limite de retenção possa ser explicado em palavras.

Um vago “apagamos o quanto antes” não permite a quem analisa tomar uma decisão.

Apagar, por si só, não basta

A retenção mínima é poderosa, mas não torna tudo seguro por si só.

Há o básico — criptografia da comunicação, separação de permissões de escrita e registro das operações.

Só junto com esse básico chega-se a um estado em que se pode usar com tranquilidade. Por exemplo, pense em conjunto em três pontos.

Ninguém de fora lê os dados enquanto estão guardados. O destino de escrita se limita ao necessário. É possível rastrear depois o que aconteceu.

Isso reduz as lacunas.

Exemplos de perguntas a confirmar antes de adotar

Quem considera adotar pode, como referência, fazer estas perguntas ao provedor.

“Onde estão os dados de fato?”, “Até quando, no máximo, ficam no servidor?”, “A exclusão é automática ou manual?”, “Se eu quiser retirar a permissão, qual é o procedimento?”.

Quanto mais concretas as respostas e quanto mais puderem ser explicadas como mecanismo, mais fácil julgar que o desenho está bem organizado.

Ao contrário, se a resposta depende do cuidado da pessoa responsável pela operação, esse é um ponto que tende a ser frágil.

Por fim, confirme também se a explicação do desenho existe por escrito; isso ajuda nas aprovações internas e nas revisões.

Uma lista das ferramentas de trabalho e do dia a dia criadas pela mesma empresa. Norolu Works(abre em uma nova aba) Como escrever OKRs(abre em uma nova aba)

Uma ferramenta para uma cultura de melhoria e avaliação fundamentada que coloca essas ideias em prática.