Los microservicios requieren medidas de seguridad especiales para reducir el riesgo. Aprenda las especificaciones según las recomendaciones de un experto de la industria.
El tema de los microservicios me parece fascinante, así que escribí a principios de este mes sobre el concepto de los microservicios y cómo asegurarlos. En pocas palabras, los microservicios son como ingredientes de aplicación que normalmente realizan un conjunto o función específica. Lo que es interesante acerca de ellos es cómo pueden ser reforzados juntos casi como el monstruo de Frankenstein (pero con mejor estabilidad) para ayudar a estandarizar el código, reducir la complejidad y añadir escalabilidad, así como flexibilidad al proceso de desarrollo y mantenimiento de la aplicación.
Hay algunos elementos dignos de mención en los dominios de la nube, las diferencias con las aplicaciones estándar y la seguridad. Hablé con Owen Garrett, Jefe de Productos de NGINX para aprender más sobre el tema.
ConsejoTecnologico.com: ¿Los microservicios son un fenómeno de nube, interno o híbrido?
Owen Garrett:«Puedes desplegar microservicios en cualquier lugar, en las instalaciones, en la nube pública o híbridos. Los primeros adoptadores son en su mayoría basados en la nube, es decir, Netflix, pero a medida que las empresas adoptan los microservicios, una buena parte de ellos los ejecutará desde su centro de datos privado.
Más información sobre ciberseguridad
El enfoque de microservicios para la arquitectura de aplicaciones surgió en parte como respuesta a la necesidad de construir «Aplicaciones Cloud Native». El patrón nativo de la nube requiere una arquitectura de aplicación desacoplada, distribuida, escalable y tolerante a fallos, y los microservicios cumplen perfectamente estos requisitos. Dicho esto, no hay nada en el enfoque de microservicios que los limite a la nube.
Las aplicaciones de microservicios se componen de grupos de pequeñas («micro») aplicaciones («servicios») que se comunican a través de una red. Estas pequeñas aplicaciones se empaquetan normalmente en contenedores, por lo que generalmente requieren una plataforma que pueda desplegar contenedores de forma rápida y eficiente, y que proporcione los servicios de red avanzados (descubrimiento y balanceo de carga) necesarios para soportarlos. Algunos proveedores de cloud computing ofrecen servicios especializados de alojamiento de contenedores, pero es más común que las empresas desplieguen ellas mismas las plataformas Kubernetes, Docker o Mesos. Estas plataformas pueden desplegarse casi en cualquier lugar, desde un solo ordenador portátil de un desarrollador hasta un centro de datos de mil servidores en las instalaciones o en la nube».
TR: ¿Puede explicar en qué se diferencian los microservicios de las aplicaciones heredadas?
OB: «Hay una mayor superficie de ataque involucrada. Cada cliente accede directamente a un subconjunto diferente de APIs y puntos finales web. Esta naturaleza distribuida significa que muchos más componentes son puntos potenciales de intrusión y necesitan ser asegurados. Sin embargo, es más difícil para una organización aplicar sistemáticamente las mejores prácticas de seguridad en todos los componentes. Una vez que una es violada, usted puede asumir que puede ser usada como cabeza de playa para tratar todos los datos que la aplicación compuesta usa, y los efectos pueden extenderse a otras aplicaciones que usan algunos de los mismos servicios».
TR: ¿Cuáles son algunos ejemplos concretos de riesgos de seguridad que implican los microservicios?
OB: «Las aplicaciones de microservicios dependen en gran medida de la red para el tráfico entrante (norte-sur) y para el tráfico interno entre servicios (este-oeste. La necesidad de asegurar el tráfico este-oeste es nueva, y uno no puede asumir que incluso un entorno de un solo inquilino es seguro. Cualquiera que tenga visibilidad no autorizada del tráfico de la red -otro inquilino, o incluso otro microservicio- puede potencialmente ver o modificar transacciones sensibles.
Los microservicios también facilitan la exposición de los servicios a usuarios externos que utilizan APIs, quizás confiando en clientes JavaScript sofisticados para generar páginas web y vistas en el dispositivo cliente. La seguridad de las API es un reto diferente a la seguridad del tráfico web típico. Las APIs pueden ofrecer una funcionalidad mucho más rica y pueden exponer información interna sensible, por lo que es esencial auditar cuidadosamente todas las APIs accesibles desde el exterior para determinar tanto la información que pueden revelar como los sistemas internos que tocan. La autenticación obligatoria (incluso para el acceso anónimo) y la limitación de velocidad pueden limitar el potencial de los ataques DoS. El registro detallado es esencial para crear una pista de auditoría y para detectar transacciones anómalas o tasas de error inusualmente altas. Se pueden utilizar patrones de interruptores automáticos para aislar servicios defectuosos sin comprometer significativamente la aplicación.
TR: ¿Alguno de estos riesgos ha sido explotado o apalancado en el mundo real?
OB: «Vigilar pasivamente este tipo de tráfico es muy común. Los documentos filtrados muestran que la NSA y otras organizaciones gubernamentales han monitoreado y catalogado las comunicaciones entre los centros de datos de Google, por ejemplo. En respuesta, Google comenzó a encriptar este tráfico, de manera similar a lo que se recomienda en la pregunta anterior.
Aunque este tipo de ataque no es específico de los microservicios, la cantidad de tráfico adicional de red «este-oeste» introducido por los microservicios los hace más susceptibles.
Cualquier medio que un atacante pueda utilizar para obtener acceso a un componente, y luego para trazar la arquitectura más amplia de la aplicación, puede ser explotado para comprometer una aplicación. Por ejemplo, la vulnerabilidad HTTPoxy que se reveló en 2019 proporcionó una forma de redirigir las solicitudes generadas internamente a un servidor de la elección del atacante, lo que permite al atacante obtener información sobre la arquitectura interna y capturar potencialmente tokens de autenticación y otra información sensible.
Un diseño deficiente de la API también puede ser explotado para revelar información interna e incluso información de los clientes. Por ejemplo, reutilizar la autenticación o la identificación de tokens (o permitir que un atacante los fuerce) es una mala práctica y puede ser usada para acceder a datos internos».
TR: ¿Qué recomienda para una estrategia de seguridad de microservicios fiable?
OB: «Cualquier organización que esté exponiendo una o más APIs para acceso externo debe implementar alguna forma de pasarela API. Esto no tiene que ser necesariamente un dispositivo especializado – para muchos casos de uso, las organizaciones utilizan un proxy inverso inteligente que les permite inspeccionar, autenticar y limitar la velocidad de las solicitudes de API, admitiendo únicamente las solicitudes que cumplen con los criterios apropiados y registrando todas las transacciones. No hace falta decir que todo el tráfico de la API debe estar cifrado mediante TLS. Los clientes de la API deben autenticarse utilizando un identificador de aplicación (y una clave de API u otro secreto compartido) y un identificador de usuario (un certificado SSL o un token de OAuth. Incluso las solicitudes anónimas de API deben ser requeridas para utilizar un identificador de usuario único, con el fin de aplicar límites de tarifas y registrar el tráfico.
Usar SSL internamente para todo el tráfico, autenticar y revocar todo el acceso usando una PKI, y autenticar e inspeccionar el tráfico entrante usando un proxy inverso es un gran paso para satisfacer las necesidades adicionales y únicas de asegurar las aplicaciones de microservicios.
Además, no debe olvidarse la seguridad interna de una aplicación de microservicios. Vale la pena mantener un grado saludable de sospecha de los otros componentes de la aplicación; incluso si se puede confiar en ellos ahora, no hay forma de saber cómo crecerá la base de clientes para la aplicación en el futuro Un buen primer paso es estandarizar rápidamente el uso de TLS para todas las comunicaciones internas y crear una validación de certificados tanto de clientes como de servidores en la arquitectura desde el principio. Una ventaja importante de utilizar una PKI interna (infraestructura de clave pública) es que puede asignar certificados de cliente y servidor a cada cliente y servidor dentro de la aplicación. Una PKI central facilita al equipo de operaciones la revocación del acceso a los componentes internos del cliente o servidor si están comprometidos, o incluso si se retiran y se sustituyen por contenedores más nuevos. Además, una identidad única para el punto final de cada transacción es inestimable a la hora de registrar y auditar las transacciones.»
TR: ¿Recomienda usted otros métodos para obtener microservicios?
OB: «Detección de intrusiones mediante la identificación de tráfico y comportamiento anómalos (altas tasas de error, ciclos frecuentes de credenciales de autenticación, solicitudes malformadas o repetidas) para identificar y luego bloquear a los malos actores.
Emplee un principio de mínimo privilegio para cada componente de la aplicación: control de acceso de lista blanca, protección secreta mediante tokens revocables, autenticación PKI y control de acceso, con especial atención a las API que pueden acceder a datos confidenciales.
Y asegúrese de utilizar regularmente herramientas de intrusión y solicitar fuzzers (una técnica utilizada para encontrar problemas de código o riesgos de seguridad introduciendo grandes cantidades de información aleatoria – fuzz – en el sistema para ver si se puede comprometer o causar un fallo) en el desarrollo y pruebas para identificar los problemas antes de que un atacante pueda encontrarlos».
Boletín informativo de consejotecnologico.com
Refuerce las defensas de seguridad de TI de su organización manteniéndose al día de las últimas noticias, soluciones y mejores prácticas en materia de ciberseguridad. Entregado los martes y jueves
Inscríbase hoy
:
Los expertos explican por qué los microservicios están sobrevalorado
s
Por qué los microservicios están a punto de tener su momento de «nub
e
Cómo un gigante del comercio electrónico utiliza los microservicios y el código abierto para escalar como loc
o
Microservicios 101: Lo bueno, lo malo y lo feo