A selector El monitor puede indicarle que los datos de verificación cambiaron o desaparecieron. No puede establecer que un servicio todavía se está enviando, que su clave privada coincide con la clave publicada o que sus mensajes llegan con valores alineados. DKIM. Cree comprobaciones independientes para la configuración publicada y el comportamiento de los mensajes observados.
Comience con rutas de envío conocidas
Cree un inventario a partir de la configuración del remitente autorizado y los mensajes recibidos del representante. Para cada ruta, registre el propietario de la empresa, el dominio d, el selector, el propietario DNS , TXT esperado o CNAME disposición, hora de la última firma observada y estado del ciclo de vida. No asuma que adivinar los selectores comunes descubre a todos los firmantes. DKIM proporciona el selector en cada firma en lugar de definir un servicio de enumeración DNS completo.
Para una firma que utilice s=invoice2 y d=brand.example, inspeccione invoice2._domainkey.brand.example en RFC 6376 §3.6.2.1. Siga un CNAME esperado hasta sus datos de verificación. Almacene una marca de tiempo de observación y una huella digital de clave pública para que un cambio pueda compararse con una rotación aprobada. Nunca recopile claves privadas en el sistema de monitoreo.
Separar los hallazgos del monitor.
Una respuesta faltante, tiempo de espera DNS , clave revocada y clave modificada son eventos diferentes. RFC 6376 §6.1.2 distingue el error de consulta de clave de una clave ausente, y un valor p vacío representa la revocación bajo RFC 6376 §3.6.1. Registre los detalles de la respuesta en lugar de traducir cada error en una interrupción genérica.
Una clave actual todavía necesita comprobaciones de sintaxis y algoritmo. RFC 8301 §3.1 prohíbe la firma y verificación de rsa-sha1; RFC 8301 §3.2 actualiza los requisitos de tamaño RSA: los firmantes deben usar al menos 1024 bits y deben usar al menos 2048. El soporte del producto y la política criptográfica organizacional actual pueden ser más estrictos. Un cambio de huella digital por sí solo no puede indicarle si se autorizó una rotación.
Agregue un bucle de evidencia en vivo
Envíe mensajes controlados a través de cada ruta de producción importante a un buzón cuyo mensaje sin procesar y resultado de autenticación confiable pueda inspeccionar. Registre los d y s observados, el resultado de la verificación y alineación con De. Ejercite las variantes de mensajes a las que podría afectar el procesamiento posterior, como HTML y archivos adjuntos.
Monitor ilustrativo: DNS continúa entregando la factura2, pero un mensaje nuevo no contiene DKIM-Signature. La verificación de publicación pasa mientras que la verificación de firma falla. En otro caso, la firma existe pero su hash corporal falla después de un cambio en el pie de página de la puerta de enlace. Ninguno de los incidentes se resuelve declarando que el registro DNS está en buen estado. Estos son casos de prueba sintéticos, no incidentes de servicio medidos.
Las pruebas sintéticas también tienen límites. Una investigación diaria no prueba todos los mensajes pasados entre las pruebas. Combínelo con informes del receptor y evidencia de incidentes, reconociendo al mismo tiempo la cobertura y el retraso en los informes.
Enrutar alertas procesables
Adjunte alertas a una ruta y propietario. Suprima solo una ventana de mantenimiento aprobada explícitamente, conserve el historial de eventos y confirme al nuevo firmante con correo nuevo después de la rotación. Escale los cambios de clave inesperados como posibles eventos de seguridad sin declarar un compromiso por un solo cambio.
Retire deliberadamente las filas de inventario obsoletas. Es posible que permanezca una clave pública antigua para la verificación de mensajes retrasados incluso cuando se haya detenido una nueva firma. Distinguir ese estado planificado de una delegación abandonada. El panel debe decir qué se observó, cuándo y mediante qué método, para que el estado DNS nunca se haga pasar por una prueba de firma en vivo.
Reproducir la decisión de alerta.
Utilice cuatro sondas sintéticas para mantener separadas las capas de alerta. Una firma con d=brand.example y s=invoice2 se asigna a invoice2._domainkey.brand.example . Si su clave pública está presente pero el resultado del receptor proporcionado es una falla en el hash del cuerpo, genere una alerta de verificación de mensaje. Si su clave está ausente, genere una alerta de ausencia de clave. Si el registro esperado está presente pero el mensaje no tiene firma, genere una alerta de falta de firma. Una clave presente más un resultado satisfactorio proporcionado no genera ninguna alerta para esa sonda por sí sola.
Estas cuatro decisiones son un modelo de decisión ilustrativo con estados DNS inventados y resultados de receptor proporcionados. Para esta revisión no se realizó ninguna consulta DNS en vivo, prueba de firma ni verificación criptográfica. Para poner en funcionamiento el monitor, reemplácelos con respuestas públicas fechadas y mensajes sin procesar que transmitan resultados desde su límite de recepción confiable. Preservar esa evidencia vinculada antes de describir una ruta como verificada operativamente.
Evidencia necesaria para la próxima decisión
Para una alerta de hash del cuerpo, conserve el resultado proporcionado e investigue la representación del cuerpo, la configuración de c/l, el valor de bh y el comportamiento de implementación; una discrepancia por sí sola no prueba que el contenido de la puerta de enlace haya sido modificado. Marque una ruta sin sonda nueva como no observada, incluso si su clave está presente. Registre por separado si se verificó la alineación, ya que el pase DKIM por sí solo no es un pase alineado.