Políticas internas

Versão 1.0 · 23 de julho de 2026 · revisão anual

1. Política de segurança da informação

Objetivo. Proteger a confidencialidade, a integridade e a disponibilidade dos dados que clientes confiam ao Proximia.

Alcance. Toda pessoa com acesso a sistemas de produção, ao repositório de código ou a dados de cliente, seja empregada, sócia ou prestadora.

Princípios que governam as decisões técnicas:

• Isolamento no banco, não na aplicação. Nenhuma tela nova pode depender de filtro em código para separar um cliente de outro.
• Menor privilégio por padrão. Função nova nasce sem permissão de execução; concede-se por nome e por motivo, e há teste que trava esse estado.
• Dado de cliente não sai. Qualquer integração que envie conteúdo da operação a um terceiro exige decisão registrada, interruptor por organização desligado por padrão e registro de cada envio.
• Falha barulhenta. Entre falhar silenciosamente e recusar a operação com mensagem clara, recusa-se.

Responsável. A direção da Produtize responde pela política. Revisão anual, ou a qualquer momento após incidente relevante.

2. Política de controle de acesso

Concessão. Acesso a sistemas de produção é concedido pela direção, individualmente e pelo menor privilégio necessário à função. Não há credencial compartilhada entre pessoas.

Autenticação. Verificação em duas etapas é obrigatória para todo acesso administrativo à plataforma, ao provedor de banco de dados e ao provedor de hospedagem.

Chaves de serviço. A chave de privilégio elevado do banco existe apenas como variável de ambiente no servidor. Nunca é versionada, nunca vai ao navegador e é rotacionada em caso de suspeita de exposição.

Revisão. Trimestral, com registro do que foi revisado e do que foi revogado.

Saída. Acesso revogado no mesmo dia útil do desligamento, em todos os sistemas, com registro.

Acesso a dados de cliente. A equipe da plataforma tem acesso à assinatura e ao uso agregado, e não à operação — carteiras, contas, contratos e histórico. Acesso ao conteúdo de um cliente só ocorre mediante solicitação dele, para suporte, e é registrado.

3. Plano de resposta a incidentes

O que é incidente. Acesso não autorizado a dado de cliente, indisponibilidade acima de quatro horas, perda de dado, ou exposição de credencial.

Primeiras horas:

• Conter — revogar credencial, suspender chave, isolar o caminho de entrada.
• Registrar — o que aconteceu, quando começou, como foi descoberto, o que se sabe e o que ainda não se sabe.
• Avaliar alcance — quais organizações, quais dados, se houve acesso efetivo ou apenas possibilidade.
• Comunicar — clientes afetados em até 48 horas da confirmação, com o que se sabe até ali, mesmo que incompleto.

Dados pessoais. Havendo risco relevante aos titulares, comunicação à ANPD e aos titulares conforme a LGPD, em prazo razoável a contar da ciência.

Depois. Registro do que causou, do que foi corrigido e do que muda para não repetir — publicado ao cliente afetado. Correção de causa vira teste automatizado sempre que possível.

Canal. seguranca@proximia.com.br, com resposta em até dois dias úteis.

4. Política de gestão de mudanças

Verificação obrigatória. Nenhuma alteração vai a produção sem passar por checagem de tipos, suíte de testes automatizados e compilação. A verificação roda a cada alteração e falha bloqueia a publicação.

Alterações de banco. Versionadas em arquivos numerados e sequenciais. Arquivo já aplicado nunca é editado — correção é arquivo novo. Cada um carrega verificação final que falha se o estado resultante não for o esperado.

Regras que exigem teste. Toda regra nova de acesso ou isolamento entra acompanhada de teste que tenta violá-la e verifica o efeito da tentativa.

Reversão. Publicação anterior permanece disponível na hospedagem e pode ser restaurada. Alterações de banco são projetadas para não destruir dado.

5. Plano de continuidade e recuperação

Cópias de segurança. Automáticas e contínuas na infraestrutura de banco, com retenção conforme o plano contratado com o provedor.

Teste de restauração. Executado e cronometrado ao menos uma vez por ano, com registro do tempo e do resultado. O procedimento de restauração está documentado internamente.

Objetivos declarados. Recuperação em até quatro horas; perda máxima aceitável de vinte e quatro horas de dado. São objetivos operacionais; o compromisso contratual é o dos Para desenvolvedores Termos de uso.

Saída de dados sem depender de nós. A exportação completa em CSV e JSON está na interface e não exige nossa participação — é a continuidade que o cliente controla.

Dependência de fornecedor único. Reconhecida: banco e hospedagem estão concentrados. O formato é PostgreSQL padrão, sem recurso proprietário que impeça a migração, mas uma troca exigiria trabalho e não é instantânea.

6. Política de gestão de fornecedores

Critério. Fornecedor que toca dado de cliente precisa de contrato aceito, acordo de tratamento de dados quando aplicável e localização de dados conhecida.

Registro. A lista completa de terceiros que participam do serviço é pública, na página de segurança, com o que cada um recebe.

Fornecedor novo que receba dado de cliente exige decisão registrada antes da adoção, com a pergunta explícita: o que sai daqui, e isso contradiz o que prometemos?

Revisão anual da lista e das condições contratadas.

7. O que estas políticas ainda não cobrem