Política de Segurança de Dados

Versão 1.0 · Em vigor desde 5 de fevereiro de 2025

​

1. Objetivo e Escopo

1.1. Esta Política de Segurança de Dados (“Política”) estabelece as diretrizes internas da Tolky Ltda. (“Tolky”) para acesso, manuseio, armazenamento, compartilhamento e descarte de informações, com ênfase nos dados pessoais tratados em nome de nossos clientes.

1.2. Aplica-se a todos os colaboradores, sócios, prestadores de serviço e parceiros com acesso a sistemas, código-fonte, dados ou ambientes da Tolky (“Pessoas Autorizadas”), em qualquer dispositivo ou local de trabalho.

1.3. Em caso de conflito com outros documentos no que diz respeito ao tratamento de dados pessoais, prevalece a interpretação mais protetiva ao titular dos dados.

1.4. Referências normativas: Lei Geral de Proteção de Dados (Lei nº 13.709/2018 — “LGPD”) e boas práticas alinhadas à ISO/IEC 27001. A Tolky mantém um programa interno de gestão de segurança da informação (SGSI) orientado por essa norma, em evolução contínua.

​

2. Princípios

2.1. Menor privilégio: cada pessoa e cada sistema recebe apenas o acesso estritamente necessário à sua função, pelo tempo necessário.

2.2. Necessidade de conhecer: ter permissão técnica de acesso a um dado não autoriza consultá-lo sem justificativa legítima de trabalho.

2.3. Privacidade por padrão: coletamos o mínimo, mascaramos dados sensíveis por padrão e exigimos ação explícita e autorizada para revelá-los.

2.4. Isolamento por desenho: dados de um cliente nunca devem ser visíveis a outro cliente. Todo acesso a dados é vinculado ao escopo da credencial utilizada.

2.5. Defesa em profundidade: nenhum controle é único; autenticação, permissão, escopo de tenant e auditoria se sobrepõem.

2.6. Responsabilização: ações administrativas relevantes devem ser registradas e atribuíveis a uma pessoa ou sistema identificado.

​

3. Classificação da Informação

3.1. Toda informação tratada pela Tolky enquadra-se em uma das classes abaixo, que determina o rigor do manuseio:

Classe	Descrição	Exemplos
Pública	Aprovada para divulgação externa	Site, documentação pública, materiais de marketing
Interna	Uso interno; divulgação causa dano limitado	Processos internos, roadmaps, métricas agregadas
Confidencial	Divulgação causa dano relevante à Tolky ou a clientes	Código-fonte, configurações, contratos, credenciais e tokens
Dados Pessoais	Informação relativa a pessoa natural identificada ou identificável (LGPD)	Nome, telefone, e-mail, CPF/CNPJ, conteúdo de conversas, áudios, documentos e mídias enviados por usuários finais

3.2. Dados pessoais sensíveis (LGPD, art. 5º, II) e documentos de identificação recebem o tratamento mais restritivo previsto nesta Política, incluindo mascaramento por padrão (ver seção 7).

3.3. Na dúvida, trate a informação como Confidencial.

​

4. Papéis e Responsabilidades

4.1. Direção: patrocina esta Política, provê recursos e aprova exceções de maior risco.

4.2. Responsável pela Segurança da Informação: mantém esta Política, coordena a resposta a incidentes, conduz revisões de acesso e o programa SGSI.

4.3. Engenharia: implementa e mantém os controles técnicos; segue as práticas de desenvolvimento seguro da seção 11.

4.4. Atendimento, Implementação e Comercial: acessam dados de clientes somente no contexto de suporte ou operação contratada, com necessidade justificada.

4.5. Todas as Pessoas Autorizadas: conhecem esta Política, protegem suas credenciais e reportam imediatamente qualquer suspeita de incidente (seção 14).

​

5. Controle de Acesso

5.1. O acesso à plataforma é organizado em camadas derivadas automaticamente da credencial utilizada — do acesso administrativo interno da Tolky, passando pelo escopo de domínio (white-label) e de host (cliente), até a camada conversacional do usuário final. Uma credencial não permite elevação para camada superior.

5.2. Dentro do painel de gestão, o acesso é regido por papéis de sistema e permissões granulares por funcionalidade, com escopo por host e por avatar. Ações sensíveis — como revelar dados criptografados, exportar bases, gerenciar usuários ou limpar históricos — exigem permissões específicas.

5.3. Acessos administrativos globais (camada Admin) são restritos à equipe interna da Tolky, concedidos individualmente e utilizados apenas para operação, suporte e diagnóstico.

5.4. Concessão de acesso segue o menor privilégio: o papel padrão é o mais restritivo, e ampliações exigem justificativa.

5.5. Os acessos de colaboradores e prestadores são revisados periodicamente (no mínimo a cada seis meses) e revogados imediatamente no desligamento ou término de contrato, incluindo contas de plataforma, e-mail, repositórios, nuvem e ferramentas auxiliares.

5.6. Contas são pessoais e intransferíveis. É vedado compartilhar contas ou credenciais, inclusive entre membros da mesma equipe.

5.7. Clientes podem suspender ou banir usuários de seus ambientes; bloqueios têm efeito imediato na plataforma.

​

6. Autenticação e Credenciais

6.1. Senhas devem ter no mínimo 8 caracteres (recomendado 12 ou mais), ser únicas por serviço e gerenciadas por um gerenciador de senhas. É vedado reutilizar senhas pessoais em serviços corporativos.

6.2. A autenticação multifator (MFA) é obrigatória em todos os serviços corporativos que a suportem — e-mail, repositórios de código, provedores de nuvem e ferramentas administrativas.

6.3. Onde disponível, o acesso deve ocorrer por SSO corporativo (Google ou Microsoft). Para clientes do setor público, a plataforma suporta autenticação federada dedicada (por exemplo, SSO PDPJ e Azure AD).

6.4. Tokens de API são segredos. Devem ser transmitidos exclusivamente via cabeçalho Authorization sobre HTTPS, e nunca podem aparecer em código-fonte, repositórios, front-ends, URLs, logs, tickets, chats ou capturas de tela. Tokens devem ser rotacionados periodicamente e imediatamente em caso de suspeita de exposição.

6.5. É vedado embutir qualquer credencial em código-fonte ou arquivos versionados, mesmo em repositórios privados (ver seção 8).

​

7. Criptografia

7.1. Em trânsito: todo o tráfego externo da plataforma ocorre sobre TLS (HTTPS), com redirecionamento forçado e certificados gerenciados automaticamente.

7.2. Em repouso: bancos de dados e armazenamento de objetos utilizam a criptografia em repouso dos provedores de infraestrutura.

7.3. Criptografia de campo: dados sensíveis capturados em conversas e formulários podem ser criptografados individualmente com AES-256-GCM antes da gravação. Na interface, esses valores aparecem mascarados por padrão; a revelação exige permissão específica, ocorre sob demanda e deve ser registrada.

7.4. As chaves de criptografia residem exclusivamente em variáveis de ambiente ou cofres de segredos — nunca no banco de dados ou no código. A plataforma suporta re-criptografia (rotação de chave) dos valores protegidos.

7.5. Valores revelados (descriptografados) herdam a classificação Dados Pessoais: não devem ser copiados para anotações, chats ou arquivos fora dos sistemas autorizados, e caches locais de revelação devem ser limpos ao final da sessão de trabalho.

​

8. Gestão de Segredos

8.1. Segredos (senhas, chaves de API, tokens, certificados, chaves privadas) nunca são versionados: arquivos .env, chaves e certificados ficam fora do controle de versão, e os repositórios mantêm regras de exclusão para esses padrões.

8.2. Em produção, segredos são provisionados por mecanismos dedicados do ambiente de orquestração (secrets), separados das configurações não sensíveis. Modelos de configuração versionados contêm apenas nomes de variáveis, nunca valores reais.

8.3. Cada ambiente (produção, homologação, desenvolvimento) usa segredos próprios. É vedado reutilizar segredos de produção em ambientes de teste ou desenvolvimento.

8.4. Cada credencial deve ter o menor escopo possível (por serviço, por ambiente, por função).

8.5. A exposição acidental de um segredo — em commit, log, print ou mensagem — é um incidente de segurança: o segredo deve ser rotacionado imediatamente, a exposição removida (incluindo histórico do repositório, quando aplicável) e o evento registrado conforme a seção 14.

​

9. Ciclo de Vida dos Dados

9.1. Coleta mínima: a plataforma e as equipes coletam apenas os dados necessários à finalidade contratada pelo cliente.

9.2. Uso restrito: dados de clientes e de usuários finais são usados exclusivamente para operar, suportar e melhorar o serviço contratado, conforme os Termos de Uso e a Política de Privacidade.

9.3. Retenção: dados operacionais têm janelas de retenção definidas por tipo — por exemplo, eventos de navegação de visitantes são retidos por até 180 dias e registros operacionais de log por períodos de 15 a 90 dias, com expurgo automático. Dados de conversas, leads e conteúdo dos clientes são mantidos enquanto vigorar o contrato ou conforme instrução do cliente controlador.

9.4. Governança de logs: toda nova coleção de registros operacionais deve declarar sua política de retenção antes de entrar em produção; coleções sem política declarada são sinalizadas em auditoria automática.

9.5. Exportações: relatórios e exportações (CSV/planilhas) são protegidos por permissões específicas. O arquivo exportado herda a classificação dos dados que contém: deve ser armazenado apenas em locais corporativos autorizados, nunca em dispositivos ou serviços pessoais, e excluído assim que cumprida sua finalidade.

9.6. Ambientes de teste: é vedado copiar dados reais de clientes para ambientes de desenvolvimento ou teste. Use dados fictícios ou anonimizados.

9.7. Descarte: ao término do contrato ou mediante solicitação do cliente controlador, os dados são excluídos ou devolvidos conforme o acordado, respeitadas obrigações legais de guarda.

​

10. Registros e Auditoria

10.1. Ações administrativas relevantes no painel — criação, alteração e exclusão de registros, convites e mudanças de permissão — são registradas com autor, data e contexto, e ficam disponíveis para consulta pelos gestores do cliente.

10.2. Logs de aplicação não devem conter dados pessoais em claro. Identificadores como CPF, telefone e e-mail devem ser mascarados ou omitidos; conteúdo de conversas não deve ser replicado em logs técnicos.

10.3. Canais internos de alerta e monitoramento (notificações de erro, alertas operacionais) não devem receber conteúdo de conversas nem dados pessoais de usuários finais.

10.4. Registros de auditoria seguem as janelas de retenção da seção 9.3 e são protegidos contra alteração pelas mesmas regras de acesso desta Política.

​

11. Desenvolvimento Seguro

11.1. Todo código passa por revisão em pull request antes de chegar à produção; mudanças com impacto em autenticação, permissões ou tratamento de dados pessoais recebem atenção redobrada na revisão.

11.2. Toda rota nasce autenticada e com escopo de tenant (fail-closed). Exceções — como webhooks públicos de integrações — devem ser explícitas, documentadas e acompanhadas de controles compensatórios (validação de origem ou assinatura, deduplicação e limitação de frequência).

11.3. Toda consulta a dados filtra pelo tenant (host ou domínio) da credencial. Resultados de outro cliente nunca devem ser alcançáveis, independentemente dos parâmetros enviados.

11.4. Entradas externas são validadas nas bordas do sistema; consultas ao banco usam parâmetros vinculados (nunca concatenação de valores de usuário).

11.5. Dependências de terceiros são monitoradas por alertas automatizados de vulnerabilidade e atualizadas com prioridade proporcional à severidade.

11.6. Ferramentas de IA usadas no desenvolvimento não devem receber segredos nem dados pessoais de clientes em prompts, salvo ferramentas aprovadas e configuradas para isso.

​

12. Terceiros e Subprocessadores

12.1. A operação da plataforma utiliza subprocessadores em categorias definidas: infraestrutura de nuvem e banco de dados, provedores de modelos de IA, provedores de canais de mensagem (por exemplo, WhatsApp Business Platform e BSPs), envio de e-mail, voz e análise de produto.

12.2. Subprocessadores só são contratados com compromissos contratuais de proteção de dados compatíveis com a LGPD e com esta Política, e recebem apenas o mínimo de dados necessário à sua função.

12.3. Transferências internacionais de dados podem ocorrer para subprocessadores localizados fora do Brasil, sempre amparadas nas salvaguardas do art. 33 da LGPD.

12.4. A análise de uso do produto (analytics) é configurada para não coletar conteúdo de conversas, gravações de sessão nem dados pessoais de usuários finais dos clientes.

12.5. A inclusão de um novo subprocessador com acesso a dados pessoais exige avaliação prévia registrada pelo Responsável pela Segurança da Informação.

​

13. Estações de Trabalho e Conduta

13.1. Dispositivos usados para o trabalho devem ter disco criptografado, bloqueio automático de tela, sistema operacional e navegador atualizados.

13.2. Bloqueie a tela ao se ausentar. Não visualize dados de clientes em locais públicos sem proteção de tela.

13.3. Desconfie de mensagens que solicitem credenciais ou instalem software (“phishing”); na dúvida, não clique e reporte.

13.4. É vedado armazenar dados de clientes em dispositivos pessoais, e-mails pessoais ou serviços de nuvem não corporativos.

13.5. Em redes públicas ou não confiáveis, o acesso a sistemas internos deve ocorrer somente por conexões seguras (HTTPS/VPN).

​

14. Gestão de Incidentes de Segurança

14.1. Incidente é qualquer evento que comprometa — ou possa comprometer — a confidencialidade, integridade ou disponibilidade de dados ou sistemas. Exemplos: exposição de segredo, acesso indevido, vazamento de dados pessoais, perda de dispositivo com dados corporativos, comportamento anômalo de sistemas.

14.2. Reporte imediato: qualquer Pessoa Autorizada que suspeitar de um incidente deve comunicá-lo de imediato ao Responsável pela Segurança da Informação e a contato@tolky.to. Reportes de boa-fé nunca geram punição — inclusive quando o próprio autor causou o evento.

14.3. Resposta padrão: conter (revogar acessos, rotacionar segredos afetados, isolar sistemas), preservar evidências (logs e registros), avaliar o impacto sobre dados pessoais e clientes, corrigir a causa e registrar todo o ocorrido.

14.4. Incidentes com dados pessoais que possam acarretar risco ou dano relevante aos titulares são comunicados aos clientes controladores afetados e, quando exigido, à ANPD e aos titulares, nos prazos da regulamentação vigente (art. 48 da LGPD).

14.5. Todo incidente relevante gera uma análise pós-incidente sem atribuição de culpa, com ações corretivas rastreadas até a conclusão.

​

15. Direitos dos Titulares de Dados

15.1. Solicitações de titulares (acesso, correção, exclusão, portabilidade, informação sobre tratamento) recebidas pela Tolky são registradas e tratadas com prioridade pelo canal contato@tolky.to.

15.2. Quando a Tolky atua como operadora, a solicitação é encaminhada sem demora ao cliente controlador dos dados, a quem cabe a decisão, com o apoio técnico da Tolky para executá-la (localização, correção ou exclusão dos dados na plataforma).

15.3. As solicitações e suas conclusões são registradas para fins de prestação de contas.

​

16. Conformidade, Exceções e Revisão

16.1. O descumprimento desta Política sujeita colaboradores e prestadores a medidas disciplinares e contratuais, sem prejuízo das responsabilidades legais.

16.2. Exceções a qualquer item exigem aprovação registrada do Responsável pela Segurança da Informação, com justificativa, prazo de validade e controles compensatórios.

16.3. Esta Política é revisada ao menos uma vez por ano, e adicionalmente após incidentes relevantes ou mudanças materiais na plataforma, na legislação ou nos subprocessadores.

16.4. Dúvidas sobre esta Política: contato@tolky.to.

​

Histórico de Versões

Versão	Data	Alterações
1.0	05/02/2025	Publicação inicial