Prácticas recomendadas para las operaciones

Last reviewed 2025-05-15 UTC

En esta sección, se presentan las operaciones que debes tener en cuenta a medida que implementas y ejecutas cargas de trabajo adicionales en tu entorno de Google Cloud . Esta sección no pretende abarcar todas las operaciones de tu entorno de nube, sino que presenta decisiones relacionadas con las recomendaciones arquitectónicas y los recursos implementados por el blueprint.

Actualiza los recursos de la base

Si bien el blueprint proporciona un punto de partida bien definido para tu entorno de base, es posible que tus requisitos de base aumenten con el tiempo. Después de la implementación inicial, es posible que debas ajustar la configuración o crear nuevos servicios compartidos para que los consuman todas las cargas de trabajo.

Para modificar los recursos de base, te recomendamos que realices todos los cambios a través de la canalización de base. Revisa la estrategia de ramificación para obtener una introducción al flujo de escritura del código, su combinación y la activación de las canalizaciones de implementación.

Decide los atributos para los proyectos de cargas de trabajo nuevos

Cuando crees proyectos nuevos a través del módulo de fábrica de proyectos de la canalización de automatización, deberás configurar varios atributos. Tu proceso para diseñar y crear proyectos para cargas de trabajo nuevas debe incluir decisiones sobre lo siguiente:

Qué APIs de Google Cloud habilitar
Qué VPC compartida usar o si se debe crear una red de VPC nueva
Qué roles de IAM crear para la project-service-account inicial que crea la canalización
Qué etiquetas de proyecto aplicar
Carpeta en la que se implementa el proyecto
Qué cuenta de facturación usar
Indica si se debe agregar el proyecto a un perímetro de Controles del servicio de VPC.
Indica si se debe configurar un presupuesto y un límite de alerta de facturación para el proyecto.

Para obtener una referencia completa de los atributos configurables de cada proyecto, consulta las variables de entrada para la fábrica de proyectos en la canalización de automatización.

Administra permisos a gran escala

Cuando implementes proyectos de cargas de trabajo sobre tu base, debes considerar cómo otorgarás acceso a los desarrolladores y consumidores previstos de esos proyectos. Recomendamos que agregues usuarios a un grupo administrado por tu proveedor de identidad existente, que sincronices los grupos con Cloud Identity y, luego, que apliques roles de IAM a los grupos. Siempre ten en cuenta el principio de privilegio mínimo.

También te recomendamos que uses el recomendador de IAM para identificar las políticas de permiso que otorgan roles con privilegios excesivos. Diseña un proceso para revisar las recomendaciones de forma periódica o aplicarlas de forma automática en las canalizaciones de implementación.

Coordina los cambios entre el equipo de redes y el equipo de aplicaciones

Las topologías de red que se implementan con el blueprint suponen que tienes un equipo responsable de administrar los recursos de red y equipos independientes responsables de implementar los recursos de infraestructura de la carga de trabajo. A medida que los equipos de carga de trabajo implementan la infraestructura, deben crear reglas de firewall para permitir las rutas de acceso previstas entre los componentes de su carga de trabajo, pero no tienen permiso para modificar las políticas de firewall de la red.

Planifica cómo trabajarán los equipos en conjunto para coordinar los cambios en los recursos de redes centralizados que se necesitan para implementar aplicaciones. Por ejemplo, puedes diseñar un proceso en el que un equipo de carga de trabajo solicite etiquetas para sus aplicaciones. Luego, el equipo de redes crea las etiquetas y agrega reglas a la política de firewall de red que permite que el tráfico fluya entre los recursos con las etiquetas y delega los roles de IAM para usar las etiquetas al equipo de carga de trabajo.

Optimiza tu entorno con la cartera de Active Assist

Además del recomendador de IAM, Google Cloud proporciona la cartera de servicios de Active Assist para hacer recomendaciones sobre cómo optimizar tu entorno. Por ejemplo, las estadísticas de firewall o el recomendador de proyectos sin actividad proporcionan recomendaciones prácticas que pueden ayudarte a reforzar tu postura de seguridad.

Diseña un proceso para revisar las recomendaciones de forma periódica o aplicarlas de forma automática en las canalizaciones de implementación. Decide qué recomendaciones debe administrar un equipo central y cuáles deben ser responsabilidades de los propietarios de las cargas de trabajo y aplica los roles de IAM para acceder a las recomendaciones según corresponda.

Cómo otorgar excepciones a las políticas de la organización

El plan aplica un conjunto de restricciones de políticas de la organización que se recomiendan para la mayoría de los clientes en la mayoría de las situaciones, pero es posible que tengas casos de uso legítimos que requieran excepciones limitadas a las políticas de la organización que aplicas de forma general.

Por ejemplo, el blueprint aplica la restricción iam.disableServiceAccountKeyCreation. Esta restricción es un control de seguridad importante porque una clave de cuenta de servicio filtrada puede tener un impacto negativo significativo y la mayoría de las situaciones deben usar alternativas más seguras para las claves de cuenta de servicio para autenticarse. Sin embargo, puede haber casos de uso que solo puedan autenticarse con una clave de cuenta de servicio, como un servidor local que requiere acceso a los servicios deGoogle Cloud y no puede usar la federación de Workload Identity. En este caso, puedes decidir permitir una excepción a la política, siempre y cuando se apliquen controles compensatorios adicionales, como las prácticas recomendadas para administrar las claves de cuentas de servicio.

Por lo tanto, debes diseñar un proceso para que las cargas de trabajo soliciten una excepción a las políticas y debes asegurarte de que los encargados de tomar decisiones que son responsables de otorgar excepciones tengan el conocimiento técnico para validar el caso de uso y consultar sobre si se deben implementar controles adicionales para compensar. Cuando otorgues una excepción a una carga de trabajo, modifica la restricción de la política de la organización de la manera más limitada posible. También puedes agregar restricciones de forma condicional a una política de la organización si defines una etiqueta que otorgue una excepción o aplicación para la política y, luego, aplicas la etiqueta a proyectos y carpetas.

Protección de tus recursos con los Controles del servicio de VPC

El plano te ayuda a preparar tu entorno para los Controles del servicio de VPC aplicando configuraciones previas, como la VIP restringida. Sin embargo, el blueprint inicialmente implementa los Controles del servicio de VPC solo en modo de ejecución de prueba, ya que el cambio al modo aplicado puede ser un proceso disruptivo que requiere una planificación exclusiva para tu organización.

Un perímetro rechaza el acceso a los servicios Google Cloud restringidos del tráfico que se origina fuera del perímetro, lo que incluye la consola, las estaciones de trabajo de los desarrolladores y la canalización de la infraestructura que se usa para implementar recursos. Si usas los Controles del servicio de VPC, debes diseñar excepciones al perímetro que permitan las rutas de acceso que deseas.

Un perímetro de Controles del servicio de VPC está diseñado para los controles de filtración entre tu organización Google Cloud y las fuentes externas. El perímetro no está diseñado para reemplazar ni duplicar las políticas de permiso para el control de acceso detallado a proyectos o recursos individuales. Cuando diseñas y creas un perímetro, recomendamos usar un perímetro unificado común para reducir la sobrecarga de administración.

Si debes diseñar varios perímetros para controlar de forma detallada el tráfico de servicios dentro de tu organización, te recomendamos que definas claramente las amenazas que aborda una estructura de perímetro más compleja y las rutas de acceso entre los perímetros que se necesitan para las operaciones previstas. Google Cloud

Para adoptar los Controles del servicio de VPC, evalúa lo siguiente:

Cuáles de tus casos de uso requieren Controles del servicio de VPC.
Indica si los servicios Google Cloud requeridos admiten los Controles del servicio de VPC.
Cómo configurar el acceso de emergencia para modificar el perímetro en caso de que interrumpa tus canalizaciones de automatización
Cómo usar las prácticas recomendadas para habilitar los Controles del servicio de VPC para diseñar e implementar tu perímetro

Después de cambiar el perímetro del modo de ejecución de prueba al modo aplicado, te recomendamos que diseñes un proceso para agregar de manera coherente proyectos nuevos al perímetro correcto y un proceso para diseñar excepciones cuando los desarrolladores tengan un caso de uso nuevo que tu configuración de perímetro actual rechace.

Prueba los cambios en toda la organización en una organización separada

Te recomendamos que nunca implementes cambios en la producción sin realizar pruebas. En el caso de los recursos de cargas de trabajo, este enfoque se facilita con entornos separados para el desarrollo, la no producción y la producción. Sin embargo, algunos recursos de la organización no tienen entornos separados para facilitar las pruebas.

Para cambios a nivel de la organización o de otro tipo que puedan afectar los entornos de producción, como la configuración entre el proveedor de identidad y Cloud Identity, considera crear una organización distinta para fines de prueba.

Controla el acceso remoto a las máquinas virtuales

Debido a que recomendamos que implementes una infraestructura inmutable a través de la canalización de base, la canalización de infraestructura y la canalización de aplicación, también recomendamos que solo otorgues acceso directo a una máquina virtual a los desarrolladores a través de SSH o RDP para casos de uso limitados o excepcionales.

En los casos que requieren acceso remoto, te recomendamos que administres el acceso de los usuarios con el Acceso a SO siempre que sea posible. Este enfoque utiliza servicios Google Cloud administrados para aplicar el control de acceso, la administración del ciclo de vida de la cuenta, la verificación en 2 pasos y el registro de auditoría. Como alternativa, si debes permitir el acceso a través de claves SSH en metadatos o credenciales de RDP, es tu responsabilidad administrar el ciclo de vida de las credenciales y almacenarlas de forma segura fuera de Google Cloud.

En cualquier situación, un usuario con acceso SSH o RDP a una VM puede representar un riesgo de escalación de privilegios, por lo que debes diseñar tu modelo de acceso teniendo esto en cuenta. El usuario puede ejecutar código en esa VM con los privilegios de la cuenta de servicio asociada o consultar el servidor de metadatos para ver el token de acceso que se usa para autenticar las solicitudes a la API. Este acceso puede ser una elevación de privilegios si no tenías la intención deliberada de que el usuario operara con los privilegios de la cuenta de servicio.

Cómo mitigar el exceso de inversión planificando alertas de presupuesto

El blueprint implementa las prácticas recomendadas que se presentan en el Google Cloud Well-Architected Framework: Optimización de costos para administrar los costos, lo que incluye lo siguiente:

Usa una sola cuenta de facturación en todos los proyectos de la base de la empresa.
Asigna a cada proyecto una etiqueta de metadatos billingcode que se use para asignar el costo entre los centros de costos.
Configura presupuestos y límites de alertas.

Es tu responsabilidad planificar los presupuestos y configurar las alertas de facturación. El plan crea alertas de presupuesto para los proyectos de cargas de trabajo cuando se prevé que la inversión alcanzará el 120% del presupuesto. Este enfoque permite que un equipo central identifique y mitigue los incidentes de exceso de inversión significativo. Los aumentos significativos no esperados en el gasto sin una causa clara pueden ser un indicador de un incidente de seguridad y deben investigarse desde las perspectivas del control de costos y la seguridad.

Según tu caso de uso, puedes establecer un presupuesto basado en el costo de una carpeta de entorno completa o de todos los proyectos relacionados con un centro de costos determinado, en lugar de establecer presupuestos detallados para cada proyecto. También te recomendamos que delegues la configuración del presupuesto y las alertas a los propietarios de las cargas de trabajo, quienes pueden establecer umbrales de alerta más detallados para su supervisión diaria.

Si necesitas orientación para optimizar los costos, consulta Optimiza los costos con FinOps Hub.

Asigna costos entre centros de costos internos

La consola te permite ver tus informes de facturación para ver y prever los costos en múltiples dimensiones. Además de los informes prediseñados, te recomendamos que exportes los datos de facturación a un conjunto de datos de BigQuery en el proyecto prj-c-billing-export. Los registros de facturación exportados te permiten asignar costos a dimensiones personalizadas, como tus centros de costos internos, en función de los metadatos de etiquetas de proyecto, como billingcode.

La siguiente consulta en SQL es una consulta de muestra para comprender los costos de todos los proyectos agrupados por la etiqueta billingcode del proyecto.

#standardSQL
SELECT
   (SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
   service.description AS description,
   SUM(cost) AS charges,
   SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC

Para configurar esta exportación, consulta Exporta datos de la Facturación de Cloud a BigQuery.

Si necesitas una contabilidad interna o una devolución de cargo entre centros de costos, es tu responsabilidad incorporar los datos que se obtienen de esta consulta en tus procesos internos.

Ingiere los resultados de los controles de detección en tu SIEM existente

Si bien los recursos de la base te ayudan a configurar destinos agregados para los registros de auditoría y los resultados de seguridad, es tu responsabilidad decidir cómo consumir y usar estos indicadores.

Si tienes un requisito para agregar registros en todos los entornos locales y en la nube a una SIEM existente, decide cómo transferir registros desde el proyecto prj-c-logging y resultados de Security Command Center en tus herramientas y procesos existentes. Puedes crear una sola exportación para todos los registros y hallazgos si un solo equipo es responsable de supervisar la seguridad en todo tu entorno, o bien puedes crear varias exportaciones filtradas según el conjunto de registros y hallazgos necesarios para varios equipos con diferentes responsabilidades.

Como alternativa, si el volumen y el costo de los registros son prohibitivos, puedes evitar la duplicación si conservas los registros y los hallazgos de Google Cloud solo enGoogle Cloud. En este caso, asegúrate de que tus equipos existentes tengan el acceso y la capacitación adecuados para trabajar con los registros y los hallazgos directamente enGoogle Cloud.

En el caso de los registros de auditoría, diseña vistas de registro para otorgar acceso a un subconjunto de registros en tu bucket de registros centralizado a equipos individuales, en lugar de duplicar los registros a varios buckets que aumentan costo de almacenamiento de los registros.
En el caso de los resultados de seguridad, otorga roles a nivel de carpeta y de proyecto para Security Command Center para permitir que los equipos vean y administren los resultados de seguridad solo para los proyectos de los que son responsables, directamente en la consola.

Desarrolla continuamente tu biblioteca de controles

El plano comienza con una base de controles para detectar y prevenir amenazas. Te recomendamos que revises estos controles y agregues otros según tus requisitos. En la siguiente tabla, se resumen los mecanismos para aplicar políticas de gobierno y cómo extenderlas para tus requisitos adicionales:

Controles de políticas que aplica el blueprint	Orientación para extender estos controles
Security Command Center detecta vulnerabilidades y amenazas de varias fuentes de seguridad.	Define módulos personalizados para Security Health Analytics y módulos personalizados para Event Threat Detection.
El servicio de políticas de la organización aplica un conjunto recomendado de restricciones de políticas de la organización en los servicios deGoogle Cloud .	Aplica restricciones adicionales de la lista prediseñada de restricciones disponibles o crea restricciones personalizadas.
La política de Open Policy Agent (OPA) valida el código en la canalización de la base para detectar configuraciones aceptables antes de la implementación.	Desarrolla restricciones adicionales según la guía que se encuentra en GoogleCloudPlatform/policy-library.
Alerting on log-based metrics and performance metrics configura métricas basadas en registros para generar alertas sobre cambios en las políticas de IAM y las configuraciones de algunos recursos sensibles.	Diseña métricas basadas en registros y políticas de alertas adicionales para los eventos de registro que esperas que no ocurran en tu entorno.
Una solución personalizada para el análisis automático de registros consulta con regularidad los registros de actividad sospechosa y crea hallazgos de Security Command Center.	Escribe consultas adicionales para crear los resultados para los eventos de seguridad que deseas supervisar usando las estadísticas del registro de seguridad como referencia.
Una solución personalizada para responder a los cambios de los recursos crea hallazgos de Security Command Center y puede automatizar las acciones de corrección.	Crea feeds de Cloud Asset Inventory adicionales para supervisar los cambios en tipos de recursos específicos y escribir funciones de Cloud Run adicionales con lógica personalizada para responder a los incumplimientos de políticas.

Estos controles pueden evolucionar a medida que cambien tus requisitos y tu madurez enGoogle Cloud .

Administra las claves de encriptación con Cloud Key Management Service

Google Cloud proporciona encriptación en reposo predeterminada para todo el contenido del cliente, pero también proporciona Cloud Key Management Service (Cloud KMS) para brindarte control adicional sobre las claves de encriptación para datos en reposo. Te recomendamos que evalúes si la encriptación predeterminada es suficiente o si tienes un requisito de cumplimiento que debes usar Cloud KMS para administrar las claves por tu cuenta. Para obtener más información, consulta cómo decidir cómo cumplir con los requisitos de cumplimiento para la encriptación en reposo.

El plano proporciona un proyecto prj-c-kms en la carpeta común y un proyecto prj-{env}-kms en cada carpeta de entorno para administrar las claves de encriptación de forma centralizada. Este enfoque permite que un equipo central audite y administre las claves de encriptación que usan los recursos en los proyectos de carga de trabajo para cumplir con los requisitos reglamentarios y de cumplimiento.

Según tu modelo operativo, es posible que prefieras una sola instancia de proyecto centralizada de Cloud KMS bajo el control de un solo equipo, o bien que administres las claves de encriptación por separado en cada entorno o que prefieras varias instancias distribuidas para que la responsabilidad de las claves de encriptación se pueda delegar a los equipos adecuados. Modifica la muestra de código de Terraform según sea necesario para que se ajuste a tu modelo operativo.

De manera opcional, puedes aplicar políticas de organización de claves de encriptación administradas por el cliente (CMEK) para aplicar que ciertos tipos de recursos siempre requieran una clave CMEK y que solo se puedan usar claves CMEK de una lista de proyectos de confianza permitidos.

Almacena y audita las credenciales de la aplicación con Secret Manager

Te recomendamos que nunca confirmes secretos sensibles (como claves de API, contraseñas y certificados privados) en repositorios de código fuente. En su lugar, confirma el secreto en Secret Manager y otorga el rol de IAM de Administrador y descriptor de acceso a secretos al usuario o la cuenta de servicio que necesita acceder al secreto. Te recomendamos que otorgues el rol de IAM a un secreto individual, no a todos los secretos del proyecto.

Cuando sea posible, debes generar automáticamente secretos de producción dentro de las canalizaciones de CI/CD y mantenerlos inaccesibles para los usuarios humanos, excepto en situaciones de emergencia. En esta situación, asegúrate de no otorgar roles de IAM para ver estos secretos a ningún usuario o grupo.

El plano proporciona un solo proyecto prj-c-secrets en la carpeta común y un proyecto prj-{env}-secrets en cada carpeta de entorno para administrar los secretos de forma centralizada. Este enfoque permite que un equipo central audite y administre los secretos que usan las aplicaciones para cumplir con los requisitos reglamentarios y de cumplimiento.

Según tu modelo operativo, es posible que prefieras una sola instancia centralizada de Secret Manager bajo el control de un solo equipo, o que prefieras administrar los secretos por separado en cada entorno, o que prefieras varias instancias distribuidas de Secret Manager para que cada equipo de carga de trabajo pueda administrar sus propios secretos. Modifica el ejemplo de código de Terraform según sea necesario para que se ajuste a tu modelo operativo.

Planifica el acceso de emergencia a cuentas con privilegios elevados

Si bien recomendamos que los cambios en los recursos de la base se administren a través de IaC con control de versiones que se implementa con la canalización de base, es posible que tengas situaciones excepcionales o de emergencia que requieran acceso privilegiado para modificar tu entorno directamente. Te recomendamos que planifiques cuentas de emergencia (a veces llamadas cuentas de llamada de emergencia o de emergencia) que tengan acceso altamente privilegiado a tu entorno en caso de emergencia o cuando los procesos de automatización fallen.

En la siguiente tabla, se describen algunos ejemplos de los propósitos de las cuentas de breakglass.

Propósito de la anulación de emergencia	Descripción
Administrador avanzado	Acceso de emergencia al rol de administrador avanzado que se usa con Cloud Identity para, por ejemplo, solucionar problemas relacionados con la federación de identidades o la autenticación de varios factores (MFA).
Administrador de la organización	Acceso de emergencia al rol de administrador de la organización, que luego puede otorgar acceso a cualquier otro rol de IAM en la organización.
Administrador de la canalización base	Acceso de emergencia para modificar los recursos en tu proyecto de CICD enGoogle Cloud y el repositorio de Git externo en caso de que se interrumpa la automatización de la canalización de la base.
Operaciones o SRE	Un equipo de operaciones o de SRE necesita acceso privilegiado para responder ante interrupciones o incidentes. Esto puede incluir tareas como reiniciar VMs o restablecer datos.

El mecanismo para permitir el acceso de emergencia depende de las herramientas y los procedimientos existentes que tengas implementados, pero algunos ejemplos de mecanismos incluyen los siguientes:

Usa las herramientas existentes para la administración de accesos con privilegios para agregar de forma temporal a un usuario a un grupo predefinido con roles de IAM con muchos privilegios o usa las credenciales de una cuenta con muchos privilegios.
Aprovisiona previamente cuentas destinadas solo al uso del administrador. Por ejemplo, la desarrolladora Dana podría tener una identidad dana@example.com para el uso diario y admin-dana@example.com para el acceso de emergencia.
Usa una aplicación como el acceso privilegiado justo a tiempo que permite a un desarrollador derivar a roles con más privilegios.

Independientemente del mecanismo que uses, considera cómo abordar operativamente las siguientes preguntas:

¿Cómo diseñas el alcance y la granularidad del acceso de emergencia? Por ejemplo, puedes diseñar un mecanismo de emergencia diferente para diferentes unidades de negocios para asegurarte de que no puedan interrumpirse entre sí.
¿Cómo evita el abuso tu mecanismo? ¿Necesitas aprobaciones? Por ejemplo, es posible que tengas operaciones divididas en las que una persona tiene las credenciales y otra tiene el token de MFA.
¿Cómo auditas y generas alertas sobre el acceso de emergencia? Por ejemplo, puedes configurar un módulo personalizado de Event Threat Detection para crear un hallazgo de seguridad cuando se use una cuenta de breakglass predefinida.
¿Cómo quitas el acceso de emergencia y reanudas las operaciones normales después de que finaliza el incidente?

Para las tareas comunes de elevación de privilegios y reversión de cambios, recomendamos diseñar flujos de trabajo automatizados en los que un usuario pueda realizar la operación sin requerir elevación de privilegios para su identidad de usuario. Este enfoque puede ayudar a reducir los errores humanos y mejorar la seguridad.

Para los sistemas que requieren intervención periódica, automatizar la corrección podría ser la mejor solución. Google recomienda a los clientes que adopten un enfoque automático para realizar todos los cambios de producción con automatización, proxies seguros o flujos de trabajo de emergencia auditados. Google proporciona los libros de SRE para los clientes que desean adoptar el enfoque de SRE de Google.

¿Qué sigue?

Lee Implementa el plano (siguiente documento de esta serie).