Política de Segurança Cibernética

1. Objetivo

Esta Política estabelece as diretrizes de segurança da informação aplicadas à operação do Abdala Mail e serve de referência para clientes, parceiros e pesquisadores que precisem compreender nossos controles.

O documento descreve a postura de segurança adotada e não substitui contratos específicos, acordos de nível de serviço ou obrigações legais aplicáveis a cada operação.

2. Escopo

Esta Política abrange o site institucional, o painel administrativo, o webmail, os servidores de mensagens, as filas de processamento, os bancos de dados, os serviços auxiliares, os ambientes de desenvolvimento e homologação e os dispositivos utilizados pela equipe para operar a plataforma.

3. Princípios

A segurança do Abdala Mail é orientada por defesa em camadas, menor privilégio possível, segregação de funções, negação por padrão, registro auditável de operações sensíveis e redução da superfície exposta.

Nenhum controle isolado é tratado como suficiente. A falha de uma camada deve encontrar outra camada capaz de conter ou detectar o evento.

4. Governança

A responsabilidade pela segurança da informação é atribuída à equipe técnica responsável pela operação, com revisão periódica das regras, dos acessos concedidos e dos incidentes registrados.

Mudanças relevantes em arquitetura, provedores ou controles passam por análise prévia de risco antes de entrar em produção.

5. Classificação de dados

Tratamos como dados de maior sensibilidade o conteúdo de mensagens, credenciais, material criptográfico, registros de autenticação e documentos fiscais. Cada categoria possui regras próprias de acesso, retenção e registro.

6. Criptografia em trânsito

As conexões com o site, o painel, o webmail e as APIs utilizam TLS com conjuntos de cifras atuais. Protocolos e cifras considerados obsoletos são desabilitados assim que deixam de ser necessários à interoperabilidade.

O acesso por HTTP simples é redirecionado para conexão protegida, e cabeçalhos de segurança são aplicados para reduzir risco de rebaixamento de protocolo.

7. Entrega de mensagens e TLS oportunista

O envio e o recebimento de mensagens entre servidores utilizam TLS sempre que o servidor remoto oferece suporte. Publicamos e mantemos registros que sinalizam a exigência de conexão protegida para quem nos envia mensagens.

A entrega entre servidores depende da configuração do provedor remoto. Quando o servidor de destino não oferece conexão protegida, a mensagem pode trafegar sem criptografia de transporte fora da nossa infraestrutura.

8. Criptografia em repouso

Volumes de armazenamento e cópias de segurança utilizam criptografia em repouso. As chaves de volume são administradas separadamente dos dados e o acesso a elas é restrito a procedimentos operacionais específicos.

A criptografia em repouso protege contra acesso ao meio físico e não substitui a criptografia de conhecimento zero disponível nos planos Advanced Security.

9. Criptografia de conhecimento zero

Nos planos Advanced Security, o conteúdo é armazenado cifrado com chave pública do cliente, e a chave privada correspondente permanece sob controle exclusivo do cliente. Nessa configuração, a equipe do Abdala Mail não consegue decifrar o conteúdo armazenado.

As consequências e limites desse modelo, incluindo a irrecuperabilidade do conteúdo em caso de perda da chave privada, estão descritos na Política do Advanced Security.

10. Senhas

Senhas de contas são armazenadas com função de derivação adequada a senhas, com sal por credencial. Senhas não são gravadas deliberadamente em texto simples, em registros de aplicação ou em mensagens de suporte.

A plataforma aplica requisitos mínimos de complexidade e rejeita senhas presentes em listas públicas de credenciais vazadas.

11. Autenticação multifator

A autenticação multifator está disponível para contas de usuário e para contas administrativas. Recomendamos o uso de aplicativo gerador de códigos temporários ou de chave de segurança física.

Códigos de recuperação devem ser guardados fora do serviço. A perda simultânea de senha, segundo fator e códigos de recuperação pode impedir a recuperação da conta.

12. Sessões e tokens

Sessões possuem prazo de validade, são vinculadas a contexto técnico e podem ser encerradas remotamente pelo titular ou por administradores da organização.

Tokens de aplicação e senhas de aplicativo possuem escopo restrito, são revogáveis individualmente e são invalidados quando a credencial principal é alterada.

13. Proteção contra ataques de autenticação

Aplicamos limites de tentativas, atrasos progressivos, bloqueio temporário de origem e análise de padrões compatíveis com preenchimento automatizado de credenciais.

Acessos com indícios de comprometimento podem gerar alerta ao titular, exigência de reautenticação ou suspensão preventiva da sessão.

14. Controle de acesso interno

O acesso de integrantes da equipe a sistemas de produção é concedido por função, limitado ao necessário para a atividade exercida e revisado periodicamente.

Acesso administrativo exige autenticação multifator e ocorre por canais controlados, com registro das operações realizadas.

15. Acesso a caixas de clientes

A equipe não acessa o conteúdo de caixas de clientes para fins rotineiros. Procedimentos de suporte são conduzidos com base em metadados operacionais, registros de entrega e informações fornecidas pelo próprio cliente.

Acesso excepcional destinado à resolução de incidente técnico depende de autorização expressa do cliente ou de ordem legal válida, e fica registrado.

16. Segregação de ambientes

Ambientes de desenvolvimento, homologação e produção são separados. Dados reais de clientes não são utilizados em ambientes de teste, e conjuntos de dados sintéticos ou anonimizados são empregados quando necessário.

17. Gestão de segredos

Credenciais de serviço, chaves de API e certificados são armazenados em repositório apropriado, com acesso restrito e rotação periódica. Segredos não são versionados em código-fonte.

A suspeita de exposição de um segredo aciona rotação imediata e verificação de uso indevido.

18. Desenvolvimento seguro

Alterações de código passam por revisão por outra pessoa, execução de testes automatizados e verificação de dependências antes da publicação.

Entradas recebidas de usuários são validadas no servidor, consultas a banco utilizam parametrização e saídas apresentadas em interface são tratadas para evitar execução de conteúdo não confiável.

19. Dependências de terceiros

Bibliotecas e imagens de contêiner utilizadas na plataforma são acompanhadas quanto a vulnerabilidades conhecidas. Correções de segurança relevantes são priorizadas conforme a gravidade e a exposição.

20. Gestão de vulnerabilidades

Realizamos verificação periódica de vulnerabilidades em serviços expostos, avaliação de configuração e acompanhamento de publicações de segurança relacionadas às tecnologias utilizadas.

Vulnerabilidades identificadas recebem classificação de severidade, responsável designado e prazo de correção proporcional ao risco.

21. Atualizações e correções

Sistemas operacionais, serviços de mensagem e componentes de infraestrutura recebem atualizações de segurança de forma programada. Correções críticas podem ser aplicadas em janela emergencial, com comunicação posterior quando houver impacto perceptível.

22. Endurecimento de servidores

Servidores executam apenas os serviços necessários, com portas desnecessárias fechadas, contas locais restritas, acesso remoto administrativo limitado por chave e origem, e registro centralizado de eventos.

23. Proteção de perímetro

A borda da rede aplica filtragem, limitação de taxa e mitigação de ataques volumétricos. Padrões de tráfego anômalo podem gerar bloqueio automático de origem.

Medidas de mitigação são aplicadas de forma proporcional e revisadas quando produzem efeito indesejado sobre tráfego legítimo.

24. Cabeçalhos e políticas de conteúdo

As interfaces web aplicam política de conteúdo restritiva, controle de enquadramento em outros sites, proteção contra interpretação indevida de tipos de arquivo e limitação de referências enviadas a terceiros.

Mensagens em formato HTML passam por sanitização antes da exibição no webmail, com remoção de elementos capazes de executar código.

25. Filtragem de spam, phishing e malware

Mensagens recebidas passam por verificação de reputação, autenticação de origem, análise de conteúdo e inspeção de anexos. Mensagens classificadas como maliciosas podem ser rejeitadas, colocadas em quarentena ou entregues com marcação.

Nenhum mecanismo de filtragem é infalível. A avaliação crítica das mensagens recebidas continua sendo responsabilidade do destinatário.

26. Autenticação de domínio

A plataforma oferece suporte a SPF, DKIM, DMARC e políticas de transporte seguro. Domínios próprios de clientes devem publicar os registros indicados no painel para obter proteção adequada contra falsificação de remetente.

27. Registros de segurança

Registramos eventos relevantes de autenticação, administração, entrega de mensagens e acionamento de mecanismos antiabuso, com prazos de retenção definidos em função da finalidade e da legislação aplicável.

Registros são protegidos contra alteração indevida e o acesso a eles é restrito às pessoas responsáveis por operação e resposta a incidentes.

28. Monitoramento

Sistemas de produção são monitorados quanto a disponibilidade, desempenho, erros e sinais de comprometimento. Alertas são encaminhados à equipe responsável conforme a criticidade.

29. Cópias de segurança

Cópias de segurança são geradas em rotina definida, armazenadas de forma cifrada e submetidas a testes de restauração periódicos.

Cópias de segurança de conteúdo protegido por criptografia de conhecimento zero permanecem cifradas e só podem ser restauradas em formato legível com a chave privada do cliente.

30. Continuidade operacional

Mantemos procedimentos para recuperação de serviços críticos em caso de falha de componente, indisponibilidade de fornecedor ou perda de ambiente, com prioridade para autenticação, recebimento e armazenamento de mensagens.

31. Localização da infraestrutura

Os serviços são operados em provedores de infraestrutura com controles de segurança física, redundância de energia e conectividade e restrição de acesso ao ambiente de servidores.

As regiões utilizadas e as condições de transferência internacional estão descritas na Política de Privacidade.

32. Fornecedores

Fornecedores com acesso a dados pessoais são selecionados conforme critérios de segurança, vinculados por contrato e limitados às finalidades necessárias à prestação do serviço.

As categorias de fornecedores utilizados estão descritas na página de Subprocessadores e Fornecedores.

33. Segurança de pessoal

Integrantes da equipe assumem obrigação de confidencialidade, recebem orientação sobre tratamento de dados e sobre engenharia social, e têm acessos revogados no encerramento do vínculo.

34. Dispositivos da equipe

Dispositivos utilizados para operar a plataforma devem manter disco cifrado, bloqueio automático de tela, sistema atualizado e ausência de software não autorizado.

35. Engenharia social

Nenhum integrante da equipe solicita senha, código de segundo fator, chave privada ou código de recuperação por telefone, mensagem ou e-mail. Solicitações nesse sentido devem ser tratadas como tentativa de fraude e comunicadas para security@abdalamail.com.

36. Resposta a incidentes

Incidentes de segurança são registrados, classificados por severidade e conduzidos por processo que abrange contenção, erradicação, recuperação e análise posterior.

Durante a resposta, podem ser adotadas medidas emergenciais como revogação de sessões, rotação de credenciais, bloqueio de origem e suspensão temporária de funcionalidade.

37. Comunicação de incidentes

Incidentes que possam acarretar risco relevante a titulares são comunicados aos clientes afetados e, quando aplicável, à autoridade competente, nos termos da legislação.

A comunicação informa a natureza do evento, os dados envolvidos, as medidas adotadas e as recomendações dirigidas ao cliente, na medida do que estiver apurado no momento.

38. Contas comprometidas

Diante de indícios de comprometimento de conta, podemos encerrar sessões ativas, exigir troca de senha, restringir envio e comunicar o titular.

Contas comprometidas utilizadas para envio abusivo seguem o tratamento previsto na Política Anti-Spam e na Política de Uso Aceitável.

39. Testes de segurança

Testes de intrusão, varreduras e exercícios ofensivos contra a infraestrutura do Abdala Mail exigem autorização prévia por escrito. Testes não autorizados são tratados como incidente.

Pesquisadores que identifiquem falhas devem seguir a Política de Divulgação de Vulnerabilidades, que rege o programa de relato mantido pelo Abdala Mail e prevê recompensa para achados válidos.

Ataques de negação de serviço e demais atividades cuja única finalidade seja sobrecarregar serviços que funcionam como esperado ficam fora do programa e são conduzidos como incidente.

40. Recebimento de relatos

Relatos de segurança recebidos em security@abdalamail.com são analisados por equipe designada, com confirmação de recebimento e acompanhamento até a conclusão.

O mesmo endereço recebe os pedidos de cadastro no programa. O pesquisador cadastrado recebe um código pessoal que dá prioridade na fila de análise dos relatos seguintes.

41. Responsabilidades do cliente

Cabe ao cliente manter senhas fortes e exclusivas, habilitar autenticação multifator, proteger códigos de recuperação, revisar sessões ativas, manter seus dispositivos atualizados e controlar os acessos concedidos dentro da organização.

Nos planos Advanced Security, cabe ao cliente a guarda da chave privada e da respectiva senha de proteção.

42. Responsabilidades do administrador

Administradores de contas empresariais são responsáveis por conceder acessos proporcionais à função, revogar acessos de pessoas desligadas, revisar permissões periodicamente e comunicar suspeitas de comprometimento.

43. Limites dos controles

Nenhum conjunto de controles elimina integralmente o risco de segurança. Falhas em componentes de terceiros, vulnerabilidades ainda desconhecidas e comprometimento do dispositivo do usuário podem afetar a proteção dos dados.

Esta Política descreve a postura adotada e não constitui garantia de inviolabilidade.

44. Revisão desta Política

Esta Política é revisada periodicamente e sempre que houver mudança relevante em arquitetura, fornecedores, ameaças ou legislação aplicável.

45. Contato de segurança

Assuntos de segurança devem ser encaminhados para security@abdalamail.com. Denúncias de abuso devem ser enviadas para abuse@abdalamail.com e assuntos de proteção de dados para dpo@abdalamail.com.