La segmentación de red tradicional no funciona para los microservicios. Las direcciones IP y los puertos no pueden proteger las comunicaciones de la API cuando los servicios se activan y desactivan dinámicamente en diferentes contenedores.
Las grandes empresas que utilizan arquitecturas de microservicios necesitan un enfoque diferente: una segmentación basada en la identidad que siga a los servicios dondequiera que se ejecuten.
Los CISO buscan herramientas de microsegmentación de código abierto que puedan:
- Aplicar políticas de seguridad de red entre las API para bloquear el tráfico no autorizado.
- Habilite el control de acceso basado en roles (RBAC) para definir los permisos de usuario y de dispositivo.
Hemos clasificado las 10 mejores herramientas de microsegmentación de código abierto según su puntuación en GitHub y su desarrollo activo.
Las 10 mejores herramientas de microsegmentación de código abierto
Tabla 1: Presencia en el mercado
Proveedor | # de estrellas de GitHub | # de colaboradores de GitHub | Idiomas compatibles | Integraciones clave | Código fuente |
|---|---|---|---|---|---|
Istio | 35.098 | 1.025 | Ir, Caparazón, Makefile, CSS, HTML, Pitón | administrador de certificados, Grafana, Jaeger, Kiali, Prometeo, AGUJA, Apache SkyWalking, Zipkin, Balanceadores de carga de terceros | |
HashiDays | 27.874 | 910 | Ir, MDX, SCSS., JavaScript, Bigote daliniano, Caparazón | CloudKinetics, Conocimiento, 3Nube, Atos, Microsoft Azul, Oracle Infraestructura en la nube, AWS, ACCUKNOX | |
Cilio | 18.731 | 745 | Ir, DO, Caparazón, Makefile, Dockerfile, Sabelotodo | AWS, Google Motor Kubernetes (GKE), Plano de datos V2, Anthos, Azure CNI | |
Linkerd | 10.453 | 354 | Ir, Óxido, JavaScript, Caparazón, Sabelotodo, Makefile | DNS externo, Cónsul, Istio, Knative | |
Franela | 8.530 | 235 | Ir, Caparazón, DO, Makefile, Dockerfile | No especificado | |
Tigera | 5.536 | 345 | Ir, DO, Pitón, Caparazón, Makefile, PowerShell | OpenStack, Franela | |
Malla | 4.927 | 605 | JavaScript, Ir, Bigote, CSS, Makefile, Agente de póliza abierta | AWS, Kong. OpenEBSMesh. SPIFFE. Prometeo | |
Kumahq | 3.535 | 101 | Ir, Makefile, Caparazón, Bigote, JavaScript, HTML | Soluciones de gestión de API nativas | |
Malla de servicios abiertos | 2.583 | 374 | Ir, Caparazón, Makefile, C++, Alondra | Dapr, Prometeo, Bandera, Piróscopo | |
Malla Traefik | 2.004 | 31 | Ir, Makefile, Dockerfile | Amazon EKS, K3S, Servicio Azure Kubernetes, Google Motor de Kubernetes |
Criterios de selección:
- Estrellas en GitHub: más de 2500
- Colaboradores en GitHub: más de 30
- Actualizaciones recientes: Al menos un lanzamiento en la última semana.
- Ordenado por estrellas de GitHub (descendente)
1. Istio
Plataforma abierta para controlar la comunicación API mediante la conexión de microservicios.
Capacidades de RBAC
Istio permite la microsegmentación dentro de una malla mediante la configuración de:
Roles: Defina los permisos de usuario especificando las actividades que un usuario puede realizar. Clasifique los roles por puestos de trabajo e identidades.
Ejemplo: El administrador define el rol como "el usuario Mert que llama desde el servicio frontend de la librería", combinando la identidad de rol del servicio que realiza la llamada (frontend de la librería) y el usuario final (Mert).
Restricciones de acceso: Cree políticas RBAC.
Ejemplo: El administrador de la base de datos crea restricciones que establecen que los administradores de la base de datos tienen acceso completo a los servicios de backend de la base de datos, pero el cliente web solo puede ver el servicio de frontend.
Figura 1: Microsegmentación de Istio con arquitectura RBAC
Fuente: Istio 1
El rol “products-viewer” tiene acceso de lectura (“GET” y “HEAD”). El usuario asignado a este rol puede enviar solicitudes y recibir respuestas al microservicio en el espacio de nombres “default”.
Figura 2: Ejemplo de consulta de microservicio con Istio
Fuente: Istio 2
2. Cónsul
Solución de redes de microservicios de HashiCorp con funciones de microsegmentación para la gestión de la comunicación API. Proporciona descubrimiento y malla de microservicios.
Los administradores pueden:
- Defina manualmente las solicitudes de datos mediante la línea de comandos o la API.
- Automatice el proceso de “descubrimiento y mallado de microservicios” en Kubernetes.
Esto garantiza que la comunicación entre servicios esté autorizada.
Vídeo 1: Introducción a la microsegmentación con autenticación de proxy mutuo en HashiCorp Consul
Fuente: HashiCorp 3
3. Cilio
Permite implementaciones de Kubernetes en múltiples clústeres para el descubrimiento de servicios, la microsegmentación y la gestión de políticas de seguridad de red .
Diferencia clave: Implementa reglas de seguridad basadas en la identidad del servicio/contenedor en lugar de la dirección IP. Los administradores utilizan políticas en distintos niveles para controlar el tráfico dentro del clúster de Kubernetes.
Ejemplo: Microsegmentación de vuelos de vacaciones
Escenario: Pasajeros en un vuelo de vacaciones con diferentes clases.
Espacios de nombres:
- “Economía” para pasajeros de clase económica
- “Business” para pasajeros de clase Business
- “Primera” para pasajeros de primera clase
Regla: Los pasajeros solo pueden acceder a los servicios de su clase (espacio de nombres).
Figura 3: Administradores creando tres espacios de nombres distintos con Cillium.
Figura 4: Administradores que crean los servicios a los que accede cada usuario en ese espacio de nombres (por ejemplo, economía) con Cillium.
Patrones de comunicación (configurados manualmente):
- Entrada desde cargas de trabajo dentro del mismo espacio de nombres (economía)
- Salida a cargas de trabajo dentro del mismo espacio de nombres (economía)
Cuando un cliente de clase económica solicita un servicio dentro del mismo espacio de nombres, Cilium permite el acceso.
Figura 5: Política de microsegmentación en acción con Cillium
Fuente: Isovalente 4
4. Linkerd
Capa de software de malla de servicios con capacidades de microsegmentación. Facilita la comunicación entre servicios o microservicios a través de un proxy.
Vídeo 2: ¿Qué es Linkerd?
Fuente: Linkerd 5
5. Franela
Proyecto de red virtual de código abierto diseñado para Kubernetes. Permite a los administradores aplicar políticas basadas en cómo se enruta el tráfico entre contenedores.
Limitación: Se centra en la segmentación de redes. No ofrece una función de aplicación de políticas para regular cómo se conectan los contenedores a la red. Proporciona una interfaz de red de contenedores (CNI) mediante un complemento para configurar los contenedores.
6. Calico
El proyecto de redes de código abierto de Tigera permite que las cargas de trabajo de Kubernetes y las que no lo son (o que son sistemas heredados) mantengan redes aisladas basadas en una arquitectura de confianza cero.
Aislar, proteger y asegurar múltiples dominios de seguridad, incluyendo:
- Cargas de trabajo de Kubernetes
- Espacios de nombres
- inquilinos
- Anfitriones
Componentes
Calico CNI: Plano de control de red L3/L4 que permite a los administradores configurar microservidores. Crea entornos aislados en flujos de comunicación entre hosts. Crea segmentos más pequeños basados en políticas entre protocolos de comunicación para proteger:
- contenedores
- clústeres de Kubernetes
- Máquinas virtuales
- Cargas de trabajo del host nativo
Conjunto de políticas de red Calico: Permite establecer políticas al configurar microservicios. Los administradores pueden:
- Utilice "namespace" para asignar permisos a determinadas direcciones IP en contenedores aislados o entornos virtuales.
- Cree configuraciones de red para redes divididas que restrinjan las direcciones IP.
Vídeo 3: Habilitación de la microsegmentación de cargas de trabajo con Calico
Fuente: Tigera 6
7. Meshery
Gestor de microservicios de código abierto y nativo de la nube.
Al administrar microservicios, los administradores crean:
Agrupación lógica: Segmenta los entornos para agrupar lógicamente las conexiones y credenciales relevantes. Esto facilita la gestión de recursos en comparación con el manejo individual de todas las conexiones.
Compartir recursos: Conecte entornos para asignar espacios de trabajo. Los miembros del equipo comparten recursos.
Vídeo 4: Diseño de Meshery
Fuente: Meshery 7
8. Kuma
Plano de control de código abierto para malla de servicios que proporciona comunicación y enrutamiento de microservicios.
Las organizaciones crean mallas de servicios basadas en la identidad y el cifrado. Los administradores pueden permitir o denegar las solicitudes entrantes en Kubernetes.
Figura 6: Interfaz de usuario de Kuma
Fuente: Kuma 8
9. Malla de servicios abiertos (OSM)
Malla de servicios nativa de la nube que permite a los usuarios gestionar microservicios.
Ejecuta la capa de control basada en Envoy en Kubernetes, configurada mediante API. Los usuarios pueden:
- Enviar solicitudes de denegación/permiso para la comunicación de tráfico de red entre API.
- Comunicación segura entre servicios a través de clústeres
- Defina políticas de control de acceso detalladas para los servicios.
Vídeo 5: Definición de políticas de control de acceso detalladas para servicios con Open Service Mesh (OSM)
Fuente: Microsoft Azure 9
10. Malla Traefik
Malla de servicios de código abierto con funciones de microsegmentación. Nativa de contenedores, se ejecuta en su clúster de Kubernetes.
Vídeo 6: Demostración de microservicios de Traefik Enterprise
Fuente: 10
Cómo seleccionar una herramienta de microsegmentación de código abierto
1. Evaluar la reputación de la herramienta
El número de estrellas y colaboradores de GitHub muestra la popularidad. Las herramientas con mayor popularidad reciben:
- Noticias, tendencias y novedades más recientes del sector.
- Más ayuda comunitaria
2. Analizar las características de la herramienta.
La mayoría de las soluciones de microsegmentación de código abierto incluyen gestión de microservicios, aplicación de políticas y opciones de inicio de sesión.
Si su empresa utiliza la microsegmentación para diversas aplicaciones, busque una solución integral.
Ejemplo: Una empresa que busca restricciones de acceso basadas en la identidad debería seleccionar un sistema con capacidades de control de acceso basado en roles (RBAC).
3. Comparación entre alternativas de código abierto y de código cerrado.
Limitaciones del código abierto:
- Integraciones limitadas
- Funcionalidad menos avanzada
Ventajas del código cerrado:
- Una solución más personalizada
- Funcionalidades más completas (gestión de la postura de seguridad en la nube (CSPM))
- Automatización del cambio de red
- Monitoreo de la configuración
- Mapeo de la topología de red
- Gestión de detección y exposición en la nube (CDEM)
Puede ser más productivo para su empresa.
Lecturas adicionales
- IA agencial para la ciberseguridad: casos de uso y ejemplos
- Segmentación de redes: 6 beneficios y 8 mejores prácticas
- Los 10 mejores programas de SDP según más de 4000 reseñas.
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios.