Implementa el plano

Requisitos previos antes de implementar los recursos de la canalización de base

Completa los siguientes pasos antes de implementar la canalización de base:

• Crea una cuenta de Cloud Identity y verifica la propiedad del dominio.
• Solicita una cuenta de facturación con tu equipo de ventas de Google Cloud o crea una cuenta de facturación de autoservicio.
• Aplica prácticas recomendadas de seguridad a las cuentas de administrador.
• Verifica y concilia los problemas con las cuentas de usuario personales.
• Configura tu proveedor de identidad externo como fuente de información para sincronizar cuentas de usuario y SSO.
• Aprovisiona los grupos para el control de acceso que son necesarios a fin de ejecutar el plano.
• Determina la topología de red que usarás.
• Decide tu herramienta de administración de código fuente. Las instrucciones para terraform-example-foundation se escriben en un repositorio de Git que se aloja en Cloud Source Repositories.
• Decide tus herramientas de automatización de CI/CD. terraform-example-foundation proporciona conjuntos de instrucciones diferentes para las diferentes herramientas de automatización.

Para conectarte a un entorno local existente, prepara lo siguiente:

• Planifica tu asignación de dirección IP en función de la cantidad y el tamaño de los rangos que requiere el plano.
• Solicita tus conexiones de interconexión dedicada.

Pasos para implementar terraform-example-foundation desde GitHub

Sigue las instrucciones de README para cada etapa para implementar terraform-example-foundation desde GitHub:

• Almacena la etapa 0-bootstrap para crear una canalización base.

  Si usas una cuenta de facturación de autoservicio, debes solicitar una cuota de proyecto adicional antes de continuar con la siguiente etapa.

• Almacena en etapa intermedia 1-org en etapa intermedia para configurar los recursos a nivel de organización.
• Almacena en etapa intermedia 2-environments para crear entornos.
• Almacena en etapa intermedia 3-networks-dual-svpc or 3-networks-hub-and-spoke para crear recursos de red en tu topología preferida.
• Almacena en etapa intermedia 4-projects para crear una canalización de infraestructura.
• De manera opcional, almacena en etapa intermedia 5-app-infra para ver un uso de muestra 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, completa lo siguiente:

• Completa los cambios de configuración locales.
• Activa Security Command Center Premium.
• Exporta datos de Facturación de Cloud a BigQuery.
• Regístrate para obtener un plan de Atención al cliente de Cloud.
• Habilita los registros de Transparencia de acceso.
• Comparte datos de Cloud Identity con Google Cloud.
• Aplica los controles administrativos de Cloud Identity que no están automatizados por la implementación de IaC.
• Evalúa cuál de los controles administrativos adicionales para clientes con cargas de trabajo sensibles es adecuado para tu caso de uso.
• Revisa las prácticas recomendadas de operaciones y planifica cómo conectar las operaciones y capacidades existentes a los recursos de base.

Protege tus recursos con los Controles del servicio de VPC

Controles del servicio de VPC te permiten definir políticas de seguridad que evitan el acceso a los servicios administrados por Google fuera de un perímetro de confianza, bloquean el acceso a los datos desde ubicaciones no confiables y mitigan los riesgos de robo de datos. Sin embargo, los Controles del servicio de VPC pueden hacer que los servicios existentes se rompan hasta que definas excepciones para permitir patrones de acceso deseados.

Evalúa si el valor de mitigar los riesgos de robo de datos justifica la mayor complejidad y la sobrecarga operativa de adoptar los Controles del servicio de VPC. El plano prepara redes restringidas y variables opcionales para configurar los Controles del servicio de VPC, pero el perímetro no está habilitado hasta que realices pasos adicionales para diseñarlo y habilitarlo.

Restringe las ubicaciones de los recursos

Es posible que tengas requisitos regulatorios que indiquen que los recursos en la nube solo se deben implementar en ubicaciones geográficas aprobadas. Esta restricción de política de la organización aplica que los recursos solo se pueden implementar en la lista de ubicaciones que definas.

Habilita Assured Workloads

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

Habilita los registros de acceso a los datos

Es posible que debas registrar todo el acceso a ciertos datos o recursos sensibles.

Evalúa dónde tus cargas de trabajo manejan datos sensibles que requieren registros de acceso a los datos y habilita los registros para cada servicio y entorno que trabaja con datos sensibles.

Habilita la aprobación de acceso

La aprobación de acceso garantiza que la ingeniería y el servicio de atención al cliente de Cloud requieran tu aprobación explícita cada vez que necesiten acceder al contenido de clientes.

Evalúa el proceso operativo necesario para revisar las solicitudes de aprobación de acceso para mitigar posibles demoras en la resolución de incidentes de asistencia.

Habilita Key Access Justifications

Key Access Justifications te permite controlar de manera programática si Google puede acceder a tus claves de encriptación, incluidas las operaciones automatizadas y la Atención al cliente para acceder al contenido de clientes.

Evalúa el costo y la sobrecarga operativa asociada con Key Access Justifications, así como su dependencia en Cloud External Key Manager (Cloud EKM).

Inhabilita Cloud Shell

Cloud Shell es un entorno de desarrollo en línea. Este shell está alojado en un servidor administrado por Google fuera de tu entorno y, por lo tanto, no está sujeto a los controles que puedes haber implementado en tus propias estaciones de trabajo para desarrolladores.

Si deseas controlar estrictamente las estaciones de trabajo que un desarrollador puede usar 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.

Restringe el acceso a la consola de Google Cloud

Google Cloud te permite restringir el acceso a la consola de Google Cloud según los atributos de nivel de acceso, como la membresía del grupo, los rangos de direcciones IP de confianza y la verificación del dispositivo. Algunos atributos requieren una suscripción adicional a Chrome Enterprise Premium.

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

Carpeta

fldr-environment

environment es una descripción de los recursos a nivel de carpetas dentro de la organización de 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 corta del campo de entorno (uno de b, c, p, n, d o net). Los proyectos host de la VPC compartida usan el environmentcode del entorno asociado. Los proyectos para los recursos de herramientas de redes compartidos entre entornos, como el proyecto interconnect, usan el código de entorno net.
• description es información adicional sobre el proyecto. Puedes usar abreviaturas cortas legibles por humanos.
• randomid es un sufijo aleatorio para evitar colisiones de nombres de recursos que deben ser únicos a nivel global y mitigar los atacantes que adivinen nombres de recursos. El plano agrega de forma automática un identificador alfanumérico aleatorio de cuatro caracteres.

Por ejemplo: prj-c-logging-a1b2

Red de VPC

vpc-environmentcode-vpctype-vpcconfig

• environmentcode es una forma corta del campo de entorno (uno de b, c, p, n, d o net).
• vpctype es uno de shared, float o peer.
• vpcconfig es base o restricted para indicar si la red está diseñada para usarse con los Controles del servicio de VPC o no.

Por ejemplo: vpc-p-shared-base

Subred

sn-environmentcode-vpctype-vpcconfig-region{-description}

• environmentcode es una forma corta del campo de entorno (uno de b, c, p, n, d o net).
• vpctype es uno de shared, float o peer.
• vpcconfig es base o restricted para indicar si la red está diseñada para usarse con los Controles del servicio de VPC o no.
• region es cualquier región de Google Cloud válida en la que se encuentra el recurso. Recomendamos quitar guiones y usar un formato abreviado de algunas regiones y direcciones para evitar alcanzar los límites de caracteres. Por ejemplo, au (Australia), na (América del Norte), sa (América del Sur), eu (Europa) y se (sureste) o ne (noreste).
• description es información adicional sobre la subred. Puedes usar abreviaturas cortas legibles por humanos.

Por ejemplo: sn-p-shared-restricted-uswest1

Políticas de firewall

fw-firewalltype-scope-environmentcode{-description}

• firewalltype es hierarchical o network.
• scope es global o la región de Google Cloud en la que se encuentra el recurso. Recomendamos quitar guiones y usar un formulario abreviado de algunas regiones y direcciones para evitar alcanzar los límites de caracteres. Por ejemplo, au (Australia), na (América del Norte), sa (América del Sur), eu (Europa) y se (sureste) o ne (noreste).
• environmentcode es una forma corta del campo de entorno (uno de b, c, p, n, d o net) que es propietario del recurso de la política.
• description es información adicional sobre la política de firewall jerárquica. Puedes usar abreviaturas cortas legibles por humanos.

Por ejemplo:

fw-hierarchical-global-c-01

fw-network-uswest1-p-shared-base

Cloud Router

cr-environmentcode-vpctype-vpcconfig-region{-description}

• environmentcode es una forma corta del campo de entorno (uno de b, c, p, n, d o net).
• vpctype es uno de shared, float o peer.
• vpcconfig es base o restricted para indicar si la red está diseñada para usarse con los Controles del servicio de VPC o no.
• region es cualquier región de Google Cloud válida en la que se encuentra el recurso. Recomendamos quitar guiones y usar un formulario abreviado de algunas regiones y direcciones para evitar alcanzar los límites de caracteres. Por ejemplo, au (Australia), na (América del Norte), sa (América del Sur), eu (Europa) y se (sureste) o ne (noreste).
• description es información adicional sobre el Cloud Router. Puedes usar abreviaturas cortas legibles por humanos.

Por ejemplo: cr-p-shared-base-useast1-cr1

Conexión de Cloud Interconnect

ic-dc-colo

• dc es el nombre de tu centro de datos al que está conectada una interconexión de Cloud Interconnect.
• colo es el nombre de la instalación de colocación con la que intercambia el tráfico la interconexión de Cloud Interconnect del centro de datos local.

Por ejemplo: ic-mydatacenter-lgazone1

Adjunto de VLAN de Cloud Interconnect

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

• dc es el nombre de tu centro de datos al que está conectada una interconexión de Cloud Interconnect.
• colo es el nombre de la instalación de colocación con la que intercambia el tráfico la interconexión de Cloud Interconnect del centro de datos local.
• environmentcode es una forma corta del campo de entorno (uno de b, c, p, n, d o net).
• vpctype es uno de shared, float o peer.
• vpcconfig es base o restricted para indicar si la red está diseñada para usarse con los Controles del servicio de VPC o no.
• region es cualquier región de Google Cloud válida en la que se encuentra el recurso. Recomendamos quitar guiones y usar un formulario abreviado de algunas regiones y direcciones para evitar alcanzar los límites de caracteres. Por ejemplo, au (Australia), na (América del Norte), sa (América del Sur), eu (Europa) y se (sureste) o ne (noreste).
• description es información adicional sobre la VLAN. Puedes usar abreviaturas cortas legibles por humanos.

Por ejemplo: vl-mydatacenter-lgazone1-p-shared-base-useast1-cr1

Grupo

grp-gcp-description@example.com

En el ejemplo anterior, description es información adicional sobre el grupo. Puedes usar abreviaturas cortas legibles por humanos.

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

Rol personalizado

rl-description

En el ejemplo anterior, description es información adicional sobre el rol. Puedes usar abreviaturas cortas legibles por humanos.

Por ejemplo: rl-customcomputeadmin

Cuenta de servicio

sa-description@projectid.iam.gserviceaccount.com

Aquí:

• description es información adicional sobre la cuenta de servicio. Puedes usar abreviaturas cortas legibles por humanos.
• projectid es el identificador de proyecto único a nivel global.

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

Bucket de almacenamiento

bkt-projectid-description

Aquí:

• projectid es el identificador de proyecto único a nivel global.
• description es información adicional sobre el bucket de almacenamiento. Puedes usar abreviaturas cortas legibles por humanos.

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

Organización: El plano usa una sola organización como nodo raíz para todos los recursos.

Decide una jerarquía de recursos para la zona de destino de Google Cloud presenta situaciones en las que es posible que prefieras varias organizaciones, como las siguientes:

• Tu organización incluye subempresas que podrían venderse en el futuro o que se ejecutan como entidades completamente separadas.
• Deseas experimentar en un entorno de zona de pruebas sin conectividad a tu organización existente.

Estructura de carpetas: El plano tiene una estructura de carpetas simple, con cargas de trabajo divididas en carpetas production, non-production y development en la capa superior.

Decide una jerarquía de recursos para la zona de destino de Google Cloud presenta otros enfoques para estructurar carpetas según la forma en la que desees administrar los recursos y heredar políticas, como las que se describen a continuación:

• Carpetas basadas en entornos de aplicaciones
• Carpetas basadas en entidades regionales o subsidiarias
• Carpetas basadas en el framework de responsabilidad

Políticas de la organización: El plano aplica todas las restricciones de la política de la organización en el nodo de la organización.

Es posible que tengas diferentes políticas de seguridad o formas de trabajar para diferentes partes del negocio. En esta situación, aplica las restricciones de la política de la organización en un nodo inferior de la jerarquía de recursos. Revisa la lista completa de restricciones de las políticas de la organización que te ayudan a cumplir con tus requisitos.

Herramientas de canalización de implementación: el plano usa Cloud Build para ejecutar la canalización de automatización.

Es posible que prefieras otros productos para tu canalización 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 el repositorio privado de Git administrado.

Usa el sistema de control de versión que prefieras para administrar repositorios de código, como GitLab, GitHub o Bitbucket.

Si usas 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 identidad: el plano supone un Active Directory local y envía las identidades a Cloud Identity mediante Google Cloud Directory Sync.

Si ya usas Google Workspace, puedes usar las identidades de Google que ya están administradas en Google Workspace.

Si no tienes un proveedor de identidad existente, puedes crear y administrar las identidades de los usuarios directamente en Cloud Identity.

Si tienes un proveedor de identidad existente, como Okta, Ping o Azure Entra ID, debes hacer lo siguiente podría administrar las cuentas de usuario en tu proveedor de identidad existente y sincronizarse con Cloud Identity.

Si tienes requisitos de soberanía de los datos o cumplimiento que te impiden usar Cloud Identity y no necesitas identidades de usuario de Google administradas para otros servicios de Google, como Google Ads o Google Marketing Platform, entonces es posible que prefieras la federación de identidades de personal. En esta situación, ten en cuenta las limitaciones de los servicios compatibles.

Varias regiones: el plano implementa recursos regionales en dos regiones diferentes de Google Cloud para ayudar a habilitar el diseño de carga de trabajo con requisitos de alta disponibilidad y recuperación ante desastres.

Si tienes usuarios finales en más ubicaciones geográficas, puedes configurar más regiones de Google Cloud para crear recursos más cercanos al usuario final con menos latencia.

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

Asignación de direcciones IP: El plano proporciona un conjunto de rangos de direcciones IP.

Es posible que debas cambiar los rangos específicos de direcciones IP que se usan en función de la disponibilidad de la dirección IP en tu entorno híbrido existente. Si modificas los rangos de direcciones IP, usa el plano como guía para la cantidad y el tamaño de los rangos requeridos y revisa los rangos de direcciones IP válidos para Google Cloud.

Herramientas de redes híbridas: El plano usa la interconexión dedicada en varios sitios físicos y regiones de Google Cloud para obtener un ancho de banda y una disponibilidad máximos.

En función de los requisitos de costo, ancho de banda y confiabilidad, puedes configurar Interconexión de socio o Cloud VPN en su lugar.

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

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

Perímetro de los Controles del servicio de VPC: El plano recomienda un solo perímetro que incluye todos los proyectos de servicio asociados con una red de VPC restringida. Los proyectos asociados con una red de VPC base no se incluyen en el perímetro.

Es posible que tengas un caso de uso que requiera varios perímetros para una organización o que decidas no usar los Controles del servicio de VPC.

Para obtener información, consulta cómo decidir cómo mitigar el robo de datos a través de las APIs de Google.

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

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

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

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

Si tienes un solo equipo responsable de administrar y auditar las claves de encriptación en toda la organización, es posible que prefieras usar un solo proyecto para administrar el acceso a las claves. Un enfoque centralizado puede ayudar a cumplir con los requisitos de cumplimiento, como los custodias de la clave PCI.

Si permites que los equipos de carga de trabajo administren sus propias claves, no puedes usar un proyecto centralizado para administrar el acceso a las claves y, en su lugar, permitir que los equipos usen sus propias instancias de Cloud KMS en proyectos de carga de trabajo.

Receptores de registros agregados: El plano configura un conjunto de receptores de registros en el nodo de la organización para que un equipo de seguridad central pueda revisar los registros de auditoría en toda la organización.

Es posible que tengas diferentes equipos responsables de auditar diferentes partes del negocio, y estos equipos puedan requerir registros diferentes para realizar sus trabajos. En esta situación, debes diseñar varios receptores agregados en las carpetas y los proyectos adecuados, y crear filtros para que cada equipo reciba solo los registros necesarios o diseñar vistas de registro para el control de acceso detallado a un bucket de registros común.

Nivel de detalle de las canalizaciones de infraestructura: El plano usa un modelo en el que cada unidad de negocios tiene una canalización de infraestructura independiente para administrar sus proyectos de carga de trabajo.

Es posible que prefieras una sola canalización de infraestructura administrada por un equipo central si tienes un equipo central que es responsable de implementar todos los proyectos y la infraestructura. Este equipo central puede aceptar solicitudes de extracción de los equipos de cargas de trabajo para que las revisen y aprueben antes de la creación del proyecto, o pueden crear la solicitud de extracción en respuesta a un sistema con tickets.

Es posible que prefieras canalizaciones más detalladas si los equipos de cargas de trabajo individuales tienen la capacidad de personalizar sus propias canalizaciones y deseas diseñar cuentas de servicio con privilegios más detalladas para las canalizaciones.

Exportaciones de SIEM: El plano administra todos los resultados de seguridad en Security Command Center.

Decide si exportarás los resultados de seguridad de Security Command Center a herramientas como Google Security Operations o tu SIEM existente, o si los equipos usarán la consola para ver y administrar los resultados de seguridad. Puedes configurar varias exportaciones con filtros únicos para diferentes equipos con diferentes permisos y responsabilidades.

Búsquedas de DNS para servicios de Google Cloud desde entornos locales: El plano configura un extremo único de Private Service Connect para cada VPC compartida, que puede ayudar a habilitar diseños con varios perímetros de Controles del servicio de VPC.

Es posible que no necesites enrutar desde un entorno local a extremos de Private Service Connect en este nivel de detalle si no necesitas varios perímetros de Control del servicio de VPC.

En lugar de asignar hosts locales a los extremos de Private Service Connect por entorno, puedes simplificar este diseño para usar un único extremo de Private Service Connect con el paquete de API adecuado o usar los extremos genéricos para private.googleapis.com y restricted.googleapis.com.