En este documento, se describen las arquitecturas de implementación recomendadas de los Controles del servicio de VPC. Este documento está dirigido a los administradores de redes, arquitectos de seguridad y profesionales de operaciones en la nube que ejecutan y operan implementaciones de producción a gran escala en Google Cloud y que desean mitigar el riesgo de pérdida de datos sensibles.
Debido a que la protección de los Controles del servicio de VPC afecta la funcionalidad de los servicios en la nube, te recomendamos que planifiques la habilitación de los Controles del servicio de VPC con anticipación y que los consideres durante el diseño de la arquitectura. Es importante que el diseño de los Controles del servicio de VPC sea lo más simple posible. Recomendamos que evites usar diseños de perímetro que usen varios puentes, proyectos de red de perímetro o un perímetro de DMZ y niveles de acceso complejos.
Usa un perímetro unificado común
Un solo perímetro grande, conocido como perímetro unificado común, proporciona la protección más eficaz contra el robo de datos en comparación con el uso de varios perímetros segmentados.
Un perímetro unificado común también proporciona el beneficio de una menor sobrecarga de administración para los equipos responsables de la creación y el mantenimiento del perímetro. Dado que los servicios y los recursos de red dentro un perímetro pueden comunicarse sin restricciones con los permisos necesarios de IAM y controles de red, los equipos responsables de la administración del perímetro se preocuparán principalmente por el acceso de norte a sur, que es el acceso de Internet a los recursos dentro del perímetro.
Cuando una organización usa varios perímetros más pequeños, los equipos de administración de perímetros deben dedicar recursos a administrar el tráfico de este a oeste entre los perímetros de una organización, además del tráfico de norte a sur desde fuera de la organización. Según el tamaño de la organización y la cantidad de perímetros, esta sobrecarga puede ser considerable. Te recomendamos que agregues capas a tu perímetro con controles de seguridad y prácticas recomendadas adicionales, como asegurarte de que los recursos dentro de la red de VPC no tengan salida directa a Internet.
Los perímetros de servicio no están diseñados para reemplazar ni reducir la necesidad de controles de IAM. Cuando definas los controles de acceso, te recomendamos que te asegures de que se siga el principio de privilegio mínimo y se apliquen las prácticas recomendadas de IAM.
Para obtener más información, consulta Crea un perímetro de servicio.
Usa varios perímetros en una organización
Algunos casos de uso pueden requerir varios perímetros para una organización. Por ejemplo, una organización que maneja datos de atención médica podría querer un perímetro para los datos de alta confianza y no ofuscados. También podría querer un perímetro independiente para los datos de nivel inferior y desidentificados con el objetivo de facilitar el uso compartido con entidades externas y, al mismo tiempo, proteger los datos de alta confianza.
Si tu organización desea cumplir con estándares como PCI DSS, es posible que desees tener un perímetro separado alrededor de tus datos regulados.
Cuando el uso compartido de datos es un caso de uso principal de tu organización, considera usar más de un perímetro. Si produces y compartes datos de nivel inferior, como datos de salud de pacientes desidentificados, puedes usar un perímetro independiente para facilitar el uso compartido con entidades externas. Para obtener más información, consulta los patrones de referencia del intercambio seguro de datos.
Además, si usas la organización de Google Cloud para alojar usuarios independientes de terceros, como socios o clientes, te recomendamos definir un perímetro para cada usuario. Si consideras que el movimiento de datos de uno de estos usuarios a otro constituye un robo de datos, recomendamos implementar un perímetro independiente.
Diseño de perímetro
Te recomendamos que habilites todos los servicios protegidos cuando crees un perímetro, lo que ayuda a reducir la complejidad operativa y minimizar los posibles vectores de robo de datos. Dejar las APIs sin protección aumenta los posibles vectores de robo de datos, por lo que deben realizarse revisiones y presentarse justificaciones si tu organización decide proteger una API y no otra.
Todos los proyectos nuevos deben someterse al proceso de revisión y calificación que se describe en las siguientes secciones. Incluye en el perímetro todos los proyectos que cumplan las condiciones de calificación.
Asegúrate de que no exista una ruta hacia la VIP privada desde ninguna de las VPC
del perímetro. Si permites una ruta de red a private.googleapis.com,
anulas la protección de los Controles del servicio de VPC contra el robo de datos por parte de usuarios con información privilegiada. Si debes permitir el acceso a un servicio no admitido, intenta aislar su uso en
un proyecto independiente o mover toda la carga de trabajo fuera del perímetro.
Revisa y califica proyectos
Una empresa típica tiene muchos proyectos que representan cargas de trabajo y construcciones de alto nivel, como planos de control, data lakes, unidades de negocios y etapas del ciclo de vida. Además de organizar estos proyectos y componentes en carpetas, te recomendamos que los califiques dentro o fuera de un perímetro de Controles del servicio de VPC. Te recomendamos realizar la calificación a partir de las siguientes preguntas:
¿Existe un componente con una dependencia estricta en un servicio que los Controles del servicio de VPC no admiten?
La aplicación de los Controles del servicio de VPC es inequívoca; por eso, este tipo de dependencia no funciona dentro de un perímetro. Recomendamos modificar la carga de trabajo para aislar el requisito de servicios no admitidos en un proyecto independiente o mover la carga de trabajo fuera del perímetro.
¿Existe algún componente que no contenga datos sensibles ni consuma datos sensibles de otros proyectos?
Si respondes que sí a alguna de las preguntas anteriores, recomendamos no incluir el proyecto en un perímetro. Puedes solucionar esta situación, como se explica en el tema Diseño de lista de entidades permitidas. Sin embargo, recomendamos reducir al mínimo la complejidad del perímetro.
¿Qué sigue?
- Obtén más información para crear un perímetro de servicio.
- Obtén más información para probar el impacto de un perímetro del modo de ejecución de prueba.
- Obtén más información sobre las reglas de entrada y salida que permiten la comunicación entre perímetros de servicio.