MSP FAQ: un secret permanent al principalului de serviciu nu e identitate de workload

Conturile de automatizare și integrările se autentifică adesea cu un secret de client al principalului de serviciu: un șir lung, valabil luni de zile, pe care orice script sau inginer cu acces la el îl poate folosi pentru a acționa ca acea identitate. Adăugarea autentificării multifactor la partea umană a unui cont nu schimbă acest lucru; secretul în sine rămâne o credențială permanentă cu propria sa rază de impact.

De ce secretele de client sunt tratate ca abordare învechită

Ghidul oficial al Microsoft este explicit că principalii de serviciu cu secrete de client ar trebui tratați ca o abordare învechită, care trebuie înlocuită cu identități gestionate sau federate oriunde mediul de găzduire o permite. Un secret de client ar trebui să existe doar atunci când un workload chiar nu poate folosi o credențială mai puternică. Problema nu este că secretele sunt imposibil de securizat — ci că trebuie stocate undeva, rotite după un program și revocate manual dacă se scurg, iar fiecare dintre acești pași este un loc pentru o greșeală.

Ce elimină federația identității de workload

Federația identității de workload permite unui workload extern — o conductă CI/CD, un cluster Kubernetes, un script care rulează în afara Azure — să aibă încredere în tokenuri de la propriul furnizor de identitate și să le schimbe pentru tokenuri de acces Microsoft Entra cu durată scurtă de viață, fără ca vreun secret să fie generat, stocat sau rotit vreodată. Comparația Microsoft a celor trei modele este directă: principalii de serviciu federați și identitățile gestionate sunt fără secrete și funcționează în medii găzduite, auto-găzduite și on-premises deopotrivă, în timp ce principalii de serviciu bazați pe secrete nu sunt fără secrete și poartă în continuare riscul operațional care vine cu orice credențială cu durată lungă de viață.

Pentru un MSP care gestionează mai mulți tenanturi de clienți

Dimensiunea tenantului contează la fel de mult ca tipul de credențială. Un singur principal de serviciu partajat între mai mulți tenanturi de clienți transformă un secret scurs într-un incident care afectează mai mulți clienți; identitatea ar trebui legată de scopul unui singur tenant, indiferent de modelul de credențială folosit. Acolo unde federația nu este încă posibilă, tratați secretul de client ca un risc permanent: inventariați unde este folosit, setați-l să expire în 90 de zile sau mai puțin și planificați eliminarea lui odată ce federația este în vigoare.

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