Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
O 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 de anexo específicos para políticas e permissões.
Em um nível alto, parece assim:
Uma máquina virtual (chamada de Instância de Computação) é um recurso. Um recurso reside em um projeto, provavelmente ao lado de outras Instâncias de Computação, buckets de armazenamento, etc.
É 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ê-lo para fora da organização primeiro. Para mais informações, consulte isso.
Permitem centralizar o controle sobre os recursos em 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 diretrizes 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.
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 recursos recém-criados.
Desabilitar a criação de contas de serviço.
Existem muitas outras restrições que oferecem controle detalhado sobre os recursos da sua organização. Para mais informações, veja a lista de todas as restrições do Serviço de Política de Organização.
Estes são como políticas IAM na AWS, pois cada papel contém um conjunto de permissões.
No entanto, ao contrário da AWS, não há um repositório centralizado de papéis. Em vez disso, recursos dão X papéis de acesso a Y principais, 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 isso significa que a única maneira de descobrir quais permissões um principal tem é perguntar a cada recurso a quem ele está concedendo 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 papéis no IAM:
Papéis Básicos/Primitivos, que incluem os papéis de Proprietário, Editor e Visualizador que existiam antes da introdução do IAM.
Papéis Predefinidos, que fornecem acesso granular para um serviço específico e são gerenciados pelo Google Cloud. Existem muitos papéis predefinidos, você pode ver todos eles com os privilégios que possuem aqui.
Papéis Personalizados, 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 um papel tem uma permissão, você pode pesquisar a permissão aqui e ver quais papéis a possuem.
Você também pode pesquisar aqui papéis predefinidos oferecidos por cada produto. Note que alguns papéis não podem ser anexados a usuários e apenas a SAs devido a algumas permissões que contêm. Além disso, note que as permissões só terão efeito se estiverem anexadas ao serviço relevante.
Ou verifique se um papel personalizado pode usar uma permissão específica aqui.
GCP - IAM, Principals & Org Policies EnumNa 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 os usuários e grupos do Workspaces em https://admin.google.com.
MFA pode ser forçada para usuários do Workspaces, no entanto, um atacante pode usar um token para acessar o GCP via cli que não estará protegido por MFA (ele será protegido por MFA apenas quando o usuário fizer login para gerá-lo: gcloud auth login).
Quando uma organização é criada, vários grupos são fortemente sugeridos para serem criados. Se você gerenciar algum deles, pode ter comprometido toda ou uma parte importante da organização:
Grupo | Função |
| Administrar qualquer recurso que pertença à organização. Atribua este papel com moderação; os administradores da organização têm acesso a todos os seus recursos do Google Cloud. Como alternativa, devido a essa função ser 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 em 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. Consulte o guia de fundamentos de segurança do Google Cloud para mais informações sobre como planejar 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 em 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 em nuvem. |
| Revisar configurações de rede. |
| Visualizar logs de auditoria. |
| Administrar o Security Command Center. |
| Gerenciar segredos no Secret Manager. |
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.
Estas 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 o papel IAM de compute.instanceAdmin, mas a instância que você invadiu foi limitada com a restrição de escopo de https://www.googleapis.com/auth/compute.readonly. Isso impediria que você fizesse quaisquer alterações usando o token OAuth que é automaticamente atribuído à sua instância.
É semelhante aos papéis 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 por meio de 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 contas de serviço personalizadas, que terão a seguinte aparência:
Existem 2 maneiras principais de acessar o GCP como uma conta de serviço:
Via tokens OAuth: Esses são tokens que você obterá de lugares como endpoints de metadados ou roubando requisições http e são limitados pelos escopos de acesso.
Chaves: Esses são pares de chaves públicas e privadas que permitirão que você assine requisições como a conta de serviço e até mesmo gere tokens OAuth para realizar ações como a conta de serviço. Essas chaves são perigosas porque são mais complicadas de limitar e controlar, por isso o GCP recomenda não gerá-las.
Note que toda vez que uma SA é criada, o GCP gera uma chave para a conta de serviço que o usuário não pode acessar (e não será listada na aplicação web). De acordo com este tópico, essa chave é usada internamente pelo GCP para dar acesso aos endpoints de metadados para gerar os tokens OAuth acessíveis.
Os escopos de acesso são anexados aos tokens OAuth gerados para acessar os endpoints da API do GCP. Eles restrigem 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 acesso a esse recurso, o token não pode ser usado para (ab)usar esses privilégios.
O Google na verdade recomenda que os escopos de acesso não sejam usados e que se confie totalmente no IAM. O portal de gerenciamento web realmente impõe isso, mas os escopos de acesso ainda podem ser aplicados a instâncias usando contas de serviço personalizadas programaticamente.
Você pode ver quais escopos estão atribuídos consultando:
Os escopos anteriores são os gerados por padrão usando gcloud para acessar dados. Isso ocorre porque, ao usar gcloud, você primeiro cria um token OAuth e, em seguida, o utiliza para contatar os endpoints.
O escopo mais importante entre eles é 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:
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:
Membros: Você define principais como membros de papéis sem restrições sobre o papel ou os principais. Você pode colocar um usuário como membro de um papel e, em seguida, colocar um grupo como membro do mesmo papel e também definir esses principais (usuário e grupo) como membros de outros papéis.
Vínculos: Vários principais podem ser vinculados a um papel. Esses principais ainda podem ser vinculados ou ser membros de outros papéis. No entanto, se um principal que não está vinculado ao papel for definido como membro de um papel vinculado, na próxima vez que o vínculo for aplicado, a associação desaparecerá.
Políticas: Uma política é autoritativa, indica papéis e principais e, então, esses principais não podem ter mais papéis e esses papéis não podem ter mais principais a menos que essa política seja modificada (nem mesmo em outras políticas, vínculos ou membros). Portanto, quando um papel ou principal é especificado na política, todos os seus privilégios são limitados por essa política. Obviamente, isso pode ser contornado caso o principal tenha a opção de modificar a política ou permissões de escalonamento de privilégios (como criar um novo principal e vinculá-lo a um novo papel).
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
