Cuando la seguridad ya no es una opción: hablemos del campo de batalla invisible en los microservicios

Imagine que pasó varios meses construyendo un sistema de control de servomotor. Los servos de cada articulación se ajustan con extrema precisión y los movimientos de los brazos robóticos son tan suaves como bailar. Pero una mañana, te das cuenta de que un módulo "falló" de repente; no fue un fallo mecánico, sino que alguien entró por una pequeña puerta que ni siquiera notaste y cambió silenciosamente algunos parámetros. Todo el sistema sigue funcionando, pero ya sabes, algo es diferente.

Este es probablemente el sentimiento que enfrentan muchas personas todos los días en el mundo de los microservicios.

¿Por qué siempre estamos tapando agujeros?

Una vez alguien me hizo una pregunta: ¿Por qué muchos equipos siempre "solucionan" los problemas de seguridad? De hecho, la respuesta es bastante sencilla: porque al principio no sabes dónde está la puerta.

La arquitectura de microservicio es como un complejo sistema de transmisión mecánica. Cada servicio es un engranaje independiente, giran de forma independiente y engranan entre sí. El problema es que cuantas más marchas hay, más espacios hay. Miras fijamente el eje de transmisión principal y olvidas que esa pequeña bomba de lubricación también puede atascarse. Para cuando escuche algún ruido anormal, ya se habrá producido desgaste.

El enfoque tradicional es cubrir todo el sistema con una carcasa protectora. Pero a los microservicios no les gustan las coberturas: necesitan respirar y escalar con flexibilidad. Entonces la seguridad se convierte en el arte de poner cinta adhesiva en cada punto de conexión. Recuperar aquí hoy, compensar allá mañana, siempre poniéndonos al día.

Otra perspectiva: la seguridad debe estar integrada en el sistema

Hace unos años, de repente descubrí algo mientras depuraba un brazo robótico de seis ejes. El mejor mecanismo de seguridad no es una cerradura externa, sino las "propiedades mecánicas" integradas en el diseño. Al igual que los circuitos de retroalimentación dentro de los servos, no se instalan posteriormente, sino que forman parte de la rotación del motor.

La seguridad de los microservicios también debería ser así. No debería ser un elemento en una lista de verificación, sino un atributo inherente de cada servicio.

¿Pero cómo?

Desmentiendo tres mitos comunes

Mito 1: “Es suficiente si tenemos un firewall” Esto es como instalar una cerradura en la puerta de tu taller mecánico pero dejar las ventanas abiertas. La comunicación entre microservicios a menudo ocurre en la red interna y no es visible para el firewall. Esas llamadas de servicio a servicio son como transferir piezas entre varias estaciones de trabajo en un taller: incluso si la puerta está cerrada, las piezas siguen circulando internamente.

Mito 2: “Utilizamos la última tecnología de cifrado” El cifrado es importante, pero es como aplicar el mejor aceite antioxidante a engranajes de precisión. Si la persona que aplicó el aceite olvidó un cojinete pequeño o lo aplicó demasiado espeso y afectó la disipación de calor, el problema aún existe. Configuraciones erróneas de cifrado, confusión en la gestión de claves, certificados caducados... estos son los detalles que salen mal con más frecuencia que ellos mismos.

Mito 3: “Todo nuestro código se revisa” La revisión manual es excelente, pero es como inspeccionar visualmente cada engranaje en busca de marcas de dientes. Cuando tienes cientos de servicios, actualizados cada semana, siempre falta algo. Sin mencionar las bibliotecas de terceros en las que confía: al igual que el equipo terminado que compra, cree en su calidad, pero ¿realmente comprende cada proceso de tratamiento térmico?

una estrategia más inteligente

Luego desarrollé un hábito: cada vez que diseño un módulo nuevo, me hago dos preguntas:

1. Si este servicio quiere hacer cosas malas, ¿hasta dónde puede llegar?
2. Si alguien quiere hacer algo malo con este servicio, ¿cuál es el lugar más fácil para empezar?

Esto puede parecer un poco neurótico, pero funciona. Al igual que cuando se diseña una estructura mecánica, no solo se considera cómo se mueve, sino también qué hacer si se atasca.

En concreto, me centraré en estos lugares:

• La identidad no es sólo una clave. Darle a cada servicio una identidad clara es como darle un número a cada herramienta del taller. Pero lo más importante es que la identidad debe tener un alcance de autoridad claro: esta llave solo puede apretar tuercas de cierto tamaño, este soldador solo puede usarse en una determinada estación de trabajo. Los permisos deben ser detallados y suficientes.

• Las conversaciones necesitan supervisión Cada llamada entre servicios debe registrarse y ser inspeccionable. No es un seguimiento, sino una especie de tarjeta de flujo de trabajo en el taller: quién tomó qué parte, se la entregó a quién y cuándo se completó. De esta forma, cuando hay algún problema en un determinado enlace, podrás encontrar pistas rápidamente.

• La configuración predeterminada es "Denegar". La configuración predeterminada en muchos sistemas es "Permitir" hasta que la desactive explícitamente. Es como un taller donde todas las herramientas están disponibles por defecto. Un mejor enfoque es hacer lo contrario: todas las operaciones se niegan de forma predeterminada y sólo se permiten aquellas que son claramente necesarias. Aunque la configuración inicial es más problemática, a la larga es mucho más segura.

• No confíes en la red interna. ¿El taller no necesita gestión interna? Todo lo contrario. Se debe suponer que el interior es tan peligroso como el exterior: un servicio comprometido puede convertirse en un trampolín para ataques a otros servicios. La comunicación entre servicios también requiere autenticación y cifrado, incluso si están en la misma sala de ordenadores.

existirkpotenciaen la práctica

Una vez necesitábamos actualizar el sistema de control de la línea de producción automatizada de un cliente. El sistema original tenía una arquitectura monolítica y las medidas de seguridad se concentraban en el borde. Al migrar a microservicios, no nos apresuramos a escribir código nuevo, sino que primero dibujamos un "mapa de confianza".

Cada servicio es un nodo y las conexiones entre nodos representan relaciones de comunicación. Luego hicimos algo divertido: coloreamos cada línea. El verde indica una alta confianza, el amarillo indica una confianza limitada y el rojo indica la necesidad de una revisión estricta.

La imagen resultante parecía una pintura abstracta: mayormente amarilla, muy poco verde y rojo esparcido aquí y allá. El cliente se puso un poco nervioso después de verlo: "Con tantas restricciones, ¿el sistema no funcionará?"

Dije que no. Es como instalar limitadores y sensores de torsión en cada articulación de un brazo robótico: no interfieren con el movimiento normal y sólo funcionan cuando hay una anomalía. Tres meses después, el sistema se puso en línea y el equipo de operación y mantenimiento informó que, aunque la configuración era un poco complicada, podían dormir mucho más tranquilos por las noches.

Volver a la pregunta original

¿Qué debería ser la seguridad? En diseño mecánico, es el factor de seguridad de los materiales, las estructuras de soporte redundantes y el análisis del modo de falla. En los microservicios, es el conocimiento de la identidad de cada fragmento de código, los límites claros entre los servicios y la actitud cautelosa predeterminada.

No es un complemento, sino parte de la filosofía de diseño. Así como no piensa en la protección contra el polvo después de instalar el riel guía de precisión, sabe que funciona en un ambiente limpio desde el principio.

Ahora, cuando observe su propia arquitectura de microservicios, es posible que desee cambiar su perspectiva: las llamadas entre servicios no son solo transmisión de datos, sino también transferencia de confianza. Y cada traslado debe contar con una supervisión y protección adecuadas.

Después de todo, los buenos sistemas no desarrollan resiliencia sólo después de que surgen vulnerabilidades. Debería evitar que se inicien los ataques antes de que aparezcan las vulnerabilidades. La diferencia entre esto es a menudo la diferencia entre el funcionamiento estable diario y las reparaciones de emergencia nocturnas.

Establecido en 2005,kpotenciase ha dedicado a un fabricante profesional de unidades de movimiento compacto, con sede en Dongguan, provincia de Guangdong, China. Aprovechando las innovaciones en la tecnología de accionamiento modular,kpotenciaintegra motores de alto rendimiento, reductores de precisión y sistemas de control multiprotocolo para proporcionar soluciones de sistemas de accionamiento inteligentes eficientes y personalizadas. Kpower ha brindado soluciones de sistemas de accionamiento profesionales a más de 500 clientes empresariales en todo el mundo con productos que cubren diversos campos, como sistemas domésticos inteligentes, electrónica automática, robótica, agricultura de precisión, drones y automatización industrial.