Implementa el plano

Last reviewed 2023-12-20 UTC

En esta sección, se describe el proceso que puedes usar para implementar el plano, sus convenciones de nombres y las alternativas a las recomendaciones del plano.

Revisión general

Para implementar tu propia base empresarial según las prácticas recomendadas y las recomendaciones de este plano, sigue las tareas de alto nivel que se resumen en esta sección. La implementación requiere una combinación de pasos de configuración que son requisitos previos, la implementación automatizada a través de terraform-example-foundation en GitHub y pasos adicionales que deben configurarse de forma manual después de que se complete la implementación inicial de la base.

Proceso Pasos

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:

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

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:

Controles administrativos adicionales para los clientes con cargas de trabajo sensibles

Google Cloud proporciona controles administrativos adicionales que pueden ayudarte con los requisitos de seguridad y cumplimiento. Sin embargo, algunos controles implican compensaciones adicionales de costo u operativas que podrían no ser adecuadas para cada cliente. Estos controles también requieren entradas personalizadas para tus requisitos específicos que no se pueden automatizar por completo en el plano con un valor predeterminado para todos los clientes.

En esta sección, se presentan los controles de seguridad que aplicas de forma centralizada a tu base. Esta sección no está diseñada para ser exhaustiva en todos los controles de seguridad que puedes aplicar a cargas de trabajo específicas. Para obtener más información sobre los productos y las soluciones de seguridad de Google, consulta el Centro de prácticas recomendadas para la seguridad de Google Cloud.

Evalúa si los siguientes controles son adecuados para tu base en función de los requisitos de cumplimiento, el apetito de riesgo y la sensibilidad de los datos.

Control Descripción

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 BeyondCorp Enterprise.

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.

Convenciones de nombres

Te recomendamos que tengas una convención de nombres estandarizada para tus recursos de Google Cloud. En la siguiente tabla, se describen las convenciones recomendadas para los nombres de recursos en el plano.

Recurso Convención de nombres

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

Alternativas a las recomendaciones predeterminadas

Es posible que las prácticas recomendadas del plano no funcionen para todos los clientes. Puedes personalizar cualquiera de las recomendaciones para cumplir con tus requisitos específicos. En la siguiente tabla, se presentan algunas de las variaciones comunes que puedes necesitar según tu pila tecnológica existente y las formas de trabajar.

Área de decisión Alternativas posibles

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.

Proyectos de alcance de Monitoring: El plano configura un solo proyecto de alcance de supervisión para cada entorno.

Puedes configurar proyectos de alcance más detallados que administran diferentes equipos, con alcance para el conjunto de proyectos que contienen las aplicaciones que administra cada equipo.

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 Chronicle 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.googlepais.com y restricted.googleapis.com.

¿Qué sigue?