GCP - Basic Information
Hierarquia de Recursos
O Google Cloud utiliza uma Hierarquia de Recursos que é semelhante, conceitualmente, à de um sistema de arquivos tradicional. Isso fornece um fluxo lógico pai/filho com pontos de anexo específicos para políticas e permissões.
Em um nível alto, parece com isso:
Uma máquina virtual (chamada de Instância de Cálculo) é um recurso. Um recurso reside em um projeto, provavelmente ao lado de outras Instâncias de Cálculo, buckets de armazenamento, 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, consulte este link.
Políticas de Organização
Permitem centralizar o controle sobre os recursos de nuvem da sua organização:
Centralize o controle para configurar restrições sobre como os recursos da sua organização podem ser usados.
Defina e estabeleça limites para que as equipes de desenvolvimento permaneçam dentro dos limites de conformidade.
Ajude os proprietários de projetos e suas equipes a se moverem rapidamente sem se preocupar em violar a conformidade.
Essas políticas podem ser criadas para afetar toda a organização, pasta(s) ou projeto(s). Os descendentes do nó hierárquico de recursos direcionado herdam a política da organização.
Para definir uma política de organização, você escolhe uma restrição, que é um tipo específico 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 as 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 de Identidade e Gerenciamento de Acesso.
Restringir a localização física de recursos recém-criados.
Desativar 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, consulte a lista de todas as restrições de serviço de Política de Organização.
Políticas de Organização Padrão
Funções do IAM
Elas 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á um repositório centralizado de funções. Em vez disso, os recursos concedem funções de acesso X a princípios 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 isso significa que a única maneira de descobrir quais permissões um princípio tem é perguntar a cada recurso para 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 funções no IAM:
Funções Básicas/Primitivas, que incluem as funções de Proprietário, Editor e Visualizador 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 pesquisar a permissão aqui e ver quais funções a possuem.
Você também pode pesquisar 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 por causa de algumas permissões que contêm. Além disso, observe que as permissões só terão efeito se forem atribuídas ao serviço relevante.
Ou verifique se uma função personalizada pode usar uma permissão específica aqui.
pageGCP - IAM, Principals & Org Policies EnumUtilizadores
No console GCP não há gestão de Utilizadores ou Grupos, isso é feito no Google Workspace. No entanto, é possível sincronizar um provedor de identidade diferente no Google Workspace.
Pode aceder aos utilizadores e grupos do Workspace em https://admin.google.com.
O MFA pode ser forçado para os utilizadores do Workspace, no entanto, um atacante poderia usar um token para aceder ao GCP via cli que não estará protegido por MFA (estará protegido por MFA apenas quando o utilizador fizer login para gerá-lo: gcloud auth login).
Grupos
Quando uma organização é criada, é fortemente sugerido criar vários grupos. Se gerir algum deles, poderá comprometer 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. Alternativamente, devido a esta 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 na nuvem. |
| Configurar contas de faturação e monitorizar a sua utilização. |
| Desenhar, codificar e testar aplicações. |
| Estabelecer e gerir políticas de segurança para toda a organização, incluindo gestão de acesso e políticas de restrição da organização. Consulte o guia de fundamentos de segurança do Google Cloud para obter mais informações sobre o planeamento da infraestrutura de segurança do Google Cloud. |
| Criar ou gerir pipelines de ponta a ponta que suportam integração e entrega contínuas, monitorização e provisionamento de sistemas. |
| |
| |
| |
| Monitorizar os gastos em projetos. Os membros típicos fazem parte da equipa financeira. |
| Rever informações de recursos em toda a organização do Google Cloud. |
| Rever segurança na nuvem. |
| Rever configurações de rede. |
| Ver registos de auditoria. |
| Administrar o Security Command Center. |
| Gerir segredos no Secret Manager. |
Política de Palavras-passe Padrão
Impor palavras-passe fortes
Entre 8 e 100 caracteres
Sem reutilização
Sem expiração
Se as pessoas estiverem a aceder ao Workspace através de um fornecedor terceirizado, estes requisitos não são aplicados.
Contas de Serviço
Estes são os princípios aos quais os recursos podem estar anexados e aceder para interagir facilmente com o GCP. Por exemplo, é possível aceder ao token de autenticação de uma Conta de Serviço anexada a uma VM nos metadados.
É possível encontrar alguns conflitos ao utilizar tanto IAM e escopos de acesso. Por exemplo, a sua conta de serviço pode ter a função IAM de compute.instanceAdmin mas a instância que comprometeu foi limitada com a limitação de escopo de https://www.googleapis.com/auth/compute.readonly. Isso impediria que fizesse quaisquer alterações usando o token OAuth atribuído automaticamente à 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 de permitir via uma política).
Várias das contas de serviço que encontrará são realmente geradas automaticamente pelo GCP quando 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:
Escopos de Acesso
Os escopos de acesso 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 escopos de acesso não sejam usados e que se confie totalmente no IAM. O portal de gerenciamento da web na verdade faz cumprir isso, mas os escopos de acesso ainda podem ser aplicados às 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 ao usar o gcloud para acessar dados. Isso ocorre porque ao usar o gcloud você primeiro cria um token OAuth e depois o utiliza para entrar em contato com os endpoints.
O escopo mais importante dentre esses potencialmente é o cloud-platform, o 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 do gcloud, é possível obter um token com outros escopos, fazendo algo como:
Políticas IAM do Terraform, Vínculos e Associações de Membros
Conforme definido pelo terraform em https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam usando o terraform com GCP, existem diferentes maneiras de conceder acesso a um principal sobre um recurso:
Associações de Membros: Você define principais como membros de funções sem restrições sobre a função ou os principais. Você pode colocar um usuário como membro de uma função e depois colocar um grupo como membro da mesma função e também definir esses principais (usuário e grupo) como membros de outras funções.
Vínculos: Vários principais podem ser vinculados a uma função. Esses principais ainda podem ser vinculados ou ser membros de outras funções. No entanto, se um principal que não está vinculado à função for definido como membro de uma função vinculada, na próxima vez que o vínculo for aplicado, a associação desaparecerá.
Políticas: Uma política é autoritativa, indica funções e principais e então, esses principais não podem ter mais funções e essas funções não podem ter mais principais a menos que essa política seja modificada (nem mesmo em outras políticas, vínculos ou associações). Portanto, quando uma função ou principal é especificado na política, todos os seus privilégios são limitados por essa política. Obviamente, isso pode ser contornado no caso em que o principal recebe 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 uma nova função).
Referências
Última actualización
