Um suplemento pode ler o conteúdo dos meus e-mails?

As permissões solicitadas por um suplemento são declaradas no manifesto dele e exibidas no momento do consentimento do administrador. Um suplemento de assinatura pede a escrita na mensagem em redação e a leitura dos atributos do diretório, não a leitura da caixa de correio.

Como verificar o que um suplemento realmente solicita?

A tela de consentimento do seu provedor de identidade lista as permissões solicitadas antes da aprovação. É a prova mais direta do escopo: ela vem da Microsoft ou do Google, não do fornecedor.

Meus e-mails passam pelos servidores do fornecedor?

Com um suplemento, não: a mensagem sai do seu tenant para o destinatário sem passar por um terceiro. Com um relay SMTP, sim, e esse é o ponto a examinar em primeiro lugar em uma análise de segurança.

O que acontece se a ferramenta for comprometida?

O escopo do risco é o dos dados mantidos. Para um suplemento, isso abrange o diretório sincronizado e os modelos, não o conteúdo das mensagens, que nunca esteve acessível.

Uma ferramenta de assinatura pode ler seus e-mails? A resposta técnica

Conforme a arquitetura, uma ferramenta de assinatura acessa ou não o conteúdo das suas mensagens. A diferença entre suplemento no cliente, regra de transporte e relay SMTP, explicada para uma análise de segurança.

É a primeira pergunta de uma análise de segurança, e ela é legítima: uma ferramenta que atua sobre os seus e-mails tem acesso ao conteúdo deles? A resposta depende inteiramente da arquitetura escolhida, e as três arquiteturas do mercado não têm o mesmo escopo.

Arquitetura 1 — O suplemento no cliente

O suplemento (add-in) é executado no cliente de e-mail, no momento em que o usuário redige a mensagem. Ele insere um bloco HTML no corpo da mensagem em andamento.

O escopo de acesso corresponde às permissões declaradas no manifesto do suplemento: a escrita no item em redação e a leitura dos atributos do diretório necessários para preencher os campos.

Daí decorrem duas propriedades, e são elas que importam em uma análise de segurança:

A mensagem não passa pelo fornecedor. A inserção acontece no computador, na janela de redação. Depois, a mensagem sai do seu tenant Microsoft ou Google para o destinatário, pelo seu roteamento habitual, sem desvio.

A caixa de correio não é lida. O suplemento atua sobre uma mensagem em redação, não sobre a caixa de entrada, o histórico ou os arquivos.

É a arquitetura do Signally, descrita na página suplemento para Microsoft 365.

Arquitetura 2 — A regra de transporte

A assinatura é adicionada pelo seu próprio servidor de e-mail — o Exchange Online ou o serviço de compliance do Google Workspace — durante o encaminhamento.

Aqui, o fornecedor não participa de forma alguma do processamento da mensagem: ele fornece o conteúdo do rodapé, e o seu servidor o aplica. Nenhum acesso, nenhum trânsito.

Em contrapartida, essa arquitetura tem limitações funcionais importantes — o remetente nunca vê a própria assinatura, os fios de conversa empilham blocos, as mensagens criptografadas escapam dela —, detalhadas em suplemento ou regra de transporte.

Arquitetura 3 — O relay SMTP

É a que pede um exame cuidadoso. A mensagem sai do seu servidor, passa pela infraestrutura do fornecedor, que adiciona a assinatura, e segue para o destinatário.

Essa arquitetura implica, por construção, que o conteúdo completo das suas mensagens passa por um terceiro — corpo, anexos, destinatários. Ela também implica uma alteração do seu roteamento de saída, com as consequências associadas sobre a entregabilidade e sobre a sua configuração de SPF e DKIM.

Ela não é ilegítima em si, e alguns fornecedores a implementam com seriedade. Mas ela muda a natureza da pergunta feita ao seu CISO: não se trata mais de autorizar um componente, e sim de inserir um terceiro na sua cadeia de encaminhamento.

Como verificar, em vez de acreditar

Três verificações concretas, que não dependem da palavra do fornecedor.

A tela de consentimento. No momento de conectar o tenant, o seu provedor de identidade — Microsoft Entra ID ou Google — exibe a lista exata das permissões solicitadas. Essa lista vem da Microsoft ou do Google, não do fornecedor. É a prova mais direta do escopo.

A documentação da API. As permissões solicitadas correspondem a escopos documentados publicamente pela Microsoft e pelo Google. Você pode verificar o que cada um abrange.

A configuração de roteamento. Se a instalação pedir para alterar seus conectores, seus registros MX ou seu SPF, você está em uma arquitetura de relay. Se ela não mexer em nada do roteamento, não está.

Bom saber: faça uma captura da tela de consentimento durante a instalação e anexe-a ao dossiê de segurança. É uma evidência datada, que vale mais do que um compromisso comercial.

O escopo do risco residual

Nenhuma ferramenta tem risco zero, e é mais honesto delimitar o risco do que negá-lo.

Com um suplemento, o que um invasor obteria em caso de comprometimento do fornecedor são os dados mantidos: o diretório sincronizado — nomes, cargos, telefones profissionais — e os modelos. Não o conteúdo das mensagens, que nunca esteve acessível.

É uma diferença de natureza, não de grau. O vazamento de um diretório profissional é um incidente sério; o histórico de e-mails de uma organização é outra coisa.

A localização e a jurisdição aplicáveis a esses dados mantidos são a outra parte do dossiê, tratada em soberania de dados.

O resumo para enviar ao seu CISO

Quatro linhas bastam para a arquitetura de suplemento:

A assinatura é inserida durante a redação, no cliente, na mensagem em andamento.
Nenhum conteúdo de e-mail é lido, analisado, armazenado ou passa pelo fornecedor.
Os únicos dados sincronizados são os atributos do diretório exibidos na assinatura.
Nenhuma alteração no roteamento de saída: nem conector, nem relay, nem mudança de SPF.

Esses elementos e o detalhe do que o Signally não faz estão na nossa página segurança e GDPR, pensada para ser enviada do jeito que está à área de TI.