Workforce Identity Federation

Con Workforce Identity Federation, los usuarios de tu proveedor de identidades (IdP) externo pueden usar el inicio de sesión único (SSO) para acceder a los Google Cloud recursos.

¿Qué es Workforce Identity Federation?

Workforce Identity Federation te permite usar tu proveedor de identidades externo para autenticar a tus empleados, es decir, a tus usuarios y grupos de usuarios, como empleados, partners y contratistas. Tus usuarios podrán acceder a Google Cloud mediante el inicio de sesión único (SSO) a través de tu proveedor de identidades. Puedes usar políticas de gestión de identidades y accesos (IAM) para autorizar a los usuarios de tu empresa a acceder Google Cloud a los servicios.

Federación frente a sincronización

La federación de identidades de Workforce federa las identidades de tu IdP, por lo que no almacena cuentas de usuario en Google Cloud. Por este motivo, la federación de identidades de los trabajadores no requiere sincronización, lo que significa que no tienes que usar herramientas para sincronizar las identidades de los usuarios de tu IdP con las identidades gestionadas por Google que requieren cuentas de Google. Por ejemplo, si usas la federación de identidades de la fuerza de trabajo, no necesitas usar Google Cloud Directory Sync (GCDS) de Cloud Identity.

Comparación entre Workforce Identity Federation y Workload Identity Federation

La federación de identidades para los trabajadores federa las identidades de los usuarios, mientras que la federación de identidades de cargas de trabajo federa las identidades de las cargas de trabajo.

Para obtener más información, consulta Federación de identidades de carga de trabajo.

Acceso basado en atributos

La federación de identidades para los trabajadores amplía las funciones de identidad de Google Cloudpara admitir el acceso basado en atributos. En algunos proveedores de identidades, los atributos también se conocen como reivindicaciones o afirmaciones.

Una vez que se autentica al usuario, los atributos que se reciben del proveedor de identidades se usan para determinar el ámbito de acceso a los recursos de Google Cloud .

Protocolos admitidos

Puedes usar la federación de identidades de trabajo con cualquier proveedor de identidades que admita OpenID Connect (OIDC) o SAML 2.0, como Microsoft Entra ID, Servicios de federación de Active Directory (AD FS) u Okta, entre otros.

Conceptos clave

En esta sección se describen los conceptos clave de la federación de identidades de Workforce.

Grupos de identidades de Workforce

Los grupos de identidades de empleados te permiten gestionar grupos de identidades de empleados y su acceso a los Google Cloud recursos.

Los grupos te permiten hacer lo siguiente:

  • Agrupar identidades de usuario; por ejemplo, employees o partners
  • Conceder acceso de gestión de identidades y accesos a todo un grupo o a un subconjunto de este.
  • Federar identidades de uno o varios IdPs.
  • Define políticas en un grupo de usuarios que necesitan permisos de acceso similares.
  • Especifique la información de configuración específica del IdP, incluido el mapeado de atributos y las condiciones de atributos.
  • Habilita la CLI de Google Cloud y el acceso a las APIs para identidades de terceros.
  • Registra el acceso de los usuarios de un grupo a los registros de auditoría de Cloud, junto con el ID del grupo.

Puedes crear varias. Para ver un ejemplo que describe uno de estos enfoques, consulta Ejemplo: varios grupos de identidades de Workforce.

Los grupos se configuran a nivel de Google Cloud organización, lo que implica las siguientes consideraciones:

  • Cuando configures por primera vez la federación de identidades de Workforce para tu organización, proporciona un nombre único para el grupo. El nombre debe ser único en todos los grupos de la organización y debe describir claramente las identidades que contiene.
  • Si tienes los permisos de gestión de identidades y accesos adecuados para ver el grupo, se puede hacer referencia a él por su nombre en todos los proyectos y carpetas de la organización.

Proveedores de grupos de identidades de Workforce

Un proveedor de grupos de identidades para el trabajo es una entidad que describe una relación entre tu organización de Google Cloud y tu IdP.

La federación de identidades para los trabajadores sigue la especificación de intercambio de tokens de OAuth 2.0 (RFC 8693). Proporcionas una credencial de tu proveedor de identidades externo al servicio de tokens de seguridad, que verifica la identidad de la credencial y, a cambio, devuelve un token de acceso de corta duración. Google Cloud

Tipos de flujo de OIDC

En el caso de los proveedores de OIDC, la federación de identidades de trabajo admite tanto el flujo de código de autorización como el flujo implícito. Se considera que el flujo de código de autorización es el más seguro, ya que los tokens se devuelven del proveedor de identidades en una transacción de backend segura e independiente, directamente del proveedor de identidades a Google Cloud, después de que los usuarios se autentiquen. Por lo tanto, las transacciones de flujo de código pueden recuperar tokens de cualquier tamaño, por lo que puedes tener más reclamaciones para usarlas en la asignación y las condiciones de atributos. En el flujo implícito, en cambio, el token de ID se devuelve del IdP al navegador. Los tokens están sujetos a los límites de tamaño de las URLs de cada navegador.

Google Cloud Consola de Workforce Identity Federation

Los usuarios de un grupo de identidades de empleados pueden acceder a la Google Cloud consola de Workforce Identity Federation, también conocida como consola (federada). La consola proporciona a estos usuarios acceso a la interfaz de usuario de losGoogle Cloud productos compatibles con la federación de identidades de Workforce.

Compatibilidad con SCIM

Si tu proveedor de identidades admite System for Cross-domain Identity Management (SCIM), puedes configurarlo para aprovisionar y gestionar grupos en Google Cloud.

Los arrendatarios de SCIM de Workforce Identity Federation admiten el uso compartido en Gemini Enterprise. Una vez que hayas configurado los tenants de SCIM en tu aplicación de IdP y en la federación de identidades de Workforce, los usuarios de Gemini Enterprise podrán compartir cuadernos de NotebookLM con un grupo usando el nombre del grupo en lugar de su ID de objeto (UUID). Para obtener más información sobre cómo compartir cuadernos con grupos, consulta Compartir un cuaderno con un grupo.

Cuando usas la compatibilidad con SCIM de la federación de identidades de Workforce, se aplican las siguientes consideraciones:

  • Debes configurar un grupo de identidades y un proveedor de empleados antes de configurar un inquilino de SCIM.
  • Cada grupo de identidades de Workforce solo admite un inquilino de SCIM. Para configurar un nuevo arrendatario de SCIM en el mismo grupo de identidades de la plantilla, primero debes eliminar el que ya tengas. Cuando eliminas un arrendatario de SCIM, tienes dos opciones:
    • Eliminación no definitiva (predeterminada): al eliminar un arrendatario de SCIM, se inicia un periodo de eliminación no definitiva de 30 días. Durante este tiempo, el arrendatario se oculta y no se puede usar, y no puedes crear un nuevo arrendatario de SCIM en el mismo grupo de identidades de empleados.
    • Eliminación definitiva: para eliminar de forma permanente e inmediata un arrendatario de SCIM, usa la marca --hard-delete con el comando de eliminación. Esta acción es irreversible y te permite crear un nuevo arrendatario de SCIM en el mismo grupo de identidades de la plantilla inmediatamente después de que se complete la eliminación.
    También puedes crear un nuevo grupo de identidades de personal y un nuevo cliente de SCIM, o bien usar un grupo de identidades de personal que no se haya configurado previamente con un cliente de SCIM.
  • Cuando usas SCIM, asignas atributos tanto en el proveedor del grupo de identidades de los empleados como en el arrendatario de SCIM. El atributo `google.subject` debe hacer referencia de forma única a las mismas identidades. Para especificar `google.subject` en el proveedor del grupo de identidades de la fuerza de trabajo, usa la marca --attribute-mapping. Para especificarlo en el cliente de SCIM, usa la marca --claim-mapping. Los valores de identidad no únicos que se asignan de esta forma pueden provocar que diferentes identidades de su proveedor de identidades se traten como la misma identidad en Google Cloud. Por lo tanto, el acceso que se concede a una identidad de usuario o de grupo también se puede aplicar a otras identidades, y revocar el acceso de una identidad puede no revocarlo para todas las identidades, lo que hace que algunas identidades sigan teniendo acceso.
  • Para usar SCIM y asignar grupos, define `--scim-usage=enabled-for-groups`. Cuando asignas grupos mediante SCIM, se ignora cualquier asignación de grupos que se defina en el proveedor del grupo de identidades de la fuerza de trabajo. Cuando se hace referencia a grupos gestionados por SCIM, el atributo asignado es `google.group`, no `google.groups`. `google.groups` solo hace referencia a grupos asignados a tokens.
  • Cuando se usa SCIM, los atributos basados en tokens que se asignan con `--attribute-mapping` se pueden seguir usando para la autenticación y en los identificadores principales.
  • Para configurar Microsoft Entra ID, no debes usar las marcas --extended-attributes cuando crees el proveedor del grupo de identidades de Workforce.

Atributos

Tu proveedor de identidades proporciona atributos, a los que algunos proveedores de identidades denominan reclamaciones. Los atributos contienen información sobre sus usuarios. Puede usar estos atributos en asignaciones de atributos y condiciones de atributos.

Asignaciones de atributos

Puedes asignar estos atributos para usarlos con Google Cloud lenguaje de expresión común (CEL).

En esta sección se describe el conjunto de atributos obligatorios y opcionales queGoogle Cloud proporciona.

También puede definir atributos personalizados en su proveedor de identidades que luego puedan usar productos específicos, como las políticas de permiso de gestión de identidades y accesos. Google Cloud

El tamaño máximo de las asignaciones de atributos es de 16 KB. Si el tamaño de las asignaciones de atributos supera el límite de 16 KB, el intento de inicio de sesión fallará.

Los atributos son los siguientes:

  • google.subject (obligatorio): identificador único del usuario que se autentica. Suele ser la aserción del asunto del JWT, ya que los registros de Cloud Audit Logs registran el contenido de este campo como el principal. Puedes usar este campo para configurar la gestión de identidades y accesos para las decisiones de autorización. Te recomendamos que no uses un valor mutable, ya que, si cambias el valor en el directorio de usuarios de tu IdP, el usuario perderá el acceso.

    La longitud máxima es de 127 bytes.

  • google.groups (Opcional): la colección de grupos a los que pertenece el usuario que se autentica. Puede configurar una expresión lógica con un subconjunto de CEL que genere una matriz de cadenas. También puedes usar este campo para configurar la gestión de identidades y accesos en las decisiones de autorización. Las limitaciones de google.groups son las siguientes:

    • Le recomendamos que el nombre del grupo no supere los 40 caracteres.

    • Si un usuario pertenece a más de 400 grupos, se producirá un error al intentar iniciar sesión. Para mitigar este problema, debes definir un conjunto de grupos más pequeño en la aserción y asignar solo los grupos que se usen para federar al usuario en Google Cloud.

    • Si usas este atributo para conceder acceso en Gestión de Identidades y Accesos, se concederá acceso a todos los miembros de los grupos asignados. Por lo tanto, te recomendamos que te asegures de que solo los usuarios autorizados de tu organización puedan modificar la pertenencia a los grupos asignados.

  • google.display_name (Opcional): atributo que se usa para definir el nombre del usuario que ha iniciado sesión en la consola. Google Cloud Este atributo no se puede usar en las políticas de permiso de IAM ni en la condición del atributo.

    La longitud máxima es de 100 bytes.

  • google.profile_photo (Opcional): URL de la miniatura de la foto del usuario. Te recomendamos que la foto sea de 400x400 píxeles. Cuando se define este atributo, la imagen se muestra como imagen de perfil del usuario en la consola de Google Cloud . Si no se define este valor o no se puede obtener, se muestra un icono de usuario genérico. Este atributo no se puede usar en las políticas de permiso de IAM ni en la condición de atributo.

  • google.posix_username (Opcional): una cadena de nombre de usuario única compatible con POSIX que se usa para lo siguiente:

    Este atributo no se puede usar en las políticas de permiso de gestión de identidades y accesos ni en la condición de atributo. La longitud máxima es de 32 caracteres.

  • google.email (Opcional): atributo que se usa para asignar las direcciones de correo de los usuarios federados que han iniciado sesión desde el proveedor de identidades a los productos que integras mediante la integración de clientes de OAuth de Workforce Identity Federation. Este atributo no se puede usar en las políticas de permiso de gestión de identidades y accesos ni en la condición de atributo.

    Por ejemplo, para asignar direcciones de correo de Okta mediante el protocolo OIDC, incluye google.email=assertion.email en tu asignación de atributos.

    Estos son algunos ejemplos de productos que admiten la integración de clientes de OAuth: Google Cloud

  • attribute.KEY (Opcional): un atributo definido por un proveedor de identidades externo que está presente en el token del proveedor de identidades de un usuario. Puedes usar el atributo personalizado para definir tu estrategia de autorización en una política de permiso de gestión de identidades y accesos.

    Por ejemplo, en tu proveedor de identidades, puedes definir un atributo como el centro de costes del usuario como costcenter = "1234" y, a continuación, hacer referencia a la entidad de seguridad de la siguiente manera:

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workforcePools/WORKFORCE_POOL_ID/attribute.costcenter/1234

    Después de conceder acceso a los recursos de Google Cloud a este identificador principal, todas las identidades configuradas en el IdP para que el atributo costcenter tenga el valor 1234 tendrán acceso a los recursos.

    Puede configurar un máximo de 50 reglas de asignación de atributos personalizados. El tamaño máximo de cada regla es de 2048 caracteres.

    Aunque no tenemos restricciones sobre los atributos que puede asignar aquí, le recomendamos que elija atributos cuyos valores sean estables. Por ejemplo, un atributo como attribute.job_description puede cambiar por muchos motivos (como mejorar su legibilidad). Como alternativa, puede usar attribute.role. Los cambios en este último indican un cambio en la responsabilidad asignada y se corresponden con los cambios en el acceso concedido al usuario.

Puedes transformar los valores de los atributos con funciones CEL estándar. También puedes usar las siguientes funciones personalizadas:

  • La función split divide una cadena en función del valor del separador proporcionado. Por ejemplo, para extraer el atributo username de un atributo de dirección de correo dividiendo su valor en @ y usando la primera cadena, utilice la siguiente asignación de atributos: 

    attribute.username=assertion.email.split("@")[0]

  • La función join une una lista de cadenas con el valor del separador proporcionado. Por ejemplo, para rellenar el atributo personalizado department concatenando una lista de cadenas con . como separador, utilice la siguiente asignación de atributos: 

    attribute.department=assertion.department.join(".")

Condiciones de los atributos

Las condiciones de los atributos son expresiones CEL opcionales que te permiten definir restricciones en los atributos de identidad que acepta Google Cloud .

Estas son algunas de las ventajas de usar condiciones de atributo:

  • Puedes usar condiciones de atributos para permitir que solo un subconjunto de identidades externas se autentique en tu Google Cloud proyecto. Por ejemplo, puede que solo quiera permitir que inicien sesión las identidades que pertenezcan a un equipo específico, sobre todo si usa un proveedor de identidades público. Por ejemplo, puede que quieras permitir que el equipo de contabilidad inicie sesión, pero no el de ingeniería.
  • Las condiciones de los atributos le permiten evitar que las credenciales destinadas a usarse con otra plataforma se utilicen con Google Cloudy viceversa. De esta forma, se evita el problema del delegado confuso. #### Condiciones de los atributos para los IdPs multicliente

La federación de identidades de Workforce no mantiene un directorio de cuentas de usuario, sino que implementa identidades basadas en reclamaciones. Por lo tanto, cuando un mismo proveedor de identidades (IdP) emite dos tokens y sus reclamaciones se asignan al mismo valor de google.subject, se da por hecho que los dos tokens identifican al mismo usuario. Para saber qué IdP ha emitido un token, la federación de identidades de Workforce inspecciona y verifica la URL del emisor del token.

Los proveedores de identidades multicliente, como GitHub y Terraform Cloud, usan una sola URL de emisor en todos sus clientes. En el caso de estos proveedores, la URL del emisor identifica a todo GitHub o Terraform Cloud, no a una organización específica de GitHub o Terraform Cloud.

Cuando usas estos proveedores de identidades, no basta con permitir que la federación de identidades de la fuerza de trabajo compruebe la URL del emisor de un token para asegurarse de que procede de una fuente de confianza y de que se puede confiar en sus reclamaciones. Si tu proveedor de identidades multitenant tiene una sola URL de emisor, debes usar condiciones de atributo para asegurarte de que el acceso se restringe al tenant correcto.

Registros de auditoría detallados.

El registro de auditoría detallado es una función de la federación de identidades de Workforce que registra los atributos recibidos de tu proveedor de identidades en los registros de auditoría de Cloud.

Puedes habilitar el registro de auditoría detallado al crear tu proveedor de identidades de la plantilla.

Para saber cómo solucionar errores de asignación de atributos con registros de auditoría detallados, consulta Errores generales de asignación de atributos.

Claves web JSON

El proveedor del grupo de trabajadores puede acceder a las claves web JSON (JWK) que proporciona tu proveedor de identidades en el campo jwks_uri del documento /.well-known/openid-configuration. Si tu proveedor de OIDC no proporciona esta información o tu emisor no es accesible públicamente, puedes subir manualmente los JWKs al crear o actualizar el proveedor de OIDC.

Identificadores principales de Workforce para políticas de gestión de identidades y accesos

En la siguiente tabla se muestran los identificadores principales que puede usar para conceder funciones a usuarios concretos y a grupos de usuarios.

Identidades Formato del identificador
Una sola identidad en un grupo de identidades de Workforce principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
Todas las identidades de los trabajadores de un grupo principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID
Todas las identidades de la plantilla que tengan un valor de atributo específico principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
Todas las identidades de un grupo de identidades de Workforce principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*

Para ver una lista completa de los identificadores principales, consulta Identificadores principales.

Otras cuestiones:

En esta sección se describen otras consideraciones que se deben tener en cuenta al usar la federación de identidades de Workforce.

Restringir el acceso entre organizaciones

Las principales de los grupos de identidades de Workforce no pueden acceder directamente a recursos que no pertenezcan a la organización a la que pertenecen. Sin embargo, si se le da permiso a un principal para actuar en nombre de una cuenta de servicio en la organización, esta restricción se puede eludir, ya que las cuentas de servicio no tienen las mismas restricciones.

Proyecto de usuario de grupos de personal

La mayoría de las APIs Google Cloud cobran el uso de la facturación y las cuotas al proyecto que contiene el recurso al que accede tu solicitud de API. Estas APIs se denominan APIs basadas en recursos. Algunas APIs Google Cloud se cobran al proyecto asociado al cliente. Estas APIs se denominan APIs basadas en el cliente. El proyecto que se usa para la facturación y las cuotas se denomina proyecto de cuota.

Cuando creas un archivo de configuración de federación de identidades de Workforce, especificas un proyecto de usuario de grupos de Workforce. Este proyecto se usa para identificar tu aplicación en las APIs de Google a las que llama. El proyecto de usuario de los grupos de trabajo también se usa como proyecto de cuota predeterminado para las APIs basadas en clientes, a menos que uses la CLI de gcloud para iniciar la solicitud de la API. Debes tener el permiso serviceusage.services.use, que está incluido en el rol de consumidor de uso de servicios (roles/serviceusage.serviceUsageConsumer), en el proyecto que especifiques.

Para obtener más información sobre el proyecto de cuota, las APIs basadas en recursos y las APIs basadas en clientes, consulta el resumen del proyecto de cuota.

Ejemplo: varios grupos de identidades de Workforce

En esta sección se incluye un ejemplo que ilustra el uso habitual de varios grupos.

Puedes crear un grupo para los empleados y otro para los partners. Las organizaciones multinacionales pueden crear grupos independientes para las distintas divisiones de su organización. Los grupos permiten una gestión distribuida, en la que diferentes grupos pueden gestionar de forma independiente su grupo específico, donde los roles solo se conceden a las identidades del grupo.

Por ejemplo, supongamos que una empresa llamada Enterprise Example Organization contrata a otra empresa llamada Partner Example Organization Inc para que le proporcione servicios de DevOps de Google Kubernetes Engine (GKE). Para que la plantilla de Partner Example Organization pueda prestar los servicios, debe tener permiso para acceder a Google Kubernetes Engine (GKE) y a otros Google Cloud recursos de la organización de Enterprise Example Organization. La organización Enterprise Example ya tiene un grupo de identidades de Workforce llamado enterprise-example-organization-employees.

Para permitir que la organización de ejemplo del partner gestione el acceso a los recursos de la organización de ejemplo de la empresa, esta última crea un grupo de empleados independiente para los usuarios de la organización de ejemplo del partner, de modo que esta pueda gestionarlo. La organización de ejemplo de empresa proporciona el grupo de trabajo al administrador de la organización de ejemplo de partner. El administrador de la organización de ejemplo del partner usa su propio proveedor de identidades para conceder acceso a sus empleados.

Para ello, el administrador de la organización de ejemplo Enterprise debe realizar las siguientes tareas:

  1. Crea una identidad, como partner-organization-admin@example.com, para el administrador de la organización de ejemplo del partner en el proveedor de identidades de la organización de ejemplo de la empresa, que ya está configurado en el grupo llamado enterprise-example-organization-employees.

  2. Crea un nuevo grupo de trabajadores llamado example-organization-partner.

  3. Crea la siguiente política de permiso para el grupo example-organization-partner:

    {
  "bindings": [
    {
      "role": "roles/iam.workforcePoolEditor",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/enterprise-example-organization-employees/subject/partner-organization-admin@example.com"
      ]
    }
  ]
}

  4. Otorgar roles para el grupo example-organization-partner en los recursos a los que necesiten acceder en la organización de la empresa de ejemplo.

El administrador de la organización de ejemplo del partner ahora puede configurar el grupo example-organization-partner para conectarse con su proveedor de identidades. De esta forma, podrán permitir que los empleados de la organización de ejemplo del partner inicien sesión con las credenciales del IdP de la organización de ejemplo del partner. Una vez que hayan iniciado sesión, los usuarios de la plantilla de Partner Example Organization podrán acceder a los recursos de Google Cloud , que estarán sujetos a las políticas definidas por Enterprise Example Organization.

Prácticas recomendadas para grupos de seguridad

En las grandes empresas, los administradores de TI suelen crear grupos de seguridad como parte de un modelo de control de acceso basado en prácticas recomendadas. Los grupos de seguridad rigen el acceso a los recursos internos. Además, las empresas suelen crear grupos adicionales para los empleados y otros grupos para los partners con el fin de ampliar este modelo de control de acceso a los recursos en la nube. Esto puede provocar la proliferación de grupos anidados que pueden resultar muy difíciles de gestionar.

Es posible que tu organización también tenga políticas que limiten el número de grupos que puedes crear para que la jerarquía del directorio de usuarios sea razonablemente plana. Una solución mejor para evitar la configuración incorrecta de las políticas de gestión de identidades y accesos y limitar el crecimiento de los grupos es usar varios grupos para separar mejor a los usuarios de diferentes unidades organizativas y unidades de negocio, así como a las organizaciones asociadas. Después, puedes hacer referencia a estos grupos y a los grupos que contengan para definir políticas de gestión de identidades y accesos (consulta ejemplos en el paso Configurar gestión de identidades y accesos).

Limitaciones de Controles de Servicio de VPC

Las funciones administrativas de Workforce Identity Federation, incluidas las APIs de configuración de grupos de empleados y las APIs de Security Token Service, no admiten Controles de Servicio de VPC. Sin embargo,los Google Cloud productos que admiten tanto Federación de Identidades de Workforce como Controles de Servicio de VPC funcionan como se indica en la documentación y están sujetos a las comprobaciones de políticas de Controles de Servicio de VPC. Además, puedes usar identidades de terceros, como usuarios de grupos de trabajadores e identidades de carga de trabajo, en las reglas de entrada o salida de Controles de Servicio de VPC.

Federación de identidades para los trabajadores y contactos esenciales

Para recibir información importante sobre los cambios en tu organización o en tus productos, debes proporcionar contactos esenciales al usar la federación de identidades de la plantilla.Google Cloud Se puede contactar con los usuarios de Cloud Identity a través de su dirección de correo de Cloud Identity, pero con los usuarios de Workforce Identity Federation se contacta mediante Contactos Esenciales.

Cuando uses la consola de Google Cloud para crear o gestionar grupos de identidades de la fuerza de trabajo, verás un banner que te pedirá que configures un contacto esencial con las categorías Legal (Legal) y Suspension (Suspensión). También puedes definir un contacto en la categoría Todos si no tienes contactos independientes. Si proporcionas los contactos, se quitará el banner.

Siguientes pasos