Fundamentos de IAM em Nuvem: GCP vs Azure
Identity and Access Management (IAM) é o pilar central da segurança em qualquer infraestrutura em nuvem. Tanto Google Cloud Platform (GCP) quanto Microsoft Azure implementam modelos baseados em princípios semelhantes, mas com diferenças significativas em nomenclatura e implementação que precisamos compreender profundamente.
No GCP, o modelo IAM opera através de três conceitos principais: identidades (quem), papéis (o que pode fazer) e recursos (sobre o quê). Esse design é elegante porque separa completamente a autenticação da autorização. No Azure, o modelo é similar mas utiliza a terminologia Azure AD (Entra ID) para identidades, roles para permissões, e scope para delimitar em qual nível (subscription, resource group, recurso) essa permissão se aplica. A diferença fundamental é que Azure trabalha com herança de permissões por padrão, enquanto GCP requer uma abordagem mais explícita.
Um detalhe crítico que muitos desenvolvedores ignoram: no GCP, quando você atribui um papel a uma identidade em um projeto, automaticamente essa permissão se estende a todos os recursos dentro daquele projeto. No Azure, você precisa ser explícito ao atribuir em cada nível (subscription → resource group → recurso específico). Essa diferença impacta diretamente sua estratégia de segurança.
Estrutura IAM no GCP: Papéis, Permissões e Recursos
Organização Hierárquica de Recursos
O GCP estrutura recursos em uma hierarquia clara: Organização → Pastas → Projetos → Recursos. Essa hierarquia é fundamental para aplicar políticas de IAM de forma escalável. Quando você define uma política em um nível superior (por exemplo, na pasta), ela é automaticamente herdada pelos níveis inferiores. Isso permite que você estabeleça governança global sem precisar configurar cada recurso individualmente.
A melhor prática é sempre usar essa hierarquia. Se sua organização tem 50 projetos, não configure IAM em cada um — configure na pasta parent e deixe a herança fazer o trabalho. Você economiza tempo e reduz inconsistências.
Papéis Predefinidos vs Customizados
O GCP oferece três tipos de papéis: Basic (Editor, Viewer, Owner), Predefinidos (específicos por serviço) e Customizados. Os papéis básicos são amplos demais para produção — nunca use Editor em produção. Os papéis predefinidos são a melhor opção na maioria dos casos porque são mantidos pelo GCP e incluem as permissões apropriadas.
Papéis customizados devem ser criados apenas quando nenhum predefinido se adequa ao seu caso. Aqui está como criar um papel customizado que permite apenas ler e listar buckets S3:
from google.cloud import iam_v1
from google.api_core import gapic_v1
# Criar um papel customizado para auditoria de armazenamento
credentials = None # Use Application Default Credentials
client = iam_v1.IAMClient(credentials=credentials)
role_body = {
"title": "Storage Auditor",
"description": "Pode listar e ler buckets, mas não modificar",
"includedPermissions": [
"storage.buckets.get",
"storage.buckets.list",
"storage.objects.get",
"storage.objects.list"
]
}
organization_id = "123456789"
request = iam_v1.CreateRoleRequest(
parent=f"organizations/{organization_id}",
role=iam_v1.Role(
title=role_body["title"],
description=role_body["description"],
included_permissions=role_body["includedPermissions"]
),
role_id="storageAuditor"
)
response = client.create_role(request=request)
print(f"Papel criado: {response.name}")
Este código cria um papel que só permite leitura de armazenamento. Note que estamos sendo explícito sobre quais permissões incluir — nada de "tudo ou nada".
Vinculação de Papéis a Identidades
Após criar o papel, você precisa vinculá-lo a uma identidade (usuário, grupo de serviço ou service account). A vinculação ocorre através de uma política de IAM, que é essencialmente um binding entre uma identidade e um papel em um recurso.
from google.cloud import resourcemanager_v3
import google.auth
# Obter credenciais e projeto
credentials, project_id = google.auth.default()
client = resourcemanager_v3.ProjectsClient(credentials=credentials)
project_name = f"projects/{project_id}"
# Obter a política atual
policy_request = resourcemanager_v3.GetIamPolicyRequest(resource=project_name)
policy = client.get_iam_policy(request=policy_request)
# Encontrar ou criar uma binding para o papel
role = "roles/storage.admin"
member = "serviceAccount:audit-sa@project_id.iam.gserviceaccount.com"
binding_found = False
for binding in policy.bindings:
if binding.role == role:
if member not in binding.members:
binding.members.append(member)
binding_found = True
break
if not binding_found:
new_binding = resourcemanager_v3.Binding(
role=role,
members=[member]
)
policy.bindings.append(new_binding)
# Atualizar a política
set_policy_request = resourcemanager_v3.SetIamPolicyRequest(
resource=project_name,
policy=policy
)
updated_policy = client.set_iam_policy(request=set_policy_request)
print(f"Política atualizada com sucesso")
Este padrão é a base de toda automação IAM no GCP. Você obtém a política atual, modifica os bindings e escreve de volta. Sempre faça isso de forma defensiva — verifique se a binding já existe antes de adicionar.
Segurança no Azure: RBAC, Entra ID e Security Posture
Azure RBAC: Role-Based Access Control com Scope
O Azure implementa controle de acesso baseado em papéis (RBAC) através do Azure RBAC, que funciona em três níveis de escopo: Subscription, Resource Group e Recurso Individual. Diferentemente do GCP onde a herança é automática, no Azure você pode estar explicitamente em qualquer nível, e as permissões herdam para baixo.
A estrutura é: Identidade + Papel + Escopo = Atribuição de Papel. Uma identidade pode ter diferentes papéis em diferentes escopos simultaneamente. Por exemplo, você pode ser "Contributor" em um resource group e apenas "Reader" em outro, tudo na mesma subscription.
Integração com Azure Entra ID (Ex-Azure AD)
Azure Entra ID (anteriormente Azure AD) é o serviço de identidade central. É onde você cria usuários, grupos, aplicações (service principals) e gerencia autenticação multifator. A integração entre Entra ID e RBAC é automática — quando você cria um usuário no Entra ID e o adiciona a uma atribuição de função, o sistema valida a identidade no Entra ID antes de conceder acesso.
Para trabalhar com Entra ID programaticamente:
from azure.identity import DefaultAzureCredential
from azure.mgmt.authorization import AuthorizationManagementClient
from azure.mgmt.authorization.models import RoleAssignment
import uuid
# Autenticar com credenciais padrão
credential = DefaultAzureCredential()
client = AuthorizationManagementClient(credential, subscription_id="seu-subscription-id")
# Obter ID do usuário do Entra ID (você precisaria consultar Entra ID primeiro)
# Aqui estamos usando um exemplo hardcoded
principal_id = "00000000-0000-0000-0000-000000000000" # Substitua pelo ID real
# Definir escopo
subscription_id = "seu-subscription-id"
scope = f"/subscriptions/{subscription_id}"
# Criar atribuição de papel
role_definition_id = "/subscriptions/seu-subscription-id/providers/Microsoft.Authorization/roleDefinitions/acded500-df8b-490d-83e8-e06efdd27ef9" # Papel de Contributor
role_assignment = RoleAssignment(
properties={
"roleDefinitionId": role_definition_id,
"principalId": principal_id,
"principalType": "User"
}
)
# Gerar um GUID único para a atribuição
assignment_name = str(uuid.uuid4())
response = client.role_assignments.create(
scope=scope,
role_assignment_name=assignment_name,
parameters=role_assignment
)
print(f"Atribuição criada: {response.id}")
Note que no Azure você precisa conhecer o principalId (que vem do Entra ID) e o roleDefinitionId (que identifica qual papel você está atribuindo). Essa explicitação é mais verbose que o GCP, mas oferece maior controle.
Políticas Condicais no Azure
Uma funcionalidade poderosa do Azure é o Conditional Access, que adiciona camadas extras de segurança baseadas em condições como localização, dispositivo e risco detectado. Embora não seja strictamente IAM, é parte da estratégia de identidade e acesso.
from azure.identity import DefaultAzureCredential
from azure.mgmt.authorization import AuthorizationManagementClient
# Exemplo conceitual: aplicar uma política de acesso condicional
# Rejeitar acesso a usuários fora da rede corporativa tentando acessar dados sensíveis
conditional_access_policy = {
"displayName": "Block access from non-corporate networks",
"conditions": {
"locations": {
"includeLocations": ["All"],
"excludeLocations": ["AllTrusted"] # Exclui locais confiáveis
},
"applications": {
"includeApplications": ["00000003-0000-0000-c000-000000000000"] # Microsoft Graph API
}
},
"grantControls": {
"operator": "OR",
"builtInControls": ["block"]
},
"state": "enabledForReportingButNotEnforced" # Começa em modo relatório
}
print("Política condicional configurada (modo conceitual)")
Este padrão não é totalmente executável aqui porque exige o Graph API, mas ilustra como políticas condicionais funcionam: você define condições e ações correspondentes.
Microsoft Defender e GCP Security Command Center: Monitoramento Contínuo
Microsoft Defender: Proteção Integrada do Azure
Microsoft Defender for Cloud é a solução de proteção de segurança nativa do Azure. Ela oferece descoberta contínua de recursos, análise de vulnerabilidades, proteção contra ameaças e conformidade regulatória. O Defender trabalha em três camadas: detecção de ameaças, gerenciamento de vulnerabilidades e avaliação de conformidade.
Quando você ativa o Defender, ele automaticamente começa a examinar seus recursos Azure em busca de configurações de segurança inadequadas, vulnerabilidades em imagens de contêiner e comportamento anômalo de máquinas virtuais.
from azure.identity import DefaultAzureCredential
from azure.mgmt.security import SecurityCenter
from azure.mgmt.security.models import SecurityContact
credential = DefaultAzureCredential()
client = SecurityCenter(credential, subscription_id="seu-subscription-id")
# Obter status do Defender para Cloud
settings = client.security_settings.list()
for setting in settings:
print(f"Configuração: {setting.name} - Valor: {setting.value}")
# Configurar contato de segurança para alertas críticos
security_contact = SecurityContact(
name="securityteam@company.com",
email="securityteam@company.com",
phone="+55-11-98765-4321",
alerts_notifications="On",
alerts_to_admins="On"
)
contact_response = client.security_contacts.create(
scope="subscriptions/seu-subscription-id",
name="securityContact1",
parameters=security_contact
)
print(f"Contato de segurança criado: {contact_response.email}")
O Defender fornece recomendações acionáveis. Por exemplo, se detecta que uma máquina virtual tem acesso SSH aberto a qualquer pessoa na internet, ele recomenda limitar o acesso a IPs específicos.
GCP Security Command Center: Visibilidade Centralizada
O Security Command Center (SCC) do GCP é a consola central para monitorar a segurança. Ele agrega descobertas de múltiplas fontes: varreduras de vulnerabilidade, configurações de IAM inadequadas, malware detectado e conformidade regulatória. Diferentemente do Defender que é nativo do Azure, o SCC do GCP é agnóstico — você pode integrá-lo com recursos multi-cloud.
O SCC opera em dois modos: Standard (gratuito, descobertas básicas) e Premium (descobertas avançadas, análise contínua). A maioria das organizações usa Premium em produção.
from google.cloud import securitycenter_v1
import json
# Inicializar cliente do SCC
client = securitycenter_v1.SecurityCenterClient()
organization_id = "123456789"
parent = f"organizations/{organization_id}"
# Listar todas as descobertas de segurança
request = securitycenter_v1.ListFindingsRequest(
parent=parent,
filter='severity = "HIGH" OR severity = "CRITICAL"'
)
findings = client.list_findings(request=request)
print("Descobertas críticas e altas:")
for finding_result in findings:
finding = finding_result.finding
print(f"- {finding.display_title}")
print(f" Recurso: {finding.resource.name}")
print(f" Severidade: {finding.severity}")
print(f" Estado: {finding.state}")
print()
Este código lista todas as descobertas de segurança críticas e altas. O SCC filtra por severidade — você pode ajustar esse filtro conforme necessário. A beleza do SCC é que ele centraliza descobertas de múltiplos serviços (Cloud Asset Inventory, Container Scanning, etc.).
Integração entre Descobertas e Remediação Automática
Tanto Defender quanto SCC permitem remediação automática de certos problemas. No SCC, você pode configurar workflows automáticos quando uma descoberta é detectada:
from google.cloud import securitycenter_v1
client = securitycenter_v1.SecurityCenterClient()
# Exemplo: Configurar notificação automática via Pub/Sub quando descoberta crítica é encontrada
# Isso é feito através da API, associando uma descoberta a um tópico Pub/Sub
notification_config = securitycenter_v1.NotificationConfig(
description="Notificar sobre descobertas críticas",
pubsub_topic="projects/seu-projeto/topics/security-alerts",
streaming_config=securitycenter_v1.NotificationConfig.StreamingConfig(
filter='severity = "CRITICAL"'
)
)
organization_id = "123456789"
parent = f"organizations/{organization_id}"
request = securitycenter_v1.CreateNotificationConfigRequest(
parent=parent,
notification_config=notification_config,
config_id="critical-findings-notify"
)
response = client.create_notification_config(request=request)
print(f"Notificação configurada: {response.name}")
Quando uma descoberta crítica é detectada, o SCC publica uma mensagem no Pub/Sub, que pode disparar uma Cloud Function para remediar automaticamente (por exemplo, fechar uma porta aberta ou revitalizar credenciais expostas).
Boas Práticas e Estratégia Defensiva
Princípio do Menor Privilégio em Ambientes Híbridos
Independentemente se você usa GCP ou Azure, o princípio fundamental é conceder apenas as permissões necessárias para executar uma tarefa específica. Muitas organizações cometem o erro de atribuir papéis amplos "para não ter problemas depois". Isso aumenta a superfície de ataque exponencialmente.
A abordagem defensiva é: comece com nenhuma permissão, teste sua aplicação e adicione permissões conforme necessário até que funcione. Documente cada permissão e por que ela é necessária. Revise trimestralmente — identidades mudaram, pessoas saíram da empresa, projetos foram descontinuados.
Auditoria Contínua e Alertas
Configure logs de auditoria em ambos os provedores. No GCP, ative Cloud Audit Logs para rastrear quem fez o quê, quando e em qual recurso. No Azure, ative Activity Logs no nível da subscription. Esses logs devem ser exportados para um local central (por exemplo, um bucket separado ou armazenamento de longo prazo) para análise forense.
# GCP: Exportar logs de auditoria para BigQuery para análise
gcloud logging sinks create security-logs-sink \
bigquery.googleapis.com/projects/seu-projeto/datasets/security_logs \
--log-filter='severity >= WARNING'
# Azure: Exportar Activity Logs para Log Analytics
az monitor diagnostic-settings create \
--resource /subscriptions/seu-subscription-id \
--name "export-to-log-analytics" \
--logs '[{"category": "Administrative", "enabled": true}]' \
--workspace seu-workspace-resource-id
Rotação de Credenciais e Gestão de Chaves
Para service accounts (GCP) e service principals (Azure), implemente rotação automática de credenciais. Não deixe uma chave de API viva por mais de 90 dias. Use Secret Management — Google Secret Manager no GCP e Azure Key Vault no Azure.
from google.cloud import secretmanager
def create_secret(project_id, secret_id, secret_value):
client = secretmanager.SecretManagerServiceClient()
parent = f"projects/{project_id}"
secret = client.create_secret(
request={
"parent": parent,
"secret_id": secret_id,
"secret": {"replication": {"automatic": {}}},
}
)
version = client.add_secret_version(
request={
"parent": secret.name,
"payload": {"data": secret_value.encode("UTF-8")},
}
)
return version.name
# Usar assim:
secret_name = create_secret("seu-projeto", "db-password", "sua-senha-aqui")
print(f"Segredo criado: {secret_name}")
Nunca coloque senhas em código ou variáveis de ambiente — sempre recupere de um gerenciador de segredos.
Conclusão
Após dominar IAM no GCP e Azure, seus principais aprendizados devem ser: (1) O IAM é o alicerce da segurança em nuvem — negligenciar configuração adequada de papéis e permissões é o caminho mais rápido para uma violação; (2) Monitoramento contínuo através de Defender e SCC não é opcional, é obrigatório — você não consegue proteger o que não consegue ver, e descobertas precisam ser remediadas em horas, não dias. (3) Implementar o princípio do menor privilégio exige disciplina — é mais fácil conceder tudo e depois revogar do que começar restritivo, mas o caminho fácil resulta em ambientes completamente comprometidos.