Comunidad Tecnología

Monitorización DevOps, Desarrollo, Seguridad y Operaciones: DevSecOpsMon

junio 20, 2019

Monitorización DevOps, Desarrollo, Seguridad y Operaciones: DevSecOpsMon

This post is also available in : Inglés

Monitorización DevOps y sus interrelaciones

En el siglo XX fuimos programadores. En el siglo XXI, desarrolladores. Con la masificación de las telecomunicaciones a nivel mundial los operadores comenzaron a ayudarnos en nuestra labor. Allí surgió el término DevOps (contracción en inglés de “developers” y “operations“), que implica el concepto de colaboración de ambos equipos. Pero, como lo único constante es el cambio, otras consideraciones prácticas han obligado a ver el bosque completo en vez de unos cuantos árboles solamente. ¡Poneos vuestras camperas tecnológicas y acompañadnos hoy!

DevOps

La colaboración entre ambos equipos es genial; solo exige un poco de trabajo a los desarrolladores el especificar los parámetros, y al equipo de operaciones, a partir de esto, trabajar en la infraestructura física y/o virtual. A su vez, el equipo de operaciones tomará la debida nota de las mejoras que se puedan hacer, tomando en cuenta los recursos de hardware y/o servidores virtuales para así mejorar las aplicaciones y/o sistemas, y retribuirá sus recomendaciones al equipo de desarrolladores. En este blog ya hemos hablado de una arquitectura DevOps donde, desde ya, avizoramos que la monitorización DevOps no estaría a un lado sino que se añadiría como un campo de trabajo especializado, ya que así operaciones tendrá una base sólida para evaluar y comparar mejoras versus desempeño.

Descripción: Cadena de procesos DevOps https://en.wikipedia.org/wiki/File:Devops-toolchain.svg

La Monitorización DevOps pasó a ser imprescindible cuando los procesos comenzaron a engranar de forma automatizada la Integración Continua de Software y sus pilares fundamentales, la Integración Continua (“Continuous Integration“), Distribución Continua (“Continuous Delivery“) y la Implementación Continua (“Continuous Deployment“), que ha devenido a abreviarse como CI/CD.

Esquema sobre la monitorización DevOps

  1. Requerimientos: del sistema y/o aplicación.
  2. Escritura: del código y su acometimiento (“commits“, en inglés) continuo.
  3. Pruebas: primero ejecución automatizada de las opciones añadidas y destinadas a los usuarios, para luego ser comprobadas por humanos cada cierto tiempo.
  4. Empaquetado: estructurar y organizar los ficheros necesarios.
  5. Liberación: llevar al repositorio una imagen en Docker, una imagen ISO, etc.
  6. Despliegue: implementar el sistema y/o aplicación.
  7. Operación: área perteneciente a los usuarios, su uso puro y simple.
  8. Monitorización: recoge los eventos y sus registros de la fase anterior.

Server monitoring with Pandora FMS

¿Quieres descubrir el software de monitorización más flexible del mercado?

Pandora FMS Enterprise es capaz de monitorizar dispositivos, servidores, aplicaciones, servicios o procesos de negocio. ¿A qué estás esperando para conocerlo mejor?


Seguridad

Así como los DevOps han automatizado sus labores, los chicos malos (léase “crackers”) no se han quedado rezagados. Ya os explicamos sobre las botnets y aunque como usuarios deberíamos estar pendientes de ello, ningún DevOps contaría nunca solamente con nuestra palabra. Es por ello que la seguridad se agregó, acuñando así el término DevSecOps (aunque escucharán y leerán sobre variaciones del término, en todo caso “el orden de los factores no altera el producto”).

Descripción: Esquema DevSecOps https://commons.wikimedia.org/wiki/File:DevOps_vs_DevSecOps_Mginise.jpg

Esquema DevSecOps

  1. Requerimientos: esencialmente de conceptos, donde nos hacemos las preguntas: ¿Qué estamos construyendo? ¿Qué puede ir mal? ¿Qué haríamos en esos casos? ¿Olvidamos incluir algo más? En este punto, también, el equipo de seguridad analizará los guiones que construirán la infraestructura inmutable en búsqueda de agujeros de seguridad.
  2. Escritura: concientización de los desarrolladores, enseñarles las últimas técnicas de ataque para que, en base a ello, modifiquen la escritura. En caso de ser necesario el equipo de seguridad enseñará a los desarrolladores herramientas como git-secrets, git-hound o incluso, de ser necesario publicar de manera cifrada contraseñas y datos de los desarrolladores, git-crypt. Corresponderá al grupo de operadores su instalación, configuración y puesta en funcionamiento.
  3. Pruebas: el equipo de seguridad solicitará incluir rutinas de ejecución que consideren adecuadas a cada módulo.
  4. Empaquetado: el equipo de seguridad analizará nuevas funciones y recursos añadidos al proyecto en búsqueda de vulnerabilidades añadidas por terceras partes. Algunas herramientas: bundler-audit, Dagda, Docker Bench, etcétera.
  5. Liberación: adicionar comprobaciones basadas en la fase anterior, buscar y verificar que cualquier elemento que hayamos bloqueado y/o corregido llegue hasta este punto.
  6. Despliegue: el equipo de seguridad dispondrá entornos de prueba que emulen lo que recibe el usuario y aplicará las técnicas que considere necesarias; si se quiere, este es el campo de juegos del equipo de seguridad.
  7. Operación: un grupo externo independiente (a veces llamado “artillería roja”) pero perteneciente al área de la seguridad intentará atacar la infraestructura y no avisará ni cómo ni cuándo. Hay otras herramientas complejas englobadas como “Chaos engineering” (Ingeniería del caos).
  8. Monitorización: software como Pandora FMS hacen su nicho en esta etapa; desarrolladores, seguridad y operadores ‘creen’ que tienen registros centralizados, Pandora FMS solo ve datos a raudales que convierte en información para luego “en verdad” centralizar en una consola web.

Esquema DevSecOpsMon

Con todo lo anteriormente explicado de una manera muy básica (que no por demás hemos dejado buen surtido de enlaces web si queréis profundizar en cada aspecto) llegamos a nuestro tema actual: DevSecOpsMon.

Descripción: Cadena de procesos DevSecOps https://en.wikipedia.org/wiki/File:Devops-toolchain.svg

El equipo de monitorización DevOps no sabe cuándo ni cómo le solicitarán información o ayuda, pero tiene la absoluta certeza de que sus servicios en algún momento serán requeridos. Es más, informará mediante alertas a cada uno de los equipos, ya sean tanto alertas normales como alertas especialmente solicitadas por el equipo de seguridad. Vamos, que será la mano derecha de la tripartita.

  1. Requerimientos: el equipo de monitorización tomará notas generales tanto del software que planean utilizar (entorno de programación, compiladores, herramientas de seguridad, de distribución, etc.) como de las plataformas objetivo (Unix/Linux, Windows, Mac, entre otros). También recolectará informes de vulnerabilidad de infraestructura, de pruebas de penetración y/o evaluaciones automatizadas y sus registros.
  2. Escritura: recolección de datos de los commits tanto aprobados como reformulados y rechazados. Deberá recolectar registros de operaciones de git-secrets, git-hound, git-crypt, Jenkins y demás. Es deber también de la monitorización el avisar oportunamente del crecimiento exponencial de las bases de datos a consecuencia de los acometimientos constantes, y deberá coordinar con el equipo de operaciones un ambiente de alta disponibilidad y respaldo de datos de monitorización.
  3. Pruebas: enfocado explícitamente en las rutinas adicionales incluidas por el equipo de seguridad a menos que ellos explícitamente lo prohíban, lo cual es muy improbable que suceda (número de problemas abiertos y/o resueltos por esprint, número de pruebas de unidades fallidas, informes de pruebas de UI automatizadas).
  4. Empaquetado: monitoreo del tráfico de red privado, ya que en este punto se reunirán y colocarán en el o los repositorios pruebas de conectividad y desempeño de los mismos.
  5. Liberación: tal vez sea la etapa donde la monitorización desempeña, si se quiere, un papel no preponderante; por mencionar alguno, sería supervisión del tráfico de red externo de los repositorios.
  6. Despliegue: igual que en el proceso anterior, podemos orientar hacia el tráfico de red.
  7. Operación: estará presta y a la mano toda la información recolectada que pueda orientar hacia el o los ataques hechos por la “artillería roja”.
  8. Monitorización: en el caso de Pandora FMS trabajamos en la búsqueda de la simplificación de la monitorización o desarrollo de la monitorización asistida para el equipo de operaciones, con tecnologías novedosas como Pandora FMS Discovery.

¿Aún quieres saber más sobre la monitorización de sistemas informáticos? Por suerte, estás en el lugar indicado para conocer más. En este blog existen decenas de artículos que pueden introducirte en este apasionante mundo. Aquí tienes un enlace a nuestra página de inicio.

O también puedes contactar directamente con el equipo de Pandora FMS si tienes más de 100 dispositivos a monitorizar. Entra aquí.

Si cuentas con un número reducido de máquinas para monitorizar puedes descargar la versión de Pandora FMS OpenSource, aquí.


Written by:



Leave a comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.