Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Configura el acceso adaptado al contexto con Identity-Aware Proxy

En esta guía se describe cómo extender las políticas de acceso de Identity-Aware Proxy (IAP) mediante niveles de acceso y el framework de las Condiciones de la administración de identidades y accesos (IAM). Los niveles de acceso permiten restringir el acceso a los recursos según la dirección IP y los atributos del dispositivo del usuario final. Las condiciones de IAM permiten restringir el acceso según las rutas de acceso y los hosts de URL, así como la fecha y hora.

Por ejemplo, según la configuración de la política, tu aplicación sensible puede realizar estas acciones:

Otorgar acceso a todos los empleados si usan un dispositivo corporativo de confianza de tu red corporativa
Otorgar acceso a los empleados que estén en el grupo Acceso remoto si utilizan un dispositivo empresarial de confianza con una contraseña segura y un parche actualizado desde cualquier red
Otorgar acceso solo a los empleados del grupo Acceso privilegiado si la ruta de URL comienza con /admin

Antes de comenzar

Necesitarás lo siguiente antes de comenzar:

Una aplicación protegida con IAP a la que deseas agregar acceso individual o grupal
Nombres de usuarios o grupos a los que deseas otorgar acceso

Configura un nivel de acceso

Para limitar el acceso según la dirección IP o los atributos del dispositivo del usuario final, crea un nivel de acceso. Algunos atributos, como los de dispositivo, requieren una licencia de Chrome Enterprise Premium. La validación de la licencia solo se produce cuando configuras los niveles de acceso y no afecta el acceso durante el tiempo de ejecución. Para aprender a crear un nivel de acceso, consulta la guía de Access Context Manager. IAP usa el nombre del nivel de acceso para asociarlo con una app protegida por IAP.

IAP no admite el uso de políticas con alcance. Los niveles de acceso se deben establecer en la política de acceso de la organización. Para obtener más información, consulta Crea una política de acceso.

Edita la política de IAM

Una aplicación protegida con IAP tiene una política de IAM que vincula la función IAP a la aplicación.

Si agregas una vinculación condicional de IAM a la política de IAM, el acceso a tus recursos se restringe aún más según los atributos de la solicitud. Estos incluyen lo siguiente:

Niveles de acceso
Ruta de acceso/host de URL
Fecha/hora

Ten en cuenta que deben ser exactos los valores de solicitud que se comparen con request.host y request.path especificados en una vinculación condicional de IAM. Por ejemplo, si restringes el acceso a rutas de acceso que empiezan con /internal admin, es posible evitar la restricción si se accede a /internal%20admin. Para obtener más información sobre las condiciones de nombre de host y ruta de acceso, consulta Usa condiciones de nombre de host y ruta de acceso.

Agrega y edita vinculaciones condicionales en tu política de IAM mediante el proceso que se describe a continuación.

Console

Para agregar una vinculación condicional con la consola de Google Cloud , sigue estos pasos:

Ve a la página de administrador de IAP.
Ir a la página Administración de IAP
Selecciona la casilla de verificación junto a los recursos para los que deseas actualizar los permisos de IAM.
En el panel de información a la derecha, haz clic en Agregar principal.
En el cuadro Principales nuevas, ingresa las principales a las que deseas asignar un rol.
En la lista desplegable Seleccionar un rol, elige el rol Usuario de aplicación web protegida con IAP y especifica las condiciones del nivel de acceso que las principales deberán cumplir para acceder al recurso.
- Para especificar los niveles de acceso existentes, selecciónalos en la lista desplegable Niveles de acceso. Debes seleccionar la función Usuario de aplicación web protegida con IAP y tener permisos de nivel de organización para ver los niveles de acceso existentes. Se te deben otorgar algunas de las siguientes funciones:
  - Administrador de Access Context Manager
  - Editor de Access Context Manager
  - Lector de Access Context Manager
- Para crear y administrar los niveles de acceso, usa Access Context Manager.
Si quieres agregar más roles a las principales, haz clic en Agregar otro rol.
Cuando hayas agregado todas las funciones que necesitas, haz clic en Guardar.

Acabas de agregar una vinculación condicional a tu recurso.

Para quitarla, sigue estos pasos:

Ve a la página de administrador de IAP.
Ir a la página Administración de IAP
Selecciona la casilla de verificación junto al recurso del que deseas quitar el rol de IAM de una principal.
En el Panel de información del lado derecho, en Rol / principal, haz clic en el rol que deseas quitar de la principal.
Haz clic en Quitar junto a la principal.
En el cuadro de diálogo ¿Quieres quitar el rol del principal? que aparece, haz clic en Quitar. Para quitar todos los roles no heredados de la principal en el recurso seleccionado, marca la casilla de verificación antes de hacer clic en Quitar.

gcloud

Por ahora, solo puedes usar la herramienta gcloud para establecer vinculaciones condicionales a nivel de proyecto.

Para establecer vinculaciones condicionales, edita el archivo policy.yaml de tu proyecto mediante el siguiente proceso:

Abre la política de IAM de la aplicación con el siguiente comando de gcloud:
```
gcloud iap web get-iam-policy --project=PROJECT_ID > policy.yaml
```
Edita el archivo policy.yaml para especificar lo siguiente:
- Los usuarios y los grupos a los que deseas aplicar la condición de IAM
- La función iap.httpsResourceAccessor para otorgarles acceso a los recursos
- La condición de IAM.
  
  En el siguiente fragmento, se muestra una condición de IAM con solo un atributo especificado. Esta condición otorga acceso al usuario y al grupo si se cumple con los requisitos de nivel de acceso ACCESS_LEVEL_NAME y la ruta de la URL del recurso comienza con /.
```
bindings:
...
  - members:
    - group:EXAMPLE_GROUP@GOOGLE.COM
    - user:EXAMPLE_USER@GOOGLE.COM
    role: roles/iap.httpsResourceAccessor
    condition:
              expression: "accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in
                          request.auth.access_levels && request.path.startsWith("/")
              title: CONDITION_TITLE
...
```
Vincula la política a la aplicación con el comando set-iam-policy.
```
gcloud iap web set-iam-policy --project=PROJECT_ID policy.yaml
```

Tu política de IAM ahora incluye una vinculación condicional.

API

A fin de editar el archivo policy.json de tu aplicación, sigue el proceso que se muestra a continuación para tu tipo de aplicación. Consulta Administra el acceso a los recursos protegidos por IAP a fin de obtener más información sobre cómo usar la API de IAM para administrar las políticas de acceso.

Antes de realizar los pasos de la API específicos de la aplicación que se indican a continuación, exporta las siguientes variables:

 export PROJECT_NUM=PROJECT_NUMBER
 export IAP_BASE_URL=https://iap.googleapis.com/v1/projects/${PROJECT_NUM}/iap_web
 # Replace POLICY_FILE.JSON with the name of JSON file to use for setIamPolicy
 export JSON_NEW_POLICY=POLICY_FILE.JSON

### App Engine

 1. Export the following App Engine variables:
 <pre class="devsite-click-to-copy prettyprint lang-html" suppresswarning="suppresswarning">
 \# The APP_ID is usually the project ID
 export GAE_APP_ID=<var>APP_ID</var>
 export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}</pre>

 1. Get the IAM policy for the App Engine app using the `getIamPolicy` method. The empty data bit at the end turns the `curl` request into POST instead of GET.

curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \\
    ${GAE_BASE_URL}/:getIamPolicy -d ''

1. Agrega tu vinculación condicional de IAM al archivo JSON de la política de IAM. A continuación, se muestra un ejemplo de un archivo `policy.json` editado que vincula el rol `iap.httpsResourceAccessor` a dos usuarios, lo que les otorga acceso a los recursos protegidos por IAP. Se agregó una condición de IAM para otorgarles acceso a los recursos solo si se cumple el requisito del nivel de acceso ACCESS_LEVEL_NAME y la ruta de URL del recurso comienza con "/". Cada vinculación puede tener solo una condición.

**Ejemplo de archivo policy.json**

{
"policy": {
  "bindings": [
        {
          "role": "roles/iap.httpsResourceAccessor",
          "members": [
              "group:EXAMPLE_GROUP@GOOGLE.COM",
              "user:EXAMPLE_USER@GOOGLE.COM"
          ],
          "condition": {
            "expression": "\"accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME\" in request.auth.access_levels && request.path.startsWith(\"/\")",
            "title": "CONDITION_NAME"
          }
        }
        ]
  }
}

1. Establece tu nuevo archivo `policy.json` con el método `setIamPolicy`.

 curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \\
     ${GAE_BASE_URL}:setIamPolicy -d @${JSON_NEW_POLICY}

#### Servicios y versiones de App Engine

 You can also update the IAM policy of a App Engine
 service, all versions, or a specific version of a service. To do this for a specific version of a service:

 1. Export the following additional variables.

    export GAE_SERVICE=SERVICE_NAME
    export GAE_VERSION=VERSION_NAME

1. Actualiza la variable GAE_BASE_URL exportada.

export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}/services/${GAE_SERVICE}/versions/${GAE_VERSION}

1. Obtén y establece la política de IAM para la versión con los comandos getIamPolicy y setIamPolicy que se muestran más arriba.

### GKE y Compute Engine

1. Exporta el ID del proyecto de tu servicio de backend.

     export BACKEND_SERVICE_NAME=BACKEND_SERVICE_NAME

 2. Get the IAM policy for the Compute Engine app using the `getIamPolicy` method. The empty data bit at the end turns the `curl` request into POST instead of GET.
 <pre class="devsite-click-to-copy prettyprint lang-html" suppresswarning="suppresswarning">
 curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \\
     ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:getIamPolicy \\
     -d ''</pre>
 3. Add your IAM conditional binding to the IAM policy JSON file.
    The following is an example of an edited `policy.json` file that binds the
    `iap.httpsResourceAccessor` role to two users, granting them access to the IAP-secured resources. An IAM
    condition has been added to grant them access to the resources only if the <var>ACCESS_LEVEL_NAME</var> access level requirement is met and the resource URL path starts with `/`.
    Each binding can have only one condition.

    <br/>**Example policy.json file**

{
  "policy": {
    "bindings": [
      {
        "role": "roles/iap.httpsResourceAccessor",
        "members": [
          "group:EXAMPLE_GROUP@GOOGLE.COM",
          "user:EXAMPLE_USER@GOOGLE.COM"
        ],
        "condition": {
          "expression": "\"accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME\" in request.auth.access_levels && request.path.startsWith(\"/\")",
          "title": "CONDITION_NAME"
        }
      }
    ]
  }
}

4. Establece tu nuevo archivo `policy.json` con el método `setIamPolicy`.

     curl -i -H "Content-Type:application/json" \\
             -H "Authentication: Bearer $(gcloud auth print-access-token)" \\
             ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:setIamPolicy \\
             -d @${JSON_NEW_POLICY}

Usa condiciones de nombre de host y ruta de acceso

El acceso a tu aplicación se puede proteger con el nombre de host y la ruta de acceso de una URL de solicitud. Por ejemplo, la condición de IAM request.path.startsWith se puede usar para otorgar acceso solo a los empleados del grupo Acceso con privilegios si la ruta de URL comienza con /admin.

Para obtener más información sobre cómo usar las condiciones de nombre de host y ruta de acceso, consulta los atributos de solicitud.

Normalización de strings

Una URL tiene un nombre de host y una ruta de acceso. Por ejemplo, la URL https://sheets.google.com/create?query=param tiene como nombre de host sheets.google.com y como ruta de acceso /create.

Los backends pueden interpretar nombres de host y rutas de acceso de diferentes maneras. Para evitar la ambigüedad, IAP normaliza las strings de ruta de acceso y nombre de host mediante la comprobación de las políticas.

IAP realiza dos verificaciones de la política cuando una solicitud tiene una ruta de acceso no normalizada. Si la ruta no normalizada supera la verificación de la política, IAP normaliza la ruta de acceso y se realiza una segunda verificación de la política. El acceso se otorga si las rutas normalizadas y no normalizadas pasan la verificación de la política.

Por ejemplo, si una solicitud tiene la ruta de acceso /internal;some_param/admin, IAP primero realiza una verificación de política en la ruta no normalizada (/internal). Si eso sucede, IAP realiza una segunda verificación de la política en la ruta normalizada (/internal/admin).

Nombres de host

Los nombres de host se normalizan de la siguiente manera:

Eliminación de puntos finales
Caracteres en minúscula
Conversión a ASCII

Los nombres de host que incluyen caracteres que no son ASCII tienen una normalización adicional con punycoding. Debes usar punycode en la string de nombre de host para que se realice una coincidencia.

Para usar punycode en tu string de nombre de host, usa un conversor, como Punycoder.

Los siguientes son ejemplos de nombres de host normalizados:

FOO.com se normaliza en foo.com
café.fr se normaliza en xn--caf-dma.fr

Rutas de acceso

Las rutas se normalizan de la siguiente manera:

Eliminación de parámetros de ruta de acceso
Cómo resolver rutas de acceso relativas a su equivalente absoluto

Un parámetro de ruta de acceso incluye todos los caracteres desde un ; hasta el siguiente / o el final de la ruta.

Las solicitudes que contienen ..; al comienzo de una sección de ruta se consideran no válidas. Por ejemplo, /..;bar/ y /bar/..;/ muestran el error HTTP 400: Bad Request.

Los siguientes son ejemplos de rutas de acceso normalizadas:

/internal;some_param/admin se normaliza en /internal/admin
/a/../b se normaliza en /b
/bar;param1/baz;baz;param2 se normaliza en /bar/baz

Terminaciones de subdominios

Una política establecida con request.host.endsWith("google.com") coincidirá tanto con sub_domain.google.com como con testgoogle.com. Si tu objetivo es limitar tu política a todos los subdominios que terminan con google.com, establece la política en request.host.endsWith(".google.com").

Ten en cuenta que cuando configuras tu política en request.host.endsWith(".google.com") coincidirá con sub_domain.google.com, pero no coincidirá con google.com debido a . adicional.

Registros de auditoría de Cloud y niveles de acceso

Habilitar los Registros de auditoría de Cloud para tu proyecto protegido por IAP te permite ver las solicitudes de acceso autorizadas y no autorizadas. Para ver las solicitudes y todos los niveles de acceso que cumplió un solicitante, completa los siguientes pasos:

Ve al Explorador de registros de la consola de Google Cloud para tu proyecto.
Ir a la página Registros
En la lista desplegable del selector de recursos, selecciona un recurso. Los recursos HTTPS protegidos por IAP se encuentran en Aplicación de App Engine y Servicio de backend de Compute Engine. Los recursos de SSH y TCP protegidos por IAP se encuentran en Instancia de VM de Compute Engine .
En la lista desplegable tipo de registros, selecciona data_access.
- El tipo de registro data_access solo aparece si hubo tráfico a tu recurso después de habilitar los Registros de auditoría de Cloud para IAP.
Haz clic para ampliar la fecha y la hora del acceso que deseas revisar.
- El acceso autorizado tiene un ícono i de color azul.
- El acceso no autorizado tiene un ícono !! de color naranja.
A fin de ver los niveles de acceso que obtuvo el solicitante, haz clic para expandir las secciones hasta llegar a protoPayload > requestMetadata > requestAttributes > auth > accessLevels.

Ten en cuenta que todos los niveles de acceso con los que cumple un usuario son visibles cuando se ve una solicitud, incluidos los niveles de acceso que no se solicitaron para acceder a ella. Ver una solicitud no autorizada no indica cuáles son los niveles de acceso con los no se cumplieron. Esto último se determina mediante la comparación de las condiciones del recurso con los niveles de acceso visibles en la solicitud.

Consulta la guía de Registros de auditoría de Cloud para obtener más información sobre los registros.

Configura el acceso adaptado al contexto con Identity-Aware Proxy Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.