Como configurar o acesso baseado no contexto com o Identity-Aware Proxy

Neste guia, você verá como estender as políticas de acesso do Identity-Aware Proxy (IAP) usando níveis de acesso e o framework do gerenciamento de identidade e acesso (IAM) Conditions. Os níveis de acesso permitem restrições de acesso a recursos com base no endereço IP e nos atributos de dispositivo do usuário final. As condições do IAM permitem restrições de acesso com base em hosts de URL, caminhos, data e hora.

Por exemplo, dependendo da configuração de política, seu app confidencial poderá:

conceder acesso a todos os funcionários se eles estiverem usando um dispositivo corporativo confiável na rede local;
conceder acesso aos funcionários no grupo Acesso remoto se eles estiverem usando um dispositivo corporativo confiável com uma senha segura e um nível de patch atualizado a partir de qualquer rede;
conceder acesso apenas aos funcionários no grupo Acesso privilegiado se o caminho do URL começar com /admin.

Antes de começar

Antes de começar, você precisará de:

um app protegido pelo IAP a que você quer adicionar acesso individual ou em grupo;
Nomes de usuários ou de grupos a que você quer conceder acesso.

Como configurar um nível de acesso

Para limitar o acesso baseado no endereço IP ou nos atributos de dispositivo de usuário final, crie um nível de acesso. Se você quiser saber como criar um nível de acesso, consulte o guia do Access Context Manager. O IAP usa o nome do nível de acesso para associá-lo a um app protegido pelo IAP.

O uso de políticas com escopo não é compatível com o IAP. Os níveis de acesso precisam ser definidos na política de acesso da organização. Para mais informações, consulte Criar uma política de acesso.

Como editar a política do IAM

Um aplicativo protegido por IAP tem uma política de IAM que vincula o papel de IAP ao aplicativo.

Ao adicionar uma vinculação condicional do IAM à política do IAM, o acesso aos seus recursos fica ainda mais restrito com base nos atributos de solicitação. Esses atributos de solicitação incluem:

Níveis de acesso
URL/caminho do host
Data/hora

Os valores de solicitação que serão comparados a request.host e request.path, especificados em uma vinculação condicional do IAM, precisam ser exatos. Por exemplo, se você restringir o acesso a caminhos que começam com /internal admin, será possível ignorar a restrição acessando /internal%20admin. Para mais informações sobre o nome do host e as condições do caminho, consulte Como usar o nome do host e as condições do caminho.

Adicione e edite as vinculações condicionais na sua política do IAM seguindo o processo abaixo.

Console

Para adicionar uma vinculação condicional usando o console do Google Cloud:

Acesse a página de administrador do IAP.
Acessar a página de administrador do IAP
Marque a caixa de seleção ao lado dos recursos com as permissões do IAM você quer atualizar.
No painel de informações direito, clique em Adicionar principal.
Na caixa Novo principal, insira os principais a que você quer atribuir um papel.
Na lista suspensa Selecionar um papel, selecione o papel Usuário do app da Web protegido pelo IAP e especifique as condições de nível de acesso a que os principais precisarão atender para acessar o recurso.
- Para especificar os níveis de acesso atuais, selecione-os na lista suspensa Níveis de acesso. É necessário selecionar o papel Usuário do app da Web protegido pelo IAP e ter permissões no nível da organização para exibir os níveis de acesso atuais. Você precisa ter recebido um dos seguintes papéis:
  - Administrador do Access Context Manager
  - Editor do Access Context Manager
  - Leitor Access Context Manager
- Para criar e gerenciar níveis de acesso, use o Access Context Manager.
Se quiser adicionar mais papéis aos principais, clique em Adicionar outro papel.
Quando terminar de adicionar papéis, clique em Salvar.

Você adicionou uma ligação condicional ao seu recurso.

Para remover uma ligação condicional, siga estas etapas:

Acesse a página de administrador do IAP.
Acessar a página de administrador do IAP
Marque a caixa de seleção ao lado do recurso com o papel do IAM de um principal que você quer remover.
No painel de informações direito, em Papel / Principal, clique no papel que você quer remover do principal.
Clique em Remover ao lado do principal.
Na caixa de diálogo Remover papel da principal que é exibida, clique em Remover. Para remover todos os papéis não herdados do principal no recurso selecionado, marque a caixa de seleção antes de clicar em Remover.

gcloud

No momento, só use a ferramenta gcloud para definir vinculações condicionais para envolvidos no projeto.

Para definir vinculações condicionais, edite o arquivo policy.yaml do seu projeto seguindo o processo abaixo:

Abra a política do IAM para o app usando o seguinte comando gcloud:
```
gcloud iap web get-iam-policy PROJECT_ID > policy.yaml
```
Edite o arquivo policy.yaml para especificar:
- Os usuários e grupos a que você quer aplicar a condição do IAM.
- o papel iap.httpsResourceAccessor para conceder a eles acesso aos recursos.
- A condição do IAM.
  
  O snippet a seguir mostra uma condição do IAM com apenas um atributo especificado. Essa condição concederá acesso ao usuário e ao grupo se os requisitos de nível de acesso ACCESS_LEVEL_NAME forem atendidos e o caminho do URL do recurso começar com /.
```
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
...
```
Vincule a política ao aplicativo usando o comando set-iam-policy.
```
gcloud iap web set-iam-policy --project PROJECT_ID policy.yaml
```

Sua política do IAM agora inclui uma vinculação condicional.

API

Para editar o arquivo policy.json do seu app, siga o processo abaixo de acordo com o tipo de aplicativo. Consulte Como gerenciar o acesso a recursos protegidos pelo IAP para mais informações sobre como usar a API do IAM para gerenciar políticas de acesso.

Antes de seguir as etapas específicas da API do aplicativo, exporte as seguintes variáveis:

 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

Exporte as seguintes variáveis do 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}

Consiga a política do IAM para o aplicativo do App Engine usando o método getIamPolicy. O bit de dados vazio no final transforma a solicitação curl em POST em vez de GET.
```
curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \
${GAE_BASE_URL}/:getIamPolicy -d ''
```
Adicione sua vinculação condicional do IAM ao arquivo JSON de política do IAM. A seguir, há um exemplo de um arquivo policy.json editado que vincula o papel iap.httpsResourceAccessor a dois usuários, concedendo a eles acesso aos recursos protegidos pelo IAP. Uma condição IAM será adicionada para conceder acesso somente se o requisito de nível de acesso ACCESS_LEVEL_NAME for atendido e o caminho do URL do recurso começar com /. Pode haver apenas uma condição por ligação.

Exemplo de arquivo 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"
  }
}
]
}
}
```

Defina o novo arquivo policy.json usando o método setIamPolicy.

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

Serviços e versões do App Engine

Você também pode atualizar a política do IAM de um serviço do App Engine, todas as versões ou uma versão específica de um serviço. Para atualizar uma versão específica de um serviço:

Exporte as seguintes variáveis adicionais.

export GAE_SERVICE=SERVICE_NAME
export GAE_VERSION=VERSION_NAME

Atualize a variável exportada GAE_BASE_URL.

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

Consiga e defina a política do IAM referente à versão usando os comandos getIamPolicy e setIamPolicy mostrados acima.

GKE e Compute Engine

Exporte o ID do projeto do seu serviço de back-end.
```
export BACKEND_SERVICE_NAME=BACKEND_SERVICE_NAME
```
Consiga a política do IAM para o app do Compute Engine usando o método getIamPolicy. O bit de dados vazio no final transforma a solicitação curl em POST em vez de GET.
```
curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \
 ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:getIamPolicy \
 -d ''
```
Adicione sua vinculação condicional do IAM ao arquivo JSON de política do IAM. A seguir, há um exemplo de um arquivo policy.json editado que vincula o papel iap.httpsResourceAccessor a dois usuários, concedendo a eles acesso aos recursos protegidos pelo IAP. Uma condição IAM será adicionada para conceder acesso somente se o requisito de nível de acesso ACCESS_LEVEL_NAME for atendido e o caminho do URL do recurso começar com /. Pode haver apenas uma condição por ligação.

Exemplo de arquivo 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"
}
}
]
}
}
```

Defina o novo arquivo policy.json usando o 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}

Como usar as condições de nome e caminho do host

O acesso ao seu app pode ser protegido usando o nome e o caminho de host de um URL de solicitação. Por exemplo, a condição do IAM request.path.startsWith só pode ser usada para conceder acesso aos funcionários no grupo Acesso prioritário se o caminho do URL começar com /admin.

Para mais informações sobre as condições de nome e caminho do host, veja Atributos de solicitação.

Normalização de strings

Um URL tem um nome e caminho de host. Por exemplo, o URL https://sheets.google.com/create?query=param tem o nome de host sheets.google.com e o caminho /create.

Os back-ends podem interpretar os nomes e caminhos de host de maneiras diferentes. Para remover a ambiguidade, o IAP normaliza essas informações ao verificar as políticas.

O IAP executa duas verificações de política quando uma solicitação tem um caminho não normalizado. Se esse caminho passar na verificação, ele será normalizado e uma segunda verificação de política será executada pelo IAP. Será concedido acesso se os caminhos não normalizados e normalizados passarem na verificação.

Por exemplo, se uma solicitação tiver o caminho /internal;some_param/admin, o IAP primeiro executará uma verificação de política no caminho não normalizado (/internal). Se ele for aprovado, o IAP executará uma segunda verificação no normalizado (/internal/admin).

Nomes de host

Os nomes de host podem ser normalizados das seguintes formas:

Removendo pontos à direita
Colocando os caracteres em minúsculo
Convertendo para ASCII

Os nomes de host que incluem caracteres não ASCII são normalizados com punycoding. Assim, você precisará codificar a string de nome de host com punycode para uma correspondência seja feita.

Para isso, use um conversor como o Punycoder (em inglês).

Veja a seguir exemplos de nomes de host normalizados:

FOO.com é a versão normalizada para foo.com.
café.fr é a versão normalizada para xn--caf-dma.fr.

Caminhos

Os caminhos podem ser normalizados da seguinte forma:

Removendo parâmetros de caminho
Resolvendo caminhos relativos ao equivalente absoluto deles.

Um parâmetro de caminho inclui todos os caracteres de ; até o próximo / ou o fim desse caminho.

Solicitações que contenham ..; no início de uma seção de caminho serão consideradas inválidas. Por exemplo, /..;bar/ e /bar/..;/ retornam o erro HTTP 400: Bad Request.

Veja a seguir exemplos de caminhos normalizados:

/internal;some_param/admin é a versão normalizada para /internal/admin.
/a/../b é a versão normalizada para /b.
/bar;param1/baz;baz;param2 é a versão normalizada para /bar/baz.

Terminações de subdomínios

Uma política definida com request.host.endsWith("google.com") corresponderá a sub_domain.google.com e testgoogle.com. Se seu objetivo é limitar a política a todos os subdomínios com final google.com, defina-a como request.host.endsWith(".google.com").

Se você configurar sua política como request.host.endsWith(".google.com"), sub_domain.google.com será correspondido, mas não google.com, devido ao . extra.

Registros de auditoria do Cloud e níveis de acesso

Ativar os registros de auditoria do Cloud para seu projeto protegido pelo IAP permite que você veja as solicitações de acesso autorizadas e não autorizadas. Veja as solicitações e todos os níveis de acesso que um solicitante atendeu seguindo o processo abaixo:

Acesse a Análise de registros no console do Google Cloud do seu projeto.
Acessar a página Registros
Na lista suspensa Seletor de recursos, selecione um recurso. Os recursos HTTPS protegidos pelo IAP estão em Aplicativo do GAE e Serviço de back-end do GCE. Os recursos SSH e TCP protegidos pelo IAP estão em Instância da VM do GCE.
Na lista suspensa Tipo de registros, selecione data_access.
- O tipo de registro data_access será exibido somente se houver tráfego para seu recurso depois que você ativar os registros de auditoria do Cloud para o IAP.
Clique para expandir a data e a hora do acesso que você quer avaliar.
- O acesso autorizado tem um ícone i azul.
- O acesso não autorizado tem um ícone !! laranja.
Veja os níveis de acesso a que o solicitante atendeu clicando para expandir as seções até chegar em protoPayload > requestMetadata > requestAttributes > auth > accessLevels.

Observe que todos os níveis de acesso a que um usuário atendeu são visíveis ao visualizar uma solicitação, incluindo níveis de acesso que não eram necessários para acessá-la. Visualizar uma solicitação não autorizada não indica quais níveis de acesso não foram atendidos. Isso é determinado comparando as condições no recurso com os níveis de acesso visíveis na solicitação.

Consulte o guia Registros de auditoria do Cloud para mais informações sobre registros.