Definir el alcance de la puerta de enlace saliente
Esta guía utiliza la documentación de implementación general de AsyncOS 16.0 para Cisco Secure Email Cloud Gateway, cuyo capítulo de Autenticación de correo electrónico tiene fecha del 3 de octubre de 2024. Es un plan de aceptación y configuración limitado a la versión, no una afirmación sobre la última versión o un inquilino inspeccionado. El flujo de trabajo de firma documentado crea una clave, asocia un perfil de dominio, publica material de verificación DNS y permite iniciar sesión en la política de salida. La ruta de la GUI descrita es Políticas de correo, Políticas de flujo de correo, RELAYED, luego DomainKeys/ DKIM Signing, seguido de enviar y confirmar. La verificación entrante es independiente de la firma saliente. Una discrepancia en el perfil puede dejar un mensaje sin firmar. Guía de autenticación de correo electrónico de Cisco
Ese flujo de trabajo limitado proporciona un punto de partida arquitectónico. No suministra la vivienda del inquilino. selector, clave privada, inventario de IP saliente o aprobado SPF autorización. El resto de este artículo es un método de revisión original para conectar el flujo de trabajo documentado con la evidencia del protocolo. Antes de implementarlo, el administrador responsable debe confirmar la versión real de la puerta de enlace, los controles admitidos, la autoridad de cambio y la ruta del mensaje. No se ha accedido a ninguna puerta de enlace y no se ha creado ninguna clave, política o mensaje aquí.
Comience con un contrato de ruta
Anote dónde se origina el mensaje y qué sistema realiza la conexión SMTP saliente final. Incluya cualquier retransmisión de aplicaciones, sistema de buzón ascendente, puerta de enlace, retransmisión descendente y salida orientada al destinatario. El objetivo es localizar el punto donde se debe evaluar la firma y la autorización SPF , no recopilar todas las direcciones de red interna. Mantenga la configuración confidencial en el registro de cambios controlados de la organización en lugar de incorporarla en un artículo ampliamente compartido.
Para cada ruta, registre el dominio visible esperado desde, SMTP CORREO DE dominio y destino DKIM dominio de firma. Se trata de identidades diferentes incluso cuando una organización deliberadamente las hace parecer similares. SPF evalúa la identidad SMTP relevante y la dirección de conexión. DKIM verifica una firma asociada con su dominio de firma. DMARC relaciona los identificadores autenticados calificados con el dominio del autor visible. La presencia de una puerta de enlace en una ruta no es una identidad autenticada en sí misma. RFC 7208 , secciones 2.3–2.4 RFC 6376 , sección 3.5 RFC 9989 , sección 4.4
El contrato de ruta debe incluir excepciones: avisos automatizados, remitentes delegados, aplicaciones con encabezados inusuales y correo que pasa por alto la puerta de enlace prevista. No acepte una configuración basada únicamente en un mensaje conveniente del personal. Decida qué rutas distintas requieren evidencia y cuáles están explícitamente fuera de la implementación. Esto produce un límite revisable en lugar de una declaración sin fundamento de que todo el correo electrónico corporativo está autenticado.
Separar la publicación de claves de la aceptación de la firma
Una implementación DKIM tiene al menos dos responsabilidades distintas. El firmante protege y utiliza la clave privada, mientras que DNS hace que el material de verificación correspondiente sea reconocible. La firma proporciona un selector y un dominio de firma que identifican la ubicación de la clave. La publicación de un valor TXT que parezca plausible no establece que la puerta de enlace posea la clave correspondiente ni firme la ruta prevista. Por el contrario, permitir la firma no prueba que el registro público esté disponible para los receptores. RFC 6376 , secciones 3.5 y 3.6.2.2
Utilice un registro de cambios que vincule el dominio de firma aprobado, el selector, la huella digital de clave pública o el identificador no secreto equivalente, el propietario DNS y la política prevista en la misma implementación. Nunca pegue claves privadas en la hoja de trabajo. Obtenga los requisitos criptográficos y de administración de claves actuales de la implementación admitida y la política de seguridad organizacional en lugar de copiar los mínimos históricos de una guía anterior. Este manuscrito no proporciona deliberadamente material de claves reutilizable ni comandos de generación de claves.
Revise el propietario DNS exacto independientemente de la visualización del editor. Una etiqueta de selector relativa puede expandirse mediante una interfaz DNS , mientras que un nombre completo puede requerir un manejo diferente. Conserve el nombre completo previsto y el contenido TXT lógico antes de la publicación. Varias cadenas dentro de una registro TXT no son lo mismo que múltiples registros de recursos en competencia. Una división de visualización o una comilla deben investigarse en contexto en lugar de tratarse automáticamente como corrupción. RFC 1035 , secciones 3.3.14 y 5.1
Revisar SPF en el límite de salida real
No invente una inclusión SPF para todo Cisco basada en el nombre del producto. La autorización relevante depende de la infraestructura de salida real y del dominio de envolvente. El operador responsable debe obtener información de salida aprobada actual, conciliarla con los remitentes legítimos existentes y revisar la política completa resultante. Una puerta de enlace alojada, una plataforma de buzón de correo ascendente y una aplicación pueden representar diferentes necesidades de autorización incluso cuando todas están administradas por el mismo equipo.
SPF debe publicarse como TXT en el dominio correspondiente. Múltiples aplicables Registros SPF producir un error en lugar de combinarse en una lista de permitidos más grande. El presupuesto de evaluación también se aplica a los términos de consulta de DNS evaluados de forma recursiva, no simplemente al número de cadenas de inclusión visibles en la política de nivel superior. Revise el comportamiento de las dependencias antes de agregar otro servicio y conserve un plan de reversión que no elimine silenciosamente a los remitentes existentes. RFC 7208 , secciones 3.1–3.3 y 4.6.4
Un resultado SPF aprobado para un dominio de sobre controlado por el proveedor no está necesariamente alineado con el dominio De visible de la organización. Cuando una ruta dependa de DKIM alineado, mantenga esa elección explícitamente. DMARC requiere un resultado SPF o DKIM alineado y calificado, pero un proyecto o proveedor puede imponer requisitos previos adicionales. No convierta las rutas alternativas del protocolo en permiso para ignorar los requisitos de la implementación. RFC 9989 , sección 4.4
Cree una secuencia de evidencia en lugar de una captura de pantalla del éxito
La secuencia de aceptación propuesta tiene puntos de control separados para la intención de configuración, DNS publicado y los mensajes recibidos reales. Primero, confirme que la configuración del inquilino admitida coincida con el contrato de ruta aprobado. En segundo lugar, conserve las observaciones DNS autorizadas con el nombre del propietario, el tipo, el valor lógico y el tiempo de observación. En tercer lugar, evaluar un mensaje aprobado recibido fuera del sistema de envío, registrando los identificadores relevantes y los resultados de la autenticación sin publicar correspondencia privada.
Cuando la evidencia no esté de acuerdo, diagnostique la capa antes de cambiar la política. Un mensaje sin firmar es un problema diferente de un mensaje firmado cuya clave de verificación no se puede encontrar. Una firma válida pero no alineada difiere de una firma invalidada por la modificación del mensaje. Una observación DNS de una caché antigua difiere de un registro autorizado incorrecto. Estas distinciones evitan que un equipo debilite DMARC para ocultar un problema de firma o enrutamiento no resuelto. Verificación DKIM y DMARC alineación son evaluaciones relacionadas pero separadas. RFC 6376 , secciones 3.5–3.6 RFC 9989 , sección 4.4
Diagnóstico ficticio: una ruta faltante en el plan
En una empresa ficticia, North Quay Parts, el equipo de mensajería prepara la firma de la correspondencia ordinaria. Una aplicación de cuentas todavía utiliza una ruta de retransmisión aprobada diferente. Un revisor ve un resultado exitoso para un mensaje del personal y propone marcar todo el dominio como completo. Este escenario no representa ninguna empresa, prueba o resultado real.
La revisión se detiene en el desajuste del alcance. Se agrega al inventario la ruta de solicitud, se documenta su sobre y la identidad del autor y se asigna su responsabilidad de firma. El equipo no adivina que la aplicación atraviesa la misma política de puerta de enlace. También evita reemplazar SPF con un ejemplo de servicio único o cambiar DMARC simplemente para obtener un indicador verde. La aceptación permanece pendiente hasta que cada ruta dentro del alcance tenga evidencia autorizada adecuada.
Hoja de trabajo de aceptación de implementación en blanco
- Producto Gateway, versión y fecha de documentación aplicable: ____.
- Propietario de la configuración, propietario DNS y aprobador de la versión: ____.
- Categoría de mensaje y ruta aprobada hasta la salida final: ____.
- Dominios de firma esperados de, CORREO DE y DKIM : ____.
- Asociación de perfil/política admitida y excepciones no resueltas: ____.
- Referencia del registro de verificación público y selector, excluyendo secretos: ____.
- Remitentes existentes SPF , autorización propuesta y revisión de dependencia: ____.
- Propietario previsto DNS , evidencia autorizada actual y tiempo de observación: ____.
- Evaluación de alineación y evidencia de mensaje recibido aprobado real: ____.
- Condiciones de reversión, discrepancias no resueltas y decisión de aprobación: ____.
La hoja de trabajo está vacía y no se ha ejecutado ningún paso operativo. La evidencia de implementación original, la revisión humana, la aplicabilidad de las fuentes actuales, las rutas de producción, las comprobaciones visuales/de accesibilidad y la autorización del propietario permanecen abiertas. La aceptación de la autenticación aún no garantizaría la entrega, la seguridad del mensaje o la legitimidad de una solicitud comercial. RFC 9989 , sección 2.4