Udostępnij przez

Konfigurowanie usługi Microsoft Entra for Zero Trust: Ochrona systemów inżynieryjnych

Filar Secure Future Initiative dotyczący ochrony systemów inżynieryjnych został po raz pierwszy opracowany w celu ochrony własnych zasobów i infrastruktury oprogramowania firmy Microsoft. Praktyki i szczegółowe informacje uzyskane z tej pracy wewnętrznej są teraz udostępniane klientom, co umożliwia wzmocnienie własnych środowisk.

Te zalecenia koncentrują się na zapewnieniu dostępu do systemów i zasobów inżynieryjnych organizacji z najniższymi uprawnieniami.

Zalecenia dotyczące zabezpieczeń

Konta dostępu awaryjnego są odpowiednio skonfigurowane

Firma Microsoft zaleca, aby organizacje miały dwa konta dostępu awaryjnego tylko w chmurze, które zostały trwale przypisane do roli administratora globalnego. Te konta są wysoce uprzywilejowane i nie są przypisane do określonych osób. Konta są ograniczone do scenariuszy awaryjnych lub "break glass", w których nie można używać zwykłych kont lub wszyscy inni administratorzy są przypadkowo zablokowani.

Akcja korygowania

Aktywacja roli administratora globalnego wyzwala przepływ pracy zatwierdzania

Bez przepływów pracy zatwierdzania aktorzy zagrożeń, którzy naruszyli zabezpieczenia poświadczeń administratora globalnego za pośrednictwem wyłudzania informacji, wypychania poświadczeń lub innych technik pomijania uwierzytelniania, mogą natychmiast aktywować najbardziej uprzywilejowaną rolę w dzierżawie bez żadnej innej weryfikacji lub nadzoru. Usługa Privileged Identity Management (PIM) umożliwia aktywowanie kwalifikujących się aktywacji ról w ciągu kilku sekund, więc naruszone poświadczenia mogą zezwalać na niemal natychmiastową eskalację uprawnień. Po aktywowaniu aktorzy zagrożeń mogą używać roli administratora globalnego do korzystania z następujących ścieżek ataku w celu uzyskania trwałego dostępu do dzierżawy:

  • Tworzenie nowych uprzywilejowanych kont
  • Modyfikowanie zasad dostępu warunkowego w celu wykluczenia tych nowych kont
  • Ustanawianie alternatywnych metod uwierzytelniania, takich jak uwierzytelnianie oparte na certyfikatach lub rejestracje aplikacji z wysokimi uprawnieniami

Rola administratora globalnego zapewnia dostęp do funkcji administracyjnych w usłudze Microsoft Entra ID i usług korzystających z tożsamości firmy Microsoft Entra, w tym usługi Microsoft Defender XDR, Microsoft Purview, Exchange Online i SharePoint Online. Bez bram zatwierdzania aktorzy zagrożeń mogą szybko eskalować do zakończenia przejęcia dzierżawy, eksfiltrowania poufnych danych, naruszania wszystkich kont użytkowników i ustanawiania długoterminowych backdoorów za pośrednictwem jednostek usługi lub modyfikacji federacji, które utrzymują się nawet po wykryciu początkowego naruszenia.

Akcja korygowania

Administratorzy globalni nie mają stałego dostępu do subskrypcji platformy Azure

Administratorzy globalni z trwałym dostępem do subskrypcji platformy Azure rozszerzają obszar ataków dla podmiotów zagrożeń. W przypadku naruszenia zabezpieczeń konta administratora globalnego osoby atakujące mogą natychmiast wyliczać zasoby, modyfikować konfiguracje, przypisywać role i eksfiltrować poufne dane we wszystkich subskrypcjach. Wymaganie podniesienia uprawnień just in time dla dostępu do subskrypcji wprowadza wykrywalne sygnały, spowalnia szybkość działania osoby atakującej i kieruje operacje o dużym wpływie za pośrednictwem obserwowanych punktów kontroli.

Akcja korygowania

Tworzenie nowych aplikacji i jednostek usługi jest ograniczone do uprzywilejowanych użytkowników

Jeśli użytkownicy niebędący nieuprzywilejowani mogą tworzyć aplikacje i jednostki usług, te konta mogą zostać nieprawidłowo skonfigurowane lub otrzymać więcej uprawnień niż jest to konieczne, tworząc nowe wektory dla osób atakujących w celu uzyskania dostępu początkowego. Osoby atakujące mogą wykorzystać te konta w celu ustanowienia prawidłowych poświadczeń w środowisku i obejścia niektórych mechanizmów kontroli zabezpieczeń.

Jeśli te konta nieuprzywilejowane zostaną błędnie przyznane podwyższonym poziomem uprawnień właściciela aplikacji, osoby atakujące mogą ich użyć do przejścia z niższego poziomu dostępu do bardziej uprzywilejowanego poziomu dostępu. Osoby atakujące, które naruszyją bezpieczeństwo kont nieuprzywilejowanych, mogą dodawać własne poświadczenia lub zmieniać uprawnienia skojarzone z aplikacjami utworzonymi przez użytkowników niebędących nieuprzywilejowanym, aby mieć pewność, że będą mogli nadal uzyskiwać dostęp do niezakrytego środowiska.

Osoby atakujące mogą używać jednostek usługi do łączenia się z uzasadnionymi procesami i działaniami systemu. Ponieważ jednostki usługi często wykonują automatyczne zadania, złośliwe działania wykonywane na tych kontach mogą nie być oflagowane jako podejrzane.

Akcja korygowania

Nieaktywne aplikacje nie mają wysoce uprzywilejowanych uprawnień interfejsu API programu Microsoft Graph

Osoby atakujące mogą wykorzystać prawidłowe, ale nieaktywne aplikacje, które nadal mają podwyższone uprawnienia. Te aplikacje mogą służyć do uzyskiwania dostępu początkowego bez zgłaszania alarmu, ponieważ są to uzasadnione aplikacje. Z tego miejsca osoby atakujące mogą używać uprawnień aplikacji do planowania lub wykonywania innych ataków. Osoby atakujące mogą również zachować dostęp, manipulując nieaktywną aplikacją, na przykład dodając poświadczenia. Ta trwałość gwarantuje, że nawet jeśli zostanie wykryta ich podstawowa metoda dostępu, może odzyskać dostęp później.

Akcja korygowania

Nieaktywne aplikacje nie mają wbudowanych ról o wysokim poziomie uprawnień

Osoby atakujące mogą wykorzystać prawidłowe, ale nieaktywne aplikacje, które nadal mają podwyższone uprawnienia. Te aplikacje mogą służyć do uzyskiwania dostępu początkowego bez zgłaszania alarmu, ponieważ są to uzasadnione aplikacje. Z tego miejsca osoby atakujące mogą używać uprawnień aplikacji do planowania lub wykonywania innych ataków. Osoby atakujące mogą również zachować dostęp, manipulując nieaktywną aplikacją, na przykład dodając poświadczenia. Ta trwałość gwarantuje, że nawet jeśli zostanie wykryta ich podstawowa metoda dostępu, może odzyskać dostęp później.

Akcja korygowania

Rejestracje aplikacji używają bezpiecznych identyfikatorów URI przekierowania

Aplikacje OAuth skonfigurowane przy użyciu adresów URL zawierających symbole wieloznaczne lub skracacze adresów URL zwiększają obszar ataków dla podmiotów zagrożeń. Niezabezpieczone identyfikatory URI przekierowania (adresy URL odpowiedzi) mogą zezwalać osobom atakującym na manipulowanie żądaniami uwierzytelniania, przejęcie kodów autoryzacji i przechwytywanie tokenów przez kierowanie użytkowników do punktów końcowych kontrolowanych przez osobę atakującą. Wpisy z symbolami wieloznacznymi rozszerzają ryzyko, zezwalając niezamierzonym domenom na przetwarzanie odpowiedzi uwierzytelniania, a skrócone adresy URL mogą ułatwić wyłudzenie informacji i kradzież tokenów w niekontrolowanych środowiskach.

Bez ścisłej weryfikacji identyfikatorów URI przekierowania osoby atakujące mogą pomijać mechanizmy kontroli zabezpieczeń, personifikować uzasadnione aplikacje i eskalować swoje uprawnienia. Ta błędna konfiguracja umożliwia trwałość, nieautoryzowany dostęp i ruch boczny, ponieważ przeciwnicy wykorzystują słabe wymuszanie protokołu OAuth w celu infiltrowania chronionych zasobów.

Akcja korygowania

Jednostki usługi używają bezpiecznych identyfikatorów URI przekierowania

Aplikacje inne niż Microsoft i wielodostępne skonfigurowane przy użyciu adresów URL zawierających symbole wieloznaczne, localhost lub skracacze adresów URL zwiększają obszar ataków dla podmiotów zagrożeń. Te niezabezpieczone identyfikatory URI przekierowania (adresy URL odpowiedzi) mogą zezwalać przeciwnikom na manipulowanie żądaniami uwierzytelniania, przejęcie kodów autoryzacji i przechwytywanie tokenów przez kierowanie użytkowników do punktów końcowych kontrolowanych przez osobę atakującą. Wpisy z symbolami wieloznacznymi rozszerzają ryzyko, zezwalając niezamierzonym domenom na przetwarzanie odpowiedzi uwierzytelniania, podczas gdy adresy URL hosta lokalnego i skróconego mogą ułatwić wyłudzanie informacji i kradzież tokenów w niekontrolowanych środowiskach.

Bez ścisłej weryfikacji identyfikatorów URI przekierowania osoby atakujące mogą pomijać mechanizmy kontroli zabezpieczeń, personifikować uzasadnione aplikacje i eskalować swoje uprawnienia. Ta błędna konfiguracja umożliwia trwałość, nieautoryzowany dostęp i ruch boczny, ponieważ przeciwnicy wykorzystują słabe wymuszanie protokołu OAuth w celu infiltrowania chronionych zasobów.

Akcja korygowania

Rejestracje aplikacji nie mogą mieć zwisających ani porzuconych identyfikatorów URI przekierowania domeny

Niezamierzone lub oddzielone identyfikatory URI przekierowania w rejestracjach aplikacji tworzą znaczące luki w zabezpieczeniach, gdy odwołują się do domen, które nie wskazują już aktywnych zasobów. Aktorzy zagrożeń mogą wykorzystać te "zwisające" wpisy DNS przez aprowizowanie zasobów w porzuconych domenach, co skutecznie przejmuje kontrolę nad punktami końcowymi przekierowania. Ta luka w zabezpieczeniach umożliwia osobom atakującym przechwytywanie tokenów uwierzytelniania i poświadczeń podczas przepływów protokołu OAuth 2.0, co może prowadzić do nieautoryzowanego dostępu, przejęcia sesji i potencjalnego szerszego naruszenia zabezpieczeń organizacji.

Akcja korygowania

Umożliwienie właścicielom grup zgody na aplikacje w identyfikatorze Entra firmy Microsoft tworzy ścieżkę eskalacji bocznej, która umożliwia aktorom zagrożeń utrwalanie i kradzież danych bez poświadczeń administratora. Jeśli osoba atakująca naruszy konto właściciela grupy, może zarejestrować lub użyć złośliwej aplikacji i wyrazić zgodę na uprawnienia interfejsu API programu Graph o wysokim poziomie uprawnień w zakresie grupy. Osoby atakujące mogą potencjalnie odczytywać wszystkie komunikaty usługi Teams, uzyskiwać dostęp do plików programu SharePoint lub zarządzać członkostwem w grupie. Ta akcja zgody tworzy długotrwałą tożsamość aplikacji z uprawnieniami delegowanymi lub uprawnieniami aplikacji. Osoba atakująca utrzymuje trwałość przy użyciu tokenów OAuth, kradnie poufne dane z kanałów i plików zespołu oraz personifikuje użytkowników za pośrednictwem wiadomości lub uprawnień poczty e-mail. Bez scentralizowanego wymuszania zasad zgody aplikacji zespoły ds. zabezpieczeń tracą widoczność i złośliwe aplikacje rozprzestrzeniają się pod radarem, umożliwiając wieloetapowe ataki na platformach współpracy.

Akcja korygowania Konfigurowanie wstępnej aplikacji uprawnień Resource-Specific Consent (RSC).

Tożsamości obciążeń nie są przypisane uprzywilejowane role

Jeśli administratorzy przypisują uprzywilejowane role do tożsamości obciążeń, takich jak jednostki usługi lub tożsamości zarządzane, dzierżawa może być narażona na znaczne ryzyko, jeśli te tożsamości zostaną naruszone. Aktorzy zagrożeń, którzy uzyskują dostęp do uprzywilejowanej tożsamości obciążenia, mogą wykonywać rekonesans w celu wyliczania zasobów, eskalacji uprawnień oraz manipulowania lub eksfiltrowania poufnych danych. Łańcuch ataków zwykle zaczyna się od kradzieży poświadczeń lub nadużywania aplikacji podatnej na zagrożenia. Następnym krokiem jest eskalacja uprawnień przez przypisaną rolę, penetrację sieci między zasobami chmury, a na koniec trwałość za pośrednictwem innych przypisań ról lub aktualizacji poświadczeń. Tożsamości obciążeń są często używane w automatyzacji i mogą nie być monitorowane tak blisko, jak konta użytkowników. Naruszenie zabezpieczeń może następnie nie być wykryte, dzięki czemu aktorzy zagrożeń mogą zachować dostęp i kontrolę nad krytycznymi zasobami. Tożsamości obciążeń nie podlegają ochronie skoncentrowanej na użytkowniku, takiej jak uwierzytelnianie wieloskładnikowe, co sprawia, że przypisanie najniższych uprawnień i regularne przeglądanie jest niezbędne.

Akcja korygowania

Aplikacje dla przedsiębiorstw muszą wymagać jawnego przypisania lub aprowizacji w zakresie

Gdy aplikacje dla przedsiębiorstw nie mają zarówno jawnych wymagań dotyczących przypisań, jak i kontroli aprowizacji w zakresie, aktorzy zagrożeń mogą wykorzystać tę podwójną słabość, aby uzyskać nieautoryzowany dostęp do poufnych aplikacji i danych. Największe ryzyko występuje, gdy aplikacje są skonfigurowane z ustawieniem domyślnym: "Wymagane przypisanie" ma wartość "Nie" , a aprowizacja nie jest wymagana ani nie jest ograniczona. Ta niebezpieczna kombinacja umożliwia podmiotom zagrożeń, którzy naruszyli bezpieczeństwo dowolnego konta użytkownika w dzierżawie, aby natychmiast uzyskiwać dostęp do aplikacji z szerokimi bazami użytkowników, rozszerzając obszar ataków i potencjalny ruch poprzeczny w organizacji.

Podczas gdy aplikacja z otwartym przypisaniem, ale odpowiednie określanie zakresu aprowizacji (takie jak filtry oparte na dziale lub wymagania dotyczące członkostwa w grupach) utrzymuje mechanizmy kontroli zabezpieczeń za pośrednictwem warstwy aprowizacji, aplikacje bez obu mechanizmów kontroli tworzą nieograniczone ścieżki dostępu, które mogą wykorzystać aktorzy zagrożeń. Gdy aplikacje aprowizują konta wszystkich użytkowników bez ograniczeń przydziału, podmioty zagrożeń mogą nadużywać kont zagrożonych w celu przeprowadzania działań rekonesansu, wyliczania poufnych danych w wielu systemach lub używania aplikacji jako punktów przejściowych w celu dalszych ataków na połączone zasoby. Ten nieograniczony model dostępu jest niebezpieczny dla aplikacji, które mają podwyższone uprawnienia lub są połączone z krytycznymi systemami biznesowymi. Aktorzy zagrożeń mogą używać dowolnego konta użytkownika, którego bezpieczeństwo jest naruszone, aby uzyskać dostęp do poufnych informacji, zmodyfikować dane lub wykonać nieautoryzowane akcje dozwolone przez uprawnienia aplikacji. Brak kontroli przypisania i określania zakresu aprowizacji uniemożliwia również organizacjom implementowanie prawidłowego ładu dostępu. Bez odpowiedniego ładu trudno jest śledzić, kto ma dostęp do których aplikacji, kiedy udzielono dostępu, i czy dostęp powinien zostać odwołany na podstawie zmian ról lub stanu zatrudnienia. Ponadto aplikacje z szerokimi zakresami aprowizacji mogą tworzyć kaskadowe zagrożenia bezpieczeństwa, gdy pojedyncze konto z naruszonymi zabezpieczeniami zapewnia dostęp do całego ekosystemu połączonych aplikacji i usług.

Akcja korygowania

Aplikacje dla przedsiębiorstw mają właścicieli

Aplikacje dla przedsiębiorstw bez właścicieli stają się osieroconymi zasobami, które mogą wykorzystać osoby stanowiące zagrożenie. Te aplikacje często zachowują podwyższone uprawnienia i dostęp do poufnych zasobów, jednocześnie nie mają odpowiedniego nadzoru i ładu w zakresie zabezpieczeń.

Aplikacje bez właścicieli tworzą luki w monitorowaniu bezpieczeństwa, gdzie osoby atakujące mogą utrwalić swoją obecność, wykorzystując istniejące uprawnienia aplikacji w celu uzyskania dostępu do danych lub tworzenia kont dostępu backdoor. Brak własności zapobiega również prawidłowym przeglądom dostępu i audytom uprawnień, umożliwiając aplikacjom posiadającym nadmierne uprawnienia lub nieaktualne konfiguracje pozostawać niezarządzane.

Przypisywanie właścicieli umożliwia efektywne zarządzanie cyklem życia aplikacji i zapewnia odpowiedni nadzór nad zabezpieczeniami.

Akcja korygowania

Ogranicz maksymalną liczbę urządzeń na użytkownika do 10

Kontrolowanie proliferacji urządzeń jest ważne. Ustaw rozsądny limit liczby urządzeń, które każdy użytkownik może zarejestrować w dzierżawie Microsoft Entra ID. Ograniczanie rejestracji urządzeń zapewnia bezpieczeństwo przy jednoczesnym umożliwieniu elastyczności biznesowej. Microsoft Entra ID pozwala użytkownikom domyślnie rejestrować maksymalnie 50 urządzeń. Zmniejszenie tej liczby do 10 minimalizuje obszar ataków i upraszcza zarządzanie urządzeniami.

Akcja korygowania

Skonfigurowano zasady dostępu warunkowego dla stacji roboczych dostępu uprzywilejowanego

Jeśli aktywacje ról uprzywilejowanych nie są ograniczone do dedykowanych stacji roboczych z dostępem uprzywilejowanym (PAW), aktorzy zagrożeń mogą wykorzystywać urządzenia punktu końcowego z naruszonymi zabezpieczeniami w celu przeprowadzania uprzywilejowanych ataków eskalacji z niezarządzanych lub niezgodnych stacji roboczych. Standardowe stacje robocze zwiększające produktywność często zawierają wektory ataków, takie jak nieograniczone przeglądanie internetu, klienci poczty e-mail podatni na wyłudzenie informacji i aplikacje zainstalowane lokalnie z potencjalnymi lukami w zabezpieczeniach. Gdy administratorzy aktywowali uprzywilejowane role z tych stacji roboczych, aktorzy zagrożeń, którzy uzyskują początkowy dostęp za pośrednictwem złośliwego oprogramowania, programów wykorzystujących luki w przeglądarce lub inżynierii społecznej, mogą następnie użyć lokalnie buforowanych uprzywilejowanych poświadczeń lub przejąć istniejące uwierzytelnione sesje w celu eskalacji swoich uprawnień. Aktywacje ról uprzywilejowanych zapewniają szerokie uprawnienia administracyjne w ramach identyfikatora Entra firmy Microsoft i połączonych usług, dzięki czemu osoby atakujące mogą tworzyć nowe konta administracyjne, modyfikować zasady zabezpieczeń, uzyskiwać dostęp do poufnych danych we wszystkich zasobach organizacji oraz wdrażać złośliwe oprogramowanie lub backdoory w całym środowisku w celu ustanowienia trwałego dostępu. Ten penetracja z naruszonego punktu końcowego do uprzywilejowanych zasobów w chmurze reprezentuje krytyczną ścieżkę ataku, która pomija wiele tradycyjnych mechanizmów kontroli zabezpieczeń. Dostęp uprzywilejowany jest wyświetlany jako legalny podczas uzyskiwania dostępu pochodzącego z sesji uwierzytelnionego administratora.

Jeśli ta kontrola przebiegnie pomyślnie, dzierżawa ma zasady dostępu warunkowego, które ograniczają dostęp uprzywilejowanej roli do urządzeń z dostępem uprzywilejowanym, ale nie jest to jedyna kontrola wymagana do pełnego włączenia rozwiązania z dostępem uprzywilejowanym. Należy również skonfigurować zasady konfiguracji i zgodności urządzeń usługi Intune oraz filtr urządzenia.

Akcja korygowania

  • Last updated on