En este documento, se describen las arquitecturas de implementación recomendadas de los Controles del servicio de VPC. Este documento está dirigido a administradores de red, arquitectos de seguridad y profesionales de operaciones en la nube que ejecutan y operan implementaciones a gran escala a escala de producción en Google Cloud y 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 planificar la habilitación de los Controles del servicio de VPC con anticipación y considerar los Controles del servicio de VPC 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. Te recomendamos que evites los diseños de perímetro que usen varios puentes, proyectos de red perimetral o un perímetro 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 efectiva 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 de un perímetro pueden comunicarse libremente con los permisos necesarios de IAM y controles de red, los equipos responsables de la administración del perímetro se ocuparán principalmente del acceso norte-sur, que es el acceso desde 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 para administrar el tráfico este-oeste entre los perímetros de una organización, además del tráfico norte-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 en capas el perímetro con controles de seguridad adicionales y prácticas recomendadas, como asegurarte de que los recursos dentro de la red de VPC no tengan salida directa de 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
Ciertos casos de uso pueden requerir varios perímetros para una organización. Por ejemplo, una organización que controla datos de atención médica podría necesitar un perímetro para datos no ofuscados y de alta confianza, y un perímetro separado para los datos desidentificados de nivel inferior a fin 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 sea un caso de uso principal para la organización, considera usar más de un perímetro. Si generas y compartes datos de nivel inferior, como datos de salud de pacientes desidentificados, puedes usar un perímetro separado para facilitar el uso compartido con entidades externas. Para obtener más información, consulta los patrones de referencia para el intercambio seguro de datos.
Además, si usas tu organización de Google Cloud para alojar usuarios externos independientes, como socios o clientes, considera definir un perímetro para cada usuario. Si consideras que el movimiento de datos de una de estas instancias a otro es un robo de datos, te recomendamos que implementes un perímetro separado.
Diseño de perímetro
Recomendamos que habilites todos los servicios protegidos cuando creas un perímetro, lo que ayuda a reducir la complejidad operativa y minimizar los posibles vectores de robo de datos. Debido a que dejar las APIs sin protección aumenta los posibles vectores de robo de datos, debería haber revisiones y justificaciones si tu organización opta por proteger una API y no otra.
Todos los proyectos nuevos deben pasar por el proceso de revisión y calificación que se describe en las siguientes secciones. Incluye en el perímetro todos los proyectos que aprueben las condiciones de calificación.
Asegúrate de que no haya una ruta de acceso a la VIP privada desde cualquiera de las VPC del perímetro. Si permites una ruta de red a private.googleapis.com, negarás la protección de los Controles del servicio de VPC del robo de datos privilegiados. Si debes permitir el acceso a un servicio no compatible, intenta aislar el uso de servicios no compatibles en un proyecto separado o mueve 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. Para calificar, haz lo siguiente:
¿Existe un componente que tenga una dependencia fija en un servicio que los Controles del servicio de VPC no admita?
La aplicación de los Controles del servicio de VPC no es ambigua, por lo que es posible que este tipo de dependencia no funcione en un perímetro. Te recomendamos modificar la carga de trabajo para aislar el requisito de los servicios no compatibles en un proyecto separado o quitar la carga de trabajo fuera del perímetro.
¿Hay un componente que no tiene datos sensibles y no utilice datos sensibles de otros proyectos?
Si respondiste que sí a cualquiera de las preguntas anteriores, te recomendamos que no coloques el proyecto en un perímetro. Puedes solucionar este problema como se explica en el tema Diseño de listas de entidades permitidas. Sin embargo, te recomendamos que minimices la complejidad del perímetro.
¿Qué sigue?
- Obtén más información para crear un perímetro de servicio.
- Obtén información sobre cómo probar el impacto de un perímetro con el modo de ejecución de prueba.
- Obtén información sobre las reglas de entrada y salida que permiten la comunicación entre perímetros de servicio.