En Geko hemos tenido la (mala) fortuna de pasar por nuestra buena cantidad de respuestas de incidentes de operaciones, sistemas y seguridad. Es algo que pasa de forma inevitable por unas razones que son omnipresentes (en las que entraremos más adelante), y como respuesta proactiva a esto hemos adoptado unas prácticas y hábitos que nos permiten detectar, localizar y resolver incidentes de todo tipo de manera eficiente. Se vuelve una práctica mucho más manejable una vez asumes que van a ocurrir y te preparas para ello. Nunca se puede ser demasiado cuidadoso cuando estás hablando de la infraestructura crítica que tu equipo y tú usáis para trabajar, o el producto al que acceden tus clientes. Es un escenario de “No podemos permitirnos un desastre” y debes estar preparado para ello.

Hay unas contramedidas y comprobaciones que necesitas introducir en tu infraestructura y ecosistema que hace este escenario mucho más fácil de gestionar:

• Una plataforma de monitorización robusta
• Un plan bien diseñado de alertas
• failover de servicios
• snapshots y backups de los datos importantes
• un plan de disaster recovery

Vayamos de uno en uno para definir qué son y por qué son imprescindibles.

¿Cómo sé cuándo falla algo?

El primer paso hacia saber que tu infraestructura está fallando, es saber cómo se ve cuando no está fallando. Necesitas construir un sistema que compruebe constantemente el estado de todas las partes críticas de tu infraestructura, así sabrás cual es su estado normal, y podrás ver cuando se desvía de este estado de funcionamiento correcto. El status drift, si no se vigila, será tu primer paso hacia un estado de fallo: todo funciona bien, luego va fallando poco a poco. Al final llega un día donde tu estado se habrá desviado tanto de su funcionamiento original que tendrás que reconstruirlo todo desde cero. No quieres acabar aquí. Así que para evitarlo, se debe monitorizar anomalías de estado. Si algo se mueve, necesita monitorización. Si algo no se mueve, necesita monitorización por si se mueve.

¿Siento a alguien a mirar métricas?

No sirve de mucho un stack de monitorización si éste no te grita cuando algo va mal. Por lo tanto, a medida que se configura la infraestructura de monitorización, se añaden al mismo tiempo las alertas. La forma de hacerlo depende de la urgencia de la tarea. ¿Es un servidor que tiene el 70% de su disco lleno? quizás vale con que envíe un mensaje de Slack sobre ello a su equipo de TI. ¿Producción no responde a los pings? Probablemente quieras que llame a alguien inmediatamente para que empiece a hacer debugging cuanto antes. Depende de la urgencia del sistema y de lo grande que sea el indicador del problema. Tu entorno, tus prioridades.

¿Pero eso no mantiene el servicio como tal, no?

¿Necesitas una forma de mantener el servicio incluso en caso de fallo? Mantén un sistema de conmutación por error. Tal vez puedas omitir la llamada sobre el servidor que falla, o puedes mover ese ticket de «cambiar el disco duro fallido» hacia abajo en la lista de prioridades porque de momento tienes otra en el RAID. Dos es uno, uno es ninguno. Implementa una conmutación por error en básicamente cualquier cosa importante, incluso si es un sistema de conmutación por error manual. Ten algo preparado para cambiar rápidamente y mantener el servicio.

¿Qué hago cuando me llega una alarma de fallo?

Pongámonos en un escenario de desastre por un momento. Supongamos que has ignorado la alerta S.M.A.R.T. un día más de lo que debías. Tu máquina principal ha caído, no puedes simplemente pulsar el botón de encender para que vuelva a funcionar y olvidarte de ella, y de alguna manera también tenías tu failover en esa misma máquina, por ejemplo un escenario en el que tu máquina proxmox pasa a conocer al creador. Enhorabuena, estás ante un incidente. Así que, para este caso, que sabías que podía ocurrir, has preparado copias de seguridad (espero) y puedes intercambiar esa unidad y restaurarla. Puede que pierdas un día de trabajo, pero no es nada comparado con perderlo todo y pasar cientos de horas reconstruyendo tu empresa desde cero. Es especialmente importante recordar la regla básica de las copias de seguridad, conocida generalmente como la regla 3-2-1:

• 3 copias de tus datos
• En al menos 2 dispositivos diferentes
• 1 de ellos en una localización remota

De este modo, incluso en caso de un incidente especialmente grave, como un incendio, puedes simplemente restaurar a partir de la copia de seguridad externa (aunque eso puede llevar bastante más tiempo dependiendo de tu solución). Además, comprueba que tus copias de seguridad funcionan. Por favor. Una copia de seguridad no es una copia de seguridad hasta que la pruebas.

Como extra, no te marques un Michael Scott con tu equipo.

¿No podemos prepararnos para todo, cierto?

Pueden ocurrir muchas cosas y, por desgracia, no se pueden predecir todas. Puede pasar cualquier cosa y cuanto más compleja sea la configuración de tu infraestructura, más puntos de fallo habrá en ella, así que tienes que prepararte todo lo posible. Tal vez no puedas tener todos los incidentes posibles previstos, pero cuantos más planifiques, mejor, de modo que si ocurre algo, tu personal de guardia pueda simplemente repasar un runbook en tu documentación y solucionar el problema sin mucho escalado. Este plan suele incluir ejemplos de escenarios que consideras posibles en función de la configuración de tu infraestructura, los elementos que se ven afectados y la forma de solucionar el problema.

Suena a que necesito uno de esos planes.

Si un elemento importante de su infraestructura falla, ¿recibirías una llamada, un correo electrónico o una notificación de Slack? ¿Está seguro de que sus copias de seguridad funcionan? ¿Cómo de resistente es tu plataforma a un fallo de disco? Si estos escenarios suenan como un problema en tu caso, tal vez te resulte útil ponerte en contacto con nosotros y hablaremos de cómo ponerlo todo en orden. Sólo tiene que tomar una decisión: ¿lo haces ahora o espera a que se produzca su próximo incidente? Recuerda las palabras de Picard sobre la gestión de incidentes:

La entrada Disaster Recovery: espera lo inesperado se publicó primero en Geko Cloud.

La mayoría de Juniors que entran a una entrevista han acabado recientemente su grado en informática. Acostumbra a ser o una ingeniería, o un grado superior en administración de sistemas. Las clases por las que han pasado son mayormente lo que se podía esperar: estructuras de datos, algo de programación, cálculo de coste de procesos, configurar máquinas virtuales, administración de servicios, funcionamiento de un centro de datos para asegurar disponibilidad, quizá algo de seguridad red-team o blue-team…

O quizá ya no eres tan junior y vienes con algo de experiencia bajo el cinturón, pero llevas un poco más de tiempo del que te gustaría sentado en una silla de oficina instalando drivers de impresora y mirando un panel de Zabbix, y quieres un poco de aire fresco, un reto profesional. En ambos casos probablemente te encuentres con que los tiempos han cambiado. Han cambiado bastante.

Visitando terrenos inexplorados

Lo primero que probablemente notes cuando explores LinkedIn es que los administradores de sistemas están un poco pasados de moda. Las empresas ya no buscan un sysadmin, o mejor dicho, no buscan sólo un sysadmin. Eso está separado de otros equipos como los developers en lo que se llama un «silo», y los «silos» son muy last-gen. El último grito es ser DevOps!

En tu búsqueda de algo nuevo, o como mínimo por ósmosis de esos posts de influencers de Linkedin, probablemente hayas oído antes el concepto de DevOps. Hemos explicado esta filosofía antes en el blog de geko, pero hagamos un recordatorio rápido: DevOps es esencialmente una filosofía, una forma de trabajar en equipo, que une esos «silos» en un solo equipo interconectado que trabaja en sintonía para hacer delivery más rápida y eficiente, más ágil y más automatizado. No más Patch Tuesdays, no más miedo de desplegar los viernes!

Esto es algo generalizado, y quizá cuesta focalizarte en un área de trabajo cuando los silos ya no existen. Si estás buscando un reto nuevo en esta industria hay muchas posibilidades de que te interese el campo de la ciberseguridad. Es un área en vías de crecimiento, hay mucho trabajo disponible, conlleva algo distinto cada día… ¡Parece todo positivo! (mientras la empresa haga caso a tus recomendaciones, claro), pero también probablemente hayas notado que la ciberseguridad es uno de los campos que más cambian en la industria. Es un trabajo que debe evolucionar siempre con todos los demás campos de IT, generalmente un paso por delante incluso, porque tiene que proteger todos los nuevos escenarios de trabajo que se presenten. Si DevOps une todos los campos del proceso de desarrollo, seguridad debe poder proteger todos los campos del desarrollo.

¿Qué tienen que ver entre ellos?

Si sigues la idea de pensamiento DevOps e intentas darle una vuelta al proceso de proteger recursos, probablemente en seguida te darás cuenta de que DevOps y la ciberseguridad son una muy buena pareja. Integrar todos los tests de seguridad en el proceso de desarrollo evita que esos errores lleguen a producción. Definir requisitos de seguridad en el desarrollo implica que esos problemas de seguridad no pueden llegar nunca a producción porque harán fallar la pipeline como requisito no cumplido. Tiene sentido que si se crea ese requisito en el proceso de desarrollo luego no tendrás que hacer ese trabajo en producción, o aún mejor, un threat actor no podrá aprovecharlo.

Esta vía de pensamiento creó recientemente un nuevo espacio de trabajo en el equipo de DevOps para acomodar la seguridad en operaciones, al que dimos el nombre de DevSecOps, porque a la industria tecnológica le pagan por producir servicios de calidad, no por inventarse nombres complicados. Al menos no dejamos a AWS ponerle el nombre y no tenemos que aguantarnos con algo como AWS DSO o algo así… Por ahora.

Definamos un poco más el concepto. DevSecOps, como su nombre fácil de reconocer presenta, consiste en ser una cultura que mete prácticas y requisitos de seguridad en el centro del proceso de desarrollo de DevOps. Se introducen controles de seguridad en todos los pasos de desarrollo de un producto, desde hardening de infraestructura como código (normas de firewall demasiado permisivas, volúmenes sin encriptar…) hasta análisis de código estático con herramientas automatizadas. Si los requisitos de seguridad no se cumplen, el proceso se para y hay que arreglar ese problema. Si te alertan en el proceso de desarrollo no necesitas detectarlo y arreglarlo después en producción!

Me gusta la idea. ¿Cómo lo implemento?

Toda la idea se puede resumir en un concepto: La seguridad no es un botón que puedas apretar para encenderla. No puedes aplicar seguridad a tu producto o servicio de forma eficiente instalando el software que te han dado en una call de ventas por Meet. La seguridad es una cultura. Un proceso contínuo que se construye directamente como parte de todo tu ciclo de desarrollo. Preferiblemente esto lo harás con checks automáticos del sistema que notifique de los cambios necesarios al equipo. No se despliegan aplicaciones inseguras en este equipo de operaciones.

Pero volviendo a lo de antes, no tiene por qué requerir siquiera intervención del equipo de Operaciones, quizá tu sistema avisa directamente al developer de la vulnerabilidad para que la arregle. Trabajo ágil, menos esperar a enviar correos de tickets y más entregar productos de valor! Toda la filosofía está pensada para cohesionar los departamentos y equipos y acelerar su trabajo eliminando pasos innecesarios.

¿Mi infraestructura es demasiado vieja escuela para esto, no?

Incluso en caso de que tu infraestructura sea demasiado legacy para adaptarse a la filosofía DevOps, las prácticas de seguridad que implica DevSecOps sigue siendo importante y debería trabajarse aplicar todas las posibles. ¿Administras algunos servidores con playbooks de Ansible? Quizá deberías pasar las repos por un pre-commit hook que compruebe que no has pusheado claves privadas. ¿Tienes una imagen de docker propia para alguna tarea concreta? ¿Por qué no pasarla por un analizador de imágenes, como Snyk o docker scan? (¿Sabías que Docker tenía un escáner de vulnerabilidades en imágenes? yo no). ¿Estás moviendo partes de tu infraestructura al cloud y quieres que sea fácilmente reconstruible con Terraform? Bridgecrew integra con casi cualquier provider para alertarte de ese «allow tcp/22 from 0.0.0.0/0» que se te ha colado.

Cualquier pequeño paso es un gran movimiento en pos de hacer a tus developers la vida un poco mas fácil, y a que tu equipo de operaciones y sistemas no les toque correr a arreglar deuda técnica para que puedan centrarse en tareas realmente importantes en tu organización. Si te preocupa el coste de implementar todos estos cambios puedes tener claro que aplicarlos ahora es la solución más barata que tienes. Quizá no lo parezca ahora, pero definitivamente un puñado de alertas de Security Hub van a ser más baratas que una multa de la Ley Europea de Protección de Datos.

Me gusta, hablemos.

¿Eres alguien de la industria que busca un nuevo reto donde poder tocar todas estas tecnologías? En Geko estamos siempre a la caza de talento de todos los perfiles de senioridad, sea para traer tus conocimientos o para aprender nuevos.

¿Estás en un entorno que se beneficiaría de todo esto y no sabes por dónde empezar? Contáctanos, aquí en Geko somos expertos en DevOps y transformación digital y microservicios. Hablemos sin compromiso de cómo podemos llevar a tu equipo a una gestión mejor.

La entrada ¿Qué es DevSecOps? se publicó primero en Geko Cloud.