LinkedIn
Instagram
WhatsApp
Telegrama
Google Agenda
Participe da comunidade do SlackConstrua integrações de e-mail que seus usuários possam confiança
Conectar-se às caixas de entrada dos seus usuários acarreta riscos de segurança reais. Senhas armazenadas, escopos OAuth excessivamente amplos e tokens não rotacionados criam superfícies de ataque que violam a confiança do usuário e descumprem o GDPR.
Unipile's Guia da API de E-mail cobre o quadro completo de integração. Este artigo foca na camada de segurança: o que uma API de e-mail segura deve garantir, quais riscos evitar e como a Unipile é arquitetada para proteger os dados dos seus usuários por design.
Gmail
Perspectivas
IMAP
O que Torna uma API de E-mail "Segura"?
Segurança em uma API de e-mail não é um recurso único. É uma escolha arquitetural que abrange autenticação, autorização, manipulação de dados e infraestrutura. Uma API de e-mail segura deve garantir quatro coisas simultaneamente.
Os usuários autorizam o acesso através do fluxo OAuth oficial de seu provedor. Nenhuma senha sai do servidor do provedor ou vai para o seu banco de dados.
Cada conta vinculada solicita apenas as permissões de que realmente precisa: somente leitura quando o envio não for necessário, escopo de envio apenas quando explicitamente necessário.
Todo o tráfego da API usa TLS 1.2+. Tokens armazenados são criptografados em repouso usando AES-256. O conteúdo do e-mail nunca é persistido além do ciclo de vida da solicitação.
OAuth 2.0 vs. armazenar uma senha
A decisão de segurança mais fundamental em qualquer integração de e-mail é como você se autentica. Muitas integrações IMAP legadas pedem aos usuários que insiram suas senhas de e-mail e as armazenem. Essa abordagem cria um único ponto de falha: uma violação em um banco de dados expõe a caixa de entrada de todos os usuários. O OAuth 2.0 elimina isso completamente. Veja como Google OAuth 2.0 e Microsoft OAuth 2.0 Implemente este fluxo.
Escopos de token: somente leitura vs. enviar
Os escopos OAuth definem exatamente o que seu aplicativo pode fazer com a caixa de correio de um usuário. Solicitar escopos amplos quando outros mais restritos seriam suficientes é um grave anti-padrão de segurança. Para um CRM que apenas lê e-mails para registrar atividades, solicitar gmail.modificar é desnecessário e expõe os usuários a um risco maior se seu token for comprometido. Se o seu aplicativo precisar API de envio de e-mail requisitos, você também encontrará uma análise completa dos escopos necessários por provedor em nosso guia da API de envio de e-mail.
| Escopo | Fornecedor | O que permite | Nível de risco |
|---|---|---|---|
| gmail.somente leitura | Gmail | Ler emails apenas | Mínimo |
| gmail.enviar | Gmail | Enviar em nome do usuário | Escopo |
| Mail.Read | Perspectivas | Ler emails apenas | Mínimo |
| Mail.Send | Perspectivas | Enviar em nome do usuário | Escopo |
| https://mail.google.com/ | Gmail | Acesso total à caixa de correio | Amplo |
| Mail.ReadWrite | Perspectivas | Ler, escrever, excluir | Amplo |
Criptografia em trânsito e em repouso
Uma API de e-mail segura impõe TLS 1.2 ou superior em todos os endpoints da API. Nenhuma comunicação em texto plano é aceitável. Além do trânsito, quaisquer tokens ou credenciais que devam ser persistidos – tokens de atualização OAuth, por exemplo – devem ser criptografados em repouso usando um cifrador simétrico forte (AES-256). Igualmente importante: o conteúdo do e-mail em si nunca deve ser armazenado além do que a solicitação exige. Ler e exibir um e-mail em sua interface de usuário não requer a persistência de seu corpo em seu banco de dados.
Riscos de segurança da API de e-mail a serem evitados
A maioria das falhas de segurança na integração de e-mail não são ataques exóticos — são erros previsíveis na forma como credenciais, tokens e dados são manuseados. Os quatro padrões abaixo respondem pela maioria dos incidentes do mundo real em integrações de API de e-mail.
Pedir aos usuários que insiram sua senha de e-mail e armazená-la – mesmo criptografada – é o padrão de maior risco na integração de e-mails. Isso torna seu banco de dados um alvo de alto valor. Se um invasor obtiver acesso ao seu armazenamento de credenciais, ele terá acesso direto à caixa de entrada de todos os usuários. Além do risco de segurança, Google e Microsoft proíbem explicitamente o acesso baseado em senha ao Gmail e às contas do Outlook para aplicativos de terceiros. O IMAP com senha só é aceitável para servidores de e-mail auto-hospedados ou legados onde o OAuth está genuinamente indisponível.
Solicitando https://mail.google.com/ (acesso completo ao Gmail) quando você só precisa ler a pasta de enviados de um usuário é um anti-padrão de escopo. Escopos amplos aumentam o raio de explosão de um token comprometido e corroem a confiança do usuário durante a tela de consentimento OAuth - os usuários que veem "ler, compor, enviar e excluir permanentemente todos os seus e-mails" têm razão em hesitar. Tanto o Google quanto a Microsoft agora sinalizam o uso desnecessário de escopo durante as revisões de aplicativos.
Tokens de acesso OAuth são de curta duração por design - tipicamente uma hora para Gmail e Outlook. Tokens de atualização podem persistir por meses ou indefinidamente. Se você armazenar tokens de atualização sem uma estratégia de rotação, um token de atualização vazado concede acesso de longo prazo à caixa de correio do usuário. Algumas integrações também armazenam em cache tokens de acesso bem após seu vencimento e falham em lidar com eventos de revogação (quando um usuário remove seu aplicativo nas configurações de sua conta Google ou Microsoft).
Os logs de aplicativos geralmente são menos protegidos do que os bancos de dados primários, retidos por mais tempo e replicados para múltiplos sistemas (agregadores de logs, serviços de monitoramento, rastreadores de erros). Registrar corpos de e-mail completos, cabeçalhos contendo dados pessoais ou listas de destinatários cria uma exposição significativa à GDPR: você está processando dados pessoais em um contexto para o qual o usuário nunca consentiu e não pode auditar. Logs de erros que incluem respostas brutas de API podem capturar inadvertidamente encadeamentos de e-mail inteiros.
Conformidade com o GDPR para Integrações de API de E-mail
Os dados de e-mail estão entre as categorias de dados pessoais mais sensíveis sob o GDPR. Quando seu aplicativo acessa a caixa de entrada de um usuário via API, você se torna um processador de dados. Isso cria obrigações legais concretas em torno de residência, consentimento e exclusão que sua arquitetura de API de e-mail deve suportar.
Os dados pessoais da UE devem permanecer na UE ou em países com uma decisão de adequação. Sua infraestrutura de API de e-mail deve oferecer endpoints hospedados na UE.
Os usuários devem autorizar explicitamente o acesso à sua caixa de correio. A tela de consentimento do OAuth deve declarar claramente quais dados serão acessados e para qual finalidade.
Quando um usuário solicita a exclusão ou desconecta sua conta, todos os tokens associados, dados em cache e dados pessoais devem ser removidos dentro dos prazos do GDPR.
Residência de dados
Sob o Artigo 44 do GDPR, a transferência de dados pessoais para fora do Espaço Econômico Europeu exige uma decisão de adequação, Cláusulas Contratuais Padrão (SCCs) ou outro mecanismo legal válido. Para integrações de API de e-mail que atendem a usuários da UE, a infraestrutura que armazena tokens OAuth, processa metadados de e-mail ou armazena em cache o conteúdo das mensagens deve estar hospedada na UE. A escolha de um provedor de API sem opções de residência de dados na UE força você a depender de SCCs e de sobrecarga de conformidade adicional. Para casos de uso de saúde ou financeiros onde se aplicam requisitos adjacentes ao HIPAA, a residência de dados torna-se ainda mais crítica.
Seu provedor de API de e-mail é um sub-processador sob o GDPR. Você deve ter um Acordo de Processamento de Dados (DPA) em vigor com ele, e sua infraestrutura deve suportar a residência de dados da UE para quaisquer dados de usuários da UE que eles processem em seu nome.
Fluxo de consentimento do usuário
O fluxo de autorização OAuth serve como a implementação técnica do consentimento da GDPR para acesso a e-mails – mas apenas se for projetado corretamente. A tela de consentimento deve descrever com precisão, em linguagem clara, o que o aplicativo acessará. Solicitar escopos além do que sua política de privacidade descreve cria uma lacuna de conformidade. Os usuários também devem ser capazes de concluir este fluxo sem coerção: conectar sua conta de e-mail não deve ser uma condição forçada para acessar seu serviço principal, a menos que o acesso ao e-mail seja genuinamente o próprio serviço.
Direito ao esquecimento - desconexão da conta
O Artigo 17 do GDPR concede aos usuários o direito ao esquecimento. Em um contexto de integração de e-mail, isso significa que seu aplicativo deve ser capaz de remover imediata e completamente todos os vestígios do acesso de um usuário ao e-mail quando solicitado. Isso não se trata apenas de excluir o token OAuth - abrange todos os artefatos criados durante a vida útil da integração.
Como a Unipile Lida com a Segurança da API de E-mail
Segurança não é um recurso adicionado ao Unipile – é o comportamento padrão da plataforma. O Unipile foi construído especificamente para entregar uma API de e-mail segura, onde autenticação, segurança de dados de e-mail e controles de conformidade são integrados por padrão – não adicionados posteriormente. Cada decisão arquitetural na forma como o Unipile se conecta a contas Gmail, Outlook e IMAP é tomada com a segurança e a privacidade dos usuários finais como a principal restrição.
Unipile se conecta ao Gmail via Google OAuth 2.0 e para o Outlook e Microsoft 365 via Microsoft OAuth 2.0. Seus usuários se autenticam diretamente através da tela oficial de consentimento do provedor. Nenhuma senha passa pela infraestrutura da Unipile. Para contas IMAP onde o OAuth não está disponível, as credenciais são criptografadas em repouso com AES-256 e nunca são expostas por nenhuma resposta de API, incluindo a Guia da API IMAP cobre esta arquitetura em detalhes.
A Unipile solicita os escopos OAuth mais restritos necessários para os recursos que seu aplicativo SaaS habilita. Se sua integração apenas lê e-mails para preencher um feed de atividades de CRM, a Unipile solicita escopos somente para leitura. O escopo de envio é adicionado apenas quando sua implementação exige explicitamente o envio. Isso reduz a área de impacto de qualquer problema de credencial e torna a tela de consentimento OAuth do seu aplicativo direta para os usuários aprovarem.
Para equipes de SaaS que atendem clientes da UE, a Unipile oferece opções de infraestrutura hospedada na UE. Tokens OAuth, metadados de contas vinculadas e quaisquer dados de e-mail processados de forma transitória permanecem dentro da jurisdição da UE. Isso permite que você mantenha um registro de processamento de dados GDPR limpo e celebre um Acordo de Processamento de Dados com a Unipile como seu sub-processador - um requisito legal sob o Artigo 28 do GDPR para qualquer processador que manuseie dados pessoais da UE em seu nome.
O Unipile expõe um endpoint DELETE para contas vinculadas. Chamá-lo revoga imediatamente o token OAuth no nível do provedor, remove todos os metadados associados da infraestrutura do Unipile e cancela quaisquer assinaturas de webhook ativas. Isso oferece um caminho limpo e de chamada de API única para atender às solicitações de "direito ao esquecimento" do GDPR relacionadas ao acesso a e-mails, sem necessidade de limpeza manual em vários painéis de provedores.
Leia a referência completa da API - fluxos de autenticação, gerenciamento de tokens e segurança de webhooks.
Certificações de Conformidade
A Unipile é auditada e certificada independentemente nas três estruturas de conformidade mais relevantes para integrações seguras de API de e-mail: operações de segurança, proteção de dados e acesso à API do Google.
Auditado por um terceiro independente. Abrange os critérios de serviço de confiança de segurança, disponibilidade e confidencialidade na infraestrutura da Unipile'.
Conformidade total com as regulamentações da UE sobre proteção de dados. A Unipile atua como Processador de Dados. Todos os dados hospedados exclusivamente na UE. DPA disponível mediante solicitação.
Avaliação de Segurança de Aplicações do Google Cloud. Valida os controles de segurança para aplicações que acessam dados de usuários do Google, incluindo escopos OAuth do Gmail.
Ao construir na Unipile, sua integração segura de e-mail se beneficia dos mesmos controles de segurança que passaram por essas auditorias. Isso é particularmente relevante para o CASA Nível II: aplicativos construídos sobre uma API de e-mail segura certificada pela CASA podem manter seu próprio status de conformidade em toda a cadeia de integração — sem uma auditoria separada da camada de e-mail.
Checklist de Segurança para Integração de API de E-mail
Use esta checklist antes de enviar qualquer integração de API de e-mail para produção. Todos os itens devem ser validados antes que a integração possa ser considerada pronta para produção do ponto de vista de segurança.
OAuth 2.0, escopos mínimos, residência de dados na UE, desconexão instantânea de contas - tudo incluído em uma única API de e-mail segura. Conecte Gmail, Outlook e IMAP com acesso criptografado a e-mails e sem armazenamento de senhas.
API de E-mail Seguro - Perguntas Frequentes
Perguntas comuns sobre segurança de API de e-mail, OAuth e conformidade
O IMAP pode ser seguro, mas depende inteiramente da implementação. O protocolo em si transmite dados via TLS quando devidamente configurado, então a camada de trânsito não é o problema. O risco está em como as credenciais são tratadas. O IMAP exige um nome de usuário e senha - ao contrário do Gmail e Outlook, que suportam OAuth 2.0, o IMAP não possui um padrão de autorização delegada. Isso significa que seu aplicativo deve armazenar ou recuperar a senha do usuário toda vez que se conectar. Isso é gerenciável se as credenciais forem criptografadas em repouso com AES-256, o acesso ao armazenamento de credenciais for estritamente limitado e as senhas nunca forem registradas ou expostas em respostas de API. Para Gmail e Outlook, prefira sempre OAuth 2.0 em vez de IMAP com senha - ambos os provedores o exigem para aplicativos de terceiros. IMAP com senha é apropriado apenas para servidores de e-mail auto-hospedados ou ambientes corporativos legados onde o OAuth está genuinamente indisponível. Leia mais em Guia da API IMAP.
A conformidade com a HIPAA para uma integração de API de e-mail é possível, mas requer uma arquitetura cuidadosa. A HIPAA não certifica provedores de e-mail, mas exige que qualquer sistema que manipule informações de saúde protegidas (PHI) implemente proteções técnicas específicas: criptografia em trânsito e em repouso, controles de auditoria, controles de acesso e logoff automático para sessões inativas. Para uma API de e-mail, isso significa: usar o OAuth 2.0 para que nenhuma senha seja armazenada, garantir que os tokens e quaisquer metadados armazenados em cache sejam criptografados em repouso, nunca registrar conteúdo de e-mail que possa conter PHI e ter um Contrato de Associado Comercial (BAA) em vigor com o seu provedor de API. O Gmail e o Outlook oferecem configurações qualificadas para HIPAA nos planos Google Workspace e Microsoft 365 Business, respectivamente, com um BAA assinado pelo provedor. Sua camada de API de e-mail também deve assinar um BAA com você se ela processar ou transmitir PHI em seu nome. Do ponto de vista prático, o caminho mais seguro da HIPAA é tratar o conteúdo do e-mail como transitório - lê-lo, processá-lo, apresentá-lo - mas nunca manter o corpo ou os anexos em seu próprio banco de dados.
Revogar o acesso ao e-mail de um usuário envolve duas ações distintas que devem ocorrer. Primeiro, revogue o token no nível do provedor. Para o Gmail, chame o endpoint de revogação de token do Google (https://oauth2.googleapis.com/revokePara o Outlook, ligue para o endpoint de revogação da Microsoft ou remova o aplicativo da conta Microsoft do usuário. A simples exclusão do token do seu banco de dados não é suficiente - o token permanece válido no provedor até ser explicitamente revogado. Em segundo lugar, limpe todos os dados locais. Exclua o token de atualização, quaisquer tokens de acesso em cache, todos os metadados de e-mail que você armazenou para essa conta vinculada, assinaturas de webhook e o próprio registro da conta vinculada. Com o Unipile, um único DELETE /contas/{id} A chamada executa as duas etapas – revoga o token no provedor e limpa todos os dados associados na infraestrutura da Unipile simultaneamente.
A segurança de e-mail geralmente se refere à proteção da comunicação de e-mail em si – filtragem de spam, detecção de phishing, autenticação DKIM/SPF/DMARC e criptografia da mensagem em trânsito entre servidores de e-mail. A segurança de API de e-mail é uma camada completamente diferente: trata de como um aplicativo de terceiros obtém acesso programático à caixa de correio de um usuário, quais dados ele manipula como resultado e como protege esse acesso. Você pode ter excelente segurança de e-mail (DMARC configurado, TLS aplicado entre servidores) ao mesmo tempo em que tem uma segurança de API de e-mail fraca (senhas armazenadas em texto simples, escopos OAuth excessivamente amplos). Ambos importam independentemente. Este artigo foca na camada de segurança de API – as decisões arquiteturais que sua equipe de desenvolvimento toma ao se integrar com Gmail, Outlook ou IMAP por meio de uma API.
Unipile não armazena persistentemente o conteúdo de e-mails. Quando seu aplicativo chama a API da Unipile para recuperar e-mails, a Unipile busca os dados do provedor (servidor Gmail, Outlook ou IMAP) em tempo real e os retorna ao seu aplicativo. Corpos de e-mail e anexos não são cacheados ou armazenados na infraestrutura da Unipile além do ciclo de vida da solicitação. O que a Unipile armazena é o token OAuth (criptografado em repouso) e metadados básicos de contas vinculadas necessários para manter a conexão – tipo de provedor, identificador da conta e status da conexão. Essa arquitetura significa que o conteúdo do e-mail permanece entre seu aplicativo e o provedor, com a Unipile atuando como o intermediário seguro em vez de um repositório de dados. Para detalhes completos sobre como a Unipile lida com os dados, consulte a documentação do desenvolvedor e solicite um DPA da equipe da Unipile.
OAuth 2.0 melhora a segurança da integração de e-mail de quatro maneiras concretas. Nenhuma exposição de credenciais: a senha do usuário nunca sai do servidor do provedor - sua aplicação só recebe um token de acesso de curta duração. Permissões granulares: Escopos OAuth permitem solicitar exatamente o acesso que você precisa (somente leitura, somente envio) em vez de controle total da caixa de correio. Revogabilidade: Um usuário pode remover o acesso ao seu aplicativo nas configurações de sua conta Google ou Microsoft a qualquer momento, sem alterar sua senha, e o token se torna imediatamente inválido. Tokens de curta duração: tokens de acesso expiram (geralmente após uma hora), limitando a janela de exposição caso um token seja comprometido. Essas propriedades tornam o OAuth 2.0 o único mecanismo de autenticação aceitável para integrações do Gmail e do Outlook em aplicações SaaS de produção. Saiba como implementá-lo para Google OAuth 2.0 e Microsoft OAuth 2.0.
Ainda tem dúvidas? Nossa equipe está aqui para ajudar.
BR 
EN 
FR 
ES 
DE 
IT 
NL 
PL 
TR