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-11-04.

Cifragem dos dados #

Os campos sensíveis da base de dados indicados abaixo 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 de campos não abrange as cópias integrais da base de dados nem os anexos; estes são cifrados separadamente, conforme descrito em anexos e cópias de segurança.

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.

Anexos #

Os ficheiros anexados a denúncias, mensagens e notas internas, as gravações de voz e as exportações de dados do caso são cifrados em repouso no Hetzner Object Storage com AES-256, com uma chave aleatória distinta para cada ficheiro (cifragem do lado do servidor com chaves fornecidas pelo cliente). A chave é enviada com cada pedido ao armazenamento, e a Hetzner recusa qualquer leitura feita sem ela. O EthicsPortal guarda-a na base de dados, sob o ActiveRecord Encryption descrito acima, pelo que as credenciais de armazenamento, por si só, não permitem ler um ficheiro: são também necessárias a base de dados e as chaves de cifragem da aplicação. Os ficheiros chegam aos utilizadores autorizados por transmissão através da aplicação, nunca através de uma ligação direta ao armazenamento.

Os ficheiros carregados antes de 6 de outubro de 2026 foram novamente cifrados nessa data, e as suas cópias não cifradas, incluindo as versões anteriores conservadas, foram eliminadas. Os ficheiros que não são dados de denúncia, como fotografias de perfil e imagens de partilha da organização, não são cifrados desta forma. Nada disto protege contra o comprometimento do servidor da aplicação, que detém em conjunto as credenciais de armazenamento, a base de dados e as chaves.

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

Anonimato e privacidade #

Endereços IP #

O EthicsPortal não regista o endereço IP de um denunciante com as denúncias, as mensagens ou os registos de auditoria, e os registos da aplicação do canal de denúncia não contêm endereços IP.

A limitação de débito no canal de denúncia (submissão de denúncia, consulta de processo, mensagens) baseia-se num hash SHA-256 com chave e truncado do IP do pedido. O hash é pseudónimo, não anónimo: não pode ser lido de volta como um endereço, mas quem detenha o segredo da aplicação poderia testar endereços candidatos contra ele. É usado apenas durante a janela de limitação (no máximo 10 minutos), e uma tarefa em segundo plano elimina-o da cache no prazo de 5 minutos após o fim da janela.

O proxy TLS à frente da aplicação mantém o seu próprio registo de pedidos: endereço IP, caminho do pedido, agente de utilizador e estado da resposta. O caminho da página em que um denunciante consulta a sua denúncia contém o ID do caso, pelo que uma entrada dessa página pode ser associada à denúncia. São guardadas num único ficheiro de registo de 10 MB, substituído à medida que se enche, atualmente ao fim de cerca de dois dias; as imagens instantâneas do servidor de 7 dias descritas em cópias de segurança podem conter uma cópia.

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.

Dentro de um PDF, os nomes nos comentários e os metadados das fotografias incorporadas, como a posição GPS e o número de série da câmara, são mantidos. O denunciante que pretenda eliminá-los deve carregar as fotografias como ficheiros de imagem separados e remover os comentários antes de carregar um PDF.

Análise de vírus #

Os ficheiros anexados a denúncias, mensagens e notas internas 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.

Denúncias por email #

Cada canal de denúncia tem o seu próprio endereço de email em report.ethicsportal.eu. Um email enviado para esse endereço torna-se um processo nesse canal, tal como uma denúncia apresentada através do formulário de denúncia online. As denúncias por email estão ativadas por predefinição. Uma organização pode desativá-las nas definições do canal; o endereço passa então a recusar novos emails no prazo de um minuto.

• Servidor de correio próprio. O correio destes endereços é recebido pelo próprio servidor de correio do EthicsPortal, na mesma infraestrutura na Alemanha, e não por um fornecedor de email terceiro. Aceita correio apenas para endereços de canais, recusa qualquer outro endereço e não reencaminha nada.
• Cifragem do transporte. O servidor oferece TLS 1.2 ou superior, com um certificado Let’s Encrypt. O TLS é oportunista: um servidor remetente que não o suporte entrega sem cifragem.
• Endereço do remetente oculto aos gestores. O endereço do remetente é armazenado cifrado e nunca é mostrado aos gestores do caso, nem no processo, nem no respetivo PDF, nem nas exportações. O EthicsPortal utiliza-o apenas para enviar ao denunciante o recibo e os avisos de novas mensagens.
• Acesso sem email. O recibo contém o ID do caso e uma palavra-passe de utilização única para a caixa de entrada segura, substituída no primeiro início de sessão. As perguntas e respostas seguintes ficam na caixa de entrada, não no email. Quando a política DMARC do próprio domínio do remetente rejeita o endereço, a denúncia é conservada, mas não é enviada nenhuma palavra-passe. Depois de 10 denúncias por email para uma organização, ou 50 em todo o EthicsPortal, em 24 horas, as denúncias seguintes são guardadas mas não é enviado nenhum email: nem o recibo ao denunciante nem o aviso por email aos administradores, que continuam a ver o caso na aplicação.
• Anexos. Os ficheiros passam pela mesma remoção de metadados e análise de vírus que os carregamentos através do formulário. Os ficheiros que não podem ser aceites (outro tipo, demasiado grandes ou impossíveis de limpar) ficam de fora, e o denunciante é informado de quantos são.
• Cópias. Uma mensagem aguarda na fila do servidor de correio, no mesmo servidor, apenas até a aplicação a aceitar. A aplicação conserva o email original cifrado até o processo ser guardado e depois elimina-o. Os registos do servidor de correio guardam os endereços dos canais, nunca o endereço do remetente.
• Verificação do remetente. SPF, DKIM e DMARC são verificados na infraestrutura do EthicsPortal. Nenhum dado das mensagens é enviado para um serviço externo de spam ou de reputação.

O email não é anónimo: o fornecedor de email do próprio denunciante e, se escrever a partir de uma conta profissional, os sistemas de correio da organização podem guardar cópias e registos da mensagem. O recibo indica-o e inclui um link para o formulário de denúncia online para os denunciantes que pretendam manter o anonimato.

E-mail para novidades #

O formulário de denúncia online tem um campo de email opcional para novidades. O endereço recebe o recibo e um aviso quando um gestor escreve, nunca o conteúdo da denúncia. É armazenado cifrado e, tal como o endereço do remetente de uma denúncia por email, não é mostrado em nenhuma página dos gestores, em nenhum PDF nem em nenhuma exportação. Continua disponível quando o denunciante denuncia de forma anónima. Só um denunciante que desative a denúncia anónima e assinale “mostrar também o meu endereço de e-mail aos gestores de casos” o transforma num endereço de contacto que os gestores veem.

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 Plausible Analytics apenas no site de marketing, servido a partir do nosso próprio domínio. Não define cookies nem guarda endereços IP. A Cloudflare, que entrega o site de marketing, trata metadados do pedido, incluindo endereços IP, conforme descrito no Aviso de privacidade. O próprio 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 — abrem a sua denúncia com um ID do caso (WB-XXXX-XXXX) e uma palavra-passe que o sistema gera quando a denúncia é submetida.
• 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.

Início de sessão do denunciante #

Os denunciantes iniciam sessão com o ID do caso e uma palavra-passe. O ID do caso identifica o caso e não é secreto. A palavra-passe tem 16 dígitos aleatórios e é gerada pelo sistema quando a denúncia é submetida; o denunciante não a escolhe. É armazenada apenas como um digest bcrypt, pelo que ninguém a pode recuperar, e o EthicsPortal não tem nenhuma funcionalidade que permita ao denunciante, ao gestor do caso ou ao operador redefini-la. Um denunciante que a perca submete uma nova denúncia e menciona o ID do caso. As denúncias submetidas antes de 18 de outubro de 2026 mantêm a palavra-passe de 6 dígitos que o denunciante escolheu na altura, que continua a funcionar. 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.

Logo após a submissão, uma página de comprovativo mostra o endereço da caixa de entrada segura, o ID do caso e a palavra-passe. Fica disponível nesse navegador apenas enquanto o caso estiver desbloqueado e desaparece quando a caixa de entrada é bloqueada após 30 minutos sem atividade ou quando o denunciante sai. Na página de início de sessão, o campo da palavra-passe é um campo de texto visível com o preenchimento automático desativado, em vez de um campo de palavra-passe mascarado, para que os navegadores não se ofereçam para guardar a palavra-passe; caso contrário, um navegador gerido pela entidade empregadora poderia sincronizá-la com a conta do empregador. É possível colar a palavra-passe, e os espaços são ignorados.

Quando o pessoal regista uma denúncia recebida por telefone, numa reunião presencial, por carta ou por email, e o denunciante quer acompanhar o caso online, o sistema gera uma palavra-passe de utilização única que o gestor transmite ao denunciante. Só funciona uma vez: no primeiro início de sessão do denunciante, é substituída, no servidor, por uma nova palavra-passe que só o denunciante vê.

O acesso do denunciante termina quando seleciona «Sair» ou após 30 minutos sem atividade. Cerca de dois minutos antes do bloqueio, um aviso oferece manter a caixa de entrada aberta; se ninguém responder, o caso desaparece do ecrã. O acesso fica guardado num cookie cifrado no navegador do denunciante, e o servidor não guarda nenhuma sessão do 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 proprietário da organização, o último administrador ativo e o responsável de conformidade designado do canal de denúncia não podem ser desativados. Todos os eventos de desativação e reativação são escritos no registo de auditoria só com acrescentos.

A remoção de um membro desativa a adesão em vez de a eliminar, para que o registo de atividades e o histórico das denúncias se mantenham resolúveis. Uma adesão só é eliminada definitivamente quando a própria conta do membro ou a própria organização é apagada.

Eliminação da conta #

Quando um membro encerra a própria conta, o endereço de email é substituído por um marcador não encaminhável e a fotografia de perfil, as credenciais de dois fatores, as sessões, os tokens de API e as preferências são eliminados definitivamente; a conta deixa de poder autenticar-se ou ser contactada. Se a conta nunca tiver atuado numa organização, o registo é eliminado na íntegra. Se tiver atuado, o nome do membro permanece, enquanto as adesões são desativadas para que as notas de processo, as mensagens e as entradas de auditoria conservadas continuem imputáveis. O Responsável pelo tratamento determina o prazo de conservação de acordo com as suas instruções documentadas e a lei aplicável; os direitos de apagamento ao abrigo do RGPD continuam sujeitos às exceções aplicáveis relativas a obrigações legais ou a direitos em processos judiciais.

Uma conta depurada não pode autenticar-se por nenhuma via: link mágico, asserção SSO ou token de API.

Limitação de débito #

Os pontos de extremidade públicos do canal de denúncia 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 com chave descrito acima — nenhum endereço IP é armazenado para esse fim. O limite por ID do caso usa como chave o próprio ID do caso, que é eliminado da mesma cache no prazo de 15 minutos.

Auditoria e conformidade #

Registo de atividades só com acrescentos #

Os eventos definidos relativos a denúncias e contas são registados com:

• Data/hora (UTC)
• Ator (que utilizador ou processo do sistema realizou a ação)
• Tipo de ação (por exemplo, denúncia criada, estado alterado, mensagem enviada, gestor atribuído, denúncia exportada ou denúncia eliminada). Cada visualização de uma denúncia por um gestor é registada, deduplicada para uma entrada por gestor por denúncia por 24 horas, e as visualizações de seguimento pelo denunciante são registadas da mesma forma. As leituras de outros recursos não são registadas.

As entradas do registo de auditoria são só com acrescentos. Nenhum utilizador, incluindo os administradores da organização, pode editar uma entrada nem eliminar uma delas de forma seletiva: os gatilhos PostgreSQL rejeitam modificação e truncagem ao nível da base de dados. As entradas só são removidas pelo ciclo de retenção ou quando a própria organização é eliminada, e a intervenção privilegiada na base de dados continua a ser um risco residual documentado (registo de riscos R-08). 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, uma tarefa em segundo plano elimina a denúncia e os dados associados da produção; as cópias de segurança expiram de acordo com o ciclo de vida documentado em separado.

Os emails enviados a um denunciante não deixam registo no histórico de envios do EthicsPortal, pelo que nenhum endereço de denunciante permanece depois de a denúncia ser eliminada.

O Responsável pelo tratamento continua responsável por selecionar um prazo que cumpra a limitação da conservação do RGPD e as regras nacionais aplicáveis de manutenção de registos.

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 controlos da cadeia de fornecimento limitam o que uma versão comprometida de uma dependência pode atingir:

• Período de espera. As novas versões de gems só são adotadas depois de estarem publicadas há três dias; as atualizações de versão do Dependabot aguardam 3, 7 ou 14 dias para versões de correção, menores e maiores. As versões sequestradas costumam ser retiradas dentro desse prazo.
• Ações de CI fixadas. Cada passo do GitHub Actions está fixado a um SHA de commit completo, pelo que uma etiqueta redirecionada não pode alterar o que é executado.
• Transferências verificadas. Os binários obtidos durante a construção da imagem do contentor são verificados contra uma soma de verificação SHA-256 fixada.
• Atualizações automáticas condicionadas. Os pedidos de integração do Dependabot só são integrados automaticamente depois de passarem o conjunto completo de testes e a análise estática.

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 #

• O armazenamento central das denúncias e dos dados dos casos ocorre na União Europeia. A entrega de email e a telemetria da aplicação têm cadeias de fornecedores a jusante separadas; ver o DPA.
• 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 envia as notificações aos gestores e, opcionalmente, os comprovativos e os avisos de nova mensagem aos denunciantes. Os avisos aos denunciantes contêm o endereço de email do destinatário, o ID do caso e um link, mas não o relato da denúncia. O comprovativo de uma denúncia enviada por email contém também uma palavra-passe de utilização única para a caixa segura, substituída quando o denunciante inicia sessão pela primeira vez. A cadeia de suporte a jusante da Mailjet pode envolver acesso fora do EEE; ver o DPA.
• O site de marketing é servido através da Cloudflare (CDN, Estados Unidos); o canal de denúncia e a área 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, e não na lista de subcontratantes do DPA do cliente.

Cópias de segurança e restauro #

O EthicsPortal opera três camadas complementares de cópias de segurança, todas 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, e a pedido, restaurando a cópia mais recente para um ambiente descartável. Decifra a cópia, restaura-a, compara cada tabela com a produção em funcionamento e, em seguida, arranca a aplicação sobre a base de dados restaurada para confirmar que uma coluna cifrada ainda é decifrada, que um anexo cifrado abre com a chave contida na cópia restaurada e que cada anexo com mais de uma hora tem uma cópia no local de cópia de segurança, sendo uma dessas cópias aberta e verificada face à respetiva soma de verificação — a contagem de linhas, por si só, não distingue uma cópia utilizável de um texto cifrado cuja chave já não corresponde. A atualidade das cópias de segurança é monitorizada continuamente (alerta se a cópia mais recente tiver mais de 36 horas).

Cifragem. A Hetzner indica que o Object Storage não cifra objetos em repouso por predefinição, pelo que as cópias da base de dados são cifradas antes de saírem do anfitrião: GnuPG simétrico AES-256, com a frase-passe detida apenas pelo processo de cópia e depositada fora da máquina. Os campos da camada de aplicação cifrados com o Rails ActiveRecord Encryption permanecem cifrados separadamente dentro de cada cópia. Os anexos são cifrados em repouso com uma chave por ficheiro (ver anexos). Essas chaves existem apenas na base de dados, pelo que cada cópia cifrada as contém. Os próprios ficheiros não são copiados para a cópia. Cada um é guardado em Nuremberga e copiado, com a mesma chave, para um segundo bucket em Falkenstein; ambos conservam as versões anteriores durante 28 dias.

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.
4. Não realize ataques de negação de serviço nem análises automatizadas em massa, não tente engenharia social junto da nossa equipa e não submeta denúncias através do canal de denúncia de um cliente.

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

Sem programa de recompensas pago. A divulgação não é remunerada: 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: 8 de novembro de 2026