Prácticas recomendadas para las operaciones

Last reviewed 2023-12-20 UTC

En esta sección, se presentan las operaciones que debes tener en cuenta a la hora de implementar y operar cargas de trabajo adicionales en tu entorno de Google Cloud . El objetivo de esta sección no es abarcar todas las operaciones de tu entorno de nube, sino presentar decisiones relacionadas con las recomendaciones arquitectónicas y los recursos que implementa el modelo.

Actualiza los recursos de la base

Aunque el modelo de diseño proporciona un punto de partida definido para tu ambiente de base, es posible que tus requisitos de base aumenten con el tiempo. Después de la implementación inicial, puedes ajustar la configuración o compilar nuevos servicios compartidos para que los consuman todas las cargas de trabajo.

Para modificar los recursos de la fundación, te recomendamos que realices todos los cambios a través de la canalización de la fundación. 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 nuevas

Cuando creas proyectos nuevos a través del módulo de fábrica de proyectos de la canalización de automatización, debes 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 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 se debe agregar el proyecto a un perímetro de Controles de servicio de VPC
  • Si deseas 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 de 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. Ten siempre presente 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

En las topologías de red que implementa el modelo, se supone 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 cargas 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 los equipos trabajarán en conjunto 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 cargas 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 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 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.

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

El modelo 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 de uso legítimos que requieran excepciones limitadas a las políticas de la organización que aplicas de forma general.

Por ejemplo, el modelo 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 esta situación, puedes 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 otorgues una excepción a una carga de trabajo, modifica la restricción de la política de la organización lo más específica 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 modelo ayuda a preparar tu entorno para los Controles del servicio de VPC, ya que separa las redes base y restringidas. Sin embargo, de forma predeterminada, el código de Terraform no habilita los Controles del servicio de VPC, ya que esta habilitación puede ser un proceso disruptivo.

Un perímetro niega el acceso a los servicios Google Cloud restringidos desde el tráfico que se origina fuera del perímetro, lo que incluye la consola, las estaciones de trabajo del desarrollador y la canalización de la 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 Google Cloud organización y fuentes externas. El perímetro no está diseñado para reemplazar o 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, te 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 Google Cloud organización, te recomendamos que definas con claridad 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.

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

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.

Cómo probar cambios en toda la organización en una organización independiente

Te recomendamos que nunca implementes cambios en producción sin realizar pruebas. En el caso de los recursos de la carga 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 situaciones que requieran acceso remoto, te recomendamos que administres el acceso de los usuarios con el Acceso al SO siempre que sea posible. En este enfoque, se usan servicios Google Cloud administrados para aplicar el control de acceso, la administración del ciclo de vida de las cuentas, 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 caso, un usuario con acceso SSH o RDP a una VM puede ser un riesgo de escalamiento 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 opere con los privilegios de la cuenta de servicio.

Planifica alertas de presupuesto para mitigar el exceso de gastos

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

  • Usa 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 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 esquema crea alertas de presupuesto para los proyectos de carga de trabajo cuando el gasto previsto está en camino de alcanzar el 120% del presupuesto. Este enfoque permite que un equipo central identifique y mitigue incidentes de sobregasto 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 cargas de trabajo que podrían establecer un umbral de alerta más detallado para su supervisión diaria.

Si deseas obtener orientación para desarrollar capacidades de FinOps, incluida la previsión de presupuestos para cargas de trabajo, consulta Primeros pasos con 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 los costos 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-export. Los registros de facturación exportados te permiten asignar el costo en dimensiones personalizadas, como tus centros de costos internos, en función de los metadatos de la etiqueta del 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 Cómo exportar datos de la Facturación de Cloud a BigQuery.

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

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

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 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 para 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 reteniendo los registros y los hallazgos de Google Cloud solo enGoogle Cloud. En esta situación, asegúrate de que tus equipos existentes tengan el acceso y la capacitación adecuados para trabajar con registros y 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.

Desarrollar continuamente tu biblioteca de controles

El plan comienza con un modelo de referencia de controles para detectar y evitar 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 extenderlas para tus requisitos adicionales:

Controles de políticas que aplica el modelo 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 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 obtener configuraciones aceptables antes de la implementación.

Desarrolla restricciones adicionales según los lineamientos de GoogleCloudPlatform/policy-library.

Alertas sobre métricas basadas en registros y métricas de rendimiento configura métricas basadas en registros para alertar sobre cambios en las políticas de IAM y la configuración 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 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 funciones de Cloud Run 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 enGoogle 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 Decide cómo cumplir con los requisitos de cumplimiento para la encriptación en reposo.

El modelo 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 regulatorios 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 automáticamente 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 modelo 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 regulatorios 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 código de Terraform según sea necesario para que se adapte a tu modelo operativo.

Planifica el acceso de emergencia a cuentas con muchos privilegios

Aunque recomendamos que los cambios en los recursos de la base se administren a través de la IaC controlada por versión que implementa la canalización de base, es posible que tengas situaciones excepcionales o de emergencia que requieran acceso con privilegios 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 de alto privilegio a tu entorno en caso de emergencia o cuando fallen los procesos de automatización.

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

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 canalización de base

Acceso de emergencia para modificar los recursos de tu proyecto de CI/CD en Google Cloud y el repositorio de Git externo en caso de que falle la automatización de la canalización de la fundación.

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 con el sistema de cristal de seguridad 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.
  • Cuentas de aprovisionamiento previo destinadas solo para el uso del administrador. Por ejemplo, la desarrolladora Dana podría 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 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 abordas de manera operativa las siguientes preguntas:

  • ¿Cómo diseñas 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 evita el abuso tu mecanismo? ¿Necesitas aprobaciones? Por ejemplo, es posible que tengas operaciones divididas en las que una persona tenga las credenciales y otra tenga el token de MFA.
  • ¿Cómo se audita y alerta sobre el acceso de emergencia? Por ejemplo, puedes configurar un módulo personalizado de Detección de amenazas de eventos para crear un hallazgo de seguridad cuando se usa una cuenta de emergencia predefinida.
  • ¿Cómo se quita el acceso al cristal de seguridad y se reanudan las operaciones normales después de que termina 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?