Ochrona danych

Ochrona danych chroni poufne informacje przed nieautoryzowanym dostępem, eksfiltracją i nieprawidłowym użyciem w całym cyklu życia danych. Zaimplementuj odnajdywanie i klasyfikację w celu ustanowienia spisu danych, szyfrowania w celu ochrony danych przesyłanych i magazynowanych oraz zdyscyplinowanego zarządzania kluczami i certyfikatami w celu zachowania integralności kryptograficznych. Takie podejście warstwowe jest zgodne z zasadami Zero Trust i strategiami dogłębnymi obrony.

Bez całościowej ochrony danych organizacje napotykają incydenty naruszenia, kary regulacyjne i uszczerbek na reputacji z powodu eksfiltracji poufnych informacji.

Poniżej przedstawiono trzy podstawowe filary domeny zabezpieczeń ochrony danych.

Poznaj i klasyfikuj dane: Odnajdywanie poufnych informacji i stosowanie spójnych etykiet w celu włączenia mechanizmów kontroli opartych na ryzyku.

Powiązane kontrolki:

• DP-1: Odnajdywanie, klasyfikowanie i etykietowanie poufnych danych
• DP-2: Monitorowanie anomalii i zagrożeń skierowanych na poufne dane

Ochrona danych za pomocą szyfrowania: Zaimplementuj kompleksowe szyfrowanie dla danych przesyłanych i magazynowanych przy użyciu nowoczesnych standardów kryptograficznych.

Powiązane kontrolki:

• DP-3: Szyfrowanie poufnych danych podczas przesyłania
• DP-4: Domyślnie włącz szyfrowanie danych magazynowanych
• DP-5: Użyj opcji klucza zarządzanego przez klienta w przypadku szyfrowania danych w spoczynku, jeśli jest to wymagane

Zarządzanie infrastrukturą kryptograficzną: Ustanów zdyscyplinowane zarządzania cyklem życia dla kluczy kryptograficznych i certyfikatów za pomocą zautomatyzowanej rotacji i kompleksowego logowania audytów.

Powiązane kontrolki:

• DP-6: Używanie bezpiecznego procesu zarządzania kluczami
• DP-7: Używanie bezpiecznego procesu zarządzania certyfikatami
• DP-8: Zapewnianie zabezpieczeń klucza i repozytorium certyfikatów

DP-1: Odnajdywanie, klasyfikowanie i etykietowanie poufnych danych

Azure Policy: Zobacz wbudowane definicje zasad Azure: DP-1.

Zasada zabezpieczeń

Utworzenie i utrzymanie kompleksowego spisu poufnych danych przez odnajdywanie, klasyfikowanie i etykietowanie danych we wszystkich repozytoriach. Umożliwia to kontrolę dostępu opartą na ryzyku, zasady szyfrowania i monitorowanie w celu ochrony przed nieautoryzowanym dostępem i eksfiltracją.

Ryzyko w celu ograniczenia ryzyka

Podmioty zagrożeń wykorzystują brak widoczności i niespójną obsługę poufnych danych w celu eksfiltracji lub nadużywania informacji o wysokiej wartości. Gdy dane poufne nie są odnajdywane, klasyfikowane lub oznaczone etykietami:

• Nieśledzone dane regulowane: (PCI, PHI, PII) przechowywane w niezarządzanych lokalizacjach (cichy IT) pomijają wymagane szyfrowanie, przechowywanie oraz monitorowanie.
• Dostęp nadmiernie uprzywilejowany: Rozległy dostęp użytkowników/usług jest utrzymywany, ponieważ nie zidentyfikowano kwestii poufności ani wpływu na biznes.
• Proliferacja repliki: Replikacja danych do analiz, testów lub eksportu potoków danych rozprzestrzenia poufną zawartość do środowisk o niższym zaufaniu.
• Luki w analizie kryminalistycznej: Osoby reagujące na zdarzenia nie mogą szybko określić zakresu incydentu z powodu braku lub niepoprawnych metadanych odnośnie wrażliwości danych.
• Niepowodzenie automatyzacji: Procesy zarządzania (DLP, dostęp warunkowy, przepływy pracy szyfrowania) nie są wyzwalane bez spójnego etykietowania.

Brak podstawowej klasyfikacji zwiększa czas przebywania, rozszerza możliwości ruchu bocznego i podnosi podatność na ryzyka regulacyjne oraz wizerunkowe.

MITRE ATT&CK

• Rekonesans (TA0043): zbieranie tożsamości ofiar/ zasobów danych (T1596) przez wyliczanie kont magazynu, wykazów schematów i metadanych klasyfikacji w celu profilowania repozytoriów o wysokiej wartości.
• Odnajdywanie (TA0007): wyliczanie kont i uprawnień (T1087, T1069) w celu ujawnienia nadmiernych powiązań ról umożliwiających eskalację dostępu do danych poziomych lub pionowych.
• Kolekcja (TA0009): dane z magazynu w chmurze (T1530) przez wyodrębnienie kontenerów blob bez etykiet lub niezarządzanych eksportów bez tagów do śledzenia.
• Eksfiltracja (TA0010): eksfiltracja przez usługi internetowe (T1567) za pomocą specjalnych punktów końcowych eksportu, gdzie brak jest bram etykietowania lub polityki.
• Eksfiltracja (TA0010): automatyczna eksfiltracja (T1020) przy użyciu stronicowania skryptowego/pętli w celu cichego zbierania błędnie sklasyfikowanych zestawów danych.

DP-1.1: Odnajdywanie, klasyfikowanie i etykietowanie poufnych danych

Użyj Microsoft Purview, aby utworzyć kompleksową mapę danych, która automatycznie odnajduje, klasyfikuje i oznacza poufne informacje w całym majątku danych. Rozszerzanie ochrony poza szyfrowanie na poziomie infrastruktury przez zaimplementowanie Microsoft Purview Information Protection w celu zastosowania trwałego szyfrowania na poziomie dokumentu i praw użytkowania, które są zgodne z danymi niezależnie od tego, gdzie są przesyłane. Ta podstawowa funkcja umożliwia sterowanie zabezpieczeniami podrzędnymi, takimi jak zapobieganie utracie danych, dostęp warunkowy i zasady szyfrowania do działania na podstawie poufności danych, a nie samej lokalizacji.

Odnajdywanie i klasyfikacja danych:

• Wdróż Microsoft Purview w celu odnajdywania, klasyfikowania i etykietowania poufnych danych w środowiskach Azure, lokalnych, Microsoft 365 i wielochmurowych.
• Użyj Microsoft Purview Mapy danych, aby automatycznie skanować i katalogować źródła danych, w tym Azure Storage, Azure SQL Database, Azure Synapse Analytics i inne obsługiwane usługi.
• Włącz etykiety poufności na mapie danych usługi Purview, aby automatycznie stosować etykiety klasyfikacji (np. Poufne, Wysoce poufne, DANE OSOBOWE, PHI) na podstawie wzorców zawartości danych i zasad organizacyjnych.

Szyfrowanie i ochrona na poziomie dokumentu:

• Wdróż Microsoft Purview Information Protection aby zastosować trwałe prawa szyfrowania i użytkowania do dokumentów i wiadomości e-mail na podstawie etykiet poufności. Skonfiguruj etykiety, aby automatycznie szyfrować pliki, stosować znaki wodne, ograniczać przekazywanie, ustawiać daty wygaśnięcia i odwoływać dostęp nawet po opuszczeniu organizacji.
• Włącz usługę Azure Rights Management Service (Azure RMS) jako podstawową technologię ochrony, która szyfruje dokumenty i wiadomości e-mail przy użyciu zasad użycia (tylko do wyświetlania, bez kopiowania, bez drukowania), które są utrwalane niezależnie od tego, gdzie dane są przechowywane lub udostępniane.

Klasyfikacja i integracja bazy danych:

• W przypadku baz danych Azure SQL włącz SQL Data Discovery & Klasyfikacja do identyfikowania, klasyfikowania i etykietowania kolumn zawierających poufne dane, takie jak numery kart kredytowych, numery ubezpieczenia społecznego lub rekordy zdrowotne.
• Integrowanie metadanych klasyfikacji z kontrolkami podrzędnymi: konfigurowanie zasad ochrony przed utratą danych (DLP) w Microsoft Purview, stosowanie reguł dostępu warunkowego w Entra ID i wymuszanie zasad szyfrowania na podstawie etykiet poufności.
• Ustanów regularny harmonogram skanowania w celu ciągłego odnajdywania nowo utworzonych lub zmodyfikowanych poufnych zasobów danych w miarę rozwoju majątku danych.

Przykład implementacji

Globalna organizacja usług finansowych wdrożyła mapę danych Microsoft Purview w celu automatycznego odnajdywania i klasyfikowania poufnych danych na kontach 200+ Azure Storage, 50 bazach danych SQL i obszarach roboczych usługi Synapse Analytics.

Challenge: Organizacja nie ma wglądu w miejsce, w którym znajdują się poufne dane w szybko rosnącej Azure infrastrukturze danych. Ręczna klasyfikacja danych była niespójna, opóźnione egzekwowanie zarządzania i tworzyła luki w zgodności z przepisami. Bez automatycznego odnajdywania dane regulowane (PHI, PII, PCI) pozostały niezabezpieczone w niekontrolowanych lokalizacjach, a zasady zapobiegania utracie danych nie mogły być odpowiednio uruchamiane.

Podejście do rozwiązania:

• Wdrażanie funkcji Mapowania danych Microsoft Purview w celu odnajdywania danych: Utwórz konto usługi Purview i zarejestruj źródła danych (konta Azure Storage, bazy danych SQL, obszary robocze Synapse Analytics), skonfiguruj mapowanie danych do skanowania źródeł przy użyciu uwierzytelniania tożsamości zarządzanej, udziel tożsamości skanującej uprawnień do odczytu (rola db_datareader) do katalogowania schematów i wykrywania poufnych kolumn.
• Konfigurowanie klasyfikacji i wykrywania wrażliwości: Ustaw reguły skanowania, aby wykrywać wzorce wrażliwe (SSN, numery kart kredytowych, numery rekordów medycznych, kody SWIFT), określ niestandardowe reguły klasyfikacji zgodne z zasadami klasyfikacji danych ("Poufne — wewnętrzne" dla danych wrażliwych dla firmy, "Wysoce poufne — regulowane" dla danych PHI/PCI/PII), skonfiguruj progi automatycznego etykietowania (zastosuj "Wysoce poufne", gdy w jednym zasobie wykryto ≥3 wzorce PII), ustanów harmonogramy skanowania na podstawie krytyczności danych (co tydzień dla produkcji oraz co miesiąc dla archiwów), skonfiguruj alerty, aby powiadamiać zespoły ds. zabezpieczeń po odnalezieniu nowych danych o wysokiej wrażliwości.
• Wdrożenie Microsoft Purview Information Protection do szyfrowania na poziomie dokumentu: Utwórz etykiety poufności w portalu zgodności usługi Purview z ustawieniami ochrony (Publiczne: brak szyfrowania, tylko oznaczenia wizualne; Wewnętrzne: znak wodny, brak ograniczeń przekazywania; Poufne: szyfruj za pomocą usługi Azure RMS, zezwalaj na wyświetlanie/edytowanie tylko dla pracowników, blokuj przekazywanie/drukowanie; Ściśle poufne — regulowane: szyfruj za pomocą usługi Azure RMS, dostęp tylko do wyświetlania, brak kopiowania/drukowania/przesyłania dalej, 90-dniowe wygaśnięcie, możliwość cofnięcia dostępu), publikuj etykiety poufności dla użytkowników za pomocą zasad etykiet (zakres: Finanse, Działy prawne, Działy wykonawcze), skonfiguruj zasady automatycznego etykietowania w celu automatycznego stosowania etykiet (≥10 SSN → "Ściśle poufne — regulowane", ≥5 numerów kart kredytowych → "Ściśle poufne — regulowane"), włącz ochronę Azure RMS dla dokumentów oznaczonych etykietami przechowywanych w kontach SharePoint, OneDrive i Azure Storage, skonfiguruj etykietowanie po stronie klienta dla aplikacji pakietu Office, aby monitować użytkowników o klasyfikowanie dokumentów przed zapisaniem/wysłaniem.

Wynik: Automatyczne skanowanie mapy danych usługi Purview zidentyfikowało ponad 15 000 zasobów danych zawierających dane regulowane w ciągu pierwszego tygodnia, co skraca czas odnajdywania z miesięcy do dni. Information Protection automatyczne etykietowanie zastosowało szyfrowanie do 8500 dokumentów w ciągu 72 godzin. Etykiety poufności umożliwiają ciągłą widoczność i ciągłą ochronę infrastruktury danych nawet wtedy, gdy dane są przenoszone do urządzeń niezarządzanych.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• Kontrolki CIS w wersji 8.1: 3.2, 3.7, 3.13
• NIST SP 800-53 Rev.5: RA-2, SC-28
• PCI-DSS 4: 3.2.1, 12.3.1
• NIST CSF v2.0: PR.DS-1, PR.DS-5
• ISO 27001:2022: A.8.11
• SOC 2: CC6.1

DP-2: Monitorowanie anomalii i zagrożeń skierowanych na poufne dane

Azure Policy: Zobacz wbudowane definicje zasad Azure: DP-2.

Zasada zabezpieczeń

Monitoruj działania dostępu do poufnych danych i transferu pod kątem anomalii, które wskazują na nieautoryzowaną eksfiltrację, zagrożenia wewnętrzne lub naruszone konta. Użyj baz zachowań i kontekstu czułości danych, aby wykrywać nietypowe wzorce, takie jak duże transfery, nietypowe czasy dostępu lub nieoczekiwany ruch danych.

Ryzyko w celu ograniczenia ryzyka

Przeciwnicy i złośliwi współpracownicy próbują eksfiltrować, etapować lub sondować poufne dane, stosując ukryte lub subtelne działania. Bez ciągłego monitorowania anomalii świadomego kontekstu powiązanego z wrażliwością danych:

• Dyskretna eksfiltracja: Eksporty zbiorcze, duże zestawy wyników lub syfonowanie przyrostowe przechodzą niezauważone z powodu braku bazowych linii.
• Niewłaściwe użycie wewnętrznych zasobów: Prawidłowe poświadczenia wykonują nietypowe sekwencje (czas dnia, ilość, lokalność), które pomijają podstawowe monitorowanie.
• Etap przygotowawczy i enumeracja: Atakujący mapują schematy/etykiety, aby ustalić priorytety celów o wysokiej wartości przed masową ekstrakcją.
• Living-off-the-land zapytania: Standardowe narzędzia administracyjne maskują rekonesans na tle normalnego szumu operacyjnego.
• Unikanie pojedynczego przechowywania: Rozproszony dostęp do wielu usług pozwala uniknąć progów i korelacji w jednym magazynie.

Nieodpowiednie wykrywanie anomalii osłabia skuteczność reagowania na incydenty i umożliwia eskalację od fazy rozpoznania do pełnoskalowej eksfiltracji przy minimalnym oporze.

MITRE ATT&CK

• Kolekcja (TA0009): dane z magazynu w chmurze (T1530) za pośrednictwem nietypowych operacji zbiorczych lub odczytów z szerokim rozchodem w kontenerach wrażliwych.
• Dostęp do poświadczeń (TA0006): prawidłowe konta (T1078) wykorzystujące naruszone lub wewnętrzne poświadczenia do wpasowania się w prawidłowe wzorce ruchu.
• Eksfiltracja (TA0010): automatyczna eksfiltracja (T1020) przy użyciu skryptowych, ograniczonych zapytań zaprojektowanych w celu uniknięcia progów alertów.
• Eksfiltracja (TA0010): eksfiltracja do magazynu w chmurze (T1567.002) umieszczania danych w regionach lub na kontach kontrolowanych przez osobę atakującą na potrzeby późniejszego pobierania.
• Command & Control/ Exfiltration (TA0011/TA0010): protokół warstwy aplikacji (T1071) tunelowanie poufnych wierszy za pośrednictwem normalnych wywołań bazy danych/interfejsu API.
• Odkrywanie (TA0007): wykrywanie systemu/usługi (T1082, T1046) enumeracja punktów końcowych w celu stworzenia ścieżek do ruchu bocznego do magazynów o wyższej wartości.

DP-2.1: Włączanie wykrywania zagrożeń dla usług danych

Wdróż usługi Microsoft Defender, aby zapewnić wykrywanie zagrożeń i monitorowanie anomalii w czasie rzeczywistym na platformach magazynu danych i bazy danych. Te usługi używają analizy behawioralnej i analizy zagrożeń do identyfikowania podejrzanych działań, takich jak próby wstrzyknięcia kodu SQL, nietypowe wzorce zapytań, nietypowe woluminy dostępu do danych i potencjalne wskaźniki eksfiltracji, których nie można wykryć w tradycyjnych kontrolach dostępu.

Włącz wykrywanie zagrożeń dla usług danych:

• Włącz Microsoft Defender dla Storage z funkcjami skanowania złośliwego oprogramowania i wykrywania zagrożeń poufnych danych w celu monitorowania nietypowych wzorców dostępu, nietypowych woluminów przesyłania/pobierania oraz potencjalnych prób eksfiltracji danych na kontach Azure Storage.
• Włącz Microsoft Defender dla programu SQL w celu wykrywania podejrzanych działań bazy danych, w tym prób iniekcji SQL, nietypowych wzorców zapytań, nietypowych operacji eksportowania danych i dostępu z nieznanych lokalizacji.
• Włącz Microsoft Defender dla Azure Cosmos DB w celu wykrywania nietypowych wzorców dostępu do bazy danych, potencjalnych eksfiltracji danych i podejrzanych działań operacyjnych.
• W przypadku baz danych typu open source (PostgreSQL, MySQL) włącz Microsoft Defender dla relacyjnych baz danych typu open source w celu wykrywania ataków siłowych, podejrzanych wzorców dostępu i nietypowych operacji administracyjnych.

DP-2.2: Monitorowanie i zapobieganie eksfiltracji danych

Zaimplementuj proaktywne mechanizmy kontroli ochrony przed utratą danych i monitorowanie zachowania w celu wykrywania i blokowania nieautoryzowanych transferów danych przed ich powodzeniem. Połącz zasady oparte na zasadach DLP z zarządzaniem ryzykiem poufnym, korelacją rozwiązania SIEM i automatyczną reakcją, aby utworzyć podejście do ochrony w głębi systemu, które zatrzymuje próby eksfiltracji w wielu kanałach, zapewniając dowody kryminalistyczne na potrzeby badania incydentów.

Wdróż mechanizmy DLP i kontrole ryzyka wewnętrznego:

• Użyj zasad Ochrona przed utratą danych w Microsoft Purview (DLP), aby zapobiec eksfiltracji poufnych danych przez monitorowanie i blokowanie nieautoryzowanych transferów danych niejawnych w usługach Azure, Microsoft 365 i punktach końcowych.
• Wdróż Zarządzanie ryzykiem wewnętrznym w Microsoft Purview w celu wykrywania ryzykownych zachowań użytkowników przy użyciu uczenia maszynowego i analizy behawioralnej. Monitoruj wskaźniki, w tym nietypowe pobieranie danych, kopiowanie plików do magazynu w chmurze USB/osobistej, uzyskiwanie dostępu do poufnych zasobów poza normalnymi godzinami pracy lub skoki dostępu do danych przed datami rezygnacji. Zarządzanie ryzykiem wewnętrznym koreluje sygnały z Microsoft 365, Azure, systemów kadrowych i narzędzi zabezpieczeń w celu zidentyfikowania potencjalnej kradzieży danych lub naruszeń zasad.

Konfigurowanie monitorowania i odpowiedzi:

• Skonfiguruj dzienniki diagnostyczne dla usług danych i kieruj je do Azure Monitor lub Microsoft Sentinel w celu ustanowienia punktów odniesienia zachowania i wykrywania odchyleń od normalnych wzorców dostępu.
• Integrowanie dzienników usługi danych z Microsoft Sentinel w celu utworzenia reguł analizy na potrzeby wykrywania nietypowych wzorców dostępu do danych, takich jak zbiorcze pobieranie, dostęp poza godzinami pracy lub podejrzane zachowania zapytań.
• Zaimplementuj zautomatyzowane przepływy pracy reagowania na incydenty przy użyciu Azure Logic Apps lub Microsoft Sentinel playbooków w celu odizolowania kompromitowanych tożsamości, cofnięcia dostępu i powiadamiania zespołów ds. zabezpieczeń, gdy zostaną wykryte próby eksfiltracji danych.

Note: W przypadku wymagań DLP opartych na hoście wdróż Microsoft Purview Endpoint DLP możliwości lub rozwiązania innych firm z Azure Marketplace w celu wymuszenia mechanizmów ochrony danych na poziomie punktu końcowego.

Przykład implementacji

Dostawca opieki zdrowotnej włączył Microsoft Defender dla usługi Storage i Defender dla programu SQL w celu monitorowania anomalii i zagrożeń dotyczących danych pacjentów na kontach Azure Storage i bazach danych SQL.

Wyzwanie: Organizacja napotkała ślepe plamy w wykrywaniu nieautoryzowanego dostępu do danych i prób eksfiltracji. Tradycyjne zabezpieczenia obwodowe nie wykryły zagrożeń wewnętrznych, przez co doszło do naruszenia zasad serwisowych wykonujących zbiorcze pobieranie danych. Bez analizy behawioralnej i wykrywania anomalii podejrzane wzorce dostępu zostały niezauważone przez dłuższy czas, zwiększając ryzyko naruszenia i czas zamieszkania.

Podejście do rozwiązania:

• Włącz Microsoft Defender dla magazynu: Włącz Defender dla magazynu na poziomie subskrypcji dla kont magazynu zawierających poufne dane, skonfiguruj skanowanie złośliwego oprogramowania w celu wykrywania i kwarantanny złośliwych plików w magazynie obiektów blob, włącz wykrywanie zagrożeń poufnych danych przy użyciu typów poufnych informacji usługi Purview w celu identyfikowania wzorców PHI/PII, aby kontrolować koszty, ustaw limity skanowania na transakcję lub miesięczne limity, stosuj ochronę do grup zasobów zawierających produkcyjne konta magazynu hostujące obrazowanie medyczne i eksporty EHR.
• Włącz program Microsoft Defender dla SQL: Włącz Defender dla SQL na poziomie subskrypcji dla Azure SQL Database i SQL Managed Instance, skonfiguruj ocenę luk w zabezpieczeniach przy użyciu cyklicznych skanów i wyznacz konto magazynu do przechowywania wyników skanowania, skonfiguruj powiadomienia e-mail, aby ostrzec zespół ds. zabezpieczeń o zidentyfikowanych lukach w zabezpieczeniach, włącz Advanced Threat Protection, aby wykrywać próby wstrzyknięcia kodu SQL, nietypowe wzorce zapytań, nietypowy dostęp z nieznanych regionów i potencjalną eksfiltrację danych.
• Integracja z Microsoft Sentinel: Połącz Microsoft Defender dla Chmury z Microsoft Sentinel przy użyciu łącznika danych, skonfiguruj ustawienia diagnostyczne (włącz dzienniki diagnostyczne dla operacji magazynowych oraz dzienniki audytu SQL, kieruj do obszaru roboczego Log Analytics), utwórz reguły analizy usługi Sentinel w celu wykrywania anomalii (alerty o zbiorczym pobieraniu plików przekraczających >10 GB w ciągu 1 godziny, dostęp do bazy danych poza godzinami, podejrzane wzorce zapytań), skonfiguruj zautomatyzowane podręczniki odpowiedzi w celu izolowania tożsamości z naruszonymi zabezpieczeniami, odwoływania dostępu do magazynu i powiadamiania zespołów ds. zabezpieczeń.
• Wdrożenie Zarządzanie ryzykiem wewnętrznym w Microsoft Purview do wykrywania zagrożeń behawioralnych: Włącz zarządzanie ryzykiem wewnętrznym i skonfiguruj szablony zasad (wykrywanie kradzieży danych przez odchodzących użytkowników poprzez nietypowe pobieranie plików w okresie 30-90 dni przed rezygnacją, monitorowanie ogólnych przecieków danych przy kopiowaniu do magazynów USB/chmurowych, wycieki danych przez użytkowników priorytetowych z rozszerzonym monitorowaniem ról o wysokich uprawnieniach), skonfiguruj wskaźniki ryzyka i progi (alerty dotyczące zbiorczego pobierania plików, skoki dostępu poza godzinami pracy, wykrywanie sekwencji łączące wiele ryzykownych sygnałów), integruj źródła danych (dzienniki aktywności Azure, dzienniki inspekcji Microsoft 365, Defender for Cloud Apps, systemy HR, zdarzenia DLP na punktach końcowych), skonfiguruj przepływ pracy dla triage alertów kierując alerty o średniej/wysokiej ważności do dedykowanej kolejki dochodzeń.

Outcome: Defender for Storage wykrył nietypowe działanie pobierania zbiorczego z naruszonego obiektu usługi w ciągu 48 godzin. Automatyczna odpowiedź odizolowała tożsamość i powiadomiła SOC w ciągu kilku minut, skracając czas wykrywania od dni do poniżej 15 minut. Insider Risk Management oznaczył odchodzącego pracownika, który pobierał dane badawcze znacznie powyżej osobistego poziomu bazowego do prywatnej chmury, umożliwiając szybką reakcję.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• Kontrolki CIS w wersji 8.1: 3.13
• NIST SP 800-53 Rev.5: AC-4, SI-4
• PCI-DSS 4: 3.2.1, 10.4.1
• NIST CSF v2.0: DE.CM-1, PR.DS-5
• ISO 27001:2022: A.8.11, A.8.16
• SOC 2: CC6.1, CC7.2

DP-3: Szyfrowanie poufnych danych podczas przesyłania

Azure Policy: Zobacz wbudowane definicje zasad Azure: DP-3.

Zasada zabezpieczeń

Ochrona danych przesyłanych przy użyciu silnego szyfrowania (takiego jak TLS 1.2 lub nowszy), aby zapobiec przechwytywaniu, manipulowaniu i nieautoryzowanemu dostępowi. Zdefiniuj granice sieci i zakresy usług, w których szyfrowanie jest obowiązkowe, ustalanie priorytetów ruchu w sieci zewnętrznej i publicznej przy jednoczesnym uwzględnieniu ochrony sieci wewnętrznej na podstawie poufności danych.

Ryzyko w celu ograniczenia ryzyka

Niezaszyfrowane lub słabo chronione kanały sieciowe narażają poufne dane na przechwytywanie, manipulację i nadużycia w celu obniżenia jakości. Brak wymuszonego nowoczesnego szyfrowania transportu (TLS 1.2+):

• Przechwytywanie pasywne: Obserwatorzy sieci przechwytują poświadczenia, tokeny, ładunki interfejsu API lub dane regulowane w postaci zwykłego tekstu.
• Man-in-the-middle: Osoby atakujące zmieniają zapytania, wstrzykują ładunki lub zbierają materiały sesji.
• Obniżanie poziomu protokołu: Starsza wersja rezerwowa (SSL/TLS < 1.2, zwykły tekst HTTP/FTP) umożliwia wykorzystanie przestarzałych zestawów szyfrowania.
• Przejęcie sesji: Brak integralności kanału umożliwia powtórne użycie tokenu lub kradzież plików cookie w celu wykonywania ruchu lateralnego.
• Manipulacja integralnością: Manipulowanie powoduje uszkodzenie analiz lub wyzwala fałszywe transakcje.
• Nieprzezroczyste ścieżki boczne: Wewnętrzny ruch w postaci zwykłego tekstu staje się przyczółkiem materiałów rozpoznawczych.

Brak wymuszania silnego szyfrowania podczas przesyłania zwiększa zakres skutków naruszenia, przyspiesza przejęcie poświadczeń i podważa założenia zerowego zaufania.

MITRE ATT&CK

• Dostęp do poświadczeń (TA0006): niechronione poświadczenia (T1552) przechwycone podczas sesji zwykłego tekstu lub obniżonej wersji protokołu TLS uwidaczniających tokeny/materiał sesji.
• Kolekcja (TA0009): przechwytywanie ruchu sieciowego (T1040), zbieranie ładunków i tajnych informacji z interfejsów API przechodzących przez słabe ścieżki szyfrujące lub przesyłane jako zwykły tekst.
• Eksfiltracja (TA0010): eksfiltracja za pośrednictwem usług internetowych (T1567) strumieniowe przesyłanie danych strukturalnych za pośrednictwem zaufanych punktów końcowych API.
• Unikanie ochrony (TA0005): ataki typu man-in-the-middle (T1557) wymuszające degradację TLS lub umieszczanie serwerów proxy do przechwytywania i modyfikowania ruchu.
• Command & Control (TA0011): protokoły spoza warstwy aplikacji (T1095) przechodzą na starsze lub mniej kontrolowane mechanizmy transportu w celu obejścia monitorowania.

DP-3.1: Wymuszanie szyfrowania TLS dla usług i aplikacji danych

Ustanów nowoczesne standardy zabezpieczeń warstwy transportu we wszystkich usługach i platformach danych przeznaczonych dla klientów, aby chronić przed przechwytywaniem, manipulowaniem i atakami typu man-in-the-middle. Wymuszanie minimalnej wersji TLS 1.2 lub 1.3 w przechowywaniu danych, aplikacjach internetowych, bazach danych i bramach interfejsu API, przy jednoczesnym wyłączeniu starszych protokołów i słabych zestawów szyfrowania, które narażają dane na ataki związane z obniżeniem poziomu szyfrowania.

Wymuszanie protokołu TLS dla usług danych i aplikacji:

• Wymuś bezpieczony transfer (tylko HTTPS) dla kont Azure Storage w celu zapewnienia, że wszystkie połączenia klienckie używają protokołu TLS 1.2 lub nowszego dla operacji obiektów blob, plików, kolejek i tabel.
• W przypadku aplikacji internetowych hostowanych w Azure App Service włącz ustawienie "Tylko https" i skonfiguruj minimum TLS w wersji 1.2 lub 1.3 aby zapobiec atakom na starszą wersję i zapewnić nowoczesne standardy kryptograficzne.
• Skonfiguruj Azure Application Gateway, aby wymusić minimalną wersję protokołu TLS 1.2/1.3 dla odbiorników frontendowych i szyfrowania połączeń zaplecza (TLS end-to-end).
• W przypadku Azure SQL Database i innych usług danych PaaS sprawdź, czy opcja "Wymagaj bezpiecznych połączeń" lub równoważne ustawienia wymuszają szyfrowane połączenia; odrzucają połączenia w postaci zwykłego tekstu.
• W przypadku usługi API Management, Azure Front Door i innych usług bramy skonfiguruj minimalne zasady wersji protokołu TLS w celu wymuszania protokołu TLS 1.2 lub nowszego i wyłączania słabych zestawów szyfrowania.

Note: Azure automatycznie szyfruje cały ruch między centrami danych Azure przy użyciu protokołu MACsec (warstwa 2) i TLS (warstwa 7). Większość usług Azure PaaS domyślnie włącza protokół TLS 1.2 lub nowszy, ale sprawdza minimalne ustawienia wersji protokołu TLS dla usług przy użyciu zasad konfigurowalnych przez klienta (Storage, App Service, Application Gateway, API Management, Front Door).

DP-3.2: Bezpieczny dostęp zdalny i protokoły transferu plików

Wyeliminuj dostęp administracyjny w postaci zwykłego tekstu i starsze protokoły transferu plików, które uwidaczniają poświadczenia i poufne dane podczas działań operacyjnych. Zastąp niezabezpieczone protokoły (FTP, niezaszyfrowane protokoły RDP/SSH) nowoczesnymi, zaszyfrowanymi alternatywami i dostępem uprzywilejowanym przez scentralizowane bastiony, aby wyeliminować bezpośrednią ekspozycję internetową interfejsów zarządzania.

Bezpieczne protokoły zdalnego zarządzania:

• Do zdalnego zarządzania maszynami wirtualnymi Azure należy używać wyłącznie bezpiecznych protokołów:
  • Maszyny wirtualne z systemem Linux: Użyj protokołu SSH (port 22) z uwierzytelnianiem opartym na kluczach; wyłącz uwierzytelnianie haseł.
  • Windows VM-y: Użyj RDP przez TLS (port 3389) z aktywnym uwierzytelnianiem NLA.
  • Dostęp uprzywilejowany: Kieruj połączenia administracyjne przez Azure Bastion, aby wyeliminować ujawnienie publicznych adresów IP i zapewnić dostęp do klienta przeglądarkowego lub natywnego za pośrednictwem protokołu TLS.

Bezpieczne protokoły transferu plików:

• W przypadku operacji transferu plików użyj bezpiecznych protokołów i wyłącz starsze alternatywy:
  • Użyj obsługi SFTP w Azure Blob Storage (wymaga hierarchicznej przestrzeni nazw).
  • Użyj usługi FTPS w Azure App Service i Azure Functions.
  • Wyłącz starszy protokół FTP (zwykły tekst).
• Użyj Azure Policy, aby wymusić zasady bezpiecznego transferu w całym środowisku i monitorować zgodność wymagań dotyczących wersji protokołu TLS.

Przykład implementacji

Platforma handlu elektronicznego wymusiła minimalną wersję protokołu TLS 1.3 we wszystkich usługach przeznaczonych dla klientów, aby spełnić wymagania PCI-DSS 4.0.

Wyzwanie: Starsze protokoły TLS 1.0/1.1 oraz słabe zestawy szyfrowania narażały dane płatności klientów na ryzyko przechwycenia przez ataki. Niespójne wymuszanie protokołu TLS między warstwami aplikacji spowodowało, że osoby atakujące mogły obniżyć poziom połączeń. Bez scentralizowanego egzekwowania polityki TLS, ręczne zmiany konfiguracji pozwalały na utrwalanie niezabezpieczonych protokołów w produkcji.

Podejście do rozwiązania:

• Konfiguruj Azure App Service dla protokołu TLS 1.3: Ustaw minimalną wersję protokołu TLS na 1.3 dla aplikacji internetowych i interfejsów API przeznaczonych dla klientów, włącz tryb tylko HTTPS, aby automatycznie przekierowywać cały ruch HTTP do protokołu HTTPS, sprawdź, czy zarządzane certyfikaty lub certyfikaty niestandardowe używają silnych zestawów szyfrowania.
• Konfigurowanie Azure Application Gateway dla kompleksowego protokołu TLS: Skonfiguruj odbiornik HTTPS na panelu przednim przy użyciu polityki SSL AppGwSslPolicy20220101 (minimum TLS 1.3 z polityką CustomV2), prześlij certyfikat TLS lub zintegruj z Key Vault w celu zarządzania certyfikatami, skonfiguruj ustawienia zaplecza dla połączeń HTTPS (ustaw protokół zaplecza na HTTPS na porcie 443, włącz opcję "Użyj znanego certyfikatu CA", jeśli usługi App Services zaplecza używają certyfikatów zarządzanych przez Azure, ustaw minimalną wersję protokołu TLS na 1.2 dla połączeń zaplecza), utwórz reguły routingu łączące odbiorniki HTTPS z pulami zaplecza z ustawieniami obsługującymi TLS.
• Wymuszaj bezpieczny transfer dla Azure Storage: Włącz ustawienie "Wymagany bezpieczny transfer", aby wymusić użycie tylko protokołu HTTPS dla operacji obiektów blob, plików, kolejek i tabel, ustaw minimalną wersję protokołu TLS na 1.2 dla wszystkich połączeń magazynu, sprawdź, czy wszystkie tokeny SAS i klucze udostępnione działają wyłącznie za pomocą połączeń HTTPS.
• Konfiguruj Azure Bastion na potrzeby bezpiecznego dostępu zdalnego: Wdróż Azure Bastion w sieci wirtualnej centrum w celu zapewnienia dostępu RDP/SSH opartego na przeglądarce za pośrednictwem protokołu TLS 1.2, usuń publiczne adresy IP z maszyn wirtualnych i skierować cały dostęp administracyjny wyłącznie za pośrednictwem usługi Bastion.

Outcome: Konta Azure Storage odrzucają połączenia HTTP na granicy usługi, Application Gateway wymusza protokół TLS 1.3 dla połączeń frontendowych z szyfrowaniem backendu TLS 1.2, a Azure Bastion eliminuje narażenie na publiczny adres IP dla zarządzania maszynami wirtualnymi.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• Kontrolki CIS w wersji 8.1: 3.10
• NIST SP 800-53 Rev.5: SC-8
• PCI-DSS 4: 4.2.1, 4.2.2
• NIST CSF v2.0: PR. DS-2
• ISO 27001:2022: A.8.24
• SOC 2: CC6.1, CC6.7

DP-4: Domyślnie włącz szyfrowanie danych magazynowanych

Azure Policy: Zobacz Wbudowane definicje zasad Azure: DP-4.

Zasada zabezpieczeń

Włącz szyfrowanie danych w spoczynku domyślnie, aby chronić dane przed nieautoryzowanym dostępem za pośrednictwem bazowej pamięci masowej, kradzieży nośników fizycznych, ujawnienia migawki lub naruszonego dostępu do infrastruktury. Szyfrowanie uzupełnia mechanizmy kontroli dostępu, zapewniając ochronę danych nawet wtedy, gdy zabezpieczenia na poziomie magazynu są pomijane.

Ryzyko w celu ograniczenia ryzyka

Niezaszyfrowane lub selektywnie zaszyfrowane warstwy magazynu umożliwiają osobom atakującym dostęp poza pasmem (naruszenie infrastruktury, skradzione nośniki, nadużycie migawek) w celu zbierania poufnych danych na dużą skalę. Bez domyślnego szyfrowania:

• Zbieranie danych z nieprzetworzonych nośników: Skradzione dyski, kopie zapasowe lub niezarządzane migawki uwidaczniają pełne zestawy danych w postaci zwykłego tekstu.
• Erozja granic uprawnień: Administratorzy platformy lub agenci hosta z naruszonymi zabezpieczeniami mogą odczytywać dane najemcy bez separacji kryptograficznej.
• Kopiowanie w trybie dyskretnym i eksfiltracja: Repliki niezaszyfrowane (test, analiza, eksport) stają się kanałami eksfiltracji o niskim tarciu.
• Manipulowanie integralnością: Osoby atakujące modyfikują nieaktywne dane (złośliwe biblioteki DLL, konfigurację lub dane referencyjne), aby wyzwolić naruszenie bezpieczeństwa na późniejszym etapie.
• Niezgodność z przepisami: Brak szyfrowania systemowego podważa gwarancje wymagane dla wielu certyfikatów branżowych.
• Narażenie na odzyskiwanie danych bez użycia kluczy: Obrazy odzyskiwania po awarii i zimne archiwa zachowują wrażliwą zawartość na czas nieokreślony w formacie czytelnego tekstu.

Brak wymuszania uniwersalnego szyfrowania w spoczynku zwiększa skalę naruszeń, komplikuje określanie zakresu śledczego i powiększa podrzędne ryzyko operacyjne i prawne.

MITRE ATT&CK

• Kolekcja (TA0009): dane z pamięci masowej w chmurze (T1530) poprzez wyodrębnianie niezaszyfrowanych migawek, replik lub odłączonych dysków.
• Obejście obrony (TA0005): usuwanie wskaźników (T1070), edytowanie lub czyszczenie dzienników po dostępie do nośników offline / migawek.
• Wpływ (TA0040): niszczenie danych (T1485) przez uszkadzanie nieszyfrowanych zasobów w stanie uśpienia w celu zakłócenia procesów podrzędnych.
• Wpływ (TA0040): hamuje odzyskiwanie systemu (T1490) usuwając lub zmieniając niezaszyfrowane kopie zapasowe i wykazy odzyskiwania.
• Wpływ (TA0040): manipulowanie danymi (T1565) subtelnie modyfikując przechowywane dane referencyjne lub konfiguracyjne, aby spowodować błędy logiki etapu późniejszego.

DP-4.1: Domyślnie włącz szyfrowanie danych w spoczynku

Upewnij się, że wszystkie dane przechowywane na platformie Azure są szyfrowane, gdy są w spoczynku, aby chronić przed nieautoryzowanym dostępem wskutek naruszenia infrastruktury, skradzionymi nośnikami lub nieautoryzowanymi migawkami. Chociaż większość usług Azure domyślnie włącza szyfrowanie, weryfikuj pokrycie w obrębie maszyn wirtualnych, kont magazynowych i baz danych oraz włączaj dodatkowe warstwy szyfrowania (szyfrowanie na hoście, szyfrowanie infrastruktury, poufne przetwarzanie i szyfrowanie na poziomie kolumny) dla wysoce poufnych obciążeń w celu spełnienia wymagań prawnych i suwerenności danych.

Włącz szyfrowanie dla maszyn wirtualnych i magazynu:

• Włącz encryption-at-host dla maszyn wirtualnych Azure, aby szyfrować dyski tymczasowe, pamięć podręczną dysku systemowego, pamięć podręczną dysków danych oraz efemeryczne dyski systemowe, zanim dane trafią do Azure Storage. Zarejestruj funkcję EncryptionAtHost na poziomie subskrypcji i wdróż maszyny wirtualne przy użyciu obsługiwanych rozmiarów maszyn wirtualnych (np. DSv3, Easv4, Dadsv5).
• Włącz szyfrowanie infrastruktury (podwójne szyfrowanie) dla kont Azure Storage wymagających dodatkowych warstw szyfrowania. Ta funkcja zapewnia dwie warstwy szyfrowania AES-256 z różnymi kluczami zarówno na poziomie usługi, jak i infrastruktury — należy to skonfigurować podczas tworzenia konta magazynowego, ponieważ nie można tego włączyć po jego utworzeniu.

Wdrażanie poufnego przetwarzania i szyfrowania na poziomie kolumny:

• Rozmieść Poufne maszyny wirtualne Azure z poufnym szyfrowaniem dysków dla obciążeń o wysokim poziomie regulacji prawnych przetwarzających dane objęte restrykcjami eksportowymi lub dane poufne. Użyj serii DCasv5/DCadsv5 (AMD SEV-SNP) lub ECasv5/ECadsv5 serii (Intel TDX) z powiązanymi kluczami szyfrowania dysków vTPM, aby zapewnić szyfrowanie danych podczas przetwarzania.
• W przypadku Azure SQL Database zaimplementuj Always Encrypted aby zapewnić szyfrowanie na poziomie kolumny po stronie klienta dla wysoce poufnych danych (SSN, numerów kart kredytowych, dokumentacji medycznej), gdzie dane pozostają szyfrowane nawet przez administratorów bazy danych, operatorów w chmurze i wysoce uprzywilejowanych, ale nieautoryzowanych użytkowników. Używaj funkcji Always Encrypted z bezpiecznymi enklawami (Intel SGX), aby umożliwić bogatsze zapytania dotyczące zaszyfrowanych kolumn.

Monitorowanie i wymuszanie zgodności szyfrowania:

• Wymuszanie zgodności szyfrowania przy użyciu Azure Policy przez przypisanie wbudowanych zasad, takich jak "Maszyny wirtualne powinny włączyć szyfrowanie na hoście", "Konta magazynu powinny mieć szyfrowanie infrastruktury" i "Transparent Data Encryption w bazach danych SQL powinny być włączone" w zakresie subskrypcji lub grupy zarządzania.
• Użyj Azure Resource Graph do zapytań i inwentaryzacji konfiguracji szyfrowania w swoim środowisku, aby zidentyfikować maszyny wirtualne bez szyfrowania podczas hostingu, konta magazynu bez szyfrowania infrastrukturalnego lub bazy danych bez włączonego szyfrowania TDE.

Note: Wiele usług Azure (Azure Storage, Azure SQL Database, Azure Cosmos DB) ma domyślnie włączone szyfrowanie danych magazynowanych w warstwie infrastruktury przy użyciu kluczy zarządzanych przez usługę, które automatycznie obracają się co dwa lata. Jeśli szyfrowanie nie jest domyślnie włączone, włącz je na poziomie magazynu, pliku lub bazy danych w oparciu o wymagania techniczne i wymagania dotyczące obciążenia.

Przykład implementacji

Międzynarodowa firma produkcyjna ustandaryzowała szyfrowanie danych w spoczynku w środowisku platformy Azure w celu ochrony danych ERP, aplikacji łańcucha dostaw i tajemnic handlowych związanych z inżynierią.

Wyzwanie: Niespójne pokrycie szyfrowania pozostawiło poufne dane narażone na naruszenie infrastruktury i kradzież migawki. Dane dysku tymczasowego i przechowywanie efemeryczne pozostały niezaszyfrowane, tworząc luki w zgodności. Bez systematycznego wymuszania szyfrowania inżynieryjne tajemnice handlowe i dane łańcucha dostaw mogą być ujawniane poprzez skradzione dyski, nieautoryzowane zrzuty lub skompromitowanych agentów hosta.

Podejście do rozwiązania:

• Włączanie szyfrowania na hoście dla Azure Virtual Machines: rejestrowanie funkcji EncryptionAtHost na poziomie subskrypcji, włączanie szyfrowania na hoście dla maszyn wirtualnych przy użyciu obsługiwanych rozmiarów maszyn wirtualnych (DSv3, Easv4, Dadsv5), szyfrowanie obejmuje dyski tymczasowe, pamięć podręczną dysku systemu operacyjnego, pamięć podręczną dysku danych i efemeryczny dysk systemu operacyjnego.
• Włącz szyfrowanie infrastruktury (podwójne szyfrowanie) dla Azure Storage: Sprawdź, czy szyfrowanie usługi Azure Storage (SSE) jest włączone (domyślnie — szyfrowanie AES-256), dla poufnych kont magazynu włącz szyfrowanie infrastruktury podczas tworzenia konta (nie można go włączyć po utworzeniu), wynik: dwie warstwy szyfrowania AES-256 z różnymi kluczami.
• Wdrażaj poufne maszyny wirtualne Azure dla wysoce regulowanych obciążeń: Wybierz odpowiednią serię poufnych maszyn wirtualnych (DCasv5/DCadsv5-serii dla AMD SEV-SNP lub ECasv5/ECadsv5-serii dla Intel TDX), włącz szyfrowanie dysków poufnych przy użyciu klucza zarządzanego przez platformę (łączenie kluczy szyfrowania dysków z wirtualnym TPM maszyny wirtualnej), włącz Bezpieczny Rozruch i wirtualny TPM na potrzeby zaświadczania, wdrażaj dla obciążeń przetwarzających dane techniczne kontrolowane przez eksport lub wysoce regulowane dane osobowe, w których dane muszą pozostać szyfrowane podczas przetwarzania.
• Implementuj Always Encrypted dla poufnych kolumn bazy danych: Zidentyfikuj wysoce poufne kolumny w Azure SQL Database wymagające szyfrowania na poziomie kolumny (takie jak SSN, CreditCardNumber, MedicalRecordNumber). Generuj klucze szyfrowania kolumn (CEK) oraz klucze główne kolumn (CMK), przechowując klucz CMK w Azure Key Vault. Klucz CEK będzie szyfrować dane w kolumnach, a klucz CMK zaszyfruje klucz CEK. Włącz Always Encrypted z użyciem bezpiecznych enklaw (Intel SGX), aby umożliwić bardziej złożone zapytania na zaszyfrowanych danych. Szyfruj poufne kolumny, korzystając z szyfrowania deterministycznego (dla porównań równoważności) lub szyfrowania losowego (dla maksymalnego zabezpieczenia). Skonfiguruj parametry połączenia aplikacji z ustawieniem Column Encryption Setting=Enabled dla przezroczystego szyfrowania/odszyfrowywania.
• Konfiguracje szyfrowania w Azure Resource Graph: Zapytaj o stan szyfrowania dla maszyn wirtualnych bez szyfrowania na hoście oraz kont magazynu bez szyfrowania infrastruktury, a następnie wyeksportuj wyniki do pliku CSV i przypisz zadania związane z korygowaniem do właścicieli zasobów.

Wynik: Szyfrowanie na hoście rozwiązało luki w zgodności, w których dane dysku tymczasowego były wcześniej niezaszyfrowane. Pliki inżynieryjne zabezpieczone szyfrowaniem infrastruktury składającym się z dwóch warstw. Poufne maszyny wirtualne zapewniły, że dane objęte kontrolą eksportu pozostają zaszyfrowane nawet przed administratorami chmury. Zawsze szyfrowane poufne kolumny bazy danych — administratorzy bazy danych potwierdzili brak możliwości odczytu zwykłego tekstu z zaszyfrowanych kolumn, spełniając wymagania dotyczące zgodności.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• Kontrole CIS w wersji 8.1: 3.11
• NIST SP 800-53 Rev.5: SC-28
• PCI-DSS 4: 3.5.1, 3.6.1
• NIST CSF v2.0: PR. DS-1
• ISO 27001:2022: A.8.24
• SOC 2: CC6.1

DP-5: Użyj opcji klucza zarządzanego przez klienta podczas szyfrowania danych w stanie spoczynku, jeśli jest to wymagane

Azure Policy: Zobacz wbudowane definicje zasad dla Azure: DP-5.

Zasada zabezpieczeń

Używaj kluczy zarządzanych przez klienta, gdy zgodność z przepisami, wymagania umowne lub czułość danych wymagają bezpośredniej kontroli nad cyklem życia klucza szyfrowania, w tym generowaniem kluczy, rotacją i urzędem odwołania. Upewnij się, że istnieją odpowiednie procesy zarządzania kluczami w celu obsługi obciążeń operacyjnych.

Ryzyko w celu ograniczenia ryzyka

Poleganie wyłącznie na kluczach zarządzanych przez usługi tam, gdzie wymagania regulacyjne, umowne lub dotyczące segregacji wymagają kontroli dzierżawcy, wprowadza ryzyko związane ze zgodnością i koncentracją. Bez prawidłowego zarządzania kluczami zarządzanymi przez klienta (CMK):

• Nieodpowiednie zapewnienie regulacyjne: Audytorzy mogą odrzucać dowody kontroli kryptograficznej, jeśli nie można wykazać zarządzania kluczami, cyklu rotacji lub uprawnień do unieważniania.
• Opóźnienie odwołania: Brak możliwości szybkiego odwołania lub zmiany skompromitowanych kluczy platformy rozszerza okno podatności po zdarzeniach związanych z poświadczeniami lub łańcuchem dostaw.
• Ryzyko jurysdykcyjne: Mandaty dotyczące suwerenności danych mogą wymagać kluczy zarządzanych przez najemcę lub opartych na module HSM — brak takich kluczy obniża wykonalność wdrożenia regionalnego.
• Zakres zagrożenia między dzierżawami: Naruszenie klucza platformy wielodzierżawowej może wpływać na obszerne zestawy danych, gdy izolacja kryptograficzna jest niewystarczająca.
• Proliferacja cieni: Wdrożenia CMK ad hoc bez zarządzania cyklem życia prowadzą do nieaktualnych, osieroconych lub słabych kluczy.
• Kruchość operacyjna: Niska automatyzacja rotacji lub brak mapowania zależności powoduje awarie aplikacji podczas zmiany klucza.

Nieprawidłowe lub pominięte użycie klucza zarządzanego przez klienta osłabia zapewnienie kryptograficzne i podważa strategiczną pozycję zgodności w przypadku wrażliwych obciążeń.

MITRE ATT&CK

• Dostęp poświadczeń (TA0006): niechronione poświadczenia (T1552) uwidocznione przez słabo chronione lub nieprawidłowo podzielone klucze platformy.
• Wpływ (TA0040): dane zaszyfrowane w celu wpłynięcia (T1486), nadużywając rotacji/odwołania CMK, aby uniemożliwić dostęp do danych.
• Wpływ (TA0040): manipulowanie danymi (T1565) modyfikujące metadane stanu szyfrowania w celu odsynchronizowania warstw ochrony.
• Eksfiltracja (TA0010): transfer danych na konto w chmurze (T1537) poprzez ponowne szyfrowanie i eksportowanie zestawów danych do przechowalni kontrolowanej przez osobę atakującą.
• Eksfiltracja (TA0010): eksfiltracja za pośrednictwem usług internetowych (T1567) koordynująca wysokonakładowe eksporty zbiorcze z obsługą kluczy w ramach normalnych wzorców usługowych.

DP-5.1: Użyj opcji klucza zarządzanego przez klienta w przypadku szyfrowania danych spoczywających, jeśli jest to wymagane.

Zaimplementuj klucze zarządzane przez klienta, gdy zgodność z przepisami, nakazy niezależności danych lub zobowiązania umowne wymagają bezpośredniej kontroli nad ochroną klucza szyfrowania, harmonogramami rotacji i urzędem odwołania. W przypadku obciążeń wymagających ostatecznej kontroli, jeśli nawet Microsoft nie może odszyfrować danych, zaimplementuj podwójne szyfrowanie kluczy (DKE), gdzie organizacja utrzymuje drugi klucz szyfrowania poza Azure. Użyj Azure Key Vault lub zarządzanego modułu HSM, aby utrzymać kontrolę kryptograficzną, jednocześnie równoważąc złożoność operacyjną zarządzania cyklem życia kluczy, planowania odzyskiwania po awarii i potencjalnych wpływów na dostępność usługi wynikających z błędów zarządzania kluczami.

Ocena wymagań dotyczących klucza zarządzanego przez klienta i wdrożenie infrastruktury klucza:

• Oceń wymagania prawne, zgodności lub biznesowe, aby określić, które obciążenia wymagają kluczy zarządzanych przez klienta zamiast kluczy zarządzanych przez platformę. Typowe czynniki obejmują niezależność danych, wymagania dotyczące inspekcji lub zobowiązania umowne dotyczące bezpośredniego nadzoru kluczy.
• Aprowizuj Azure Key Vault (Standardowa lub Premium) lub Azure Key Vault zarządzany moduł HSM do przechowywania kluczy szyfrowania zarządzanych przez klienta i zarządzania nimi. Użyj zarządzanego modułu HSM w przypadku obciążeń wymagających zweryfikowanej ochrony sprzętowej ze standardem FIPS 140–3 na poziomie 3.
• Wygeneruj klucze szyfrowania w Azure Key Vault przy użyciu generowania kluczy lub importuj klucze z lokalnych modułów HSM przy użyciu Bring Own Key (BYOK) w celu zapewnienia maksymalnej przenośności i kontroli.

Skonfiguruj CMK i ustanów hierarchię kluczy:

• W przypadku wymagań dotyczących skrajnej kontroli zaimplementuj Double Key Encryption (DKE) gdzie poufne dokumenty wymagają dwóch kluczy do odszyfrowywania: jeden zarządzany przez Microsoft (Azure RMS) i drugi klucz zarządzany wyłącznie przez organizację lokalnie lub w własnej zewnętrznej usłudze zarządzania kluczami. W przypadku DKE Microsoft nie może odszyfrować danych, nawet jeśli zostanie do tego zmuszony przez proces prawny, ponieważ kontrolujesz drugi klucz wymagany do odszyfrowania.
• Skonfiguruj usługi Azure (Azure Storage, Azure SQL Database, Azure Cosmos DB, Azure Disk Encryption itp.), aby używać klucza cmK, odwołując się do identyfikatora URI klucza Key Vault. Włącz automatyczne zasady rotacji kluczy , aby zmniejszyć ręczne obciążenie operacyjne.
• Ustanów hierarchię klucza szyfrowania klucza (KEK) i klucza szyfrowania danych (DEK), gdzie klucz KEK (przechowywany w Key Vault) szyfruje klucz DEK (do używania przez usługi), minimalizując wpływ rotacji kluczy na dostępność usług.
• Udokumentowanie kluczowych procedur cyklu życia, w tym harmonogramów rotacji kluczy, procesów cofnięcia dla zagrożonych kluczy, przepływów pracy dotyczących wycofywania kluczy i procedur odzyskiwania po awarii. Integrowanie zarządzania kluczami z procesami zarządzania zmianami organizacji.

Uwaga: Klucze zarządzane przez klienta wymagają bieżących inwestycji operacyjnych, w tym zarządzania cyklem życia kluczy, administrowania kontrolą dostępu, monitorowania i planowania odzyskiwania po awarii. Upewnij się, że gotowość operacyjna jest zapewniona przed wdrożeniem kluczy zarządzanych przez klienta; niewłaściwe zarządzanie kluczami może spowodować niedostępność lub utratę danych.

Przykład implementacji

Regulowana instytucja finansowa wdrożyła klucze zarządzane przez klienta (CMK) w usługach Azure w celu spełnienia wymagań regulacyjnych dotyczących bezpośredniej kontroli kryptograficznej nad danymi handlowymi i rekordami finansowymi klientów.

Wyzwanie: Audytorzy regulacyjni wymagali wykazania kontroli kryptograficznej, w tym zarządzanie kluczami, autorytet rotacji oraz możliwość cofnięcia lub unieważnienia. Klucze zarządzane przez usługę nie mogą dostarczyć dowodów na cykl życia klucza kontrolowanego przez najemcę. Bez kluczy zarządzanych przez klienta organizacja nie mogła szybko odwołać dostępu podczas zdarzeń zabezpieczeń i nie mogła spełnić wymagań dotyczących niezależności danych dla wdrożeń regionalnych.

Podejście do rozwiązania:

• Zaimplementuj zarządzany moduł HSM usługi Azure Key Vault: Utwórz zarządzany moduł HSM (FIPS 140-3 poziom 3) z co najmniej 3 partycjami HSM, aby zapewnić wysoką dostępność. Aktywuj zarządzany moduł HSM przez wyeksportowanie domeny zabezpieczeń przy użyciu kluczy kworum (podzielonych na fragmenty kluczy przechowywanych w geograficznie rozproszonych offline magazynach), generuj klucze szyfrowania (RSA-4096 o nazwie KEK-Prod-2024) z operacjami klucza: Zawijanie klucza, Rozwijanie klucza, Szyfruj, Odszyfruj.
• Skonfiguruj klucze zarządzane przez klienta dla usług Azure: Dla usługi Azure Storage skonfiguruj konto magazynu do używania typu szyfrowania CMK, wybierz Key Vault z zarządzanym modułem HSM jako źródło klucza, włącz tożsamość zarządzaną przypisaną przez użytkownika z rolą Managed HSM Crypto Service Encryption User; dla usługi Azure SQL Database skonfiguruj bazę danych SQL do używania klucza zarządzanego przez klienta jako ochrony TDE, wybierz klucz z zarządzanego modułu HSM, włącz automatyczną rotację; w przypadku usługi Azure Cosmos DB włącz klucze zarządzane przez klienta dla konta Cosmos DB, wybierz klucz z zarządzanego modułu HSM, przyznaj dostęp tożsamości zarządzanej usługi Cosmos DB.
• Implementuj automatyczną rotację kluczy: Skonfiguruj zasady rotacji z częstotliwością 90 dni, włącz automatyczną rotację, skonfiguruj powiadomienie o wygaśnięciu (alert 7 dni przed wygaśnięciem), utwórz alert Azure Monitor dla metryki bliskości wygaśnięcia klucza, aby powiadomić zespół ds. zabezpieczeń.
• Włącz rejestrowanie inspekcji pod kątem zgodności: Włącz rejestrowanie diagnostyczne zarządzanego modułu HSM (dzienniki AuditEvent), wysyłaj dzienniki do obszaru roboczego Log Analytics z niezmiennym magazynem (90-dniowym przechowywaniem na dzienniki audytu odporne na manipulacje), oraz wysyłaj dzienniki dostępu kluczy do monitorowania operacji Szyfruj, Odszyfruj, ZwińKlucz i RozwińKlucz.
• Procedury cyklu życia klucza: Tworzenie awaryjnych runbooków unieważnienia (kroki unieważniania kluczy, kontakty do reagowania na zdarzenia, procedury odzyskiwania przy użyciu kluczy kworum domeny zabezpieczeń), testowanie runbooków kwartalnie poprzez ćwiczenia symulacyjne, integracja operacji CMK z przepływem pracy zatwierdzania zmian w zarządzaniu usługami IT.

pl-PL: Outcome: KEK RSA-4096 w zarządzanym module HSM szyfrują klucze szyfrowania na poziomie usługi dla Azure Storage, SQL Database i Cosmos DB. Kwartalna automatyczna rotacja minimalizuje przestój dzięki ponownemu szyfrowaniu tylko wzKaZaNych Kluczy SzyFRoWanIa. Kworum domeny zabezpieczeń zapewnia odzyskiwanie po awarii nawet w przypadku całkowitej awarii regionalnej.

Poziom krytyczny

Powinien mieć.

Mapowanie kontrolek

• Kontrole CIS w wersji 8.1: 3.11
• NIST SP 800-53 Rev.5: SC-12, SC-28
• PCI-DSS 4: 3.5.1, 3.6.1, 12.3.2
• NIST CSF v2.0: PR. DS-1, ID.AM-3
• ISO 27001:2022: A.8.24
• SOC 2: CC6.1

DP-6: Używanie bezpiecznego procesu zarządzania kluczami

Azure Policy: Zobacz Wbudowane definicje zasad Azure: DP-6.

Zasada zabezpieczeń

Zaimplementuj bezpieczne procesy zarządzania kluczami, które zarządzają pełnym cyklem życia klucza: generowanie, dystrybucja, magazyn, rotacja i odwoływanie. Używaj dedykowanych usług magazynu kluczy z silnymi mechanizmami kontroli dostępu, utrzymując standardy kryptograficzne, wymuszając rozdzielenie obowiązków oraz zapewniając regularną rotację i szybkie unieważnianie kluczy.

Ryzyko w celu ograniczenia ryzyka

Słabe lub niezarządzane cykle życia kluczy kryptograficznych obniżają poziom bezpieczeństwa zapewniany przez szyfrowanie i mogą prowadzić do systemowego naruszenia bezpieczeństwa. Bez generowania kluczy w sposób strukturalny, rotacji, ochrony i unieważniania:

• Rozprzestrzenienie się kluczy i sierocenie: Niesledzone klucze utrzymują się dłużej, niż wymaga tego biznes, zachowując niezamierzone prawo do odszyfrowywania.
• Nieaktualna kryptografia: Rzadko rotacja zwiększa narażenie na algorytmiczne obniżenie, siłę siłową lub postęp kanału bocznego.
• Nadużycie uprawnień: Brak rozdzielenia ról umożliwia administratorom zarówno zarządzanie kluczami, jak i korzystanie z nich, co umożliwia niewłaściwe wykorzystanie przez osobę z wewnątrz.
• Niewykryte naruszenie: Żadne monitorowanie integralności ani pochodzenie wersji nie ukrywa, czy klucze zostały złośliwie zastąpione.
• Odwołanie nie powiodło się: Reagowanie na zdarzenia nie może kryptograficznie zawierać dostępu do danych po podejrzeniu naruszenia.
• Niespójna hierarchia: Brak warstw KEK/DEK wielokrotnie zwiększa zasięg wybuchu rotacji i wydłuża czas przestoju operacyjnego.

Niedobór zarządzania kluczami zamienia szyfrowanie w kontrolę punktu w czasie, a nie trwałe ograniczenie ryzyka przed zmieniającymi się zagrożeniami.

MITRE ATT&CK

• Dostęp do poświadczeń (TA0006): poświadczenia z magazynów haseł (T1555) wyodrębnienie nieprawidłowo przechowywanego lub buforowanego materiału klucza lub prawidłowych kont (T1078) wykorzystujące szerokie role RBAC w zarządzaniu kluczami do bezprawnego uzyskiwania lub rotacji kluczy.
• Uchylanie się od obrony (TA0005): osłabianie szyfrowania (T1600) poprzez stosowanie przestarzałych algorytmów i niewystarczających rozmiarów kluczy, aby zmniejszyć siłę kryptograficzną.
• Wpływ (TA0040): niszczenie danych (T1485) wykonujące destrukcyjne przeczyszczanie lub błędnie używane zdarzenia odwołania.
• Wpływ (TA0040): manipulowanie danymi (T1565) zastępowanie lub zmienianie wersji kluczy w celu przekierowywania lub wyłączania przepływów szyfrowania.

DP-6.1: Ustanawianie zasad zarządzania kluczami i infrastruktury

Stwórz podstawy ładu do zarządzania kluczami kryptograficznymi, ustanawiając scentralizowany magazyn kluczy, definiując standardy kryptograficzne i dobierając właściwe poziomy ochrony na podstawie wrażliwości zadań. Wdróż Azure Key Vault jako centralne źródło prawdy dla operacji związanych z kluczami, wdrażając kompleksowe rejestrowanie audytów w celu śledzenia wszystkich dostępów do kluczy oraz zmian administracyjnych do celów zgodności i śledztwa.

Ustanów scentralizowaną infrastrukturę zarządzania kluczami:

• Użyj Azure Key Vault jako scentralizowanej usługi zarządzania kluczami kryptograficznymi, aby kontrolować pełny cykl życia klucza: generowanie, dystrybucja, magazyn, rotacja i odwoływanie.
• Definiowanie i wymuszanie zasad kluczy określających minimalne standardy kryptograficzne:
  • Typ klucza: RSA (zalecane: minimum 3072-bitowe lub 4096-bitowe) lub EC (krzywe P-256, P-384, P-521).
  • Kluczowe operacje: Ogranicz dozwolone operacje (szyfrowanie, odszyfrowywanie, podpisywanie, weryfikowanie, zawijanie, odpakowywanie) na podstawie zasad najniższych uprawnień.
  • Okres ważności: Ustaw daty aktywacji i wygaśnięcia, aby wymusić użycie klucza powiązanego z czasem.

Wybierz odpowiednią warstwę magazynu kluczy:

• Wybierz odpowiednią warstwę Key Vault na podstawie wymagań dotyczących zabezpieczeń i zgodności obciążenia:
  • Klucze chronione przez oprogramowanie (jednostki SKU w warstwie Standardowa i Premium): Zweryfikowano standard FIPS 140-2 poziom 1
  • Klucze chronione przez moduł HSM (SKU Premium): Zweryfikowano standard FIPS 140-2 poziom 2 (współużytkowane zaplecze HSM z wieloma dzierżawcami)
  • Zarządzany HSM: FIPS 140-3 poziom 3 zwalidowany (dedykowana jednotenantowa pula HSM)
• Dla wzmocnionego bezpieczeństwa użyj Azure Key Vault Managed HSM dla jednolitych dzierżaw, ochrony HSM zatwierdzonej na poziomie FIPS 140-3, Poziom 3. Zarządzany moduł HSM obsługuje domenę kryptograficzną na potrzeby tworzenia kopii zapasowych i odzyskiwania po awarii.
• Skonfiguruj logowanie w Azure Key Vault i kierowanie dzienników do Azure Monitor lub Microsoft Sentinel w celu śledzenia dostępu do kluczy, zdarzeń rotacji i operacji administracyjnych na cele audytu i zgodności.

DP-6.2: Implementowanie automatyzacji cyklu życia klucza

Automatyzowanie rotacji kluczy i ustanawianie kluczowych hierarchii w celu zmniejszenia obciążenia operacyjnego, zminimalizowania błędów ludzkich i umożliwienia szybkiego zastąpienia klucza bez przerw w działaniu usługi. Zaimplementuj wzorce KEK/DEK, które umożliwiają wydajną rotację przez ponowne szyfrowanie małych pakietów kluczy, a nie całych zestawów danych, i integrowanie procedur odzyskiwania po awarii w celu zachowania kluczowej dostępności w regionalnych awariach lub katastroficznych zdarzeniach.

Zaimplementuj automatyczną rotację kluczy:

• Zaimplementuj automatyczne polityki rotacji kluczy w Azure Key Vault.
  • Skonfiguruj częstotliwość rotacji na podstawie wymagań dotyczących zgodności (typowe interwały: 90 dni, 180 dni lub rocznie).
  • Włącz powiadomienia o rotacji, aby powiadamiać zespoły operacyjne, zanim klucz wygaśnie.
  • Skonfiguruj automatyczną rotację, aby generować nowe wersje kluczy bez ręcznej interwencji.

Zdefiniuj hierarchię kluczy i BYOK:

• Ustanów hierarchię kluczy oddzielającą klucze szyfrowania kluczy (KEK) i klucze szyfrowania danych (DEK):
  • Przechowuj klucze KEK w Azure Key Vault z ograniczoną kontrolą dostępu.
  • Generowanie kluczy szyfrowania danych (DEK) na poziomie usługi, zaszyfrowanych przez klucze szyfrowania kluczy (KEK), minimalizując skalę oddziaływania rotacji kluczy.
  • Rotacja klucza KEK wymaga tylko ponownego szyfrowania zestawów szyfrowania (nie całych zestawów danych), co umożliwia wydajną rotację kluczy z zerowym przestojem.
• W przypadku scenariuszy Bring Your Own Key (BYOK) wygeneruj klucze w lokalnych modułach HSM zgodnych z FIPS 140-2 poziom 2+ i używaj mechanizmu klucza transferu BYOK, aby bezpiecznie importować klucze do Azure Key Vault lub Zarządzane HSM, zachowując kryptograficzne dowody pochodzenia i nadzoru nad kluczami.

Implementowanie procedur odzyskiwania po awarii:

• Tworzenie magazynów kluczy replikowanych geograficznie w regionach pomocniczych.
• Tworzenie kopii zapasowych i przywracanie kluczy w celu zachowania kluczowej dostępności w różnych regionach.
• Dokumentowanie i testowanie procedur odzyskiwania po awarii z określonymi celami RTO (ocele czasu odzyskiwania) i RPO (ocele punktu odzyskiwania danych).

DP-6.3: Wymuszanie rozdzielenia obowiązków na potrzeby dostępu do klucza

Zapobiegaj zagrożeniom poufnym i nadużyciom uprawnień, oddzielając role zarządzania kluczami od ról operacji kryptograficznych, zapewniając, że żadna pojedyncza tożsamość nie może tworzyć kluczy i używać ich do szyfrowania danych lub odszyfrowywania. Zaimplementuj ciągłe monitorowanie, aby wykrywać nietypowe wzorce użycia kluczy i zarządzać kompleksowymi rejestrami kluczy, które umożliwiają szybką ocenę wpływu podczas incydentów bezpieczeństwa lub audytów zgodności.

Wymuszanie rozdzielenia obowiązków:

• Zaimplementuj kontrolę dostępu opartą na rolach (RBAC) lub zasady dostępu, aby wymusić rozdzielenie obowiązków:
  • Oddzielne role dla administratorów kluczy (którzy mogą tworzyć/obracać/usuwać klucze, ale nie mogą wykonywać operacji kryptograficznych).
  • Oddzielne role dla kluczowych użytkowników (którzy mogą wykonywać operacje szyfrowania/odszyfrowywania, ale nie mogą zarządzać kluczami).
  • Przykładowe role: Key Vault Crypto Officer (administratorzy), Key Vault Crypto User (aplikacje/użytkownicy).
• Sprawdź, czy żadna pojedyncza tożsamość nie ma dostępu zarówno do klucza administracyjnego, jak i operacyjnego, aby zapobiec nadużyciom uprawnień.

Monitorowanie dostępu do kluczy i utrzymywanie spisu:

• Integrowanie monitorowania dostępu do kluczy z Microsoft Sentinel w celu wykrywania anomalii.
  • Nietypowe wzorce dostępu klucza (dostęp z nieznanych adresów IP lub regionów).
  • Operacje klucza zbiorczego (nadmierne operacje w krótkim czasie).
  • Zmiany administracyjne poza godzinami pracy (usunięcie klucza lub rotacja poza godzinami pracy).
• Utrzymaj śledzenie inwentarza kluczy z uwzględnieniem nazwy klucza, przeznaczenia, harmonogramu rotacji i usług zależnych. Regularnie przeglądaj spis podczas przeglądów zabezpieczeń.

Przykład implementacji

Dostawca usług SaaS w sektorze opieki zdrowotnej scentralizował zarządzanie kluczami kryptograficznymi przy użyciu Azure Key Vault w wersji Premium SKU z kluczami chronionymi przez moduł HSM do szyfrowania danych PHI na swojej platformie wielodostępnej.

Wyzwanie: Pofragmentowane zarządzanie kluczami w zespołach programistycznych doprowadziło do rozrostu kluczy, niespójnych praktyk ich rotacji oraz trudności ze śledzeniem użycia kluczy podczas incydentów bezpieczeństwa. Nadmiernie szerokie uprawnienia RBAC umożliwiły administratorom zarówno zarządzanie kluczami, jak i korzystanie z nich, co stwarza wewnętrzne zagrożenie. Bez zautomatyzowanej rotacji i rozdzielenia obowiązków organizacja napotkała rozszerzone okna zagrożenia kompromitacją kluczy i niepowodzenia w spełnianiu wymogów audytowych.

Podejście do rozwiązania:

• Provision Azure Key Vault Premium z kluczami chronionymi przez moduł HSM: Utwórz Azure Key Vault z warstwą Premium w celu obsługi kluczy chronionych przez moduł HSM. Włącz ochronę przed wyczyszczeniem, aby zapobiec trwałemu usunięciu w okresie przechowywania. Włącz usuwanie miękkie z 90-dniowym okresem przechowywania, aby umożliwić odzyskiwanie przypadkowo usuniętych kluczy. Generuj klucze szyfrowania RSA-3072 chronione przez moduł HSM (KEK-PHI-Prod) przy użyciu sprzętowego rodzaju klucza.
• Wdrażaj zasady automatycznej rotacji kluczy: Skonfiguruj zasady rotacji z częstotliwością 180 dni, włącz automatyczną rotację i ustaw powiadomienie 30 dni przed wygaśnięciem, utwórz grupy działań w Azure Monitor, aby powiadomić zespół ds. operacji zabezpieczeń, gdy klucze zbliżają się do wygaśnięcia, skonfiguruj akcję rotacji, aby automatycznie generować nowe wersje kluczy.
• Konfiguruj podział obowiązków RBAC: Przypisz rolę Key Vault Crypto Officer członkom zespołu ds. zabezpieczeń (uprawnienia: zarządzanie cyklem życia klucza, ale brak uprawnień do wykonywania operacji szyfrowania/odszyfrowywania), przypisz rolę Crypto User Key Vault tożsamościom zarządzanym przez aplikację (uprawnienia: wykonywanie operacji szyfrowania/odszyfrowywania jedynie z brakiem uprawnień do zarządzania kluczami), weryfikowanie podziału obowiązków przez zapewnienie, że żadna tożsamość nie posiada jednocześnie ról Crypto Officer i Crypto User.
• Hierarchia KEK/DEK dla szybkiej rotacji kluczy: Generowanie kluczy szyfrowania danych na poziomie aplikacji (DEK) w kodzie aplikacji (klucze AES-256) w celu szyfrowania danych pacjentów, przechowywanie zaszyfrowanych kluczy DEK wraz z zaszyfrowanymi danymi, używanie klucza KEK z Key Vault do opakowywania/szyfrowania kluczy DEK za pomocą operacji WrapKey, pobieranie i odpakowywanie kluczy DEK przy użyciu operacji UnwrapKey podczas odszyfrowywania danych pacjentów, korzyść: rotowanie klucza KEK wymaga tylko ponownego szyfrowania kluczy DEK zamiast całej bazy danych pacjentów.
• Integracja dzienników Key Vault z Microsoft Sentinel: Włącz ustawienia diagnostyczne dla Key Vault i wysyłaj dzienniki do obszaru roboczego Log Analytics, twórz reguły analizy usługi Sentinel w celu wykrywania nietypowych wzorców dostępu do kluczy, operacji zbiorczych, zmian administracyjnych poza godzinami pracy.
• Bring Your Own Key (BYOK) przesył z lokalnego modułu HSM: Pobierz klucz transferu BYOK z Key Vault, wyeksportuj klucz z lokalnego modułu HSM opakowany przy użyciu klucza publicznego BYOK Key Vault, zachowaj kryptograficzny dowód pochodzenia kluczy, zaimportuj opakowany klucz do Key Vault, gdzie jest chroniony przez moduł HSM bez ujawnienia tekstu jawnego.

Wynik: Klucze RSA-3072 obracają się co 180 dni z automatycznymi powiadomieniami. Separacja kontroli dostępu opartej na rolach uniemożliwia nadużycie uprawnień. Hierarchia KEK/DEK umożliwia szybką rotację przez ponowne szyfrowanie tylko DEK. Miękkie usunięcie pozwala odzyskać przypadkowo usunięte klucze. Microsoft Sentinel wykrywa anomalie, takie jak nieznany dostęp do adresu IP lub modyfikacje poza godzinami pracy.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• Kontrole CIS w wersji 8.1: N/A
• NIST SP 800-53 Rev.5: IA-5, SC-12, SC-28
• PCI-DSS 4: 3.6.1, 8.3.2
• NIST CSF v2.0: PR.AC-1, PR.DS-1
• ISO 27001:2022: A.8.24, A.8.3
• SOC 2: CC6.1, CC6.2

DP-7: Używanie bezpiecznego procesu zarządzania certyfikatami

Azure Policy: Zobacz wbudowane definicje zasad Azure: DP-7.

Zasada zabezpieczeń

Zarządzanie cyklami życia certyfikatów za pomocą scentralizowanych procesów obejmujących spis, automatyczne odnawianie, silne standardy kryptograficzne i terminowe odwoływanie. Upewnij się, że certyfikaty dla usług krytycznych są śledzone, monitorowane i odnawiane przed wygaśnięciem, aby zapobiec przerwom w działaniu usługi i utrzymywać bezpieczną zaszyfrowaną komunikację.

Ryzyko w celu ograniczenia ryzyka

Źle zarządzane cykle życia certyfikatów powodują awarie usługi, osłabiają zaszyfrowane kanały i umożliwiają personifikację. Bez scentralizowanego spisu, wymuszania zasad i automatycznego odnawiania:

• Nieoczekiwane wygaśnięcia: Wygasłe certyfikaty wyzwalają awarie produkcyjne, przerywające działanie interfejsów API, federację tożsamości czy ścieżki zaufania klienta.
• Słaba trwałość kryptografii: Starsze rozmiary kluczy/algorytmy podpisu (np. SHA-1, RSA < 2048) pozostają w użyciu poza wycofaniem.
• Nadużycia z symbolami wieloznacznymi i certyfikatami z podpisem własnym: Certyfikaty z podpisem własnym o szerokim zakresie lub brakujące zarządzanie umożliwiają poprzeczną personifikację i ryzyko degradacji TLS.
• Niewykryte naruszenie: Skradzione klucze prywatne umożliwiają transparent man-in-the-middle lub odszyfrowywanie ruchu do czasu rotacji.
• Certyfikaty cieni: Niezatwierdzone wystawianie poza zatwierdzonymi urzędami certyfikacji fragmentuje zarządzanie i zwiększa obszary niewiedzy w odniesieniu do odwołań.
• Błędy ręcznego odnawiania: Niespójne sekwencjonowanie zastępcze powoduje niezgodność łańcucha zaufania i częściowy dryf środowiska.

Brak wydajnego zarządzania certyfikatami obniża bezpieczeństwo zaszyfrowane i wprowadza zarówno niezawodność, jak i niestabilność zabezpieczeń w usługach krytycznych.

MITRE ATT&CK

• Uchylanie się od obrony (TA0005): obejście kontroli zaufania (T1553), wydawanie lub wprowadzanie fałszywych/nieautoryzowanych certyfikatów, aby ominąć weryfikację.
• Tworzenie zasobów (TA0042): tworzenie możliwości (T1587) tworzenia certyfikatów lub narzędzi dla przyszłych faz włamań.
• Uchylanie się od obrony (TA0005): osłabianie szyfrowania (T1600) poprzez kontynuowanie korzystania z przestarzałych algorytmów podpisu, co zmniejsza pewność weryfikacji.
• Dostęp poświadczeń (TA0006): niechronione poświadczenia (T1552) wyodrębnianie kluczy prywatnych z niezabezpieczonych magazynów plików lub pamięci procesu.
• Trwałość (TA0003): modyfikowanie procesu uwierzytelniania (T1556), zmieniając przepływy uwierzytelniania oparte na certyfikatach w celu integracji dostępu o długim czasie trwania.

DP-7.1: Ustanowienie zasad certyfikatów i integracji urzędu certyfikacji

Zdefiniuj standardy zarządzania certyfikatami i zintegruj zaufane autorytety certyfikacyjne, aby zapewnić jednolitą jakość kryptograficzną i automatyczne wystawianie w całej infrastrukturze. Ustanów zasady, które wymuszają nowoczesne rozmiary kluczy, algorytmy podpisów i okresy ważności, eliminując ryzykowne praktyki, takie jak certyfikaty z podpisem własnym i certyfikaty wieloznaczne, które rozszerzają powierzchnie ataków w przypadku naruszenia zabezpieczeń kluczy prywatnych.

Ustanów infrastrukturę zarządzania certyfikatami:

• Użyj Azure Key Vault aby centralnie zarządzać pełnym cyklem życia certyfikatu: tworzenie, importowanie, odnawianie, rotacja, odwoływanie i bezpieczne usuwanie.
• Zdefiniuj zasady dotyczące certyfikatów w Azure Key Vault w celu wymuszania standardów zabezpieczeń organizacji.
  • Typ i rozmiar klucza: Minimum RSA 2048-bitowe (zalecane: 3072-bitowe lub 4096-bitowe dla certyfikatów długotrwałych); EC P-256 lub nowszy dla certyfikatów krzywej eliptycznej.
  • Algorytm podpisu: SHA-256 lub silniejszy (zakaz SHA-1 i MD5).
  • Okres ważności: Maksymalnie 397 dni dla publicznych certyfikatów TLS (zgodnie z wymaganiami punktu odniesienia dla forum przeglądarki/urzędu certyfikacji); krótsze czasy trwania (90 dni) zalecane w przypadku zmniejszonej ekspozycji.
  • Urząd certyfikacji: Używaj tylko zatwierdzonych, zintegrowanych urzędów certyfikacji (DigiCert, GlobalSign) lub prywatnego urzędu certyfikacji organizacji.

Integrowanie urzędów certyfikacji:

• Użyj partnerskich urzędów certyfikacji zintegrowanych z Azure Key Vault dla publicznych certyfikatów TLS/SSL:
  • DigiCert: Certyfikaty TLS/SSL zweryfikowane przez organizację
  • GlobalSign: Certyfikaty TLS/SSL zweryfikowane przez organizację
• W przypadku usług prywatnych/wewnętrznych zintegruj wewnętrzny urząd certyfikacji organizacji (np. usługi certyfikatów Active Directory — ADCS) z Azure Key Vault w celu automatycznego wystawiania certyfikatów.
• Unikaj certyfikatów z podpisem własnym i certyfikatów wieloznacznych w środowiskach produkcyjnych:
  • Certyfikaty z podpisem własnym: Brak weryfikacji przez podmiot trzeci, nie można odwołać za pomocą publicznej listy CRL/OCSP i są odrzucane przez nowoczesne przeglądarki i klientów.
  • Certyfikaty z symbolami wieloznacznymi: Szeroki zakres zwiększa ryzyko w przypadku naruszenia zabezpieczeń; Zamiast tego należy używać certyfikatów alternatywnej nazwy podmiotu (SAN) z jawnymi nazwami FQDN.

Note: W przypadku prostych scenariuszy można użyć certyfikatów zarządzanych Azure App Service (bezpłatne, automatycznie odnawiane certyfikaty dla domen niestandardowych).

DP-7.2: Implementowanie automatycznego odnawiania certyfikatów

Wyeliminuj awarie usług spowodowane wygasłymi certyfikatami, automatyzując przepływy pracy dotyczące odnawiania, które są uruchamiane znacznie przed wygaśnięciem i bezproblemowo aktualizują certyfikaty w usługach zależnych bez ręcznej interwencji. Skonfiguruj usługi Azure, aby automatycznie pobierać odnowione certyfikaty z Key Vault przy użyciu tożsamości zarządzanych, zmniejszając trud operacyjny i eliminując ryzyko zapomnianych ręcznych odnawiań podczas urlopów lub przejścia pracowników.

Konfigurowanie automatycznego odnawiania:

• Włącz automatyczne odnawianie certyfikatu w Azure Key Vault przez skonfigurowanie akcji związanych z czasem życia, aby wyzwolić odnowienie przy określonym procencie czasu życia certyfikatu.
  • Zalecany wyzwalacz: 80–90% okresu ważności (np. ~318 dni dla certyfikatu 397-dniowego).
  • Akcja: Automatyczne odnawianie (Key Vault automatycznie żąda przedłużenia certyfikatu z urzędu certyfikacji bez potrzeby ręcznej interwencji).
• Skonfiguruj kontakty powiadomień, aby powiadamiać administratorów o nadchodzącym wygaśnięciu certyfikatów zanim nastąpi automatyczne odnowienie.

Włącz automatyczne powiązanie certyfikatu:

• W przypadku usług Azure, które obsługują automatyczną rotację certyfikatów (Azure App Service, Azure Application Gateway, Azure Front Door), skonfiguruj te usługi tak, aby automatycznie pobierały zaktualizowane certyfikaty z Key Vault przy użyciu tożsamości zarządzanych lub jednostek usługi z odpowiednimi zasadami dostępu Key Vault:
  • Usługi Azure będą automatycznie powiązywać nowe wersje certyfikatów po ich odnowieniu (zazwyczaj w ciągu 24 godzin, nie wymagają ponownego uruchomienia).
• W przypadku aplikacji, które nie mogą automatycznie korzystać z certyfikatów Key Vault, zaimplementuj ręczne przepływy pracy rotacji certyfikatów z operacyjnymi runbookami i alertami monitorowania, aby zapobiec awariom związanym z wygaśnięciem.
• Utrzymuj spis wszystkich certyfikatów w Azure Key Vault, śledząc nazwę certyfikatu, cel jego przeznaczenia, datę wygaśnięcia, usługi zależne oraz stan odnowienia.

DP-7.3: Monitorowanie cyklu życia certyfikatu i obsługa odwołania

Zachowaj ciągły wgląd w kondycję certyfikatów za pomocą zautomatyzowanego monitorowania, zapytań inwentarza i pulpitów nawigacyjnych, które wyświetlają certyfikaty zbliżające się do wygaśnięcia, używające przestarzałej kryptografii lub nie spełniają wymogów zarządzania. Ustanów procedury szybkiego odwoływania skompromitowanych certyfikatów i integruj się z branżową inteligencją zagrożeń, aby proaktywnie blokować certyfikaty wystawione przez skompromitowane urzędy certyfikacji, zanim umożliwią przeprowadzenie ataków typu man-in-the-middle.

Konfigurowanie monitorowania i zgłaszania alertów:

• Skonfiguruj alerty Azure Monitor dla zdarzeń wygaśnięcia certyfikatu:
  • Utwórz powiadomienia na 30 dni przed wygaśnięciem (powiadomienie ostrzegawcze).
  • Utwórz alerty na 7 dni przed wygaśnięciem (alert krytyczny z eskalacją do zespołu ds. bezpieczeństwa).

Zachowaj inwentarz certyfikatów i pulpity nawigacyjne:

• Użyj Azure Resource Graph, aby wykonywać zapytania dotyczące spisu certyfikatów:
  • Wykonywanie zapytań o certyfikaty zbliżające się do wygaśnięcia (w ciągu 30/60/90 dni).
  • Wykonywanie zapytań względem certyfikatów z podpisem własnym.
  • Wykonywanie zapytań o certyfikaty przy użyciu przestarzałych algorytmów (np. SHA-1).
• Tworzenie pulpitów nawigacyjnych inspekcji certyfikatów (np. Power BI) przy użyciu wizualizacji:
  • Harmonogram wygaśnięcia certyfikatów według przedziałów czasowych.
  • Liczba certyfikatów z podpisem własnym według grupy zasobów.
  • Certyfikaty korzystające ze przestarzałych standardów kryptograficznych.
• Regularnie przeglądaj pulpity nawigacyjne inspekcji certyfikatów podczas spotkań przeglądu zabezpieczeń (zalecane: co kwartał).

Ustanawianie procedur odwołania:

• Ustanów procedury odwołania certyfikatów dla certyfikatów zagrożonych lub wycofanych:
  • Proces odwoływania dokumentów (wyłącz certyfikat w Key Vault, powiadom usługi zależne).
  • Utrzymanie runbooków reagowania na zdarzenia dla scenariuszy naruszenia zabezpieczeń certyfikatów.
  • Monitoruj zalecenia branżowe pod kątem certyfikatów głównych lub pośrednich urzędów certyfikacji i blokuj je szybko.

Przykład implementacji

Przedsiębiorstwo z ponad 200 publicznymi aplikacjami internetowymi scentralizowało zarządzanie cyklem życia certyfikatów przy użyciu Azure Key Vault zintegrowanego z firmą DigiCert jako urzędem certyfikacji.

Wyzwanie: Ręczne procesy odnawiania certyfikatów spowodowały wiele przestojów produkcyjnych, gdy certyfikaty wygasły nieoczekiwanie. Certyfikaty wieloznaczne zwiększyły ryzyko szerokiego zasięgu naruszenia, gdy naruszono bezpieczeństwo kluczy prywatnych. Pofragmentowane zarządzanie certyfikatami w zespołach spowodowało cienie certyfikatów, niespójne standardy kryptograficzne oraz opóźnioną rewokację podczas incydentów bezpieczeństwa. Bez zautomatyzowanego odnawiania i scentralizowanej inwentaryzacji organizacja napotkała niedostosowania zgodności i zakłócenia usług.

Podejście do rozwiązania:

• Konfiguruj integrację urzędu certyfikacji z Azure Key Vault: Dodaj DigiCert (lub inny partnerski urząd certyfikacji) do Key Vault z poświadczeniami API na potrzeby zautomatyzowanych żądań certyfikatów.
• Utwórz zasady certyfikatów wymuszające standardy zabezpieczeń: Definiowanie zasad certyfikatu przy użyciu nazwy certyfikatu (www-contoso-com-2024), wystawcy (DigiCert), podmiotu (CN=www.contoso.com), nazw DNS (SAN: www.contoso.com, api.contoso.com, portal.contoso.com — unikaj certyfikatów wieloznacznych), typu klucza (RSA 4096 bitów), algorytmu podpisu (SHA-256), okresu ważności (maksymalnie 397 dni na punkt odniesienia urzędu certyfikacji/forum przeglądarki), skonfiguruj akcję okresu istnienia automatycznego odnawiania (wyzwalacz ustawiony na 80% okresu istnienia certyfikatu około 318 dni dla 397-dniowego certyfikatu), akcja: automatyczne odnawianie (Key Vault żąda odnowienia od firmy DigiCert bez interwencji ręcznej).
• Konfiguruj automatyczne powiązanie certyfikatu dla usług Azure: Dla Azure App Service zaimportuj certyfikat z Key Vault, przypisz zarządzaną tożsamość przypisaną przez użytkownika z rolą Użytkownik tajemnic Key Vault, włącz automatyczne aktualizacje certyfikatów (usługa App Service wiąże nową wersję certyfikatu w ciągu 24 godzin po odnowieniu, bez konieczności ponownego uruchamiania); dla Azure Application Gateway skonfiguruj odbiornik do pobierania certyfikatu z Key Vault, przypisz zarządzaną tożsamość przypisaną przez użytkownika z rolami Użytkownik tajemnic Key Vault i Użytkownik certyfikatów, usługa Application Gateway automatycznie pobiera zaktualizowany certyfikat po odnowieniu przez Key Vault.
• Konfiguruj alerty wygasania certyfikatów: Utwórz dwie reguły alertów w Azure Monitor — 30-dniowe ostrzeżenie o wygaśnięciu (wyślij powiadomienie do kanału inżynieryjnego platformy Slack), 7-dniowy alert krytyczny wygaśnięcia (otwórz bilet Jira na potrzeby ręcznego przeglądu i wysyłania wiadomości e-mail do zespołu ds. zabezpieczeń).
• Eliminuj wieloznaczne certyfikaty na korzyść certyfikatów SAN: Przeprowadź inspekcję istniejących certyfikatów wieloznacznych (*.contoso.com) w Key Vault, zastąp je certyfikatami SAN, które zawierają jawne nazwy DNS (www.contoso.com, api.contoso.com), korzyść: jeśli naruszono bezpieczeństwo klucza prywatnego, dotyczy to tylko wymienionych nazw FQDN (a nie wszystkich domen podrzędnych).
• Monitorowanie wygaśnięcia certyfikatu: Użyj Azure Resource Graph do wykonywania zapytań dotyczących spisu certyfikatów i identyfikowania certyfikatów zbliżających się do wygaśnięcia (w ciągu 30 dni), certyfikatów z podpisem własnym lub certyfikatów przy użyciu przestarzałego algorytmu podpisu SHA-1, przejrzyj pulpit nawigacyjny co kwartał podczas spotkań przeglądu zabezpieczeń.

Wynik: Automatyczne odnawianie certyfikatów jest inicjowane w 80% okresu ważności. Azure App Service i Application Gateway pobierają zaktualizowane certyfikaty w ciągu 24 godzin za pośrednictwem tożsamości zarządzanych (nie jest wymagane ponowne uruchomienie). Azure Monitor alerty powiadamiają inżynierię platformy przed wygaśnięciem. Certyfikaty SAN zastępują certyfikaty wieloznaczne, zmniejszając zasięg skutków naruszenia bezpieczeństwa.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• Kontrole CIS w wersji 8.1: N/A
• NIST SP 800-53 Rev.5: IA-5, SC-12, SC-17
• PCI-DSS 4: 3.6.1, 8.3.2
• NIST CSF v2.0: PR. AC-1, ID.AM-3
• ISO 27001:2022: A.8.3
• SOC 2: CC6.1, CC6.2

DP-8: Zapewnianie zabezpieczeń klucza i repozytorium certyfikatów

Azure Policy: Zobacz wbudowane definicje zasad Azure: DP-8.

Zasada zabezpieczeń

Zabezpieczanie usług magazynu kluczy za pomocą mechanizmów kontroli ochrony w głębi systemu: dostęp z najmniejszymi uprawnieniami, izolacja sieci, kompleksowe rejestrowanie i monitorowanie, możliwości tworzenia kopii zapasowych i odzyskiwania oraz ochrona oparta na module HSM, jeśli jest to wymagane. Magazyny kluczy to krytyczna infrastruktura, która chroni klucze kryptograficzne i certyfikaty używane do szyfrowania i uwierzytelniania.

Ryzyko w celu ograniczenia ryzyka

Naruszenie klucza i repozytorium certyfikatów unieważnia szyfrowanie na wcześniejszym etapie, podpisywanie i zapewnienia tożsamości. Bez wzmocnionego dostępu do skarbca, monitorowania i izolacji:

• Eksfiltracja kluczy: Skradzione pliki KEKs/materiał HSM umożliwiają zbiorcze odszyfrowywanie przechowywanych danych i przechwytywania ruchu.
• Dostęp administracyjny w tle: Zbyt szeroka kontrola dostępu oparta na rolach lub błędna konfiguracja zasad umożliwia nielegalne eksportowanie, czyszczenie lub wycofywanie wersji.
• Dyskretne manipulowanie: Zamiana złośliwego klucza umożliwia przezroczyste zastępowanie kodu/podpisów typu man-in-the-middle lub sfałszowanego.
• Narażenie na sieć: Nadużycie publicznego punktu końcowego (wypychanie poświadczeń, sondowanie interfejsu API) zwiększa obszar ataków w przypadku ataku siłowego lub ponownego odtwarzania tokenu.
• Przypadkowe akcje destruktywne: Brak ochrony przed miękkim usuwaniem i usuwaniem prowadzi do nieodwracalnej utraty danych kryptograficznych.
• Niewystarczający ślad audytowy: Brak niezmiennych dzienników pogarsza reagowanie na incydenty i potrzeby dowodowe organów regulacyjnych.
• Niesegmentowana dzierżawa: Współmiestrowane klucze aplikacji rozszerzają promień ruchu bocznego po naruszeniu zabezpieczeń jednej tożsamości.

Słabe strony repozytorium szybko rozprzestrzeniają się do systemowych naruszeń poufności, integralności i dostępności w obciążeniach zależnych.

MITRE ATT&CK

• Dostęp do poświadczeń (TA0006): niechronione poświadczenia lub magazyny poświadczeń (T1552 / T1555) uzyskane wskutek niepoprawnie skonfigurowanej roli w sejfie lub zasad sieciowych.
• Uchylanie się od obrony (TA0005): pośrednik atakujący (T1557) przechwytywanie ruchu kierowanego do magazynu na potrzeby przechwytywania klucza/certyfikatu lub osłabienie szyfrowania (T1600) zastępując silne klucze danymi kontrolowanymi przez atakującego.
• Eskalacja uprawnień (TA0004): prawidłowe konta (T1078) wykorzystujące zbyt szerokie role operatora sejfu w celu wyliczania i zmieniania tajemnic.
• Wpływ (TA0040): niszczenie danych/ hamowanie odzyskiwania (T1485 / T1490) wykonujące destrukcyjne sekwencje przeczyszczania, które uniemożliwiają przywrócenie.

DP-8.1: Implementowanie kontroli dostępu dla Key Vault

Chroń podstawy kryptograficzne infrastruktury, wymuszając ścisłe mechanizmy kontroli dostępu opartej na tożsamościach, które uniemożliwiają nieautoryzowany dostęp do klucza, ograniczają uprawnienia administracyjne do uzasadnionych okien czasowych i eliminują przechowywanie poświadczeń za pośrednictwem tożsamości zarządzanych. Wprowadź rozdzielenie obowiązków między administratorami kluczy a użytkownikami kluczy, aby zapobiec możliwości zarządzania i eksploatacji materiałów kryptograficznych przez jedną skompromitowaną tożsamość.

Implementowanie RBAC i rozdzielenie obowiązków:

• Zaimplementuj Azure RBAC dla Key Vault aby wymusić kontrolę dostępu z najniższymi uprawnieniami:
  • W przypadku Azure Key Vault Managed HSM: użyj lokalnej kontroli dostępu opartej na rolach na poziomie indywidualnego klucza, tajemnicy i certyfikatu z wbudowanymi rolami (Crypto Officer, Crypto User, Crypto Auditor).
  • W przypadku Azure Key Vault Standard/Premium: Tworzenie dedykowanych magazynów dla aplikacji lub środowiska w celu wymuszania separacji logicznej i przypisywania ról RBAC (Key Vault Administrator, Secrets Officer, Certificate Officer) z zakresem specyficznym dla aplikacji.
• Wymuszanie rozdzielenia obowiązków: oddzielne role do zarządzania kluczami (którzy mogą tworzyć/obracać klucze) z operacji kryptograficznych (którzy mogą używać kluczy do szyfrowania/odszyfrowywania).

Używaj zarządzanych tożsamości i dostępu JIT:

• Użyj tożsamości zarządzanych dla zasobów Azure (App Services, maszyn wirtualnych, Azure Functions itp.), aby uzyskać dostęp do Key Vault zamiast przechowywać poświadczenia w kodzie aplikacji lub plikach konfiguracji. Tożsamości zarządzane eliminują złożoność przechowywania poświadczeń i rotacji.
• Zaimplementuj Microsoft Entra Privileged Identity Management (PIM) aby uzyskać dostęp administracyjny just in time do Key Vault:
  • Konfiguruj przypisania kwalifikujące się dla roli administratora Key Vault (nie przypisań na stałe).
  • Wymagaj uzasadnienia, uwierzytelnianie wieloskładnikowe i zatwierdzenie aktywacji.
  • Ustaw maksymalny czas trwania aktywacji (np. 8 godzin).
  • Przeprowadzanie regularnych przeglądów dostępu w celu odwołania niepotrzebnych stałych uprawnień.

DP-8.2: Wzmacnianie zabezpieczeń sieci Key Vault

Wyłącz narażone na ataki powierzchnie dostępne z Internetu, kierując cały dostęp do Key Vault za pośrednictwem prywatnych punktów końcowych w sieciach wirtualnych, uniemożliwiając ataki brute force, wypychanie poświadczeń i rekonesans z zewnętrznych zagrożeń. Jeśli dostęp publiczny jest nieunikniony w scenariuszach ciągłej integracji/ciągłego wdrażania, zaimplementuj ścisłe listy dozwolonych adresów IP i reguły zapory sieciowej, aby utworzyć najmniejsze możliwe okno ekspozycji.

Wdróż Private Link i skonfiguruj zaporę sieciową:

• Zabezpiecz dostęp sieciowy do Azure Key Vault przy użyciu Azure Private Link, aby nawiązać łączność prywatną z sieciami wirtualnymi, nie ujawniając Key Vault publicznemu internetowi.
• Skonfiguruj zaporę Key Vault aby ograniczyć dostęp do określonych zakresów adresów IP lub sieci wirtualnych w scenariuszach, w których Private Link nie jest możliwe:
  • Wyłącz dostęp publiczny, jeśli to możliwe (Key Vault dostępne tylko za pośrednictwem prywatnego punktu końcowego).
  • Jeśli wymagany jest dostęp publiczny (np. w przypadku potoków CI/CD), zezwól na dostęp z wybranych sieci tylko przy użyciu wąskich list dozwolonych adresów IP.
• Tworzenie i łączenie prywatnych stref DNS (np privatelink.vaultcore.azure.net. ) z sieciami wirtualnymi w celu zapewnienia prawidłowego rozpoznawania nazw DNS dla prywatnych punktów końcowych.

DP-8.3: Włącz ochronę i monitorowanie Key Vault

Zaimplementuj ochronę w głąb, która uniemożliwia nieodwracalną utratę danych kryptograficznych poprzez miękkie usuwanie oraz ochronę przed trwałym usunięciem danych, przy użyciu kluczy wspieranych przez moduł HSM na potrzeby obciążeń produkcyjnych wymagających zabezpieczeń, które spełniają standard FIPS. Wdróż kompleksowe monitorowanie przy użyciu Microsoft Defender for Key Vault i Microsoft Sentinel, aby wykrywać nietypowe wzorce dostępu, nietypowe operacje kluczy i anomaliach administracyjnych, które wskazują na naruszenie zabezpieczeń, zagrożenia wewnętrzne lub działania rekonesansowe ukierunkowane na infrastrukturę kryptograficzną.

Włącz miękkie usuwanie i ochronę przed czyszczeniem:

• Włącz soft delete i purge protection na wszystkich Azure Key Vault, aby zapobiec przypadkowemu lub złośliwemu usunięciu kluczy, wpisów tajnych i certyfikatów:
  • Usuwanie miękkie umożliwia odzyskiwanie w okresie przechowywania (domyślnie: 90 dni).
  • Ochrona przed przeczyszczaniem uniemożliwia trwałe usunięcie w okresie przechowywania.
  • Wymuś te ustawienia z użyciem Azure Policy i wbudowanych zasad: "Key Vault powinny mieć włączone miękkie usuwanie" oraz "Key Vault powinny mieć włączoną ochronę przed czyszczeniem" (efekt deployIfNotExists).
• Zaimplementuj zasady cyklu życia klucza, aby uniknąć kryptograficznego wymazywania danych.
  • Przed przeczyszczeniem zaszyfrowanych danych sprawdź, czy klucze szyfrowania są przechowywane przez wymagany okres przechowywania danych.
  • Podczas likwidowania kluczy należy użyć operacji wyłącz zamiast usuwania , aby zapobiec przypadkowej utracie danych przy zachowaniu kluczowych metadanych na potrzeby inspekcji.
  • Utwórz i przetestuj procedury tworzenia kopii zapasowych dla Key Vault w scenariuszach odzyskiwania po awarii.

Użyj kluczy zabezpieczonych przez moduł HSM i BYOK:

• Używaj kluczy opartych na module HSM dla obciążeń produkcyjnych wymagających silnej ochrony kryptograficznych:
  • Azure Key Vault Premium: Klucze RSA-HSM i EC-HSM chronione przez certyfikowane moduły HSM FIPS 140-2 poziomu 2 (współużytkowane, wielodostępne).
  • Azure Key Vault Zarządzany HSM: Klucze RSA-HSM i EC-HSM chronione przez moduły HSM zweryfikowane na poziomie 3 FIPS 140-3, zapewniające dedykowane pule z jedną dzierżawą.
• W przypadku scenariuszy Bring Your Own Key (BYOK) wygeneruj klucze w lokalnych modułach HSM FIPS 140-2 Poziom 2+ i użyj mechanizmu klucza transferu BYOK do bezpiecznego importowania kluczy do Azure Key Vault, zachowując kryptograficzny dowód pochodzenia klucza i zarządzania.

Włącz monitorowanie i wykrywanie zagrożeń:

• Włącz rejestrowanie diagnostyczne dla Azure Key Vault i kierowanie dzienników do Azure Monitor, Log Analytics lub Microsoft Sentinel w celu przechwycenia wszystkich operacji płaszczyzny zarządzania i płaszczyzny danych. Monitoruj podejrzane działania, w tym nietypowe wzorce dostępu klucza, nieudane próby uwierzytelniania i zmiany administracyjne.
• Włącz Microsoft Defender dla Key Vault w celu wykrywania nietypowych wzorców dostępu, nietypowych operacji klucza i potencjalnych zagrożeń, takich jak nadużycie poświadczeń, podejrzane pobieranie kluczy lub anomalie administracyjne. Integracja alertów usługi Defender dla Key Vault z przepływami pracy na potrzeby reagowania na incydenty.
• Zintegruj dzienniki Key Vault z Microsoft Sentinel aby utworzyć reguły analizy dotyczące wykrywania anomalii, takich jak nietypowy dostęp regionalny, potencjalne próby siłowe lub podejrzane operacje administracyjne. Zaimplementuj zautomatyzowane plany reakcji, aby odizolować tożsamości z naruszonymi zabezpieczeniami i powiadamiać zespoły bezpieczeństwa.

Note: Wszystkie jednostki SKU Key Vault uniemożliwiają eksportowanie kluczy zgodnie z projektem; operacje kryptograficzne są wykonywane w ramach bezpiecznej granicy modułu HSM. Nigdy nie eksportuj ani nie przechowuj kluczy w postaci zwykłego tekstu poza Azure Key Vault.

Przykład implementacji

Międzynarodowa firma technologiczna wdrożyła wielowarstwowe zabezpieczenia dla swojej infrastruktury Azure Key Vault, chroniącej klucze szyfrowania, tajne dane API i certyfikaty TLS dla ponad 500 mikrousług.

Wyzwanie: Nadmierne uprawnienia kontroli dostępu opartej na rolach zezwoliły deweloperom na bezpośredni dostęp do produkcyjnych Key Vaultów, co stwarza ryzyko wynikające z działania wewnętrznego i naruszenia zgodności. Publiczna ekspozycja w Internecie umożliwiła ataki typu credential stuffing oraz próby rekonesansu. Bez kompleksowego monitorowania i automatycznego reagowania podejrzane wzorce dostępu do kluczy nie są wykrywane. Brak miękkiego usuwania i ochrony przed czyszczeniem groziło trwałą utratą danych kryptograficznych podczas incydentów.

Podejście do rozwiązania:

• Wdróż dedykowane magazyny kluczy na potrzeby segmentacji logicznej: Utwórz Key Vault dla środowiska i jednostki biznesowej z konwencją nazewnictwa kv-{businessunit}-{environment}-{region} (np. kv-finance-prod-eastus2, kv-finance-dev-eastus2), wdróż w osobnych grupach zasobów na środowisko w celu wymuszenia izolacji (naruszona jednostka usługi deweloperskich nie może uzyskać dostępu do kluczy produkcyjnych).
• Konfiguruj RBAC (kontrola dostępu oparta na rolach) w celu uzyskania dostępu z minimalnymi uprawnieniami: W przypadku nieprodukcyjnych magazynów kluczy (deweloperskie/przejściowe) przypisz rolę Key Vault Secrets User (tylko do odczytu) do grup zabezpieczeń deweloperów — deweloperzy mogą odczytywać wpisy tajne w środowisku deweloperskim/przejściowym, ale nie mają dostępu do produkcyjnych magazynów kluczy; w przypadku produkcyjnych magazynów kluczy przypisz rolę Key Vault Secrets User do głównych jednostek usługi CI/CD (zarządzane tożsamości potoku Azure DevOps), ogranicz zakres do określonych nazwanych wpisów tajnych, brak interaktywnego dostępu dewelopera do kluczy produkcyjnych.
• Zwiększ bezpieczeństwo sieci przy użyciu Azure Private Link: Wdróż prywatne punkty końcowe dla Key Vault (wybierz sieć wirtualną i podsieć, utwórz prywatną strefę DNS privatelink.vaultcore.azure.net i połącz ją z siecią wirtualną), skonfiguruj zaporę Key Vault (wyłącz dostęp publiczny, aby Key Vault był dostępny tylko przez prywatny punkt końcowy; jeśli dostęp publiczny jest wymagany dla CI/CD, zezwól na dostęp tylko z wybranych sieci z zatwierdzonymi podsieciami sieci wirtualnej Azure oraz zakresami adresów IP agenta CI/CD).
• Włącz Microsoft Defender dla Key Vault: Aktywuj Microsoft Defender dla Key Vault na poziomie subskrypcji; Defender monitoruje anomalie, takie jak nietypowy dostęp geograficzny, podejrzane wyliczanie (szybkie operacje listowe wskazujące na rekonesans), nietypowe operacje administracyjne (masowe usuwanie tajnych danych).
• Integracja z Microsoft Sentinel dla zautomatyzowanej odpowiedzi: Dodaj łącznik danych Microsoft Defender dla Chmury do usługi Sentinel, utwórz reguły analizy usługi Sentinel dla nietypowego dostępu regionalnego, potencjalnych ataków siłowych i podejrzanych operacji administracyjnych, skonfiguruj zautomatyzowane podręczniki odpowiedzi w celu wyłączania podejrzanych tożsamości oraz powiadamiania zespołów ds. zabezpieczeń.
• Stream dzienniki diagnostyczne do Log Analytics: Włącz rejestrowanie diagnostyczne dla Key Vault za pomocą funkcji AuditEvent (wszystkie operacje klucza/tajemnic/certyfikatu), AllMetrics (częstotliwość użycia, opóźnienie), wysyłaj do Log Analytics, z 2-letnim okresem przechowywania, tworząc niestandardowe zapytania KQL do wykrywania anomalii, w tym potencjalne wykrywanie ataków brute force (ponad 10 nieautoryzowanych prób w ciągu 5 minut), operacje miękkiego usuwania są wyłączone (wskaźnik sabotażu).
• Implement Just-In-Time dostęp administratora za pomocą usługi Microsoft Entra PIM: Skonfiguruj przypisania dla roli Administratora Key Vault, które mogą być kwalifikowane (dodaj członków zespołu zabezpieczeń jako uprawnionych, nie do stałego przypisania, wymagaj uzasadnienia i uwierzytelniania wieloskładnikowego do aktywacji, ustaw maksymalny czas trwania aktywacji na 8 godzin, wymagaj zatwierdzenia od starszego architekta zabezpieczeń), przeprowadź kwartalne przeglądy dostępu dla wszystkich przypisań roli Administratora Key Vault; odwołaj niepotrzebny dostęp.

Wynik: Osobne Key Vaulty na każde środowisko wymuszają segmentację. Kontrola dostępu oparta na rolach ogranicza deweloperom dostęp tylko do odczytu w środowiskach nieprodukcyjnych. Private Link eliminuje publiczne narażenie na internet. Microsoft Defender wykrywa anomalie. Podręczniki usługi Sentinel automatycznie wyłączają podejrzane tożsamości. Usługa PIM umożliwia dostęp administratora just in time, co znacznie zmniejsza stałe uprawnienia.

Poziom krytyczny

To musisz mieć.

Mapowanie kontrolek

• Kontrole CIS w wersji 8.1: N/A
• NIST SP 800-53 Rev.5: IA-5, SC-12, SC-17
• PCI-DSS 4: 3.6.1, 8.3.2
• NIST CSF v2.0: PR.AC-1, PR.DS-1
• ISO 27001:2022: A.8.3, A.8.24
• SOC 2: CC6.1, CC6.2