Resolver problemas de política e acesso

Neste documento, você terá uma visão geral dos controles de aplicação da política de acesso do Google Cloud e das ferramentas disponíveis para solucionar problemas de acesso. Este documento é destinado a equipes de suporte que querem ajudar os clientes da organização a resolver problemas relacionados ao acesso aos recursos do Google Cloud.

Controles de aplicação da política de acesso do Google Cloud

Nesta seção, descrevemos as políticas que você ou o administrador da organização podem implementar para afetar o acesso aos recursos do Google Cloud. Implemente políticas de acesso usando todos ou alguns dos produtos e ferramentas a seguir.

Rótulos, tags e tags de rede

O Google Cloud oferece várias maneiras de rotular e agrupar recursos. É possível usar rótulos, tags e tags de rede para ajudar a aplicar políticas.

Os rótulos são pares de chave-valor que ajudam você a organizar seus recursos do Google Cloud. Muitos serviços do Google Cloud aceitam rótulos. Também é possível usar rótulos para filtrar e agrupar recursos para outros casos de uso, por exemplo, para identificar todos os recursos que estão em um ambiente de teste, e não os que estão em produção. No contexto da aplicação da política, os rótulos podem identificar onde os recursos precisam estar localizados. Por exemplo, as políticas de acesso aplicadas a recursos rotulados como teste são diferentes das políticas de acesso aplicadas a recursos rotulados como recursos de produção.

Tags são pares de chave-valor que fornecem um mecanismo para identificar recursos e aplicar a política. É possível anexar tags a uma organização, pasta ou projeto. Uma tag se aplica a todos os recursos no nível da hierarquia em que a tag é aplicada. É possível usar tags para permitir ou negar políticas de acesso condicionalmente com base no fato de um recurso ter uma tag específica ou não. Também é possível usar tags com políticas de firewall para controlar o tráfego em uma rede de nuvem privada virtual (VPC). É importante entender como as tags são herdadas e combinadas com políticas de acesso e firewall para solucionar problemas.

As tags de rede são diferentes das tags anteriores do Resource Manager. As tags de rede se aplicam a instâncias de VM e são uma maneira de controlar o tráfego de rede de e para uma VM. Nas redes do Google Cloud, as tags de rede identificam quais VMs estão sujeitas a regras de firewall e rotas de rede. É possível usar tags como valores de origem e destino nas regras de firewall. Também é possível usar tags para identificar a quais VMs uma determinada rota se aplica. O entendimento das tags de rede pode ajudar a solucionar problemas de acesso porque as tags são usadas para definir regras de rede e de roteamento.

Regras de firewall da VPC

É possível configurar regras de firewall da VPC para permitir ou negar tráfego de e para instâncias de máquina virtual (VM) e produtos criados em VMs. Toda rede VPC funciona como um firewall distribuído. Embora as regras de firewall são definidas no nível da rede, as conexões são permitidas ou negadas por instância. É possível aplicar regras de firewall da VPC à rede VPC, às VMs agrupadas por tags e às VMs agrupadas por contas de serviço.

VPC Service Controls

O VPC Service Controls fornece uma solução de segurança de perímetro que ajuda a reduzir a exfiltração de dados dos serviços do Google Cloud, como o Cloud Storage e o BigQuery. Você cria um perímetro de serviço que cria um limite de segurança em torno dos recursos do Google Cloud e pode gerenciar o que é permitido dentro e fora do perímetro. O VPC Service Controls também fornece controles de acesso baseado no contexto implementando políticas com base em atributos contextuais, como endereço IP e identidade.

Resource Manager

Use o Resource Manager para configurar um recurso de organização. O Resource Manager oferece ferramentas que permitem mapear a organização e a maneira como você desenvolve aplicativos para uma hierarquia de recursos. Com a ajuda do agrupamento de recursos de maneira lógica, o Resource Manager fornece pontos de anexação e herança para controle de acesso e políticas da organização.

Identity and Access Management

O Identity and Access Management (IAM) permite definir quem (identidade) tem acesso (função) a qual recurso. Uma política do IAM é um conjunto de instruções que define o tipo de acesso de cada um, como de leitura ou gravação. A política do IAM é anexada a um recurso e aplica o controle de acesso sempre que um usuário tentar acessar o recurso.

Um recurso do IAM são as Condições do IAM. Ao implementar condições do IAM como parte da definição da política, é possível conceder acesso de recursos a identidades (principais) somente se as condições configuradas forem atendidas. Por exemplo, é possível usar as condições do IAM para limitar o acesso a recursos somente para funcionários que fazem solicitações do seu escritório corporativo.

Organization Policy Service

O serviço de políticas da organização permite que você aplique restrições aos recursos compatíveis em toda a hierarquia da organização. Cada recurso compatível com as políticas da organização tem um conjunto de restrições que descreve as formas de restrição do recurso. Você define uma política que define regras específicas que restringem a configuração de recursos.

O serviço de políticas da organização permite que você, como administrador autorizado, modifique as políticas da organização padrão no nível da pasta ou do projeto, conforme necessário. As políticas da organização se concentram em como você configura os recursos, enquanto as políticas do IAM se concentram em quais permissões suas identidades receberam para esses recursos.

Cotas

O Google Cloud aplica cotas aos recursos, que definem um limite de quanto de um recurso específico do Google Cloud seu projeto pode usar. O número de projetos que você tem também está sujeito a uma cota. Os seguintes tipos de uso de recursos são limitados por cotas:

Cota de taxa, como solicitações de API por dia. Ela é redefinida após um período especificado, como um minuto ou um dia.
Cota de alocação, como o número de máquinas virtuais ou balanceadores de carga usados pelo projeto. Ela não é redefinida com o tempo. Uma cota de alocação precisa ser liberada explicitamente quando você não quer mais usar o recurso, como ao excluir um cluster do Google Kubernetes Engine (GKE).

Se você atingir o limite de uma cota de alocação, não será possível iniciar novos recursos. Se você atingir uma cota de taxa, não será possível concluir solicitações de API. Ambos os problemas podem parecer um problema relacionado ao acesso.

BeyondCorp Enterprise

O BeyondCorp Enterprise usa vários produtos do Google Cloud para aplicar o controle de acesso granular com base na identidade de um usuário e no contexto da solicitação. É possível configurar o BeyondCorp Enterprise para restringir o acesso ao Console do Google Cloud e às APIs do Google Cloud.

A proteção de acesso do BeyondCorp Enterprise funciona usando os seguintes serviços do Google Cloud:

Identity-Aware Proxy (IAP): um serviço que verifica a identidade do usuário e usa contexto para determinar se um usuário precisa receber acesso a um recurso.
IAM: o serviço de gerenciamento de identidade e autorização do Google Cloud.
Access Context Manager: um mecanismo de regras que permite o controle de acesso refinado.
Verificação de endpoints: uma extensão do Google Chrome que coleta detalhes do dispositivo do usuário.

Namespaces do Kubernetes e RBAC

O Kubernetes é operado como um serviço gerenciado no Google Cloud como Google Kubernetes Engine (GKE). O GKE pode aplicar políticas que são consistentes em qualquer lugar em que seu cluster do GKE esteja em execução. As políticas que afetam o acesso a recursos são uma combinação de controles integrados do Kubernetes e controles específicos do Google Cloud.

Além dos firewalls VPC e VPC Service Controls, o GKE usa namespaces, controle de acesso baseado em papéis (RBAC, na sigla em inglês) e identidades de carga de trabalho para gerenciar políticas que afetam o acesso aos recursos.

Namespaces

Namespaces são clusters virtuais que são apoiados pelo mesmo cluster físico e fornecem um escopo para os nomes. Os nomes dos recursos precisam ser exclusivos em um namespace. No entanto, é possível usar o mesmo nome em namespaces diferentes. Com os namespaces, é possível usar cotas de recursos para dividir os recursos do cluster entre vários usuários.

RBAC

O RBAC inclui os seguintes recursos:

Controle refinado sobre como os usuários acessam os recursos de API em execução no cluster.
- Permite criar políticas detalhadas que definem quais operações e recursos você permite que usuários e contas de serviço acessem.
- Pode controlar o acesso de Contas do Google e contas de serviço do Google Cloud e do Kubernetes.
Permite criar permissões do RBAC que se aplicam a todo o cluster ou a namespaces específicos dentro do cluster.
- As permissões em todo o cluster são úteis para limitar o acesso a recursos específicos da API para determinados usuários. Esses recursos de API incluem políticas de segurança e secrets.
- As permissões específicas de namespace são úteis quando, por exemplo, você tem vários grupos de usuários que operam nos respectivos namespaces. O controle de acesso baseado em papéis ajuda você a garantir que os usuários tenham acesso somente aos recursos do cluster dos respectivos namespaces.
Um papel que só pode ser usado para conceder acesso a recursos em um único namespace.
Um papel que contém regras que representam um conjunto de permissões. As permissões são puramente aditivas, e não há regras de negação.

O IAM e o RBAC do Kubernetes são integrados para que os usuários tenham autorização para executar ações se tiverem permissões suficientes de acordo com qualquer ferramenta.

A Figura 1 mostra como usar o IAM com RBAC e namespaces para implementar políticas.

**Figura 1**. O IAM e o RBAC do Kubernetes trabalham juntos para controlar o acesso a um cluster do GKE.

A Figura 1 mostra as seguintes implementações de política:

No nível do projeto, o IAM define papéis para os administradores do cluster para gerenciar clusters e permitir que os desenvolvedores de contêineres acessem APIs dentro dos clusters.
No nível do cluster, o RBAC define permissões em clusters individuais.
No nível do namespace, o RBAC define permissões nos namespaces.

Identidade da carga de trabalho

Além do RBAC e do IAM, você também precisa entender o impacto das identidades da carga de trabalho. A Identidade da carga de trabalho permite que você configure uma conta de serviço do Kubernetes para atuar como uma conta de serviço do Google. Qualquer aplicativo em execução como a conta de serviço do Kubernetes é autenticado automaticamente como a conta de serviço do Google ao acessar as APIs do Google Cloud. Essa autenticação permite atribuir identidade e autorização refinadas para aplicativos no cluster.

A Identidade da carga de trabalho depende das permissões do IAM para controlar quais APIs do Google Cloud seu aplicativo GKE pode acessar. Por exemplo, se as permissões do IAM forem alteradas, um aplicativo do GKE talvez não consiga gravar no Cloud Storage.

Ferramentas para solução de problemas

Nesta seção, você verá as ferramentas disponíveis para solucionar problemas das políticas. É possível usar produtos e recursos diferentes para aplicar uma combinação de políticas. Por exemplo, é possível usar firewalls e sub-redes para gerenciar a comunicação entre recursos no seu ambiente e em qualquer zona de segurança definida. Também é possível usar o IAM para restringir quem pode acessar o que está na zona de segurança e em qualquer zona definida do VPC Service Controls.

Registros

Quando ocorre um problema, normalmente o primeiro lugar para começar a solução de problemas é analisar os registros. Os registros do Google Cloud que fornecem insights sobre problemas relacionados ao acesso são os registros de auditoria do Cloud, a geração de registros de regras de firewall e os registros de fluxo de VPC.

Registros de auditoria do Cloud

Os registros de auditoria do Cloud consistem nos seguintes fluxos de registros de auditoria para cada projeto, pasta e organização: atividade do administrador, acesso a dados e evento do sistema. Os serviços do Google Cloud gravam entradas de registro de auditoria nesses registros para ajudar a identificar qual usuário executou uma ação nos seus projetos do Google Cloud, onde o fez e quando.

Os Registros de atividade do administrador contêm entradas de registros para chamadas de API ou de outras ações administrativas que modificam a configuração ou os metadados de recursos. Os registros de atividades do administrador estão sempre ativados. Para informações sobre preços e cotas de registros de atividades do administrador, consulte a visão geral dos registros de auditoria do Cloud.
Os Registros de acesso a dados gravam chamadas de API que criam, modificam ou lêem dados fornecidos pelo usuário. Os registros de auditoria de acesso a dados estão desativados por padrão, exceto para o BigQuery. Os registros de acesso a dados podem ser grandes e gerar custos. Para informações sobre os limites de uso de registros de acesso a dados, consulte Cotas e limites. Para mais informações sobre possíveis custos, consulte Preços.
Os registros de eventos do sistema contêm entradas de registro para quando o Compute Engine executa um evento do sistema. Por exemplo, cada migração em tempo real é registrada como um evento do sistema. Para mais informações sobre preços e cotas de registros de eventos do sistema, consulte a visão geral dos registros de auditoria do Cloud.

No Cloud Logging, o campo protoPayload contém um objeto AuditLog que armazena os dados de registro de auditoria. Para ver um exemplo de uma entrada de registro de auditoria, consulte o exemplo de entrada de registro de auditoria.

Para visualizar os registros de auditoria de atividade do administrador, você precisa ter o papel de visualizador de registros (roles/logging.viewer) ou o papel básico de visualizador (roles/viewer). Sempre que possível, selecione o papel com os privilégios mínimos necessários para concluir a tarefa.

Entradas individuais de registro de auditoria são armazenadas por um período especificado. Para uma retenção mais longa, exporte as entradas de registro para o Cloud Storage, BigQuery ou Pub/Sub. Para exportar entradas de registro de todos os projetos, pastas e contas de faturamento da sua organização, use as exportações agregadas. As exportações agregadas oferecem uma maneira centralizada de revisar os registros em toda a organização.

Para usar os registros de auditoria para ajudar na solução de problemas, faça o seguinte:

Verifique se você tem os papéis necessários do IAM para ver os registros. Se você exportar os registros, também precisará de permissões para visualizar os registros exportados no coletor.
Siga as práticas recomendadas de uso de registros de auditoria para atender à sua estratégia de auditoria.
Selecione uma estratégia de equipe para ver os registros. Há várias maneiras de visualizar registros em registros de auditoria do Cloud, e todas as pessoas da sua equipe devem usar o mesmo método.
Use a página "Atividade do console do Google Cloud" para ter uma visão geral dos registros de atividades.
Visualize os registros exportados do coletor para o qual foram exportados. Os registros que estão fora do período de armazenamento só ficam visíveis no coletor. Também é possível usar registros exportados para realizar uma investigação de comparação, por exemplo, de um momento em que tudo funcionou como esperado.

Registro de regras de firewall

A geração de registros de regras de firewall permite auditar, verificar e analisar os efeitos das suas regras de firewall. Por exemplo, é possível determinar se uma regra de firewall criada para negar tráfego está funcionando conforme o esperado.

Ative a geração de registros de regras de firewall individualmente para cada regra de firewall que tem as conexões que você precisa registrar. A geração de registros de regras de firewall é uma opção para qualquer regra de firewall, seja qual for a ação (permitir ou negar) ou a direção (entrada ou saída) dela. A geração de registros de regras de firewall pode gerar uma grande quantidade de dados. A geração de registros de regras de firewall tem uma cobrança associada a ele. Portanto, você precisa planejar com cuidado quais conexões quer registrar.

Determine onde você quer armazenar os registros de firewall. Se você quiser ter uma visualização dos registros em toda a organização, exporte os registros de firewall para o mesmo coletor dos registros de auditoria. Use filtros para pesquisar eventos de firewall específicos.

Firewall Insights

O Firewall Insights fornece relatórios que contêm informações sobre o uso do firewall e o impacto de várias regras de firewall na sua rede VPC. Use o Firewall Insights para verificar se as regras de firewall permitem ou bloqueiam as conexões pretendidas.

Também é possível usar o Firewall Insights para detectar regras de firewall que são sombreadas por outras regras. Uma regra sombreada é uma regra de firewall que tem todos os atributos relevantes, como portas e intervalos de endereços IP, sobrepostos por atributos de uma ou mais regras de firewall que tenham prioridades superiores ou iguais. As regras sombreadas são calculadas em 24 horas após a ativação da geração de registros de regras de firewall.

Quando você ativa a geração de registros de regras de firewall, o Firewall Insights analisa os registros para exibir insights sobre qualquer regra de negação usada no período de observação que você especificar (por padrão, as últimas 24 horas). Os insights da regra de negação fornecem sinais de queda de pacote de firewall. Use os sinais de queda de pacote para verificar se os pacotes descartados são esperados devido a proteções de segurança ou se os pacotes descartados são inesperados devido a problemas de configuração de rede.

Registros de fluxo de VPC

Os registros de fluxo de VPC registram uma amostra de fluxos de rede enviados e recebidos por instâncias de VM. Os registros de fluxo de VPC abrangem o tráfego que afeta uma VM. Todo o tráfego de saída (enviado) é registrado, mesmo se uma regra de firewall de negação de saída bloquear o tráfego. O tráfego de entrada (recebido) é registrado se uma regra de permissão de entrada de firewall permitir o tráfego. O tráfego de entrada não será registrado se uma regra de firewall de negação de entrada bloquear o tráfego.

Os registros de fluxo são coletados para cada conexão de VM em intervalos específicos. Todos os pacotes de amostra coletados para um determinado intervalo de uma determinada conexão (um intervalo de agregação) são agregados em uma única entrada de registro de fluxo. A entrada de registro de fluxo é então enviada para o Cloud Logging.

Os registros de fluxo de VPC são ativados ou desativados para cada sub-rede de VPC. Quando você ativa os registros de fluxo de VPC, isso gera uma grande quantidade de dados. Recomendamos que você gerencie com cuidado as sub-redes em que ativou os registros de fluxo de VPC. Por exemplo, recomendamos que você não ative os registros de fluxo por um período prolongado em sub-redes usadas por projetos de desenvolvimento. É possível consultar registros de fluxo de VPC diretamente usando o Cloud Logging ou o coletor exportado. Ao solucionar problemas perceptíveis relacionados a tráfego, use os registros de fluxo de VPC para ver se o tráfego está saindo de ou entrando em uma VM por meio da porta esperada.

Alertas

Os alertas permitem que você receba notificações oportunas de eventos fora da política que possam afetar o acesso aos seus recursos do Google Cloud.

Notificações em tempo real

O Inventário de recursos do Cloud mantém um histórico de cinco semanas dos metadados de recursos do Google Cloud. Recursos são aqueles compatíveis com o Google Cloud. Os recursos compatíveis incluem o IAM e o Compute Engine com recursos de rede associados, como regras de firewall e namespaces do GKE, além de vinculações de papéis e papéis do cluster. Todos os recursos anteriores afetam o acesso aos recursos do Google Cloud.

Para monitorar os desvios das configurações de recursos, como regras de firewall e regras de encaminhamento, inscreva-se para receber notificações em tempo real. Se as configurações do seu recurso forem alteradas, as notificações em tempo real serão enviadas imediatamente por meio do Pub/Sub. As notificações podem avisar você sobre qualquer problema com antecedência, antecipando uma chamada de suporte.

Registros de auditoria do Cloud e Cloud Functions

Para complementar o uso de notificações em tempo real, é possível monitorar o Cloud Logging e alertar sobre chamadas de ações confidenciais. Por exemplo, é possível criar um coletor do Cloud Logging que filtra chamadas para SetIamPolicy no nível da organização. O coletor envia registros a um tópico do Pub/Sub que pode ser usado para acionar a função do Cloud.

Testes de conectividade

Para determinar se um problema de acesso está relacionado à rede ou relacionado à permissão, use a ferramenta Testes de conectividade do Network Intelligence Center. Testes de conectividade são uma ferramenta estática de análise e diagnóstico de configuração que permite verificar a conectividade entre um endpoint de origem e de destino. Os testes de conectividade ajudam a identificar a causa raiz de problemas de acesso relacionados à rede e associados à configuração de rede do Google Cloud.

O Connectivity Tests realiza testes que incluem sua rede VPC, peering de rede VPC e túneis VPN para sua rede local. Por exemplo, os testes de conectividade podem identificar se uma regra de firewall está bloqueando a conectividade. Para mais informações, consulte Casos de uso comuns.

Solucionador de problemas de políticas

Muitas tarefas no Google Cloud exigem um papel do IAM e permissões associadas. Recomendamos que você verifique quais permissões estão contidas em um papel e quais delas são necessárias para concluir uma tarefa. Por exemplo, para usar imagens do Compute Engine para criar uma instância, o usuário precisa do papel compute.imageUser, que inclui nove permissões. Portanto, o usuário precisa ter uma combinação de papéis e permissões que incluam todas as nove permissões.

O Solucionador de problemas de políticas é uma ferramenta do console do Google Cloud que ajuda a depurar por que um usuário ou conta de serviço não tem permissão para acessar um recurso. Para resolver problemas de acesso, use a parte do IAM do Solucionador de problemas de políticas.

Por exemplo, convém verificar por que um determinado usuário pode criar objetos em buckets em um projeto, enquanto outro usuário não pode. O Solucionador de problemas de políticas pode ajudar a ver quais permissões o primeiro usuário tem que o segundo não tem.

O Solucionador de problemas de políticas exige as seguintes entradas:

Principal (usuário individual, conta de serviço ou grupos)
Permissão (essas são as permissões subjacentes, não os papéis do IAM)
Recurso

Encaminhamento ao Customer Care

Ao solucionar problemas relacionados ao acesso, é importante ter um bom processo de suporte interno e um processo bem definido para encaminhamento ao Cloud Customer Care. Nesta seção, você verá um exemplo de configuração de suporte e como se comunicar com o Customer Care para ajudá-lo a resolver seus problemas rapidamente.

Caso não consiga resolver um problema usando as ferramentas descritas neste documento, um processo de suporte claramente definido ajudará o Customer Care a resolvê-lo. É recomendável ter uma abordagem sistemática para solução de problemas, conforme descrito no capítulo Solução de problemas efetivo do livro Engenharia de confiabilidade do site (SRE, na sigla em inglês) do Google.

Recomendamos que o processo de suporte interno faça as seguintes ações:

Detalhe os procedimentos a serem seguidos se houver um problema.
Tenha um caminho de encaminhamento claramente definido.
Configure um processo de chamada.
Crie um plano de resposta a incidentes.
Configure um sistema de rastreamento de bugs ou de atendimento ao usuário.
Certifique-se de que sua equipe de suporte tenha autorização para se comunicar com o Customer Care e seja contatos nomeados.
Comunique processos de suporte à equipe interna, incluindo como entrar em contato com os contatos nomeados do Google Cloud.
Analise regularmente problemas de suporte e itere e melhore com base no que for aprendido.
Inclua um formulário retrospectivo padronizado.

Se você precisar encaminhar para o Customer Care, tenha as seguintes informações disponíveis para compartilhar com eles quando for solucionar problemas de acesso:

A identidade (e-mail da conta de serviço ou do usuário) que está solicitando acesso.
- Se esse problema afeta todas as identidades ou apenas algumas.
- Se apenas algumas identidades forem afetadas, forneça uma identidade de exemplo que funcione e uma identidade de exemplo que falhe.
Se a identidade foi recriada recentemente.
O recurso que o usuário está tentando acessar (incluir ID do projeto).
A solicitação ou o método que está sendo chamado.
- Forneça uma cópia da solicitação e da resposta.
As permissões concedidas à identidade desse acesso.
- Forneça uma cópia da política do IAM.
O local de origem de onde a identidade está tentando acessar os recursos. Por exemplo, se estiverem tentando acessar um recurso a partir do Google Cloud (como uma instância do Compute Engine), do console do Google Cloud, da Google Cloud CLI, do Cloud Shell ou a partir de uma fonte externa, seja local ou da Internet.
- Se a origem for de outro projeto, forneça o ID do projeto de origem.
A hora (carimbo de data/hora) em que o erro ocorreu e se ele ainda é um problema.
A última vez conhecida que a identidade acessou o recurso (inclua carimbos de data/hora).
Todas as alterações feitas antes do início do problema (inclua os carimbos de data/hora).
Quaisquer erros registrados no Cloud Logging. Antes de compartilhar com o Customer Care, edite dados confidenciais, como tokens de acesso, credenciais e números de cartão de crédito.

A seguir

Leia sobre os casos de uso para resolver problemas de acesso.