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 do 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;

Configurar um nível de acesso

Para limitar o acesso com base no endereço IP ou nos atributos do dispositivo do usuário final, crie um nível de acesso. Alguns atributos, como os de dispositivo, exigem uma licença do Chrome Enterprise Premium. A validação da licença só ocorre quando você configura os níveis de acesso e não afeta o acesso ao ambiente de execução. Para 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.

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 recursos é 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 condições de nome do host e caminho, consulte Usar condições de nome do host e 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 :

  1. Acesse a página de administrador do IAP.

    Acessar a página de administrador do IAP

  2. Marque a caixa de seleção ao lado dos recursos com as permissões do IAM você quer atualizar.

  3. No painel de informações direito, clique em Adicionar principal.

  4. Na caixa Novo principal, insira os principais a que você quer atribuir um papel.

  5. Na lista suspensa Selecionar um papel, selecione o papel Usuário do app da Web protegido pelo IAP e especifique as condições do nível de acesso que os principais precisam 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.

  6. Se quiser adicionar mais papéis aos principais, clique em Adicionar outro papel.

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

  1. Acesse a página de administrador do IAP.

    Acessar a página de administrador do IAP

  2. Marque a caixa de seleção ao lado do recurso de que você quer remover o papel do IAM de um principal.

  3. No Painel de informações à direita, em Papel / Principal, clique no papel que você quer remover do principal.

  4. Clique em Remover ao lado do principal.

  5. Na caixa de diálogo Remover papel do principal que aparece, 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:

  1. Abra a política do IAM do app usando o seguinte comando gcloud: 

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

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

  3. 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 da API específicas do aplicativo abaixo, 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

 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. Adicione sua vinculação condicional do IAM ao arquivo JSON de política do IAM. Veja a seguir 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 do IAM foi adicionada para conceder acesso aos recursos somente se o requisito de nível de acesso ACCESS_LEVEL_NAME for atendido e o caminho do URL do recurso começar com `/`. Cada vinculação pode ter apenas uma condiçã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"
          }
        }
        ]
  }
}
 1. 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

 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. Atualize a variável GAE_BASE_URL exportada. 
export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}/services/${GAE_SERVICE}/versions/${GAE_VERSION}
 1. Receba e defina a política do IAM para a versão usando os comandos getIamPolicy e setIamPolicy mostrados acima.

### GKE e Compute Engine

1. Exporte o ID do projeto do seu serviço de back-end. 
     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. 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}

Usar condições de nome do host e caminho

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 um nome de host sheets.google.com e um caminho /create.

Os back-ends podem interpretar os nomes e caminhos de host de maneiras diferentes. Para remover a ambiguidade, o IAP normaliza as strings de nome do host e de caminho 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 no projeto protegido pelo IAP permite que você veja solicitações de acesso autorizadas e não autorizadas. Para ver as solicitações e todos os níveis de acesso que um solicitante atendeu, siga estas etapas:

  1. Acesse a Análise de registros do seu projeto no console do Google Cloud .
    Acessar a página de registros
  2. Na lista suspensa Seletor de recursos, selecione um recurso. Os recursos HTTPS protegidos pelo IAP estão em Aplicativo do App Engine e Serviço de back-end do Compute Engine. Os recursos SSH e TCP protegidos pelo IAP estão em Instância de VM do Compute Engine .
  3. Na lista suspensa Tipo de registros, selecione data_access.
    • O tipo de registro data_access será exibido somente se houver tráfego no seu recurso depois que você ativar os registros de auditoria do Cloud para o IAP.
  4. 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.
  5. Visualize 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.