Implementa una arquitectura segura sin servidores con Cloud Run

Last reviewed 2023-03-10 UTC

Este contenido se actualizó por última vez en marzo de 2023 y representa el statu quo en el momento de su redacción. Los sistemas y las políticas de seguridad de Google pueden cambiar en el futuro, ya que mejoramos la protección para nuestros clientes de manera continua.

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

En este documento, se proporciona orientación revisada para ingenieros DevOps, arquitectos de seguridad y desarrolladores de aplicaciones sobre cómo ayudar a proteger aplicaciones sin servidores que usan Cloud Run. El documento es parte de un plano de seguridad que consta de los siguientes elementos:

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

Aunque puedes implementar este plano sin implementar primero el plano de bases empresariales de Google Cloud, en este documento, se supone que ya configuraste un conjunto básico de controles de seguridad, como se describe en el plano de bases empresariales de Google Cloud. La arquitectura que se describe en este documento te ayuda a agregar controles adicionales a la base para proteger las aplicaciones sin servidores.

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

Casos de uso sin servidores

Este plano admite los siguientes casos de uso:

Las diferencias entre Cloud Functions y Cloud Run incluyen las siguientes opciones:

  • Cloud Functions se activa mediante eventos, como cambios en los datos en una base de datos o la recepción de un mensaje de un sistema de mensajería, como Pub/Sub. Las solicitudes, como las solicitudes HTTP, activan Cloud Run.
  • Cloud Functions se limita a un conjunto de entornos de ejecución compatibles. Puedes usar Cloud Run con cualquier lenguaje de programación.
  • Cloud Functions administra los contenedores y la infraestructura que controla el servidor web o el entorno de ejecución de lenguaje para que puedas enfocarte en el código. Cloud Run proporciona la flexibilidad para que ejecutes estos servicios, de modo 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 Elige una opción de procesamiento de Google Cloud.

Arquitectura

Este plano te permite ejecutar aplicaciones sin servidores en Cloud Run con una VPC compartida. Te recomendamos usar una VPC compartida porque centraliza la política de red y el control para todos los recursos de red. Además, la VPC compartida se implementa en el plano de las bases empresariales.

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

La arquitectura del plano sin servidores.

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

  • Un balanceador de cargas de aplicaciones externo recibe los datos que las aplicaciones sin servidores requieren de Internet y los reenvía a Cloud Run. El balanceador de cargas de aplicaciones externo es un balanceador de cargas de capa 7.
  • Google Cloud Armor actúa como el firewall de aplicación web para ayudar a proteger las aplicaciones sin servidores contra los ataques web y de denegación del servicio (DoS).
  • Cloud Run te permite ejecutar el código de la aplicación en contenedores y administra la infraestructura en tu nombre. En este plano, la configuración de entrada de Cloud Load Balancing e interna restringe el acceso a Cloud Run para que Cloud Run acepte solicitudes solo del balanceador de cargas de aplicaciones externo.

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

    De forma predeterminada, creas el conector de Acceso a VPC sin servidores en el proyecto de servicio. Para crear el conector de Acceso a VPC sin servidores en el proyecto host, especifica true para la variable de entrada connector_on_host_project cuando ejecutes módulo de red segura de Cloud Run. Para obtener más información, consulta la Comparación de los métodos de configuración.

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

  • Los Controles del servicio de VPC crean un perímetro de seguridad que aísla los servicios y recursos de Cloud Run mediante la configuración de la autorización, los controles de acceso y el intercambio de datos seguro. Este perímetro está diseñado para proteger el contenido entrante, aislar la aplicación mediante la configuración de controles de acceso y supervisión adicionales, y para separar la administración de Google Cloud de la aplicación. Tu administración incluye el registro y la administración de claves.

  • La VPC compartida te permite conectar el conector de Acceso a VPC sin servidores en el proyecto de servicio al proyecto host.

  • Cloud Key Management Service (Cloud KMS) almacena las claves de encriptación administradas por el cliente (CMEK) que usan los servicios de este plano, incluidas las aplicaciones sin servidores, Artifact Registry y Cloud Run.

  • Identity and Access Management (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 privilegio mínimo.

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 servidores en un perímetro de Control de servicios de VPC sin una red de VPC compartida. Puedes implementar esta arquitectura alternativa si usas una topología de concentrador y radio.

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

Una arquitectura alternativa para el plano sin servidores.

En la arquitectura que se muestra en el diagrama anterior, se usa una combinación de servicios y funciones de Google Cloud que es similar a los que se describen en la sección anterior, Arquitectura recomendada: Cloud Run con una VPC compartida..

Estructura de la organización

Agrupas los recursos para que puedas administrarlos y separar los entornos de desarrollo y de pruebas del 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 arranque, común, 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 bases empresariales. Debes implementar los proyectos que el plano especifica en las siguientes carpetas: Common, Production, Non-production y Dev.

La estructura de la organización del plano sin servidores.

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

Carpetas

Usa carpetas para aislar tu entorno de producción y los servicios de administración de tus entornos de prueba y no producción. En la siguiente tabla, se describen las carpetas del plano de las bases empresariales que usa este plano.

Carpeta Descripción
Bootstrap Contiene los recursos necesarios para implementar el plano de las bases empresariales.
Common Contiene servicios centralizados para la organización, como el proyecto de seguridad.
Production Contiene proyectos que tienen recursos en la nube y que se probaron y están listos para que los usen los clientes. En este plano, la carpeta Production contiene el proyecto de servicio y el proyecto host.
Non-production Contiene proyectos que tienen recursos en la nube que están en proceso de prueba y de preparación para el lanzamiento. En este plano, la carpeta Non-production contiene el proyecto de servicio y el proyecto host.
Dev Contiene proyectos que tienen recursos en la nube que están en proceso de desarrollando. En este plano, la carpeta Dev contiene el proyecto de servicio y el proyecto host.

Puedes cambiar los nombres de estas carpetas para que se alineen con la estructura de carpetas de tu organización, pero te recomendamos que mantengas una estructura similar. Para obtener más información, consulta Estructura de la organización. Para otras estructuras de carpetas, consulta Elige una jerarquía de recursos para la zona de destino de Google Cloud.

Proyectos

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

Proyecto Descripción
Proyecto host En este proyecto, se incluyen las reglas de entrada de firewall y cualquier recurso que tenga direcciones IP internas (como se describe en Conéctate a una red de VPC). Cuando usas una VPC compartida, debes designar un proyecto como proyecto host y conectar uno o más proyectos de servicio a él.

Cuando aplicas el código de Terraform, debes especificar el nombre de este proyecto y el plano implementa los servicios.
Proyecto de servicio En este proyecto, se incluyen la aplicación sin servidores, Cloud Run y el conector de Acceso a VPC sin servidores. Debes conectar el proyecto de servicio al proyecto host para que el proyecto de servicio pueda participar en la red de VPC compartida.

Cuando aplicas el código de Terraform, debes especificar el nombre de este proyecto. El plano implementa Cloud Run, Google Cloud Armor, el conector de Acceso a VPC sin servidores y el balanceador de cargas.
Proyecto de seguridad Este proyecto incluye los servicios específicos de seguridad, como Cloud KMS y Secret Manager.

Cuando aplicas el código de Terraform, debes especificar el nombre de este proyecto y el plano implementa Cloud KMS. Si usas el módulo Secure Cloud Run Harness, también se implementa Artifact Registry.

Si implementas este plano después de implementar el plano de bases de seguridad, este es el proyecto de secretos que creó el plano de bases empresariales. Para obtener más información sobre los proyectos de planos de bases empresariales, consulta Proyectos.

Si implementas varias instancias de este plano sin el plano de bases empresariales, cada instancia tiene su propio proyecto de seguridad.

Asigna roles y grupos a proyectos

Debes otorgar a diferentes grupos de usuarios en tu organización acceso a los proyectos que conforman la arquitectura sin servidores. En la siguiente tabla, se describen las recomendaciones del plano para los grupos de usuarios y las asignaciones de roles en los proyectos que creas. Puedes personalizar los grupos para que se adapten a la estructura existente de tu organización, pero te recomendamos que mantengas una división de tareas y una asignación de roles similares.

Grupo Proyecto Funciones
Administrador sin servidores

grp-gcp-serverless-admin@example.com		 Proyecto de servicio
Administrador de seguridad sin servidores

grp-gcp-serverless-security-admin@example.com		 Proyecto de seguridad
Desarrollador de Cloud Run

grp-gcp-secure-cloud-run-developer@example.com		 Proyecto de seguridad
Usuario de Cloud Run

grp-gcp-secure-cloud-run-user@example.com		 Proyecto de servicio

Controles de seguridad

En esta sección, se analizan los controles de seguridad en Google Cloud que se usan para proteger la arquitectura sin servidores. Los principios clave de seguridad que debes considerar son los siguientes:

  • Protege el acceso según el principio de privilegio mínimo, para otorgar a las entidades solo los privilegios necesarios para realizar sus tareas.
  • Protege las conexiones de red a través del diseño de segmentación, las políticas de la organización y las políticas de firewall.
  • Protege la configuración de cada uno de los servicios.
  • Comprende los niveles de riesgo y los requisitos de seguridad para el entorno que aloja tus cargas de trabajo sin servidores.
  • Configura la supervisión y el registro suficientes para permitir la detección, investigación y respuesta.

Controles de seguridad para aplicaciones sin servidores

Puedes ayudar a proteger tus aplicaciones sin servidores mediante controles que protegen el tráfico en la red, controlan el acceso y encriptan los datos.

Compila controles del sistema

Cuando implementas tu aplicación sin servidores, debes usar Artifact Registry para almacenar los objetos binarios y las imágenes de contenedor. Artifact Registry admite CMEK para que puedas encriptar el repositorio mediante tus propias claves de encriptación.

Tráfico SSL

A fin de admitir el tráfico HTTPS a tu aplicación sin servidores, debes configurar un certificado SSL para el balanceador de cargas de aplicaciones externo. De forma predeterminada, usas un certificado autofirmado que puedes cambiar a un certificado administrado después de aplicar el código de Terraform. Para obtener más información sobre la instalación y el uso de certificados administrados, consulta Usa certificados SSL administrados por Google.

Reglas de firewall y red

Las reglas de firewall de la nube privada virtual (VPC) controlan el flujo de datos en los perímetros. Puedes crear reglas de firewall que rechacen todas las salidas, excepto conexiones TCP específicas del puerto 443 de los nombres de dominio especiales de restricted.googleapis.com. Usar el dominio restricted.googleapis.com tiene los siguientes beneficios:

  • Ayuda a reducir la superficie de ataque de la red usando el Acceso privado a Google cuando las cargas de trabajo se comunican con los servicios y las APIs de Google.
  • Garantiza que solo uses servicios que admitan los Controles del servicio de VPC.

Para obtener más información, consulta Configura el Acceso privado a Google.

Controles perimetrales

Como se muestra en el diagrama de arquitectura recomendada, debes colocar los recursos para la aplicación sin servidores en un perímetro separado. Este perímetro ayuda a proteger la aplicación sin servidores del acceso no deseado y el robo de datos.

Política de acceso

Para ayudar a garantizar que solo las identidades específicas (usuarios o servicios) puedan acceder a los recursos y los datos, habilita los grupos y los roles de IAM.

A fin de garantizar que solo recursos específicos puedan acceder a tus proyectos, habilita una política de acceso para 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 un proxy de identidad y acceso (IAP), puedes configurar el balanceador de cargas de aplicaciones externo a fin de usar IAP para autorizar el tráfico para tu aplicación sin servidores. IAP te permite establecer una capa de autorización central para la aplicación sin servidores a fin de que puedas usar los controles de acceso a nivel de la aplicación, en lugar de los firewalls a nivel de red.

A fin de habilitar IAP para tu aplicación, en el archivo loadbalancer.tf, configura iap_config.enable como true.

Para obtener más información sobre IAP, consulta Descripción general de Identity-Aware Proxy.

Cuentas de servicio y controles de acceso

Las cuentas de servicio son identidades que Google Cloud puede usar para ejecutar solicitudes a la API en tu nombre. A fin de implementar la separación de obligaciones, crea cuentas de servicio que tengan roles diferentes para propósitos específicos. Las cuentas de servicio son las siguientes:

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

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

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

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

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

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

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

  • Un agente de servicio para 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 servidores.

  • Una identidad de servicio para Cloud Run (serverless_sa) que tiene el rol roles/artifactregistry.reader. Esta cuenta de servicio proporciona acceso a las claves de encriptación y desencriptación de CMEK y Artifact Registry.

Administración de claves

Usa las claves CMEK para proteger tus datos en Artifact Registry y en Cloud Run. Debes usar las siguientes claves de encriptación:

  • Una clave de software para Artifact Registry que certifica el código para tu aplicación sin servidores.
  • Una clave de encriptación para encriptar las imágenes de contenedor que implementa Cloud Run.

Cuando aplicas la configuración de Terraform, debes especificar 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 de CMEK estén en la misma región que tus recursos. De forma predeterminada, las claves de CMEK se rotan cada 30 días.

Administración de Secrets

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

Cuando implementas este plano con el plano de bases empresariales, debes agregar tus secretos al proyecto de secretos antes de aplicar el código de Terraform. El plano otorgará el rol de usuario con acceso a secretos de Secret Manager a la cuenta de servicio de Cloud Run. Para obtener más información, consulta Usa secretos.

Políticas de la organización

Este plano agrega indicadores a las restricciones de las políticas de la organización. Para obtener más información sobre las restricciones que usa el plano de bases empresarial, consulta las restricciones de las políticas de la organización.

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

Restricción de política Descripción Valor recomendado
constraints/run.allowedIngress Solo permite el tráfico de entrada desde los servicios internos o el balanceador de cargas de aplicaciones externo. internal-and-cloud-load-balancing
constraints/run.allowedVPCEgress Requiere que las revisiones de un servicio de Cloud Run usen un conector de Acceso a VPC sin servidores y asegúrate de que la configuración de salida de VPC de las revisiones se establezca para permitir solo rangos privados. private-ranges-only

Controles operativos

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

  • Supervisar quién accede a tus datos.
  • Asegurarse de que la auditoría sea la correcta.
  • Admitir la capacidad de los equipos de operaciones y administración de incidentes para responder a problemas que puedan ocurrir.

Logging

Para ayudarte a cumplir con los requisitos de auditoría y obtener estadísticas sobre tus proyectos, configura Google Cloud Observability con registros de datos para los servicios de los que deseas realizar un seguimiento. Implementa Cloud Logging en los proyectos antes de aplicar el código de Terraform para asegurarte de que el plano pueda configurar el registro del firewall, el balanceador de cargas y la red de VPC.

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

Para todos los servicios dentro de los proyectos, asegúrate de que tus registros incluyan información sobre operaciones de lectura y escritura de datos, y asegúrate de que incluyan información sobre a qué acceden los administradores. Para obtener más información sobre las prácticas recomendadas de registro, consulta Controles de detección.

Supervisión y alertas

Después de implementar el plano, puedes configurar alertas para notificar a tu centro de operaciones de seguridad (SOC) que puede estar ocurriendo un incidente de seguridad. Por ejemplo, puedes usar alertas para informar a los analistas de seguridad cuando cambie un permiso en un rol de IAM. Para obtener más información sobre cómo configurar alertas de Security Command Center, consulta Configura las notificaciones de hallazgos.

El panel de supervisión de Cloud Run, que forma parte de la biblioteca de paneles de muestra, te proporciona la siguiente información:

  • Recuento de solicitudes
  • Latencia de la solicitud
  • Tiempo de instancia facturable
  • Asignación de CPU del contenedor
  • Asignación de memoria del contenedor
  • Uso de CPU de contenedor
  • Uso de memoria de contenedor

Si deseas obtener instrucciones para importar el panel, consulta Instala paneles de muestra. Para exportar alertas, consulta los siguientes documentos:

Depuración y solución de problemas

Puedes ejecutar pruebas de conectividad para ayudarte a depurar problemas de configuración de red entre Cloud Run y los recursos dentro de tu subred. Las pruebas de conectividad simulan la ruta esperada de un paquete y proporcionan detalles sobre la conectividad, incluido el análisis de conectividad de recurso a recurso.

El código de Terraform no habilita las pruebas de conectividad debes configurarlo por separado. Para obtener más información, consulta Crea y ejecuta pruebas de conectividad.

Controles de detección

En esta sección, se describen los controles de detección que se incluyen en el plano.

Google Cloud Armor y WAF

Usa un balanceador de cargas de aplicaciones externo y Google Cloud Armor para proporcionar protección contra la denegación de servicio distribuido (DSD) para tu aplicación sin servidores. Google Cloud Armor es el firewall de aplicación web (WAF) que se incluye en Google Cloud.

Configura las reglas de Google Cloud Armor que se describen en la siguiente tabla para ayudar a proteger la aplicación sin servidores. Las reglas están diseñadas para ayudar a mitigar los 10 riesgos principales de OWASP.

Nombre de la regla de Google Cloud Armor Nombre de la regla de ModSecurity
Ejecución de código remoto rce-v33-stable
Archivo local incluido lfi-v33-stable
Ataque de protocolo protocolattack-v33-stable
Inclusión de archivos remotos rfi-v33-stable
Detección de escáner scannerdetection-v33-stable
Ataque de fijación de sesión sessionfixation-v33-stable
inyección de SQL sqli-v33-stable
Secuencia de comandos entre sitios xss-v33-stable

Cuando estas reglas están habilitadas, Google Cloud Armor rechaza cualquier tráfico que coincida con la regla de forma automática.

Para obtener más información sobre estas reglas, consulta Ajusta 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 el recomendador. El recomendador puede detectar problemas de seguridad como los siguientes:

  • Contraseñas o claves de API que se almacenan en variables de entorno en lugar de en Secret Manager
  • Contenedores que incluyen credenciales hard-coded en lugar de identidades de servicio.

Alrededor de un día después de que implementes Cloud Run, el recomendador comienza a proporcionar sus resultados y recomendaciones. El recomendador muestra los resultados y las acciones correctivas recomendadas en la lista de servicios de Cloud Run o en el Centro de recomendaciones.

Modos de implementación de Terraform

En la siguiente tabla, se describen las formas en que puedes implementar este plano y qué módulos de Terraform se aplican para cada modo de implementación.

Modo de implementación Módulos de Terraform
Implementa este plano después de implementar el plano de bases empresariales de las bases (recomendado).

Con esta opción, se implementan los recursos para este plano en el mismo perímetro de Controles del servicio de VPC que usa el plano de bases empresariales. Para obtener más información, consulta Cómo personalizar la base v2.3.1 para la implementación sin servidores segura.

En esta opción, también se usa el proyecto de secretos que creaste cuando implementaste el plano de bases empresariales.		 Usa estos módulos de Terraform:
Instala este plano sin instalar el plano de bases empresariales.

Esta opción requiere que crees un perímetro de Controles del servicio de VPC.		 Usa estos módulos de Terraform:

Revisión general

Para implementar la arquitectura que se describe en este documento, haz lo siguiente:

  1. Revisa el archivo readme del plano y asegúrate de cumplir con todos los requisitos.
  2. Crea un certificado SSL para usarlo con el balanceador de cargas de aplicaciones externo.
    Si no completas este paso, el plano usará un certificado autofirmado para implementar el balanceador de cargas y tu navegador mostrará advertencias sobre conexiones no seguras cuando intentes acceder a tu aplicación sin servidores.
  3. En tu entorno de pruebas, implementa el ejemplo de Secure Cloud Run para ver el plano en acción. Como parte de tu proceso de prueba, considera lo siguiente:
    1. Usa Security Command Center para analizar los proyectos en función de los requisitos de cumplimiento comunes.
    2. Reemplaza la aplicación de muestra con una aplicación real y ejecuta una situación de implementación típica.
    3. Trabaja con los equipos de operaciones y de ingeniería de aplicaciones de tu empresa para probar su acceso a los proyectos y verificar si pueden interactuar con la solución de la manera que esperan.
  4. Implementa el plano en tu entorno.

Mapeos de cumplimiento

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

Riesgo Mitigación del plano Tu responsabilidad
1. Inserción de datos de eventos de funciones Google Cloud Armor y los balanceadores de cargas de aplicaciones externos ayudan a proteger contra los 10 riesgos principales de OWASP, como se describe en Las 10 opciones principales de mitigación de 2021 en Google Cloud de OWASP Prácticas de programación segura, como el manejo de excepciones, como se describe en las Prácticas de programación segura de OWASP y los niveles de la cadena de suministro para artefactos de software (SLSA)
2. Autenticación dañada Ninguna IAP y Identity Platform para autenticar usuarios en el servicio
3. Configuración de implementación sin servidores no segura CMEK con Cloud KMS
 Administración de tus propias claves de encriptación
4. Permisos y roles de funciones con privilegios excesivos
  • Cuenta de servicio personalizada para la autenticación de servicio (no la cuenta de servicio predeterminada de Compute Engine)
  • Roles de IAM de alcance estricto en la cuenta de servicio de Cloud Run
  • Controles del servicio de VPC para limitar el alcance del acceso a la API de Google Cloud (como se proporciona en las bases empresariales de Google Cloud).
 Ninguna
5. Supervisión y registro de funciones inadecuados Cloud Logging Paneles de Cloud Monitoring y estructura de alertas
6. Dependencias de terceros no seguras Ninguna Protege la canalización de CI/CD mediante el análisis de código y el análisis previo a la implementación.
7. Almacenamiento no seguro de los secretos de la aplicación Secret Manager Administración de secretos en el código de la aplicación
8. Denegación del servicio y agotamiento de los recursos financieros
  • Google Cloud Armor
  • Tiempos de espera del servicio de Cloud Run (el valor predeterminado es de 120 segundos)
 Ninguna
9. Manipulación de la lógica empresarial sin servidores Controles del servicio de VPC para limitar el alcance del acceso a la API de Google Cloud (proporcionado con el plano de bases empresariales). Ninguna
10. Manejo de excepciones incorrecto y mensajes de error detallados Ninguna Prácticas recomendadas de programación segura
11. Funciones obsoletas, recursos en la nube y activadores de eventos Usa las revisiones para minimizar la superficie de ataque. Las revisiones ayudan a reducir la probabilidad de habilitar de manera accidental una iteración anterior y obsoleta de un servicio. Las revisiones también te ayudan a probar la posición de seguridad de una revisión nueva mediante pruebas A/B junto con las herramientas de supervisión y registro.
  • Infraestructura como código (IaC) para administrar los recursos en la nube
  • Supervisión de recursos en la nube mediante Security Command Center
  • Supervisión de la Facturación de Cloud
  • Limpieza de recursos no usados en la nube para minimizar la superficie de ataque
12. Persistencia de datos entre ejecuciones Ninguna Ninguna

Próximos pasos