Google Cloud para profissionais da AWS: gerenciamento

Atualizado em 17 de março de 2017

Compare os serviços de gerenciamento que a Amazon e o Google oferecem nos respectivos ambientes de nuvem. Se você já estiver familiarizado com a implementação do gerenciamento de identidade e acesso (IAM, na sigla em inglês) da Amazon Web Services (AWS), este artigo fornece uma introdução abrangente ao Google Cloud Identity and Access Management. O Google Cloud e a AWS oferecem soluções de IAM semelhantes. Você pode usar essas ferramentas para criar e gerenciar permissões para recursos de nuvem, inclusive dados e aplicativos.

Com a AWS e o Google Cloud, é possível conceder permissões a usuários, grupos e aplicativos. Com essas permissões, a entidade terá acesso claramente definido aos recursos da nuvem.

Veja na tabela a seguir um mapeamento geral dos termos e conceitos da AWS para os equivalentes do Google Cloud.

Conceito AWS Google Cloud
Identidade programática Papel de IAM (em inglês) e perfil da instância Conta de serviço do Cloud IAM
Identidade do usuário Gerenciada no IAM. Identidade federada ao sistema de gerenciamento de identidades externas. Gerenciada fora do IAM. Identidade federada ao sistema de gerenciamento de identidades externas.
Política Um documento que lista explicitamente as permissões. Uma lista de associações. Uma associação vincula uma lista de membros a um papel.
Anexo da política Política anexada a um usuário ou grupo do IAM ou a um recurso. Política anexada ao recurso.

Avaliação da política Negar por padrão. Negar por padrão.
Coleção de permissões Política Papel
Conjunto predefinido de permissões Políticas gerenciadas Papéis predefinidos
Auditoria de chamadas de IAM AWS CloudTrail Geração de registros de auditoria
Controle de versões Sim Não

Gerenciamento e encapsulamento de recursos

Esta seção ajuda você a entender como cada fornecedor de nuvem gerencia recursos.

Várias contas na AWS

Com a AWS, a prática recomendada é configurar várias contas para cada equipe. Você pode acabar atribuindo permissões e políticas em cada conta. Você pode reduzir a complexidade do gerenciamento de várias contas da AWS configurando o faturamento consolidado e implementando as organizações da AWS.

Como organizar projetos e políticas no Google Cloud

O Google Cloud oferece recursos de contêiner, como organizações, pastas e projetos, que permitem agrupar e organizar hierarquicamente outros recursos do Google Cloud, como tópicos do Pub/Sub e instâncias de máquina virtual (VMs) do Compute Engine. Essa organização hierárquica permite gerenciar aspectos comuns dos recursos, como controle de acesso e definições de configuração.

Todos os recursos do Google Cloud pertencem a um recurso do projeto e uma Conta do Google individual pode gerenciar vários projetos. É possível gerenciar os projetos individualmente. Você pode agrupar projetos semelhantes ou relacionados em pastas e gerenciá-los a partir delas. Além disso, é possível gerenciar pastas e projetos em um recurso da organização.

O diagrama a seguir mostra um exemplo de vários recursos e a respectiva organização hierárquica no Google Cloud. Para interagir com a maioria dos recursos do Google Cloud, você precisa fornecer as informações de identificação do projeto para cada solicitação.

Exemplo de uma hierarquia de recursos do Google Cloud.

Herança de políticas

Com a AWS, você pode especificar permissões com base no recurso, que se aplicam diretamente a recursos, ou especificar permissões para ações específicas que possam ser realizadas em um determinado recurso. A maneira como as permissões podem ser especificadas depende do serviço.

A herança de políticas de IAM do Google Cloud é complementada pela organização de recursos. No Google Cloud, os recursos são organizados hierarquicamente para que você defina as políticas de IAM a partir do nó da organização de forma descendente. Se você quiser ter políticas de IAM em toda a organização, atribua essas políticas ao recurso dela. Se você quiser definir políticas para várias equipes e projetos, use as pastas do Google Cloud para fazer isso. Em seguida, atribua permissões para envolvidos no projeto e, por fim, no nível do recurso dentro do projeto para um nível mais granular de controle.

Identidades

As identidades usadas para acessar recursos de nuvem são divididas em dois agrupamentos:

  • Identidades de usuário final, representadas pelos logins corporativos comuns. No caso da AWS, os usuários finais também podem ser representados pelo uso de contas do IAM.
  • Identidades programáticas, que permitem que o código do aplicativo acesse recursos de nuvem.

Identidades de usuário final na AWS

A AWS gerencia a conta raiz, que é um requisito para qualquer conta. A AWS fornece uma lista das práticas recomendadas para ajudar a proteger as chaves de acesso raiz da conta da AWS.

Para permitir o acesso aos seus recursos da AWS, você pode configurar usuários do IAM, que são identidades criadas na AWS, ou configurar a federação a partir do seu diretório corporativo. Você pode usar um provedor de identidade de terceiros. Ao configurar um provedor de identidade de terceiros a ser usado com a AWS, você precisa criar um papel de IAM e definir permissões para o papel. Quando um usuário federado faz login na AWS, o usuário é associado ao papel e recebe as permissões definidas no papel.

Acesso do usuário final no Google Cloud

Com o Google Cloud, existem duas opções principais para atribuir a propriedade do projeto:

  • É possível criar um projeto com um ou mais proprietários que tenham acesso completo aos recursos do projeto.
  • Os projetos não precisam de um proprietário explícito. Essa abordagem pode ser útil quando o projeto faz parte de uma organização e você quer que todos os projetos sejam de propriedade dessa organização.

O Cloud IAM não permite gerenciar identidades de usuário final, mas permite que você conceda acesso a usuários criados e gerenciados por outros meios. Ao usar o Cloud IAM, por padrão, você pode conceder acesso aos seguintes tipos de identidades:

  • Conta do Google
  • Conta de serviço
  • Grupo do Google
  • Domínio do G Suite

Os Grupos do Google são a maneira prática e recomendada de aplicar uma política de acesso a uma coleção de usuários. Você pode conceder e alterar controles de acesso para um grupo inteiro de uma só vez, em vez de conceder ou alterar controles de acesso para cada usuário ou conta de serviço individualmente. Também é fácil adicionar e remover membros de um Grupo do Google, em vez de atualizar uma política do Cloud IAM para fazer isso por você.

Se você ainda não usa um domínio do G Suite para gerenciar seus usuários, poderá federar o subconjunto existente de usuários operacionais de vários diretórios de usuários conhecidos, como o Active Directory. Essa abordagem permite usar suas identidades corporativas atuais. Você precisa verificar inicialmente o nome do domínio junto ao Google.

A tabela a seguir lista e descreve maneiras de federar usuários no Google Cloud.

Técnica de federação Descrição
Cloud Directory Sync Ferramenta fornecida pelo Google que funciona com a maioria dos serviços de diretório LDAP comercial e corporativo. Com o Cloud Directory Sync, é possível adicionar, mudar e excluir usuários, grupos e contatos que não sejam de funcionários para sincronizar os dados no domínio do Google Cloud com o servidor de diretório LDAP usando consultas LDAP. Os dados no servidor de diretório LDAP nunca são modificados nem comprometidos.
Conectores de identidade de terceiros Os conectores nativos com um provedor de identidade para aqueles que o fornecem. Conecta diretamente um provedor de identidade ao domínio provisionado no Google Cloud. Por exemplo:

  • Ping Federate
  • Okta
  • CA Siteminder
  • Azure AD
  • OpenIAM
  • Auth0
  • Oracle IAM
API do Google Apps Dá a uma organização controle programático do gerenciamento de usuário e grupo.

É possível adicionar as identidades, na forma de endereços de e-mail, aos Grupos do Google para conceder a eles acesso aos recursos do Google Cloud.

Identidades programáticas na AWS

Com a AWS, caso queira chamar as APIs da AWS em um aplicativo que não esteja sendo executado com recursos de computação da AWS, crie um usuário do IAM. Em seguida, faça o download das chaves apropriadas e use-as com o aplicativo para fazer chamadas às APIs da AWS.

Caso queira usar uma identidade programática em uma instância do EC2, você também precisa criar um perfil de instância anexado à instância. Esse perfil contém um papel de IAM e pode fornecer as credenciais do papel a um aplicativo em execução na instância.

Um papel de IAM permite que um usuário, grupo ou aplicativo de IAM em execução no EC2 ou em um dispositivo móvel pressuponha as permissões definidas pelo papel. As credenciais temporárias são criadas e fornecidas para a entidade que está pressupondo o papel.

O uso dos papéis de IAM também permite que os usuários de IAM mudem para um papel a fim de usar temporariamente as permissões desse papel durante a utilização do console. Quando isso acontece, os usuários abrem mão das permissões originais e assumem as permissões atribuídas ao papel. Quando deixam o papel, os usuários desistem dessas permissões.

Identidades programáticas no Google Cloud

Com o Google Cloud, uma conta de serviço é uma Conta do Google especial que os aplicativos podem usar para acessar os serviços do Google de modo programático. Essa conta pertence ao aplicativo ou a uma instância do Compute Engine, e não a um usuário final individual.

Uma conta de serviço pode conter pares de chaves da conta de serviço, usadas na autenticação com o Google. Uma chave de conta de serviço é um par de chaves pública/privada gerado pelo Google. O Google fica com a chave pública, e o usuário recebe a chave privada.

É possível criar contas de serviço personalizadas em projetos do Google Cloud usando o Console do Google Cloud, a API do Cloud Identity and Access Management ou a ferramenta de linha de comando gcloud.

Se você só pretende usar a conta de serviço com aplicativos executados nos serviços de computação do Google Cloud, não é necessário fazer o download das chaves privadas. Use as chaves gerenciadas pelo Google Cloud.

Uma das características das contas de serviço do Cloud IAM é que você pode tratá-las como um recurso ou uma identidade. A conta de serviço tem uma identidade, e você dá a ela permissões concedendo um papel para acessar um recurso, como um projeto.

Ao analisar uma conta de serviço como um recurso, é possível conceder permissão a um usuário para acessá-la, como você faria com outros recursos do Google Cloud. É possível conceder um papel de proprietário, editor, visualizador ou um papel indefinido serviceAccountUser a um usuário para acessar a conta de serviço. Um usuário que é um serviceAccountUser para uma conta de serviço pode acessar todos os recursos com as mesmas permissões a que a conta de serviço tem acesso. Trata-se de uma funcionalidade semelhante ao uso do papel de IAM abordado na seção anterior.

As chaves da conta de serviço podem ser chaves gerenciadas pelo usuário (você) ou chaves gerenciadas pelo Google Cloud.

É possível criar e gerenciar chaves gerenciadas pelo usuário usando o Console do Cloud, a API do Cloud IAM ou a ferramenta de linha de comando gcloud. Você é responsável por manter as chaves seguras e alterná-las.

As chaves gerenciadas pelo Google Cloud são usadas por serviços como o App Engine e o Compute Engine. Não é possível explicitamente criar ou fazer o download de uma chave gerenciada pelo Google Cloud. O Google gerencia as chaves e as alterna para você uma vez por dia.

Atribuição da permissão

Tanto o Google Cloud quanto a AWS usam os termos papel e política, mas os usos são um pouco diferentes. Essas diferenças podem causar confusão no mapeamento do AWS IAM para o Cloud IAM. Uma coleção de permissões no Google Cloud é chamada de papel, mas com a AWS ela é chamada de política.

Exemplo de permissão da AWS

Com a AWS, você especifica as permissões como uma ação, recurso e efeito na definição da política. Por exemplo, uma política da AWS que permite (o efeito) que alguém liste todos os buckets (a ação) em uma conta (o recurso) tem esta aparência:

{
  "Version": "2012-10-17",
  "Statement": {
  "Effect": "Allow",
  "Action": "s3:ListAllMyBuckets",
  "Resource": "*"
  }
}

As políticas de IAM da AWS que podem ser anexadas a vários usuários, grupos e papéis são chamadas de políticas gerenciadas. As políticas gerenciadas podem ser administradas pelo AWS, criadas e gerenciadas pelo AWS, ou administradas pelo cliente, criadas e gerenciadas na conta do AWS.

Exemplo de permissão do Google Cloud

O Google Cloud tem uma abordagem predefinida que prioriza o papel. Dessa maneira, um caso de uso comum, como listar todos os buckets em um projeto, é apenas uma questão de usar o papel de visualizador. Assim, esse papel precisa ser atribuído ao usuário ou ao grupo, e o documento resultante que associa usuários ou grupos ao papel é chamado de política. A definição de uma política é semelhante ao seguinte exemplo:

{
  "bindings": [
      {
     "role": "roles/viewer",
     "members": ["group:gcs-viewers@example.com"]
   }
  ]
}

Políticas da AWS

Com a AWS, além de poder anexar políticas a uma identidade, você pode anexar uma política a um recurso. Para políticas anexadas a um recurso, você precisa incorporar uma identidade ou um papel capaz de acessar o recurso dentro da política.

Na maioria dos casos, a AWS recomenda o uso de políticas gerenciadas. As recomendações para escolher entre políticas gerenciadas e políticas inline estão descritas na documentação da AWS.

Políticas do Google Cloud

Agora observe uma política do Google Cloud declarada em um arquivo JSON, chamado iam-gcs-access.json,, que concede o papel viewer a um grupo de usuários e o papel objectCreator a uma conta de serviço. Um aplicativo usa a conta de serviço para adicionar objetos a repositórios em um projeto. O exemplo a seguir ilustra como você pode criar várias associações membro/papel em uma única política.

{
    "bindings": [
    {
        "members": [
            "group:gcs-viewers@example.com"
        ],
        "role": "roles/viewer"
    },
    {
        "members": [
            "serviceAccount:123456789012-compute@developer.gserviceaccount.com"
        ],
        "role": "roles/storage.objectCreator"
    },
    ],
    "etag": "BwUjMhCsNvY=",
    "version": 1
}

Em seguida, essa política poderá ser vinculada ao recurso, que nesse caso é um projeto. Basta usar o Console do Cloud, o comando set-iam-policy na ferramenta gcloud ou a API. Para este exemplo, o comando gcloud tem esta aparência:

gcloud projects set-iam-policy [PROJECT_ID] iam-gcs-access.json

em que [PROJECT_ID] representa o ID do projeto do Google Cloud.

Isso se assemelha à maneira como você incorpora uma identidade ou um papel capaz de acessar o recurso dentro da política na AWS.

Como gerenciar políticas no Google Cloud

Você precisa tratar as políticas como trata o código: mantendo-as em um sistema de controle da versão com o restante dos ativos usados para definir o ambiente de nuvem. Caso você atualize as políticas, crie uma nova versão.

Embora a AWS tenha os dois tipos de política discutidos anteriormente, o Google Cloud tem apenas um, e você tem flexibilidade para gerenciar suas políticas usando o sistema de controle de versões apropriado. O Google Cloud oferece o Cloud Source Repositories, que são repositórios Git particulares e repletos de recursos hospedados no Google Cloud.

Se você já tem um repositório no GitHub ou no Bitbucket, pode conectá-lo ao seu repositório do Cloud Source Repositories. Os repositórios conectados e o Cloud Source Repositories são sincronizados automaticamente. O Cloud Source Repositories também oferece um editor de origem que pode ser usado para procurar, ver, editar e confirmar mudanças feitas em arquivos do repositório no Console do Cloud.

Se você preferir usar as soluções de controle de versão atuais, poderá fazer isso no Google Cloud.

Como testar e verificar permissões

Ao usar a AWS, você pode usar o IAM Policy Simulator, que permite testar e validar políticas novas e existentes e ver quais políticas foram definidas para um usuário, grupo ou recurso.

Com o Google Cloud, é possível usar o comando get-iam-policy gcloud para retornar a definição da política:

gcloud projects get-iam-policy [PROJECT_ID]

Você pode usar a definição retornada para ajudar a verificar quais políticas estão anexadas ao recurso. Também é possível usar o Console do Cloud para acessar um recurso específico e verificar as permissões.

Para verificar as permissões atribuídas a uma identidade, selecione a identidade no Console do Cloud e veja os papéis vinculados a ela. Também é possível fazer login usando essa identidade ou uma identidade de teste com as mesmas permissões para verificar o que ela pode acessar no Console do Cloud.

Propagação da permissão

Com a AWS, todas as políticas são avaliadas. A ordem em que as políticas são definidas não tem impacto discernível, uma vez que o resultado final será "permitido" ou "negado". Usando uma negação explícita, você pode modificar uma política ampla que pode permitir acesso a um amplo conjunto de recursos. Isso é descrito em detalhes em Como determinar se uma solicitação é permitida ou negada em uma conta (em inglês).

Com o Google Cloud, a política efetiva de um recurso é a união da política definida para o recurso com a herdada do pai dele. Como os papéis são concêntricos, a concessão de vários papéis para o mesmo usuário dá ao usuário as permissões do papel mais amplo concedido. Você pode ler alguns cenários de exemplo em Como usar a hierarquia de recursos para controle de acesso.

Auditoria de IAM

Para auditar uma atividade de IAM, a Amazon oferece o AWS CloudTrail, que grava e registra chamadas à API da AWS para a conta. O CloudTrail envia esses registros para uma conta do Amazon S3 que você especificou.

O Google Cloud oferece registros de auditoria do Cloud, que registram a atividade de administradores e o acesso aos dados. Esses dois streams são gerados pelos serviços do Google Cloud para que você possa determinar quem fez o quê, onde e quando nos projetos do Google Cloud.

As entradas de registros de auditoria individuais são mantidas por um período especificado no conjunto de operações do Google Cloud. Assim, é possível visualizar um resumo do painel das atividades recentes. Essas entradas são excluídas do conjunto de operações do Google Cloud após um período especificado. A política de cotas do Cloud Logging explica o tempo que as entradas de registro são mantidas. Não é possível excluir nem modificar registros de auditoria.

Os papéis do IAM do Logging permitem restringir o acesso apenas aos recursos relacionados ao registro em um projeto ou organização.

Para uma retenção mais longa, exporte entradas de registros de auditoria para um bucket do Cloud Storage, um conjunto de dados do BigQuery, um tópico do Pub/Sub ou qualquer combinação dos três.

A seguir

Confira os outros artigos do Google Cloud para profissionais da AWS: