GCP - Basic Information
Hierarquia de Recursos
Google Cloud usa uma Hierarquia de Recursos que é semelhante, conceitualmente, à de um sistema de arquivos tradicional. Isso fornece um fluxo de trabalho lógico de pai/filho com pontos específicos de anexação para políticas e permissões.
Em um nível alto, parece assim:
Uma máquina virtual (chamada de Compute Instance) é um recurso. Um recurso reside em um projeto, provavelmente junto com outras Compute Instances, storage buckets, etc.
Migração de Projetos
É possível migrar um projeto sem nenhuma organização para uma organização com as permissões roles/resourcemanager.projectCreator e roles/resourcemanager.projectMover. Se o projeto estiver dentro de outra organização, é necessário entrar em contato com o suporte do GCP para movê-los para fora da organização primeiro. Para mais informações, confira isso.
Políticas de Organização
Permitem centralizar o controle sobre os recursos de nuvem da sua organização:
Centralizar o controle para configurar restrições sobre como os recursos da sua organização podem ser usados.
Definir e estabelecer guardrails para que suas equipes de desenvolvimento permaneçam dentro dos limites de conformidade.
Ajudar os proprietários de projetos e suas equipes a se moverem rapidamente sem se preocupar em quebrar a conformidade.
Essas políticas podem ser criadas para afetar a organização completa, pasta(s) ou projeto(s). Os descendentes do nó da hierarquia de recursos alvo herdam a política da organização.
Para definir uma política de organização, você escolhe uma restrição, que é um tipo particular de restrição contra um serviço do Google Cloud ou um grupo de serviços do Google Cloud. Você configura essa restrição com suas restrições desejadas.
Casos de uso comuns
Limitar o compartilhamento de recursos com base no domínio.
Limitar o uso de contas de serviço do Identity and Access Management.
Restringir a localização física de novos recursos criados.
Desativar a criação de contas de serviço.
Existem muitas outras restrições que oferecem controle detalhado dos recursos da sua organização. Para mais informações, veja a lista de todas as restrições do Organization Policy Service.
Políticas de Organização Padrão
Funções do IAM
Estas são como políticas do IAM na AWS, pois cada função contém um conjunto de permissões.
No entanto, ao contrário da AWS, não há repositório centralizado de funções. Em vez disso, recursos dão funções de acesso X a principais Y, e a única maneira de descobrir quem tem acesso a um recurso é usar o método get-iam-policy sobre esse recurso.
Isso pode ser um problema porque significa que a única maneira de descobrir quais permissões um principal tem é perguntar a cada recurso a quem ele está dando permissões, e um usuário pode não ter permissões para obter permissões de todos os recursos.
Existem três tipos de funções no IAM:
Funções Básicas/Primitivas, que incluem as funções Owner, Editor e Viewer que existiam antes da introdução do IAM.
Funções predefinidas, que fornecem acesso granular para um serviço específico e são gerenciadas pelo Google Cloud. Existem muitas funções predefinidas, você pode ver todas elas com os privilégios que possuem aqui.
Funções personalizadas, que fornecem acesso granular de acordo com uma lista de permissões especificada pelo usuário.
Existem milhares de permissões no GCP. Para verificar se uma função tem uma permissão, você pode procurar a permissão aqui e ver quais funções a possuem.
Você também pode procurar aqui funções predefinidas oferecidas por cada produto. Note que algumas funções não podem ser atribuídas a usuários e apenas a SAs devido a algumas permissões que contêm. Além disso, note que permissões só terão efeito se estiverem vinculadas ao serviço relevante.
Ou verificar se uma função personalizada pode usar uma permissão específica aqui.
GCP - IAM, Principals & Org Policies EnumUsuários
No console do GCP não há gerenciamento de Usuários ou Grupos, isso é feito no Google Workspace. Embora você possa sincronizar um provedor de identidade diferente no Google Workspace.
Você pode acessar usuários e grupos do Workspaces em https://admin.google.com.
MFA pode ser forçado para usuários do Workspaces, no entanto, um atacante pode usar um token para acessar o GCP via cli, que não será protegido por MFA (será protegido por MFA apenas quando o usuário fizer login para gerá-lo: gcloud auth login).
Grupos
Quando uma organização é criada, vários grupos são fortemente sugeridos para serem criados. Se você gerenciar qualquer um deles, pode ter comprometido toda ou uma parte importante da organização:
Grupo | Função |
| Administrar qualquer recurso que pertença à organização. Atribua essa função com moderação; os administradores da organização têm acesso a todos os recursos do Google Cloud. Alternativamente, porque essa função é altamente privilegiada, considere usar contas individuais em vez de criar um grupo. |
| Criar redes, sub-redes, regras de firewall e dispositivos de rede, como Cloud Router, Cloud VPN e balanceadores de carga na nuvem. |
| Configurar contas de faturamento e monitorar seu uso. |
| Projetar, codificar e testar aplicativos. |
| Estabelecer e gerenciar políticas de segurança para toda a organização, incluindo gerenciamento de acesso e políticas de restrição da organização. Veja o guia de fundamentos de segurança do Google Cloud para mais informações sobre o planejamento da sua infraestrutura de segurança do Google Cloud. |
| Criar ou gerenciar pipelines de ponta a ponta que suportam integração e entrega contínuas, monitoramento e provisionamento de sistemas. |
| |
| |
| |
| Monitorar os gastos nos projetos. Membros típicos fazem parte da equipe financeira. |
| Revisar informações de recursos em toda a organização do Google Cloud. |
| Revisar a segurança da nuvem. |
| Revisar configurações de rede. |
| Visualizar logs de auditoria. |
| Administrar o Security Command Center. |
| Gerenciar segredos no Secret Manager. |
Política de Senha Padrão
Impor senhas fortes
Entre 8 e 100 caracteres
Sem reutilização
Sem expiração
Se as pessoas estiverem acessando o Workspace através de um provedor de terceiros, esses requisitos não são aplicados.
Contas de serviço
Estes são os principais que recursos podem ter anexados e acesso para interagir facilmente com o GCP. Por exemplo, é possível acessar o token de autenticação de uma Conta de Serviço anexada a uma VM nos metadados.
É possível encontrar alguns conflitos ao usar tanto IAM quanto escopos de acesso. Por exemplo, sua conta de serviço pode ter a função IAM de compute.instanceAdmin, mas a instância que você invadiu foi limitada com a limitação de escopo de https://www.googleapis.com/auth/compute.readonly. Isso impediria você de fazer qualquer alteração usando o token OAuth que é automaticamente atribuído à sua instância.
É semelhante às funções do IAM da AWS. Mas, ao contrário da AWS, qualquer conta de serviço pode ser anexada a qualquer serviço (não precisa permitir isso via uma política).
Várias das contas de serviço que você encontrará são na verdade geradas automaticamente pelo GCP quando você começa a usar um serviço, como:
No entanto, também é possível criar e anexar a recursos custom service accounts, que se parecerão com isto:
Access scopes
Access scope são anexados aos tokens OAuth gerados para acessar os endpoints da API do GCP. Eles restringem as permissões do token OAuth. Isso significa que se um token pertence a um Proprietário de um recurso, mas não tem no escopo do token para acessar esse recurso, o token não pode ser usado para (ab)usar esses privilégios.
O Google na verdade recomenda que os access scopes não sejam usados e que se confie totalmente no IAM. O portal de gerenciamento web realmente impõe isso, mas os access scopes ainda podem ser aplicados a instâncias usando contas de serviço personalizadas programaticamente.
Você pode ver quais scopes estão atribuídos consultando:
Os escopos anteriores são os gerados por default usando gcloud para acessar dados. Isso ocorre porque quando você usa gcloud você primeiro cria um token OAuth e depois o utiliza para contatar os endpoints.
O escopo mais importante desses potencialmente é cloud-platform, que basicamente significa que é possível acessar qualquer serviço no GCP.
Você pode encontrar uma lista de todos os escopos possíveis aqui.
Se você tiver credenciais de navegador gcloud, é possível obter um token com outros escopos, fazendo algo como:
Terraform IAM Policies, Bindings and Memberships
Como definido pelo terraform em https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam usando terraform com GCP, existem diferentes maneiras de conceder a um principal acesso a um recurso:
Memberships: Você define principals como membros de roles sem restrições sobre o role ou os principals. Você pode colocar um usuário como membro de um role e depois colocar um grupo como membro do mesmo role e também definir esses principals (usuário e grupo) como membros de outros roles.
Bindings: Vários principals podem ser vinculados a um role. Esses principals ainda podem ser vinculados ou ser membros de outros roles. No entanto, se um principal que não está vinculado ao role for definido como membro de um role vinculado, na próxima vez que a binding for aplicada, a membership desaparecerá.
Policies: Uma policy é autoritativa, ela indica roles e principals e, então, esses principals não podem ter mais roles e esses roles não podem ter mais principals a menos que essa policy seja modificada (nem mesmo em outras policies, bindings ou memberships). Portanto, quando um role ou principal é especificado na policy, todos os seus privilégios são limitados por essa policy. Obviamente, isso pode ser contornado caso o principal tenha a opção de modificar a policy ou permissões de escalonamento de privilégios (como criar um novo principal e vinculá-lo a um novo role).
Referências
Last updated
