Zarządzanie tożsamością

Zarządzanie tożsamościami ustanawia podstawy zabezpieczeń w chmurze, kontrolując, kto (użytkownicy, aplikacje, usługi) może uzyskać dostęp do zasobów, w jakich warunkach. W przeciwieństwie do tradycyjnych zabezpieczeń opartych na perimeterze, które polegają na granicach sieci i statycznych poświadczeniach, nowoczesne środowiska chmurowe wymagają dynamicznej weryfikacji tożsamości, ciągłego uwierzytelniania i decyzji dotyczących dostępu kontekstowego w rozproszonych architekturach wielodostępnych. Organizacje wdrażające kompleksowe zarządzanie tożsamościami zapobiegają atakom opartym na poświadczeniach, nieautoryzowanemu dostępowi i eskalacji uprawnień, podczas gdy organizacje zaniedbujące mechanizmy kontroli tożsamości napotykają kompromitację konta, ruch lateralny i ciągłe zagrożenia wykorzystujące słabe uwierzytelnianie lub nadmierne uprawnienia.

Oto cztery podstawowe filary domeny zabezpieczeń usługi Identity Management.

Ochrona tożsamości użytkowników: Ustanów i zachowaj bezpieczeństwo wszystkich kont użytkowników, szczególnie uprzywilejowanych użytkowników, za pośrednictwem scentralizowanego zarządzania tożsamościami, silnego uwierzytelniania wieloskładnikowego, pełnego zarządzania cyklem życia i bezpiecznych metod dostępu, w tym uprzywilejowanych stacji roboczych (PAW) i kont dostępu awaryjnego (break-glass).

Powiązane kontrolki:

• IM-1: Użyj scentralizowanego systemu tożsamości i uwierzytelniania
• IM-2: Ochrona systemów tożsamości i uwierzytelniania
• IM-5: Używanie logowania jednokrotnego na potrzeby dostępu do aplikacji
• IM-6: Używanie silnych kontrolek uwierzytelniania
• IM-7: Ograniczanie dostępu do zasobów na podstawie warunków

Ochrona aplikacji i wpisów tajnych: Bezpieczne zarządzanie tożsamościami nieludzkimi (aplikacjami, usługami) za pomocą zautomatyzowanego zarządzania tożsamościami, odpowiedniego uwierzytelniania serwera i usługi oraz bezpiecznego zarządzania wpisami tajnymi, aby zapobiec narażeniu na poświadczenia.

Powiązane kontrolki:

• IM-3: Bezpieczne i automatyczne zarządzanie tożsamościami aplikacji
• IM-4: Uwierzytelnianie serwera i usług
• IM-8: Ograniczanie ujawnienia poświadczeń i wpisów tajnych

Bezpieczny dostęp: Upewnij się, że użytkownicy mają odpowiedni dostęp do zasobów za pomocą zasad minimalnych uprawnień, unikając stałych kontroli dostępu i korzystając z kontroli dostępu uwzględniających kontekst na podstawie oceny ryzyka w czasie rzeczywistym.

Powiązane kontrolki:

• IM-7: Ograniczanie dostępu do zasobów na podstawie warunków

IM-1: Scentralizowanie tożsamości i uwierzytelniania przy jednoczesnym zapewnieniu izolacji

Azure Policy: Zobacz Wbudowane definicje zasad platformy Azure: IM-1.

Zasada zabezpieczeń

Użyj scentralizowanego systemu tożsamości i uwierzytelniania, aby zarządzać tożsamościami i uwierzytelnianiem organizacji dla zasobów w chmurze i innych niż chmura.

Podczas centralizowania zarządzania tożsamością i uwierzytelnianiem należy również zapewnić segregację i izolację tożsamości, zgodnie z ogólną strategią przedsiębiorstwa. Celem jest zapewnienie, że środowiska produkcyjne są zarządzane przy użyciu poświadczeń i tożsamości, które są oddzielone od tych używanych do codziennego dostępu. Identyfikacja segregacji i izolacji na podstawie strategii dla całego przedsiębiorstwa może obejmować:

• Egzekwowanie dostępu na zasadzie najmniejszych uprawnień dla tożsamości
• Segregowanie tożsamości administracyjnych i niezwiązanych z administracją
• Izolowanie tożsamości w różnych środowiskach
• Implementacja oddzielenia tożsamości obciążeń
• Wymuszanie separacji granic tożsamości między dzierżawami

Ryzyko w celu ograniczenia ryzyka

• Nieautoryzowany dostęp: Zdecentralizowane lub lokalne systemy uwierzytelniania często prowadzą do niespójnych zasad zabezpieczeń, słabych praktyk haseł lub niemonitorowanych kont, dzięki czemu osoby atakujące mogą wykorzystać błędnie skonfigurowane lub nieaktualne poświadczenia w celu uzyskania dostępu do poufnych zasobów (np. za pośrednictwem siłowych lub skradzionych poświadczeń).
• Kradzież poświadczeń i ponowne użycie: Pofragmentowane systemy tożsamości zwiększają ryzyko przechowywania poświadczeń niezabezpieczonych (np. w postaci zwykłego tekstu lub słabych skrótów) lub ponownego użycia w systemach, umożliwiając osobom atakującym zbieranie poświadczeń z jednego systemu z naruszonymi zabezpieczeniami i używanie ich w innym miejscu (np. za pośrednictwem wyłudzania informacji lub dumpingu poświadczeń).
• Niespójna kontrola dostępu: Bez scentralizowanego ładu różne systemy mogą mieć różne zasady dostępu, co prowadzi do nadmiernie uprzywilejowanych kont lub oddzielonych kont, które osoby atakujące mogą wykorzystać do eskalacji uprawnień lub dostępu do nieautoryzowanych zasobów.
• Brak widoczności i monitorowania: Uwierzytelnianie zdecentralizowane nie ma ujednoliconego rejestrowania i monitorowania, co utrudnia wykrywanie podejrzanych działań, takich jak nieautoryzowane próby logowania lub nietypowe zachowanie użytkownika, zwiększając ryzyko niezakrytych naruszeń.

MITRE ATT&CK

• Dostęp początkowy (TA0001): Wykorzystanie słabych lub zdecentralizowanych mechanizmów uwierzytelniania, takich jak konta lokalne z domyślnymi poświadczeniami lub nieaktualnymi protokołami, dzięki czemu osoby atakujące mogą uzyskać nieautoryzowany wpis (np. T1078 — prawidłowe konta).
• Dostęp poświadczeń (TA0006): kradzież poświadczeń z pofragmentowanych systemów tożsamości, wykorzystanie niezabezpieczonego magazynu (np. haseł w postaci zwykłego tekstu w systemach lokalnych) lub słabe metody uwierzytelniania, ułatwiając dumping poświadczeń lub ponowne użycie (np. T1003 — dumping poświadczeń systemu operacyjnego).
• Eskalacja uprawnień (TA0004): Wykorzystanie niespójnych mechanizmów kontroli dostępu w zdecentralizowanych systemach do eksploatowania kont z nadmiernymi uprawnieniami lub osieroconych, co umożliwia osobom atakującym podniesienie poziomu dostępu do poufnych zasobów (np. T1078 — ważne konta).
• Uchylanie się od obrony (TA0005): Pomijanie wykrywania z powodu braku scentralizowanego monitorowania, dzięki czemu osoby atakujące mogą wykonywać nieautoryzowane akcje bez wyzwalania alertów (np. T1562 — Upośledzanie zabezpieczeń).

IM-1.1: Scentralizowanie tożsamości i uwierzytelniania

Scentralizowane zarządzanie tożsamościami eliminuje zagrożenia bezpieczeństwa pofragmentowanych systemów uwierzytelniania, zapewniając spójne wymuszanie zasad, ujednolicone monitorowanie i usprawnione sterowanie dostępem we wszystkich zasobach. Nowoczesne środowiska w chmurze wymagają jednego autorytatywnego źródła tożsamości, które obsługuje silne metody uwierzytelniania, zasady dostępu warunkowego i kompleksowe rejestrowanie inspekcji. Organizacje przyjmujące scentralizowane systemy tożsamości zmniejszają rozrastanie poświadczeń, zwiększają widoczność stanu zabezpieczeń i upraszczają zgodność przy zachowaniu elastyczności architektur hybrydowych i wielochmurowych.

Zaimplementuj scentralizowane zarządzanie tożsamościami przy użyciu następującego podejścia:

• Wdrażanie platformy tożsamości w chmurze: Microsoft Entra ID to wielodostępna, oparta na chmurze usługa zarządzania tożsamościami i dostępem, która centralizuje uwierzytelnianie, autoryzację i ład w środowiskach firmy Microsoft i innych firm, które obsługują identyfikator Entra. Standaryzuj Microsoft Entra ID, aby zarządzać tożsamościami we wszystkich zasobach.

• Zarządzanie tożsamościami zasobów w chmurze: Użyj tożsamości zarządzanych i federacji tożsamości obciążeń dla zasobów chmury Microsoft, w tym Azure Storage, maszyn wirtualnych Azure (Linux i Windows), Azure Key Vault, a także aplikacji PaaS i SaaS, aby wyeliminować tajne oraz zapewnić izolację.

• Scentralizowane uwierzytelnianie zasobów organizacji: Korzystaj z logowania jednokrotnego (SSO) i dostępu warunkowego do zasobów organizacji, takich jak aplikacje hostowane na platformie Azure, aplikacje innych firm w sieciach firmowych i aplikacje SaaS innych firm, aby zapewnić bezpieczny, kontekstowy dostęp.

• Synchronizowanie tożsamości hybrydowych: Synchronizuj lokalną usługę Active Directory z identyfikatorem Entra ID firmy Microsoft za pośrednictwem usługi Microsoft Entra Connect Sync , aby zachować spójną, centralnie zarządzaną strategię tożsamości hybrydowej dla tożsamości przedsiębiorstwa.

• Eliminowanie uwierzytelniania lokalnego dla usług platformy Azure: Unikaj lokalnych metod uwierzytelniania dla usług platformy Azure i używaj identyfikatora Entra firmy Microsoft do scentralizowania uwierzytelniania, stosowania metod bez hasła (np. windows Hello, kluczy FIDO2) i uwierzytelniania wieloskładnikowego (MFA), aby zwiększyć bezpieczeństwo.

Uwaga: W porównaniu z rozwiązaniem Active Directory, Microsoft Entra zapewnia korzyści z silnego uwierzytelniania, zasad dostępu warunkowego itp. Gdy tylko będzie to technicznie możliwe, należy przeprowadzić migrację lokalnych aplikacji opartych na Active Directory do Microsoft Entra ID, używając konfiguracji, takich jak dzierżawy pracownicze dla użytkowników wewnętrznych, Microsoft Entra B2B na potrzeby współpracy z partnerami lub Microsoft Entra External ID dla aplikacji przeznaczonych dla klientów. Możesz również korzystać z usług Microsoft Entra Domain Services dla starszych aplikacji wymagających atrybutów niestandardowych.

Przykład implementacji

Scenariusz: Organizacja usług finansowych wymaga scentralizowanego zarządzania tożsamościami z ścisłą izolacją między środowiskami produkcyjnymi, deweloperskimi i partnerskimi w celu zapewnienia zgodności z przepisami i zapobiegania ruchom bocznym.

Kroki implementacji:

1. Wdróż Microsoft Entra ID jako scentralizowanego dostawcę tożsamości:

   • Utwórz główną dzierżawę (contoso.onmicrosoft.com) dla tożsamości firmowej
   • Konfigurowanie usługi Microsoft Entra Connect Sync w celu synchronizowania lokalnych użytkowników usługi AD
   • Włącz ochronę entra ID dla zasad opartych na ryzyku i dostępu warunkowego wymagającego uwierzytelniania wieloskładnikowego dla administratorów
   • Konfigurowanie logowania jednokrotnego dla aplikacji SaaS (Salesforce, ServiceNow, GitHub)
   • Wdrażanie tożsamości zarządzanych dla zasobów platformy Azure, eliminowanie uwierzytelniania lokalnego w usłudze Azure SQL/Storage
   • Włączanie uwierzytelniania bez hasła przy użyciu kluczy FIDO2 i funkcji Windows Hello

2. Projektowanie hierarchii grup zarządzania pod kątem izolacji:

Tenant Root Group
├── Corporate Production (finance-prod-sub, hr-prod-sub)
├── Corporate Non-Production (dev-sub, test-sub)
├── Partner Integration (partner-sub)
└── Customer-Facing Tenant (customer-prod-sub, customer-staging-sub)

3. Zaimplementuj segregację tożsamości:

   • Tożsamości produkcyjne: Dedykowane konta administratora z PAWs, bez dostępu developerskiego/testowego
   • Tożsamości deweloperskie: Standardowe konta z podwyższonym poziomem uprawnień tylko w środowisku dev
   • Tożsamości partnerów:Microsoft Entra B2B z ograniczonym czasem dostępu
   • Tożsamości klientów: Oddzielna dzierżawa z użyciem Microsoft Entra External ID

4. Wymuszanie izolacji na poziomie subskrypcji:

   • Przypisz RBAC platformy Azure na zakresie subskrypcji (grupa prod-admin-group: właściciel tylko na finance-prod-sub)
   • Stosowanie dostępu warunkowego wymagającego zgodnych urządzeń w celu uzyskania dostępu do środowiska produkcyjnego
   • Konfigurowanie usługi Azure Policy na poziomie grupy zarządzania dla punktów odniesienia zabezpieczeń
   • Włącz oddzielne obszary robocze usługi Log Analytics dla każdego środowiska

5. Implementowanie mechanizmów kontroli zabezpieczeń:

   • Używanie granic subskrypcji do izolowania rozliczeń, zasobów i uprawnień
   • Wdrażanie usługi Azure Firewall w celu ograniczenia ruchu między środowiskami
   • Włączanie usługi Defender for Cloud na potrzeby ujednoliconego monitorowania zabezpieczeń
   • Streaming dzienników inspekcji Entra ID do usługi Azure Monitor i alert dotyczący prób dostępu między środowiskami.
   • Przeprowadzaj kwartalne przeglądy dostępu przy użyciu Entra ID Governance

Wyniki:

Organizacja ustanowiła pojedynczą scentralizowaną platformę tożsamości zarządzającą całym uwierzytelnianiem, eliminując rozdrobnione silosy tożsamości. Poświadczenia produkcyjne są całkowicie odizolowane od dostępu deweloperów dzięki ścisłej separacji środowiska, zapewniając, że naruszenie poświadczeń programistycznych nie może mieć wpływu na obciążenia produkcyjne. Spójne zasady uwierzytelnienia wieloskładnikowego i dostępu warunkowego są wymuszane we wszystkich środowiskach, podczas gdy zgodność regulacyjna jest utrzymywana przez kompleksowe rejestry audytowe i podział obowiązków.

Reference:Samouczek dla początkujących Microsoft Entra ID

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: AC-2, AC-3, AC-4, AC-6, SC-2, SC-7
• PCI-DSS 4: 1.4.2, 7.2.1, 7.2.2, 8.2.1
• Kontrolki CIS w wersji 8.1: 6.7, 12.5, 16.1
• NIST CSF v2.0: PR.AA-1, PR.AC-1, PR.AC-7
• ISO 27001:2022: A.5.15, A.5.16, A.8.2
• SOC 2: CC6.1, CC6.2, CC6.6

IM-2: Ochrona systemów tożsamości i uwierzytelniania

Azure Policy: Zobacz Wbudowane definicje zasad platformy Azure: IM-2.

Zasada zabezpieczeń

Zabezpiecz system tożsamości i uwierzytelniania jako wysoki priorytet w praktyce zabezpieczeń w chmurze organizacji. Typowe mechanizmy kontroli zabezpieczeń obejmują:

• Ograniczanie ról i kont uprzywilejowanych
• Wymagaj silnego uwierzytelniania dla wszystkich uprzywilejowanych dostępów
• Monitorowanie i przeprowadzanie inspekcji działań o wysokim ryzyku

Ryzyko w celu ograniczenia ryzyka

• Ataki oparte na poświadczeniach: Uwierzytelnianie bez federacji, starsze protokoły (np. POP3, IMAP) i niezabezpieczone przepływy zgody protokołu OAuth 2.0 tworzą punkty dostępu możliwe do wykorzystania, umożliwiając atakującym naruszenie poświadczeń lub tokenów (np. poprzez atak siłowy, wyłudzenie informacji lub nadużycie zgody protokołu OAuth) na infiltrację systemów.
• Podniesienie uprawnień: Nadmiernie przyznane role RBAC, stały dostęp uprzywilejowany i nadmierne przydzielanie ról administratora globalnego umożliwiają uzyskiwanie nieautoryzowanych uprawnień, co jest wykorzystywane przez atakujących do przejęcia konta lub niewłaściwego użycia certyfikatu atrybutu uprawnień (PAC) w celu eskalacji dostępu.
• Naruszenia granic zasobów: Niespójne zarządzanie subskrypcjami i brak segregacji środowisk umożliwiają dostęp między zasobami, wykorzystywany przez atakujących poprzez ruch lateralny (np. wykorzystanie źle skonfigurowanych zasad bezpieczeństwa usług) w celu naruszenia granic środowisk deweloperskich, testowych lub produkcyjnych.
• Nadużycie tożsamości między dzierżawami: słabe uwierzytelnianie między dzierżawami i niezweryfikowane tożsamości federacyjne narażają środowiska wielodzierżawowe, wykorzystywane przez atakujących poprzez odtwarzanie tokenów lub nieautoryzowaną federację tożsamości w celu uzyskania dostępu do dzierżaw zewnętrznych.
• Trwałość dostępu: Nieodpowiednie zarządzanie cyklem życia tożsamości i niemonitorowane przeglądy dostępu prowadzą do nieaktualnych lub zbyt dużych uprawnień, które są wykorzystywane przez atakujących poprzez ponowną aktywację uśpionych kont lub wykorzystanie osieroconych zasad usługi w celu utrzymania długoterminowego dostępu.
• Uchylanie się od wykrywania zagrożeń: pofragmentowane monitorowanie i nieskonfigurowane alerty w czasie rzeczywistym w środowiskach chmurowych i lokalnych ukrywają złośliwe działania, wykorzystywane przez osoby atakujące za pośrednictwem ataków Kerberos (np. pass-the-ticket) lub nietypowe użycie tokenu w celu uniknięcia wykrycia.
• Błędna konfiguracja polityk: niewymuszone polityki ładu i brak scentralizowanych mechanizmów kontroli Grup Zarządzania prowadzą do niespójnych ustawień zabezpieczeń, wykorzystywane przez atakujących za pośrednictwem nieprawidłowo skonfigurowanego dostępu warunkowego lub przypisań ról w celu obejścia ograniczeń.

MITRE ATT&CK

• Dostęp początkowy (TA0001): Wykorzystywanie niefederowanych protokołów tożsamości lub nieprawidłowo skonfigurowanych zgody aplikacji OAuth 2.0, umożliwiając przeciwnikom uzyskanie nieautoryzowanego wpisu (np. T1078 — prawidłowe konta).
• Dostęp poświadczeń (TA0006): kradzież tokenów dostępu lub tajnych danych tożsamości usługi z niezabezpieczonych konfiguracji tożsamości, wykorzystanie słabych metod przechowywania lub przestarzałe metody uwierzytelniania, ułatwienie kompromitacji poświadczeń (np. T1110 — brutalna siła).
• Eskalacja uprawnień (TA0004): Wykorzystanie nadmiernie uprzywilejowanych przypisań RBAC lub błędnie skonfigurowanych certyfikatów atrybutów uprawnień (PAC) w systemach tożsamości, co umożliwia przeciwnikom podniesienie poziomu dostępu do poufnych zasobów (np. T1134 — manipulowanie tokenem dostępu).
• "Przenoszenie boczne" (TA0008): Wykorzystywanie niesegregowanych subskrypcji lub niewłaściwej konfiguracji tożsamości między dzierżawcami, co umożliwia przeciwnikom przechodzenie przez środowisko lub granice dzierżaw (np. T1578 – Modyfikowanie infrastruktury obliczeniowej chmury).
• Trwałość (TA0003): Manipulowanie niezauważalnym cyklem życia tożsamości lub osieroconymi jednostkami usługowymi, co umożliwia ataktorom utrzymanie długotrwałego dostępu za pośrednictwem przeterminowanych poświadczeń (np. T1098 — manipulowanie kontem).
• Uchylanie się od obrony (TA0005): Wykorzystywanie niemonitorowanych działań związanych z tożsamościami lub manipulowanie biletami Protokołu Kerberos, umożliwiając przeciwnikom ukrywanie złośliwych akcji, takich jak nietypowe użycie tokenów (np. T1550 — Używanie alternatywnego materiału uwierzytelniania).

IM-2.1: Ocena wskaźnika bezpieczeństwa tożsamości

Stan zabezpieczeń tożsamości wymaga ciągłej oceny i poprawy dzięki mierzalnym metryom, które identyfikują luki w konfiguracji i słabości zabezpieczeń. Wskaźnik bezpieczeństwa tożsamości zawiera zalecenia umożliwiające podejmowanie działań w celu wzmocnienia mechanizmów kontroli uwierzytelniania, zmniejszenia narażenia na dostęp uprzywilejowany i zaimplementowania nowoczesnych funkcji zabezpieczeń, które uniemożliwiają ataki oparte na poświadczeniach. Organizacje regularnie przeglądające swój wskaźnik bezpieczeństwa identyfikują ulepszenia o wysokim wpływie, priorytetyzują działania korygujące i wykazują dojrzałość zabezpieczeń dla uczestników projektu, zachowując zgodność ze strukturami branżowymi.

Ocenianie i ulepszanie stanu zabezpieczeń tożsamości za pomocą następujących rozwiązań:

• Ocena wskaźnika bezpieczeństwa tożsamości: Użyj wskaźnika bezpieczeństwa tożsamości , aby ocenić stan zabezpieczeń tożsamości i rozwiązać problemy z lukami w konfiguracji, oceniając przypisania ról administracyjnych, wymuszanie uwierzytelniania wieloskładnikowego, stan starszego uwierzytelniania i zasady zgody.

• Przypisz ograniczone role administracyjne: Egzekwowanie zasady minimalnych uprawnień przez przypisanie ograniczonych ról administracyjnych i wyznaczenie 2-4 administratorów globalnych dla celów nadmiarowości, jednocześnie unikając nadmiernego przydzielania uprawnień.

• Włącz zasady ochrony tożsamości: Włącz zasady ryzyka związanego z użytkownikiem i logowaniem za pośrednictwem usługi Microsoft Entra ID Protection i blokuj starsze protokoły uwierzytelniania, aby zapobiec niezabezpieczonemu dostępowi.

• Wymuszanie uwierzytelniania wieloskładnikowego: Wymagaj uwierzytelniania wieloskładnikowego dla wszystkich użytkowników obsługujących metody bez hasła (np. FIDO2, Windows Hello) i wymuszaj uwierzytelnianie wieloskładnikowe dla ról administracyjnych w celu zabezpieczenia dostępu uprzywilejowanego.

• Włącz funkcje samoobsługi: Włącz samoobsługowe resetowanie haseł (SSPR) na potrzeby bezpiecznego odzyskiwania opartego na użytkowniku i ustaw wygaśnięcie hasła dla kont wysokiego ryzyka (np. ról uprzywilejowanych) równoważących zabezpieczenia i użyteczność.

• Kontrolowanie zgody aplikacji: Ogranicz użytkownikom udzielanie zgody na aplikacje niezarządzane, aby zapobiec nieautoryzowanemu dostępowi.

• Wdrażanie wykrywania zagrożeń tożsamości: Skorzystaj z usługi Microsoft Entra ID Protection, aby wykrywać, badać i korygować zagrożenia oparte na tożsamościach. W przypadku lokalnej usługi Active Directory użyj usługi Microsoft Defender for Identity zintegrowanej z usługą Microsoft 365 Defender, aby monitorować i chronić środowiska hybrydowe.

Uwaga: postępuj zgodnie z najlepszymi rozwiązaniami firmy Microsoft dla wszystkich innych składników tożsamości, w tym lokalnych usług Active Directory, możliwości innych firm i infrastruktury hostingu (systemów operacyjnych, sieci, baz danych), aby zapewnić bezpieczeństwo tożsamości i dostępu.

Przykład implementacji

Scenariusz: Organizacja usług finansowych musi poprawić poziom zabezpieczeń tożsamości dla 5000 użytkowników i 200+ aplikacji przy użyciu ciągłego monitorowania i ochrony opartej na ryzyku.

Kroki implementacji:

1. Ustanów punkt odniesienia przy użyciu wskaźnika bezpieczeństwa tożsamości:

   • Dostęp do pulpitu nawigacyjnego Secure Score w Microsoft Entra ID (bieżący wynik: 62/100)
   • Przejrzyj zalecenia z priorytetami: Zmniejszenie liczby administratorów globalnych (8→3), wymuszanie uwierzytelniania wieloskładnikowego dla kont uprzywilejowanych, wyłączanie starszego uwierzytelniania, ograniczanie zgody aplikacji
   • Ustaw wynik docelowy: 85/100 w ciągu 90 dni

2. Wdróż usługę Microsoft Entra ID Protection w celu automatycznego wykrywania ryzyka:

   • Włączanie zasad opartych na ryzyku: wymagaj zmiany hasła dla użytkowników wysokiego ryzyka, wymagaj uwierzytelniania wieloskładnikowego na potrzeby logowania średniego/wysokiego ryzyka
   • Konfigurowanie alertów dotyczących ujawnionych poświadczeń, nietypowych działań, prób eskalacji uprawnień
   • Integracja z usługą Microsoft 365 Defender na potrzeby skorelowanej analizy zagrożeń

3. Implementowanie ciągłego monitorowania:

   • Ustanawianie cotygodniowych przeglądów wskaźnika bezpieczeństwa i codziennego monitorowania wykrywania ryzyka
   • Konfigurowanie zautomatyzowanego korygowania: automatyczne blokowanie adresów IP wysokiego ryzyka, wyzwalanie resetowania hasła dla poświadczeń, odwoływanie sesji w przypadku nietypowego zachowania
   • Przeprowadzać kwartalne przeglądy dostępu w celu usunięcia przestarzałych uprawnień uprzywilejowanych

Wyniki:

Organizacja znacznie poprawiła stan zabezpieczeń tożsamości dzięki ciągłemu monitorowaniu i ochronie opartej na ryzyku. Wskaźnik bezpieczeństwa tożsamości znacznie wzrósł w ramach docelowego przedziału czasu, podczas gdy konta administratorów globalnych zostały zredukowane w celu dostosowania do najlepszych rozwiązań dotyczących najniższych uprawnień. Pokrycie uwierzytelniania wieloskładnikowego osiągnęło pełne wdrożenie dla wszystkich kont uprzywilejowanych, a starsze protokoły uwierzytelniania zostały wyłączone, co znacznie zmniejsza obszar ataków. Automatyczne wykrywanie ryzyka i możliwości reagowania znacznie skróciły czas odpowiedzi, podczas gdy ataki oparte na poświadczeniach zostały całkowicie wyeliminowane dzięki proaktywnego monitorowania i zautomatyzowanego korygowania.

Reference:

• Nowe zalecenia dotyczące wskaźnika Identity Secure Score w ogólnej dostępności
• Monitorowanie i ocena ryzyka z Microsoft Entra ID Protection

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: AC-2, AC-3, IA-2, IA-4, IA-5, IA-8, SI-4
• PCI-DSS 4: 7.2.1, 8.2.1, 8.3.1, 8.3.2, 10.2.1
• Kontrolki CIS wersja 8.1: 5.4, 6.3, 6.5, 8.2
• NIST CSF v2.0: PR.AA-1, PR.AC-1, DE.CM-1
• ISO 27001:2022: A.5.15, A.5.16, A.5.17, A.8.5
• SOC 2: CC6.1, CC6.2, CC6.6, CC7.2

IM-3: Bezpieczne i automatyczne zarządzanie tożsamościami aplikacji

Azure Policy: Zobacz Wbudowane definicje zasad platformy Azure: IM-3.

Zasada zabezpieczeń

Użyj tożsamości aplikacji zarządzanych zamiast tworzyć konta użytkowników dla aplikacji w celu uzyskiwania dostępu do zasobów i wykonywania kodu. Tożsamości zarządzanych aplikacji zapewniają korzyści, takie jak zmniejszenie ryzyka ujawnienia danych uwierzytelniających. Zautomatyzuj rotację poświadczeń, aby zapewnić bezpieczeństwo tożsamości.

Ryzyko w celu ograniczenia ryzyka

• Ujawnienie poświadczeń zakodowanych na stałe w kodzie lub plikach konfiguracyjnych: statyczne poświadczenia (np. klucze API, tajne klucze klienta) osadzone w kodzie źródłowym, artefaktach kompilacji lub plikach konfiguracyjnych (np. .env, YAML) są ujawniane przez błędnie skonfigurowane repozytoria systemu kontroli wersji (SCM) (np. publiczne repozytoria Git) lub potoki ciągłej integracji i wdrażania, co umożliwia uwierzytelnienie się przez przeciwników do interfejsów API chmury za pośrednictwem żądań HTTP POST skierowanych do punktów końcowych tokenów.
• Kradzież poświadczeń za pośrednictwem wyłudzania informacji lub przechwytywania: przeciwnicy przechwytują długotrwałe poświadczenia lub klucze interfejsu API za pośrednictwem kampanii spearphishing (np. wyłudzania zgody OAuth) lub ataków MitM przechwytujących niezaszyfrowany ruch HTTP/HTTPS, wykorzystując słabe konfiguracje protokołu TLS do uzyskiwania tokenów na potrzeby uwierzytelniania usługi w chmurze.
• Nieautoryzowany dostęp ze słabych lub ponownie użytych poświadczeń: niezabezpieczone poświadczenia (np. hasła o niskiej entropii, ponowne użycie kluczy interfejsu API) są narażone na wyliczenie siłowe (np. rozpylanie haseł za pośrednictwem wywołań interfejsu API REST) lub ataki wypychania poświadczeń wykorzystujące naruszone zestawy danych, udzielając dostępu do interfejsów API zarządzania chmurą.
• Trwały dostęp za pośrednictwem nieautoryzowanych lub oddzielonych kont: osoby atakujące tworzą nieautoryzowane konta lub wykorzystują niezwołane poświadczenia z zlikwidowanych zasobów, osadzając klucze statyczne w szablonach aranżacji w chmurze (np. pliki IaC), aby zachować trwały dostęp za pośrednictwem powtarzających się wymiany tokenów OAuth 2.0.
• Eskalacja uprawnień z nadmiernie uprzywilejowanych poświadczeń: poświadczenia z nadmiernie szerokimi uprawnieniami (np. klucze API z rolami IAM na poziomie administratora) umożliwiają przeciwnikom eskalację uprawnień poprzez wywoływanie operacji API o wysokim poziomie uprawnień (np. tworzenie zasobów, modyfikacja zasad), wykorzystując nieprawidłowo skonfigurowane uprawnienia RBAC.
• Wykrywanie poświadczeń z systemów z naruszonymi zabezpieczeniami: Atakujący pozyskują poświadczenia w postaci zwykłego tekstu, klucze API lub tokeny OAuth z naruszonych instancji chmury (np. za pomocą scrapingu pamięci) lub niezabezpieczonego magazynu (np. zasobniki S3, magazyny konfiguracji), wykorzystując zebrane dane do uwierzytelniania w dodatkowych interfejsach API chmury w celu przeprowadzania ruchów bocznych.
• Unikanie wykrycia przez niemonitorowane użycie poświadczeń: Adwersarze wykorzystują skradzione statyczne poświadczenia do generowania żądań API, które imitują autoryzowany ruch. W ten sposób unikają detekcji, korzystając z wyłączonego logowania inspekcyjnego lub braku wykrywania anomalii w chmurowej telemetrii, co opóźnia identyfikację nieautoryzowanego dostępu.

MITRE ATT&CK

• Dostęp początkowy (TA0001): wykorzystanie zakodowanych na stałe poświadczeń lub skompromitowanych kont użytkowników osadzonych w kodzie aplikacji chmurowej lub plikach konfiguracyjnych, wykorzystując phishing (T1566.001) w celu kradzieży haseł lub wykorzystywanie nieprawidłowo skonfigurowanych publicznych interfejsów API (T1190) do uwierzytelniania za pośrednictwem protokołu OAuth 2.0 lub punktów końcowych opartych na kluczach API.
• Dostęp poświadczeń (TA0006): atakowanie ujawnionych poświadczeń w repozytoriach kodu źródłowego lub niezabezpieczonym magazynie danych (T1003), za pomocą ataków typu brute-force na słabe hasła użytkowników (T1110.001) lub przechwytywanie kluczy API i tokenów sesji (T1539) podczas procesów uwierzytelniania usług w chmurze.
• Trwałość (TA0003): utrzymywanie dostępu przez tworzenie nieautoryzowanych kont użytkowników (T1136.003) lub modyfikowanie konfiguracji aplikacji w chmurze w celu osadzania trwałych poświadczeń (T1098.001), zapewniając wielokrotne uwierzytelnianie do zasobów w chmurze bez wykrywania.
• Eskalacja uprawnień (TA0004): Naruszone konta użytkowników lub ujawnione klucze interfejsu API z nadmiernymi uprawnieniami są wykorzystywane w celu uzyskania dostępu administracyjnego, nadużywania nieprawidłowo skonfigurowanych kontroli dostępu opartej na rolach (T1548.004) w celu manipulowania zasobami w chmurze lub interfejsami API zarządzania.
• Unikanie obrony (TA0005): Atakujący unikają wykrywania poprzez podrabianie skradzionych kluczy API lub tokenów sesji (T1606.002), aby naśladować prawdziwy ruch chmury, lub wyłączając rejestrowanie audytu (T1562.001), podszywając się pod autoryzowanych użytkowników (T1036), aby uniknąć monitorowania.
• Kolekcja (TA0009): zbieranie zahardcodowanych poświadczeń, kluczy API lub danych sesji użytkownika z naruszonych wystąpień chmury lub magazynów (T1213.002), ukierunkowanie na pliki konfiguracyjne lub zrzuty pamięci (T1005) w celu zbierania poufnych danych na potrzeby ruchu lateralnego.

IM-3.1: Używanie tożsamości zarządzanej w obsługiwanych zasobach platformy Azure

Zarządzane tożsamości eliminują ekspozycję poświadczeń, zapewniając zasobom platformy Azure automatycznie zarządzane tożsamości do uwierzytelniania w usługach obsługujących uwierzytelnianie Microsoft Entra ID. Te poświadczenia zarządzane przez platformę są w pełni rotowane i chronione bez konieczności kodowania tajnych danych w kodzie źródłowym lub plikach konfiguracji, co zmniejsza powierzchnię ataku i koszty operacyjne. Organizacje przyjmujące zarządzane tożsamości uniemożliwiają kradzież poświadczeń, upraszczają zarządzanie tajnymi danymi i utrzymują zgodność z zabezpieczeniami, umożliwiając bezproblemowe uwierzytelnianie między usługami w zasobach platformy Azure.

Zaimplementuj tożsamości zarządzane, wykonując następujące kroki:

• Wybierz i włącz tożsamość zarządzaną: Zdecyduj między przypisaną przez system (powiązaną z pojedynczym zasobem, automatycznie usuwaną wraz z zasobem) lub przypisaną przez użytkownika (autonomiczną, wielokrotnego użytku w wielu zasobach) na podstawie Twojego przypadku użycia. Włącz tożsamość zarządzaną podczas tworzenia zasobów (np. włącz tożsamość przypisaną przez system dla usługi Azure App Service w celu uzyskania dostępu do usługi Key Vault).

• Przypisz uprawnienia o zasadzie najmniej uprawnień: Użyj Azure Role-Based Access Control (RBAC), aby nadać zarządzanej tożsamości określone role (np. Key Vault Secrets User lub Storage Blob Data Reader) dla docelowych usług Azure.

• Integrowanie uwierzytelniania w kodzie aplikacji: Użyj zestawów AZURE SDK (np. Azure.Identity na platformie .NET, azure-identity w języku Python) z ustawieniem DefaultAzureCredential, aby uwierzytelnić się w usługach takich jak Key Vault, SQL Database lub Storage bez osadzania poświadczeń. Na przykład w języku C# użyj var credential = new DefaultAzureCredential(); aby pobrać token, aby uzyskać dostęp do sekretu w usłudze Key Vault.

• Włącz automatyczne odświeżanie tokenu: Upewnij się, że aplikacja automatycznie obsługuje odświeżanie tokenów (tokeny zwykle wygasają po 24 godzinach).

IM-3.2: Użyj zasad serwisowych, gdy tożsamości zarządzane nie są stosowane.

Jednostki usługi zapewniają bezpieczne uwierzytelnianie dla usług i aplikacji, które nie mogą używać tożsamości zarządzanych, implementujące dostęp oparty na poświadczeniach z rozszerzonymi mechanizmami kontroli zabezpieczeń. Organizacje powinny nadawać priorytet poświadczeniom certyfikatu zamiast tajnych zapisów klienta, aby zmniejszyć ryzyko narażenia, zachowując ścisłe granice uprawnień poprzez przypisań RBAC z najmniejszymi uprawnieniami. Prawidłowo skonfigurowane jednostki usługowe umożliwiają bezpieczne scenariusze automatyzacji i integracji, jednocześnie minimalizując ryzyko kradzieży poświadczeń dzięki zasadom rotacji tajnych i bezpiecznemu przechowywaniu w skarbcu.

Zaimplementuj zasady usługi przy użyciu następującego podejścia:

• Utwórz jednostkę usługi w identyfikatorze Entra firmy Microsoft: Użyj identyfikatora Entra firmy Microsoft, aby utworzyć jednostkę usługi dla usług, które nie obsługują tożsamości zarządzanych, zapewniając, że reprezentuje aplikację lub usługę (np. zarejestruj aplikację dla starszej usługi wymagającej dostępu do usługi Azure Storage).

• Konfigurowanie ograniczonych uprawnień: Przypisz uprawnienia najniższych uprawnień do jednostki usługi przy użyciu usługi Azure Role-Based Access Control (RBAC) na poziomie zasobu (np. Współautor danych obiektu blob usługi Storage dla określonego konta magazynu).

• Użyj poświadczeń opartych na certyfikatach: Preferuj poświadczenia certyfikatowe zamiast wpisów tajnych klienta w celu zapewnienia zwiększonych zabezpieczeń. Wygeneruj certyfikat z podpisem własnym lub wystawiony przez urząd certyfikacji i prześlij go do podmiotu usługi w Entra ID.

• W razie potrzeby wykorzystaj tajne klucze klienta: Jeśli certyfikaty nie są możliwe, utwórz tajny klucz klienta w Entra ID o zdefiniowanym wygaśnięciu (np. 1 rok). Bezpiecznie przechowuj wpis tajny w usłudze Azure Key Vault i programowo pobieraj go, unikając kodowania twardego w kodzie źródłowym lub plikach konfiguracji. Obracanie wpisów tajnych przed wygaśnięciem i usuwanie nieużywanych wpisów tajnych w celu zminimalizowania ryzyka.

• Integrowanie uwierzytelniania w kodzie aplikacji: Użyj zestawów SDK platformy Azure (np. ClientCertificateCredential lub ClientSecretCredential w usłudze Azure.Identity), aby uwierzytelnić się przy użyciu poświadczeń jednostki usługi w kodzie aplikacji.

Przykład implementacji

Scenariusz: Organizacja opieki zdrowotnej z ponad 50 aplikacjami wymaga bezpiecznego uwierzytelniania pod kątem zgodności HIPAA, eliminując poświadczenia z plików kodu i konfiguracji.

Kroki implementacji:

1. Wdrażanie tożsamości zarządzanych dla usług platformy Azure:

   • Włącz tożsamości przypisane przez system dla 30 usług App Service uzyskujących dostęp do SharePoint i Azure SQL
   • Konfigurowanie tożsamości przypisanych przez użytkownika dla 15 Azure Functions, które dostępują do Key Vault i Service Bus
   • Wdrażanie tożsamości zarządzanych na maszynach wirtualnych na potrzeby zadań przetwarzania w tle
   • Refaktoryzacja kodu aplikacji za pomocą zestawu Azure.Identity SDK (DefaultAzureCredential)

2. Konfigurowanie zasad serwisowych dla starszych systemów:

   • Tworzenie 5 jednostek usługi przy użyciu uwierzytelniania opartego na certyfikatach (X.509 na podstawie organizacyjnej infrastruktury kluczy publicznych)
   • Przechowywanie certyfikatów w usłudze Azure Key Vault przy użyciu automatycznej rotacji
   • Przypisywanie ról kontroli dostępu opartej na rolach o najniższych uprawnieniach do określonych grup zasobów
   • W przypadku potoków ciągłej integracji/ciągłego wdrażania: używaj sekretów klienta z 6-miesięcznym wygaśnięciem i automatyczną rotacją

3. Wdrażanie monitorowania i zarządzania:

   • Wdrażanie usługi Azure Policy w celu inspekcji zasobów bez tożsamości zarządzanych
   • Konfigurowanie usługi Defender for Cloud w celu wykrywania ujawnienia poświadczeń
   • Ustanawianie kwartalnych przeglądów dostępu dla uprawnień jednostki usługi
   • Monitoruj dzienniki logowania pod kątem nietypowych działań głównej usługi

Wyniki:

Organizacja pomyślnie zmigrowała zdecydowaną większość aplikacji do tożsamości zarządzanych, eliminując konieczność zarządzania poświadczeniami w nowoczesnych usługach natywnych dla chmury. Starsze systemy, które nie mogły przyjąć tożsamości zarządzanych, zostały zabezpieczone przy użyciu podstawowych jednostek usługi opartych na certyfikatach z możliwością automatycznej rotacji certyfikatów. Wszystkie zakodowane na stałe poświadczenia zostały usunięte z kodu aplikacji i plików konfiguracji, co umożliwiło pełną automatyzację rotacji poświadczeń dla podmiotów usługi. Ta kompleksowa transformacja wyeliminowała wszystkie ustalenia inspekcji zgodności związane z zarządzaniem poświadczeniami, które zostały wcześniej zidentyfikowane.

Reference:

• Udzielanie dostępu do witryn usługi SharePoint Online zasobom platformy Azure przy użyciu tożsamości zarządzanej
• Praca z kontami głównymi usługi platformy Azure

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: AC-2, AC-3, IA-2, IA-4, IA-5, IA-9, SC-12, SC-13
• PCI-DSS 4: 8.2.1, 8.2.2, 8.3.1, 8.5.1
• Kontrolki CIS w wersji 8.1: 6.7, 12.5, 16.1, 16.9
• NIST CSF v2.0: PR.AA-1, PR.AC-1, PR.DS-1
• ISO 27001:2022: A.5.15, A.8.3, A.8.5
• SOC 2: CC6.1, CC6.2

IM-4: Uwierzytelnianie serwera i usług

Azure Policy: Zobacz Wbudowane definicje zasad platformy Azure: IM-4.

Zasada zabezpieczeń

Uwierzytelniaj zdalne serwery i usługi po stronie klienta, aby upewnić się, że łączysz się z zaufanym serwerem i usługą. Najczęściej używanym protokołem uwierzytelniania serwera jest Transport Layer Security (TLS), gdzie po stronie klienta (często przeglądarka lub urządzenie klienckie) sprawdza serwer, sprawdzając certyfikat serwera wystawiony przez zaufany urząd certyfikacji.

Uwaga: wzajemne uwierzytelnianie może być używane, gdy zarówno serwer, jak i klient uwierzytelniają się nawzajem.

Ryzyko w celu ograniczenia ryzyka

• Nieautoryzowany dostęp: osoby atakujące wykorzystują brakujące lub wadliwe uwierzytelnianie w celu personifikacji usług lub klientów, uzyskiwania dostępu do interfejsów API, magazynu lub zasobów obliczeniowych. Umożliwia to eksfiltrację danych, wstrzyknięcie ładunku lub przejęcie systemu. Na przykład, żądanie między usługami bez uwierzytelnienia może wyodrębnić poufne dane z Azure Storage, podczas gdy klient pomijający walidację może bezpośrednio manipulować interfejsami API backendu.
• Kradzież poświadczeń lub wyciek: zakodowane lub ujawnione poświadczenia (np. wpisy tajne klienta, tokeny) w kodzie, konfiguracjach lub dziennikach są zbierane przez osoby atakujące, udzielając trwałego dostępu do zasobów. Skradziony tajny klucz aplikacji AAD może umożliwiać bezterminową personifikację zaufanej aplikacji, zapewniając dostęp do wszystkich punktów końcowych o określonym zakresie aż do czasu odwołania. Słaba rotacja wpisów tajnych lub niezaszyfrowany magazyn wzmacnia ekspozycję.
• Ataki typu man-in-the-middle (MITM): przeciwnicy przechwytują niezabezpieczoną komunikację, kradną tokeny lub zmieniają żądania. Bez wzajemnego uwierzytelniania osoby atakujące mogą fałszować tożsamości, co narusza integralność danych. Na przykład niezaszyfrowane wywołanie usługi do usługi może spowodować wyciek JWTs, co umożliwia sfałszowanie żądań interfejsu API. Słabe szyfry TLS lub brak weryfikacji certyfikatu zwiększa podatność na zagrożenia.
• Eskalacja uprawnień: nadmiernie permisywne tożsamości lub nieprawidłowo skonfigurowane zakresy umożliwiają osobom atakującym dostęp do nieautoryzowanych zasobów lub wykonywanie uprzywilejowanych akcji. Jednostka usługi z nadmiernymi rolami RBAC (np. "Właściciel") może wdrożyć złośliwe zasoby, podczas gdy klient z szerokimi uprawnieniami użytkownika może zmienić krytyczne konfiguracje, eskalując z ograniczonej do pełnej kontroli.

MITRE ATT&CK

• Dostęp początkowy (TA0001): Osoby atakujące wykorzystują słabe uwierzytelnianie w przepływach typu usługa-usługa lub klient-usługa przy użyciu skradzionych poświadczeń klienta (T1078.004) lub wyłudzania informacji w przypadku tokenów użytkownika (T1566.002) do infiltracji środowisk. Na przykład nieprawidłowo skonfigurowana rejestracja aplikacji OAuth 2.0 umożliwia nieautoryzowany dostęp do interfejsu API (T1133) za pośrednictwem sfałszowanych tokenów, udzielając wpisu do magazynu lub zasobów obliczeniowych.
• Dostęp poświadczeń (TA0006): Przeciwnicy celują w ujawnione tajemnice klienta, certyfikaty lub JWT w repozytoriach kodu, dziennikach lub niezabezpieczonych repozytoriach (T1552.001). Techniki obejmują pozyskiwanie poświadczeń głównego użytkownika usług z potoków CI/CD (T1552.004) lub przechwytywanie tokenów odświeżania podczas uwierzytelniania klienta (T1539), w celu umożliwienia trwałego dostępu do chronionych interfejsów API.
• Kolekcja (TA0009): Osoby atakujące zbierają artefakty uwierzytelniania, takie jak tokeny dostępu lub dane sesji z naruszonych zasobów (T1213.002). Obejmuje to wyodrębnianie zakodowanych na stałe sekretów z konfiguracji aplikacji (T1552.001) lub przechwytywanie tokenów w trakcie ich przesyłania przez atak typu MITM na niezabezpieczonych połączeniach między usługami (T1040), co napędza dalsze ataki.
• Eskalacja uprawnień (TA0004): Naruszone zasady lub konta użytkowników z nadmiernymi uprawnieniami opartymi na rolach są nadużywane w celu uzyskania wyższego poziomu dostępu (T1078.004). Osoby atakujące wykorzystują błędnie skonfigurowane uprawnienia aplikacji (T1548.004), aby zmodyfikować konfiguracje zasobów lub przypisać role administratora, eskalując kontrolę nad systemami lub dzierżawami.
• Uchylanie się od obrony (TA0005): Atakujący fałszują skradzione tokeny (T1606.002), aby naśladować legalny ruch lub manipulować roszczeniami w celu obejścia walidacji API (T1036.008). Wyłączenie rejestrowania inspekcji (T1562.001) lub używanie tożsamości zarządzanych w celu połączenia z normalnymi operacjami (T1078) pomaga uniknąć wykrywania przez systemy monitorowania.

IM-4.1: Uwierzytelnianie serwera i usług

Uwierzytelnianie serwera i usługi ustanawia relacje zaufania między składnikami rozproszonymi, zapobiegając atakom typu man-in-the-middle i zagrożeniom personifikacji usługi. Protokół Transport Layer Security (TLS) zapewnia standardowy mechanizm uwierzytelniania serwera, w którym klienci weryfikują certyfikaty serwera wystawione przez zaufane urzędy certyfikacji przed ustanowieniem bezpiecznej komunikacji. Organizacje wymuszające uwierzytelnianie TLS we wszystkich usługach chronią dane podczas przesyłania, zapobiegają przechwytywaniu poświadczeń i utrzymują bezpieczne interakcje między usługami niezbędne dla architektur bez zaufania.

Zaimplementuj uwierzytelnianie serwera i usługi za pomocą następujących rozwiązań:

• Włącz uwierzytelnianie TLS dla wszystkich usług: Wiele usług platformy Azure domyślnie obsługuje uwierzytelnianie TLS. W przypadku usług, które domyślnie nie obsługują uwierzytelniania TLS lub obsługują wyłączanie protokołu TLS, upewnij się, że jest ona zawsze włączona do obsługi uwierzytelniania serwera/klienta.

• Sprawdź zaufanie do certyfikatów w aplikacjach klienckich: Aplikacja kliencka powinna zostać zaprojektowana tak, aby zweryfikować tożsamość serwera/klienta, sprawdzając, czy certyfikat serwera został wystawiony przez zaufany urząd certyfikacji podczas etapu uzgadniania.

• W razie potrzeby zaimplementuj wzajemne protokoły TLS: Usługi takie jak API Management i API Gateway obsługują wzajemne uwierzytelnianie TLS w celu zapewnienia zwiększonych zabezpieczeń, gdy zarówno serwer, jak i klient uwierzytelniają się nawzajem.

Przykład implementacji

Scenariusz: Firma zajmująca się przetwarzaniem płatności musi zabezpieczyć komunikację interfejsu API między aplikacjami mobilnymi, usługami zaplecza i bramami płatności w celu spełnienia PCI-DSS zgodności. Muszą zapobiegać atakom typu „człowiek w środku” poprzez wzajemne uwierzytelnianie.

Kroki implementacji:

1. Wymuś protokół TLS 1.2 lub nowszy dla wszystkich usług:

   • Konfigurowanie minimalnej wersji protokołu TLS (1.2 lub nowszej) we wszystkich usługach Azure App Services i API Management
   • Wdrażanie zaufanych certyfikatów SSL/TLS z firmy DigiCert dla wszystkich domen niestandardowych
   • Włączanie trybu tylko HTTPS w celu przekierowywania żądań HTTP
   • Konfigurowanie usługi Azure SQL Database przy użyciu wartości "Encrypt=True" i "TrustServerCertificate=False"

2. Zaimplementuj wzajemne protokoły TLS (mTLS) dla krytycznych interfejsów API:

   • Włączanie uwierzytelniania certyfikatu klienta w konfiguracji usługi App Service
   • Przekazywanie zaufanego urzędu certyfikacji certyfikatu klienta do usługi App Service
   • Konfigurowanie usługi API Management w celu weryfikowania certyfikatów klienta (odcisk palca, wygaśnięcie, wystawca)
   • Wystawianie unikatowych certyfikatów klienta dla każdej wersji partnera/aplikacji mobilnej
   • Przechowywanie certyfikatów w usłudze Azure Key Vault z odpowiednimi mechanizmami kontroli dostępu

3. Zarządzanie cyklem życia certyfikatów:

   • Włączanie automatycznego obracania certyfikatów dla certyfikatów zarządzanych przez platformę Azure
   • Konfigurowanie alertów dotyczących certyfikatów wygasających w ciągu 60 dni
   • Implementowanie sprawdzania stanu certyfikatu online (OCSP)
   • Konfigurowanie testów odwoływania certyfikatów kwartalnych

4. Weryfikacja certyfikatu aplikacji klienckiej:

   • Implementowanie przypinania certyfikatów dla aplikacji bankowości mobilnej (iOS/Android)
   • Weryfikowanie łańcucha certyfikatów serwera w kodzie aplikacji
   • Przechowywanie certyfikatów klienta w bezpiecznej enklawie urządzenia/pęku kluczy

Wyniki:

Organizacja osiągnęła pełne szyfrowanie całej komunikacji interfejsu API, korzystając z nowoczesnych standardów TLS, a wzajemne uwierzytelnianie TLS zostało zaimplementowane dla punktów końcowych API o wysokiej wartości, które wymagają zwiększonych zabezpieczeń. Ataki typu man-in-the-middle zostały całkowicie wyeliminowane po wdrożeniu, podczas gdy problemy z zarządzaniem certyfikatami powodujące awarie usług zostały rozwiązane przez automatyzację. Pełna zgodność PCI-DSS została osiągnięta we wszystkich wymaganiach, a automatyczne zarządzanie cyklem życia certyfikatów zapewnia ciągłe bezpieczeństwo bez nakładu pracy.

Reference:

• Konfigurowanie wzajemnego uwierzytelniania TLS w usłudze Azure App Service

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: IA-9, SC-8, SC-13, SC-23
• PCI-DSS 4: 4.2.1, 6.2.4, 8.2.1
• Kontrolki CIS w wersji 8.1: 3.10, 9.2, 13.3
• NIST CSF v2.0: PR.DS-2, PR.DS-5
• ISO 27001:2022: A.5.14, A.8.24
• SOC 2: CC6.6, CC6.7

IM-5: Używanie logowania jednokrotnego na potrzeby dostępu do aplikacji

Zasada zabezpieczeń

Zaimplementuj logowanie jednokrotne (SSO), aby usprawnić uwierzytelnianie użytkowników w usługach w chmurze, aplikacjach SaaS i środowiskach lokalnych, zwiększając środowisko użytkownika i zabezpieczenia. SSO umożliwia użytkownikom logowanie jednokrotne za pośrednictwem zaufanego dostawcy tożsamości oraz uzyskiwanie dostępu do wszystkich autoryzowanych zasobów bez konieczności powtarzających się logowań. Zmniejsza to zmęczenie hasłami, minimalizuje rozrastanie poświadczeń i redukuje ryzyko, takie jak phishing, ataki typu brute-force i ujawnione poświadczenia, poprzez wymuszanie scentralizowanego uwierzytelniania wieloskładnikowego, spójnych protokołów TLS oraz ujednoliconego monitorowania, co zapewnia bezpieczne i wydajne zarządzanie dostępem.

Ryzyko w celu ograniczenia ryzyka

• Ujawnienie poświadczeń specyficznych dla aplikacji w kodzie lub konfiguracjach: poświadczenia w postaci zwykłego tekstu (np. klucze interfejsu API, hasła) osadzone w kodzie źródłowym lub plikach konfiguracji (np. .env, JSON) są ujawniane za pośrednictwem nieprawidłowo skonfigurowanych repozytoriów lub potoków ciągłej integracji i ciągłego wdrażania, umożliwiając przeciwnikom uwierzytelnianie do usług w chmurze lub lokalnych za pośrednictwem endpointów API.
• Kradzież poświadczeń za pośrednictwem wyłudzania informacji w wielu interfejsach logowania: przeciwnicy przechwytują poświadczenia za pomocą wyłudzania informacji (np. fałszywych stron logowania specyficznych dla aplikacji) lub przechwytują niezaszyfrowany ruch do różnych punktów końcowych logowania, wykorzystując niespójne konfiguracje protokołu TLS w celu uzyskania poświadczeń dla wielu systemów.
• Nieautoryzowany dostęp z użyciem słabych lub ponownie wykorzystanych poświadczeń: Poświadczenia o niskiej entropii lub ponownie użyte poświadczenia w różnych aplikacjach są narażone na ataki brute-force (np. próby logowania przy użyciu rozpylenia haseł poprzez interfejsy API logowania aplikacji) lub wypychanie poświadczeń, co umożliwia dostęp do usług w chmurze, SaaS lub zasobów lokalnych.
• Trwały dostęp za pośrednictwem nieśledzonych kont aplikacji: przeciwnicy wykorzystują niezarządzane konta w poszczególnych bazach danych aplikacji, osadzając poświadczenia w konfiguracjach w celu utrzymania dostępu za pomocą powtarzanego uwierzytelniania w systemach silosowych bez scentralizowanego odwoływania.
• Unikanie wykrycia poprzez niemonitorowane użycie poświadczeń: przeciwnicy używają skradzionych poświadczeń, aby naśladować legalny ruch w nieskoordynowanych systemach, unikając wykrycia z powodu rozdrobnionego rejestrowania audytów lub braku scentralizowanej telemetrii, opóźniając identyfikację nieautoryzowanego dostępu.

MITRE ATT&CK

• Dostęp do poświadczeń (TA0006) — Wyłudzanie informacji: Spearphishing z użyciem linku (T1566.001): Fałszywe strony logowania naśladują punkty końcowe aplikacji w celu przechwytywania poświadczeń, wykorzystując niespójność protokołów TLS w systemach bez logowania jednokrotnego.
• Dostęp do poświadczeń (TA0006) — Niezabezpieczone poświadczenia: Poświadczenia w plikach (T1552.001): Niezaszyfrowane klucze API lub hasła w nieprawidłowo skonfigurowanych repozytoriach Git lub artefaktach CI/CD są wyodrębniane.
• Dostęp początkowy (TA0001) — prawidłowe konta (T1078): skradzione poświadczenia uwierzytelniają się w aplikacjach platformy Azure, SaaS lub lokalnych, pomijając uwierzytelnianie wieloskładnikowe w konfiguracjach innych niż logowanie jednokrotne.
• Trwałość (TA0003) — manipulowanie kontem (T1098): niezarządzane konta aplikacji lub poświadczenia osadzone zapewniają powtarzany dostęp bez odwołania.
• Defense Evasion (TA0005) — Masquerading (T1036): Skradzione poświadczenia naśladują prawidłowy ruch interfejsu API, aby uniknąć wykrycia w systemach zamkniętych.

IM-5.1: Używanie logowania jednokrotnego na potrzeby dostępu do aplikacji

Logowanie jednokrotne eliminuje zmęczenie wynikające z konieczności zapamiętywania haseł oraz nadmiar poświadczeń, umożliwiając użytkownikom jednorazowe uwierzytelnianie i uzyskiwanie dostępu do wszystkich autoryzowanych zasobów bez konieczności powtarzających się logowań. Logowanie jednokrotne za pośrednictwem scentralizowanego dostawcy tożsamości wymusza spójne zasady zabezpieczeń, w tym uwierzytelnianie wieloskładnikowe, dostęp warunkowy i ujednolicone rejestrowanie inspekcji we wszystkich aplikacjach. Organizacje wdrażające jednokrotne logowanie (SSO) zmniejszają podatność na phishing, upraszczają doświadczenie użytkownika i utrzymują kompleksowy wgląd we wzorce dostępu, obsługując jednocześnie różnorodne grupy użytkowników, w tym pracowników, partnerów i klientów.

Zaimplementuj logowanie jednokrotne w całym środowisku przy użyciu następującego podejścia:

• Planowanie implementacji logowania jednokrotnego: Identyfikowanie aplikacji (chmury, środowiska lokalnego, klienta) i zasobów platformy Azure wymagających logowania jednokrotnego. Kategoryzuj użytkowników jako przedsiębiorstwa (pracowników), zewnętrznych zaufanych (partnerów) lub publicznych (klientów). Zdecyduj protokoły (np. OpenID Connect, SAML 2.0, OAuth 2.0) na podstawie zgodności aplikacji.

• Konfigurowanie logowania jednokrotnego w usłudze Microsoft Entra ID: Skorzystaj z Microsoft Entra ID, aby usprawnić dostęp do aplikacji obsługujących klientów za pośrednictwem logowania jednokrotnego (SSO), eliminując potrzebę duplikowania kont użytkowników. Zarejestruj aplikacje w module Rejestracji aplikacji Entra i skonfiguruj ustawienia logowania jednokrotnego przy użyciu metadanych SAML lub identyfikatorów klienta OIDC/wpisów tajnych zgodnie z potrzebami. Przypisz role RBAC platformy Azure (np. Współtwórca) na potrzeby dostępu do warstwy zarządzania.

• Włącz logowanie jednokrotne dla użytkowników przedsiębiorstwa: Zsynchronizuj lokalną usługę Active Directory z identyfikatorem Entra ID przy użyciu aplikacji Entra Connect, umożliwiając bezproblemowe logowanie jednokrotne przy użyciu poświadczeń firmowych.

• Konfiguracja SSO dla partnerów zewnętrznych: Konfiguracja tożsamości zewnętrznych dla partnerów obsługujących SSO za pośrednictwem dostawców tożsamości lub Microsoft Entra Verified ID, służącego do weryfikacji poświadczeń zdecentralizowanych.

• Implementacja logowania jednokrotnego (SSO) dla użytkowników publicznych: Korzystaj z Entra ID B2C w aplikacjach skierowanych do klienta, konfigurując przepływy użytkowników na potrzeby SSO z użyciem zewnętrznych tożsamości użytkowników (np. tożsamości z sieci społecznościowych).

• Bezpieczny dostęp za pomocą dostępu warunkowego: Utwórz zasady dostępu warunkowego, aby wymusić uwierzytelnianie wieloskładnikowe, zgodność urządzeń lub reguły oparte na lokalizacji. Wymusz uwierzytelnianie wieloskładnikowe dla użytkowników wysokiego ryzyka i używaj Zarządzania Entra ID w celu zautomatyzowania prowizji/deprowizji dostępu (np. pakietów dostępu dla wykonawców).

Przykład implementacji

Scenariusz: Globalna firma produkcyjna z 12 000 pracownikami, 500 partnerami i 50 000 klientów musi skonsolidować uwierzytelnianie w 75 aplikacjach, wyeliminować zmęczenie hasłami i zmniejszyć liczbę biletów pomocy technicznej przy jednoczesnym zwiększeniu bezpieczeństwa.

Kroki implementacji:

1. Konfigurowanie logowania jednokrotnego SAML dla aplikacji dla przedsiębiorstw:

   • Spis 75 aplikacji: 45 aplikacji SaaS (Salesforce, ServiceNow), 20 aplikacji lokalnych, 10 niestandardowych aplikacji platformy Azure
   • Konfigurowanie integracji protokołu SAML 2.0 dla usługi Salesforce (mapowanie atrybutów identyfikatora Entra, włączanie aprowizacji JIT)
   • Konfigurowanie programu OpenID Connect dla niestandardowych aplikacji internetowych platformy Azure przy użyciu zestawu Microsoft.Identity.Web SDK
   • Wdróż serwer proxy aplikacji Azure AD dla 20 lokalnych starszych aplikacji przy użyciu ograniczonego delegowania protokołu Kerberos

2. Konfigurowanie tożsamości zewnętrznych dla partnerów (B2B):

   • Zapraszanie 500 użytkowników partnerów za pośrednictwem funkcji współpracy B2B na potrzeby narzędzi do zarządzania projektami
   • Włączanie federacyjnego logowania jednokrotnego dla partnerów w celu używania własnych poświadczeń organizacyjnych
   • Implementowanie pakietów dostępu z dostępem do projektu na czas określony (automatycznym wygaśnięciem)
   • Ustanawianie zaufania między dzierżawami z 5 głównymi partnerami przy użyciu ustawień dostępu między dzierżawami

3. Wdrażanie usługi Azure AD B2C dla klientów:

   • Konfigurowanie instancji B2C dla 50 000 klientów korzystających z portali wsparcia
   • Konfigurowanie dostawców tożsamości społecznościowych (Microsoft, Google, Facebook)
   • Ochrona interfejsów API klientów za pomocą OAuth 2.0 i tokenów wystawionych przez B2C
   • Strony uwierzytelniania marki z logo firmy

4. Implementowanie dostępu warunkowego i zarządzania:

   • Konfigurowanie zasad opartych na ryzyku (użytkownicy wysokiego ryzyka wymagają zmiany hasła i uwierzytelniania wieloskładnikowego, blokuj starsze uwierzytelnianie)
   • Włączanie aprowizacji użytkowników opartej na protokole SCIM dla usług Salesforce, ServiceNow, Workday
   • Zaimplementowanie cyklu życia opartego na HR: automatyczne prowizjonowanie w ciągu 4 godzin, automatyczne unieważnianie w ciągu 1 godziny
   • Ustanawianie kwartalnych przeglądów dostępu dla partnerów i rocznej certyfikacji dla poufnych aplikacji

Wyniki:

Organizacja pomyślnie włączyła logowanie jednokrotne w dużym portfolio aplikacji obsługującym pracowników, partnerów i klientów, co znacznie poprawia bezpieczeństwo i środowisko użytkownika. Znacznie zmniejszyła się liczba zgłoszeń dotyczących resetowania haseł, podczas gdy użytkownicy uzyskali znaczny wzrost wydajności dzięki wyeliminowaniu powtarzających się żądań logowania. Podatność na wyłudzanie informacji gwałtownie spadła z powodu mniejszej liczby punktów ujawnienia danych uwierzytelniających. Czas dołączania partnerów znacznie zmniejszył się dzięki automatycznym pakietom dostępu, a zadowolenie klientów zwiększyło się szczególnie dzięki bezproblemowej integracji logowania społecznościowego. Co najważniejsze, zdarzenia zabezpieczeń związane ze słabymi hasłami zostały całkowicie wyeliminowane.

Reference:

• Włączanie logowania jednokrotnego SAML dla aplikacji dla przedsiębiorstw — Microsoft Entra ID

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: IA-2, IA-4, IA-8, AC-2
• PCI-DSS 4: 8.2.1, 8.2.2, 8.3.1
• Kontrolki CIS w wersji 8.1: 6.3, 6.5, 12.5
• NIST CSF v2.0: PR.AA-1, PR.AC-1
• ISO 27001:2022: A.5.15, A.5.16
• SOC 2: CC6.1, CC6.2

IM-6: Używanie silnych kontrolek uwierzytelniania

Azure Policy: Zobacz Wbudowane definicje zasad platformy Azure: IM-6.

Zasada zabezpieczeń

Wymuszaj silne i odporne na wyłudzanie informacji mechanizmy uwierzytelniania (silne uwierzytelnianie bez hasła lub uwierzytelnianie wieloskładnikowe) za pomocą scentralizowanego systemu zarządzania tożsamościami i uwierzytelnianiem w celu uzyskania dostępu do zasobów. Uwierzytelnianie oparte na samych poświadczeniach hasła jest uznawane za starsze, ponieważ jest niezabezpieczone i nie jest zgodne z popularnymi metodami ataku.

Podczas wdrażania silnego uwierzytelniania należy najpierw skonfigurować administratorów i uprzywilejowanych użytkowników, aby zapewnić najwyższy poziom metody silnego uwierzytelniania, a następnie szybko wdrożyć odpowiednie zasady silnego uwierzytelniania dla wszystkich użytkowników.

Uwaga: jeśli starsze uwierzytelnianie oparte na hasłach jest wymagane w przypadku starszych aplikacji i scenariuszy, należy upewnić się, że są przestrzegane najlepsze rozwiązania w zakresie zabezpieczeń haseł, takie jak wymagania dotyczące złożoności.

Ryzyko w celu ograniczenia ryzyka

• Naruszenie poświadczeń za pośrednictwem wyłudzania informacji lub przechwytywania: Atakujący przechwytują poświadczenia za pomocą wyłudzania informacji lub podsłuchu sieciowego, wykorzystując phishing OAuth lub przejęcie sesji do uzyskania dostępu do aplikacji i zasobów.
• Słabe lub ponownie użyte poświadczenia: Przewidywalne lub ponownie używane hasła umożliwiają ataki siłowe lub wypychanie poświadczeń z naruszonych baz danych.
• Ujawnienie poświadczeń w kodzie lub konfiguracjach: zakodowane poświadczenia w kodzie źródłowym lub plikach konfiguracji są ujawniane za pośrednictwem błędnych konfiguracji lub błędów wewnętrznych.
• Nieautoryzowany dostęp z naruszonych kont: Narzucone konta umożliwiają atakującym szeroki dostęp do aplikacji i zasobów z powodu niewystarczającego monitorowania zachowań.
• Proliferacja kont i opuszczone konta: zduplikowane lub porzucone konta (np. dla byłych pracowników) są wykorzystywane przez atakujących lub wykorzystywane w niewłaściwy sposób.
• Niespójne zasady zabezpieczeń w aplikacjach: różne mechanizmy kontroli zabezpieczeń (np. brak uwierzytelniania wieloskładnikowego) między aplikacjami tworzą luki w zabezpieczeniach umożliwiające wykorzystanie.
• Ataki typu man-in-the-middle (MitM): atakujący przechwytują sesje uwierzytelniania w celu kradzieży poświadczeń lub tokenów.
• Zagrożenia wewnętrzne z kont o nadmiernych uprawnieniach: nadmierne uprawnienia pozwalają na celowe lub przypadkowe niewłaściwe użycie przez pracowników lub partnerów.
• Inżynieria społeczna za pośrednictwem wielu punktów logowania: wiele interfejsów logowania rozszerza obszar ataków, aby skłonić użytkowników do ujawnienia poświadczeń.
• Nieautoryzowany dostęp zewnętrzny: źle zarządzane tożsamości zewnętrzne (np. partnerzy, klienci) uzyskują niezamierzony dostęp do poufnych systemów.

MITRE ATT&CK

• Dostęp do poświadczeń (TA0006): wyodrębnianie poświadczeń w postaci zwykłego tekstu (np. kluczy API, haseł) zakodowanych w kodzie źródłowym lub plikach konfiguracyjnych (np. .env, JSON) z nieprawidłowo skonfigurowanych repozytoriów lub potoków CI/CD, a następnie używanie uzyskanych poświadczeń do uwierzytelniania w interfejsach API usług w chmurze lub na miejscu.
• Dostęp początkowy (TA0001): przechwytywanie poświadczeń za pośrednictwem spear-phishing (np. fałszywych stron logowania specyficznych dla aplikacji, T1566.001) lub przechwytywanie niezaszyfrowanego ruchu do różnych punktów końcowych logowania, wykorzystując niespójne konfiguracje protokołu TLS w celu uzyskania poświadczeń dla wielu systemów.
• Dostęp początkowy (TA0001): wykorzystanie słabych lub ponownie użytych poświadczeń w niezwiązanych aplikacjach, wykorzystanie ataków siłowych (np. rozpylanie haseł za pośrednictwem interfejsów API logowania aplikacji, T1110.001) lub wypychanie poświadczeń w celu uzyskania nieautoryzowanego dostępu do usług w chmurze, SaaS lub zasobów lokalnych.
• Trwałość (TA0003): utrzymywanie dostępu przez wykorzystanie niezarządzanych kont w poszczególnych bazach danych aplikacji, osadzanie poświadczeń w konfiguracjach (T1098.001) w celu wielokrotnego uwierzytelniania w systemach silosowych bez scentralizowanego odwoływania.
• Ominięcie obrony (TA0005): używanie skradzionych poświadczeń do generowania żądań dla API lub aplikacji naśladujących uprawniony ruch w różnych systemach, unikanie wykrycia (T1036) z powodu rozproszonych logów audytowych lub braku centralnej telemetrii.

IM-6.1: Używanie kontrolek silnego uwierzytelniania

Silne uwierzytelnianie zapobiega atakom opartym na poświadczeniach, eliminując poleganie tylko na hasłach, które pozostają narażone na wyłudzanie informacji, siłę siłową i naruszenie baz danych. Nowoczesne metody uwierzytelniania, w tym opcje bez hasła (biometryczne, klucze zabezpieczeń, uwierzytelnianie oparte na certyfikatach) i uwierzytelnianie wieloskładnikowe znacznie zmniejszają ryzyko naruszenia zabezpieczeń kont, jednocześnie poprawiając środowisko użytkownika. Organizacje wdrażające silne uwierzytelnianie powinny najpierw określać priorytety administratorów i uprzywilejowanych użytkowników w celu ochrony kont o wysokiej wartości, a następnie systematycznie rozszerzać zasięg do wszystkich użytkowników przy zachowaniu obsługi starszych scenariuszy wymagających haseł za pomocą rozszerzonych zasad zabezpieczeń.

Zaimplementuj mechanizmy kontroli silnego uwierzytelniania przy użyciu następujących metod:

• Wdrażanie uwierzytelniania bez hasła: Użyj uwierzytelniania bez hasła jako domyślnej metody z czterema dostępnymi opcjami: Windows Hello dla firm, logowaniem telefonicznym aplikacji Microsoft Authenticator, kluczami dostępu (FIDO2) i uwierzytelnianiem opartym na certyfikatach. Identyfikator Entra firmy Microsoft obsługuje uwierzytelnianie bez hasła natywnie. Ponadto klienci mogą używać lokalnych metod uwierzytelniania, takich jak karty inteligentne.

• Wymuszanie uwierzytelniania wieloskładnikowego: Włącz usługę Azure MFA , która może być wymuszana dla wszystkich użytkowników, wybierać użytkowników lub na poziomie poszczególnych użytkowników na podstawie warunków logowania i czynników ryzyka. Postępuj zgodnie z zaleceniami dotyczącymi zarządzania tożsamościami i dostępem w usłudze Microsoft Defender for Cloud dla konfiguracji uwierzytelniania wieloskładnikowego.

• Zachowaj zabezpieczenia haseł dla starszych scenariuszy: Jeśli starsze uwierzytelnianie oparte na hasłach jest nadal używane do uwierzytelniania identyfikatora Entra firmy Microsoft, należy pamiętać, że konta tylko w chmurze (konta użytkowników utworzone bezpośrednio na platformie Azure) mają domyślne zasady haseł punktu odniesienia, a konta hybrydowe (konta użytkowników z lokalnej usługi Active Directory) są zgodne z lokalnymi zasadami haseł. W przypadku aplikacji i usług innych firm z domyślnymi identyfikatorami i hasłami wyłącz je lub zmień podczas początkowej konfiguracji usługi.

Przykład implementacji

Scenariusz: Firma technologiczna z 8000 pracownikami musi wyeliminować ataki oparte na hasłach i poprawić środowisko użytkownika dzięki wdrożeniu uwierzytelniania bez hasła odpornego na wyłudzanie informacji.

Kroki implementacji:

1. Włącz metody uwierzytelniania w identyfikatorze Entra firmy Microsoft:

   • Przejdź do centrum administracyjnego Microsoft Entra > Protection > Metody uwierzytelniania
   • Włącz funkcję Windows Hello dla firm dla wszystkich użytkowników (domyślne uwierzytelnianie urządzeń z systemem Windows 10/11)
   • Włącz klucze dostępu (FIDO2) z wymuszeniem zaświadczenia ustawionym na Tak (gwarantuje użycie tylko zweryfikowanych kluczy zabezpieczeń z usługi FIDO Alliance MDS)
   • Włącz klucze dostępu w aplikacji Microsoft Authenticator (wersja zapoznawcza) z wymuszaniem zaświadczeń.
   • Włącz uwierzytelnianie oparte na certyfikatach (CBA) i skonfiguruj zaufane urzędy certyfikacji
   • Konfiguracja rezerwowych metod uwierzytelniania wieloskładnikowego obejmuje: powiadomienia push Microsoft Authenticator i tokeny OATH; unikaj wiadomości SMS/głosu dla uprzywilejowanych użytkowników.

2. Definiowanie zasad siły uwierzytelniania:

   • Tworzenie niestandardowej siły uwierzytelniania "Administrator odporny na wyłudzanie informacji" wymagające: klucz zabezpieczeń FIDO2 LUB Windows Hello dla Firm LUB uwierzytelnianie zintegrowane z platformą LUB uwierzytelnianie oparte na certyfikatach (wieloskładnikowe)
   • Używanie wbudowanej siły uwierzytelniania wieloskładnikowego bez hasła dla użytkowników standardowych (w tym windows Hello, FIDO2, Authenticator passkeys, CBA)
   • Użyj wbudowanej "mocy uwierzytelniania wieloskładnikowego" jako alternatywę dla dostępu do starszych aplikacji

3. Wdrażanie uwierzytelniania odpornego na wyłudzanie informacji dla uprzywilejowanych użytkowników (150 administratorów):

   • Zakup kluczy zabezpieczeń FIDO2 z obsługą usb-A/C i NFC (Seria YubiKey 5) w celu zapewnienia zgodności międzyplatformowych
   • Rozpowszechnij klucze do wszystkich administratorów i przeprowadź ich przez rejestrację na stronie Microsoft Entra Security Info
   • Konfigurowanie usługi Windows Hello dla firm na 100 stacji roboczych z dostępem uprzywilejowanym systemu Windows przy użyciu modułu TPM 2.0 z wymaganiami dotyczącymi złożoności numeru PIN
   • Utwórz zasadę dostępu warunkowego przeznaczoną dla ról administratora (administrator globalny, administrator zabezpieczeń itp.): wymagaj odporności na phishing dla całego dostępu do Portalu Azure i aplikacji administracyjnych.
   • Wynik: 100% logowań administratora używa metod odpornych na wyłudzanie informacji opartych na sprzęcie, atestacja uniemożliwia rejestrację nieuprawnionych urządzeń.

4. Wdrażanie uwierzytelniania bez hasła dla użytkowników końcowych (7850 użytkowników):

   • Użytkownicy systemu Windows (6500): Wdrażanie funkcji Windows Hello dla firm za pośrednictwem usługi Intune przy użyciu modułu TPM 2.0 lub czujników biometrycznych (odcisk palca, rozpoznawanie twarzy)
   • Użytkownicy mobilni (1200): Włączanie kluczy dostępu w aplikacji Microsoft Authenticator (wersja zapoznawcza) dla systemu iOS/Android
     • iOS: klucze dostępu związane z urządzeniem przy użyciu bezpiecznej enklawy z funkcją FaceID/TouchID
     • Android: Klucze dostępu powiązane z urządzeniem, przy użyciu Secure Element lub Trusted Execution Environment (TEE) z biometrycznym uwierzytelnianiem
     • Włącz zaświadczanie za pomocą App Attest (iOS) i Play Integrity API (Android) w celu zweryfikowania autentycznej aplikacji Authenticator
   • Pilotaż z 500 wcześni użytkownikami z działów IT oraz finansów
   • Ustaw opcję Wymuszaj poświadczenie na wartość Tak, aby upewnić się, że zarejestrowane są tylko klucze dostępu powiązane z urządzeniem (blokowanie dostawców kluczy dostępu niezwiązanych z urządzeniem)
   • Tworzenie zasad dostępu warunkowego dla użytkowników standardowych: wymagaj uwierzytelniania o sile "MFA bez hasła" przy dostępie do aplikacji firmowych.
   • Przypadki brzegowe: użytkownicy bez urządzeń obsługujących biometrię otrzymują klucze zabezpieczeń FIDO2

5. Wdróż uwierzytelnianie oparte na certyfikatach (CBA) dla wyspecjalizowanych scenariuszy:

   • Konfigurowanie uwierzytelniania opartego na certyfikatach firmy Microsoft dla 100 zewnętrznych wykonawców wymagających integracji infrastruktury kluczy publicznych
   • Wystawianie certyfikatów X.509 z urzędu certyfikacji organizacji z 2-letnią ważnością
   • Konfigurowanie zasad powiązania uwierzytelniania CBA na potrzeby uwierzytelniania wieloskładnikowego: Wymagaj certyfikatuPolicyOid i powiązania nazwy użytkownika (silna uwierzytelnianie wieloskładnikowe)
   • Przechowuj certyfikaty w sprzętowych modułach zabezpieczeń (kartach inteligentnych) lub bezpiecznym magazynie urządzenia (TPM, bezpieczna enklawa)
   • Uwzględnij CBA w polityce uwierzytelniania o sile "odpornej na phishing dla administratorów" dla wykonawców z dostępem administracyjnym.

6. Skonfiguruj zasady dostępu warunkowego z siłą uwierzytelniania:

   • Polityka 1 — Ochrona Administratora: Skierowanie do wszystkich ról administratora → Wymagana siła „odporność na wyłudzanie informacji dla administratora” → Zastosuj do portalu Azure, centrów administracyjnych Microsoft 365
   • Zasady 2 — Użytkownicy standardowi: Obejmuje wszystkich użytkowników (z wyłączeniem administratorów) → Wymagać "siły MFA bez użycia hasła" → Stosuj do wszystkich aplikacji w chmurze
   • Zasady 3 — Starsze aplikacje: Starsze aplikacje nie mogą obsługiwać trybu bezhasłowego → wymagana jest "siła uwierzytelniania wieloskładnikowego" (zezwala na hasło + powiadomienie push z autentykatora/OTP)
   • Zasady 4 — dostęp zewnętrzny: Docelowi użytkownicy-goście/zewnętrzni → wymagaj minimalnej siły uwierzytelniania wieloskładnikowego
   • Monitorowanie analizy dostępu warunkowego pod kątem przestrzegania siły uwierzytelniania i skuteczności polityki

7. Obsługa starszych aplikacji i zabezpieczenia haseł (15 aplikacji):

   • Identyfikowanie aplikacji, które nie mogą obsługiwać nowoczesnego uwierzytelniania (graficzny interfejs użytkownika SAP, starsza sieć VPN wymagająca hasła)
   • W przypadku tych aplikacji wymagaj "mocy uwierzytelniania wieloskładnikowego" za pośrednictwem dostępu warunkowego (zezwalając na hasło + powiadomienie push aplikacji Authenticator/OTP)
   • Blokuj starsze protokoły uwierzytelniania (POP3, IMAP, SMTP AUTH) za pośrednictwem dostępu warunkowego dla platformy Microsoft 365
   • Włącz usługę Microsoft Entra Password Protection z niestandardową listą zakazanych haseł dla pozostałych użytkowników haseł
   • Planowanie ścieżki migracji dla starszych aplikacji w celu obsługi nowoczesnych protokołów uwierzytelniania (OAuth 2.0, SAML 2.0)

8. Mechanizmy eliminacji i odzyskiwania haseł:

   • Wymuszanie zasad dostępu warunkowego wymagających siły uwierzytelniania bez hasła dla nowoczesnych aplikacji
   • Wyłącz uwierzytelnianie haseł dla 95% użytkowników, którzy zarejestrowali poświadczenia bez hasła
   • Konfigurowanie Tymczasowy Kod Dostępu (TAP) na potrzeby odzyskiwania konta i początkowej rejestracji poświadczeń bez hasła
   • Zachowaj możliwość używania haseł dla 5% użytkowników wymagających dostępu do starszych aplikacji.

9. Monitorowanie i ciągłe ulepszanie:

   • Monitorowanie pulpitu nawigacyjnego metod uwierzytelniania w centrum administracyjnym firmy Microsoft Entra
   • Śledzenie metryk: Współczynnik wdrażania metod logowania bez hasła (Windows Hello: 81%, klucze dostępu Authenticator: 15%, FIDO2: 2%, CBA: 1%, logowanie jednokrotne na platformie: 1%)
   • Przeglądanie zgodności siły uwierzytelniania w szczegółowych informacji o dostępie warunkowym
   • Monitorowanie raportu logowań pod kątem używanych metod uwierzytelniania, ocen siły uwierzytelniania i zablokowanych prób uwierzytelniania w starszej wersji
   • Inspekcja błędów atestacji, aby zidentyfikować użytkowników próbujących zarejestrować niezgodne urządzenia
   • Podstawowy poziom: 15 alertów dotyczących naruszenia poświadczeń/miesiąc przed wdrożeniem bezhasłowym
   • Cel: <2 alerty/miesiąc po przejściu na bezhasłowy

Wyniki:

Organizacja osiągnęła kompleksowe wdrożenie bez hasła na wszystkich głównych platformach z metodami uwierzytelniania odpornymi na wyłudzanie informacji. Pełne pokrycie zostało osiągnięte w przypadku uprzywilejowanych kont przy użyciu poświadczeń opartych na sprzęcie (FIDO2, Windows Hello, SSO platformy, CBA), eliminując zagrożenia oparte na hasłach dla celów o wysokiej wartości. Wdrożenie uwierzytelniania bez hasła osiągnęło 95% wśród pracowników dzięki rozwiązaniom natywnym dla platformy (Windows Hello 81%, klucze dostępu Authenticatora 15%, FIDO2 2%, CBA 1%, SSO platformy 1%). Zdarzenia zabezpieczeń oparte na hasłach zostały całkowicie wyeliminowane, podczas gdy współczynnik niepowodzeń symulacji wyłudzania informacji zmniejszył się z 18% do <2% po wdrożeniu. Zgłoszenia do biura pomocy dotyczące resetowania hasła spadły o 87%, prowadząc do 340 000 USD rocznych oszczędności kosztów na wsparciu uwierzytelniania. Użytkownicy doświadczyli 40% szybszego uwierzytelniania przy użyciu metod biometrycznych, co zwiększyło produktywność dzięki usprawnionemu dostępowi. Zasady siły uwierzytelniania zapewniały szczegółowe wymuszanie, zapobiegając atakom polegającym na obniżeniu poziomu metod uwierzytelniania i zachowaniu spójnych wymagań odpornych na wyłudzanie informacji we wszystkich scenariuszach dostępu administratora.

Reference:

• Włączanie kluczy dostępu w aplikacji Microsoft Authenticator (wersja zapoznawcza)
• Uwierzytelnianie oparte na certyfikatach firmy Microsoft
• Siła uwierzytelniania w dostępie warunkowym

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: AC-2, AC-3, IA-2, IA-5, IA-8, IA-11
• PCI-DSS 4: 7.2.1, 8.2.1, 8.3.1, 8.3.2, 8.4.2
• Kontrolki CIS w wersji 8.1: 6.3, 6.4, 6.5
• NIST CSF v2.0: PR.AA-1, PR.AC-1
• ISO 27001:2022: A.5.15, A.5.17, A.5.18
• SOC 2: CC6.1, CC6.2

IM-7: Ograniczanie dostępu do zasobów na podstawie warunków

Zasada zabezpieczeń

Jawnie zweryfikuj zaufane sygnały, aby zezwolić lub odmówić dostępu użytkowników do zasobów w ramach modelu dostępu bez zaufania. Sygnały do weryfikacji powinny obejmować silne uwierzytelnianie konta użytkownika, analizę behawioralną konta użytkownika, wiarygodność urządzenia, członkostwo użytkownika lub grupy, lokalizacje itd.

Ryzyko w celu ograniczenia ryzyka

• Eskalacja uprawnień z nadmiernie rozbudowanych uprawnień poświadczeń lub kont: Przeciwnicy wykorzystują udostępnione poświadczenia lub konta użytkowników z przesadnie szerokimi uprawnieniami (np. pełnym dostępem administracyjnym) do wykonywania operacji API w chmurze wymagających wysokich uprawnień, takich jak tworzenie zasobów, usuwanie lub modyfikowanie zasad, poprzez żądania HTTP do punktów końcowych zarządzania (np. interfejsów API REST).
• Nieautoryzowany dostęp za pośrednictwem skradzionych poświadczeń Broad-Scope: Osoby atakujące używają skradzionych poświadczeń z źle zarządzanych systemów dostępu, uzyskiwanych za pośrednictwem spearphishing lub błędnie skonfigurowanych punktów końcowych publicznych w celu uwierzytelniania w usługach w chmurze za pośrednictwem kluczy interfejsu API lub haseł, które nie mają szczegółowych ograniczeń specyficznych dla zasobów.
• Trwały dostęp za pośrednictwem niezarządzanych lub nadmiernych kont: przeciwnicy tworzą lub modyfikują niezarządzane konta z szerokimi uprawnieniami, osadzając poświadczenia statyczne w konfiguracjach chmury (np. szablony IaC), aby zachować trwały dostęp za pośrednictwem powtarzających się uwierzytelnień interfejsu API bez scentralizowanego odwoływania uprawnień.
• Unikanie wykrywania poprzez użycie poświadczeń o szerokim zakresie: Atakerzy wykorzystują poświadczenia o szerokim zakresie do generowania żądań interfejsu API, które naśladują legalny ruch w chmurze, unikając wykrywania z powodu braku śladów inspekcji specyficznych dla ról lub szczegółowego monitorowania w niedokładnych systemach kontroli dostępu.
• Nieautoryzowane dane lub zbieranie poświadczeń z nadmiernie dostępnych zasobów: przeciwnicy wyodrębniają poufne dane lub poświadczenia (np. klucze interfejsu API, dane użytkownika) z zasobów w chmurze, takich jak zasobniki magazynu lub maszyny wirtualne, wykorzystując permissywne mechanizmy kontroli dostępu, które umożliwiają nieograniczone zapytania interfejsu API lub dostęp do plików z powodu braku granic opartych na rolach.

MITRE ATT&CK

• Eskalacja uprawnień (TA0004): wykorzystanie nadmiernie uprzywilejowanych poświadczeń udostępnionych lub kont użytkowników z szerokimi zakresami dostępu, nadużywanie mechanizmów kontroli dostępu w celu wywoływania operacji interfejsu API w chmurze o wysokich uprawnieniach (np. tworzenia zasobów, modyfikacji zasad) między usługami.
• Dostęp początkowy (TA0001): wykorzystanie skradzionych poświadczeń z nieprecyzyjnie zarządzanych systemów dostępu, używając celowanych ataków phishingowych (spear-phishing) lub błędnie skonfigurowanych publicznych punktów końcowych do uwierzytelniania za pośrednictwem kluczy interfejsu API lub haseł bez określonych restrykcji.
• Trwałość (TA0003): utrzymywanie dostępu przez tworzenie lub modyfikowanie niezarządzanych kont z nadmiernymi uprawnieniami, osadzanie poświadczeń w konfiguracjach chmury w celu wielokrotnego uwierzytelniania bez odwoływania opartego na rolach.
• Omijanie mechanizmów obrony (TA0005): używanie szeroko określonych poświadczeń do naśladowania legitymującego ruchu API w chmurze (T1036), unikanie wykrycia z powodu braku logów audytowych specyficznych dla roli lub monitorowania, pomijając ogólne mechanizmy logowania dostępu.
• Kolekcja (TA0009): zbieranie poufnych danych lub poświadczeń z zasobów w chmurze z nadmiernym dostępem do wyodrębniania kluczy interfejsu API lub danych użytkownika z magazynu lub wystąpień z powodu braku granic dostępu opartego na rolach.

IM-7.1: Ograniczanie dostępu do zasobów na podstawie warunków

Zasady dostępu warunkowego umożliwiają bezpieczeństwo zgodne z zero trust, dynamicznie oceniając wiele sygnałów przed udzieleniem dostępu do zasobów, co pozwala przejść od statycznych uprawnień do kontekstowej kontroli dostępu. Organizacje implementują dostęp warunkowy, aby wymusić adaptacyjne wymagania zabezpieczeń, takie jak wymaganie uwierzytelniania wieloskładnikowego na potrzeby akcji administracyjnych, blokowanie starszych protokołów uwierzytelniania lub wymuszanie zgodnych urządzeń dla poufnych aplikacji. Te zasady zapewniają szczegółową kontrolę nad sesjami uwierzytelniania, równoważąc wymagania dotyczące zabezpieczeń z produktywnością użytkowników, zapewniając odpowiednie poziomy ochrony na podstawie oceny ryzyka w czasie rzeczywistym.

Zaimplementuj mechanizmy kontroli dostępu warunkowego przy użyciu następującego podejścia:

• Wdróż dostęp warunkowy firmy Microsoft Entra: Użyj dostępu warunkowego firmy Microsoft Entra w celu uzyskania szczegółowych kontroli dostępu na podstawie warunków zdefiniowanych przez użytkownika, takich jak wymaganie logowania użytkownika z określonych zakresów adresów IP (lub urządzeń) do korzystania z uwierzytelniania wieloskładnikowego. Dostęp warunkowy firmy Microsoft Entra umożliwia wymuszanie kontroli dostępu w aplikacjach organizacji na podstawie określonych warunków.

• Zdefiniuj odpowiednie warunki i kryteria: Podczas definiowania odpowiednich warunków i kryteriów dostępu warunkowego Microsoft Entra w Twojej pracy należy wziąć pod uwagę następujące typowe przypadki użycia:

• Wymagaj uwierzytelniania wieloskładnikowego dla ról administracyjnych: Wymagaj uwierzytelniania wieloskładnikowego dla użytkowników z rolami administracyjnymi.

• Wymagaj uwierzytelniania wieloskładnikowego dla zadań zarządzania: Wymagaj uwierzytelniania wieloskładnikowego dla zadań zarządzania platformy Azure.

• Blokuj starsze protokoły uwierzytelniania: Blokuj logowania użytkowników próbujących używać starszych protokołów uwierzytelniania.

• Wymuszaj zaufane lokalizacje: Wymagaj zaufanych lokalizacji na potrzeby rejestracji uwierzytelniania wieloskładnikowego i blokuj lub udzielaj dostępu z określonych lokalizacji.

• Blokuj ryzykowne zachowania logowania: Blokuj ryzykowne zachowania logowania.

• Wymagaj urządzeń zarządzanych: Wymagaj urządzeń zarządzanych przez organizację dla określonych aplikacji.

• Implementacja funkcji zarządzania sesjami: Szczegółowe funkcje zarządzania sesjami uwierzytelniania można również zaimplementować za pomocą polityki Microsoft Entra Conditional Access, takich jak częstotliwość logowania i ciągła sesja przeglądarki.

Przykład implementacji

Scenariusz: Organizacja opieki zdrowotnej z 3500 pracownikami wymaga kontroli dostępu bez zaufania dla 150 zasobów platformy Azure i 45 aplikacji przy jednoczesnym zapewnieniu zgodności z przepisami HIPAA. Zrozumienie podstaw kontroli dostępu opartej na rolach (RBAC) jest niezbędne.

Kroki implementacji:

1. Ustanów podstawę kontroli dostępu opartej na rolach:

   • Definiowanie hierarchii ról: administrator globalny (3), administrator zabezpieczeń (8), administrator aplikacji (25), użytkownicy standardowi (3464)
   • Tworzenie niestandardowych ról platformy Azure dla scenariuszy opieki zdrowotnej (czytelnik danych PHI, administrator aplikacji klinicznej, recenzent inspekcji)
   • Przypisz role na odpowiednich poziomach (poziom subskrypcji dla infrastruktury, poziom grupy zasobów dla aplikacji)
   • Rejestrowanie 4200 urządzeń w usłudze Microsoft Intune na potrzeby śledzenia zgodności

2. Wdróż 8 zasad dostępu warunkowego:

   • Polityka 1 — Podstawowa zasada MFA: Wszyscy użytkownicy i wszystkie aplikacje chmurowe wymagają MFA (częstotliwość wymagań logowania: 8 godzin)
   • Zasady 2 — Ochrona ról uprzywilejowanych: Administratorzy wymagają uwierzytelniania wieloskładnikowego + zgodnego urządzenia i zatwierdzonej aplikacji klienckiej (sesje 4-godzinne)
   • Zasady 3 — Azure Management: Wymagaj uwierzytelniania wieloskładnikowego, zgodnego urządzenia i dołączenia do hybrydowej usługi Azure AD, aby uzyskać dostęp do portal.azure.com.
   • Zasady 4 — Blokowanie starszej autoryzacji: Blokuj POP3, IMAP, SMTP AUTH (15 tymczasowych wyjątków z 6-miesięcznym harmonogramem wycofywania)
   • Zasady 5 — zaufana lokalizacja: Wymagaj uwierzytelniania wieloskładnikowego dla dostępu do DPI z niezaufanych lokalizacji; blokowanie serwerów proxy Tor / anonimowych
   • Zasady 6 — Kontrola Oparta na Ryzyku: Wymagaj uwierzytelniania wieloskładnikowego oraz zmiany hasła dla ryzyka logowania o średnim/wysokim poziomie (integracja z Entra ID Protection)
   • Zasady 7 — Urządzenie zarządzane: Wymaganie zgodnych lub hybrydowych urządzeń przyłączonych do usługi Azure AD dla aplikacji SharePoint/Azure Web Apps
   • Polityka 8 — Sesje Specyficzne dla Aplikacji: 30-minutowe sesje dla systemów finansowych, blokowanie pobierania, kopiowania i wklejania dla CIH

3. Włącz ocenę dostępu ciągłego (CAE):

   • Natychmiastowe odwołanie tokenu po wyłączeniu użytkownika, zmianie hasła lub przeniesieniu do lokalizacji wysokiego ryzyka
   • Tokeny unieważnione w ciągu 15 minut w przypadku zdarzeń krytycznych

4. Monitorowanie i optymalizacja:

   • Przegląd szczegółowych informacji o dostępie warunkowym co tydzień (wpływ zasad, metryki środowiska użytkownika)
   • Zarządzanie 45 wyjątkami (kontami awaryjnymi, starszymi systemami) poprzez kwartalne przeglądy
   • Comiesięczne spotkania dotyczące przeglądu zasad z uczestnikami projektu

Wyniki:

Organizacja wdrożyła kompleksowe zasady dostępu warunkowego obejmujące wszystkich użytkowników z pełnym zastosowaniem uwierzytelniania wieloskładnikowego oraz wysokim poziomem adopcji urządzeń zarządzanych. Starsze uwierzytelnianie zostało zablokowane dla prawie wszystkich żądań, z nielicznymi wyjątkami wynikającymi z określonych potrzeb biznesowych. Wszystkie konta administratorów wymagają teraz uwierzytelniania wieloskładnikowego odpornego na wyłudzanie informacji połączonego ze zgodnymi urządzeniami. Nieautoryzowany dostęp do chronionych informacji o kondycji uległ znacznemu zmniejszeniu, a anomalie oparte na lokalizacji są teraz automatycznie blokowane, zapobiegając naruszeniom, które wcześniej wystąpiły. Wskaźnik zgodności HIPAA organizacji znacznie się poprawił, wykazując znaczną dojrzałość zabezpieczeń.

Reference:

• Przewodnik dla początkujących dotyczący kontroli dostępu opartej na rolach na platformie Azure

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: AC-2, AC-3, AC-6, AC-16
• PCI-DSS 4: 7.2.1, 7.2.2, 7.2.3
• Kontrolki CIS w wersji 8.1: 3.3, 6.4, 6.8, 13.5
• NIST CSF v2.0: PR.AC-1, PR.AC-4, PR.AA-1
• ISO 27001:2022: A.5.15, A.5.18, A.8.2, A.8.3
• SOC 2: CC6.1, CC6.3, CC6.6

IM-8: Ograniczanie ujawnienia poświadczeń i wpisów tajnych

Azure Policy: Zobacz Wbudowane definicje zasad platformy Azure: IM-8.

Zasada zabezpieczeń

Upewnij się, że deweloperzy aplikacji bezpiecznie obsługują poświadczenia i wpisy tajne:

• Unikaj osadzania poświadczeń i wpisów tajnych w kodzie i plikach konfiguracji
• Przechowywanie poświadczeń i wpisów tajnych przy użyciu magazynu kluczy lub bezpiecznego magazynu kluczy
• Skanuj pod kątem poświadczeń w kodzie źródłowym.

Uwaga: jest to często zarządzane i wymuszane za pośrednictwem bezpiecznego cyklu życia rozwoju oprogramowania (SDLC) i procesu bezpieczeństwa DevOps.

Ryzyko w celu ograniczenia ryzyka

• Nieautoryzowany dostęp: ujawnione poświadczenia (np. klucze interfejsu API, hasła) w postaci zwykłego tekstu, repozytoria kodu lub dzienniki mogą być wykorzystywane przez osoby atakujące w celu uzyskania dostępu do poufnych systemów lub danych. Na przykład ujawniony klucz jednostki usługi platformy Azure może umożliwić osobie atakującej dostęp do kont magazynu lub maszyn wirtualnych.
• Eskalacja uprawnień: naruszone wpisy tajne, takie jak tokeny konta usługi z nadmiernymi uprawnieniami, umożliwiają atakującym podniesienie poziomu dostępu w środowisku chmury, potencjalnie uzyskanie kontroli nad całą subskrypcją lub zasobami krytycznymi (np. użycie skradzionego wpisu tajnego usługi Key Vault w celu uzyskania dostępu do funkcji administracyjnych).
• Naruszenie danych: ujawnione parametry połączenia bazy danych lub klucze konta magazynu mogą prowadzić do nieautoryzowanego uzyskiwania zasobów danych, ujawniania poufnych informacji, takich jak rekordy klienta lub własność intelektualna, często poprzez publiczne błędne konfiguracje (np. otwarty kontener Blob platformy Azure).
• Przenoszenie boczne: Skradzione poświadczenia umożliwiają atakującym przemieszczanie się przez zasoby w chmurze, wykorzystując relacje zaufania lub udostępnione tajne dane, aby uzyskać dostęp do dodatkowych systemów, takich jak przechodzenie z naruszonego VM do klastra Kubernetes, wykorzystując ponownie użyty token.

MITRE ATT&CK

• Dostęp początkowy (TA0001): Wykorzystanie ujawnionych poświadczeń, takich jak klucze interfejsu API lub tokeny usługi głównej w repozytoriach publicznych lub nieprawidłowo skonfigurowanym magazynie, umożliwiające atakującym uzyskanie nieautoryzowanego dostępu do zasobów w chmurze (np. T1078 — ważne konta).
• Eskalacja uprawnień (TA0004): Wykorzystanie skradzionych, nadmiernie uprzywilejowanych tajemnic w celu podniesienia poziomu uprawnień, co umożliwia atakującym kontrolowanie dodatkowych zasobów lub subskrypcji (np. T1078 — ważne konta).
• Kolekcja (TA0009): Pozyskiwanie poufnych danych przez wykorzystanie ujawnionych ciągów połączenia baz danych lub kluczy magazynowania, co prowadzi do nieautoryzowanego dostępu do danych z zasobów chmurowych (np. T1530 — dane z magazynu w chmurze).
• Ruch poprzeczny (TA0008): Poruszanie się między zasobami w chmurze przy użyciu skompromitowanych poświadczeń, takich jak ponownie używane tokeny lub konta usługowe, aby uzyskać dostęp do połączonych systemów lub sieci wirtualnych (np. T1021 — Usługi zdalne).

IM-8.1 Wykrywanie wpisów tajnych i poświadczeń na żywo

Proaktywne wykrywanie wpisów tajnych uniemożliwia ujawnienie poświadczeń przez zidentyfikowanie wpisów tajnych na żywo osadzonych w kodzie źródłowym, plikach konfiguracji, narzędziach komunikacyjnych i zarchiwizowanych materiałach przed odnalezieniem ich przez osoby atakujące. Organizacje wdrażające ciągłe skanowanie sekretów w potokach programistycznych, wdrożeniach infrastruktury i systemach magazynowania wykrywają i korygują ujawnione poświadczenia, w tym klucze interfejsu API, ciągi połączenia i tokeny uwierzytelniania. Automatyczne wykrywanie zagrożeń zintegrowane z przepływami pracy CI/CD umożliwia szybką reakcję na wycieki poświadczeń, zmniejszając czas narażenia i uniemożliwiając nieautoryzowany dostęp do zasobów oraz usług w chmurze.

Zaimplementuj wykrywanie wpisów tajnych za pomocą następujących rozwiązań:

• Włącz skanowanie tajnych danych w Azure DevOps: Jeśli używasz Azure DevOps do zarządzania kodem, zaimplementuj Azure DevOps Credential Scanner, aby zidentyfikować poświadczenia w repozytoriach kodu.

• Włącz skanowanie wpisów tajnych usługi GitHub: W przypadku repozytoriów GitHub użyj natywnej funkcji skanowania wpisów tajnych , aby zidentyfikować poświadczenia lub inne formy wpisów tajnych w kodzie.

• Umożliwienie skanowania tajnych wpisów bez agenta: Włącz usługę Microsoft Defender for Cloud w celu skanowania tajnych wpisów bez agenta na maszynach wirtualnych, zasobach i instancjach multi-cloud w celu wykrywania tajnych wpisów, takich jak ciągi połączeń w plikach konfiguracji i repozytoriach kodu źródłowego.

IM-8.2 Ochrona tajemnic i poświadczeń

Zarządzanie bezpiecznymi tajemnicami chroni poświadczenia uwierzytelniania za pomocą scentralizowanych sejfów, automatycznej rotacji i kontroli dostępu uniemożliwiającej kradzież poświadczeń i nieautoryzowany dostęp do usługi. Usługa Azure Key Vault udostępnia magazyn danych tajnych klasy korporacyjnej z wbudowanymi funkcjami rotacji dla obsługiwanych usług, modułu sprzętowego zabezpieczeń (HSM) i kompleksowego rejestrowania inspekcji. Organizacje przechowujące tajemnice w usłudze Key Vault, dostępne za pośrednictwem tożsamości zarządzanych, eliminują trwale zakodowane poświadczenia, implementują zasady automatycznej rotacji i zachowują zgodność z ramami zabezpieczeń, jednocześnie umożliwiając bezpieczne uwierzytelnianie między usługami w środowiskach chmurowych i hybrydowych.

Ochrona tajemnic i poświadczeń przy użyciu następujących praktyk:

• Przechowywanie wpisów tajnych w usłudze Azure Key Vault: Jeśli tożsamość zarządzana nie jest opcją, upewnij się, że wpisy tajne i poświadczenia są przechowywane w bezpiecznych lokalizacjach, takich jak usługa Azure Key Vault, zamiast osadzać je w plikach kodu i konfiguracji.

• Wdrażanie automatycznej rotacji sekretów: Azure Key Vault zapewnia automatyczną rotację dla obsługiwanych usług. W przypadku wpisów tajnych, których nie można automatycznie obracać, upewnij się, że są one okresowo obracane i czyszczone, gdy nie są już używane.

• Uzyskiwanie dostępu do usługi Key Vault za pośrednictwem tożsamości zarządzanych: Klienci, tacy jak Azure Functions, usługi Azure Apps i maszyny wirtualne, mogą bezpiecznie uzyskiwać dostęp do usługi Azure Key Vault bez przechowywania dodatkowych poświadczeń.

Przykład implementacji

Scenariusz: Startup fintech z deweloperami w wielu zespołach doświadcza zdarzenia zabezpieczeń, gdy klucz interfejsu API zatwierdzony w publicznym repozytorium GitHub uwidacznia dane klientów, co skutkuje grzywnami prawnymi. Potrzebują kompleksowej identyfikacji i ochrony tajemnic w celu zapobieżenia wyciekom danych uwierzytelniających w przyszłości.

Faza 1: Wykrywanie danych poufnych — zapobieganie wyciekom poświadczeń (IM-8.1)

1. Zaimplementuj program CredScan w bezpiecznym cyklu życia aplikacji:

   • Integracja narzędzia CredScan z potokami Azure DevOps, aby skanować typowe wzorce sekretów.
   • Skonfiguruj potok, aby zakończył się niepowodzeniem, jeśli wykryte zostaną tajne dane o wysokim stopniu zagrożenia, co blokuje wdrożenia produkcyjne.
   • Wstępne skanowanie identyfikuje ujawnione wpisy tajne w repozytoriach (klucze magazynu, parametry połączenia SQL, klucze interfejsu API, wpisy tajne podpisywania JWT)

2. Skanowanie sekretów w GitHub Advanced Security:

   • Włączanie usługi GitHub Advanced Security dla wszystkich repozytoriów
   • Konfigurowanie natywnego skanowania tajnych danych do wykrywania typowych typów tokenów i wzorców niestandardowych
   • Włącz ochronę przesyłania, aby zablokować zatwierdzenia zawierające tajne dane przed zakończeniem przesyłania
   • Ustaw alerty, aby uruchamiać przepływ pracy reakcji na incydenty.

3. Skanowanie bez agenta w usłudze Microsoft Defender for Cloud:

   • Włączanie usługi Defender for Cloud dla maszyn wirtualnych platformy Azure, kont magazynu i rejestrów kontenerów
   • Skonfiguruj skanowanie tajnych danych bez użycia agenta pod kątem plików konfiguracji, obrazów kontenerów i magazynu obiektów blob
   • Konfigurowanie automatycznych alertów dla wpisów tajnych znalezionych na uruchomionych maszynach wirtualnych, kontach magazynu i obrazach kontenerów

4. Skanowanie repozytorium historycznego (korygowanie):

   • Używanie narzędzi takich jak Gitleaks lub TruffleHog w celu skanowania całej historii usługi Git pod kątem uwidocznionych wpisów tajnych
   • Identyfikowanie poświadczeń ujawnionych w zatwierdzeniach z biegiem czasu
   • Implementacja rozwiązań naprawczych: zmiana wszystkich zidentyfikowanych poświadczeń, usuwanie sekretnych informacji z historii Git, edukacja deweloperów

Faza 2: Ochrona tajemnic — scentralizowany skarbiec i wymiana (IM-8.2)

1. Wdrożenie usługi Azure Key Vault:

   • Tworzenie 3 magazynów kluczy według środowiska (produkcja, przemieszczanie, programowanie)
   • Migrowanie wpisów tajnych: parametry połączenia bazy danych, klucze interfejsu API innych firm, poświadczenia usługi platformy Azure, wpisy tajne protokołu OAuth, klucze szyfrowania
   • Aktualizowanie mikrousług w celu pobierania tajemnic przy użyciu zestawów Azure SDK (Azure.Security.KeyVault.Secrets dla platformy .NET, @azure/keyvault-secrets dla Node.js, azure-keyvault-secrets dla Python)
   • Usuń wszystkie zakodowane na stałe tajne dane z kodu, plików konfiguracyjnych i potoków CI/CD

2. Automatyczna rotacja wpisów tajnych:

   • Włącz automatyczną rotację kluczy Azure Storage, haseł SQL i sekretów jednostki usługi
   • Zaimplementować niestandardową rotację kluczy API stron trzecich i poświadczeń bazy danych
   • Konfiguracja kontroli dostępu opartej na rolach dla Key Vault z zasadą najmniejszych uprawnień dla aplikacji i operatorów
   • Włączanie rejestrowania inspekcji i alertów dla nietypowych wzorców dostępu

3. Przepływ pracy i reagowanie na zdarzenia dla deweloperów:

   • Aktualizacja szkoleń, udostępnianie szablonów kodu, wymuszanie wstępnych hooków do wykrywania danych poufnych.
   • Zastępowanie sekretów potoku odwołaniami do Key Vault, użycie zarządzanych tożsamości dla połączeń usług.
   • Definiowanie podręcznika reagowania na zdarzenia przy użyciu przejrzystych ścieżek eskalacji i procedur rotacji

4. Ciągłe monitorowanie:

   • Regularne rozrastanie wpisów tajnych w celu upewnienia się, że żadne wpisy tajne nie istnieją poza usługą Key Vault
   • Śledzenie pulpitu nawigacyjnego pod kątem wygaśnięcia wpisu tajnego i zgodności rotacji
   • Okresowe testy penetracyjne i inspekcje zabezpieczeń

Wyniki:

Organizacja pomyślnie zidentyfikowała i skorygowała wszystkie uwidocznione poświadczenia w bazie kodu i infrastrukturze. Wpisy tajne zapisane na stałe zostały całkowicie wyeliminowane z kodu produkcyjnego przez kompleksową migrację do Azure Key Vault. Zautomatyzowana rotacja wpisów tajnych znacznie zmniejszyła nakład pracy ręcznej i błąd człowieka, umożliwiając znacznie szybsze wykrywanie i reagowanie na potencjalne wycieki poświadczeń. Implementacja nie spowodowała żadnych incydentów bezpieczeństwa związanych z ujawnionymi poświadczeniami, zwiększyła produktywność deweloperów dzięki usprawnionym procesom zarządzania tajnymi danymi oraz zapewniła pełną zgodność z wymaganiami kontroli bezpieczeństwa, w tym standardami, takimi jak SOC 2 i PCI-DSS.

Reference:

• Bezpieczny cykl życia aplikacji — część 1 — używanie narzędzia CredScan
• Używanie Azure Key Vault do zarządzania tajemnicami
• Automatyzowanie rotacji tajemnic w usłudze Key Vault

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• NIST SP 800-53 Rev.5: IA-5, SI-4, RA-5, SC-12, SC-13, SC-28
• PCI-DSS 4: 3.5.1, 6.3.2, 8.2.1, 8.3.2
• Kontrolki CIS w wersji 8.1: 16.9, 16.10, 16.12
• NIST CSF v2.0: DE.CM-8, PR.DS-1, PR.AC-1
• ISO 27001:2022: A.5.15, A.8.3, A.8.24
• SOC 2: CC6.1, CC6.6, CC7.2