Como proteger sua conta de envio de e-mail: acesso da equipe, credenciais e resposta a comprometimentos

Uma boa segurança da conta de envio de e-mail é a diferença entre uma tarde ruim e um trimestre ruim. Se alguém assume a conta que você usa para enviar e-mails, herda seu domínio autenticado, sua reputação de envio e a confiança dos seus clientes. Em poucas horas, essa pessoa pode enviar phishing ou spam que passa por todas as verificações técnicas, e você pode levar semanas para se recuperar das listas de bloqueio e da filtragem que se seguem. Queremos ajudar você a tornar isso improvável e superável. Este guia aborda quem deve ter acesso e em que nível, como proteger os logins, como tratar credenciais por aplicação, como desligar pessoas, como um comprometimento aparece nos seus dados e o que fazer na primeira hora.

Tudo aqui são boas práticas gerais, aplicáveis a qualquer plataforma de envio. Quando um controle depende do seu plano ou da sua configuração, dizemos isso, e o certo é verificar quais controles a sua conta MigoSMTP oferece antes de planejar com base neles. Não presumimos nomes de papéis específicos nem recursos de login específicos.

Por que contas de envio são alvos

Os invasores gostam de contas de envio pelos mesmos motivos que você. A infraestrutura é confiável, o domínio é autenticado e os e-mails chegam às caixas de entrada. Um login roubado ou uma chave vazada transforma tudo isso em uma ferramenta para eles. Os objetivos típicos incluem campanhas de phishing que usam a sua marca, spam em massa, fraude de faturas e abuso de redefinição de senha direcionado a terceiros.

O dano raramente se limita ao invasor. Os provedores de caixa de entrada avaliam seu domínio e seus endereços IP pelo que veem, portanto uma rajada de e-mails abusivos reduz a entrega das suas mensagens legítimas por dias ou semanas. Os destinatários que recebem e-mails fraudulentos em seu nome perdem a confiança, e ela é difícil de reconquistar. Se a conta também expõe listas de destinatários, logs de entrega ou conteúdo de mensagens, pode haver um problema de proteção de dados além do problema de entregabilidade.

Acesso da equipe e privilégio mínimo

Privilégio mínimo significa que cada pessoa e cada programa recebe o acesso mínimo necessário para a tarefa e nada além disso. É a ideia isolada mais eficaz em segurança de contas, porque limita o que uma credencial roubada pode fazer. Comece anotando quem tem acesso hoje e por quê. A maioria das equipes se surpreende: ex-prestadores de serviço, uma agência de dois anos atrás, um fundador que configurou a conta e passou adiante.

Separe os papéis

Mesmo uma equipe pequena se beneficia de pensar em grupos de papéis. Se a sua conta tem papéis integrados, permissões personalizadas ou apenas um login de proprietário é algo que você deve verificar na sua conta MigoSMTP. A tabela mostra a divisão que sugerimos como meta e a lógica por trás dela. Adapte-a aos controles que você realmente tem.

Duas regras práticas ajudam. Primeiro, mantenha o número de proprietários no menor valor que ainda sobreviva à ausência de alguém em férias, o que geralmente significa dois. Segundo, não deixe as pessoas usarem um login de proprietário para o trabalho comum. Se um profissional de marketing precisa enviar uma campanha, deve fazê-lo como profissional de marketing.

Acesso individual é melhor do que logins compartilhados

Um login compartilhado é conveniente no primeiro dia e caro para sempre depois. Você não sabe quem alterou uma configuração, todos que já souberam a senha continuam sendo um risco e trocá-la interrompe a equipe inteira. Dê a cada pessoa um usuário nominal. Quando a sua conta permitir, vincule o login ao sistema de identidade da empresa, para que desativar uma pessoa em um único lugar remova o acesso em todos os outros. Se a sua conta não oferece usuários nominais no seu plano, trate isso como um risco a registrar e compense com um manuseio mais rigoroso das credenciais e mais monitoramento.

Proteja os logins com autenticação em dois fatores

Um segundo fator significa que uma senha roubada, sozinha, não basta para fazer login. As diretrizes do NIST sobre identidade digital tratam a autenticação multifator como um controle essencial, e as orientações de autenticação da OWASP a recomendam para contas que carregam risco real. Uma conta de envio certamente se enquadra. Se a sua conta MigoSMTP oferece autenticação em dois fatores, ative-a para todos os usuários, começando pelos proprietários e por quem pode gerenciar credenciais.

• Prefira métodos resistentes a phishing. Chaves de segurança físicas e passkeys resistem melhor a páginas de login falsas do que códigos digitados a partir de uma mensagem de texto. Aplicativos autenticadores são uma boa opção intermediária. Códigos por mensagem de texto são melhores do que nada, mas são a escolha mais fraca.
• Use um gerenciador de senhas. Cada usuário deve ter uma senha longa e única para a conta. A reutilização entre sites é como a maioria das invasões de conta realmente acontece.
• Proteja o caminho de recuperação. Um invasor que não consegue vencer o seu login pode tentar a redefinição de senha. Proteja a caixa de e-mail que recebe as mensagens de redefinição com o mesmo nível de segurança de login e guarde os códigos de recuperação em um lugar seguro e offline.
• Não dependa de um recurso que pode não existir. Não afirmamos aqui nenhum recurso de login específico. Verifique quais controles a sua conta MigoSMTP oferece e, se faltar algum, compense protegendo com mais rigor a identidade e a caixa de e-mail por trás de cada login.

Credenciais SMTP e chaves de API: uma por aplicação

As pessoas fazem login em um painel, enquanto os programas se autenticam com credenciais SMTP ou chaves de API. Ambas são segredos que permitem a um software enviar e-mails em seu nome, e ambas costumam acabar em repositórios, mensagens de chat, tickets e backups antigos de servidores. Nosso guia sobre segurança de chaves de API, permissões, armazenamento e rotação aprofunda a parte mecânica. Os princípios de segurança da conta são estes.

• Uma credencial por aplicação e por ambiente. Produção, homologação e cada serviço separado têm a sua. Se uma vazar, você revoga uma e as demais continuam funcionando. Seus logs também mostram qual sistema está fazendo o quê.
• A menor permissão disponível. Um serviço que só envia não precisa gerenciar usuários nem ler dados. Sempre que uma chave puder ser limitada, limite-a.
• Mantenha os segredos fora do código. Use variáveis de ambiente ou um gerenciador de segredos. Adicione varredura aos seus repositórios e pipelines de build para que um commit acidental seja detectado antes de se espalhar.
• Não cole segredos em chats ou e-mails. Compartilhe pelo gerenciador de segredos, para que o acesso seja registrado e possa ser retirado.
• Faça a rotação periodicamente e após qualquer exposição. Crie a nova credencial, implante-a, confirme que o envio funciona e só então revogue a antiga. Nunca revogue primeiro em um sistema em produção sem um plano.
• Dê nome e data a elas. Uma credencial nomeada com o responsável, o sistema e a data de criação é fácil de auditar. Uma credencial chamada test2 é um mistério esperando para causar uma interrupção.

Se você ainda está decidindo como uma determinada aplicação deve se conectar, nossa comparação entre envio por SMTP e por API cobre os prós e contras, e toda conexão deve usar TLS, como explica a RFC 8314. Uma credencial enviada por um link sem criptografia é uma credencial entregue de bandeja.

Desligamento de pessoas, prestadores de serviço e agências

A maioria dos problemas de acesso nem são ataques. São ex-funcionários, contratos encerrados e integrações esquecidas que ainda funcionam. Uma rotina de desligamento por escrito transforma isso de uma decisão desconfortável em uma lista de verificação, e ela vale para funcionários, freelancers e agências.

1. Remova ou desative o usuário nominal no dia da saída. Se o login estiver vinculado ao seu provedor de identidade, desative a pessoa primeiro lá.
2. Liste todas as credenciais que a pessoa podia ler ou criar, incluindo chaves de aplicação no gerenciador de segredos, em repositórios e em tickets antigos.
3. Faça a rotação dessas credenciais, começando pela produção. Segredos compartilhados são o motivo de o desligamento ser trabalhoso, o que é mais um argumento a favor de credenciais por aplicação.
4. Revise os últimos trinta dias de atividade da pessoa: usuários criados, credenciais emitidas, configurações alteradas, exportações executadas.
5. Verifique webhooks, regras de encaminhamento e integrações de API que ela configurou e remova aqueles que você não consegue justificar.
6. Transfira a titularidade de campanhas, modelos e automações para um colega nomeado, para que o trabalho não pare quando a conta da pessoa desaparecer.
7. Registre a data, as etapas realizadas e quem as confirmou.

Faça o mesmo quando o contrato com uma agência ou fornecedor terminar. Terceiros costumam ter o acesso mais privilegiado e o menor vínculo com as suas políticas de segurança.

Identifique cedo uma conta comprometida

Os invasores raramente se anunciam. Eles enviam rápido, antes que alguém perceba, então sua melhor defesa é saber como é o normal e vigiar os desvios dele. Veja como interpretá-los do ponto de vista de segurança.

Crie alertas aos quais as pessoas realmente respondam

• Defina limites relativos ao seu padrão normal, por exemplo um múltiplo do volume horário habitual, em vez de um número que alguém chutou uma vez.
• Envie os alertas para pelo menos duas pessoas e para um canal compartilhado, para que férias ou uma mensagem perdida não escondam um incidente.
• Verifique quais alertas e logs a sua conta MigoSMTP fornece e preencha as lacunas com verificações do seu lado, como contar as mensagens que as suas aplicações enviam.
• Revise um breve resumo semanal de volume, bounces, reclamações e novas credenciais. Um silêncio incomum também merece atenção, já que uma integração quebrada é um problema por si só.

Um exemplo prático: identificar e conter uma chave vazada

Eis um exemplo inventado, com números ilustrativos, para mostrar como os sinais e a resposta se encaixam. Uma pequena loja virtual normalmente envia cerca de 400 mensagens por dia, todas de um único serviço de confirmação de pedidos, com taxa de bounce em torno de 1 por cento e quase nenhuma reclamação.

O dano neste exemplo foi de aproximadamente 3.000 mensagens indesejadas em cerca de vinte minutos, em vez de centenas de milhares ao longo de um fim de semana. Esse resultado veio de três decisões anteriores: credenciais separadas por ambiente, um alerta baseado no volume normal e uma pessoa de plantão que sabia que podia revogar uma chave sem pedir permissão antes.

Resposta a incidentes: a primeira hora e depois

Defina o plano antes de precisar dele. Durante um incidente as pessoas ficam sob estresse, e metade do atraso vem de não saber quem pode fazer o quê. O NIST publica um guia de tratamento de incidentes amplamente usado (SP 800-61), cujas fases são preparação, detecção e análise, contenção, erradicação e recuperação, e lições aprendidas. As etapas abaixo seguem o mesmo formato, adaptado a uma conta de envio.

1. Conter. Revogue a credencial suspeita, desative o usuário suspeito ou pause a aplicação afetada. Faça isso primeiro, antes de ter certeza da causa. Prefira a ação mais restrita que interrompa o abuso.
2. Preservar as evidências. Exporte logs, amostras de mensagens e a lista de usuários e credenciais antes que mudem. Registre os horários em um único fuso horário.
3. Avaliar o alcance. Estabeleça o que foi enviado, para quem, a partir de qual credencial e por quanto tempo. Verifique se algum dado de destinatários, modelos ou configurações foi lido ou alterado.
4. Erradicar. Faça a rotação de todas as credenciais que o invasor possa ter visto. Redefina senhas e sessões dos usuários afetados, ative ou reverifique os segundos fatores e remova tudo o que você não criou, como usuários, webhooks e regras de encaminhamento.
5. Recuperar. Retome o envio legítimo por etapas, começando pelos e-mails mais críticos. Acompanhe de perto as taxas de bounce e de reclamações. Se houve bloqueio de e-mails, siga as etapas de remoção de uma lista de bloqueio.
6. Comunicar. Avise primeiro as partes interessadas internas. Confirme com seu contato de compliance as obrigações legais ou contratuais de notificação. Se destinatários receberam e-mails fraudulentos, diga isso claramente e oriente o que devem ignorar.
7. Aprender. Em até uma semana, faça uma breve revisão sem culpados. Corrija a causa raiz, atualize este plano e adicione a detecção que a teria identificado mais cedo.

Uma lista de verificação de segurança para a sua conta de envio

• Cada pessoa tem um usuário nominal, e não restam logins compartilhados.
• O grupo de proprietários tem no máximo dois membros, e ninguém o usa no trabalho diário.
• Os papéis seguem a divisão entre desenvolvedor, profissional de marketing, financeiro e auditor, na medida em que a sua conta permitir.
• A autenticação em dois fatores está ativada para todos os usuários onde estiver disponível, e os caminhos de recuperação estão protegidos.
• Cada aplicação e ambiente tem sua própria credencial, com nome e data, e com a menor permissão disponível.
• Os segredos ficam em um gerenciador de segredos ou em variáveis de ambiente, e os repositórios são verificados quanto a vazamentos.
• Existem alertas para volume, bounces, reclamações, novas credenciais e locais de login incomuns, e eles chegam a pelo menos duas pessoas.
• Existe uma rotina de desligamento e ela é usada para funcionários, prestadores de serviço e agências.
• O plano de resposta a incidentes está escrito, define responsáveis para cada etapa e inclui um canal de contato de emergência conosco.
• As revisões de acesso e a rotação de credenciais acontecem em um calendário, pelo menos a cada trimestre.
• Seu domínio de envio está autenticado e monitorado; veja como autenticar um domínio de envio.

Fontes e leituras adicionais

Estas referências públicas embasaram as práticas acima. São orientações gerais, não afirmações sobre qualquer recurso do MigoSMTP.

• NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide
• NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management
• OWASP Authentication Cheat Sheet
• OWASP Secrets Management Cheat Sheet
• RFC 8314, Cleartext Considered Obsolete: Use of TLS for Email Submission and Access
• RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC)