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 funciones de Cloud Run (2ª 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 funciones de Cloud Run (este documento)
- Implementa una arquitectura sin servidores con Cloud Run
Las diferencias entre las funciones de Cloud Run y Cloud Run incluyen las siguientes:
- Las funciones de Cloud Run se activan 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.
- Las funciones de Cloud Run se limitan a un conjunto de entornos de ejecución compatibles. Puedes usar Cloud Run con cualquier lenguaje de programación.
- Las funciones de Cloud Run administran 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 las funciones de Cloud Run, consulta Elige una opción de procesamiento de Google Cloud.
Arquitectura
Este modelo usa una arquitectura de VPC compartida, en la que las funciones de Cloud Run se implementan en un proyecto de servicio y pueden 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 Run Functions te permite ejecutar funciones como servicio y administrar la infraestructura en tu nombre. De forma predeterminada, esta arquitectura implementa funciones de Cloud Run 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 las funciones de Cloud Run. 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 funciones de Cloud Run.
- 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 red 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 del 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 las funciones de Cloud Run se comuniquen 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 de host de la VPC compartida o en un proyecto de servicio. De forma predeterminada, este esquema implementa el Acceso a VPC sin servidores en el proyecto host de 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 las funciones 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 aislar tu aplicación y los servicios administrados 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.
El servicio de consumidor es la aplicación en la que actúan las funciones de Cloud Run. 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 las funciones de Cloud Run o en otro proyecto de servicio.
El proxy web seguro está diseñado para proteger el tráfico web de salida, si es necesario. Habilita políticas flexibles y detalladas basadas en identidades en la nube y aplicaciones web. Este modelo 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 las funciones de Cloud Run. 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 las funciones de Cloud Run no requieren 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 modelo, incluidas las funciones de tu aplicación sin servidores, Artifact Registry y Cloud Run.
Secret Manager almacena los secretos de las funciones de Cloud Run. El modelo activa los 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 que usa Cloud Storage
En el siguiente diagrama, se muestra cómo puedes ejecutar una aplicación sin servidores que accede a un servidor interno cuando ocurre un evento en particular en Cloud Storage.
Además de los servicios que se describen 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 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 las funciones de Cloud Run.
- 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 Run 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 debes recopilar registros, agregar datos, etcétera.
Además de los servicios que se describen en Arquitectura, esta arquitectura de ejemplo usa una combinación de los siguientes servicios y funciones de Google Cloud:
- Cloud Scheduler emite eventos de forma periódica.
- Pub/Sub pone en cola los eventos que se usan como entrada y un activador para las funciones de Cloud Run.
- 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 al que la aplicación sin servidores puede acceder. Si implementas el ejemplo de funciones de Secure Cloud Run 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 puedes ejecutar una aplicación sin servidor 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 que se describen 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 funciones de Cloud Run seguras activadas por BigQuery, debes implementar un conjunto de datos y una tabla de BigQuery de muestra.
- Eventarc activa funciones de Cloud Run 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, las funciones de 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 modelo implementa las funciones y los servicios de Cloud Run 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 funciones de Cloud Run, 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 funciones de Cloud Run grp-gcp-secure-cloud-run-developer@example.com |
Proyecto de seguridad | |
| Usuario de las funciones de Cloud Run 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 privilegio mínimo, para otorgar a las principales solo los privilegios necesarios para realizar tareas.
- Protege las conexiones de red a través del diseño de límites de confianza, que incluye la segmentación de red, las políticas de la organización y las políticas de firewall.
- Protege la configuración de cada uno de los servicios.
- Identifica cualquier requisito de cumplimiento o regulatorio para la infraestructura que aloja cargas de trabajo sin servidores y asígnale un nivel de riesgo.
- Configura la supervisión y el registro suficientes para admitir los registros de auditoría de las operaciones de seguridad y la 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, creas un registro DNS para resolver *.googleapis.com en restricted.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 general de una vulneración de sistemas o servicios. Sin embargo, este perímetro de seguridad no se aplica al proceso de compilación de funciones de Cloud Run 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 para usuarios finales individuales. Para implementar el principio de privilegio mínimo y el principio de separación de obligaciones, creas 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 Run 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) - Secret Assessor de Secret Manager (
roles/secretmanager.secretAccessor)
Para obtener más información, consulta Permite que las funciones de Cloud Run accedan a un secreto.
Las funciones de Cloud Run usan esta cuenta de servicio para otorgar permiso solo a temas específicos de Pub/Sub y restringir el sistema de eventos de Eventarc de los recursos de procesamiento de funciones de Cloud Run en la arquitectura de ejemplo con una aplicación sin servidores que usa Cloud Storage y la 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 funciones de Cloud Run (
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 servicio (roles/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 las funciones de Cloud Run (
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 tenga 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 Run Functions, Cloud Storage y Eventarc. Las CMEK te brindan un mayor control sobre tu 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 implementan las funciones de Cloud Run.
- Una clave de encriptación para los eventos de Eventarc que encripta el canal de mensajería 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 secretos
Las funciones de Cloud Run admiten
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 funciones de Cloud Run. 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 Run functions Security de este modelo.
| Restricción de política | Descripción | Valor recomendado |
|---|---|---|
Configuración de entrada permitida (funciones de Cloud Run)
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 (funciones de Cloud Run)
constraints/cloudfunctions.requireVPCConnector |
Exige especificar un conector de Acceso a VPC sin servidores cuando se implemente una función. Cuando se aplique esta restricción, las funciones deberán especificar un conector de Acceso a VPC sin servidores.
El valor predeterminado es |
true
|
Configuración de salida permitida del conector de VPC (funciones de Cloud Run)
cloudfunctions.allowedVpcConnectorEgressSettings |
Requiere que todo el tráfico de salida de las funciones de Cloud Run 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.
- Admitir 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 dentro de los proyectos, asegúrate de que tus registros incluyan información sobre operaciones de escritura de datos y acceso administrativo. 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 modelo, 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 supervisión de funciones de Cloud Run te ayuda a supervisar el rendimiento y el estado de tus funciones de Cloud Run. Proporciona una variedad de métricas y registros que puedes usar para identificar y solucionar problemas. El panel también incluye varias funciones que pueden ayudarte a mejorar el rendimiento de tus funciones, como la capacidad de establecer alertas y cuotas.
Para obtener más información, consulta Supervisa las funciones de Cloud Run.
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 las funciones de 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.
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 Run 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:
|
Reúne todo en un solo lugar
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 tu entorno de pruebas, para ver el modelo en acción, implementa uno de los ejemplos.
Estos ejemplos coinciden con los ejemplos de arquitectura que se describen 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 ejemplo 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 segura sin servidores con Cloud Run.