MSP FAQ: stały sekret jednostki usługi to nie tożsamość obciążenia

Konta automatyzacji i integracje często uwierzytelniają się za pomocą sekretu klienta jednostki usługi: długiego ciągu znaków, ważnego przez wiele miesięcy, którego każdy skrypt lub inżynier mający do niego dostęp może użyć, aby działać jako ta tożsamość. Dodanie uwierzytelniania wieloskładnikowego po ludzkiej stronie konta niczego tu nie zmienia; sam sekret pozostaje trwałym poświadczeniem z własnym zasięgiem skutków naruszenia.

Dlaczego sekrety klienta traktuje się jako rozwiązanie przestarzałe

Własne wytyczne Microsoftu jasno mówią, że jednostki usługi z sekretami klienta należy traktować jako podejście przestarzałe i zastępować je tożsamościami zarządzanymi lub federacyjnymi wszędzie tam, gdzie środowisko hostingowe to umożliwia. Sekret klienta powinien istnieć tylko wtedy, gdy obciążenie naprawdę nie może użyć silniejszego poświadczenia. Problem nie polega na tym, że sekretów nie da się zabezpieczyć — chodzi o to, że trzeba je gdzieś przechowywać, rotować zgodnie z harmonogramem i ręcznie unieważniać w razie wycieku, a każdy z tych kroków to miejsce na błąd.

Co eliminuje federacja tożsamości obciążeń

Federacja tożsamości obciążeń pozwala zewnętrznemu obciążeniu — potokowi CI/CD, klastrowi Kubernetes, skryptowi działającemu poza platformą Azure — ufać tokenom z własnego dostawcy tożsamości i wymieniać je na krótkotrwałe tokeny dostępu Microsoft Entra, bez generowania, przechowywania ani rotowania jakiegokolwiek sekretu. Porównanie trzech modeli przedstawione przez Microsoft jest bezpośrednie: federacyjne jednostki usługi i tożsamości zarządzane działają bez sekretów i sprawdzają się zarówno w środowiskach hostowanych, samodzielnie zarządzanych, jak i lokalnych, podczas gdy jednostki usługi oparte na sekretach nie są wolne od sekretów i nadal niosą ryzyko operacyjne właściwe każdemu długoterminowemu poświadczeniu.

Dla dostawcy MSP zarządzającego wieloma dzierżawami klientów

Wymiar dzierżawy ma znaczenie równie duże jak typ poświadczenia. Jedna jednostka usługi współdzielona przez kilku klientów zamienia jeden wyciek sekretu w incydent obejmujący wielu klientów; tożsamość powinna być powiązana z zakresem pojedynczej dzierżawy niezależnie od tego, który model poświadczeń jest używany. Tam, gdzie federacja nie jest jeszcze możliwa, traktuj sekret klienta jako trwałe ryzyko: zinwentaryzuj miejsca jego użycia, ustaw wygaśnięcie na 90 dni lub krócej i zaplanuj jego usunięcie po wdrożeniu federacji.

Źródła: Microsoft Learn — Federacja tożsamości obciążeń, Microsoft Learn — Jednostki usługi i tożsamości zarządzane.