Cómo proteger su cuenta de envío de correo: acceso del equipo, credenciales y respuesta ante una vulneración

Una buena seguridad de la cuenta de envío de correo marca la diferencia entre una mala tarde y un mal trimestre. Si alguien toma el control de la cuenta con la que usted envía correo, hereda su dominio autenticado, su reputación de envío y la confianza de sus clientes. En pocas horas puede enviar phishing o spam que supera todas las comprobaciones técnicas, y usted puede tardar semanas en recuperarse de las inclusiones en listas de bloqueo y del filtrado que siguen. Queremos ayudarle a que eso sea improbable y superable. Esta guía explica quién debe tener acceso y con qué nivel, cómo proteger los inicios de sesión, cómo gestionar las credenciales por aplicación, cómo dar de baja a las personas, qué aspecto tiene una vulneración en sus datos y qué hacer durante la primera hora.

Todo lo que sigue son buenas prácticas generales aplicables a cualquier plataforma de envío. Cuando un control depende de su plan o de su configuración, lo indicamos, y lo correcto es comprobar qué controles ofrece su cuenta de MigoSMTP antes de planificar en función de ellos. No damos por sentados nombres de roles ni funciones de inicio de sesión concretos.

Por qué se atacan las cuentas de envío

A los atacantes les atraen las cuentas de envío por las mismas razones que a usted. La infraestructura es fiable, el dominio está autenticado y el correo llega a la bandeja de entrada. Un inicio de sesión robado o una clave filtrada convierte todo eso en una herramienta para ellos. Entre sus objetivos habituales están las campañas de phishing que usan su marca, el spam masivo, el fraude con facturas y el abuso de restablecimientos de contraseña dirigido a terceros.

El daño rara vez se limita al atacante. Los proveedores de buzones juzgan su dominio y sus direcciones IP por lo que observan, de modo que una ráfaga de correo abusivo reduce la entrega de sus mensajes legítimos durante días o semanas. Los destinatarios que reciben correo fraudulento en su nombre pierden una confianza difícil de reconstruir. Si además la cuenta expone listas de destinatarios, registros de entrega o contenido de mensajes, puede surgir un problema de protección de datos sumado al problema de entregabilidad.

Acceso del equipo y privilegios mínimos

Privilegios mínimos significa que cada persona y cada programa recibe el acceso mínimo necesario para su tarea y nada más. Es la idea más eficaz de la seguridad de cuentas, porque limita lo que puede hacer una credencial robada. Empiece por anotar quién tiene acceso hoy y por qué. A la mayoría de los equipos les sorprende lo que encuentran: antiguos contratistas, una agencia de hace dos años, un fundador que configuró la cuenta y se la traspasó a otra persona.

Separe los roles

Incluso un equipo pequeño se beneficia de pensar en grupos de roles. Si su cuenta dispone de roles integrados, permisos personalizados o solo de un único inicio de sesión de propietario es algo que debe comprobar en su cuenta de MigoSMTP. La tabla muestra la división que sugerimos como objetivo y el razonamiento que la sustenta. Adáptela a los controles que realmente tenga.

Dos reglas prácticas ayudan. Primera: mantenga el número de propietarios en la cifra más baja que siga funcionando cuando alguien esté de vacaciones, que suele ser dos. Segunda: no permita que nadie use un inicio de sesión de propietario para el trabajo ordinario. Si alguien de marketing necesita enviar una campaña, debe hacerlo con su rol de marketing.

El acceso individual es mejor que los inicios de sesión compartidos

Un inicio de sesión compartido resulta cómodo el primer día y caro para siempre. No se sabe quién cambió un ajuste, todos los que alguna vez conocieron la contraseña siguen siendo un riesgo y rotarla interrumpe a todo el equipo. Dé a cada persona un usuario nominal. Si su cuenta lo admite, vincule el inicio de sesión al sistema de identidad de su empresa para que desactivar a una persona en un solo lugar le retire el acceso en todas partes. Si su cuenta no ofrece usuarios nominales en su plan, trátelo como un riesgo que debe registrar y compénselo con un manejo más estricto de las credenciales y más monitoreo.

Proteja los inicios de sesión con autenticación de dos factores

Un segundo factor implica que una contraseña robada no basta para iniciar sesión. La guía del NIST sobre identidad digital considera la autenticación multifactor un control esencial, y la guía de autenticación de OWASP la recomienda para las cuentas que conllevan un riesgo real. Una cuenta de envío sin duda lo conlleva. Si su cuenta de MigoSMTP ofrece autenticación de dos factores, actívela para todos los usuarios, empezando por los propietarios y quienes puedan gestionar credenciales.

• Prefiera métodos resistentes al phishing. Las llaves de seguridad físicas y las passkeys resisten mejor las páginas de inicio de sesión falsas que los códigos recibidos por mensaje de texto. Las aplicaciones de autenticación son una opción intermedia sólida. Los códigos por SMS son mejores que nada, pero son la opción más débil.
• Use un gestor de contraseñas. Cada usuario debe tener una contraseña larga y única para la cuenta. La reutilización entre sitios es la forma en que ocurren realmente la mayoría de las tomas de control de cuentas.
• Proteja la vía de recuperación. Un atacante que no puede vencer su inicio de sesión puede ir tras el restablecimiento de contraseña. Proteja con la misma fortaleza de inicio de sesión el buzón que recibe los mensajes de restablecimiento y guarde los códigos de recuperación en un lugar seguro y sin conexión.
• No dependa de una función que quizá no exista. Aquí no afirmamos que exista ninguna función de inicio de sesión concreta. Compruebe qué controles ofrece su cuenta de MigoSMTP y, si falta alguno, compénselo protegiendo con más rigor la identidad y el buzón que hay detrás de cada inicio de sesión.

Credenciales SMTP y claves API: una por aplicación

Las personas inician sesión en un panel, mientras que los programas se autentican con credenciales SMTP o claves API. Ambas son secretos que permiten al software enviar correo en su nombre, y ambas suelen acabar en repositorios, mensajes de chat, tickets y copias de seguridad antiguas de servidores. Nuestra guía sobre seguridad, permisos, almacenamiento y rotación de claves API profundiza en la parte técnica. Los principios para la seguridad de la cuenta son estos.

• Una credencial por aplicación y por entorno. Producción, preproducción y cada servicio independiente tienen la suya. Si una se filtra, usted revoca una y las demás siguen funcionando. Además, sus registros le indican qué sistema hace cada cosa.
• El permiso más restringido disponible. Un servicio que solo envía no necesita gestionar usuarios ni leer datos. Siempre que se pueda limitar una clave, límitela.
• Mantenga los secretos fuera del código. Use variables de entorno o un gestor de secretos. Añada análisis a sus repositorios y a sus canalizaciones de compilación para detectar una confirmación accidental antes de que se propague.
• No pegue secretos en chats ni en correos. Compártalos mediante el gestor de secretos para que el acceso quede registrado y pueda retirarse.
• Rote según un calendario y tras cualquier exposición. Cree la nueva credencial, despliéguela, confirme que el envío funciona y solo entonces revoque la anterior. Nunca revoque primero en un sistema activo sin un plan.
• Póngales nombre y fecha. Una credencial nombrada según su responsable, su sistema y su fecha de creación es fácil de auditar. Una credencial llamada test2 es un misterio a la espera de provocar una caída.

Si todavía está decidiendo cómo debe conectarse una aplicación concreta, nuestra comparación del envío por SMTP y por API explica las ventajas e inconvenientes, y toda conexión debe usar TLS, como explica la RFC 8314. Una credencial enviada por un enlace sin cifrar es una credencial regalada.

Baja de personas, contratistas y agencias

La mayoría de los problemas de acceso no son ataques en absoluto. Son antiguos empleados, contratos vencidos e integraciones olvidadas que siguen funcionando. Un procedimiento de baja por escrito convierte esto de una decisión incómoda en una lista de verificación, y sirve igual para empleados, autónomos y agencias.

1. Elimine o desactive al usuario nominal el día de su salida. Si el inicio de sesión está vinculado a su proveedor de identidad, desactívelo primero allí.
2. Enumere todas las credenciales que la persona podía leer o crear, incluidas las claves de aplicación en el gestor de secretos, los repositorios y los tickets antiguos.
3. Rote esas credenciales, empezando por las de producción. Los secretos compartidos son la razón de que las bajas resulten difíciles, lo cual es otro argumento a favor de las credenciales por aplicación.
4. Revise los últimos treinta días de su actividad: usuarios creados, credenciales emitidas, ajustes modificados, exportaciones realizadas.
5. Compruebe los webhooks, las reglas de reenvío y las integraciones de API que configuró y elimine las que no pueda justificar.
6. Transfiera la titularidad de campañas, plantillas y automatizaciones a un compañero concreto, para que el trabajo no se interrumpa cuando desaparezca la cuenta.
7. Registre la fecha, los pasos realizados y quién los confirmó.

Haga lo mismo cuando termine la relación con una agencia o un proveedor. Los terceros externos suelen tener el acceso más privilegiado y el menor apego a sus políticas de seguridad.

Detecte pronto una cuenta vulnerada

Los atacantes rara vez anuncian su presencia. Envían rápido, antes de que nadie lo note, así que su mejor defensa es saber qué es lo normal y vigilar las desviaciones. Así se interpretan desde el punto de vista de la seguridad.

Cree alertas a las que la gente realmente responda

• Fije umbrales relativos a su patrón normal, por ejemplo un múltiplo del volumen horario habitual, en lugar de una cifra que alguien adivinó una vez.
• Envíe las alertas al menos a dos personas y a un canal compartido, para que unas vacaciones o un mensaje perdido no oculten un incidente.
• Compruebe qué alertas y registros ofrece su cuenta de MigoSMTP y cubra las carencias con comprobaciones por su parte, como contar los mensajes que envían sus aplicaciones.
• Revise un breve resumen semanal de volumen, rebotes, quejas y credenciales nuevas. Un silencio inusual también merece atención, ya que una integración rota es un problema en sí misma.

Un ejemplo práctico: detectar y contener una clave filtrada

Este es un ejemplo inventado con cifras ilustrativas, para mostrar cómo encajan las señales y la respuesta. Una pequeña tienda en línea envía normalmente unos 400 mensajes al día, todos desde un único servicio de confirmación de pedidos, con una tasa de rebotes cercana al 1 por ciento y casi sin quejas.

El daño en este ejemplo fueron unos 3.000 mensajes no deseados en unos veinte minutos, en lugar de cientos de miles a lo largo de un fin de semana. Ese resultado se debió a tres decisiones previas: credenciales separadas por entorno, una alerta basada en el volumen normal y una persona de guardia que sabía que podía revocar una clave sin pedir permiso antes.

Respuesta a incidentes: la primera hora y después

Decida el plan antes de necesitarlo. Durante un incidente las personas están bajo estrés, y la mitad del retraso viene de no saber quién puede hacer qué. El NIST publica una guía de gestión de incidentes ampliamente usada (SP 800-61) cuyas fases son preparación, detección y análisis, contención, erradicación y recuperación, y lecciones aprendidas. Los pasos siguientes tienen la misma estructura, adaptada a una cuenta de envío.

1. Contenga. Revoque la credencial sospechosa, desactive al usuario sospechoso o pause la aplicación afectada. Hágalo primero, antes de estar seguro de la causa. Prefiera la acción más acotada que detenga el abuso.
2. Conserve las pruebas. Exporte los registros, muestras de mensajes y la lista de usuarios y credenciales antes de que cambien. Anote las horas en una única zona horaria.
3. Evalúe el alcance. Determine qué se envió, a quién, desde qué credencial y durante cuánto tiempo. Compruebe si se leyeron o modificaron datos de destinatarios, plantillas o ajustes.
4. Erradique. Rote todas las credenciales que el atacante pudo ver. Restablezca contraseñas y sesiones de los usuarios afectados, active o revise los segundos factores y elimine todo lo que usted no creó, como usuarios, webhooks y reglas de reenvío.
5. Recupere. Restablezca el envío legítimo por etapas, empezando por el correo más crítico. Vigile de cerca las tasas de rebotes y quejas. Si el correo fue bloqueado, siga los pasos de cómo eliminar una inclusión en una lista de bloqueo.
6. Comunique. Informe primero a las partes interesadas internas. Consulte con su contacto de cumplimiento las obligaciones legales o contractuales de notificación. Si los destinatarios recibieron correo fraudulento, dígalo con claridad e indíqueles qué deben ignorar.
7. Aprenda. En el plazo de una semana, haga una breve revisión sin culpas. Corrija la causa raíz, actualice este plan y añada la detección que lo habría descubierto antes.

Lista de verificación de seguridad para su cuenta de envío

• Cada persona tiene un usuario nominal y no queda ningún inicio de sesión compartido.
• El grupo de propietarios tiene como máximo dos miembros y nadie lo usa para el trabajo diario.
• Los roles siguen la división entre desarrollador, marketing, finanzas y auditor, en la medida en que su cuenta lo permita.
• La autenticación de dos factores está activada para todos los usuarios donde esté disponible, y las vías de recuperación están protegidas.
• Cada aplicación y entorno tiene su propia credencial, con nombre y fecha, con el permiso más restringido disponible.
• Los secretos están en un gestor de secretos o en variables de entorno, y los repositorios se analizan en busca de filtraciones.
• Existen alertas de volumen, rebotes, quejas, credenciales nuevas y ubicaciones de inicio de sesión inusuales, y llegan al menos a dos personas.
• Existe un procedimiento de baja y se aplica al personal, los contratistas y las agencias.
• El plan de respuesta a incidentes está escrito, nombra responsables para cada paso e incluye una vía de contacto de emergencia con nosotros.
• Las revisiones de acceso y la rotación de credenciales se hacen según un calendario, al menos cada trimestre.
• Su dominio de envío está autenticado y monitoreado; consulte cómo autenticar un dominio de envío.

Fuentes y lecturas adicionales

Estas referencias públicas respaldan las prácticas descritas. Son orientaciones generales, no afirmaciones sobre ninguna función de MigoSMTP.

• NIST SP 800-61 Rev. 2, Guía de gestión de incidentes de seguridad informática
• NIST SP 800-63B, Directrices de identidad digital: autenticación y gestión del ciclo de vida
• Hoja de referencia de autenticación de OWASP
• Hoja de referencia de gestión de secretos de OWASP
• RFC 8314, El texto sin cifrar se considera obsoleto: uso de TLS para el envío y el acceso al correo
• RFC 7489, Autenticación, informes y conformidad de mensajes basados en dominio (DMARC)