Esta página se ha traducido con Cloud Translation API.

Configurar el acceso contextual con Identity-Aware Proxy

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

Por ejemplo, en función de la configuración de la política, tu aplicación sensible puede hacer lo siguiente:

Concede acceso a todos los empleados si utilizan un dispositivo corporativo de confianza desde tu red corporativa.
Concede acceso a los empleados del grupo Acceso remoto si utilizan un dispositivo corporativo de confianza con una contraseña segura y un nivel de parche actualizado, desde cualquier red.
Solo concede acceso a los empleados del grupo Acceso privilegiado si la ruta de la URL empieza por /admin.

Antes de empezar

Antes de empezar, necesitarás lo siguiente:

Una aplicación protegida por compras en la aplicación a la que quieras añadir acceso individual o de grupo.
Nombres de usuarios o grupos a los que quieras conceder acceso.

Configurar un nivel de acceso

Para limitar el acceso en función de la dirección IP o de los atributos del dispositivo del usuario final, debes crear un nivel de acceso. Para saber cómo crear un nivel de acceso, consulta la guía del Administrador de contextos de acceso. IAP usa el nombre del nivel de acceso para asociarlo a una aplicación protegida mediante IAP.

IAP no admite el uso de políticas con ámbito. Los niveles de acceso deben definirse en la política de acceso de la organización. Para obtener más información, consulta el artículo Crear una política de acceso.

Editar la política de gestión de identidades y accesos

Una aplicación protegida mediante IAP tiene una política de gestión de identidades y accesos que vincula el rol de IAP a la aplicación.

Si añades un enlace condicional de gestión de identidades y accesos (IAM) a la política de IAM, el acceso a tus recursos se restringirá aún más en función de los atributos de la solicitud. Estos atributos de solicitud incluyen lo siguiente:

Niveles de acceso
Host o ruta de URL
Fecha/hora

Ten en cuenta que los valores de solicitud que se comparan con request.host y request.path especificados en una vinculación condicional de IAM deben ser exactos. Por ejemplo, si restringes el acceso a las rutas que empiezan por /internal admin, se puede eludir la restricción si se va a /internal%20admin. Para obtener más información sobre las condiciones de nombre de host y ruta, consulta el artículo Usar condiciones de nombre de host y ruta.

Añade y edita enlaces condicionales en tu política de gestión de identidades y accesos siguiendo el proceso que se indica a continuación.

Consola

Para añadir un enlace condicional mediante la consola, sigue estos pasos: Google Cloud

Ve a la página de administración de IAP.
Ir a la página de administración de IAP
Seleccione la casilla situada junto a los recursos cuyos permisos de gestión de identidades y accesos quiera actualizar.
En el panel de información de la derecha, haz clic en Añadir principal.
En el cuadro Nuevo principal, introduce los principales a los que quieras asignar un rol.
En la lista desplegable Seleccionar un rol, selecciona el rol Usuario de aplicación web protegida por IAP y especifica las condiciones de nivel de acceso que deberán cumplir las principales para acceder al recurso.
- Para especificar los niveles de acceso, selecciónalos en la lista desplegable Niveles de acceso. Debes seleccionar el rol Usuario de aplicaciones web protegidas mediante IAP y tener permisos a nivel de organización para ver los niveles de acceso que ya existen. Debes tener concedido uno de los siguientes roles:
  - Administrador de contextos de acceso
  - Editor del administrador de contextos de acceso
  - Lector del administrador de contextos de acceso
- Para crear y gestionar niveles de acceso, usa el Administrador de contextos de acceso.
Si quieres añadir más roles a las entidades, haz clic en Añadir otro rol.
Cuando termines de añadir roles, haz clic en Guardar.

Ahora has añadido un enlace condicional a tu recurso.

Para eliminar un enlace condicional, siga estos pasos:

Ve a la página de administración de IAP.
Ir a la página de administrador de IAP
Seleccione la casilla situada junto al recurso del que quiera quitar el rol de gestión de identidades y accesos de un principal.
En el panel de información de la derecha, en Rol o principal, haz clic en el rol que quieras quitar del principal.
Haga clic en Quitar junto al principal.
En el cuadro de diálogo Quitar rol del principal que aparece, haz clic en Quitar. Para quitar todos los roles no heredados del principal en el recurso seleccionado, marca la casilla antes de hacer clic en Quitar.

gcloud

Por el momento, solo puedes usar la herramienta gcloud para definir enlaces condicionales a nivel de proyecto.

Para definir enlaces condicionales, edita el archivo policy.yaml de tu proyecto siguiendo el proceso que se indica a continuación:

Abre la política de IAM de la aplicación con el siguiente comando gcloud:
```
gcloud iap web get-iam-policy --project=PROJECT_ID > policy.yaml
```
Edita el archivo policy.yaml para especificar lo siguiente:
- Los usuarios y grupos a los que quieras aplicar la condición de IAM.
- El rol iap.httpsResourceAccessor para concederles acceso a los recursos.
- La condición de gestión de identidades y accesos.
  
  En el siguiente fragmento se muestra una condición de IAM con un solo atributo especificado. Esta condición concede acceso al usuario y al grupo si se cumplen los requisitos del nivel de acceso ACCESS_LEVEL_NAME y la ruta de la URL del recurso empieza por /.
```
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 mediante el comando set-iam-policy.
```
gcloud iap web set-iam-policy --project=PROJECT_ID policy.yaml
```

Tu política de gestión de identidades y accesos ahora incluye una vinculación condicional.

API

Para editar el archivo policy.json de tu aplicación, sigue el proceso que se indica a continuación para tu tipo de aplicación. Consulta Gestionar el acceso a recursos protegidos con IAP para obtener más información sobre cómo usar la API IAM para gestionar políticas de acceso.

Antes de seguir 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

Exporta las siguientes variables de App Engine:

# The APP_ID is usually the project ID
export GAE_APP_ID=APP_ID
export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}

Obtén la política de gestión de identidades y accesos de la aplicación de App Engine mediante el método getIamPolicy. El bit de datos vacío al final convierte la solicitud curl en POST en lugar de GET.
```
curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \
${GAE_BASE_URL}/:getIamPolicy -d ''
```
Añade tu enlace 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 da acceso a los recursos protegidos por IAP. Se ha añadido una condición de gestión de identidades y accesos para concederles acceso a los recursos solo si se cumple el requisito de nivel de acceso ACCESS_LEVEL_NAME y la ruta de la URL del recurso empieza por /. Solo puede haber una condición por enlace.

Archivo policy.json de ejemplo
```
{
"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"
  }
}
]
}
}
```

Define 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

También puedes actualizar la política de gestión de identidades y accesos de un servicio de App Engine, de todas sus versiones o de una versión específica. Para hacerlo en una versión específica de un servicio, sigue estos pasos:

Exporta las siguientes variables adicionales.

export GAE_SERVICE=SERVICE_NAME
export GAE_VERSION=VERSION_NAME

Actualiza la variable GAE_BASE_URL exportada.

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

Obtén y define la política de gestión de identidades y accesos de la versión con los comandos getIamPolicy y setIamPolicy que se muestran arriba.

GKE y Compute Engine

Exporta el ID de proyecto de tu servicio backend.
```
export BACKEND_SERVICE_NAME=BACKEND_SERVICE_NAME
```
Obtén la política de gestión de identidades y accesos de la aplicación de Compute Engine mediante el método getIamPolicy. El bit de datos vacío al final convierte la solicitud curl en POST en lugar de GET.
```
curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \
 ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:getIamPolicy \
 -d ''
```
Añade tu enlace 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 da acceso a los recursos protegidos por IAP. Se ha añadido una condición de gestión de identidades y accesos para concederles acceso a los recursos solo si se cumple el requisito de nivel de acceso ACCESS_LEVEL_NAME y la ruta de la URL del recurso empieza por /. Solo puede haber una condición por enlace.

Archivo policy.json de ejemplo
```
{
"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"
}
}
]
}
}
```

Define 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}

Usar condiciones de nombre de host y ruta

El acceso a tu aplicación se puede proteger mediante el nombre de host y la ruta de una URL de solicitud. Por ejemplo, la condición de IAM request.path.startsWith se puede usar para conceder acceso únicamente a los empleados del grupo Acceso privilegiado si la ruta de la URL empieza por /admin.

Para obtener más información sobre el uso de las condiciones de nombre de host y ruta, consulta los atributos de solicitud.

Normalización de cadenas

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

Los back-ends pueden interpretar los nombres de host y las rutas de diferentes formas. Para evitar ambigüedades, IAP normaliza las cadenas de nombre de host y de ruta al comprobar las políticas.

IAP realiza dos comprobaciones de políticas cuando una solicitud tiene una ruta no normalizada. Si la ruta no normalizada supera la comprobación de la política, IAP normaliza la ruta y se realiza una segunda comprobación de la política. Se concederá acceso si tanto la ruta no normalizada como la normalizada superan la comprobación de la política.

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

Nombres de host

Los nombres de host se normalizan de la siguiente manera:

Eliminar puntos finales
Convertir caracteres a minúsculas
Convertir a ASCII

Los nombres de host que incluyen caracteres no ASCII se normalizan aún más con punycode. Debes convertir tu cadena de nombre de host a punycode para que se produzca una coincidencia.

Para convertir tu cadena de nombre de host a Punycode, usa un convertidor como Punycode.

A continuación, se muestran ejemplos de nombres de host normalizados:

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

Rutas

Las rutas se normalizan de la siguiente manera:

Eliminar parámetros de ruta
Resolver rutas relativas a su equivalente absoluto

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

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

Estos son algunos ejemplos de rutas normalizadas:

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

Terminaciones de subdominio

Una política definida con request.host.endsWith("google.com") coincidirá con sub_domain.google.com y testgoogle.com. Si tu objetivo es limitar tu política a todos los subdominios que terminen en google.com, define tu política como request.host.endsWith(".google.com").

Ten en cuenta que, si defines tu política como request.host.endsWith(".google.com"), se corresponderá con sub_domain.google.com, pero no con google.com debido al . adicional.

Registros de auditoría de Cloud y niveles de acceso

Habilitar los registros de auditoría de Cloud en 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 ha cumplido un solicitante, sigue el proceso que se indica a continuación:

Ve a la Google Cloud consola Explorador de registros de tu proyecto.
Ve a la página de registros.
En la lista desplegable selector de recursos, selecciona un recurso. Los recursos HTTPS protegidos mediante IAP se encuentran en Aplicación de GAE y Servicio de backend de GCE. Los recursos SSH y TCP protegidos por IAP se encuentran en Instancia de VM de GCE.
En la lista desplegable Tipo de registros, selecciona data_access.
- El tipo de registro data_access solo aparece si ha habido tráfico a tu recurso después de habilitar Cloud Audit Logs para IAP.
Haz clic para desplegar la fecha y la hora del acceso que quieras revisar.
- El acceso autorizado tiene un icono i azul.
- El acceso no autorizado tiene un icono !! naranja.
Para ver los niveles de acceso que ha cumplido el solicitante, haz clic para desplegar las secciones hasta que llegues a protoPayload > requestMetadata > requestAttributes > auth > accessLevels.

Ten en cuenta que todos los niveles de acceso que ha cumplido un usuario se muestran al ver una solicitud, incluidos los niveles de acceso que no eran necesarios para acceder a ella. Ver una solicitud no autorizada no indica qué niveles de acceso no se han cumplido. Esto se determina comparando las condiciones del recurso con los niveles de acceso visibles en la solicitud.

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

Configurar el acceso contextual con Identity-Aware Proxy Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.