Managed identities, service principals e más práticas a evitar

O problema que as managed identities resolvem

Antes das managed identities, uma aplicação que precisasse de aceder a um recurso do Azure (ex. Key Vault, Storage) tinha de guardar credenciais algures — num ficheiro de configuração, numa variável de ambiente — criando um segredo para gerir e rodar manualmente. As managed identities eliminam isto: a plataforma Azure gere e roda a credencial automaticamente, sem que nenhum código a veja.

Managed identity atribuída pelo sistema vs. pelo utilizador

• System-assigned — o ciclo de vida está ligado ao recurso (ex. uma VM): quando o recurso é eliminado, a identidade também é eliminada. Um recurso só pode ter uma.
• User-assigned — existe como um objeto independente do Azure, pode ser atribuída a múltiplos recursos, e sobrevive à eliminação de qualquer um deles individualmente.

Service principals

Uma managed identity é, tecnicamente, um tipo especial de service principal gerido automaticamente. Nem toda a identidade de aplicação precisa de ser managed identity — aplicações registadas manualmente (app registrations) também têm um service principal associado, mas com credenciais geridas pelo próprio developer (certificados ou client secrets), não pela plataforma.

Contas de utilizador para aplicações: uma anti-prática

Usar uma conta de utilizador normal (com password) para autenticar uma aplicação ou script automatizado é desaconselhado: fica sujeita a políticas pensadas para humanos (expiração de password, MFA), não aparece nos relatórios de aplicações, e não beneficia da rotação automática de credenciais das managed identities.

Managed service accounts

No mundo on-premises (Active Directory), o equivalente conceptual são as group Managed Service Accounts (gMSA) — contas de serviço com password gerida e rodada automaticamente pelo Active Directory, evitando o mesmo problema de segredos geridos manualmente.

Usar a identidade atribuída

Depois de atribuída a um recurso (ex. uma VM), a managed identity pode ser usada para obter um token do Microsoft Entra ID e aceder a outro recurso do Azure (ex. essa VM lê um segredo do Key Vault), desde que tenha as permissões RBAC do Azure necessárias atribuídas nesse recurso de destino.