La plataforma de marketing de un banco puede pasar DMARC constantemente mientras falla un pequeño servicio de código de autenticación. El porcentaje agregado oculta la incapacidad del cliente para iniciar sesión. Haga un inventario de las notificaciones críticas por propósito y consecuencia operativa antes de utilizar el estado general del correo para juzgar la preparación.
Distinguir tres promesas de servicio
Un mensaje de código de autenticación tiene un ciclo de vida de vencimiento y reintento controlado por el servicio de identidad. Es posible que una alerta de fraude necesite atención oportuna a través de un flujo de trabajo de contacto aprobado. Un aviso de cuenta puede ser menos inmediato pero aun así contener información importante. Para cada uno, documente el desencadenante, el propietario de la aplicación, el momento esperado, la ruta de acceso alternativa y el equipo de escalamiento.
No convierta este inventario en un respaldo del correo electrónico como factor de autenticación para una transacción bancaria en particular. La idoneidad de los códigos de correo electrónico depende del diseño de seguridad aprobado por la institución y de los requisitos aplicables. DMARC protege una evaluación de identidad de dominio; no puede hacer aceptable un proceso de recuperación débil o una elección de factor inseguro.
Inspeccionar la ruta que realmente emite el código.
Registre el dominio De, la identidad del sobre, DKIM firmante, selector, inquilino de la aplicación y entorno para el servicio de identidad. Verifique que las configuraciones de prueba, puesta en escena y producción estén claramente separadas. Una prueba exitosa a través de un buzón de desarrollador no dice nada sobre el trabajador de notificación de producción si utiliza otro proveedor.
Para alertas de fraude, registre el remitente que crea la alerta y el canal por el cual los clientes deben verificarla de forma independiente. Evite enseñar a los clientes a confiar en un mensaje únicamente porque parece tener una marca o estar autenticado. Los avisos de cuenta pueden utilizar un procesador por lotes con un comportamiento diferente de firma y reintento; inclúyalo explícitamente en lugar de heredar el resultado del servicio de código.
Mide la latencia sin reclamar más de lo que muestran los relojes
Capture el tiempo de activación, el tiempo de envío del proveedor, la aceptación remota cuando esté disponible y el tiempo de observación del buzón controlado. Registre zonas horarias e incertidumbre del reloj. Comparar estas etapas con los objetivos de servicio aprobados por la propia institución; Aquí no se proporciona ningún umbral de tiempo de entrega universal. Los intervalos de informes agregados no pueden medir el tiempo de llegada de un código en particular.
Utilice códigos sintéticos que no puedan autenticarse en ninguna cuenta real. Nunca recopile códigos utilizables en capturas de pantalla o diagnósticos de fácil acceso. Pruebe el comportamiento del código caducado, la entrega retrasada y las solicitudes repetidas en un entorno aprobado que no sea de producción. Un código tardío puede autenticarse perfectamente en la capa de correo electrónico y fallar correctamente en la capa de aplicación porque ha caducado.
Asignar recuperación antes de endurecer la política
El propietario de la identidad debe definir cómo un usuario recupera el acceso cuando falla el correo electrónico, mientras que las operaciones de fraude deben definir cómo los clientes pueden verificar las alertas a través de una ruta confiable. El equipo de correo diagnostica la identidad del remitente y la evidencia del destinatario. Evite la supresión automática de una notificación de seguridad crítica simplemente para mejorar un porcentaje de autenticación.
Exigir una prueba representativa para cada ruta crítica y un propietario designado para cualquier brecha. En el mapa local a continuación, se estipula que el firmante del aviso de cuenta no está alineado, mientras que el código y los firmantes de fraude coinciden exactamente. Este es un contraste de entrenamiento, no una medición bancaria. Vuelva a verificar después de la conmutación por error del proveedor, los cambios en la plataforma de identidad, la rotación del selector y los cambios en la vida útil del código o el comportamiento de reintento. Separe la autoridad de reversión documentada de la capacidad técnica para cambiar DNS .
Trabajar a través de tres registros de ruta escritos
Estos dominios de ejemplo reservados, selectores, roles y premisas DKIM de paso son ficticios. En estos casos no se proporciona ni ejecuta ningún mensaje firmado, clave, verificación criptográfica, búsqueda DNS , transacción SMTP o prueba de servicio en vivo. No se necesita ningún código de prueba ni muestra externa para inspeccionar el razonamiento siguiente.
- código de autenticación: visible desde codes.bank.example de dominio.banco.ejemplo; DKIM d=codes.bank.example; demostración del selector1; asumir el pase DKIM únicamente para este caso escrito. SPF CORREO DE identidad y resultado desconocidos; otras firmas desconocidas; Se desconoce el descubrimiento y la entrega de la política real. Propietario propuesto: propietario del servicio de identidad. Siguiente acción: Obtenga una muestra autorizada y un resultado de receptor confiable para este inquilino exacto.
- alerta de fraude: visible Desde el dominio fraud.bank.example ; DKIM d=fraud.bank.example; demostración del selector2; asumir el pase DKIM únicamente para este caso escrito. SPF MAIL FROM identidad y resultado desconocidos; otras firmas desconocidas; Se desconoce el descubrimiento y la entrega de la política real. Propietario propuesto: Propietario de operaciones de fraude. Siguiente acción: Confirme esta ruta separada y su evento comercial en lugar de heredar el resultado de la primera ruta.
- aviso de cuenta: visible Desde el dominio accounts.bank.example ; DKIM d=provider.example.net; demostración del selector3; asumir el pase DKIM únicamente para este caso escrito. SPF MAIL FROM identidad y resultado desconocidos; otras firmas desconocidas; Se desconoce el descubrimiento y la entrega de la política real. Propietario propuesto: Propietario de los servicios de la cuenta. Siguiente acción: Pregunte al proveedor verificado cuál es la ruta de firma alineada admitida por este inquilino; no ampliar la autorización a toda su red.
Para las dos primeras firmas estipuladas, d= es exactamente igual al dominio De, por lo que el identificador satisface tanto lo estricto como lo relajado. alineación. Dado el resultado DKIM exitoso estipulado, existe una ruta de autenticación alineada para esos mensajes hipotéticos. El tercer firmante no está deliberadamente relacionado con el dominio del autor y no puede proporcionar esa ruta alineada. No llame al tercer mensaje una falla DMARC : SPF alineado u otro paso alineado firma DKIM todavía podría satisfacer el mecanismo, y esas entradas se desconocen. No infieras la implementación real o la ubicación de la bandeja de entrada de ninguna fila.
Una firma criptográfica autentica la responsabilidad de un dominio firmante, no la veracidad o autorización de cada instrucción. Los cambios en los bytes canonicalizados cubiertos pueden invalidar una firma; No todas las ediciones visibles cambian necesariamente la entrada firmada. La autenticación y la aceptación a nivel de aplicación permanecen separadas.
Leer un cronograma de vencimiento hipotético
Para el caso OTP-01 no funcional, supongamos relojes sincronizados: activación a 10:00:00 GST, envío del proveedor 10:00:01 , aceptación SMTP remota 10:00:03 , vencimiento de la aplicación aprobada 10:01:00 y observación del buzón controlado 10:01:10 . Esta llegada inventada se produce 70 segundos después del disparo y 10 segundos después del supuesto vencimiento. Incluso un pase DKIM alineado estipulado no puede extender la vida útil del código. El propietario de la identidad investiga la latencia y la ruta de recuperación aprobada; la aplicación debe aplicar sus reglas de validez configuradas. La aceptación remota no es observación del buzón ni lectura humana. No se midió la latencia operativa, la validez del código ni el acceso de los clientes. Los registros reales necesitan compensaciones de reloj e incertidumbre antes de comparar etapas.
Aplicar las normas sin pretender cumplimiento
RFC 9989 Secciones 4.4 y 5.3.5 apoyar la distinción de alineación y mecanismo. Su Sección 7.4 advierte sobre la interoperabilidad del correo indirecto: dominios que utilizan p=reject debe utilizar DKIM válido, no solo SPF , y el uso de listas de correo de propósito general necesita especial cuidado. Un inventario de rutas no es en sí mismo un permiso para imponer el rechazo. RFC 6376 Secciones 3.4–3.7 y 6.1 describir las entradas firmadas y la verificación. RFC 9990 Sección 3.1 proporciona un contexto de informes, no una prueba de llegada por destinatario. RFC 5321 Sección 4.2.5 distingue la responsabilidad de aceptación del servidor de los resultados de entrega posteriores. Las opciones de flujo de trabajo del sector aquí son recomendaciones editoriales; el alcance legal, la idoneidad de los factores y la autorización local necesitan su propia revisión responsable.