En el artículo anterior de esta serie, The Everything Guide to Data Collection in DevSecOps , discutimos la importancia de la recopilación de datos. En este artículo, exploraremos el papel del monitoreo en la observabilidad, especialmente en lo que se refiere a la seguridad, el rendimiento y la confiabilidad.
El monitoreo es esencial para detectar problemas y valores atípicos a medida que ocurren en la producción y permite que los equipos de DevSecOps identifiquen y aborden los problemas antes de que causen daños graves. Supervisar las degradaciones del rendimiento o la actividad sospechosa puede generar alertas y respuestas automáticas para aislar posibles problemas o ataques.
En este artículo, veremos el monitoreo en detalle, brindaremos varios casos de uso y mejores prácticas, y discutiremos cómo el monitoreo puede mejorar específicamente la seguridad, el rendimiento y la confiabilidad a través de la observación.
En un sistema observable, recopilamos datos de registros, métricas y seguimientos distribuidos. Y mientras que para sistemas muy pequeños puede navegar y buscar manualmente los registros, visualizar las métricas como gráficos y rastrear a través de diagramas que muestran cómo fluye el tráfico a través del sistema para identificar problemas, a escala, esto no es suficiente. Necesita monitoreo, un proceso automatizado que vigile estos datos y le avise apropiadamente. (Para un tratamiento más detallado sobre la diferencia entre monitoreo y observabilidad, puede consultareste recurso ).
En una empresa, necesita formas automatizadas de filtrar, agregar, enriquecer y analizar todos estos datos. Las empresas también necesitan formas automatizadas de actuar cuando se detecta algo inusual. La respuesta automática puede notificar al equipo responsable o incluso tomar medidas correctivas directamente.
En otros campos como la medicina, la monitorización de las constantes vitales de los pacientes es una actividad clave, que salva vidas. El monitoreo de los sistemas de software es muy similar, e incluso usamos la misma metodología cuando realizamos controles de salud y discutimos la salud de diferentes componentes.
Suficiente teoría, veamos algunos ejemplos concretos de monitoreo.
Estos son algunos casos de uso típicos que aprovechan el monitoreo:
4xx
o 5xx
) puede ayudar a un equipo a abordar los problemas de rendimiento y confiabilidad antes de que se conviertan en problemas importantes.
Tenga en cuenta que el monitoreo es mucho más complicado que establecer una condición simple (como "más de cinco consultas INSERT
en la base de datos de orders
en dos minutos") y disparar una alerta cuando se cumple esa condición. La estacionalidad puede estar en juego, con patrones de uso que provocan picos en ciertos momentos del día, la semana o el año. El monitoreo efectivo que detecta comportamientos inesperados tiene en cuenta el contexto y puede reconocer tendencias basadas en datos anteriores.
Este tipo de monitoreo, especialmente cuando se implementa con una herramienta que combina observabilidad, monitoreo y seguridad a escala, puede ser inmensamente efectivo, como en este caso de estudio de Sumo Logic e Infor, donde Infor pudo ahorrar 5000 horas de tiempo dedicado a incidentes
El monitoreo mejora el rendimiento y la confiabilidad de un sistema mediante la detección temprana de problemas para evitar la degradación. Los problemas de rendimiento a menudo se convierten en problemas de disponibilidad y confiabilidad. Esto es especialmente cierto en presencia de tiempos de espera. Por ejemplo, suponga que una aplicación expira después de 60 segundos. Debido a un problema de rendimiento reciente, muchas solicitudes de repente tardan más de 60 segundos en procesarse. Todas estas solicitudes ahora fallarán y la aplicación ahora no es confiable.
Una mejor práctica común para abordar esto es monitorear las cuatro señales doradas de cualquier componente en la ruta crítica de los servicios y aplicaciones de alta prioridad: latencia, tráfico, errores y saturación.
¿Cuánto tiempo se tarda en procesar una solicitud? Tenga en cuenta que la latencia de las solicitudes exitosas puede ser diferente a la de las solicitudes fallidas. Cualquier aumento significativo en la latencia puede indicar una degradación del rendimiento del sistema. Por otro lado, cualquier disminución significativa podría ser una señal de que se salta algún procesamiento. De cualquier manera, el monitoreo llamará la atención sobre el posible problema.
Supervisar el tráfico le permite comprender la carga general de cada componente. El tráfico se puede medir de diferentes maneras para diferentes componentes. Por ejemplo:
Un aumento en el tráfico puede deberse al crecimiento orgánico del negocio, lo cual es bueno. Sin embargo, también puede indicar un problema en un sistema ascendente que genera un tráfico inusualmente mayor que antes.
Un aumento en las tasas de error de cualquier componente impacta directamente en la confiabilidad y utilidad del sistema. Además, si las opciones fallidas se retiran automáticamente, esto puede generar un aumento en el tráfico y, posteriormente, puede generar problemas de rendimiento.
De los recursos disponibles, ¿cuántos utiliza el servicio o la aplicación? Esto es lo que le dice el monitoreo de saturación. Por ejemplo, si un disco está lleno, un servicio que escribe registros en ese disco fallará en cada solicitud posterior. En un nivel superior, si un clúster de Kubernetes no tiene espacio disponible en sus nodos, los nuevos pods estarán pendientes y no programados, lo que puede generar problemas de latencia.
Como notará, las cuatro señales doradas están relacionadas entre sí. Los problemas a menudo se manifiestan a través de múltiples señales.
Si bien cualquier problema de salud del sistema puede afectar directa o indirectamente la seguridad, existen algunas amenazas directas que el monitoreo puede ayudar a detectar y mitigar.
Un sistema está hecho de múltiples componentes, pero es más que la suma de sus partes. En un nivel básico, debe monitorear cada componente de su sistema (al menos en las rutas críticas) en busca de las cuatro señales doradas . ¿Qué significa esto en la práctica?
También debe prestar mucha atención a las dependencias externas . Por ejemplo, si se ejecuta en la nube o se integra con un proveedor de servicios externo, debe monitorear los puntos finales públicos de los que depende y establecer alertas para detectar problemas. Si un tercero está inactivo o su rendimiento se degrada, esto puede causar una falla en cascada en su sistema.
No es posible tener componentes 100% confiables. Sin embargo, el monitoreo puede ayudarlo a crear un sistema confiable a partir de componentes no confiables al detectar problemas con los componentes, tanto internos como externos, y reemplazarlos o degradar correctamente el servicio . Por ejemplo, si está ejecutando su sistema en una configuración multizona y hay un problema en una zona, entonces el monitoreo puede detectarlo y desencadenar el redireccionamiento (manual o automático) de todo el tráfico a otras zonas.
Por seguridad, las cuatro señales también pueden ser indicadores auxiliares de un compromiso . Este es especialmente el caso, por ejemplo, si ve un aumento en su dispositivo de punto final o CPU de carga de trabajo en la nube, o un aumento en la cantidad de intentos fallidos de inicio de sesión. Sin embargo, la supervisión de la seguridad debe ser muy deliberada, ya que se trata de adversarios malintencionados. Debe definir el servicio de ataque de cada componente y de todo el sistema y asegurarse de que la información que recopila sea suficiente para detectar problemas . Por ejemplo, para detectar la exfiltración de datos, puede monitorear las direcciones IP y la cantidad de datos enviados fuera de su red interna por diferentes aplicaciones y servicios. Si no tiene esos datos, estará ciego a esa metodología de ataque.
Una vez que configure su recopilación de datos, puede seguir los pasos a continuación para implementar una estrategia de monitoreo sólida y efectiva.
Ya ha realizado un inventario completo de todos sus activos como parte de la recopilación de datos. Ahora, su tarea es identificar los activos críticos que deben monitorearse de cerca para prevenir y mitigar los desastres. Es fácil decir, "simplemente monitoree todo", pero hay costos a considerar con el monitoreo. Supervisar y generar alertas para sus entornos de preparación y desarrollo o servicios experimentales puede generar una gran cantidad de estrés innecesario para sus ingenieros. Las alertas frecuentes a las 3 AM para problemas insignificantes causarán fatiga de alertas, lo que paralizará el impulso de su equipo para abordar un problema cuando realmente importa.
Una vez que identifica los activos críticos, necesita un propietario claro para cada uno. El propietario puede ser una persona o un equipo. En el caso de una persona, asegúrese de identificar también una alternativa. También es importante mantener la propiedad de los activos a medida que las personas se unen y abandonan la organización o se trasladan a otros roles y equipos.
En última instancia, su estrategia de monitoreo vivirá o morirá en función de cómo defina las alertas para los activos que están en mal estado o potencialmente comprometidos. Debe comprender qué es lo normal para cada activo.
Si está monitoreando métricas, definir "normal" significa asociar un atributo (como la utilización de la CPU) con un rango de valores (como "50%-80%"). La banda normal puede cambiar dinámicamente con el negocio y puede variar en diferentes momentos y ubicaciones. En algunos casos, es posible que solo tenga techos o pisos. Al definir rangos normales, crea alertas para notificar al propietario de un activo cuando su activo está funcionando fuera del rango normal.
Si está monitoreando registros, las alertas generalmente se definen en función del resultado de ciertas consultas de registro (como "número de errores 404 registrados en todos los servicios API en los últimos cinco minutos") que cumplen o no cumplen una condición (como "es menos de 10”). Las herramientas de análisis y administración de registros pueden ayudar.
Cuando se dispara una alerta crítica, ¿qué hace? Lo que no quiere hacer es tratar de descubrir su estrategia en el acto, mientras los clientes tuitean sobre los productos poco confiables de su empresa y la gerencia entra en pánico.
Un runbook es una receta de pasos fáciles de seguir que prepara y prueba con anticipación para ayudarlo a recopilar información adicional (por ejemplo, qué paneles mirar y qué scripts de línea de comandos ejecutar para diagnosticar la causa raíz) y mitigar acciones (por ejemplo, implementar la versión anterior de la aplicación). Su runbook debería ayudarlo a identificar rápidamente el problema en un problema específico e identificar a la mejor persona para manejarlo.
Tiene propietarios, alertas y runbooks. A menudo, las alertas no son lo suficientemente específicas como para asignarlas directamente a los propietarios. La mejor práctica es asignar ingenieros de guardia a diferentes áreas del negocio. Este ingeniero de guardia recibirá la alerta, seguirá el runbook, mirará el panel e intentará comprender la causa raíz. Si no pueden entender o solucionar el problema, lo derivarán al propietario. Tenga en cuenta que este proceso puede ser complicado; a menudo, un problema ocurre debido a una cadena de fallas que requieren que múltiples partes interesadas colaboren para resolver el problema.
Los runbooks son geniales, pero mantener runbooks complejos y capacitar a los ingenieros de turno para que los sigan requiere mucho esfuerzo. Y al final, su proceso de remediación aún depende de un ser humano lento y propenso a errores. Si su runbook no está actualizado, seguirlo puede empeorar la crisis.
En teoría, un runbook se puede ejecutar mediante programación. Si el runbook dice, "cuando se activa la alerta X, el proceso Y debe reiniciarse", entonces un script o programa puede recibir una notificación de la alerta X y reiniciar el proceso Y. El mismo programa puede monitorear el proceso Y después del reinicio, asegurarse de que todo esté bien. y eventualmente generar un informe del incidente, todo sin despertar al ingeniero de guardia. Si la acción de autorreparación falla, se puede contactar al ingeniero de guardia.
La autocuración es increíble, sin embargo, una onza de prevención vale más que una libra de cura, por lo que es mejor prevenir los problemas en primer lugar. Cada incidente es una oportunidad para aprender y posiblemente prevenir toda una clase de problemas. Por ejemplo, si ocurren múltiples incidentes porque el código con errores llega a producción, entonces una lección de las autopsias de incidentes podría ser mejorar las pruebas en la etapa de preparación. Si la respuesta del ingeniero de guardia a una alerta fue demasiado lenta o el runbook no estaba actualizado, esto puede sugerir que el equipo debería invertir en algunas prácticas de recuperación automática.
El monitoreo es una parte crucial de la observabilidad en general y de la observabilidad para la seguridad en particular. No es práctico a gran escala que los humanos "simplemente miren de vez en cuando" varios paneles y gráficos para detectar problemas. Necesita un conjunto completo de prácticas de respuesta a incidentes que incluyan la identificación de propietarios, la configuración de alertas, la escritura de runbooks, la automatización de runbooks y la configuración de procesos de guardia y procesos post-mortem.
¡Que tengas un gran día!