En este documento se describen las arquitecturas de implementación recomendadas de Controles de Servicio de VPC. Este documento está dirigido a administradores de redes, arquitectos de seguridad y profesionales de operaciones en la nube que gestionan implementaciones a gran escala en producción en Google Cloud y que quieren mitigar el riesgo de pérdida de datos sensibles.
Como la protección de Controles de Servicio de VPC afecta a la funcionalidad de los servicios en la nube, te recomendamos que planifiques con antelación la habilitación de Controles de Servicio de VPC y que tengas en cuenta este servicio durante el diseño de la arquitectura. Es importante que el diseño de los Controles de Servicio de VPC sea lo más sencillo posible. Te recomendamos que evites los diseños de perímetro que usen varios puentes, proyectos de redes perimetrales o un perímetro de DMZ, así como niveles de acceso complejos.
Usar un perímetro unificado común
Un único perímetro grande, denominado perímetro unificado común, ofrece la protección más eficaz contra la filtración externa de datos en comparación con el uso de varios perímetros segmentados.
Un perímetro unificado común también ofrece la ventaja de reducir la sobrecarga de gestión para los equipos responsables de la creación y el mantenimiento del perímetro. Como los servicios y los recursos de red de un perímetro pueden comunicarse libremente con los permisos de gestión de identidades y accesos y de controles de red necesarios, los equipos responsables de la gestión del perímetro se centrarán principalmente en el acceso de norte a sur, es decir, el acceso desde Internet a los recursos que se encuentran dentro del perímetro.
Cuando una organización usa varios perímetros más pequeños, los equipos de gestión de perímetros deben dedicar recursos a gestionar el tráfico este-oeste entre los perímetros de la organización, además del tráfico norte-sur procedente de fuera de la organización. En función del tamaño de la organización y del número de perímetros, esta sobrecarga puede ser considerable. Te recomendamos que añadas controles de seguridad y prácticas recomendadas a tu perímetro, como asegurarte de que los recursos de la red de VPC no tengan salida directa a Internet.
Los perímetros de servicio no están pensados para sustituir ni reducir la necesidad de controles de gestión de identidades y accesos. Cuando definas los controles de acceso, te recomendamos que te asegures de que se sigue el principio de privilegio mínimo y de que se aplican las prácticas recomendadas de gestión de identidades y accesos.
Para obtener más información, consulta el artículo Crear un perímetro de servicio.
Usar varios perímetros en una organización
En algunos casos prácticos, una organización puede necesitar varios perímetros. Por ejemplo, una organización que gestione datos sanitarios puede querer un perímetro para los datos de alta confianza no ofuscados y otro perímetro para los datos desidentificados de nivel inferior, de modo que pueda compartir datos con entidades externas y, al mismo tiempo, proteger los datos de alta confianza.
Si tu organización quiere cumplir estándares como PCI DSS, puede que te interese tener un perímetro independiente alrededor de tus datos regulados.
Si tu organización usa principalmente el uso compartido de datos, te recomendamos que utilices más de un perímetro. Si produces y compartes datos de nivel inferior, como datos de salud de pacientes anonimizados, 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 para el intercambio de datos seguro.
Además, si usas tu Google Cloud organización para alojar inquilinos independientes de terceros, como partners o clientes, considera la posibilidad de definir un perímetro para cada inquilino. Si considera que el movimiento de datos de uno de estos inquilinos a otro es una exfiltración, le recomendamos que implemente un perímetro independiente.
Diseño de perímetro
Te recomendamos que habilites todos los servicios protegidos al crear un perímetro, lo que te ayudará a reducir la complejidad operativa y minimizar los posibles vectores de filtración. Si las APIs no están protegidas, aumentan los posibles vectores de exfiltración, por lo que debe haber revisiones y justificaciones si tu organización decide proteger una API y no otra.
Todos los proyectos nuevos deben someterse al proceso de revisión y cualificación que se describe en las siguientes secciones. Incluye en el perímetro todos los proyectos que cumplan las condiciones de cualificación.
Asegúrate de que no haya ninguna ruta a la VIP privada desde ninguna de las VPCs del perímetro. Si permites una ruta de red a private.googleapis.com, anularás la protección de Controles de Servicio de VPC contra la filtración de datos por parte de usuarios internos. Si debes permitir el acceso a un servicio no admitido, intenta aislar el uso de servicios no admitidos en un proyecto independiente o mueve toda la carga de trabajo fuera del perímetro.
Revisar y calificar proyectos
Una empresa típica tiene muchos proyectos que representan cargas de trabajo y estructuras de alto nivel, como planos de control, lagos de datos, unidades de negocio y fases del ciclo de vida. Además de organizar estos proyectos y componentes en carpetas, te recomendamos que los califiques para que estén dentro o fuera de un perímetro de Controles de Servicio de VPC. Para obtener la cualificación, responde a las siguientes preguntas:
¿Hay algún componente que tenga una dependencia estricta de un servicio que no sea compatible con Controles de Servicio de VPC?
La aplicación de Controles de Servicio de VPC es inequívoca, por lo que es posible que este tipo de dependencia no funcione en un perímetro. Te recomendamos que modifiques la carga de trabajo para aislar el requisito de los servicios no admitidos en un proyecto independiente o que la saques del perímetro por completo.
¿Hay algún componente que no tenga datos sensibles y que no consuma datos sensibles de otros proyectos?
Si has respondido afirmativamente a alguna de las preguntas anteriores, te recomendamos que no incluyas el proyecto en un perímetro. Puedes solucionar este problema, tal como se explica en el tema Diseño de la lista de permitidos. Sin embargo, le recomendamos que minimice la complejidad del perímetro.
Siguientes pasos
- Consulta cómo crear un perímetro de servicio.
- Consulta cómo probar el impacto de un perímetro con el modo de prueba.
- Consulta información sobre las reglas de entrada y salida que permiten la comunicación entre perímetros de servicio.