Segurança #

O EthicsPortal trata dados sensíveis de denúncia. Esta página documenta as medidas técnicas e organizativas específicas que temos em vigor. Está escrita para responsáveis de conformidade, EPD e equipas jurídicas que avaliam a plataforma.

Última atualização: 2026-08-28.

Cifragem dos dados #

Todos os campos sensíveis são cifrados em repouso com o Rails ActiveRecord Encryption com cifragem não determinística (cada cifragem produz um texto cifrado único, impedindo a análise de padrões).

A cifragem não determinística significa que estes campos não podem ser consultados por valor ao nível da base de dados. Mesmo com acesso total à base de dados, um atacante não consegue pesquisar o nome de um denunciante específico entre os registos.

Todas as ligações ao EthicsPortal usam HTTPS/TLS. Os pedidos HTTP não cifrados são reencaminhados.

Anonimato e privacidade #

Anonimização dos endereços IP #

As rotas do portal (submissão de denúncia, consulta de processo, mensagens) usam um hash SHA256 unidirecional do IP do pedido exclusivamente para limitação de débito. O hash não é reversível — não é possível recuperar o IP original a partir do valor armazenado.

Ao nível da aplicação, o endereço IP bruto do denunciante não é armazenado na base de dados, e os registos da aplicação para as rotas do portal são depurados para proteger o anonimato do denunciante.

Remoção dos metadados dos ficheiros #

Os ficheiros carregados são automaticamente despojados de metadados identificadores antes do armazenamento:

A remoção de metadados é feita do lado do servidor antes do armazenamento. Para os tipos de ficheiro tratados pelo exiftool, depende da presença do conjunto padrão de ferramentas de produção.

Análise de vírus #

Todos os ficheiros carregados são automaticamente analisados em busca de software malicioso com o ClamAV , um motor antivírus de código aberto. A análise ocorre do lado do servidor, num processo em segundo plano após o carregamento. Os ficheiros que não passaram na análise ficam bloqueados para entrega, e os ficheiros infetados são removidos automaticamente.

Os ficheiros são analisados na infraestrutura do EthicsPortal — nenhum dado dos ficheiros é enviado para serviços de análise de terceiros.

Anonimato dos gestores #

Os denunciantes nunca veem os nomes reais nem os endereços de email das pessoas que tratam a sua denúncia. Todas as mensagens dos gestores são apresentadas como “Gestor do caso”. Isto protege a identidade do gestor e previne a engenharia social.

Sem rastreio #

O EthicsPortal não usa cookies de rastreio de terceiros, pixels de publicidade nem scripts de fingerprinting. Usamos o Cloudflare Web Analytics apenas nas páginas de marketing. Não define cookies analíticos, mas a Cloudflare pode tratar metadados do pedido, incluindo endereços IP, conforme descrito no Aviso de privacidade . O canal de denúncia não tem análises.

Estado atual de garantia #

O EthicsPortal não reivindica atualmente neste site uma certificação ISO 27001 acreditada. Também não publica atualmente uma auditoria independente por terceiros à arquitetura de anonimato. Se isso mudar, o âmbito e a data serão publicados aqui.

Materiais de revisão de segurança #

Os clientes que necessitem de materiais de revisão de aprovisionamento ou jurídica podem solicitá-los durante o aprovisionamento. Os materiais disponíveis podem incluir um DPA assinado, elementos de registo e fiscais, um questionário de segurança preenchido e respostas escritas que abrangem os procedimentos de cópia de segurança e restauro, o acesso privilegiado de produção e o tratamento da resposta a incidentes.

Controlo de acesso #

A autorização é aplicada ao nível da aplicação através de políticas Pundit .

• Os gestores não podem ver denúncias que não lhes estejam atribuídas nem em que não participem. Os participantes são explicitamente adicionados por um administrador ou pelo responsável principal (por exemplo, envolvendo o departamento jurídico ou de recursos humanos).
• Os denunciantes não têm conta de utilizador — acedem à sua denúncia através de um ID do caso (WB-XXXX-XXXX) mais um código de acesso de 6 dígitos que escolhem na submissão.
• Cada ação do controlador verifica a autorização. As tentativas de acesso não autorizado são bloqueadas e registadas.

Autenticação de dois fatores #

As contas de gestor e administrador podem ativar a autenticação de dois fatores baseada em TOTP através de qualquer aplicação de autenticação padrão (Google Authenticator, 1Password, Authy e alternativas compatíveis). Uma vez ativada, o início de sessão exige tanto a credencial principal como um código rotativo de 6 dígitos.

Os denunciantes também se autenticam com dois fatores: o ID do caso (algo que detêm) e o código de acesso que escolheram na submissão (algo que sabem). O código de acesso é armazenado apenas como um digest bcrypt e não pode ser recuperado. A caixa de entrada de seguimento e a publicação de mensagens estão protegidas por sessão atrás desta verificação, pelo que um ID do caso divulgado não permite, por si só, ler a denúncia nem fazer-se passar pelo denunciante.

Ciclo de vida da sessão #

Cada sessão autenticada regista last_seen_at em cada pedido (com debounce). Os utilizadores podem rever as suas sessões ativas, ver quando cada uma esteve ativa pela última vez, revogar qualquer sessão individualmente ou terminar todas as outras sessões de uma só vez a partir das definições da conta.

As sessões expiram automaticamente após 14 dias de inatividade. O próximo pedido de uma sessão inativa destrói o registo do lado do servidor, limpa o cookie e força a reautenticação através de um novo link mágico. Uma tarefa noturna varre as sessões abandonadas com o mesmo limite de tempo, pelo que o user_agent e o ip_address não são conservados além da janela de inatividade, mesmo quando o utilizador nunca regressa.

A autenticação por link mágico limita o raio de impacto das sessões de longa duração: um cookie de sessão roubado não confere uma credencial reutilizável, e a reautenticação exige acesso ao email.

Acesso de membros e cessação #

O acesso à organização é aplicado na fronteira do pedido. Quando um membro é desativado:

• O acesso à organização é rejeitado de imediato, incluindo em URLs previamente marcados como favoritos.
• As atribuições de denúncias abertas são removidas.
• As participações são removidas.
• O histórico do registo de auditoria imputável ao membro é preservado.
• O membro desativado é notificado.
• A reativação não restaura automaticamente o acesso anterior aos processos.

O último administrador ativo e o proprietário da organização não podem ser desativados. Todos os eventos de desativação e reativação são escritos no registo de auditoria só com acrescentos.

As adesões sem pegada de conformidade (sem entradas no registo de auditoria, sem atribuições, sem participações) são eliminadas definitivamente na remoção; as adesões com pegada são desativadas de forma reversível para que o registo de atividades se mantenha resolúvel.

Eliminação da conta #

Quando um membro encerra a própria conta, o endereço de email é substituído por um endereço não encaminhável e as credenciais de dois fatores, sessões, tokens de API e preferências são eliminados definitivamente. Se nunca tiver atuado numa organização, o registo é eliminado. Caso contrário, o nome e a fotografia permanecem associados aos processos e ao registo de auditoria, enquanto as adesões são desativadas para preservar a atribuição exigida pelas obrigações de registo.

Limitação de débito #

Os pontos de extremidade do portal público são limitados em débito para prevenir abusos e ataques de enumeração:

A limitação de débito usa o hash de IP unidirecional descrito acima — nenhum IP real é armazenado.

Auditoria e conformidade #

Registo de atividades só com acrescentos #

Cada ação no EthicsPortal é registada com:

• Data/hora (UTC)
• Ator (que utilizador ou processo do sistema realizou a ação)
• Tipo de ação (denúncia criada, estado alterado, mensagem enviada, gestor atribuído, denúncia visualizada, denúncia exportada, denúncia eliminada, etc.)

As entradas do registo de auditoria são só com acrescentos. Não podem ser editadas nem eliminadas por nenhum utilizador, incluindo os administradores da organização. O registo de auditoria completo é incluído nas exportações de processos em PDF para revisão regulamentar.

Conservação dos dados #

As organizações configuram o seu próprio prazo de conservação: 12, 24, 36, 48 ou 60 meses após o encerramento de uma denúncia. Quando o prazo de conservação expira, a denúncia e todos os dados associados (mensagens, anexos, entradas do registo de auditoria) são automática e permanentemente eliminados por uma tarefa em segundo plano.

Isto satisfaz os requisitos de limitação da conservação do RGPD (art. 5.º, n.º 1, al. e)) e as obrigações de manutenção de registos da Diretiva 2019/1937 (art. 17.º-18.º).

Proteção CSRF #

Todas as submissões de formulários estão protegidas contra a falsificação de pedidos entre sites através dos tokens CSRF integrados no Rails.

Ciclo de vida de desenvolvimento seguro #

O EthicsPortal segue um ciclo de vida de desenvolvimento documentado para as alterações que tocam o Serviço. As etapas são aqui indicadas para que um revisor de aprovisionamento as possa mapear para os controlos A.8.25-A.8.29 da ISO/IEC 27001:2022 (ver o mapa de controlos para o mapeamento completo).

Gestão de dependências e correções #

O EthicsPortal não implementa componentes de software em fim de vida. A aplicação corre sobre versões ativamente suportadas do Rails, do Ruby, do PostgreSQL e do sistema operativo subjacente; as versões de segurança a montante são aplicadas numa base contínua.

As dependências são analisadas continuamente em integração contínua:

• O Brakeman assinala vulnerabilidades específicas do Rails em cada alteração.
• O bundler-audit verifica o Gemfile face à Ruby Advisory Database em cada alteração e ainda diariamente, para que os avisos recém-divulgados sejam detetados mesmo quando nenhum código foi alterado.
• O importmap audit analisa as importações de JavaScript em busca de vulnerabilidades conhecidas em cada alteração e ainda diariamente.
• O Dependabot abre pedidos de integração semanalmente para gems Ruby e GitHub Actions desatualizados, agrupados por atualizações menores/de correção.

Os componentes que atingem o fim de vida a montante são substituídos ou atualizados antes do fecho da sua janela de suporte.

Infraestrutura #

• Todo o tratamento central das denúncias e dos dados dos casos ocorre dentro da União Europeia.
• Nenhum número de cartão de crédito ou credencial de pagamento é armazenado nos servidores do EthicsPortal. Todos os dados de pagamento são tratados pela Stripe.
• A Mailjet é usada para email transacional (notificações de gestores, não dirigidas aos denunciantes). A Mailjet tem sede em França e trata todos os dados na UE.
• O site de marketing é servido através da Cloudflare (CDN, Estados Unidos); os portais de denúncia e de gestão não. Este tratamento separado do site público e as respetivas salvaguardas de transferência são descritos no Aviso de privacidade .

Cópias de segurança e restauro #

O EthicsPortal opera duas camadas complementares de cópias de segurança, ambas conservadas na UE:

Objetivos de recuperação. O objetivo de ponto de recuperação (RPO) é de 24 horas. O objetivo de tempo de recuperação (RTO) é de 4 horas. Estes objetivos também constam do acordo de nível de serviço .

Teste de restauro. Um ensaio de restauro corre automaticamente todos os meses através de um fluxo de CI que restaura a cópia mais recente para um ambiente descartável, e a pedido através de bin/backup-restore-test. A atualidade das cópias de segurança é monitorizada continuamente (alerta se a cópia mais recente tiver mais de 36 horas).

Cifragem. Os campos cifrados pela aplicação permanecem cifrados na cópia. O Hetzner Object Storage não cifra objetos em repouso por predefinição; a cifragem integral das cópias e dos anexos não foi verificada.

Revisão operacional #

Alguns materiais operacionais são partilhados durante a revisão de aprovisionamento, em vez de publicados integralmente na web aberta, porque contêm detalhes de infraestrutura e de resposta que são mais adequados a uma divulgação controlada.

Os temas disponíveis a pedido durante o aprovisionamento incluem:

• Resumo de acesso privilegiado de produção
• Fluxo de resposta a incidentes e contactos de escalada
• Respostas sobre continuidade do negócio e cessação/exportação do cliente

Divulgação responsável #

Se descobrir uma vulnerabilidade de segurança no EthicsPortal, comunique-a a security@ethicsportal.eu . Pedimos que:

1. Não divulgue publicamente a vulnerabilidade antes de termos tido a oportunidade de a resolver.
2. Forneça detalhe suficiente para que possamos reproduzir e corrigir o problema.
3. Não aceda nem modifique os dados de outros clientes.

Confirmaremos a sua comunicação no prazo de 2 dias úteis e procuraremos resolver prontamente as vulnerabilidades confirmadas.

Sem programa de recompensas pago. Não remuneramos comunicações de vulnerabilidades nem assinamos acordos de confidencialidade, aceitamos condições comerciais ou realizamos chamadas como condição prévia para receber uma comunicação. Envie o ativo afetado, os passos de reprodução e o impacto que apurou para o endereço indicado.

Última atualização: 23 de setembro de 2026