FAQ MSP: um segredo de principal de serviço permanente não é identidade de carga

As contas de automatização e as integrações autenticam-se frequentemente com um segredo de cliente de principal de serviço: uma cadeia longa, válida durante meses, que qualquer script ou engenheiro com acesso a ela pode utilizar para agir como essa identidade. Adicionar autenticação multifator ao lado humano de uma conta não altera isso; o segredo em si continua a ser uma credencial permanente com o seu próprio raio de impacto.

Porque é que os segredos de cliente são tratados como legado

A própria orientação da Microsoft é explícita ao afirmar que os principais de serviço com segredos de cliente devem ser tratados como uma abordagem legada, a substituir por identidades geridas ou federadas sempre que o ambiente de alojamento o suportar. Um segredo de cliente só deve existir quando uma carga de trabalho não consegue, de facto, utilizar uma credencial mais forte. O problema não é que os segredos sejam impossíveis de proteger — é que têm de ser armazenados em algum lugar, renovados segundo um calendário e revogados manualmente se forem divulgados, e cada um desses passos é um local para um erro.

O que a federação de identidades de carga de trabalho elimina

A federação de identidades de carga de trabalho permite que uma carga de trabalho externa — um pipeline de CI/CD, um cluster Kubernetes, um script executado fora do Azure — confie em tokens do seu próprio fornecedor de identidade e os troque por tokens de acesso de curta duração do Microsoft Entra, sem que qualquer segredo seja alguma vez gerado, armazenado ou rotacionado. A comparação da Microsoft entre os três modelos é direta: os principais de serviço federados e as identidades geridas são livres de segredos e funcionam em ambientes alojados, autoalojados e no local, enquanto os principais de serviço baseados em segredos não são livres de segredos e continuam a acarretar o risco operacional que acompanha qualquer credencial de longa duração.

Para um MSP que gere muitos inquilinos de clientes

A dimensão do inquilino importa tanto como o tipo de credencial. Um único principal de serviço partilhado entre vários inquilinos de clientes transforma um segredo divulgado num incidente entre clientes; a identidade deve estar vinculada ao âmbito de um único inquilino, independentemente do modelo de credencial em utilização. Onde a federação ainda não for possível, trate o segredo de cliente como um risco permanente: faça um inventário de onde é utilizado, defina a sua expiração para 90 dias ou menos e agende a sua remoção assim que a federação estiver implementada.

Fontes: Microsoft Learn — Workload identity federation, Microsoft Learn — Service principals and managed identities.