2️⃣ As comunicações por e-mail estão protegidas contra usurpação de identidade e falsificação de conteúdos?

O email continua a ser um dos principais canais de comunicação oficial das organizações: propostas, instruções de pagamento, comunicações contratuais, notificações, pareceres, respostas a entidades reguladoras, informação sensível e documentação com valor jurídico.

Mas há uma pergunta que poucas organizações fazem.

Na maioria dos casos, a resposta é desconfortável.

O problema escondido até ser tarde

Imagine o seguinte cenário. Um cliente recebe um email, aparentemente enviado pela vossa organização, com novos dados bancários para o próximo pagamento. O domínio parece correto. O tom é o habitual. A assinatura institucional está lá. O cliente paga.

Só que a vossa organização nunca enviou esse email.

Este tipo de fraude, uma forma dirigida de PHISING conhecida como Business Email Compromise (BEC), não exige necessariamente competências técnicas sofisticadas. Ao contrário do phishing em massa, que lança redes amplas para capturar credenciais, o BEC é cirúrgico: faz-se passar por uma entidade de confiança (a vossa organização, um fornecedor, um gestor, um parceiro) para desviar pagamentos, obter informação sensível ou induzir decisões erradas. E, em muitos casos, só é possível porque a organização visada não implementou três ou quatro medidas básicas de proteção da sua identidade digital.

O cada vez mais conhecido ataque de CEO Fraud (Fraude do CEO) é, de facto, um dos exemplos mais comuns e devastadores de Business Email Compromise.

O email foi desenhado numa internet onde a confiança era assumida por defeito. O protocolo SMTP, que ainda hoje transporta praticamente todo o correio eletrónico do mundo, não verifica nativamente quem é o remetente: qualquer pessoa pode tentar colocar qualquer endereço no campo “De:”. É o equivalente digital a enviar uma carta com o remetente de outra pessoa no envelope, e o sistema postal entregá-la na mesma.

A boa notícia: existem soluções maduras, normalizadas e, na sua componente técnica de base, acessíveis. A má notícia: muitas organizações ainda não as implementaram corretamente.

Dois níveis do problema

A proteção das comunicações eletrónicas deve ser analisada em dois planos distintos e complementares.

O Nível 1 protege o domínio: impede que terceiros enviem mensagens fazendo-se passar pela organização. O Nível 2 protege a mensagem: garante que o conteúdo não foi alterado e que foi assinada por uma pessoa ou entidade identificada.

Ter apenas um destes níveis deixa sempre uma porta aberta.

Nível 1. Autenticidade da origem: SPF, DKIM e DMARC

SPF, DKIM e DMARC são três mecanismos técnicos que trabalham em conjunto para proteger o domínio de email de uma organização. Nenhum, isoladamente, resolve todo o problema; mas, corretamente implementados, reduzem de forma significativa o risco de spoofing direto do domínio.

SPF · Sender Policy Framework

O SPF funciona como uma lista autorizada de remetentes. A organização publica, no DNS do seu domínio, quais os servidores autorizados a enviar email em seu nome. Quando um servidor de receção recebe uma mensagem, consulta esse registo; se o servidor que a enviou não constar da lista, o email falha a verificação.

Responde, portanto, à pergunta: “este servidor está autorizado a enviar email por este domínio?”

Mas tem limitações importantes: valida sobretudo o envelope técnico do email, não necessariamente o endereço visível no campo “De:”, e pode falhar em cenários de reencaminhamento. SPF é necessário, mas não suficiente.

DKIM · DomainKeys Identified Mail

O DKIM acrescenta uma assinatura criptográfica à mensagem. O servidor de envio assina determinados elementos do email com uma chave privada; o servidor de receção verifica essa assinatura com a chave pública publicada no DNS. Se for válida, obtêm-se duas garantias: a mensagem passou efetivamente por uma infraestrutura autorizada do domínio, e os elementos assinados não foram alterados em trânsito.

Responde a uma pergunta diferente: “esta mensagem foi assinada por uma infraestrutura associada ao domínio e manteve-se íntegra?”

A limitação: por si só, o DKIM não define o que deve acontecer quando a verificação falha. É aqui que entra o DMARC.

DMARC · a peça que fecha o sistema

O DMARC (Domain-based Message Authentication, Reporting and Conformance) é a camada de governação que articula SPF e DKIM, e faz três coisas decisivas.

1. Alinha a autenticação com o domínio visível ao utilizador. Verifica se os resultados SPF e DKIM estão alinhados com o domínio que aparece no campo “De:”, ou seja, o que o utilizador efetivamente vê. Este detalhe é crítico, porque muitos ataques exploram precisamente a diferença entre o domínio técnico de transporte e o domínio visível ao destinatário.

2. Define uma política de tratamento para mensagens que falham as verificações:

p=none : apenas monitorizar;
p=quarantine : enviar para spam ou quarentena;
p=reject : rejeitar a mensagem.

3. Gera relatórios agregados sobre quem está a enviar email em nome do domínio: que sistemas internos enviam legitimamente, que fornecedores externos o fazem, que fluxos estão mal configurados e que tentativas de abuso ocorrem. Sem esta visibilidade, muitas organizações nem sequer sabem quem envia email em seu nome.

O baseline técnico recomendado

1. Inventariar todos os remetentes legítimos, incluindo faturação, CRM, marketing, helpdesk, sistemas transacionais, plataformas cloud e fornecedores externos.

2. Publicar SPF corretamente, apenas com os servidores e serviços autorizados.

3. Ativar DKIM em todos os fluxos relevantes, com chaves robustas e rotação adequada.

4. Implementar DMARC de forma progressiva, de p=none (recolha de relatórios) para p=quarantine e, finalmente, p=reject.

5. Monitorizar relatórios DMARC antes de endurecer a política, para não bloquear correio legítimo.

6. Rever periodicamente a configuração, sempre que se adicionem novos serviços, fornecedores ou plataformas de envio.

Esta componente é, em grande medida, baseada em registos DNS, com custo de licenciamento reduzido ou inexistente. O verdadeiro custo está no conhecimento necessário para configurar corretamente, interpretar relatórios e manter disciplina operacional.

Nível 2. Integridade e não-repúdio do conteúdo: S/MIME

SPF, DKIM e DMARC ajudam a garantir que o email veio de um domínio legítimo. Mas não respondem plenamente a duas perguntas críticas em comunicações oficiais: o conteúdo da mensagem foi alterado depois de sair do remetente? e foi aquela pessoa concreta que a assinou?

É aqui que entra o S/MIME (Secure/Multipurpose Internet Mail Extensions), um standard técnico que permite aplicar mecanismos criptográficos às mensagens de email, em duas operações:

1. Assinatura digital: garante a integridade do conteúdo e associa a mensagem a um certificado digital. Se o conteúdo assinado for alterado, a assinatura deixa de validar.

2. Cifragem: garante a confidencialidade, tornando o conteúdo legível apenas para o destinatário pretendido.

A diferença é simples: SPF, DKIM e DMARC protegem o domínio; o S/MIME protege a mensagem. Os primeiros ajudam a provar que uma carta saiu do edifício certo; o S/MIME ajuda a provar que foi assinada por uma pessoa identificada e que o seu conteúdo não foi alterado.

S/MIME e eIDAS: dois planos que se cruzam, mas não se confundem

É importante separar dois planos que são muitas vezes confundidos.

O S/MIME é o mecanismo técnico: define como uma mensagem de email pode ser assinada e cifrada. O Regulamento eIDAS, na sua versão revista pelo Regulamento (UE) 2024/1183, o chamado eIDAS 2.0, regula os efeitos jurídicos das assinaturas eletrónicas, dos selos, dos certificados e dos serviços de confiança que lhes dão suporte. O eIDAS não regula o S/MIME.

O ponto de encontro é o certificado. Quando uma assinatura S/MIME assenta num certificado de baixa garantia, a confiança resultante é limitada. Quando assenta num certificado qualificado emitido por um Prestador de Serviços de Confiança Qualificado (QTSP), a identidade do titular fica ancorada no quadro europeu dos serviços de confiança, e o nível de garantia eleva-se.

Ou seja: o S/MIME é o envelope técnico; o certificado é o selo que determina o nível de confiança associado à identidade. O mesmo envelope pode transportar diferentes níveis de garantia, e é o selo que define a força do conjunto.

Nem todos os certificados S/MIME são iguais

Um erro comum é tratar o S/MIME como se tivesse sempre o mesmo valor. Não tem. O valor técnico, jurídico e probatório de uma mensagem assinada por S/MIME depende do tipo de certificado utilizado e do processo de validação da identidade do titular.

Esta distinção é essencial. Uma assinatura eletrónica qualificada não resulta apenas da utilização de um certificado qualificado: exige também que a assinatura seja criada por um dispositivo qualificado de criação de assinatura (QSCD) e que todos os requisitos aplicáveis sejam cumpridos.

O equilíbrio operacional: identidade forte sem complexidade excessiva

O eIDAS estabelece três níveis de assinatura eletrónica: simples, avançada e qualificada. A assinatura qualificada tem o nível jurídico mais elevado: ao abrigo do artigo 25.º do Regulamento, tem efeito legal equivalente ao de uma assinatura manuscrita em toda a União, com a correspondente inversão do ónus da prova em caso de litígio.

Mas esse nível implica requisitos adicionais, incluindo certificado qualificado e QSCD. Em muitos contextos isso é adequado e necessário: contratos de elevado valor, atos formais, decisões com impacto jurídico significativo, documentação sujeita a requisitos regulatórios específicos.

É aqui que pode surgir uma abordagem intermédia, frequentemente mais racional para comunicações oficiais correntes: usar S/MIME com certificados de identidade forte (sempre que adequado, certificados qualificados emitidos por QTSP)

Porque é que isto é um risco de negócio, não apenas técnico

A proteção das comunicações oficiais é um tema de identidade organizacional, continuidade de negócio, responsabilidade jurídica e confiança institucional, e as consequências de uma má configuração materializam-se em vários planos.

Fraude financeira direta. O BEC/CEO Fraud é uma das formas de cibercrime com maior impacto financeiro, precisamente porque explora a confiança no email. Não é necessário comprometer sistemas internos complexos: muitas vezes basta convencer alguém a pagar para a conta errada ou a responder a uma instrução falsa. Quando o domínio não está protegido, o atacante consegue parecer legítimo, e essa é a sua vantagem decisiva.

Responsabilidade legal e contratual. Em contextos regulados, contratuais ou litigiosos, pode ser necessário demonstrar quem enviou uma comunicação, se o conteúdo foi alterado, se o destinatário recebeu uma mensagem autêntica e se existiam controlos adequados para prevenir o abuso do domínio. A ausência de mecanismos de autenticação, assinatura e evidência fragiliza a posição da organização.

Reputação e confiança. Quando clientes, parceiros ou cidadãos recebem emails fraudulentos aparentemente enviados por uma organização, o dano reputacional é imediato, mesmo sem qualquer intrusão interna. A perceção externa é simples: “recebi um email falso em nome desta entidade.” E a confiança perde-se mais depressa do que se reconstrói.

Conformidade e evidência. Quadros regulatórios como o RGPD, NIS2, certificação ISO/IEC 27001, requerem que as organizações adotem controlos proporcionais para proteger comunicações, identidades, acessos e informação sensível.

Conclusão

Proteger as comunicações oficiais não é um projeto de meses. O baseline técnico pode estar operacional em poucos dias, desde que exista conhecimento técnico e decisão de gestão.

SPF, DKIM e DMARC protegem o domínio. O S/MIME protege a mensagem. Os certificados adequados reforçam a identidade. As políticas internas transformam tecnologia em governação.

A questão não é se a vossa organização será alvo de uma tentativa de usurpação de identidade. É se, nesse momento, as defesas estarão implementadas, testadas e documentadas.