Política de Segurança da Informação — TemploCERC

Última atualização: 3 de outubro de 2026 · Classificação: Pública

1. Objetivo

Proteger informação, sistemas, aplicação, dado pessoal e ativo de usuário contra acesso não autorizado, destruição, perda, alteração, indisponibilidade, divulgação indevida e uso incompatível.

2. Abrangência

Aplica-se ao site institucional, à aplicação (*.templocerc.com.br e subdomínios dev/hmg), API, ambientes de desenvolvimento/homologação/produção, dado pessoal de usuário e dado de negócio. Sistemas de terceiro (Supabase, Infinity Pay/CloudWalk, Resend, Google, Vercel) seguem a política de segurança própria de cada fornecedor — fora da responsabilidade direta desta política, mas considerados na avaliação de risco (ver seção 5.6).

3. Princípios

• Confidencialidade: acesso à informação só por pessoa, sistema e fornecedor autorizado.
• Integridade: proteção contra alteração não autorizada ou uso indevido.
• Disponibilidade: medida razoável para manter o acesso ao serviço.
• Necessidade: tratamento com o mínimo de acesso/dado necessário.
• Prevenção: identificação de risco antes e durante a operação.
• Responsabilização: registro, revisão, resposta e melhoria contínua.
• Proporcionalidade: controle ajustado ao risco e à capacidade operacional do estágio atual (piloto).

4. Governança e responsabilidades

METADAX (responsável técnica pelo desenvolvimento e segurança da aplicação):

• Aprovar diretrizes e alocar recurso proporcional ao risco.
• Coordenar a implementação dos controles desta política.
• Gerenciar vulnerabilidade e resposta a incidente técnico.
• Comunicar o Operador da Plataforma e, quando aplicável, a autoridade competente.

Operador da Plataforma (Ilê Àṣẹ Odé Omi Afẹ́fẹ́ / Templo de Cipriano e Rosa Caveira — TemploCERC):

• Definir finalidade e base legal do tratamento de dado (decisão de negócio, não técnica).
• Comunicar titular afetado quando exigido pela LGPD.

Usuário (qualquer papel):

• Usar apenas o acesso autorizado para seu papel.
• Proteger credencial e dispositivo.
• Reportar incidente e vulnerabilidade pelo canal da seção 10.
• Não copiar, extrair ou tentar acessar dado fora do que seu papel permite.

5. Controles de segurança

5.1 Gestão de acesso

Autenticação (Supabase Auth, com segundo fator por e-mail), separação de privilégio por papel (RBAC), revisão periódica e revogação de acesso. Credencial não deve ser compartilhada nem armazenada em local inseguro; chave, token, senha e segredo são protegidos e substituídos em caso de suspeita de comprometimento.

5.2 Desenvolvimento e mudanças

Segurança considerada desde o planejamento. Nível de teste e revisão proporcional ao risco da funcionalidade (ex.: fluxo de pagamento recebe revisão mais rigorosa que conteúdo institucional estático).

5.3 Atualização e vulnerabilidade

Dependência mantida em versão suportada. Correção priorizada por criticidade, exposição, explorabilidade e impacto. Nenhuma frase desta política representa certificação, auditoria independente ou garantia de ausência de vulnerabilidade.

5.4 Proteção de dado e criptografia

• RLS (Row Level Security) habilitada em 100% das tabelas com dado de usuário.
• Criptografia de coluna para CPF/CNPJ, chave Pix e nome de usuário de pagamento.
• Trilha de auditoria (append-only) para acesso a prontuário e dado sensível.
• Dado de cartão de pagamento nunca toca a nossa infraestrutura — fica só no checkout tokenizado da Infinity Pay.
• Arquivo enviado pelo templeadmin (imagem, PDF, áudio) fica num bucket do Supabase Storage com controle de acesso por templo — cada gestor só escreve na própria pasta.

5.5 Backup e continuidade

RTO, RPO e plano de continuidade formal só se aplicam quando expressamente contratados para o estágio atual (piloto). Existência de backup não garante recuperação completa automática.

5.6 Fornecedores

Fornecedor crítico (Supabase, Infinity Pay, Resend, Google, Vercel) avaliado por função, nível de acesso, tipo de dado e risco antes da adoção.

6. Classificação da informação

Classificação	Exemplo	Tratamento
Pública	Conteúdo institucional, biblioteca de pontos	Divulgação livre
Interna	Processo operacional, documentação de arquitetura	Restrita a pessoa autorizada
Restrita	Credencial, chave, dado sensível, incidente não divulgado	Acesso excepcional, proteção reforçada
Confidencial	Contrato, dado financeiro de usuário, código não publicado	Acesso mínimo, proteção adicional

7. Eventos, vulnerabilidade e incidente

• Vulnerabilidade: fragilidade que pode permitir acesso não autorizado, alteração, indisponibilidade, exposição ou outro impacto.
• Evento de segurança: ocorrência observada ou suspeita que afete segurança (ex. tentativa de acesso, alerta, falha, indisponibilidade, código malicioso, comportamento anômalo, denúncia de terceiro).
• Incidente de segurança: evento confirmado que compromete ou pode comprometer confidencialidade, integridade, disponibilidade ou autenticidade de informação ou sistema.

8. Processo de resposta a incidente

1. Recebimento e registro.
2. Triagem e classificação.
3. Contenção e preservação de evidência.
4. Investigação e avaliação de impacto.
5. Comunicação interna e contratual.
6. Correção, recuperação e monitoramento.
7. Comunicação regulatória e ao titular, quando aplicável.
8. Lição aprendida e melhoria de controle.

9. Retenção de registro de incidente

Registro mantido incluindo data de conhecimento, circunstância, dado afetado, titular, avaliação de risco, medida de correção e comunicação feita. Retenção mínima de 5 anos para incidente regulado, conforme regulamentação da ANPD.

10. Divulgação responsável de vulnerabilidade

Canal preferencial: [email protected]

10.1 Escopo

Apenas ativo controlado pela plataforma (*.templocerc.com.br e subdomínios) em produção/homologação/desenvolvimento. Ativo de terceiro (Supabase, Infinity Pay, Resend, Google, Vercel) está fora de escopo — reporte ao responsável pelo próprio fornecedor, sem testar sem autorização.

10.2 Regras obrigatórias

O pesquisador deve:

1. Agir de boa-fé, de forma responsável e dentro do escopo.
2. Evitar degradação de serviço, DoS/DDoS, spam, engenharia social, phishing ou acesso físico.
3. Não acessar, copiar, alterar, apagar, divulgar ou extrair dado real além do mínimo necessário para demonstrar a falha.
4. Interromper o teste e comunicar imediatamente se encontrar dado pessoal, credencial, segredo ou acesso de terceiro durante a investigação.
5. Não testar pessoa, funcionário, cliente, fornecedor ou ativo fora de escopo.
6. Não instalar persistência, malware ou backdoor.
7. Não divulgar a vulnerabilidade publicamente antes de coordenação razoável.
8. Apagar ou devolver evidência quando solicitado, exceto retenção legalmente exigida.

10.3 Conteúdo do reporte

Título, descrição, ativo afetado, passo de reprodução, impacto, evidência mínima, classificação de severidade, data e contato seguro.

10.4 Porto seguro limitado

Nos limites da lei, não buscaremos responsabilizar pesquisador que agir de boa-fé, dentro do escopo, por método autorizado e em conformidade com esta política. Isso não autoriza acesso a ativo de terceiro, não concede imunidade perante terceiro, e não substitui autorização de cliente, fornecedor ou titular de dado envolvido.

10.5 Recompensa

Não há programa de recompensa financeira formal nesta fase — sem garantia de pagamento ou reconhecimento por reporte, embora relatos de boa-fé sejam sempre bem-vindos.

11. Tratamento de dado do pesquisador

Dado do pesquisador usado apenas para receber, validar, investigar, corrigir e documentar a vulnerabilidade — nunca para marketing.

12. Auditoria e cooperação

Registro de acesso, mudança, incidente, risco e decisão de segurança mantido pelo período necessário à segurança, auditoria, contrato e obrigação legal.

13. Continuidade e recuperação

Procedimento proporcional à natureza da operação. Continuidade depende de dependência de terceiro (provedor de nuvem, gateway de pagamento, API, internet, energia) — não há garantia de disponibilidade contínua além do que estiver expressamente contratado.

14. Exceções e revisão

Exceção exige justificativa, aprovação competente, prazo/escopo definido e medida compensatória. Revisão periódica ou mediante mudança relevante de serviço, risco, incidente, fornecedor ou legislação.

15. Canais de contato

• Segurança e vulnerabilidade: [email protected]
• Privacidade e direitos do titular: ver Política de Privacidade
• Incidente contratual: canal definido em contrato/SLA específico, quando houver

Aviso: não envie credencial, chave privada, dado de saúde, dado pessoal sensível ou informação confidencial por formulário ou e-mail sem orientação prévia.

16. Relação com outros documentos

Deve ser lida em conjunto com a Política de Privacidade e os Termos e Condições de Uso. Em caso de conflito, prevalece a legislação vigente.

17. Referências legais

Regulamento CD/ANPD nº 15/2024 (comunicação de incidente de segurança) · Lei nº 13.709/2018 (LGPD) · Resolução CD/ANPD nº 2/2022 (agente de pequeno porte) · Guia da ANPD sobre segurança da informação para agente de pequeno porte · Lei nº 12.965/2014 (Marco Civil da Internet).