Desplegar el plano

Requisitos previos para implementar los recursos de la canalización inicial

Sigue estos pasos antes de implementar la canalización base:

• Crea una cuenta de Cloud Identity y verifica la propiedad del dominio.
• Solicita una cuenta de facturación mensual a tu equipo de Ventas de Google Cloud o crea una cuenta de facturación con servicio automático.
• Aplica las prácticas recomendadas de seguridad para las cuentas de administrador.
• Verificar y conciliar problemas con cuentas de usuario de consumidor.
• Configura tu proveedor de identidades externo como fuente de información veraz para sincronizar cuentas de usuario y el SSO.
• Aprovisiona los grupos de control de acceso necesarios para ejecutar el blueprint.
• Determina la topología de red que vas a usar.
• Decide qué herramienta de gestión de código fuente vas a usar. Las instrucciones de terraform-example-foundation se escriben en un repositorio de Git alojado en Cloud Source Repositories.
• Decide qué herramientas de automatización de CI/CD vas a usar. terraform-example-foundation proporciona diferentes conjuntos de instrucciones para distintas herramientas de automatización.

Para conectarte a un entorno local, prepara lo siguiente:

• Planifica la asignación de direcciones IP en función del número y el tamaño de los intervalos que requiera el plano.
• Solicita tus conexiones de interconexión dedicada.

Pasos para desplegar terraform-example-foundation desde GitHub

Sigue las instrucciones del archivo README de cada fase para implementar terraform-example-foundation desde GitHub:

• Fase 0-bootstrap para crear un flujo de procesamiento básico.

  Si usas una cuenta de facturación de autoservicio, debes solicitar cuota adicional para el proyecto antes de pasar a la siguiente fase.

• Fase 1-org para configurar recursos a nivel de organización.
• Fase 2-environments para crear entornos.
• Organiza 3-networks-dual-svpc or 3-networks-hub-and-spoke para crear recursos de red en la topología que prefieras.
• Fase 4-projects para crear una canalización de infraestructura.
• Si quieres, puedes organizar 5-app-infra para ver un ejemplo de uso de la canalización de infraestructura.

Pasos adicionales después de la implementación de IaC

Después de implementar el código de Terraform, haz lo siguiente:

• Completa los cambios de configuración on-premise.
• Activa Security Command Center Premium.
• Exportar datos de Facturación de Cloud a BigQuery
• Regístrate en un plan de Cloud Customer Care.
• Habilita los registros de Transparencia de acceso.
• Compartir datos de Cloud Identity con Google Cloud.
• Aplica los controles administrativos de Cloud Identity que no se automatizan con la implementación de IaC.
• Evalúa cuáles de los controles administrativos adicionales para clientes con cargas de trabajo sensibles son adecuados para tu caso práctico.
• Consulta las prácticas recomendadas de operaciones y planifica cómo conectar tus operaciones y funciones actuales a los recursos de la base.

Protege tus recursos con Controles de Servicio de VPC

Controles de Servicio de VPC te permite definir políticas de seguridad que impidan el acceso a servicios gestionados por Google fuera de un perímetro de confianza, bloquear el acceso a datos desde ubicaciones no fiables y mitigar los riesgos de filtración externa de datos. Sin embargo, Controles de Servicio de VPC puede provocar que los servicios dejen de funcionar hasta que definas excepciones para permitir los patrones de acceso previstos.

Evalúa si el valor de mitigar los riesgos de exfiltración justifica el aumento de la complejidad y la sobrecarga operativa que supone adoptar Controles de Servicio de VPC. El blueprint prepara los controles de red necesarios y un perímetro de Controles de Servicio de VPC de prueba, pero el perímetro no se aplica hasta que sigues pasos adicionales.

Restringir ubicaciones de recursos

Puede que tengas requisitos normativos que exijan que los recursos de la nube solo se implementen en ubicaciones geográficas aprobadas. Esta restricción de política de la organización obliga a que los recursos solo se puedan implementar en la lista de ubicaciones que definas.

Habilitar Assured Workloads

Assured Workloads proporciona controles de cumplimiento adicionales que te ayudan a cumplir regímenes normativos específicos. El plano proporciona variables opcionales en la canalización de implementación para habilitar la función.

Habilitar registros de acceso a datos

Es posible que tengas que registrar todos los accesos a determinados datos o recursos sensibles.

Evalúa en qué puntos de tus cargas de trabajo se gestionan datos sensibles que requieren registros de acceso a datos y habilita los registros de cada servicio y entorno que trabaje con datos sensibles.

Habilitar aprobación de acceso

Aprobación de acceso asegura que el equipo de Asistencia de Google Cloud y el de ingeniería necesiten tu aprobación explícita siempre que deban acceder al contenido de tus clientes.

Evalúa el proceso operativo necesario para revisar las solicitudes de Aprobación de acceso y mitigar posibles retrasos en la resolución de incidencias de asistencia.

Habilitar Justificaciones de Acceso a Claves

Las justificaciones de acceso a claves te permiten controlar mediante programación si Google puede acceder a tus claves de cifrado, incluso para operaciones automatizadas y para que el equipo de Asistencia pueda acceder al contenido de tus clientes.

Evalúa los costes y la sobrecarga operativa asociados a las justificaciones de acceso a claves, así como su dependencia de Cloud External Key Manager (Cloud EKM).

Inhabilitar Cloud Shell

Cloud Shell es un entorno de desarrollo online. Este shell se aloja en un servidor gestionado por Google fuera de tu entorno, por lo que no está sujeto a los controles que hayas implementado en tus propias estaciones de trabajo de desarrollador.

Si quieres controlar estrictamente las estaciones de trabajo que puede usar un desarrollador para acceder a los recursos de la nube, inhabilita Cloud Shell. También puedes evaluar Cloud Workstations para obtener una opción de estación de trabajo configurable en tu propio entorno.

Restringir el acceso a la Google Cloud consola

Google Cloud te permite restringir el acceso a la Google Cloud consola en función de atributos de nivel de acceso, como la pertenencia a grupos, los intervalos de direcciones IP de confianza y la verificación de dispositivos. Algunos atributos requieren una suscripción adicional a Chrome Enterprise Premium.

Evalúa los patrones de acceso en los que confías para que los usuarios accedan a aplicaciones web, como la consola, como parte de una implementación de confianza cero más amplia.

Carpeta

fldr-environment

environment es una descripción de los recursos a nivel de carpeta de la organización Google Cloud. Por ejemplo, bootstrap, common, production, nonproduction, development o network.

Por ejemplo: fldr-production

ID del proyecto

prj-environmentcode-description-randomid

• environmentcode es una forma abreviada del campo de entorno (uno de los siguientes: b, c, p, n, d o net). Los proyectos host de VPC compartida usan el valor environmentcode del entorno asociado. Los proyectos de recursos de red que se comparten entre entornos, como el proyecto interconnect, usan el código del entorno net.
• description es información adicional sobre el proyecto. Puedes usar abreviaturas cortas que sean fáciles de leer.
• randomid es un sufijo aleatorio que se añade para evitar conflictos con nombres de recursos que deben ser únicos a nivel global y para evitar que los atacantes adivinen los nombres de los recursos. El plano añade automáticamente un identificador alfanumérico aleatorio de cuatro caracteres.

Por ejemplo: prj-c-logging-a1b2

Red VPC

vpc-environmentcode-vpctype

• environmentcode es una forma abreviada del campo de entorno (uno de b, c, p, n, d o net).
• vpctype puede ser svpc, float o peer.

Por ejemplo: vpc-p-svpc

Subred

sn-environmentcode-vpctype-region{-description}

• environmentcode es una forma abreviada del campo de entorno (uno de b, c, p, n, d o net).
• vpctype puede ser svpc, float o peer.
• region es cualquier Google Cloud región válida en la que se encuentre el recurso. Te recomendamos que elimines los guiones y uses una forma abreviada de algunas regiones y direcciones para no superar el límite de caracteres. Por ejemplo, au (Australia), na (Norteamérica), sa (Sudamérica), eu (Europa), se (sureste) o ne (noreste).
• description es información adicional sobre la subred. Puedes usar abreviaturas cortas y fáciles de leer.

Por ejemplo: sn-p-svpc-uswest1

Políticas de cortafuegos

fw-firewalltype-scope-environmentcode{-description}

• firewalltype es hierarchical o network.
• scope es global o la Google Cloud región en la que se encuentra el recurso. Te recomendamos que elimines los guiones y uses una forma abreviada de algunas regiones y direcciones para no alcanzar el límite de caracteres. Por ejemplo, au (Australia), na (Norteamérica), sa (Sudamérica), eu (Europa), se (sureste) o ne (noreste).
• environmentcode es una forma abreviada del campo de entorno (uno de b, c, p, n, d o net) que posee el recurso de política.
• description es información adicional sobre la política de cortafuegos jerárquica. Puedes usar abreviaturas cortas que sean fáciles de leer.

Por ejemplo:

fw-hierarchical-global-c-01

fw-network-uswest1-p-svpc

Cloud Router

cr-environmentcode-vpctype-region{-description}

• environmentcode es una forma abreviada del campo de entorno (uno de b, c, p, n, d o net).
• vpctype puede ser svpc, float o peer.
• region es cualquier región válida Google Cloud en la que se encuentre el recurso. Te recomendamos que elimines los guiones y uses una forma abreviada de algunas regiones y direcciones para no alcanzar el límite de caracteres. Por ejemplo, au (Australia), na (Norteamérica), sa (Sudamérica), eu (Europa), se (sureste) o ne (noreste).
• description es información adicional sobre Cloud Router. Puedes usar abreviaturas cortas que sean fáciles de leer.

Por ejemplo: cr-p-svpc-useast1-cr1

Conexión de Cloud Interconnect

ic-dc-colo

• dc es el nombre del centro de datos al que está conectada una Cloud Interconnect.
• colo es el nombre de la instalación de colocación con la que se empareja Cloud Interconnect desde el centro de datos on-premise.

Por ejemplo: ic-mydatacenter-lgazone1

Vinculación de VLAN de Cloud Interconnect

vl-dc-colo-environmentcode-vpctype-region{-description}

• dc es el nombre del centro de datos al que está conectada una Cloud Interconnect.
• colo es el nombre de la instalación de colocación con la que se empareja Cloud Interconnect desde el centro de datos on-premise.
• environmentcode es una forma abreviada del campo de entorno (uno de b, c, p, n, d o net).
• vpctype puede ser svpc, float o peer.
• region es cualquier región válida Google Cloud en la que se encuentre el recurso. Te recomendamos que elimines los guiones y uses una forma abreviada de algunas regiones y direcciones para no alcanzar el límite de caracteres. Por ejemplo, au (Australia), na (Norteamérica), sa (Sudamérica), eu (Europa), se (sureste) o ne (noreste).
• description es información adicional sobre la VLAN. Puedes usar abreviaturas cortas y fáciles de leer.

Por ejemplo: vl-mydatacenter-lgazone1-p-svpc-useast1-cr1

Grupo

grp-gcp-description@example.com

Donde description es información adicional sobre el grupo. Puedes usar abreviaturas cortas y fáciles de leer.

Por ejemplo: grp-gcp-billingadmin@example.com

Función personalizada

rl-description

Donde description es información adicional sobre el rol. Puedes usar abreviaturas cortas y fáciles de leer.

Por ejemplo: rl-customcomputeadmin

Cuenta de servicio

sa-description@projectid.iam.gserviceaccount.com

Donde:

• description es información adicional sobre la cuenta de servicio. Puedes usar abreviaturas cortas que sean fáciles de leer.
• projectid es el identificador de proyecto único a nivel mundial.

Por ejemplo: sa-terraform-net@prj-b-seed-a1b2.iam.gserviceaccount.com

Segmento de almacenamiento

bkt-projectid-description

Donde:

• projectid es el identificador de proyecto único a nivel mundial.
• description es información adicional sobre el contenedor de almacenamiento. Puedes usar abreviaturas cortas que sean fáciles de leer.

Por ejemplo: bkt-prj-c-infra-pipeline-a1b2-app-artifacts

Organización: el plano técnico usa una sola organización como nodo raíz de todos los recursos.

En Decide una jerarquía de recursos para tu Google Cloud zona de aterrizaje se presentan situaciones en las que puede ser preferible tener varias organizaciones, como las siguientes:

• Tu organización incluye subempresas que probablemente se vendan en el futuro o que funcionen como entidades completamente independientes.
• Quieres experimentar en un entorno de pruebas sin conectividad con tu organización.

Estructura de carpetas: el plano tiene una estructura de carpetas que divide las cargas de trabajo en las carpetas production, non-production y development en la capa superior.

En Decidir una jerarquía de recursos para tu Google Cloud zona de aterrizaje se presentan otros enfoques para estructurar las carpetas en función de cómo quieras gestionar los recursos y heredar las políticas, como los siguientes:

• Carpetas basadas en entornos de aplicación
• Carpetas basadas en entidades regionales o filiales
• Carpetas basadas en el marco de rendición de cuentas

Políticas de organización: el blueprint aplica todas las restricciones de las políticas de organización en el nodo de organización.

Es posible que tengas políticas de seguridad o formas de trabajar diferentes para distintas partes de la empresa. En este caso, aplica las restricciones de la política de organización en un nodo inferior de la jerarquía de recursos. Consulta la lista completa de restricciones de políticas de la organización que te ayudarán a cumplir tus requisitos.

Herramientas de la canalización de despliegue: el blueprint usa Cloud Build para ejecutar la canalización de automatización.

Puede que prefieras otros productos para tu flujo de implementación, como Terraform Enterprise, GitLab Runners, GitHub Actions o Jenkins. El plano incluye instrucciones alternativas para cada producto.

Repositorio de código para la implementación: el plano usa Cloud Source Repositories como repositorio de Git privado gestionado.

Usa el sistema de control de versiones que prefieras para gestionar los repositorios de código, como GitLab, GitHub o Bitbucket.

Si utilizas un repositorio privado alojado en tu entorno local, configura una ruta de red privada desde tu repositorio hasta tu entorno de Google Cloud.

Proveedor de identidades: el blueprint presupone que hay un Active Directory local y federa las identidades a Cloud Identity mediante Google Cloud Directory Sync.

Si ya usas Google Workspace, puedes usar las identidades de Google que ya se gestionan en Google Workspace.

Si no tienes un proveedor de identidades, puedes crear y gestionar identidades de usuario directamente en Cloud Identity.

Si tienes un proveedor de identidades, como Okta, Ping o Azure Entra ID, puedes gestionar las cuentas de usuario en tu proveedor de identidades y sincronizarlas con Cloud Identity.

Si tienes requisitos de soberanía de datos o de cumplimiento que te impiden usar Cloud Identity y no necesitas identidades de usuario de Google gestionadas para otros servicios de Google, como Google Ads o Google Marketing Platform, puede que prefieras la federación de identidades de empleados. En este caso, ten en cuenta las limitaciones de los servicios compatibles.

Varias regiones: el plano despliega recursos regionales en dos regiones diferentes para facilitar el diseño de cargas de trabajo con requisitos de alta disponibilidad y recuperación tras desastres. Google Cloud

Si tienes usuarios finales en más ubicaciones geográficas, puedes configurar más Google Cloud regiones para crear recursos más cerca de los usuarios finales y reducir la latencia.

Si tienes restricciones de soberanía de datos o tus necesidades de disponibilidad se pueden satisfacer en una sola región, puedes configurar solo unaGoogle Cloud región.

Asignación de direcciones IP: el plano técnico proporciona un conjunto de intervalos de direcciones IP.

Es posible que tengas que cambiar los intervalos de direcciones IP específicos que se usan en función de la disponibilidad de direcciones IP en tu entorno híbrido. Si modificas los intervalos de direcciones IP, utiliza el plan como guía para saber el número y el tamaño de los intervalos necesarios, y consulta los intervalos de direcciones IP válidos para Google Cloud.

Redes híbridas: el plano técnico usa Interconnect dedicado en varios sitios físicos yGoogle Cloud regiones para ofrecer el máximo ancho de banda y disponibilidad.

En función de tus requisitos de coste, ancho de banda y fiabilidad, puedes configurar Partner Interconnect o Cloud VPN.

Si necesitas empezar a desplegar recursos con conectividad privada antes de que se pueda completar una interconexión dedicada, puedes empezar con Cloud VPN y cambiar a la interconexión dedicada más adelante.

Si no tienes un entorno local, es posible que no necesites una red híbrida.

Perímetro de Controles de Servicio de VPC: el blueprint recomienda un único perímetro que incluya todos los proyectos de servicio de tu topología de VPC compartida.

Puede que tengas un caso práctico que requiera varios perímetros para una organización o que decidas no usar Controles de Servicio de VPC.

Para obtener más información, consulta cómo mitigar la exfiltración de datos a través de las APIs de Google.

Secret Manager: la blueprint implementa un proyecto para usar Secret Manager en la carpeta common para los secretos de toda la organización y un proyecto en cada carpeta de entorno para los secretos específicos de cada entorno.

Si tienes un solo equipo responsable de gestionar y auditar secretos sensibles en toda la organización, puede que prefieras usar un solo proyecto para gestionar el acceso a los secretos.

Si permites que los equipos de carga de trabajo gestionen sus propias secretos, es posible que no uses un proyecto centralizado para gestionar el acceso a los secretos y, en su lugar, permitas que los equipos usen sus propias instancias de Secret Manager en proyectos de carga de trabajo.

Cloud KMS: la plantilla implementa un proyecto para usar Cloud KMS en la carpeta common de las claves de toda la organización y un proyecto para cada carpeta de entorno de las claves de cada entorno.

Si tienes un solo equipo responsable de gestionar y auditar las claves de cifrado de toda la organización, puede que prefieras usar un solo proyecto para gestionar el acceso a las claves. Un enfoque centralizado puede ayudar a cumplir los requisitos de cumplimiento, como los custodios de claves de PCI.

Si permites que los equipos de cargas de trabajo gestionen sus propias claves, es posible que no utilices un proyecto centralizado para gestionar el acceso a las claves y, en su lugar, permitas que los equipos usen sus propias instancias de Cloud KMS en proyectos de cargas de trabajo.

Sumideros de registros agregados: la blueprint configura un conjunto de sumideros de registros en el nodo de la organización para que un equipo de seguridad central pueda revisar los registros de auditoría de toda la organización.

Puede que tengas diferentes equipos responsables de auditar distintas partes de la empresa, y estos equipos pueden necesitar diferentes registros para hacer su trabajo. En este caso, diseña varios receptores agregados en las carpetas y los proyectos adecuados, y crea filtros para que cada equipo reciba solo los registros necesarios. También puedes diseñar vistas de registro para controlar el acceso de forma granular a un segmento de registro común.

Granularidad de las canalizaciones de infraestructura: el plano técnico usa un modelo en el que cada unidad de negocio tiene una canalización de infraestructura independiente para gestionar sus proyectos de carga de trabajo.

Puede que prefieras una única canalización de infraestructura gestionada por un equipo central si tienes un equipo central responsable de implementar todos los proyectos y la infraestructura. Este equipo central puede aceptar solicitudes de extracción de los equipos de carga de trabajo para revisarlas y aprobarlas antes de crear el proyecto, o bien puede crear la solicitud de extracción por su cuenta en respuesta a un sistema de incidencias.

Puede que prefieras usar canalizaciones más granulares si los equipos de cargas de trabajo individuales tienen la capacidad de personalizar sus propias canalizaciones y quieres diseñar cuentas de servicio con privilegios más granulares para las canalizaciones.

Exportaciones de SIEM: el blueprint gestiona todos los resultados de seguridad de Security Command Center.

Decide si vas a exportar los resultados de seguridad de Security Command Center a herramientas como Google Security Operations o tu SIEM, o si los equipos van a usar la consola para ver y gestionar los resultados de seguridad. Puedes configurar varias exportaciones con filtros únicos para diferentes equipos con distintos ámbitos y responsabilidades.