Prácticas recomendadas para operaciones

Last reviewed 2023-12-20 UTC

En esta sección, se presentan las operaciones que debes tener en cuenta cuando implementas y operas cargas de trabajo adicionales en tu entorno de Google Cloud. Esta sección no tiene como objetivo ser exhaustiva en todas las operaciones de tu entorno de nube, pero presenta decisiones relacionadas con las recomendaciones y los recursos de arquitectura que implementa el plano.

Actualiza los recursos de la base

Aunque el plano proporciona un punto de partida bien definido para el entorno de base, los requisitos de la base pueden crecer con el tiempo. Después de la implementación inicial, puedes ajustar la configuración o compilar nuevos servicios compartidos para que las consuman todas las cargas de trabajo.

Para modificar los recursos 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 atributos para proyectos de carga de trabajo nuevos

Cuando creas proyectos nuevos a través del módulo de fábrica del proyecto de la canalización de automatización, debes configurar varios atributos. Tu proceso de diseño y creación de proyectos para cargas de trabajo nuevas debe incluir las siguientes decisiones:

Qué APIs de Google Cloud habilitar
Qué VPC compartida usar o si deseas 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
La carpeta en la que se implementa el proyecto
Qué cuenta de facturación usar
Si agregar el proyecto a un perímetro de Controles del servicio de VPC
Si se configura un presupuesto y un límite de alertas de facturación para el proyecto

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

Administra permisos a gran escala

Cuando implementes proyectos de carga 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 permisos 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 en el plano suponen que tienes un equipo responsable de administrar los recursos de red y los equipos separados responsables de implementar recursos de infraestructura de 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 red.

Planifica cómo los equipos trabajarán juntos para coordinar los cambios en los recursos de red centralizados que se necesitan para implementar aplicaciones. Por ejemplo, puedes diseñar un proceso en el que un equipo de carga de trabajo solicita 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 a Workload Team.

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 el 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.

Otorga excepciones a las políticas de la organización

El plano 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 los casos, pero puedes tener casos de uso legítimos que requieran excepciones limitadas a las políticas de la organización que aplicas de manera amplia.

Por ejemplo, el plano 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 de Google Cloud y no puede usar la federación de Workload Identity. En esta situación, puedes decidir permitir una excepción a la política, siempre que se apliquen controles de compensación adicionales, como las prácticas recomendadas para administrar 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 otorgas 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 estrecha 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.

Protege tus recursos con los Controles del servicio de VPC

El plano ayuda a preparar tu entorno para los Controles del servicio de VPC mediante la separación de las redes base y restringidas. Sin embargo, de forma predeterminada, el código de Terraform no habilita los Controles del servicio de VPC porque esta habilitación puede ser un proceso disruptivo.

Un perímetro rechaza el acceso a los servicios restringidos de Google Cloud desde el tráfico que se origina fuera del perímetro, que incluye la consola, las estaciones de trabajo para desarrolladores y la canalización base 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 robo de datos entre tu organización de Google Cloud y fuentes externas. El perímetro no está diseñado para reemplazar o duplicar las políticas de permisos 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 el tráfico de servicio de forma detallada dentro de la organización de Google Cloud, te recomendamos que definas con claridad las amenazas que se abordan en una estructura de perímetro más compleja y las rutas de acceso entre ellos necesarias para las operaciones previstas.

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.
Si los servicios de Google Cloud necesarios admiten los Controles del servicio de VPC.
Cómo configurar el acceso de emergencia para modificar el perímetro en caso de que interrumpa las 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.

Una vez habilitado el perímetro, 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 distinta

Te recomendamos que nunca implementes cambios en la producción sin pruebas. Para los recursos de carga de trabajo, este enfoque facilita este entorno mediante entornos de desarrollo, no producción y producción. Sin embargo, algunos recursos en 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.

Para situaciones que requieren acceso remoto, te recomendamos que administres el acceso de los usuarios mediante el Acceso al SO cuando sea posible. Este enfoque usa los servicios administrados de Google Cloud para aplicar el control de acceso, la administración del ciclo de vida de la cuenta, la verificación en dos 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 almacenar las credenciales de forma segura fuera de Google Cloud.

En cualquier situación, un usuario con acceso SSH o RDP a una VM puede ser un riesgo de elevación de privilegios, por lo que debes diseñar tu modelo de acceso con esto en mente. El usuario puede ejecutar el 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 querías que el usuario opere con los privilegios de la cuenta de servicio de forma deliberada.

Mitiga los gastos excesivos mediante la planificación de alertas de presupuesto

El plano implementa las prácticas recomendadas que se presentan en Framework de la arquitectura de Google Cloud: Optimización de costos para administrar los costos, incluidas las siguientes:

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

Es su responsabilidad planificar los presupuestos y configurar alertas de facturación. El plano crea alertas de presupuesto para proyectos de carga de trabajo cuando el gasto previsto está por llegar al 120% del presupuesto. Este enfoque permite que un equipo central identifique y mitigue incidentes de gastos significativos. 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 de presupuesto y alertas a los propietarios de cargas de trabajo que podrían establecer un límite de alertas más detallado para su supervisión diaria.

Si deseas obtener orientación para compilar capacidades de FinOps, incluido la previsión de presupuestos para cargas de trabajo, consulta Comienza a usar FinOps en Google Cloud.

Asigna costos entre centros de costos internos

La consola te permite ver tus informes de facturación para ver y prever el costo en varias dimensiones. Además de los informes precompilados, te recomendamos que exportes los datos de facturación a un conjunto de datos de BigQuery en el proyecto prj-c-billing-logs. Los registros de facturación exportados te permiten asignar costos a dimensiones personalizadas, como tus centros de costos internos, según los metadatos de las 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 Facturación de Cloud a BigQuery.

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

Transfiere resultados de los controles de detección a tu SIEM existente

Aunque los recursos 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 resultados si un solo equipo es responsable de supervisar la seguridad en todo el entorno, o puedes crear varias exportaciones filtradas con el conjunto de registros y resultados necesarios para varios equipos con diferentes responsabilidades.

Como alternativa, si el volumen y el costo de los registros son prohibitivos, puedes conservar los registros y los resultados de Google Cloud solo en Google Cloud para evitar la duplicación. En esta situación, asegúrate de que tus equipos existentes tengan el acceso y la capacitación adecuados para trabajar con registros y resultados directamente en Google 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 tu biblioteca de controles de forma continua

El plano comienza con un modelo de referencia de controles para detectar y prevenir amenazas. Te recomendamos que revises estos controles y agregues controles adicionales según tus requisitos. En la siguiente tabla, se resumen los mecanismos para aplicar las políticas de administración y cómo extenderlos según tus requisitos adicionales:

Controles de políticas que aplica el plano	Orientación para extender estos controles
Security Command Center detecta vulnerabilidades y amenazas de varias fuentes de seguridad.	Define módulos personalizados para las estadísticas del estado de la seguridad 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 de Google Cloud.	Aplica restricciones adicionales de la lista de restricciones disponibles prediseñadas o crea restricciones personalizadas.
La política de agente de políticas abiertas (OPA) valida el código en la canalización base para obtener configuraciones aceptables antes de la implementación.	Desarrolla restricciones adicionales según la guía de GoogleCloudPlatform/policy-library.
Las alertas sobre métricas basadas en registros y métricas de rendimiento configuran métricas basadas en registros para alertar sobre cambios en políticas de IAM y configuraciones de algunos recursos sensibles.	Diseña métricas adicionales basadas en registros y políticas de alertas 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 mediante las estadísticas del registro de seguridad como referencia.
Una solución personalizada para responder a los cambios de los elementos crea hallazgos de Security Command Center y puede automatizar las acciones de solución.	Crea feeds de Cloud Asset Inventory adicionales para supervisar los cambios en tipos de recursos específicos y escribir Cloud Functions adicionales con lógica personalizada para responder a los incumplimientos de políticas.

Estos controles pueden evolucionar a medida que cambian tus requisitos y madurez en Google Cloud.

Administra 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 proporcionarte control 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 central. 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 las claves CMEK de una lista de proyectos de confianza estén 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 secretos de producción de forma automática 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 secretos de forma centralizada. Este enfoque permite que un equipo central audite y administre 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 la muestra de código de Terraform según sea necesario para que se ajuste a tu modelo operativo.

Planifica el acceso de emergencia a las cuentas con muchos privilegios

Aunque recomendamos que los cambios en los recursos de la base se administran a través de una IaC controlada por la versión que implementa la canalización de base, es posible que tengas situaciones de excepción o emergencia que requieran acceso con privilegios para modificar tu entorno directamente. Te recomendamos que planifiques cuentas de emergencia (a veces llamadas cuentas de firecall o de emergencia) que tengan acceso con muchos privilegios a tu entorno en caso de una emergencia o cuando se interrumpan los procesos de automatización.

En la siguiente tabla, se describen algunos ejemplos de cuentas de emergencia.

Propósito 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 de base	Acceso de emergencia para modificar los recursos en tu proyecto de CICD en Google Cloud y en el repositorio de Git externo en caso de que se interrumpa la automatización de la canalización base.
Operaciones o SRE	Un equipo de operaciones o SRE necesita acceso con privilegios para responder a interrupciones o incidentes. Esto puede incluir tareas como reiniciar VMs o restablecer datos.

Tu mecanismo para permitir el acceso de emergencia depende de las herramientas y los procedimientos existentes que tengas, pero algunos mecanismos de ejemplo 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.
Aprovisionamiento previo de cuentas destinadas solo al uso del administrador. Por ejemplo, el desarrollador Dana podría tener una identidad dana@example.com para 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.

Sin importar el mecanismo que uses, considera cómo abordas de forma operativa las siguientes preguntas:

¿Cómo se diseña el alcance y el nivel de detalle 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 previene el mecanismo de abuso? ¿Requieren aprobaciones? Por ejemplo, puedes tener operaciones divididas en las que una persona contiene credenciales y otra persona contiene el token de MFA.
¿Cómo se audita y se alerta sobre el acceso de emergencia? Por ejemplo, puedes configurar un módulo personalizado de Event Threat Detection para crear un resultado de seguridad cuando se usa una cuenta de emergencia 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 el error humano y mejorar la seguridad.

Automatizar la corrección puede ser la mejor solución para los sistemas que requieren intervención regular. 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 buscan adoptar el enfoque de SRE de Google.

¿Qué sigue?

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