CIEM: por que "quem pode fazer o quê na nuvem" virou pergunta que ninguém responde rápido

Peça pro time de plataforma responder, agora, quantas identidades — humanas e de máquina — têm permissão equivalente a administrador em cada provedor de nuvem que a empresa usa. Na maioria das empresas com ambiente multi-cloud de alguns anos, a resposta demora, e quando chega, costuma vir com ressalva: "isso é o que sabemos hoje".

Isso não é falha de disciplina — é resultado natural de como permissão de nuvem é concedida: rápido, sob demanda, quase sempre mais ampla do que o necessário porque é mais fácil pedir acesso de sobra do que pedir de novo depois. O problema é que ninguém revisa essa permissão pra reduzir depois que o projeto termina.

Por que permissão de nuvem cresce sem ninguém perceber

Cada novo serviço, papel ou política de acesso adiciona permissão ao ambiente — e cada provedor de nuvem tem seu próprio modelo de entitlement, o que torna quase impossível ter uma visão unificada sem ferramenta dedicada. Multiplique isso por AWS, Azure e GCP rodando em paralelo, cada um com dezenas de papéis criados ao longo de anos, e o resultado é uma superfície de permissão que cresce continuamente e nunca encolhe.

Diferente de outras formas de dívida técnica, essa não gera erro visível no dia a dia — o sistema continua funcionando normalmente com permissão de sobra. É exatamente por isso que ninguém prioriza corrigir, até o momento em que uma credencial com privilégio esquecido é comprometida.

O problema não é dar acesso, é nunca tirar

Conceder acesso é rápido e tem dono claro: alguém pede, alguém aprova. Remover acesso não usado não tem o mesmo gatilho — não existe momento natural em que alguém é forçado a revisar se aquela permissão de seis meses atrás ainda faz sentido. O resultado é o que o setor chama de "shadow admin": identidade com privilégio efetivo de administrador que ninguém decidiu conceder de propósito, resultado de acúmulo de permissões menores combinadas.

CIEM vs. IAM tradicional: o que muda

Gestão de identidade tradicional responde "quem é essa pessoa e ela está autenticada". CIEM (cloud infrastructure entitlement management) responde uma pergunta diferente e mais difícil: "o que essa identidade, já autenticada, realmente pode fazer, em quais recursos, e ela usou essa permissão nos últimos noventa dias". Essa segunda pergunta é a que revela o entitlement acumulado que nenhum processo de IAM tradicional captura sozinho.

Isso complementa diretamente o trabalho já necessário em identidade de máquina — CIEM é a camada que mostra, na prática, quanto dessas credenciais de máquina têm permissão muito além do que a função técnica exige.

O exercício que revela o tamanho do problema

Rodar um relatório de permissão não utilizada nos últimos noventa dias, por identidade, em cada provedor de nuvem, normalmente revela um número desconfortável: boa parte das permissões concedidas simplesmente nunca foi exercida. Isso não significa necessariamente má-fé ou erro — significa que "conceder mais por segurança" virou hábito padrão de provisionamento, sem processo de revisão correspondente.

Por onde começar sem travar a operação

O caminho mais seguro não é revogar permissão em massa — é começar por relatório, não por ação. Mapear entitlement não utilizado, priorizar identidades com privilégio mais crítico, e revisar com o dono de cada uma antes de qualquer revogação. Essa disciplina de revisão contínua é extensão natural da mesma arquitetura de identidade como novo perímetro — só que aplicada especificamente ao que cada identidade pode fazer dentro da nuvem, não só a como ela se autentica.

Acesso não utilizado é risco não contabilizado

Toda permissão concedida e nunca usada é risco que já existe no ambiente, mesmo que ninguém tenha explorado ainda. A UNIQ ajuda clientes a mapear e priorizar esse entitlement acumulado como parte da arquitetura de Cloud & SaaS e Identity & Access, antes que alguém de fora encontre a permissão esquecida primeiro.