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 Functions (2nd gen). 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:
- Implementa una arquitectura sin servidores con Cloud Functions (este documento)
- Implementa una arquitectura sin servidores con Cloud Run
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 usa una arquitectura de VPC compartida, en la que Cloud Functions se implementa en un proyecto de servicio y puede acceder a los recursos ubicados en otras redes de VPC.
En el siguiente diagrama, se muestra una arquitectura de alto nivel, que se describe con más detalle en las arquitecturas de ejemplo que la siguen.
En la arquitectura que se muestra en el diagrama anterior, se usa una combinación de los siguientes servicios y funciones de Google Cloud:
- Cloud Functions te permite ejecutar funciones como servicio y administrar la infraestructura en tu nombre. De forma predeterminada, esta arquitectura implementa Cloud Functions solo con una dirección IP interna y sin acceso a la Internet pública.
- El evento de activación es el evento que activa Cloud Functions. Como se describe con más detalle en las arquitecturas de ejemplo, puede ser un evento de Cloud Storage, un intervalo programado o un cambio en BigQuery.
- Artifact Registry almacena los contenedores de origen para tu aplicación de Cloud Functions.
- La VPC compartida te permite conectar el conector de Acceso a VPC sin servidores en el proyecto de servicio al proyecto host. Implementas una red de VPC compartida independiente para cada entorno (producción, no producción y desarrollo). Este diseño de herramientas de redes proporciona aislamiento de red entre los diferentes entornos. Una red de VPC compartida te permite administrar de forma centralizada los recursos de red en una red común y, al mismo tiempo, delegar responsabilidades administrativas para el proyecto de servicio.
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 Functions se comunique con otros servicios, sistemas de almacenamiento y recursos que admiten los Controles del servicio de VPC.
Puedes configurar el Acceso a VPC sin servidores en el proyecto host de la VPC compartida o en un proyecto de servicio. De forma predeterminada, este plano implementa el acceso a VPC sin servidores en el proyecto host de la VPC compartida para alinearse con el modelo de VPC compartida de centralización de los recursos de configuración de red. Para obtener más información, consulta la Comparación de los métodos de configuración.
Los Controles del servicio de VPC crean un perímetro de seguridad que aísla los servicios y recursos de Cloud Functions 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 aislar tu aplicación y los servicios administrados mediante la configuración de controles y supervisión de acceso adicionales, y para separar tu administración de Google Cloud de la aplicación. Tu administración incluye el registro y la administración de claves.
El servicio de consumidor es la aplicación en la que actúa Cloud Functions. El servicio de consumidor puede ser un servidor interno o cualquier otro servicio de Google Cloud, como Cloud SQL. Según tu caso de uso, este servicio puede estar detrás del firewall de nueva generación de Cloud, en otra subred, en el mismo proyecto de servicio que Cloud Functions o en otro proyecto de servicio.
El proxy web seguro está diseñado para proteger el tráfico web de salida, si es necesario. Permite políticas flexibles y detalladas basadas en identidades en la nube y aplicaciones web. Este plano usa el proxy web seguro para las políticas de acceso detalladas para salir del tráfico web durante la fase de compilación de Cloud Functions. El plano agrega una lista permitida de URLs a la Regla de política de seguridad de puerta de enlace.
Cloud NAT proporciona conexión saliente a Internet, si es necesario. Cloud NAT es compatible con la traducción de direcciones de red de origen (SNAT) para los recursos de procesamiento sin direcciones IP públicas. Los paquetes de respuesta entrantes usan la traducción de direcciones de red de destino (DNAT). Puedes inhabilitar Cloud NAT si Cloud Functions no requiere acceso a Internet. Cloud NAT implementa la política de red de salida que se adjunta al proxy web seguro.
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 Functions.
Secret Manager almacena los secretos de Cloud Functions. El plano activa secretos como un volumen para proporcionar un nivel de seguridad más alto que pasar secretos como variables de entorno.
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.
Cloud Logging recopila todos los registros de los servicios de Google Cloud para el almacenamiento y la recuperación mediante tus herramientas de investigación y análisis.
Cloud Monitoring recopila y almacena información y métricas de rendimiento sobre los servicios de Google Cloud.
Arquitectura de ejemplo con una aplicación sin servidores mediante Cloud Storage
En el siguiente diagrama, se muestra cómo ejecutar una aplicación sin servidores que accede a un servidor interno cuando se produce un evento en particular en Cloud Storage.
Además de los servicios descritos en Arquitectura, esta arquitectura de ejemplo usa una combinación de los siguientes servicios y funciones de Google Cloud:
- Cloud Storage emite un evento cuando un recurso, aplicación o usuario de nube crea un objeto web en un bucket.
- Eventarc enruta los eventos de diferentes recursos. Eventarc encripta los eventos en tránsito y en reposo.
- Pub/Sub pone en cola los eventos que se usan como entrada y un activador para Cloud Functions.
- 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 interno.
- El servidor interno se ejecuta en Compute Engine o Google Kubernetes Engine y aloja tu aplicación interna. Si implementas el ejemplo de Secure Cloud Functions con el servidor interno, debes implementar un servidor Apache con una página HTML de Hello World. En este ejemplo, se simula el acceso a una aplicación interna que ejecuta VMs o contenedores.
Arquitectura de ejemplo con Cloud SQL
En el siguiente diagrama, se muestra cómo ejecutar una aplicación sin servidores que accede a un servicio alojado de Cloud SQL en un intervalo regular que se define en Cloud Scheduler. Puedes usar esta arquitectura cuando debas recopilar registros, agregar datos, etcétera.
Además de los servicios descritos en Arquitectura, esta arquitectura de ejemplo usa una combinación de los siguientes servicios y funciones de Google Cloud:
- Cloud Scheduler emite eventos con regularidad.
- Pub/Sub pone en cola los eventos que se usan como entrada y un activador para Cloud Functions.
- Las reglas de firewall de la nube privada virtual (VPC) controlan el flujo de datos en la subred que aloja tus recursos, como los datos de la empresa almacenados en Cloud SQL.
- El proxy de autenticación de Cloud SQL controla el acceso a Cloud SQL.
- Cloud SQL aloja un servicio que intercambia tráfico con la red de VPC y a la que la aplicación sin servidores puede acceder. Si implementas el ejemplo de Protege Cloud Functions con Cloud SQL, debes implementar una base de datos de MySQL con una base de datos de muestra.
Arquitectura de ejemplo con el almacén de datos de BigQuery
En el siguiente diagrama, se muestra cómo ejecutar una aplicación sin servidores que se activa cuando se produce un evento en BigQuery (por ejemplo, se agregan datos o se crea una tabla).
Además de los servicios descritos en Arquitectura, esta arquitectura de ejemplo usa una combinación de los siguientes servicios y funciones de Google Cloud:
- BigQuery aloja un almacén de datos. Si implementas el ejemplo de Secure Cloud Functions activado por BigQuery, debes implementar un conjunto de datos y una tabla de BigQuery de muestra.
- Eventarc activa Cloud Functions cuando ocurre un evento en particular en BigQuery.
Estructura de la organizació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.
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. 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. |
Development
|
Contiene proyectos que tienen recursos en la nube que están en proceso de desarrollando. En este plano, la carpeta Development 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 de host de VPC compartida | 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, especificas el nombre de este proyecto y el plano implementa el conector de Acceso a VPC sin servidores, Cloud NAT y el proxy web de Cloud Secure. |
| Proyecto de servicio de VPC compartida | En este proyecto, se incluyen la aplicación sin servidores, Cloud Functions 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 Functions y los servicios necesarios para tu caso de uso, como Cloud SQL, Cloud Scheduler, Cloud Storage o BigQuery. 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 sin servidores en el plano sin servidores para Cloud Functions, también se implementa Artifact Registry. |
| Proyecto de seguridad | Este proyecto incluye los servicios específicos de seguridad, como Cloud KMS y Secret Manager.
El nombre predeterminado del proyecto de seguridad es 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 | Roles |
|---|---|---|
| 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 Functions grp-gcp-secure-cloud-run-developer@example.com |
Proyecto de seguridad | |
| Usuario de Cloud Functions grp-gcp-secure-cloud-run-user@example.com |
Proyecto de servicio de VPC compartida |
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 mínimo privilegio, de modo que los principales solo tengan los privilegios necesarios para realizar tareas.
- Protege las conexiones de red a través del diseño de límite de confianza, que incluye la segmentación de red, políticas de la organización y políticas de firewall.
- Protege la configuración de cada uno de los servicios.
- Identifica los requisitos normativos o de cumplimiento de la infraestructura que aloja las cargas de trabajo sin servidores y asigna un nivel de riesgo.
- Configura la supervisión y el registro suficientes para admitir registros de auditoría de operaciones de seguridad y administración de incidentes.
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.
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.
Además, debes crear un registro DNS para resolver *.googleapis.com en restrict.googleapis.com.
Para obtener más información, consulta Configura el Acceso privado a Google.
Controles perimetrales
Como se muestra en la sección Arquitectura, debes colocar los recursos de la aplicación sin servidores en un perímetro de seguridad de Controles del servicio de VPC independiente. Este perímetro ayuda a reducir el impacto amplio de un compromiso de sistemas o servicios. Sin embargo, este perímetro de seguridad no se aplica al proceso de compilación de Cloud Functions cuando Cloud Build compila tu código de forma automática en una imagen de contenedor y envía esa imagen a Artifact Registry. En esta situación, crea una regla de entrada para la cuenta de servicio de Cloud Build en el perímetro de servicio.
Política de acceso
Para ayudar a garantizar que solo los principales específicos (usuarios o servicios) puedan acceder a los recursos y los datos, habilita los grupos y los roles de IAM.
Para 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.
Cuentas de servicio y controles de acceso
Las cuentas de servicio son cuentas para aplicaciones o cargas de trabajo de procesamiento, en lugar de cuentas de usuarios finales individuales. Para implementar el principio de mínimo privilegio y de separación de obligaciones, crea cuentas de servicio con permisos detallados y acceso limitado a los recursos. Las cuentas de servicio son las siguientes:
Una cuenta de servicio de Cloud Functions (
cloudfunction_sa) que tiene los siguientes roles:- Visualizador de la red de Compute (
roles/compute.networkViewer) - Receptor de eventos de Eventarc (
roles/eventarc.eventReceiver) - Invocador de Cloud Run (
roles/run.invoker) - Evaluador de Secrets de Secret Manager (
roles/secretmanager.secretAccessor)
Para obtener más información, consulta Permite que Cloud Functions acceda a un secreto.
Cloud Functions usa esta cuenta de servicio para otorgar permiso solo a temas específicos de Pub/Sub y restringir el sistema de eventos de Eventarc desde los recursos de procesamiento de Cloud Functions en Arquitectura de ejemplo con una aplicación sin servidores. Usa Cloud Storage y Arquitectura de ejemplo con el almacén de datos de BigQuery.
- Visualizador de la red de Compute (
Una cuenta de conector de Acceso a VPC sin servidores (
gcp_sa_vpcaccess) que tiene el rol de Usuario de la red de Compute (roles/compute.networkUser).Una segunda cuenta de conector de Acceso a VPC sin servidores (
cloud_services) que tiene el rol de usuario de la red de Compute (roles/compute.networkUser).Estas cuentas de servicio del conector de Acceso a VPC sin servidores son necesarias para 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 Functions
cloudfunction_sa) que tenga los roles de usuario de Acceso a VPC sin servidores (roles/vpcaccess.user)](/iam/docs/understanding-roles#vpcaccess.user)) y Usuario de la cuenta de servicioroles/iam.serviceAccountUser)..Una cuenta de servicio para las APIs de Google (
cloud_services_sa) que tenga el rol de usuario de red de Compute (roles/compute.networkUser) para ejecutar procesos internos de Google en tu nombre.Una identidad de servicio para Cloud Functions (
cloud_serverless_sa) que tiene el rol de lector de Artifact Registry (roles/artifactregistry.reader). Esta cuenta de servicio proporciona acceso a Artifact Registry y CMEK.Una identidad de servicio para Eventarc (
eventarc_sa) que tiene los roles de desencriptador de CryptoKey de Cloud KMS (roles/cloudkms.cryptoKeyDecrypter) y encriptador de CryptoKey de Cloud KMS (roles/cloudkms.cryptoKeyEncrypter).Una identidad de servicio para Artifact Registry (
artifact_sa) con los roles de desencriptador de CryptoKey (roles/cloudkms.cryptoKeyDecrypter) y encriptador de CryptoKey de Cloud KMS (roles/cloudkms.cryptoKeyEncrypter).
Administración de claves
Para validar la integridad y ayudar a proteger los datos en reposo, usa CMEK con Artifact Registry, Cloud Functions, Cloud Storage y Eventarc. Las CMEK te proporcionan un mayor control sobre la clave de encriptación. Se usan las siguientes CMEK:
- 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 Functions.
- Una clave de encriptación para los eventos de Eventarc que encripta el canal de mensajes en reposo.
- Una clave de encriptación para ayudar a proteger los datos en Cloud Storage.
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 CMEK estén en la misma región que tus recursos. De forma predeterminada, las CMEK se rotan cada 30 días.
Administración de Secrets
Cloud Functions 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 de objeto service_configs y 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 evaluador de secretos de Secret Manager (roles/secretmanager.secretAccessor) a la cuenta de servicio de Cloud Functions. Para obtener más información, consulta Usa secretos.
Políticas de la organización
Este plano agrega restricciones a las restricciones de la política de la organización que usa el plano de bases empresariales. 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 Functions Security de este plano.
| Restricción de política | Descripción | Valor recomendado |
|---|---|---|
Configuración de entrada permitida (Cloud Functions)
constraints/cloudfunctions.allowedIngressSettings |
Permite el tráfico de entrada solo desde los servicios internos o el balanceador de cargas HTTP(S) externo.
El valor predeterminado es |
ALLOW_INTERNAL_ONLY
|
Exigir conector de VPC (Cloud Functions)
constraints/cloudfunctions.requireVPCConnector |
Requiere especificar un conector de acceso a VPC sin servidores cuando se implementa una función. Cuando se aplica esta restricción, las funciones deben especificar un conector de Acceso a VPC sin servidores.
El valor predeterminado es |
true
|
Configuración de salida permitida del conector de VPC (Cloud Functions)
cloudfunctions.allowedVpcConnectorEgressSettings |
Requiere que todo el tráfico de salida para que Cloud Functions use un conector de Acceso a VPC sin servidores. El valor predeterminado es |
ALL_TRAFFIC
|
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:
- Supervisa el acceso a los datos.
- Asegurarse de que la auditoría sea la correcta.
- Admite las operaciones de seguridad y las capacidades de administración de incidentes de tu organización.
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:
- Crea un receptor de registros agregado en todos los proyectos.
- Agrega CMEKs al receptor de registros.
Para todos los servicios de los proyectos, asegúrate de que los registros incluyan información sobre las escrituras de datos y el acceso de administrador. 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 se produjo un evento 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 Cloud Functions Monitoring te ayuda a supervisar el rendimiento y el estado de tus Cloud Functions. Proporciona una variedad de métricas y registros, que puedes usar para identificar y solucionar problemas. En el panel, también se incluyen una serie de funciones que pueden ayudarte a mejorar el rendimiento de las funciones, como la capacidad de configurar alertas y cuotas.
Para obtener más información, consulta Supervisa las extensiones de Cloud Functions.
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 Functions 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.
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 Foundation v3.0.0 para la implementación segura de Cloud Functions. 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 de seguridad. 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:
- Revisa el archivo readme del plano y asegúrate de cumplir con todos los requisitos.
- En el entorno de pruebas, para ver el plano en acción, implementa uno de los ejemplos.
Estos ejemplos coinciden con los ejemplos de arquitectura descritos en Arquitectura.
Como parte de tu proceso de prueba, considera lo siguiente:
- Usa Security Command Center para analizar los proyectos en función de los requisitos de cumplimiento comunes.
- Reemplaza la aplicación de muestra por una aplicación real (por ejemplo, 1) y ejecuta una situación de implementación típica.
- 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.
- Implementa el plano en tu entorno.
¿Qué sigue?
- Revisa el plano de bases empresariales de Google Cloud para obtener un entorno seguro de referencia.
- Para ver los detalles del plano, lee el archivo README de configuración de Terraform.
- Para implementar una aplicación sin servidores con Cloud Run, consulta Implementa una arquitectura sin servidores segura con Cloud Run.