A segurança de chaves de API se resume a quatro hábitos: dar a cada chave o menor conjunto de permissões de que ela precisa, guardá-la em um repositório de segredos adequado, fazer a rotação sem downtime e ter um plano pronto para o dia em que uma delas vazar. Uma chave de envio vazada permite que qualquer pessoa envie e-mails como se fosse você, e por isso coloca em risco a sua reputação de remetente, além dos seus dados.
Confira os nomes das permissões na sua conta. Os nomes de permissões neste guia são exemplos do padrão. Use as opções que a sua conta MigoSMTP realmente oferece e escolha a mais restrita que funcione.
Por que as chaves vazam
| Como vaza | Exemplo | Prevenção |
|---|---|---|
| Enviada em um commit para um repositório | Um arquivo de configuração com uma chave é enviado a um repositório público ou compartilhado | Use variáveis de ambiente, arquivos de ignore e varredura de segredos |
| Enviada ao cliente | Uma chave dentro de JavaScript ou de um aplicativo móvel | Chame o seu próprio servidor |
| Compartilhada em chat ou tickets | Uma chave colada em uma conversa de suporte | Compartilhe por meio de um gerenciador de segredos e faça a rotação se ela for exposta |
| Esquecida em uma conta de quem saiu | Um ex-prestador de serviços ainda tem a chave | Faça a rotação quando pessoas saírem |
| Registrada acidentalmente em logs | Um log de depuração imprime cabeçalhos de requisição | Mascare segredos nos logs |
| Servidor comprometido | Um malware lê variáveis de ambiente | Aplique patches nos servidores e limite o que cada servidor pode acessar |
Etapa 1: uma chave por aplicação e ambiente
Crie chaves separadas para produção, homologação e cada aplicação que envia e-mails. Dê nomes a elas para que você as reconheça em um log de auditoria.
| Nome da chave | Usada por | Permissão |
|---|---|---|
| shop-production | A loja virtual, e-mails de pedidos | Somente envio |
| shop-staging | Ambiente de teste | Somente envio, para endereços de teste |
| crm-production | O CRM, envio de campanhas | Envio e gerenciamento dos próprios contatos |
| webhooks-reader | Uma rotina de relatórios | Somente leitura de eventos |
| ops-admin | Uma pessoa identificada, tarefas raras | Acesso total com autenticação de dois fatores |
Etapa 2: aplique o privilégio mínimo
Pergunte sobre cada chave: qual é o mínimo de que ela precisa para fazer o trabalho? Enviar e-mails não exige ler a sua lista de contatos, alterar o DNS ou gerenciar a cobrança, e uma rotina de relatórios não deveria conseguir enviar nada.
- Dê preferência a uma chave somente de envio para qualquer sistema que apenas entrega mensagens.
- Reserve a gestão de conta, cobrança e usuários para pessoas com autenticação de dois fatores, não para chaves.
- Revise as permissões a cada trimestre e remova o que não for mais necessário.
- Se a sua conta oferecer restrições por endereço IP, domínio ou limite de taxa, use-as. Consulte as configurações de segurança da conta para ver o que está disponível.
Etapa 3: armazene as chaves com segurança
Carregue a chave em tempo de execução a partir do ambiente ou de um gerenciador de segredos. Um padrão mínimo está abaixo.
# .env (never commit this file)
MIGOSMTP_API_KEY=replace-with-your-key
# .gitignore
.env
*.pem<?php
$key = getenv('MIGOSMTP_API_KEY');
if (!$key) {
throw new RuntimeException('API key is not configured');
}Adicione a varredura de segredos. Ative a varredura de segredos na sua plataforma de código e execute um scanner no pipeline de build. Ela detecta chaves antes que cheguem a uma branch compartilhada e envia um alerta se alguma escapar.
Etapa 4: faça a rotação sem downtime
- Crie a nova chave. Dê a ela as mesmas permissões e um nome com a data ou a versão.
- Armazene-a. Adicione-a ao seu gerenciador de segredos ou à configuração de ambiente.
- Faça o deploy. Publique a mudança e reinicie os serviços que leem a chave.
- Verifique. Confira os logs de entrega para confirmar que o tráfego usa a nova chave.
- Revogue a chave antiga. Faça isso somente depois que o tráfego tiver migrado. Aguarde um curto período e verifique se há falhas.
- Registre. Anote a data, o motivo e quem fez.
Etapa 5: monitore em busca de abuso
| Sinal | O que pode significar | Ação |
|---|---|---|
| Volume muito acima do normal | Uma chave vazada ou um loop no seu código | Pause a chave e investigue |
| Destinatários novos ou desconhecidos | Spam ou phishing enviado com a sua chave | Revogue a chave e revise as mensagens |
| Envios em horários incomuns | Abuso automatizado | Verifique o IP de origem e restrinja o acesso |
| Aumento de bounces ou reclamações | Destinatários ruins ou abuso | Verifique a supressão e as origens, veja o checklist de spam |
| Requisições de novos endereços IP | Uma chave usada fora dos seus servidores | Adicione uma lista de IPs permitidos e faça a rotação |
Se uma chave vazar: a primeira hora
| Minutos | Faça isto |
|---|---|
| 0 a 10 | Revogue a chave. Se ainda não conseguir fazer o deploy de uma substituta, aceite uma breve indisponibilidade em vez de abuso contínuo |
| 10 a 30 | Crie e faça o deploy de uma nova chave. Confirme que o envio voltou ao normal |
| 30 a 60 | Revise o log de entrega em busca de mensagens que você não enviou. Verifique as taxas de reclamação e de bounce e as listas de bloqueio |
| Depois | Descubra como ela vazou, elimine a origem, faça a rotação de segredos relacionados e registre o que aprendeu |
Se e-mails foram enviados em seu nome, siga o guia de remoção de listas de bloqueio e entre em contato com o suporte para que a análise da conta tenha contexto.
Acha que uma chave foi exposta? Revogue-a primeiro e depois fale conosco, informando o nome da chave e o horário, para que possamos ajudar você a revisar os envios recentes.
Leituras complementares e fontes
Perguntas frequentes
Por que uma chave de API de e-mail é tão sensível?
Qualquer pessoa que tenha uma chave de envio pode enviar e-mails como se fosse você. Atacantes usam chaves vazadas para enviar phishing e spam em minutos, o que pode levar o seu domínio e os seus IPs a listas de bloqueio e a sua conta a ser suspensa. O custo está na reputação, que leva semanas para ser reparada.
O que privilégio mínimo significa para chaves de API?
Significa que cada chave pode fazer somente o que a sua função exige, e nada além. Uma chave usada por um formulário web para enviar e-mails não deve poder ler contatos, alterar domínios ou gerenciar a cobrança. Se ela vazar, o dano fica limitado ao que aquela chave tinha permissão de fazer.
Devo usar uma única chave para tudo?
Não. Use uma chave separada para cada aplicação e ambiente. Se uma vazar, você revoga somente essa chave, e os seus logs mostram de qual sistema veio uma mensagem. Chaves compartilhadas tornam a resposta a incidentes lenta e arriscada.
Onde devo armazenar as chaves de API?
Use variáveis de ambiente ou um gerenciador de segredos e carregue-as em tempo de execução. Não coloque chaves no código-fonte, no front-end de um site ou aplicativo móvel, em repositórios públicos, em tickets ou em chats. Adicione ao seu arquivo de ignore os arquivos de configuração que guardam segredos.
Com que frequência devo fazer a rotação das chaves?
Uma regra comum é a cada 90 dias para chaves de produção, e imediatamente quando uma pessoa com acesso sai da empresa, um notebook é perdido ou há suspeita de vazamento. Mais importante que o intervalo é ter um processo de rotação que você já tenha praticado.
Como faço a rotação de uma chave sem downtime?
Crie uma nova chave, adicione-a ao seu repositório de segredos, faça o deploy da mudança, confirme que o tráfego usa a nova chave e só então revogue a chave antiga. Nunca revogue primeiro, pois isso causa uma indisponibilidade enquanto você faz o deploy.
O que devo fazer se uma chave vazar?
Revogue a chave imediatamente, crie uma substituta, faça o deploy dela, revise os envios recentes em busca de mensagens que você não enviou e verifique se há listagens em listas de bloqueio e picos de reclamações. Depois, descubra como ela vazou e feche esse caminho.
Como saber se uma chave está sendo usada de forma abusiva?
Fique atento a picos repentinos de volume, destinatários novos ou incomuns, envios em horários estranhos, aumento de bounces ou reclamações e requisições de endereços IP desconhecidos. Alertas de volume e de taxa de bounce dão um aviso antecipado.
As credenciais SMTP são diferentes das chaves de API?
Elas servem ao mesmo propósito, que é comprovar que você pode enviar, e exigem o mesmo cuidado. Trate o usuário e a senha SMTP como uma chave de API: um conjunto por aplicação, armazenado como segredo e com rotação em um cronograma. Consulte o guia de configurações de SMTP para os detalhes de conexão.
Posso colocar uma chave de API em um aplicativo móvel ou em JavaScript de uma página web?
Não. Tudo o que é enviado a um dispositivo ou navegador pode ser extraído. Envie e-mails a partir do seu próprio servidor e deixe que o aplicativo ou a página chame o seu servidor, que então chama a API de e-mail com a chave.