Prácticas recomendadas de operaciones

En esta sección se describen las operaciones que debes tener en cuenta al implementar y operar cargas de trabajo adicionales en tu entorno de Google Cloud . El objetivo de esta sección no es enumerar todas las operaciones de tu entorno en la nube, sino presentar las decisiones relacionadas con las recomendaciones de arquitectura y los recursos desplegados por el blueprint.

Actualizar recursos de la base

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

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

Decidir los atributos de los nuevos proyectos de carga de trabajo

Cuando creas proyectos mediante el módulo de fábrica de proyectos de la automatización, debes configurar varios atributos. El proceso para diseñar y crear proyectos para nuevas cargas de trabajo debe incluir decisiones sobre lo siguiente:

• Qué APIs de Google Cloud habilitar
• Qué VPC compartida se va a usar o si se va a crear una red de VPC
• Qué roles de gestión de identidades y accesos se deben crear para el 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 quieres añadir el proyecto a un perímetro de Controles de Servicio de VPC
• Si quieres configurar un presupuesto y un umbral 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 de la fábrica de proyectos en la canalización de automatización.

Gestionar permisos a gran escala

Cuando despliegues proyectos de carga de trabajo sobre tu base, debes plantearte cómo vas a conceder acceso a los desarrolladores y consumidores previstos de esos proyectos. Te recomendamos que añadas usuarios a un grupo gestionado por tu proveedor de identidades, sincronices los grupos con Cloud Identity y, a continuación, apliques roles de gestión de identidades y accesos a los grupos. Ten siempre presente el principio de mínimos accesos.

También te recomendamos que uses Recomendador de IAM para identificar las políticas de permiso que conceden roles con demasiados privilegios. Diseña un proceso para revisar periódicamente las recomendaciones o aplicarlas automáticamente en tus flujos de implementación.

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

Las topologías de red que se implementan con el blueprint presuponen que tienes un equipo responsable de gestionar los recursos de red y otros equipos responsables de implementar los recursos de infraestructura de las cargas de trabajo. Cuando los equipos de carga de trabajo implementan la infraestructura, deben crear reglas de cortafuegos 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 cortafuegos de red.

Planifica cómo trabajarán los equipos en colaboración 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 solicite etiquetas para sus aplicaciones. A continuación, el equipo de redes crea las etiquetas y añade reglas a la política de cortafuegos de red que permite que el tráfico fluya entre los recursos con las etiquetas, y delega los roles de gestión de identidades y accesos para usar las etiquetas al equipo de la carga de trabajo.

Optimizar tu entorno con la cartera de Active Assist

Además del recomendador de gestión de identidades y accesos, Google Cloud ofrece la cartera de servicios 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 periódicamente las recomendaciones o aplicar automáticamente las recomendaciones en tus flujos de procesamiento de despliegue. Decide qué recomendaciones debe gestionar un equipo central y cuáles deben ser responsabilidad de los propietarios de las cargas de trabajo, y aplica los roles de gestión de identidades y accesos para acceder a las recomendaciones según corresponda.

Conceder excepciones a las políticas de organización

El plano técnico aplica un conjunto de restricciones de políticas de la organización que se recomiendan a la mayoría de los clientes en la mayoría de los casos, pero es posible que tengas casos prácticos legítimos que requieran excepciones limitadas a las políticas de la organización que apliques de forma general.

Por ejemplo, el blueprint aplica la restricción iam.disableServiceAccountKeyCreation. Esta restricción es un control de seguridad importante, ya que una clave de cuenta de servicio filtrada puede tener un impacto negativo significativo. En la mayoría de los casos, se deben usar alternativas más seguras a las claves de cuenta de servicio para autenticar. Sin embargo, puede haber casos prácticos en los que solo se pueda autenticar con una clave de cuenta de servicio, como un servidor local que requiera acceso a servicios deGoogle Cloud y no pueda usar la federación de identidades de carga de trabajo. En este caso, puede que decidas permitir una excepción a la política siempre que se apliquen controles compensatorios adicionales, como las prácticas recomendadas para gestionar 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 asegurarte de que los responsables de conceder excepciones tengan los conocimientos técnicos necesarios para validar el caso práctico y determinar si se deben implementar controles adicionales para compensar la excepción. Cuando concedas una excepción a una carga de trabajo, modifica la restricción de la política de organización de la forma más específica posible. También puedes añadir restricciones condicionalmente a una política de organización definiendo una etiqueta que conceda una excepción o aplique la política y, a continuación, aplicando la etiqueta a proyectos y carpetas.

Protect your resources with VPC Service Controls

El blueprint te ayuda a preparar tu entorno para Controles de Servicio de VPC aplicando configuraciones obligatorias, como el VIP restringido. Sin embargo, el blueprint implementa inicialmente Controles de Servicio de VPC solo en el modo de prueba, ya que cambiar al modo obligatorio puede ser un proceso disruptivo que requiere una planificación específica para tu organización.

Un perímetro deniega el acceso a los servicios restringidos Google Cloud desde el 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 base que se usa para implementar recursos. Si usas Controles de Servicio de VPC, debes diseñar excepciones al perímetro que permitan las rutas de acceso que quieras.

Un perímetro de Controles de Servicio de VPC está diseñado para controlar la filtración externa de datos entre tu Google Cloud organización y fuentes externas. El perímetro no está diseñado para sustituir ni duplicar las políticas de permiso para controlar el acceso granular a proyectos o recursos concretos. Cuando diseñes y crees una arquitectura de perímetro, te recomendamos que utilices un perímetro unificado común para reducir la sobrecarga de gestión.

Si debes diseñar varios perímetros para controlar de forma granular el tráfico de servicios dentro de tu Google Cloud 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 perímetros que se necesitan para las operaciones previstas.

Para adoptar Controles de Servicio de VPC, evalúa lo siguiente:

• En qué casos prácticos necesitas Controles de Servicio de VPC.
• Si los Google Cloud serviciosnecesarios admiten Controles de Servicio de VPC.
• Cómo configurar el acceso de emergencia para modificar el perímetro en caso de que interrumpa tus pipelines de automatización.
• Cómo usar las prácticas recomendadas para habilitar Controles de Servicio de VPC y diseñar e implementar tu perímetro.

Después de cambiar el perímetro del modo de prueba al modo aplicado, te recomendamos que diseñes un proceso para añadir nuevos proyectos al perímetro correcto de forma coherente y otro para diseñar excepciones cuando los desarrolladores tengan un nuevo caso de uso que se deniegue con la configuración actual del perímetro.

Probar los cambios en toda la organización en una organización independiente

Te recomendamos que nunca implementes cambios en producción sin haberlos probado. En el caso de los recursos de carga de trabajo, este enfoque se facilita mediante entornos independientes para el desarrollo, las fases fuera de producción y la producción. Sin embargo, algunos recursos de la organización no tienen entornos independientes para facilitar las pruebas.

Si quieres hacer cambios a nivel de organización u otros cambios que puedan afectar a los entornos de producción, como la configuración entre tu proveedor de identidades y Cloud Identity, te recomendamos que crees una organización independiente para hacer pruebas.

Controlar el acceso remoto a máquinas virtuales

Como te recomendamos que implementes una infraestructura inmutable a través de las canalizaciones de base, infraestructura y aplicación, también te recomendamos que solo concedas a los desarrolladores acceso directo a una máquina virtual a través de SSH o RDP para casos prácticos limitados o excepcionales.

En los casos en los que se requiera acceso remoto, te recomendamos que gestiones el acceso de los usuarios mediante Inicio de sesión del SO siempre que sea posible. Este enfoque usa servicios gestionados Google Cloud para aplicar el control de acceso, la gestión del ciclo de vida de las cuentas, la verificación en dos pasos y el registro de auditoría. De lo contrario, si debes permitir el acceso mediante claves SSH en metadatos o credenciales RDP, es tu responsabilidad gestionar el ciclo de vida de las credenciales y almacenarlas de forma segura fuera de Google Cloud.

En cualquier caso, un usuario con acceso SSH o RDP a una VM puede suponer un riesgo de escalada 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 de la API. Este acceso puede convertirse en una elevación de privilegios si no tenías la intención de que el usuario operara con los privilegios de la cuenta de servicio.

Reducir el gasto excesivo planificando alertas de presupuesto

El plano técnico implementa las prácticas recomendadas que se describen en el Google Cloud framework Well-Architected: optimización de costes para gestionar los costes, entre las que se incluyen las siguientes:

• 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 utilice para asignar costes entre centros de costes.

• Define presupuestos y umbrales de alerta.

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

En función de su caso práctico, puede definir un presupuesto basado en el coste de una carpeta de entorno completa o de todos los proyectos relacionados con un centro de costes determinado, en lugar de definir presupuestos detallados para cada proyecto. También te recomendamos que delegues la configuración del presupuesto y las alertas en los propietarios de las cargas de trabajo, que pueden definir umbrales de alerta más específicos para su monitorización diaria.

Para obtener información sobre la optimización de costes, consulta Optimizar costes con FinOps hub.

Asignar costes entre centros de costes internos

La consola le permite ver sus informes de facturación para consultar y predecir los costes en varias dimensiones. Además de los informes predefinidos, te recomendamos que exportes los datos de facturación a un conjunto de datos de BigQuery en el proyecto de prj-c-billing-export. Los registros de facturación exportados le permiten asignar costes a dimensiones personalizadas, como sus centros de costes internos, en función de los metadatos de las etiquetas de los proyectos, como billingcode.

La siguiente consulta SQL es un ejemplo para conocer los costes de todos los proyectos agrupados por la etiqueta de proyecto billingcode.

#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 el artículo sobre cómo exportar datos de Facturación de Cloud a BigQuery.

Si necesitas llevar a cabo una contabilidad interna o una devolución de cargo entre centros de costes, es tu responsabilidad incorporar los datos obtenidos de esta consulta en tus procesos internos.

Ingiere las detecciones de los controles de detección en tu SIEM

Aunque 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 estas señales.

Si necesitas agregar registros de todos los entornos en la nube y locales en un SIEM, decide cómo ingerir registros del proyecto prj-c-logging y resultados de Security Command Center en tus herramientas y procesos. Puedes crear una única exportación de todos los registros y resultados si un solo equipo se encarga de monitorizar la seguridad en todo tu entorno, o bien puedes crear varias exportaciones filtradas por el conjunto de registros y resultados que necesiten varios equipos con diferentes responsabilidades.

Si el volumen de registros y el coste son prohibitivos, puedes evitar la duplicación conservando los registros y los resultados solo en Google Cloud .Google CloudEn este caso, asegúrate de que tus equipos tengan el acceso y la formación adecuados para trabajar con registros y resultados directamente enGoogle Cloud.

• En el caso de los registros de auditoría, diseña vistas de registro para conceder acceso a un subconjunto de registros de tu segmento de registros centralizado a equipos concretos, en lugar de duplicar los registros en varios segmentos, lo que aumenta el coste de almacenamiento de los registros.
• En el caso de los resultados de seguridad, concede roles a nivel de carpeta y de proyecto en Security Command Center para que los equipos puedan ver y gestionar los resultados de seguridad de los proyectos de los que son responsables directamente en la consola.

Desarrollar continuamente tu biblioteca de controles

El plan empieza con una base de controles para detectar y prevenir amenazas. Te recomendamos que revises estos controles y añadas otros en función de tus requisitos. En la siguiente tabla se resumen los mecanismos para aplicar las políticas de gobernanza y cómo ampliarlas para que se ajusten a tus requisitos adicionales:

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

Gestionar claves de cifrado con Cloud Key Management Service

Google Cloud proporciona cifrado predeterminado en reposo para todo el contenido de los clientes, pero también ofrece Cloud Key Management Service (Cloud KMS) para que tengas más control sobre las claves de cifrado de los datos en reposo. Te recomendamos que evalúes si el cifrado predeterminado es suficiente o si tienes un requisito de cumplimiento que te obliga a usar Cloud KMS para gestionar las claves por tu cuenta. Para obtener más información, consulta cómo decidir cómo cumplir los requisitos de cumplimiento para el cifrado en reposo.

El blueprint proporciona un proyecto prj-c-kms en la carpeta común y un proyecto prj-{env}-kms en cada carpeta de entorno para gestionar las claves de cifrado de forma centralizada. Este enfoque permite que un equipo central audite y gestione las claves de cifrado que usan los recursos de los proyectos de carga de trabajo para cumplir los requisitos normativos y de cumplimiento.

En función de tu modelo operativo, puede que prefieras una única instancia de proyecto centralizada de Cloud KMS controlada por un solo equipo, gestionar las claves de cifrado por separado en cada entorno o usar varias instancias distribuidas para que la responsabilidad de las claves de cifrado se pueda delegar en los equipos correspondientes. Modifica el código de ejemplo de Terraform según sea necesario para adaptarlo a tu modelo operativo.

También puedes aplicar políticas de organización de claves de cifrado gestionadas por el cliente (CMEK) para que determinados tipos de recursos siempre requieran una clave CMEK y solo se puedan usar claves CMEK de una lista de permitidos de proyectos de confianza.

Almacenar y auditar credenciales de aplicaciones con Secret Manager

Te recomendamos que nunca subas secretos sensibles (como claves de API, contraseñas y certificados privados) a repositorios de código fuente. En su lugar, confirma el secreto en Secret Manager y asigna el rol de IAM Permiso para acceder a los recursos de Secret Manager al usuario o a la cuenta de servicio que necesite acceder al secreto. Te recomendamos que asignes el rol de gestión de identidades y accesos a un secreto concreto y no a todos los secretos del proyecto.

Cuando sea posible, debes generar secretos de producción automáticamente en los flujos de procesamiento de CI/CD y mantenerlos inaccesibles para los usuarios humanos, excepto en situaciones de emergencia. En este caso, asegúrate de no conceder roles de gestión de identidades y accesos para ver estos secretos a ningún usuario ni grupo.

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

En función de tu modelo operativo, puede que prefieras una única instancia centralizada de Secret Manager controlada por un solo equipo, o bien gestionar los secretos por separado en cada entorno, o bien usar varias instancias distribuidas de Secret Manager para que cada equipo de carga de trabajo pueda gestionar sus propios secretos. Modifica el ejemplo de código de Terraform según sea necesario para adaptarlo a tu modelo operativo.

Planificar el acceso de emergencia a cuentas con privilegios elevados

Aunque recomendamos que los cambios en los recursos de la base se gestionen mediante IaC con control de versiones que se implemente a través de la canalización de la base, puede que te encuentres en situaciones excepcionales o de emergencia que requieran acceso privilegiado para modificar tu entorno directamente. Te recomendamos que planifiques cuentas de acceso de emergencia (a veces llamadas cuentas de emergencia o de acceso de emergencia) que tengan acceso con privilegios elevados 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 fines de las cuentas de acceso de emergencia.

El mecanismo que utilices para permitir el acceso de emergencia dependerá de las herramientas y los procedimientos que ya tengas, pero algunos ejemplos son los siguientes:

• Usa tus herramientas de gestión de accesos privilegiados para añadir temporalmente a un usuario a un grupo predefinido con roles de gestión de identidades y accesos con privilegios elevados o usa las credenciales de una cuenta con privilegios elevados.
• Cuentas preaprovisionadas destinadas únicamente a administradores. Por ejemplo, el desarrollador Dana puede tener la identidad dana@example.com para el uso diario y admin-dana@example.com para el acceso de emergencia.
• Usa una aplicación como acceso privilegiado just-in-time que permita a un desarrollador ascender a roles con más privilegios.

Independientemente del mecanismo que utilices, piensa en cómo vas a abordar las siguientes cuestiones:

• ¿Cómo se diseña el alcance y la granularidad del acceso de emergencia? Por ejemplo, puedes diseñar un mecanismo de acceso de emergencia diferente para cada unidad de negocio para asegurarte de que no puedan interrumpirse entre sí.
• ¿Cómo evita vuestro mecanismo el abuso? ¿Necesitas aprobaciones? Por ejemplo, puede que tengas operaciones divididas en las que una persona tenga las credenciales y otra, el token de MFA.
• ¿Cómo auditas y envías 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 emergencia predefinida.
• ¿Cómo se elimina el acceso de emergencia y se reanudan las operaciones normales una vez que ha finalizado el incidente?

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

En el caso de los sistemas que requieren una intervención periódica, automatizar la corrección puede ser la mejor solución. Google recomienda a los clientes que adopten un enfoque de producción sin intervención humana para realizar todos los cambios en la producción mediante la automatización, proxies seguros o breakglass auditado. Google ofrece los libros de SRE a los clientes que quieran adoptar el enfoque de SRE de Google.

Siguientes pasos

• Lee Implementar el plano (el siguiente documento de esta serie).