Desplegar una arquitectura sin servidor segura con Cloud Run Functions

Last reviewed 2023-08-06 UTC

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 functions (2nd gen). 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:

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 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 que se encuentran en otras redes de VPC.

En el siguiente diagrama se muestra una arquitectura de alto nivel, que se describe con más detalle en los ejemplos de arquitecturas que aparecen a continuación.

Arquitectura del blueprint sin servidor con funciones de Cloud Run.

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

  • Cloud Run Functions te permite ejecutar funciones como servicio y gestiona 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 Internet público.
  • El evento de activación es el evento que activa las funciones de Cloud Run. Como se describe 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 de la aplicación de funciones de Cloud Run.
  • VPC compartida te permite conectar un conector de Acceso a VPC sin servidor de tu proyecto de servicio al proyecto host. Despliega 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 gestionar de forma centralizada los recursos de red en una red común y, al mismo tiempo, delegar las responsabilidades administrativas del proyecto de servicio.

  • 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 se expongan a Internet. Acceso a VPC sin servidor permite que las funciones de Cloud Run se comuniquen con otros servicios, sistemas de almacenamiento y recursos que admiten Controles de Servicio de VPC.

    Puedes configurar Acceso a VPC sin servidor en el proyecto host de la VPC compartida o en un proyecto de servicio. De forma predeterminada, esta plantilla implementa el acceso a VPC sin servidor en el proyecto host de la VPC compartida para ajustarse al 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.

  • Controles de Servicio de VPC crea un perímetro de seguridad que aísla tus servicios y recursos de funciones 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 aislar tu aplicación y los servicios gestionados configurando controles de acceso y monitorización adicionales, así como para separar tu gestión de Google Cloud de la aplicación. Tu gobernanza incluye la gestión de claves y el registro.

  • 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 u otro Google Cloud servicio, como Cloud SQL. En función de tu caso de uso, este servicio puede estar detrás de Cloud Next Generation Firewall, en otra subred, en el mismo proyecto de servicio que las funciones de Cloud Run o en otro proyecto de servicio.

  • Proxy web seguro se ha diseñado para proteger el tráfico web de salida, si es necesario. Permite crear políticas flexibles y detalladas basadas en identidades de la nube y aplicaciones web. Este blueprint usa el proxy web seguro para aplicar políticas de acceso granular al tráfico web de salida durante la fase de compilación de las funciones de Cloud Run. El plano añade una lista de URLs permitidas a la regla de política de seguridad de la pasarela.

  • Cloud NAT proporciona una conexión saliente a Internet, si es necesario. Cloud NAT admite la traducción de direcciones de red de origen (SNAT) para recursos de computación 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 necesitan acceder a Internet. Cloud NAT implementa la política de red de salida que está asociada al proxy web seguro.

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

  • Secret Manager almacena los secretos de las funciones de Cloud Run. El blueprint monta secretos como un volumen para proporcionar un nivel de seguridad más alto que si se pasaran como variables de entorno.

  • 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.

  • Cloud Logging recoge todos los registros de los Google Cloud servicios para que tus herramientas de análisis e investigación los almacenen y los recuperen.

  • Cloud Monitoring recoge y almacena información sobre el rendimiento y métricas de los servicios deGoogle Cloud .

Ejemplo de arquitectura con una aplicación sin servidor que usa Cloud Storage

En el siguiente diagrama se muestra cómo puedes ejecutar una aplicación sin servidor que acceda a un servidor interno cuando se produzca un evento concreto en Cloud Storage.

Ejemplo de arquitectura sin servidor con Cloud Storage.

Además de los servicios descritos en la sección Arquitectura, esta arquitectura de ejemplo usa una combinación de los siguientes servicios y funciones: Google Cloud

  • Cloud Storage emite un evento cuando un recurso, una aplicación o un usuario de la nube crea un objeto web en un segmento.
  • Eventarc encamina eventos de diferentes recursos. Eventarc cifra los eventos en tránsito y en reposo.
  • Pub/Sub pone en cola los eventos que se usan como entrada y activador de las funciones de Cloud Run.
  • 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 interno.
  • El servidor interno se ejecuta en Compute Engine o Google Kubernetes Engine y aloja tu aplicación interna. Si despliegas las funciones de Cloud Run seguras con el ejemplo de servidor interno, se desplegará un servidor Apache con una página HTML Hola, mundo. En este ejemplo se simula el acceso a una aplicación interna que ejecuta máquinas virtuales o contenedores.

Arquitectura de ejemplo con Cloud SQL

En el siguiente diagrama se muestra cómo puedes ejecutar una aplicación sin servidor que acceda a un servicio alojado de Cloud SQL a intervalos regulares definidos en Cloud Scheduler. Puedes usar esta arquitectura cuando tengas que recoger registros, agregar datos, etc.

Arquitectura sin servidor de ejemplo con Cloud SQL.

Además de los servicios descritos en la sección Arquitectura, esta arquitectura de ejemplo usa una combinación de los siguientes servicios y funciones: Google Cloud

Arquitectura de ejemplo con un 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, cuando se añaden datos o se crea una tabla).

Ejemplo de arquitectura sin servidor con BigQuery.

Además de los servicios descritos en la sección Arquitectura, esta arquitectura de ejemplo usa una combinación de los siguientes servicios y funciones: Google Cloud

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 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.

La estructura de la organización del plano técnico sin servidor.

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 están listos para que los usen los clientes. 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.
Development Contiene proyectos que tienen recursos en la nube que se están desarrollando. En este blueprint, la carpeta Development contiene el proyecto de servicio y el proyecto 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 de host de VPC compartida

Este proyecto incluye las reglas de entrada del cortafuegos y los recursos que tienen 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á el conector de acceso a la VPC sin servidor, Cloud NAT y Cloud Secure Web Proxy.
Proyecto de servicio de VPC compartida

Este proyecto incluye tu aplicación sin servidor, las funciones de 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 las funciones y los servicios de Cloud Run necesarios para tu caso práctico, como Cloud SQL, Cloud Scheduler, Cloud Storage o BigQuery.

Cuando aplicas el código de Terraform, especificas el nombre de este proyecto y el blueprint implementa Cloud KMS. Si usas el módulo Secure Serverless Harness en el plano técnico sin servidor de las funciones de Cloud Run, también se desplegará Artifact Registry.
Proyecto de seguridad

Este proyecto incluye tus servicios específicos de seguridad, como Cloud KMS y Secret Manager.

El nombre predeterminado del proyecto de seguridad es prj-bu1-p-sec. Si implementas este blueprint después de implementar el blueprint de las bases de seguridad, el proyecto de seguridad se creará además del proyecto de secretos del blueprint de las bases de la empresa (prj-bu1-p-env-secrets). Para obtener más información sobre los proyectos del blueprint de las bases de la empresa, 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
Administrador de seguridad de Serverless
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 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 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:

  • Acceso seguro según el principio de mínimos accesos, que otorga a las entidades solo los privilegios necesarios para realizar tareas.
  • Protege las conexiones de red mediante el diseño de límites de confianza, que incluye la segmentación de la red, las políticas de la organización y las políticas de cortafuegos.
  • Configuración segura para cada uno de los servicios.
  • Identifica los requisitos de cumplimiento o normativos de la infraestructura que aloja cargas de trabajo sin servidor y asigna un nivel de riesgo.
  • Configura una monitorización y un registro suficientes para admitir registros de auditoría de operaciones de seguridad y gestión de incidentes.

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.

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 usando 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.

Además, debes crear un registro DNS para resolver *.googleapis.com en restricted.googleapis.com.

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

Controles perimetrales

Como se muestra en la sección Arquitectura, los recursos de la aplicación sin servidor se colocan en un perímetro de seguridad de Controles de Servicio de VPC independiente. Este perímetro ayuda a reducir el impacto generalizado 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 automáticamente tu código en una imagen de contenedor y envía esa imagen a Artifact Registry. En este caso, crea una regla de entrada para la cuenta de servicio de Cloud Build en el perímetro de servicio.

Política accedida

Para asegurarte de que solo determinadas entidades principales (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.

Cuentas de servicio y controles de acceso

Las cuentas de servicio son cuentas para aplicaciones o cargas de trabajo de computación en lugar de para usuarios finales concretos. Para implementar el principio de los mínimos accesos y el principio de separación de obligaciones, crea cuentas de servicio con permisos específicos y acceso limitado a los recursos. Las cuentas de servicio son las siguientes:

Gestión de claves

Para validar la integridad y proteger tus datos en reposo, puedes usar CMEKs con Artifact Registry, Cloud Run Functions, Cloud Storage y Eventarc. Las CMEKs te ofrecen un mayor control sobre tu clave de cifrado. Se usan las siguientes CMEKs:

  • 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 despliegan las funciones de Cloud Run.
  • Una clave de cifrado para eventos de Eventarc que cifra el canal de mensajería en reposo.
  • Una clave de cifrado para proteger los datos en Cloud Storage.

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 CMEKs estén en la misma región que tus recursos. De forma predeterminada, las CMEKs se rotan cada 30 días.

Gestión de secretos

Cloud Run functions 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 de objeto service_configs en el módulo principal.

Cuando despliegues este blueprint con el blueprint de aspectos básicos de seguridad para empresas, debes añadir tus secretos al proyecto de secretos antes de aplicar el código de Terraform. El blueprint concederá el rol Secret Manager Secret Assessor (roles/secretmanager.secretAccessor) a la cuenta de servicio de Cloud Run Functions. Para obtener más información, consulta Usar secretos.

Políticas de organización

Este plano añade restricciones a las restricciones de las políticas de organización que usa el plano de aspectos básicos de las empresas. 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 las funciones de Cloud Run seguras de este plano.

Restricción basada en las políticas Descripción Valor recomendado
Configuración de entrada permitida (Cloud Run functions) constraints/cloudfunctions.allowedIngressSettings

Permitir el tráfico de entrada solo desde servicios internos o desde el balanceador de carga HTTP(S) externo.

El valor predeterminado es ALLOW_ALL.

 ALLOW_INTERNAL_ONLY
Requiere el conector VPC (funciones de Cloud Run) constraints/cloudfunctions.requireVPCConnector

Requiere especificar un conector de Acceso a VPC sin servidor al desplegar una función. Cuando se aplique esta restricción, las funciones deberán especificar un conector de Acceso a VPC sin servidor.

El valor predeterminado es false.

 true
Configuración de salida del conector de VPC permitida (Cloud Run functions) cloudfunctions.allowedVpcConnectorEgressSettings

Requiere que todo el tráfico de salida de las funciones de Cloud Run utilice un conector de acceso a VPC sin servidor.

El valor predeterminado es PRIVATE_RANGES_ONLY.

 ALL_TRAFFIC

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 el acceso a los datos.
  • Asegúrate de que se realice una auditoría adecuada.
  • Apoyar las operaciones de seguridad y las funciones de gestión de incidentes de tu organización.

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.

Una vez que hayas implementado el blueprint, te recomendamos que configures lo siguiente:

En todos los servicios de los proyectos, asegúrate de que tus registros incluyan información sobre las escrituras de datos y el acceso administrativo. 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 se ha producido un evento 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 Monitorización de funciones de Cloud Run te ayuda a monitorizar el rendimiento y el estado de tus funciones de Cloud Run. Proporciona varias métricas y registros que puedes usar para identificar y solucionar problemas. El panel de control también incluye una serie de funciones que pueden ayudarte a mejorar el rendimiento de tus funciones, como la posibilidad de definir alertas y cuotas.

Para obtener más información, consulta Monitorizar funciones de Cloud Run.

Para exportar alertas, consulta los siguientes documentos:

Depuración y solución de problemas

Puedes ejecutar pruebas de conectividad para depurar problemas de configuración de red entre funciones de 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 debes configurarlas por separado. Para obtener más información, consulta Crear y ejecutar pruebas de conectividad.

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 utiliza el blueprint de bases de la empresa. Para obtener más información, consulta Cómo personalizar Foundation v3.0.0 para la implementación de funciones de Cloud Run seguras.

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:

Instala este plano sin instalar el plano de cimientos de seguridad.

Para usar esta opción, debes crear un perímetro de Controles de Servicio de VPC.

 Usa estos módulos de Terraform:

Resumen

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

  1. Consulta el archivo README del plano para asegurarte de que cumples todos los requisitos previos.
  2. En tu entorno de pruebas, para ver el blueprint en acción, implementa uno de los ejemplos. Estos ejemplos coinciden con los ejemplos de arquitectura descritos en Arquitectura. 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 muestra por una aplicación real (por ejemplo, la 1) y sigue un proceso de implementación 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.
  3. Despliega el proyecto en tu entorno.

Siguientes pasos