Jak tożsamości zarządzane eliminują zakodowane na sztywno hasła w Azure

By Mirko Peters · 2026-08-13

Witamy ponownie w blogu towarzyszącym naszemu podcastowi! Jeśli od dłuższego czasu tworzysz aplikacje, zapewne spotkałeś się z odwiecznym problemem o…

Automatically translated with AI from the original post. Read the English original

Witamy ponownie w blogu towarzyszącym naszemu podcastowi! Jeśli od dłuższego czasu tworzysz aplikacje, na pewno spotkałeś się z odwiecznym problemem łączenia kodu z bazą danych, interfejsem API lub kontem magazynu w chmurze. Dotychczas programiści rozwiązywali to, wpisując ciąg połączenia, hasło do bazy danych lub sekret klienta bezpośrednio w pliku konfiguracyjnym, zmiennej środowiskowej, a nawet, co gorsza, na sztywno w kodzie źródłowym w repozytorium. Dopóki aplikacja mogła odczytać ten sekret, mogła się uwierzytelnić i wykonywać swoje zadania. Ale co się dzieje, gdy ten kod przypadkowo zostanie wysłany do publicznego repozytorium w serwisie GitHub? Co, gdy niezadowolony pracownik odejdzie z firmy albo atakujący uzyska dostęp do odczytu ustawień aplikacji? Cała infrastruktura jest natychmiast zagrożona. W nowoczesnej architekturze chmurowej to niedopuszczalne ryzyko. Dzisiaj szczegółowo omówimy, jak tożsamości zarządzane w Microsoft Azure całkowicie eliminują potrzebę stosowania haseł zakodowanych na sztywno, zastępując statyczne sekrety dynamicznymi, krótkotrwałymi tokenami dostępu.

Wprowadzenie do bezpieczeństwa chmury i sekretów zakodowanych na sztywno

Tradycyjny model bezpieczeństwa oparty na granicy sieci zakładał, że jeśli znajdujesz się w sieci firmowej, możesz być uznany za zaufanego. Wewnątrz tej granicy aplikacje komunikowały się, korzystając ze statycznych kont usługowych, haseł zakodowanych na sztywno i długotrwałych tokenów, które rzadko kiedy – o ile w ogóle – wygasały. Jeśli złoczyńca przełamał granicę, miał dostęp do skarbca statycznych poświadczeń, które mogły być używane w nieskończoność.

Przetwarzanie w chmurze całkowicie zburzyło tę granicę. Nasze obciążenia obejmują obecnie środowiska wielochmurowe, lokalne centra danych, platformy SaaS i rozproszone funkcje bezserwerowe. W tym nowym świecie bezpieczeństwo musi podążać za tożsamością samego obciążenia. Sekrety zakodowane na sztywno to bomby z opóźnionym zapłonem. Nie są automatycznie rotowane, są notorycznie trudne do audytu i nie pozostawiają żadnego marginesu błędu w razie ujawnienia. Aby osiągnąć prawdziwe bezpieczeństwo w modelu Zero Trust, musimy całkowicie oddzielić poświadczenia od kodu źródłowego. Potrzebujemy mechanizmu uwierzytelniania, w którym aplikacje mogą udowodnić, kim są, bez konieczności znajomości lub przechowywania hasła.

Tożsamości użytkowników a tożsamości obciążeń w usłudze Entra ID

Aby zrozumieć, jak ewoluowało bezpieczeństwo chmury, musimy najpierw przyjrzeć się temu, jak usługa Microsoft Entra ID zarządza podmiotami, które uzyskują dostęp do naszych systemów. Ogólnie rzecz biorąc, Microsoft Entra ID dzieli tożsamości na dwie główne grupy: tożsamości użytkowników i tożsamości obciążeń.

Tożsamości użytkowników reprezentują ludzi – pracowników, partnerów, kontrahentów i klientów. Ludzie wchodzą w interakcję z systemami w sposób dynamiczny i uwierzytelniają się metodami dostosowanymi do ludzi, takimi jak hasła, Windows Hello dla firm, klucze zabezpieczeń FIDO2 i uwierzytelnianie wieloskładnikowe. Ludzie zapominają hasła, padają ofiarą ataków phishingowych i wymagają administracyjnego resetowania haseł.

Tożsamości obciążeń z kolei reprezentują oprogramowanie. Obejmują one aplikacje, usługi działające w tle, skrypty automatyzacji, Azure Functions, Logic Apps, potoki wdrożeniowe DevOps oraz agentów AI. Obciążenia nie piją kawy, nie klikają w wiadomości phishingowe i nie mogą zrealizować interaktywnego monitu uwierzytelniania wieloskładnikowego na smartfonie. Muszą uwierzytelniać się w sposób nieinteraktywny, programowy i ciągły. Traktowanie tożsamości obciążenia jak tożsamości użytkownika, czyli przypisywanie jej statycznego hasła, jest jednym z najczęstszych błędów w architekturze chmurowej. Tożsamości obciążeń wymagają własnych, wyspecjalizowanych modeli zarządzania, cyklu życia i zautomatyzowanych przepływów uwierzytelniania.

Rozwiewamy wątpliwości dotyczące rejestracji aplikacji, jednostek usługi i tożsamości zarządzanych

Jeśli choć trochę czasu spędziłeś na konfigurowaniu aplikacji w usłudze Microsoft Entra ID, na pewno natknąłeś się na trzy pojęcia, które często wprowadzają zamieszanie: rejestracje aplikacji, jednostki usługi i tożsamości zarządzane. Rozłóżmy je na czynniki pierwsze w prosty sposób.

Rejestracja aplikacji (Application Registration) to globalna definicja lub szablon Twojej aplikacji. Kiedy rejestrujesz aplikację w usłudze Microsoft Entra ID, tworzysz jej globalną tożsamość w obrębie całego ekosystemu wielodzierżawnego. To właśnie tutaj określasz, jakich uprawnień aplikacja może potrzebować, z jakich punktów końcowych uwierzytelniania korzysta i jakie identyfikatory URI są z nią powiązane. Myśl o rejestracji aplikacji jak o wzorze paszportu.

Jednostka główna usługi (Service Principal) to lokalna instancja tej aplikacji w konkretnej dzierżawie. Jeśli aplikacja jest wielodzierżawna, będzie mieć jedną rejestrację aplikacji w dzierżawie wydawcy, ale osobną jednostkę główną usługi w każdej dzierżawie klienta, w której jest wdrożona i na którą wyrażono zgodę. To właśnie w jednostce głównej usługi administratorzy faktycznie przypisują uprawnienia, stosują zasady dostępu warunkowego i kontrolują, kto może lokalnie korzystać z aplikacji. Myśl o jednostce głównej usługi jak o wybitym paszporcie, dzięki któremu wjeżdża się do konkretnego kraju.

Tożsamość zarządzana (Managed Identity) rozwija tę koncepcję o krok dalej, z myślą o zasobach działających w usłudze Microsoft Azure. Zamiast tego, żeby deweloper ręcznie tworzył rejestrację aplikacji, generował sekret klienta, przechowywał go w zmiennej środowiskowej i pisał kod obsługujący cykl życia uwierzytelniania, cały ten proces obsługuje za kulisami platforma Azure. Azure tworzy, zarządza i automatycznie rotuje bazowymi poświadczeniami za Ciebie. Deweloper wystarczy, że wskaże zasobowi Azure, aby korzystał ze swojej tożsamości zarządzanej, a reszta dzieje się sama.

Jak tożsamości zarządzane eliminują hasła i zakodowane na stałe poświadczenia

Magia tożsamości zarządzanych tkwi w tym, jak zasadniczo zmieniają transakcję uwierzytelniania. Gdy używasz tożsamości zarządzanej dla zasobu Azure, takiego jak Azure App Service, maszyna wirtualna czy Azure Function, w kodzie ani w ustawieniach konfiguracji dosłownie nie ma żadnego hasła, sekretu ani certyfikatu.

Kiedy Twoja aplikacja potrzebuje dostępu do chronionego zasobu, na przykład bazy danych lub interfejsu API, nie wyszukuje zapisanego hasła. Zamiast tego wykonuje lokalne wywołanie do punktu końcowego Azure Instance Metadata Service (IMDS), który jest bezpiecznie dostępny wyłącznie z poziomu danego zasobu Azure. Platforma bazowa zasobu Azure żąda w imieniu aplikacji krótkotrwałego tokenu sieciowego JSON Web Token (JWT) bezpośrednio od usługi Microsoft Entra ID.

Microsoft Entra ID weryfikuje tożsamość zasobu Azure, wydaje kryptograficznie podpisany token dostępu o bardzo krótkim okresie ważności (zwykle około godziny) i przekazuje go z powrotem do aplikacji. Aplikacja używa tego tokenu do uwierzytelnienia w docelowej usłudze. Ponieważ token szybko wygasa, nawet jeśli atakujący zdoła go przechwycić, okno podatności jest bardzo wąskie. Co więcej, skoro w kodzie nie ma zapisanego na stałe hasła, deweloper nie ma czego przypadkowo wyciec do publicznego repozytorium.

Integracja Azure Key Vault i krótkotrwałych tokenów dostępu

Tożsamości zarządzane eliminują potrzebę stosowania haseł aplikacji, ale możesz zastanawiać się, jak aplikacje obsługują sekrety rzeczywiście zewnętrzne, na przykład klucze API usług firm trzecich, które nie obsługują uwierzytelniania Microsoft Entra. Tutaj do gry wchodzi Azure Key Vault, który działa ramię w ramię z tożsamościami zarządzanymi.

Zamiast zakodowywać na stałe klucz API firmy trzeciej w kodzie źródłowym, przechowujesz ten sekret bezpiecznie w Azure Key Vault. Następnie przyznajesz tożsamości zarządzanej swojego zasobu Azure uprawnienie do odczytu sekretów z tego magazynu kluczy, używając kontroli dostępu opartej na rolach (RBAC) platformy Azure lub zasad dostępu usługi Key Vault.

Gdy aplikacja się uruchamia, używa swojej tożsamości zarządzanej, aby uwierzytelnić się w Azure Key Vault, pobiera wymagany klucz API firmy trzeciej dynamicznie, do pamięci, i z niego korzysta. Na żadnym etapie poświadczenia nie są ujawniane w kodzie źródłowym. Aplikacja korzysta z bezpiecznego mechanizmu opartego na tożsamości, aby pobrać sekret, zamiast polegać na statycznym ciągu znaków osadzonym w pliku konfiguracyjnym.

Zabezpieczanie tożsamości obciążeń zgodnie z zasadą najmniejszych uprawnień i zarządzanie nimi

Wyeliminowanie zakodowanych na stałe haseł to ogromny zysk dla bezpieczeństwa, ale wdrożenie tożsamości zarządzanych nie jest modelem operacyjnym typu „ustaw i zapomnij”. Tożsamości obciążeń wymagają solidnego zarządzania, tak samo jak konta użytkowników.

Przede wszystkim musisz bezwzględnie przestrzegać zasady najmniejszych uprawnień. Nie przypisuj tożsamościom obciążeń szerokich ról współautora ani nadmiernych uprawnień Microsoft Graph tylko po to, by szybko wszystko zadziałało. Jeśli skrypt automatyzacji w tle potrzebuje jedynie odczytu elementów z jednego konkretnego kontenera w Azure Storage, przydziel mu rolę Storage Blob Data Reader wyłącznie dla tego kontenera – nic ponadto. Jeśli taka tożsamość obciążenia zostanie kiedyś przejęta, zasięg szkód będzie minimalny.

Po drugie, musisz w sposób ciągły monitorować i audytować tożsamości obciążeń. Organizacje często tworzą jednostki usługi i tożsamości zarządzane na potrzeby projektów proof of concept, skryptów automatyzacji i tymczasowych integracji, a następnie pozostawiają je działające bezterminowo z wysokimi uprawnieniami. Wdrażaj regularne przeglądy bezpieczeństwa, aby identyfikować osierocone jednostki usługi, nieużywane konta automatyzacji i nieaktualne poświadczenia. Wykorzystanie funkcji takich jak Microsoft Entra ID Protection oraz konfiguracja solidnego rejestrowania za pomocą Azure Monitor zapewnia pełną widoczność tego, kiedy i jak tożsamości obciążeń uzyskują dostęp do Twojego środowiska.

Wybór właściwej strategii tożsamości dla każdego obciążenia w chmurze

Przy tak wielu dostępnych opcjach w ekosystemie tożsamości Microsoft pojawia się pytanie: jak wybrać właściwą strategię uwierzytelniania dla konkretnego obciążenia? Decyzja zależy zazwyczaj od tego, gdzie działa Twoja aplikacja i jaka jest jej architektura.

Jeśli Twój kod działa w usłudze Microsoft Azure – czy to w Azure App Services, Azure Functions, maszynach wirtualnych, Azure Container Instances czy Azure Kubernetes Service – Twoim pierwszym wyborem powinna zawsze być tożsamość zarządzana. Możesz wybierać między tożsamością zarządzaną przypisaną do systemu (która ma cykl życia 1:1, bezpośrednio powiązany z zasobem Azure) a tożsamością zarządzaną przypisaną przez użytkownika (którą można utworzyć niezależnie i przypisać do wielu zasobów Azure, co ułatwia zarządzanie).

Jeśli Twoja aplikacja działa poza Azure – na przykład na serwerach lokalnych, w AWS lub jako część potoku CI/CD w GitHub Actions – tożsamości zarządzane hostowane bezpośrednio przez infrastrukturę Azure nie wchodzą w grę. W takich scenariuszach warto wykorzystać federację tożsamości obciążeń. Pozwala ona zewnętrznym platformom wymieniać tokeny bezpośrednio z Microsoft Entra ID, korzystając z zaufania OpenID Connect (OIDC), co całkowicie eliminuje potrzebę zarządzania, rotowania i przechowywania długotrwałych sekretów klienta.

Wreszcie, w przypadku tradycyjnych, niestandardowych aplikacji korporacyjnych wymagających uwierzytelniania klienta, w których ani tożsamości zarządzane, ani federacja nie są możliwe, certyfikaty zarządzane z należytą starannością powinny zawsze mieć pierwszeństwo przed długotrwałymi sekretami klienta. Łącząc Microsoft Entra Workload Identities, Azure Key Vault, zasady Zero Trust oraz dostęp według zasady najmniejszych uprawnień, Twoja organizacja może całkowicie wyeliminować zakodowane na stałe hasła i zbudować wyjątkowo odporną architekturę chmurową.

Podsumowanie i kolejne kroki dla nowoczesnego bezpieczeństwa w chmurze

Zakodowane na stałe hasła i statyczne ciągi połączeń to relikty przestarzałej epoki w bezpieczeństwie IT. Dzięki przyjęciu Microsoft Entra Workload Identities oraz tożsamości zarządzanych Azure możemy całkowicie wyeliminować ryzyko związane z osadzonymi poświadczeniami, chronić repozytoria kodu źródłowego przed przypadkowym wyciekiem i konsekwentnie stosować dostęp zgodny z zasadą najmniejszych uprawnień we wszystkich aplikacjach natywnych dla chmury. Krótkotrwałe tokeny dostępu sprawiają, że nawet jeśli token zostanie przechwycony, jego okres ważności będzie zbyt krótki, by wyrządzić trwałe szkody, a to zasadniczo przesuwa nasze podejście do bezpieczeństwa od reaktywnej obrony ku proaktywnej ochronie.

Aby zgłębić ten temat jeszcze bardziej i poznać praktyczne wskazówki wdrożeniowe z pierwszej ręki, koniecznie posłuchaj powiązanego odcinka podcastu: Entra Workload Identities - Simply Explained. Razem rozłożymy te koncepcje na czynniki pierwsze, aby pomóc Ci zabezpieczać środowiska Azure i Microsoft 365 jak prawdziwy profesjonalista!