Diseño multi-cuenta de Amazon VPC Lattice - Patrones de configuración con RAM y redes de servicios
Explicamos el diseño de compartición con RAM, la estrategia de segmentación de redes de servicios y el diseño jerárquico de Auth Policy para operar VPC Lattice en entornos multi-cuenta.
Desafíos de VPC Lattice en entornos multi-cuenta
En la estrategia multi-cuenta de AWS, se aíslan las cargas de trabajo por cuenta para asegurar los límites de seguridad. Sin embargo, la comunicación entre microservicios necesita cruzar los límites de las cuentas, lo que tradicionalmente se lograba combinando VPC peering, Transit Gateway y PrivateLink. VPC Lattice puede establecer comunicación entre cuentas a nivel de aplicación, pero el diseño en entornos multi-cuenta tiene consideraciones específicas. La propiedad de la red de servicios, el alcance de compartición de servicios y la responsabilidad de gestión de Auth Policy son puntos de decisión importantes en el diseño.
Compartición de redes de servicios mediante RAM
La conexión entre cuentas de VPC Lattice se realiza a través de AWS Resource Access Manager (RAM). La cuenta propietaria de la red de servicios crea un recurso compartido RAM y otorga permisos de asociación a las cuentas participantes. Los destinos de compartición pueden ser IDs de cuenta individuales, unidades organizativas (OU) de Organizations o la organización completa. El patrón recomendado es centralizar las redes de servicios en una cuenta dedicada de administración de red (Networking Account) y compartir por OU. Esto centraliza la gestión del ciclo de vida de las redes de servicios y otorga automáticamente acceso cuando se agrega una nueva cuenta de carga de trabajo a la OU. La aprobación de compartición RAM puede automatizarse utilizando la relación de confianza de Organizations, reduciendo la carga operativa.
Estrategia de segmentación de redes de servicios
Cómo segmentar las redes de servicios depende del tamaño de la organización y los requisitos de seguridad. En organizaciones pequeñas (menos de 10 cuentas), una configuración simple con una única red de servicios que registre todos los servicios es más fácil de gestionar. Para organizaciones medianas y grandes, se recomienda segmentar por entorno (producción, staging, desarrollo) o por dominio (pagos, autenticación, notificaciones, etc.). La segmentación por entorno elimina el riesgo de que servicios de producción sean llamados desde el entorno de desarrollo. La segmentación por dominio clarifica los límites de responsabilidad entre equipos y permite distribuir la gestión de Auth Policy. Sin embargo, segmentar demasiado las redes de servicios complica las rutas de comunicación entre servicios y aumenta la carga operativa. Se recomienda como guía práctica tener entre 50 y 100 servicios por red de servicios, y considerar la segmentación cuando se supere ese número. Para más detalles sobre diseño multi-cuenta, puede consultar libros especializados (Amazon).
Diseño jerárquico de Auth Policy
Las Auth Policy de VPC Lattice se aplican en dos niveles: a nivel de red de servicios y a nivel de servicio. En entornos multi-cuenta, esta estructura jerárquica se aprovecha para diseñar la separación de responsabilidades. La política a nivel de red de servicios es gestionada por la cuenta de administración de red y controla a grandes rasgos qué principales de qué cuentas pueden acceder a los servicios dentro de la red. La política a nivel de servicio es gestionada por cada cuenta de carga de trabajo y controla de forma granular qué principales pueden acceder a su servicio. Esta separación permite que los administradores de red controlen el marco general de seguridad mientras cada equipo gestiona autónomamente el control de acceso de sus propios servicios. La evaluación de políticas se realiza con condición AND, por lo que un acceso denegado a nivel de red de servicios no se permitirá aunque se autorice a nivel de servicio.
Resumen
En el diseño multi-cuenta de VPC Lattice, los principales patrones de diseño son la gestión centralizada de redes de servicios mediante compartición RAM, la segmentación de redes de servicios por entorno o dominio, y la separación de responsabilidades mediante los dos niveles de Auth Policy. Se recomienda como base centralizar las redes de servicios en la cuenta de administración de red y compartir por OU mediante RAM, considerando la segmentación de redes de servicios a medida que la organización crece.