Desplegar una arquitectura sin servidor segura con Cloud Run

Este contenido se actualizó por última vez en marzo del 2023 y representa la situación en el momento en que se redactó. Las políticas y los sistemas de seguridad de Google pueden cambiar en el futuro, ya que mejoramos constantemente la protección que proporcionamos a nuestros clientes.

Las arquitecturas sin servidor te permiten desarrollar software y servicios sin aprovisionar ni mantener servidores. Puedes usar arquitecturas sin servidor para crear aplicaciones para una amplia gama de servicios.

En este documento se ofrecen consejos personalizados para ingenieros de DevOps, arquitectos de seguridad y desarrolladores de aplicaciones sobre cómo proteger las aplicaciones sin servidor que utilizan Cloud Run. El documento forma parte de un plan de seguridad que consta de lo siguiente:

• Un repositorio de GitHub que contiene un conjunto de configuraciones y secuencias de comandos de Terraform.
• Una guía sobre la arquitectura, el diseño y los controles de seguridad que implementas con el plano (este documento).

Aunque puedes implementar este plano sin implementar primero el Google Cloud plano de las bases de la empresa, en este documento se da por hecho que ya has configurado un conjunto básico de controles de seguridad, tal como se describe en el plano de las bases de la empresa. Google Cloud La arquitectura que se describe en este documento te ayuda a añadir controles adicionales a tu base para proteger tus aplicaciones sin servidor.

Para ayudar a definir los controles de seguridad clave relacionados con las aplicaciones sin servidor, la Cloud Security Alliance (CSA) publicó los 12 principales riesgos críticos para las aplicaciones sin servidor. Los controles de seguridad que se usan en este plano están diseñados para abordar los riesgos que son relevantes para los distintos casos prácticos descritos en este documento.

Casos prácticos de la tecnología sin servidor

El plan admite los siguientes casos prácticos:

• Desplegar una arquitectura sin servidor con Cloud Run (este documento)
• Desplegar una arquitectura sin servidor con Cloud Run Functions

Estas son algunas de las diferencias entre Cloud Run Functions y Cloud Run:

• Las funciones de Cloud Run se activan mediante eventos, como cambios en los datos de una base de datos o la recepción de un mensaje de un sistema de mensajería como Pub/Sub. Cloud Run se activa mediante solicitudes, como las solicitudes HTTP.
• Cloud Run Functions se limita a un conjunto de tiempos de ejecución admitidos. Puedes usar Cloud Run con cualquier lenguaje de programación.
• Cloud Run Functions gestiona los contenedores y la infraestructura que controla el servidor web o el tiempo de ejecución del lenguaje para que puedas centrarte en tu código. Cloud Run te ofrece la flexibilidad de ejecutar estos servicios por tu cuenta para que tengas el control de la configuración del contenedor.

Para obtener más información sobre las diferencias entre Cloud Run y Cloud Functions, consulta Elegir una opción de Google Cloud proceso.

Arquitectura

Este plano técnico te permite ejecutar aplicaciones sin servidor en Cloud Run con VPC compartida. Te recomendamos que uses una VPC compartida porque centraliza la política de red y el control de todos los recursos de red. Además, la VPC compartida se implementa en el plano de aspectos básicos de las empresas.

Arquitectura recomendada: Cloud Run con una red de VPC compartida

En la siguiente imagen se muestra cómo puedes ejecutar tus aplicaciones sin servidor en una red de VPC compartida.

La arquitectura que se muestra en el diagrama anterior usa una combinación de los siguientes Google Cloud servicios y funciones:

• Un balanceador de carga de aplicaciones externo recibe los datos que necesitan las aplicaciones sin servidor de Internet y los reenvía a Cloud Run. El balanceador de carga de aplicación externo es un balanceador de carga de capa 7.
• Google Cloud Armor actúa como cortafuegos de aplicaciones web para proteger tus aplicaciones sin servidor frente a ataques web y de denegación de servicio (DoS).
• Cloud Run te permite ejecutar código de aplicación en contenedores y gestiona la infraestructura en tu nombre. En este plano, el ajuste de Ingress de balanceo de carga interno y de Cloud restringe el acceso a Cloud Run para que Cloud Run solo acepte solicitudes del balanceador de carga de aplicaciones externo.

• El conector de Acceso a VPC sin servidor conecta tu aplicación sin servidor a tu red de VPC mediante Acceso a VPC sin servidor. Acceso a VPC sin servidor ayuda a asegurar que las solicitudes de tu aplicación sin servidor a la red VPC no estén expuestas a Internet. Acceso a VPC sin servidor permite que Cloud Run se comunique con otros servicios, sistemas de almacenamiento y recursos que admiten Controles de Servicio de VPC.

  De forma predeterminada, el conector de Acceso a VPC sin servidor se crea en el proyecto de servicio. Puedes crear el conector de acceso a VPC sin servidor en el proyecto host especificando true para la variable de entrada connector_on_host_project cuando ejecutes el módulo Secure Cloud Run Network. Para obtener más información, consulta la comparación de los métodos de configuración.

• Las reglas de cortafuegos de la nube privada virtual (VPC) controlan el flujo de datos hacia la subred que aloja tus recursos, como un servidor de la empresa alojado en Compute Engine o datos de la empresa almacenados en Cloud Storage.

• Controles de Servicio de VPC crea un perímetro de seguridad que aísla tus servicios y recursos de Cloud Run configurando la autorización, los controles de acceso y el intercambio de datos seguro. Este perímetro se ha diseñado para proteger el contenido entrante, aislar tu aplicación configurando controles de acceso y monitorización adicionales, y separar tu gobernanza de Google Cloud de la aplicación. Tu gobernanza incluye la gestión de claves y el registro.

• VPC compartida te permite conectar el conector de Acceso a VPC sin servidor de tu proyecto de servicio al proyecto host.

• Cloud Key Management Service (Cloud KMS) almacena las claves de cifrado gestionadas por el cliente (CMEKs) que utilizan los servicios de este plano, como tu aplicación sin servidor, Artifact Registry y Cloud Run.

• Gestión de Identidades y Accesos (IAM) y Resource Manager ayudan a restringir el acceso y aislar los recursos. Los controles de acceso y la jerarquía de recursos siguen el principio de mínimos accesos.

Arquitectura alternativa: Cloud Run sin una red de VPC compartida

Si no usas una red de VPC compartida, puedes implementar Cloud Run y tu aplicación sin servidor en un perímetro de Controles de Servicio de VPC sin una red de VPC compartida. Puedes implementar esta arquitectura alternativa si utilizas una topología de concentrador y radios.

En la siguiente imagen se muestra cómo puedes ejecutar tus aplicaciones sin servidor sin una VPC compartida.

La arquitectura que se muestra en el diagrama anterior usa una combinación de servicios y funciones deGoogle Cloud similar a la que se describe en la sección anterior, Arquitectura recomendada: Cloud Run con una VPC compartida.

Estructura de la organización

Agrupa tus recursos para poder gestionarlos y separar tus entornos de desarrollo y prueba de tu entorno de producción. Resource Manager te permite agrupar recursos de forma lógica por proyecto, carpeta y organización.

En el siguiente diagrama se muestra una jerarquía de recursos con carpetas que representan diferentes entornos, como bootstrap, common, producción, no producción (o pruebas) y desarrollo. Esta jerarquía de recursos se basa en la jerarquía que se describe en el plano de aspectos básicos de las empresas. Los proyectos que especifica el plano se implementan en las siguientes carpetas: Common, Production, Non-production y Dev.

En las secciones siguientes se describe este diagrama con más detalle.

Carpetas

Usa carpetas para aislar tu entorno de producción y tus servicios de gobernanza de tus entornos de prueba y no de producción. En la siguiente tabla se describen las carpetas del blueprint de las bases de la empresa que utiliza este blueprint.

Carpeta	Descripción
Bootstrap	Contiene los recursos necesarios para desplegar el blueprint de las bases de la empresa.
Common	Contiene servicios centralizados para la organización, como el proyecto de seguridad.
Production	Contiene proyectos con recursos en la nube que se han probado y que los clientes pueden usar. En este blueprint, la carpeta Production contiene el proyecto de servicio y el proyecto host.
Non-production	Contiene proyectos que tienen recursos en la nube que se están probando y preparando para su lanzamiento. En este blueprint, la carpeta Non-production contiene el proyecto de servicio y el proyecto host.
Dev	Contiene proyectos que tienen recursos en la nube que se están desarrollando. En este blueprint, la carpeta Dev contiene el proyecto de servicio y el proyecto del host.

Puede cambiar los nombres de estas carpetas para que se ajusten a la estructura de carpetas de su organización, pero le recomendamos que mantenga una estructura similar. Para obtener más información, consulta Estructura organizativa. Para ver otras estructuras de carpetas, consulta Decidir una jerarquía de recursos para tu Google Cloud zona de aterrizaje.

Proyectos

Puedes aislar los recursos de tu entorno mediante proyectos. En la siguiente tabla se describen los proyectos que se necesitan en la organización. Puedes cambiar los nombres de estos proyectos, pero te recomendamos que mantengas una estructura similar.

Proyecto	Descripción
Proyecto del host	Este proyecto incluye las reglas de entrada del cortafuegos y los recursos que tengan direcciones IP internas (como se describe en Conectarse a una red de VPC). Cuando usas la VPC compartida, designas un proyecto como proyecto host y le asocias uno o varios proyectos de servicio. Cuando apliques el código de Terraform, especifica el nombre de este proyecto y el blueprint implementará los servicios.
Proyecto de servicio	Este proyecto incluye tu aplicación sin servidor, Cloud Run y el conector de acceso a VPC sin servidor. Asocia el proyecto de servicio al proyecto del host para que pueda participar en la red de VPC compartida. Cuando apliques el código de Terraform, especifica el nombre de este proyecto. El blueprint implementa Cloud Run, Cloud Armor, el conector de acceso a VPC sin servidor y el balanceador de carga.
Proyecto de seguridad	Este proyecto incluye tus servicios específicos de seguridad, como Cloud KMS y Secret Manager. Cuando apliques el código de Terraform, especifica el nombre de este proyecto y el blueprint implementará Cloud KMS. Si usas el módulo Secure Cloud Run Harness, también se implementa Artifact Registry. Si implementas este blueprint después de implementar el blueprint de las bases de seguridad, este proyecto será el proyecto de secretos creado por el blueprint de las bases de la empresa. Para obtener más información sobre los proyectos de la plantilla de bases empresariales, consulta Proyectos. Si implementas varias instancias de este blueprint sin el blueprint de bases empresariales, cada instancia tendrá su propio proyecto de seguridad.

Asignar roles y grupos a proyectos

Debes dar acceso a los distintos grupos de usuarios de tu organización a los proyectos que componen la arquitectura sin servidor. En la siguiente tabla se describen las recomendaciones de la plantilla para los grupos de usuarios y las asignaciones de roles en los proyectos que crees. Puedes personalizar los grupos para que se ajusten a la estructura de tu organización, pero te recomendamos que mantengas una segregación de tareas y una asignación de roles similares.

Grupo	Proyecto	Roles
Administrador de Serverless grp-gcp-serverless-admin@example.com	Proyecto de servicio	roles/run.admin roles/compute.networkViewer compute.networkUser
Administrador de seguridad de Serverless grp-gcp-serverless-security-admin@example.com	Proyecto de seguridad	roles/run.viewer roles/cloudkms.viewer roles/artifactregistry.reader
Desarrollador de Cloud Run grp-gcp-secure-cloud-run-developer@example.com	Proyecto de seguridad	roles/run.developer roles/artifactregistry.writer roles/cloudkms.cryptoKeyEncrypter
Usuario de Cloud Run grp-gcp-secure-cloud-run-user@example.com	Proyecto de servicio	roles/run.invoker

Controles de seguridad

En esta sección se describen los controles de seguridad de Google Cloud que puedes usar para proteger tu arquitectura sin servidor. Estos son los principios de seguridad clave que debes tener en cuenta:

• Protege el acceso según el principio de mínimos accesos, concediendo a las entidades solo los privilegios necesarios para realizar sus tareas.
• Protege las conexiones de red mediante el diseño de segmentación, las políticas de la organización y las políticas de cortafuegos.
• Configuración segura para cada uno de los servicios.
• Conocer los niveles de riesgo y los requisitos de seguridad del entorno que aloja tus cargas de trabajo sin servidor.
• Configura una monitorización y un registro suficientes para permitir la detección, la investigación y la respuesta.

Controles de seguridad para aplicaciones sin servidor

Puedes proteger tus aplicaciones sin servidor con controles que protejan el tráfico de la red, controlen el acceso y cifren los datos.

Controles del sistema de compilación

Cuando despliegues tu aplicación sin servidor, usarás Artifact Registry para almacenar las imágenes de contenedor y los archivos binarios. Artifact Registry admite CMEK para que puedas cifrar el repositorio con tus propias claves de cifrado.

Tráfico SSL

Para admitir el tráfico HTTPS a tu aplicación sin servidor, configura un certificado SSL para tu balanceador de carga de aplicaciones externo. De forma predeterminada, se usa un certificado autofirmado que se puede cambiar por un certificado gestionado después de aplicar el código de Terraform. Para obtener más información sobre cómo instalar y usar certificados gestionados, consulta Usar certificados SSL gestionados por Google.

Reglas de red y de cortafuegos

Las reglas de cortafuegos de la nube privada virtual (VPC) controlan el flujo de datos hacia los perímetros. Crea reglas de cortafuegos que denieguen todo el tráfico de salida, excepto las conexiones específicas del puerto TCP 443 de los nombres de dominio especiales de restricted.googleapis.com. Usar el dominio restricted.googleapis.com tiene las siguientes ventajas:

• Ayuda a reducir la superficie de ataque de tu red mediante el acceso privado a Google cuando las cargas de trabajo se comunican con las APIs y los servicios de Google.
• De esta forma, solo usará servicios que admitan Controles de Servicio de VPC.

Para obtener más información, consulta el artículo sobre cómo configurar Acceso privado de Google.

Controles perimetrales

Como se muestra en el diagrama de arquitectura recomendada, los recursos de la aplicación sin servidor se colocan en un perímetro independiente. Este perímetro ayuda a proteger la aplicación sin servidor frente a accesos no deseados y filtraciones de datos.

Política accedida

Para asegurarte de que solo identidades específicas (usuarios o servicios) puedan acceder a recursos y datos, habilita grupos y roles de gestión de identidades y accesos.

Para asegurarte de que solo determinados recursos puedan acceder a tus proyectos, habilita una política de acceso en tu organización de Google. Para obtener más información, consulta Atributos de nivel de acceso.

Proxy de identidad y acceso

Si tu entorno ya incluye Identity and Access Proxy (IAP), puedes configurar el balanceador de carga de aplicaciones externo para que use IAP y autorice el tráfico de tu aplicación sin servidor. IAP te permite establecer una capa de autorización central para tu aplicación sin servidor, de forma que puedas usar controles de acceso a nivel de aplicación en lugar de depender de firewalls a nivel de red.

Para habilitar IAP en tu aplicación, en el archivo loadbalancer.tf, asigna el valor true a iap_config.enable.

Para obtener más información sobre IAP, consulta el artículo de introducción a Identity-Aware Proxy.

Cuentas de servicio y controles de acceso

Las cuentas de servicio son identidades que Google Cloud pueden usar para ejecutar solicitudes de API en tu nombre. Para implementar la separación de tareas, crea cuentas de servicio que tengan diferentes roles para fines específicos. Las cuentas de servicio son las siguientes:

• Una cuenta de servicio de Cloud Run (cloud_run_sa) que tenga los siguientes roles:

  • roles/run.invoker
  • roles/secretmanager.secretAccessor

  Para obtener más información, consulta Permitir que Cloud Run acceda a un secreto.

• Una cuenta de conector de Acceso a VPC sin servidor (gcp_sa_vpcaccess) que tenga el rol roles/compute.networkUser.

• Una segunda cuenta de conector de Acceso a VPC sin servidor (cloud_services) que tenga el rol roles/compute.networkUser.

  Estas cuentas de servicio del conector de Acceso a VPC sin servidor son necesarias para que el conector pueda crear las reglas de entrada y salida del cortafuegos en el proyecto host. Para obtener más información, consulta Conceder permisos a cuentas de servicio en proyectos de servicio.

• Una identidad de servicio para ejecutar Cloud Run (run_identity_services) que tenga el rol roles/vpcaccess.user.

• Un agente de servicios de las APIs de Google (cloud_services_sa) que tiene el rol roles/editor. Esta cuenta de servicio permite que Cloud Run se comunique con el conector de Acceso a VPC sin servidor.

• Una identidad de servicio de Cloud Run (serverless_sa) que tenga el rol roles/artifactregistry.reader. Esta cuenta de servicio proporciona acceso a Artifact Registry y a las claves de encriptado y desencriptado de CMEK.

Gestión de claves

Las claves CMEK se usan para proteger los datos de Artifact Registry y Cloud Run. Utiliza las siguientes claves de cifrado:

• Una llave de software de Artifact Registry que certifica el código de tu aplicación sin servidor.
• Una clave de cifrado para cifrar las imágenes de contenedor que despliega Cloud Run.

Cuando aplicas la configuración de Terraform, especificas la ubicación de CMEK, que determina la ubicación geográfica en la que se almacenan las claves. Debes asegurarte de que tus claves CMEK estén en la misma región que tus recursos. De forma predeterminada, las claves CMEK se rotan cada 30 días.

Gestión de secretos

Cloud Run admite Secret Manager para almacenar los secretos que pueda requerir tu aplicación sin servidor. Estos secretos pueden incluir claves de API, nombres de usuario y contraseñas de bases de datos. Para exponer el secreto como un volumen montado, usa las variables volume_mounts y volumes en el módulo principal.

Cuando implementes este blueprint con el blueprint de bases de la empresa, debes añadir tus secretos al proyecto de secretos antes de aplicar el código de Terraform. El blueprint concederá el rol Permiso para acceder a los recursos de Secret Manager a la cuenta de servicio de Cloud Run. Para obtener más información, consulta Usar secretos.

Políticas de organización

Este blueprint añade restricciones a las restricciones de las políticas de organización. Para obtener más información sobre las restricciones que usa el blueprint de las bases de la empresa, consulta Restricciones de la política de la organización.

En la siguiente tabla se describen las restricciones de políticas de organización adicionales que se definen en el módulo Seguridad de Cloud Run de este plano.

Restricción basada en las políticas	Descripción	Valor recomendado
constraints/run.allowedIngress	Permitir solo el tráfico de entrada de servicios internos o del balanceador de carga de aplicaciones externo.	internal-and-cloud-load-balancing
constraints/run.allowedVPCEgress	Requerir que las revisiones de un servicio de Cloud Run usen un conector de acceso a VPC sin servidor y asegurarse de que la configuración de salida de VPC de las revisiones esté definida para permitir solo los intervalos privados.	private-ranges-only

Controles operativos

Puedes habilitar el registro y las funciones del nivel Premium de Security Command Center, como las analíticas del estado de la seguridad y la detección de amenazas. Estos controles te ayudan a hacer lo siguiente:

• Monitoriza quién accede a tus datos.
• Asegúrate de que se realice una auditoría adecuada.
• Ayuda a tus equipos de gestión de incidentes y operaciones a responder a los problemas que puedan surgir.

Almacenamiento de registros

Para ayudarte a cumplir los requisitos de auditoría y obtener información valiosa sobre tus proyectos, puedes configurar Observabilidad de Google Cloud con registros de datos de los servicios que quieras monitorizar. Implementa Cloud Logging en los proyectos antes de aplicar el código de Terraform para asegurarte de que el blueprint pueda configurar el registro del cortafuegos, el balanceador de carga y la red de VPC.

Después de implementar el blueprint, te recomendamos que configures lo siguiente:

• Crea un sumidero de registro agregado en todos los proyectos.
• Selecciona la región adecuada para almacenar tus registros.
• Añade claves CMEK a tu receptor de registro.

En todos los servicios de los proyectos, asegúrese de que sus registros incluyan información sobre las lecturas y escrituras de datos, así como sobre a qué acceden los administradores. Para obtener más información sobre las prácticas recomendadas de registro, consulta Controles de detección.

Monitorización y alertas

Una vez que hayas implementado el blueprint, puedes configurar alertas para notificar a tu centro de operaciones de seguridad (SOC) que puede estar produciéndose un incidente de seguridad. Por ejemplo, puedes usar alertas para informar a tus analistas de seguridad cuando se haya cambiado un permiso en un rol de gestión de identidades y accesos. Para obtener más información sobre cómo configurar las alertas de Security Command Center, consulta el artículo Configurar notificaciones de resultados.

El panel de control de monitorización de Cloud Run, que forma parte de la biblioteca de paneles de control de ejemplo, te proporciona la siguiente información:

• Número de solicitudes
• Latencia de solicitudes
• Tiempo de instancia facturable
• Asignación de CPU del contenedor
• Asignación de memoria de contenedor
• Uso de la CPU del contenedor
• Uso de la memoria del contenedor

Para obtener instrucciones sobre cómo importar el panel de control, consulta el artículo Instalar paneles de control de ejemplo. Para exportar alertas, consulta los siguientes documentos:

• Introducción a las alertas

• Exportación de métricas de Cloud Monitoring

Depuración y solución de problemas

Puedes ejecutar pruebas de conectividad para depurar problemas de configuración de red entre Cloud Run y los recursos de tu subred. Pruebas de conectividad simula la ruta prevista de un paquete y proporciona detalles sobre la conectividad, incluido el análisis de la conectividad entre recursos.

El código de Terraform no habilita las pruebas de conectividad, por lo que debe configurarlas por separado. Para obtener más información, consulta Crear y ejecutar pruebas de conectividad.

Controles de detección

En esta sección se describen los controles de detección que se incluyen en el plan técnico.

Cloud Armor y WAF

Utilizas un balanceador de carga de aplicación externo y Cloud Armor para proteger tu aplicación sin servidor frente a ataques de denegación de servicio distribuido (DDoS). Cloud Armor es el cortafuegos de aplicación web (WAF) incluido enGoogle Cloud.

Configura las reglas de Cloud Armor descritas en la siguiente tabla para proteger la aplicación sin servidor. Las reglas están diseñadas para ayudar a mitigar los diez riesgos principales según el proyecto OWASP.

Nombre de la regla de Cloud Armor	Nombre de la regla de ModSecurity
Ejecución remota de código	rce-v33-stable
Inclusión de archivos locales	lfi-v33-stable
Ataque de protocolo	protocolattack-v33-stable
Inclusión de archivos remotos	rfi-v33-stable
Detección de escáneres	scannerdetection-v33-stable
Ataque de fijación de sesión	sessionfixation-v33-stable
inyección de SQL	sqli-v33-stable
Cross-site scripting	xss-v33-stable

Cuando estas reglas están habilitadas, Cloud Armor deniega automáticamente el tráfico que coincida con la regla.

Para obtener más información sobre estas reglas, consulta el artículo Activar las reglas de WAF preconfiguradas de Google Cloud Armor.

Detección de problemas de seguridad en Cloud Run

Puedes detectar posibles problemas de seguridad en Cloud Run con Recommender. Recommender puede detectar problemas de seguridad como los siguientes:

• Claves de API o contraseñas almacenadas en variables de entorno en lugar de en Secret Manager.
• Contenedores que incluyen credenciales codificadas en lugar de usar identidades de servicio.

Aproximadamente un día después de implementar Cloud Run, Recommender empieza a proporcionar sus conclusiones y recomendaciones. Recommender muestra sus conclusiones y las acciones correctivas recomendadas en la lista de servicios de Cloud Run o en el centro de recomendaciones.

Modos de despliegue de Terraform

En la siguiente tabla se describen las formas en las que puedes implementar este blueprint y los módulos de Terraform que se aplican a cada modo de implementación.

Modo de despliegue	Módulo de Terraform
Implementa este plano después de implementar el plano de aspectos básicos de las empresas (recomendado). Esta opción implementa los recursos de este blueprint en el mismo perímetro de Controles de Servicio de VPC que usa el blueprint de bases de la empresa. Para obtener más información, consulta Cómo personalizar Foundation v2.3.1 para una implementación sin servidor segura. Esta opción también usa el proyecto de secretos que creaste al implementar el blueprint de las bases de la empresa.	Usa estos módulos de Terraform: secure-cloud-run-core secure-serverless-net secure-cloud-run-security secure-cloud-run
Instala este plano sin instalar el plano de los fundamentos de la empresa. Para usar esta opción, debes crear un perímetro de Controles de Servicio de VPC.	Usa estos módulos de Terraform: secure-cloud-run-core secure-serverless-harness secure-serverless-net secure-cloud-run-security secure-cloud-run

Resumen

Para implementar la arquitectura descrita en este documento, sigue estos pasos:

1. Consulta el archivo README del blueprint y asegúrate de que cumples todos los requisitos previos.
2. Crea un certificado SSL para usarlo con el balanceador de carga de aplicaciones externo.
   Si no completas este paso, el blueprint usará un certificado autofirmado para implementar el balanceador de carga y tu navegador mostrará advertencias sobre conexiones no seguras cuando intentes acceder a tu aplicación sin servidor.
3. En tu entorno de pruebas, implementa el ejemplo de Cloud Run seguro para ver el blueprint en acción. Como parte del proceso de prueba, te recomendamos que hagas lo siguiente:
   1. Usa Security Command Center para analizar los proyectos en función de los requisitos de cumplimiento habituales.
   2. Sustituye la aplicación de ejemplo por una aplicación real y sigue un proceso de despliegue típico.
   3. Colabora con los equipos de ingeniería y operaciones de aplicaciones de tu empresa para probar su acceso a los proyectos y verificar si pueden interactuar con la solución de la forma esperada.
4. Despliega el proyecto en tu entorno.

Asignaciones de cumplimiento

Para ayudar a definir los controles de seguridad clave relacionados con las aplicaciones sin servidor, la Cloud Security Alliance (CSA) publicó los 12 principales riesgos críticos para las aplicaciones sin servidor. Los controles de seguridad que se usan en este plan técnico te ayudan a abordar la mayoría de estos riesgos, tal como se describe en la siguiente tabla.

Riesgo	Mitigación de planos	Tu responsabilidad
1. Inyección de datos de eventos de funciones	Cloud Armor y los balanceadores de carga de aplicaciones externos ayudan a protegerse frente a las 10 principales amenazas de OWASP, tal como se describe en las opciones de mitigación de las 10 principales amenazas de OWASP del 2021 Google Cloud.	Prácticas de codificación segura, como el control de excepciones, tal como se describe en las prácticas de codificación segura de OWASP y en los niveles de la cadena de suministro para artefactos de software (SLSA)
2. Autenticación vulnerada	Ninguno	IAP e Identity Platform para autenticar a los usuarios en el servicio
3. Configuración de despliegue sin servidor no segura	CMEK con Cloud KMS	Gestión de tus propias claves de cifrado
4. Permisos y roles de funciones con demasiados privilegios	Cuenta de servicio personalizada para la autenticación de servicios (no la cuenta de servicio predeterminada de Compute Engine) Roles de gestión de identidades y accesos con un ámbito reducido en la cuenta de servicio de Cloud Run Controles de Servicio de VPC para limitar el ámbito del acceso a las APIs (tal como se proporciona en el blueprint de las bases empresariales) Google Cloud Google Cloud	Ninguno
5. Monitorización y registro de funciones inadecuados	Cloud Logging	Paneles de control y estructura de alertas de Cloud Monitoring
6. Dependencias de terceros no seguras	Ninguno	Protege el flujo de procesamiento de CI/CD con el escaneo de código y el análisis previo a la implementación.
7. Almacenamiento no seguro de secretos de aplicaciones	Secret Manager	Gestión de secretos en el código de la aplicación
8. Denegación de servicio y agotamiento de recursos financieros	Cloud Armor Tiempos de espera del servicio de Cloud Run (el valor predeterminado es de 120 segundos)	Ninguno
9. Manipulación de la lógica empresarial sin servidor	Controles de Servicio de VPC para limitar el ámbito del acceso a la Google Cloud API (proporcionado mediante el blueprint de la base empresarial)	Ninguno
10. Gestión inadecuada de excepciones y mensajes de error detallados	Ninguno	Prácticas recomendadas de programación segura
11. Funciones, recursos de nube y activadores de eventos obsoletos	Usa revisiones para minimizar la superficie de ataque. Las revisiones ayudan a reducir la probabilidad de habilitar por error una iteración anterior y obsoleta de un servicio. Las revisiones también te ayudan a probar la postura de seguridad de una nueva revisión mediante pruebas A/B, así como herramientas de monitorización y registro.	Infraestructura como código (IaC) para gestionar recursos en la nube Monitorizar recursos de la nube con Security Command Center Monitorización de Facturación de Cloud Limpieza de recursos en la nube no utilizados para minimizar la superficie de ataque
12. Persistencia de datos entre ejecuciones	Ninguno	Ninguno

Siguientes pasos

• Para crear un entorno seguro básico, consulta el Google Cloud plano de aspectos básicos de las empresas.
• Para ver los detalles del blueprint que se describe en este documento, consulta el archivo README de configuración de Terraform.

• Para consultar las prácticas recomendadas de seguridad y cumplimiento, consulta el artículo Google Cloud Framework Well-Architected: seguridad, privacidad y cumplimiento.

• Para consultar más prácticas recomendadas y planos, visita el centro de prácticas recomendadas de seguridad.