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 IAP não oferece suporte ao uso de políticas de escopo. 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.
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 aos quais 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 necessárias 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.
- 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:
Se você 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.
Marque a caixa de seleção ao lado do recurso com o papel do IAM que você quer remover.
No Painel de informações à direita, 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 do principal, clique em Remover. Para remover todos os papéis não herdados do participante 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 do app usando o seguinte comando gcloud:
gcloud iap web get-iam-policy --project=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 executar 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
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çãocurl
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 papeliap.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 seu novo arquivo
policy.json
usando o métodosetIamPolicy
.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
esetIamPolicy
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çãocurl
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 papeliap.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 seu novo arquivo
policy.json
usando o métodosetIamPolicy
.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 parafoo.com
.café.fr
é a versão normalizada paraxn--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 o
Explorador de registros do console do Google Cloud para 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 no 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.
- O acesso autorizado tem um ícone
-
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.