Dlaczego konta „svc-” są bombą z opóźnionym zapłonem

By Mirko Peters · 2026-08-11

Witamy ponownie w podcaście i w naszym trwającym przeglądzie architektury bezpieczeństwa przedsiębiorstw. Jeśli Twoja organizacja jest podobna do większości, szybki przegląd Active Dir…

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

Witamy ponownie w podcaście i w naszym trwającym przeglądzie architektury bezpieczeństwa przedsiębiorstw. Jeśli Twoja organizacja jest podobna do większości, szybki przegląd Active Directory lub katalogu Microsoft Entra ID pokaże rozległe cmentarzysko kont zaczynających się od „svc-”, „app-” lub „admin-bot”. Konta te utrzymują wszystko w ruchu, zapewniają przepływ danych i działanie automatyzacji. Są jednocześnie największym pojedynczym martwym punktem w Twoim nowoczesnym modelu bezpieczeństwa. W tym wpisie na blogu rozwijamy naszą najnowszą rozmowę, by wyjaśnić, dlaczego tradycyjne konta usługowe całkowicie podważają architekturę Zero Trust i dlaczego migracja do Microsoft Entra Workload Identities to jedyna droga naprzód.

Pełne omówienie audio tego tematu znajdziesz w naszym towarzyszącym odcinku podcastu, Replace Service Accounts with Entra Workload Identities. A teraz przejdźmy do mechaniki ryzyka związanego z kontami nieludzkimi i sposobów, jak można je trwale wyeliminować.

TL;DR

Konta usługowe ze statycznymi sekretami i szerokimi uprawnieniami to Twoja największa luka w tożsamości. Workload Identities (w Microsoft Entra ID) dają każdemu nieludzkiemu podmiotowi zarządzaną tożsamość z najmniejszymi uprawnieniami, cyklem życia, zasadami CA, rotacją i pełnymi śladami audytu — bez psucia automatyzacji.

Dlaczego konta usługowe zawodzą (i łamią Zero Trust)

Tradycyjny model kont usługowych powstał w erze granic sieciowych, które już nie istnieją. Gdy zaufanie zależało od tego, czy urządzenie było podłączone do firmowej sieci LAN, statyczne hasło przechowywane w pliku konfiguracyjnym wydawało się dopuszczalne. Dziś ta filozofia projektowa stanowi zagrożenie.

• Statyczne sekrety i brak MFA -> łatwe do wykradzenia, trudne do bezpiecznej rotacji
• Domyślnie nadmierne uprawnienia -> uprawnienia nadane na zasadzie „niech działa” stają się stałe
• Brak cyklu życia -> osierocone, zapomniane konta przetrwują migracje i reorganizacje
• Słaba audytowalność -> „kto tego użył i dlaczego?” = zgadywanie i zrzuty ekranu
• Kultura wyjątków -> wyłączenia z CA/MFA dla botów po cichu poszerzają powierzchnię ataku

Managed Identities: dobry krok, ale związany z Azure

Gdy organizacje uświadamiają sobie, że statyczne konta usługowe są niebezpieczne, ich pierwszym naturalnym kierunkiem bywają często Azure Managed Identities. Managed Identities to ogromny krok naprzód, ponieważ całkowicie eliminują sekrety dla zasobów hostowanych w Azure, mają jednak wyraźne ograniczenia.

• ✅ Dostęp bez sekretów do zasobów natywnych dla Azure (Functions, maszyny wirtualne, Logic Apps)
• ❌ Luki w przypadku celów hybrydowych/zewnętrznych, słabe mapowanie właścicieli, ograniczone widoki zarządzania
• ❌ Pokrycie CA/uprawnieniami nie jest jednolite na powierzchniach spoza Azure

Workload Identities: co faktycznie otrzymujesz

Tu do gry wchodzą Microsoft Entra Workload Identities. Zamiast traktować nieludzkie podmioty jak obywateli drugiej kategorii albo zmuszać Cię do ograniczeń charakterystycznych dla Azure, Workload Identities podnoszą aplikacje, skrypty i zautomatyzowane usługi do rangi podmiotów zabezpieczeń pierwszej klasy.

• Nieludzkie tożsamości pierwszej klasy (aplikacje, skrypty, łączniki, RPA, integracje)
• Zakresowe uprawnienia (role Graph/zasobów, uwierzytelnianie tylko aplikacji) z najmniejszymi uprawnieniami
• Cykl życia (właściciel, częstotliwość przeglądów, proces wycofania) powiązany z procesem biznesowym
• Warunkowy dostęp dla obciążeń (bramki uwzględniające ryzyko i kontekst, kontrola sesji tam, gdzie jest obsługiwana)
• Higiena poświadczeń (krótkotrwałe sekrety, certyfikaty, zasady rotacji kluczy)
• Jednolita widoczność (logowania, tokeny, dostęp do zasobów, historia zmian) -> gotowość do audytu

Macierz porównawcza (w skrócie)

Wzorce architektury (typowe przypadki użycia)

Wdrożenie tożsamości obciążeń wymaga ich poprawnego odwzorowania na wzorce architektoniczne. Oto, jak stosują się one do najczęstszych obciążeń w przedsiębiorstwach:

• Łączniki Power Platform / przepływy w chmurze -> Przypisz tożsamość obciążenia do każdej integracji; nadaj tylko niezbędne zakresy Graph/Dataverse.
• Aplikacje biznesowe (interfejsy API sieci Web, demony) -> Rejestracja aplikacji + certyfikat; używaj ról aplikacji i usługi Graph działającej wyłącznie w kontekście aplikacji; egzekwuj zasady dostępu warunkowego tam, gdzie ma to zastosowanie.
• Skrypty automatyzacji (Azure Automation, GitHub Actions, DevOps) -> Używaj poświadczeń federacyjnych (OIDC), bez przechowywanych sekretów.
• Zadania między dzierżawami / B2B -> Dedykowana tożsamość obciążenia dla każdej granicy dzierżawy; izoluj uprawnienia i rejestrowanie zdarzeń.

Playbook migracji (90 dni, bez zbędnych komplikacji)

Zajęcie się setkami starszych kont usługowych może wydawać się przytłaczające. Dlatego potrzebujesz uporządkowanego playbooka migracji, obejmującego 90 dni i koncentrującego się na ograniczaniu ryzyka.

Faza 1 — Odkrywanie i priorytetyzacja (tygodnie 0–3)

1. Zinwentaryzuj logowania i obiekty nieludzkie: svc-*, app-*, udostępnione skrzynki pocztowe, rejestracje aplikacji, sekrety wygasające w ciągu <90 dni.
2. Przypisz każdy element do właściciela, celu biznesowego, celów, uprawnień oraz zależności od kont awaryjnych.
3. Oceń ryzyko: statyczne hasła, role globalne, brak właściciela, brak niedawnej rotacji.

Faza 2 — Najpierw konwersja grup wysokiego ryzyka (tygodnie 4–8)

1. Utwórz tożsamość obciążenia dla każdej integracji (nie używaj ponownie).
2. Zastąp uwierzytelnianie hasłem certyfikatami lub poświadczeniami federacyjnymi; ustaw rotację.
3. Przejdź na uprawnienia wyłącznie aplikacyjne; usuń uprawnienia delegowane przez użytkownika, jeśli nie są wymagane.
4. Zastosuj zasady dostępu warunkowego dla logowań obciążeń (tam, gdzie jest to obsługiwane).
5. Wdroż przeglądy dostępu (kwartalnie) oraz przypisanie właścicieli w CMDB/ITSM.

Faza 3 — Wycofanie i zarządzanie (tygodnie 9–12)

1. Wyłącz stare konta usługowe; monitoruj przez 14 dni; następnie usuń.
2. Wymuś standardy tworzenia: nazewnictwo, właściciel, klasyfikacja danych, częstotliwość przeglądów.
3. Dodaj alerty: anomalne logowania, nieaktywne tożsamości przez >30/60/90 dni, wygasające sekrety.
4. Wbuduj kontrole tożsamości w CI/CD (policy-as-code).

Dostęp warunkowy i uprawnienia (praktyczne zabezpieczenia)

Jedną z najpotężniejszych funkcji nowoczesnych platform tożsamości jest możliwość stosowania zabezpieczeń dostosowanych specjalnie do podmiotów nieludzkich. Rozdzielając zasady dla ludzi i obciążeń, uniemożliwiasz botom wywoływanie fałszywych alertów o „niemożliwej podróży”, a jednocześnie nadal blokujesz złośliwy ruch.

• Oddzielne zasady dla tożsamości ludzkich i obciążeń; blokuj interaktywne logowanie dla obciążeń.
• Lokalizacje nazwane / ograniczenia sieciowe dla dostępu wyłącznie aplikacyjnego, tam gdzie jest to możliwe.
• Uprawnienia ograniczone w czasie (PIM dla ról aplikacji, gdy jest dostępne; zaplanowane przeglądy dostępu).
• Zakresy: preferuj role aplikacji lub role specyficzne dla zasobu zamiast uprawnień obejmujących cały katalog.

Rejestrowanie i audyt (co pokazać audytorowi)

Kiedy inspektorzy ds. zgodności i audytorzy pukają do drzwi, nie akceptują już arkuszy kalkulacyjnych ani ustnych zapewnień o tym, kto ma dostęp do skryptów zaplecza. Musisz być w stanie natychmiast udowodnić nadzór dzięki scentralizowanemu rejestrowaniu zdarzeń.

• Właściciel aplikacji/obciążenia, cel, wrażliwość danych
• Dzienniki logowania (logowania jednostek usługi), odbiorca tokenu, adres IP, aplikacja klienta
• Przypisania ról (kto zatwierdził, kiedy certyfikowano)
• Historia poświadczeń (typ, ostatnia rotacja, wygaśnięcie)
• Cykl życia: utworzono/zmodyfikowano/wyłączono/usunięto wraz z podmiotem wprowadzającym zmianę

Pulpit wskaźników KPI (udowodnij poprawę)

Aby utrzymać stałe poparcie kierownictwa, śledź i raportuj kluczowe wskaźniki efektywności, które pokazują zmniejszanie ryzyka związanego z tożsamościami nieludzkimi w czasie.

• % tożsamości nieludzkich z właścicielem i częstotliwością przeglądów (cel ≥ 95%)
• Osierocone konta usługowe (cel -> 0)
• Sekrety starsze niż 90 dni (cel -> 0; preferuj certyfikaty/poświadczenia federacyjne)
• Zakres ról aplikacji tylko do zapisu (liczba „Directory.ReadWrite.All” -> trend spadkowy)
• Ustalenia audytu dotyczące dostępu nieludzkiego (kwartał do kwartału ↓)

Antywzorce do wyeliminowania

Porządkując środowisko, dopilnuj, aby zespoły nie wracały do starych nawyków. Natychmiast wyeliminuj te antywzorce:

• Ponowne używanie jednego ogólnego konta usługowego w wielu systemach
• Osadzanie haseł w skryptach, plikach web.config lub w Key Vault bez zasad rotacji
• Nadawanie roli Administrator globalny / Właściciel „na wszelki wypadek”, żeby zadania działały dalej
• „Tymczasowe” wyjątki od dostępu warunkowego, które nigdy nie wygasają

Szybkie wygrane (w tym tygodniu)

Nie musisz czekać na rozpoczęcie dużego projektu, żeby zacząć poprawiać swoją postawę bezpieczeństwa. Oto cztery szybkie działania, które możesz wykonać w tym tygodniu:

• Oznacz każdą tożsamość nieosobową tagami Właściciel, System, Klasa danych.
• Przełącz jedno zadanie wysokiego ryzyka na poświadczenia federacyjne (GitHub OIDC -> Entra).
• Zastąp współdzielone konto usługi w Power Automate tożsamością obciążenia.
• Utwórz raport jednostek usługi z wygasającymi lub wygasłymi wpisami tajnymi i skonfiguruj alerty.

Często zadawane pytania (szybkie odpowiedzi)

Czy tożsamości obciążeń przerwą działanie starszych zadań lokalnych?
Nie. Można zastosować uwierzytelnianie tylko aplikacji, certyfikaty lub usługi pośredniczące, a hasła wycofywać stopniowo.

Czy mogę wymusić dostęp warunkowy dla logowań nieosobowych?
Tak, w obsługiwanych scenariuszach (logowania jednostek usługi). Tam, gdzie to możliwe, wykorzystaj sygnały sieci, lokalizacji i urządzenia oraz zablokuj logowania interaktywne.

Jak uniknąć rozrostu tych tożsamości?
Jedna tożsamość obciążenia na integrację (a nie na zespół). Wymuszaj nazewnictwo, właściciela i przeglądy już przy tworzeniu, a czyszczenie nieaktywnych tożsamości zautomatyzuj.

A Power Platform?
Do łączników i Dataverse używaj jednostek usługi / tożsamości obciążeń i zrezygnuj ze współdzielonych kont użytkowników.

Podsumowanie

Samą rotacją haseł nie rozwiążesz ryzyka związanego z kontami usług. Tożsamości obciążeń w Entra wprowadzają dostęp nieosobowy do tego samego modelu Zero Trust, cyklu życia i audytu, którego już wymagasz w odniesieniu do ludzi, i robią to bez przestojów i heroicznych działań. Zacznij od najbardziej ryzykownych kont „svc-”, przekształć je w zarządzane tożsamości obciążeń i spraw, by wyjątki znów były wyjątkami.

Jeśli spodobał Ci się ten tekst, koniecznie zajrzyj do pełnej dyskusji w naszym odcinku podcastu Replace Service Accounts with Entra Workload Identities. Subskrybuj podcast, by znaleźć więcej dogłębnych analiz strategii bezpieczeństwa Microsoft 365 i Azure w przedsiębiorstwach!