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 configurar restricciones para acceder a los recursos según las direcciones 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 los niveles de acceso

Deberás crear un nivel de acceso, para limitar el acceso por dirección IP o por atributos del dispositivo del usuario final. Si deseas saber cómo 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 aplicación protegida con IAP.

IAP no admite el uso de políticas con alcance. Los niveles de acceso deben establecerse 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.

Cuando se agrega una vinculación condicional de IAM a la política de IAM, el acceso a tus recursos está más restringido según atributos de 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 los nombres de host y las rutas de acceso, consulta cómo usar las condiciones de ruta de acceso y nombre de host.

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:

  1. Ve a la página de administrador de IAP.

    Ir a la página Administración de IAP

  2. Selecciona la casilla de verificación junto a los recursos para los que deseas actualizar los permisos de IAM.

  3. En el panel de información a la derecha, haz clic en Agregar principal.

  4. En el cuadro Principal nueva, ingresa las principales a las que deseas asignarles un rol.

  5. En la lista desplegable Seleccionar un rol, selecciona el rol Usuario de app web protegida con IAP y especifica las condiciones de 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.

  6. Si quieres agregar más roles a las principales, haz clic en Agregar otro rol.

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

  1. Ve a la página de administrador de IAP.

    Ir a la página Administración de IAP

  2. Selecciona la casilla de verificación junto al recurso del que deseas quitar el rol de IAM de una principal.

  3. En el panel de información de la derecha, en Rol / Principal, haz clic en el rol que deseas quitar de la principal.

  4. Haz clic en Quitar junto a la principal.

  5. En el diálogo Quitar rol de la principal que aparece, haz clic en Quitar. Para quitar todos los roles no heredados de la principal en el recurso seleccionado, selecciona 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:

  1. Abre la política de IAM de la app con el siguiente comando de gcloud: 

    gcloud iap web get-iam-policy PROJECT_ID > policy.yaml

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

  3. 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 API específicos de la aplicación que aparecen 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. 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}

  2. Obtén la política de IAM para la aplicación de App Engine con 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 ''

  3. 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 la función iap.httpsResourceAccessor a dos usuarios y les otorga acceso a los recursos protegidos con IAP. Se agregó una condición de IAM para otorgarles acceso a los recursos solo si se cumple el requisito de nivel de acceso ACCESS_LEVEL_NAME y la ruta de URL del recurso comienza con /. Solo puede haber una condición por vinculación.

    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"
  }
}
]
}
}

  4. Configura el 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 IAM para un servicio de App Engine, todas las versiones o una versión específica de un servicio. Sigue estos pasos para hacerlo con una versión específica de un servicio:

  1. Exporta las siguientes variantes adicionales. 
    export GAE_SERVICE=SERVICE_NAME
export GAE_VERSION=VERSION_NAME
  2. Actualiza la variante GAE_BASE_URL exportada. 
    export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}/services/${GAE_SERVICE}/versions/${GAE_VERSION}
  3. Obtén y establece la política de IAM para la versión con los comandos getIamPolicy y setIamPolicy que se muestran arriba.

GKE y Compute Engine

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

    export BACKEND_SERVICE_NAME=BACKEND_SERVICE_NAME

  2. Obtén la política de IAM para la aplicación de Compute Engine con 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 ''

  3. 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 la función iap.httpsResourceAccessor a dos usuarios y les otorga acceso a los recursos protegidos con IAP. Se agregó una condición de IAM para otorgarles acceso a los recursos solo si se cumple el requisito de nivel de acceso ACCESS_LEVEL_NAME y la ruta de URL del recurso comienza con /. Solo puede haber una condición por vinculación.


    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"
}
}
]
}
}

  4. Configura el 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}

Utiliza las condiciones del nombre de host y la 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 request.path.startsWith de IAM se puede usar para otorgar acceso únicamente a los empleados del grupo de Acceso privilegiado 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
  • Resolución de rutas 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.

Cloud Audit Logging y niveles de acceso

La habilitación de Cloud Audit Logging para tu proyecto protegido con IAP te permite ver solicitudes de acceso autorizadas y no autorizadas. Sigue los pasos que aparecen a continuación para ver las solicitudes y todos los niveles de acceso con que cumple un solicitante:

  1. Ve al Explorador de registros de la consola de Google Cloud de tu proyecto.
    Ir a la página Registros
  2. En la lista desplegable del selector de recursos, selecciona un recurso. Los recursos de HTTPS protegidos con IAP se encuentran en la Aplicación de GAE y el Servicio de backend de GCE. Los recursos de SSH y TCP protegidos con IAP se encuentran en la instancia de VM en GCE.
  3. En la lista desplegable tipo de registros, selecciona data_access.
    • El tipo de registro data_access solo aparece si se registró tráfico hacia tu recurso después de habilitar Registros de auditoría de Cloud para IAP.
  4. 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.
  5. Haz clic para expandir las secciones a fin de ver los niveles de acceso con los que cumple el solicitante 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.