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 obrony w głąb.

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 platformy 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 usługi Microsoft Purview, aby utworzyć kompleksową mapę danych, która automatycznie odnajduje, klasyfikuje i oznacza poufne informacje w całej infrastrukturze danych. Rozszerzanie ochrony poza szyfrowanie na poziomie infrastruktury poprzez implementację usługi Microsoft Purview Information Protection, aby zastosować trwałe szyfrowanie na poziomie dokumentu oraz prawa użytkowania, które towarzyszą danym, gdziekolwiek się one znajdują. 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óż usługę Microsoft Purview , aby odnajdywać, klasyfikować i oznaczać poufne dane na platformie Azure, lokalnie, na platformie Microsoft 365 i w środowiskach z wieloma chmurami.
• Mapa danych usługi Microsoft Purview umożliwia automatyczne skanowanie i katalogowanie źródeł danych, w tym usług Azure Storage, Azure SQL Database, Azure Synapse Analytics i innych obsługiwanych usług.
• 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óż usługę 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 (Azure RMS) jako podstawową technologię ochrony, która szyfruje dokumenty i wiadomości e-mail przy użyciu zasad użycia (tylko widok, 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 Database włącz funkcję odnajdywania i klasyfikacji danych SQL w celu identyfikowania, klasyfikowania i etykietowania kolumn zawierających poufne dane, takie jak numery kart kredytowych, numery ubezpieczenia społecznego lub rekordy kondycji.
• Integrowanie metadanych klasyfikacji z kontrolkami podrzędnymi: konfigurowanie zasad ochrony przed utratą danych (DLP) w usłudze Microsoft Purview, stosowanie reguł dostępu warunkowego w identyfikatorze Entra 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 usługi Microsoft Purview w celu automatycznego odnajdywania i klasyfikowania poufnych danych na 200+ kontach usługi Azure Storage, 50 bazach danych SQL i obszarach roboczych usługi Synapse Analytics.

Wyzwanie: Organizacja nie ma wglądu w lokalizację, w której znajdują się poufne dane w szybko rosnącej infrastrukturze danych platformy Azure. 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:

• Wdróż mapę danych usługi Microsoft Purview na potrzeby odnajdywania danych: Tworzenie konta usługi Purview i rejestrowanie źródeł danych (konta usługi Azure Storage, bazy danych SQL, obszary robocze usługi Synapse Analytics), konfigurowanie mapy danych w celu skanowania źródeł przy użyciu uwierzytelniania tożsamości zarządzanej, udzielanie uprawnień odczytu tożsamości (db_datareader roli) do schematów wykazu i wykrywanie 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.
• Wdróż usługę Microsoft Purview Information Protection na potrzeby szyfrowania na poziomie dokumentu: Utwórz etykiety poufności w portalu zgodności Purview z ustawieniami ochrony (Publiczne: brak szyfrowania, tylko oznaczenia wizualne; Wewnętrzne: znak wodny, brak ograniczeń przesyłania dalej; Poufne: szyfruj za pomocą usługi Azure RMS, zezwalaj na wyświetlanie/edytowanie tylko dla pracowników, blokuj przesyłanie dalej/drukowanie; Wysoce poufne — regulowane: szyfruj za pomocą usługi Azure RMS, dostęp tylko do wyświetlania, brak kopiowania/drukowania/przesyłania dalej, 90-dniowy termin wygaśnięcia, możliwość cofnięcia dostępu), publikowanie etykiet poufności dla użytkowników za pośrednictwem zasad etykiet (zakres: działy finansowe, prawne, wykonawcze), konfigurowanie zasad automatycznego etykietowania w celu automatycznego stosowania etykiet (≥10 numerów SSN → "Wysoce poufne — regulowane", ≥5 numerów kart kredytowych → "Wysoce poufne — regulowane"), włącz ochronę usługi Azure RMS dla dokumentów oznaczonych etykietami przechowywanymi w programie SharePoint, skonfiguruj etykietowanie po stronie klienta dla kont OneDrive i Azure Storage, aby aplikacje pakietu Office monitowały użytkowników o klasyfikację dokumentów przed ich zapisaniem lub 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. Funkcja automatycznego etykietowania Information Protection zastosowała 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 platformy 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 usługę Microsoft Defender for Storage za pomocą skanowania złośliwego oprogramowania i wykrywania zagrożeń poufnych danych w celu monitorowania nietypowych wzorców dostępu, nietypowych woluminów przekazywania/pobierania i potencjalnych prób eksfiltracji danych na kontach usługi Azure Storage.
• Włącz usługę Microsoft Defender dla programu SQL , aby wykrywać podejrzane działania bazy danych, w tym próby iniekcji SQL, nietypowe wzorce zapytań, nietypowe operacje eksportowania danych i dostęp z nieznanych lokalizacji.
• Włącz usługę Microsoft Defender dla usługi Azure Cosmos DB , aby wykrywać nietypowe wzorce dostępu do bazy danych, potencjalne eksfiltrację danych i podejrzane działania operacyjne.
• W przypadku baz danych typu open source (PostgreSQL, MySQL, MariaDB) włącz usługę 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 ochrony przed utratą danych (DLP) firmy Microsoft, aby zapobiec eksfiltracji poufnych danych przez monitorowanie i blokowanie nieautoryzowanych transferów danych niejawnych w usługach platformy Azure, platformie Microsoft 365 i punktach końcowych.
• Wdrażanie rozwiązania Microsoft Purview Insider Risk Management 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 niejawnych koreluje sygnały z platformy Microsoft 365, platformy Azure, systemów HR i narzędzi zabezpieczeń w celu zidentyfikowania potencjalnych naruszeń danych lub naruszeń zasad.

Konfigurowanie monitorowania i odpowiedzi:

• Konfigurowanie dzienników diagnostycznych dla usług danych i kierowanie ich do usługi Azure Monitor lub Microsoft Sentinel w celu ustanowienia punktów odniesienia zachowania i wykrywania odchyleń od normalnych wzorców dostępu.
• Zintegruj dzienniki usługi danych z usługą Microsoft Sentinel , aby utworzyć reguły analizy służące do 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 podręczników Microsoft Sentinel, aby odizolować zagrożone tożsamości, cofnąć dostęp i powiadomić zespoły bezpieczeństwa po wykryciu prób eksfiltrowania danych.

Nuta: W przypadku wymagań DLP opartych na hoście należy wdrożyć funkcje DLP punktu końcowego usługi Microsoft Purview lub rozwiązania innych firm z witryny Azure Marketplace, aby wymusić mechanizmy ochrony danych na poziomie punktu końcowego.

Przykład implementacji

Dostawca opieki zdrowotnej włączył usługę Microsoft Defender for Storage i usługę Defender for SQL w celu monitorowania anomalii i zagrożeń przeznaczonych dla danych pacjentów na kontach usługi 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 usługę Microsoft Defender for Storage: Włącz usługę Defender for Storage na poziomie subskrypcji dla kont magazynu zawierających poufne dane, skonfiguruj skanowanie pod kątem złośliwego oprogramowania w celu wykrywania i kwarantanny złośliwych plików w magazynie obiektów blob, włącz wykrywanie zagrożeń dla danych poufnych przy użyciu typów informacji poufnych usługi Purview w celu identyfikowania wzorców PHI/PII, ustanawiaj limity skanowania dla poszczególnych transakcji lub miesięczne limity w celu kontrolowania kosztów, zastosuj ochronę do grup zasobów zawierających produkcyjne konta magazynu hostujące obrazy medyczne i eksporty z elektronicznych kart zdrowia (EHR).
• Włącz Microsoft Defender for SQL: Włącz Defender for SQL na poziomie subskrypcji dla Azure SQL Database i SQL Managed Instance, skonfiguruj ocenę luk w zabezpieczeniach przy użyciu cyklicznych skanowań i wyznacz konto magazynu dla wyników skanowania, skonfiguruj powiadomienia e-mail, aby powiadamiać zespół ds. zabezpieczeń o zidentyfikowanych lukach, włącz Advanced Threat Protection w celu wykrywania prób iniekcji SQL, nietypowych wzorców zapytań, anomalii dostępu z nieznanych regionów i potencjalnych eksfiltracji danych.
• Integracja z Microsoft Sentinel: Połączenie usługi Microsoft Defender for Cloud z Microsoft Sentinel za pomocą łącznika danych, konfigurowanie ustawień diagnostycznych (włączanie dzienników diagnostycznych dla operacji magazynowania i dzienników inspekcji SQL, przekierowanie do obszaru roboczego Log Analytics), tworzenie reguł analizy usługi Sentinel w celu wykrywania anomalii (alerty pobierania zbiorczego dla plików do pobrania o rozmiarze >10 GB w ciągu jednej godziny, dostęp do bazy danych poza godzinami, podejrzane wzorce zapytań), konfigurowanie planów działań automatycznej reakcji, aby izolować tożsamości z naruszonymi zabezpieczeniami, odwoływać dostęp do magazynu i powiadamiać zespoły bezpieczeństwa.
• Wdróż rozwiązanie Microsoft Purview Insider Risk Management na potrzeby wykrywania zagrożeń behawioralnych: Włącz Zarządzanie Ryzykiem Insiderowym i skonfiguruj szablony zasad (kradzież danych przez użytkowników opuszczających firmę, wykrywających nietypowe pliki do pobrania 30–90 dni przed rezygnacją, ogólne wycieki danych poprzez monitorowanie kopiowania na magazyn USB/ w chmurze, wycieki danych z priorytetyzowaniem użytkowników z rozszerzonym monitorowaniem ról o wysokich uprawnieniach), skonfiguruj wskaźniki ryzyka i progi (skumulowane alerty dotyczące pobierania plików, skoki dostępu poza godzinami pracy, wykrywanie sekwencji łączące wiele ryzykownych sygnałów), zintegrować źródła danych (dzienniki aktywności platformy Azure, dzienniki inspekcji platformy Microsoft 365, usługa Defender for Cloud Apps, systemy HR, zdarzenia DLP punktu końcowego), skonfiguruj alerty dotyczące workflow routing o średniej/wysokiej ważności dla dedykowanej kolejki badania.

Wynik: Usługa Defender for Storage wykryła nietypowe działanie zbiorczego pobierania z naruszonej jednostki 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 platformy 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ś bezpieczny transfer (tylko protokół HTTPS) dla kont usługi Azure Storage, aby upewnić się, ż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 usłudze Azure App Service włącz ustawienie "Tylko protokół HTTPS" i skonfiguruj minimalną wersję protokołu TLS do wersji 1.2 lub 1.3 , aby zapobiec atakom na starszą wersję i zapewnić nowoczesne standardy kryptograficzne.
• Skonfiguruj usługę Azure Application Gateway , aby wymusić minimalną wersję protokołu TLS 1.2/1.3 dla odbiorników frontonu i szyfrowania połączeń zaplecza (end-to-end TLS).
• W przypadku usługi Azure SQL Database i innych usług danych PaaS sprawdź, czy "Wymagaj bezpiecznych połączeń" lub równoważne ustawienia wymuszają szyfrowane połączenia; odrzuć połączenia w postaci zwykłego tekstu.
• W przypadku usług 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.

Nuta: Platforma Azure automatycznie szyfruje cały ruch między centrami danych platformy Azure przy użyciu protokołu MACsec (warstwa 2) i TLS (warstwa 7). Większość usług PaaS platformy Azure domyślnie włącza protokół TLS 1.2 lub nowszy, ale weryfikuje 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 platformy 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ł.
  • Maszyny wirtualne z systemem Windows: Użyj protokołu RDP przez protokół TLS (port 3389) z włączonym uwierzytelnianiem na poziomie sieci (NLA).
  • Dostęp uprzywilejowany: Kierowanie połączeń administracyjnych za pośrednictwem usługi Azure Bastion w celu wyeliminowania ujawnienia publicznych adresów IP i zapewnienia dostępu klienta opartego na przeglądarce 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:
  • Korzystanie z obsługi SFTP w usłudze Azure Blob Storage (wymaga hierarchicznej przestrzeni nazw).
  • Używanie usługi FTPS w usługach Azure App Service i Azure Functions.
  • Wyłącz starszy protokół FTP (zwykły tekst).
• Użyj usługi Azure Policy , aby wymusić zasady bezpiecznego transferu w całym środowisku i monitorować zgodność pod kątem 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:

• Konfigurowanie usługi 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, sprawdzić, czy zarządzane certyfikaty lub certyfikaty niestandardowe używają silnych zestawów szyfrowania.
• Konfigurowanie usługi Azure Application Gateway dla kompleksowego połączenia TLS: Skonfiguruj odbiornik HTTPS frontonu przy użyciu zasad SSL AppGwSslPolicy20220101 (minimalna wersja TLS 1.3 z zasadami CustomV2), prześlij certyfikat TLS lub integruj 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 dobrze znanego certyfikatu urzędu certyfikacji”, jeśli usługi App Services zaplecza używają certyfikatów zarządzanych przez Azure, ustaw minimalną wersję TLS na 1.2 dla połączeń zaplecza), utwórz reguły routingu łączące odbiorniki HTTPS z pulami zaplecza przy użyciu ustawień z obsługą TLS.
• Wymuszanie bezpiecznego transferu dla usługi Azure Storage: Włącz ustawienie "Wymagany bezpieczny transfer", aby wymusić tylko protokół 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ą tylko za pośrednictwem połączeń HTTPS.
• Konfigurowanie usługi Azure Bastion pod kątem bezpiecznego dostępu zdalnego: Wdróż usługę Azure Bastion w sieci wirtualnej piasty, aby zapewnić dostęp RDP/SSH oparty na przeglądarce za pośrednictwem protokołu TLS 1.2, usunąć publiczne adresy IP z maszyn wirtualnych i skierować cały dostęp administracyjny wyłącznie za pośrednictwem usługi Bastion.

Wynik: Konta usługi Azure Storage odrzucają połączenia HTTP na granicy usługi. Usługa Application Gateway wymusza protokół TLS 1.3 dla połączeń frontonu z szyfrowaniem zaplecza TLS 1.2, a usługa Azure Bastion eliminuje narażenie publicznych adresów IP na potrzeby 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 platformy 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 w Azure są szyfrowane w stanie spoczynku, aby chronić przed nieautoryzowanym dostępem w przypadku naruszenia infrastruktury, skradzionego nośnika lub nieautoryzowanych migawek. Podczas gdy większość usług platformy Azure domyślnie włącza szyfrowanie, zweryfikuj pokrycie w przypadku maszyn wirtualnych, kont magazynowych i baz danych oraz włącz dodatkowe warstwy szyfrowania (szyfrowanie na poziomie hosta, szyfrowanie infrastruktury, poufne przetwarzanie i szyfrowanie na poziomie kolumny) w przypadku bardzo wrażliwych obciążeń, aby spełnić wymagania regulacyjne oraz dotyczące suwerenności danych.

Włącz szyfrowanie dla maszyn wirtualnych i magazynu:

• Włącz szyfrowanie na hoście dla usługi Azure Virtual Machines, aby szyfrować dyski tymczasowe, pamięć podręczną dysku systemu operacyjnego, pamięć podręczną dysku danych i efemeryczne dyski systemu operacyjnego przed dotarciem do usługi 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 usługi 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:

• Wdróż poufne maszyny wirtualne platformy Azure z szyfrowaniem dysków poufnych na potrzeby wysoce regulowanych obciążeń przetwarzających dane kontrolowane przez eksport lub poufne dane. 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 usługi Azure SQL Database zaimplementuj funkcję 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 baz 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:

• Wymuszenie zgodności szyfrowania z użyciem usługi Azure Policy przez przypisanie wbudowanych zasad, takich jak "Maszyny wirtualne powinny włączyć szyfrowanie na hoście", "Konta magazynu powinny mieć szyfrowanie infrastruktury", a opcja "Transparent Data Encryption w bazach danych SQL powinna być włączona" na poziomie subskrypcji lub grupy zarządzania.
• Usługa Azure Resource Graph umożliwia wykonywanie zapytań i tworzenie spisu konfiguracji szyfrowania w środowisku, identyfikowanie maszyn wirtualnych bez szyfrowania na hoście, kont magazynu bez szyfrowania infrastruktury lub baz danych bez włączonej funkcji TDE.

Nuta: Wiele usług platformy 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 są automatycznie obracane 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 stanie spoczynku w całym środowisku platformy Azure, aby chronić dane ERP, aplikacje łańcucha dostaw oraz tajemnice handlowe inżynierii.

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łącz szyfrowanie na hoście dla maszyn wirtualnych platformy Azure: Zarejestruj funkcję EncryptionAtHost na poziomie subskrypcji. Następnie włącz szyfrowanie na hoście dla maszyn wirtualnych, korzystając z obsługiwanych rozmiarów (serie DSv3, Easv4, Dadsv5). Szyfrowanie obejmuje dyski tymczasowe, pamięć podręczną dysku systemu operacyjnego, pamięć podręczną dysków danych oraz efemeryczne dyski systemu operacyjnego.
• Włącz szyfrowanie infrastruktury (podwójne szyfrowanie) dla usługi Azure Storage: Sprawdź, czy szyfrowanie usługi Azure Storage (SSE) jest włączone (domyślnie — szyfrowanie AES-256) dla poufnych kont magazynu włącza szyfrowanie infrastruktury podczas tworzenia konta magazynu (nie można włączyć po utworzeniu), wynik: dwie warstwy szyfrowania AES-256 z różnymi kluczami.
• Wdróż poufne maszyny wirtualne platformy Azure na potrzeby obciążeń wysoce regulowanych: Wybierz odpowiednią serię poufnych maszyn wirtualnych (seria DCasv5/DCadsv5 dla AMD SEV-SNP lub ECasv5/ECadsv5 dla Intel TDX), włącz szyfrowanie dysków poufnych przy użyciu klucza zarządzanego przez platformę (wiąże klucze szyfrowania dysków z wirtualnym modułem TPM), włącz Bezpieczny Rozruch i wirtualny TPM (vTPM) na potrzeby zaświadczenia, wdrażaj w przypadku obciążeń przetwarzających techniczne dane podlegające kontroli eksportowej lub w przypadku wysoce regulowanych danych osobowych, które muszą pozostać zaszyfrowane podczas przetwarzania.
• Zaimplementuj funkcję Always Encrypted dla poufnych kolumn bazy danych: Zidentyfikuj wysoce poufne kolumny w usłudze Azure SQL Database wymagające szyfrowania na poziomie kolumny (SSN, CreditCardNumber, MedicalRecordNumber), generuj klucze szyfrowania kolumn (CEK) i klucze główne kolumn (CMK), przechowując klucz CMK w usłudze Azure Key Vault, gdzie CEK szyfruje dane kolumnowe, a CMK szyfruje CEK. Włącz funkcję Always Encrypted z użyciem bezpiecznych enklaw (Intel SGX), aby umożliwić bardziej złożone zapytania dotyczące zaszyfrowanych danych. Szyfruj poufne kolumny, używając szyfrowania deterministycznego (dla wyszukiwania równości) lub szyfrowania randomizowanego (dla maksymalnego bezpieczeństwa). Skonfiguruj parametry połączenia aplikacji, ustawiając Column Encryption Setting = Włączone dla przezroczystego szyfrowania i odszyfrowania.
• Konfiguracje szyfrowania spisu za pomocą usługi Azure Resource Graph: Wykonywanie zapytań o stan szyfrowania dla maszyn wirtualnych bez szyfrowania na hoście i kontach magazynu bez szyfrowania infrastruktury, eksportowanie wyników do pliku CSV i przypisywanie zadań korygujących 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 platformy 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 firma Microsoft nie może odszyfrować danych, zaimplementuj podwójne szyfrowanie kluczy (DKE), gdzie organizacja utrzymuje drugi klucz szyfrowania poza platformą Azure. Użyj usługi Azure Key Vault lub zarządzanego modułu HSM, aby zachować kontrolę kryptograficzną podczas równoważenia złożoności operacyjnej zarządzania cyklem życia kluczy, planowania odzyskiwania po awarii i potencjalnego wpływu dostępności usługi na błędy 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.
• Skonfiguruj usługę Azure Key Vault (w warstwie Standardowa lub Premium) lub zarządzany moduł HSM usługi Azure Key Vault, aby przechowywać i zarządzać kluczami szyfrowania zarządzanymi przez klienta. 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.
• Generowanie kluczy szyfrowania w usłudze Azure Key Vault przy użyciu funkcji generowania kluczy lub importowanie kluczy z lokalnych modułów HSM przy użyciu funkcji Bring Your Own Key (BYOK) w celu zapewnienia maksymalnej przenośności i kontroli.

Skonfiguruj CMK i ustanów hierarchię kluczy:

• W przypadku ekstremalnych wymagań dotyczących kontroli zaimplementuj podwójne szyfrowanie kluczy (DKE), gdzie poufne dokumenty wymagają dwóch kluczy do odszyfrowywania: jednego zarządzanego przez firmę Microsoft (Azure RMS) i drugiego klucza zarządzanego wyłącznie przez organizację lokalną lub w własnej usłudze zarządzania kluczami zewnętrznymi. W przypadku DKE firma Microsoft nie może odszyfrować danych, nawet jeśli zmusi je do tego proces prawny, ponieważ kontrolujesz drugi klucz wymagany do odszyfrowania.
• Skonfiguruj usługi platformy 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 usługi Key Vault. Włącz automatyczne zasady rotacji kluczy , aby zmniejszyć ręczne obciążenie operacyjne.
• Ustanów hierarchię klucza szyfrowania kluczy (KEK) i klucza szyfrowania danych (DEK), w której klucz KEK (przechowywany w usłudze Key Vault) szyfruje klucz szyfrowania danych (DEK, używany 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 platformy Azure, aby spełnić wymagania prawne dotyczące 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:

• Aprowizuj zarządzany moduł HSM usługi Azure Key Vault: Utwórz zarządzany moduł HSM (FIPS 140-3 na poziomie 3) z co najmniej 3 partycjami HSM w celu zapewnienia wysokiej dostępności, aktywuj zarządzany moduł HSM przez eksportowanie domeny zabezpieczeń z kluczami kworum (podzielonymi na fragmenty kluczy przechowywanych w geograficznie rozproszonych offline sejfach), generuj klucze szyfrowania (RSA-4096 o nazwie KEK-Prod-2024) przy użyciu operacji klucza: opakowywanie klucza, odpakowywanie klucza, szyfrowanie, odszyfrowywanie.
• Konfigurowanie kluczy zarządzanych przez klienta dla usług platformy Azure: Dla Azure Storage skonfiguruj konto, aby używać szyfrowania typu CMK, wybierz klucz z Zarządzanego HSM w usłudze Key Vault jako źródło, włącz tożsamość zarządzaną przypisaną przez użytkownika wraz z rolą Użytkownika Szyfrowania Usługi Crypto Managed HSM; dla Azure SQL Database skonfiguruj bazę danych SQL do używania klucza zarządzanego przez klienta jako ochrony TDE, wybierz klucz z Zarządzanego HSM, włącz automatyczne obracanie; dla Azure Cosmos DB włącz klucze zarządzane przez klienta dla konta Cosmos DB, wybierz klucz z Zarządzanego HSM, przyznaj dostęp tożsamości zarządzanej usługi Cosmos DB.
• Zaimplementuj automatyczną rotację kluczy: Skonfiguruj zasady rotacji z częstotliwością rotacji 90 dni, włącz automatyczną rotację, skonfiguruj powiadomienie o wygaśnięciu (alert 7 dni przed wygaśnięciem), utwórz alert usługi Azure Monitor dla metryki Key Near Expiration, aby powiadomić zespół ds. zabezpieczeń.
• Włącz rejestrowanie inspekcji pod kątem zgodności: Włącz rejestrowanie diagnostyczne dla zarządzanego modułu HSM (dzienniki AuditEvent), wysyłaj dzienniki do obszaru roboczego Log Analytics z niezmiennym przechowywaniem (zachowaniem przez 90 dni dla zapewnienia nienaruszalnych śladów audytu), korzystaj z dzienników dostępu do kluczy, aby monitorować operacje Szyfrowania, Deszyfrowania, WrapKey i UnwrapKey.
• 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.

Wynik: KEK RSA-4096 w zarządzanym module HSM szyfrują DEK na poziomie usług 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 platformy 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óż usługę Azure Key Vault jako pojedyncze źródło prawdy dla operacji związanych z kluczami, wdrażając kompleksowe logowanie audytowe w celu śledzenia wszystkich zmian dostępu do kluczy i zmian administracyjnych na potrzeby zgodności i celów sądowo-śledczych.

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

• Użyj usługi 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 Twojego 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)
• Aby zwiększyć bezpieczeństwo, użyj Azure Key Vault Managed HSM do ochrony w ramach pojedynczej dzierżawy, zweryfikowanego zgodnie ze standardem FIPS 140-3 poziom 3. Zarządzany moduł HSM obsługuje domenę kryptograficzną na potrzeby tworzenia kopii zapasowych i odzyskiwania po awarii.
• Skonfiguruj rejestrowanie i kierowanie dzienników usługi Azure Key Vault do usługi Azure Monitor lub Microsoft Sentinel w celu śledzenia wszystkich kluczowych zdarzeń dostępu, rotacji i operacji administracyjnych na potrzeby inspekcji 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 zasady zautomatyzowanej rotacji kluczy w usłudze 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 KEKs w usłudze Azure Key Vault z ograniczonym dostępem.
  • 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 BYOK (Bring Your Own Key) wygeneruj klucze w lokalnych modułach HSM FIPS 140-2 poziom 2+ i używaj mechanizmu transferu kluczy BYOK, aby bezpiecznie importować klucze do usługi Azure Key Vault lub zarządzanej usługi HSM, zachowując kryptograficzny dowód pochodzenia klucza i nadzoru.

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: Administrator kryptograficzny usługi Key Vault, użytkownik kryptograficzny usługi Key Vault (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 kluczy z usługą 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 zakresie opieki zdrowotnej scentralizował zarządzanie kluczami kryptograficznymi przy użyciu SKU Premium usługi Azure Key Vault z kluczami chronionymi za pomocą modułu HSM na potrzeby szyfrowania PHI na całej platformie przeznaczonej dla wielu klientów.

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:

• Aprowizuj usługę Azure Key Vault Premium z kluczami chronionymi przez moduł HSM: Utwórz usługę Azure Key Vault w warstwie Premium, aby obsługiwać klucze chronione przez moduł HSM, włącz ochronę przed trwałym usunięciem na czas przechowywania, włącz funkcję miękkiego usuwania 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) z typem klucza sprzętowego.
• Zaimplementuj zasady zautomatyzowanej rotacji kluczy: Skonfiguruj zasady rotacji z częstotliwością rotacji co 180 dni, włącz automatyczną rotację i ustaw powiadomienie na alert 30 dni przed wygaśnięciem, utwórz grupy akcji usługi 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.
• Konfiguracja RBAC dla rozdzielenia obowiązków: Przypisz rolę Kryptograficzny Oficer Key Vault członkom zespołu ds. zabezpieczeń (uprawnienia: zarządzanie cyklem życia klucza, ale bez możliwości wykonywania operacji szyfrowania/odszyfrowywania), przypisz rolę Kryptograficzny Użytkownik Key Vault zarządzanym tożsamościom aplikacji (uprawnienia: wykonywanie operacji szyfrowania i odszyfrowywania bez uprawnień do zarządzania kluczami), weryfikuj rozdzielenie obowiązków, zapewniając, że żadna tożsamość nie posiada jednocześnie roli Oficera i Użytkownika kryptograficznego.
• Ustanów hierarchię KEK/DEK na potrzeby szybkiej rotacji kluczy: Generowanie kluczy szyfrowania danych na poziomie aplikacji (DEK) w kodzie aplikacji (klucze AES-256) na potrzeby szyfrowania danych pacjentów, przechowywanie zaszyfrowanych kluczy szyfrowania wraz z zaszyfrowanymi danymi, używanie klucza KEK usługi Key Vault do zawijania/szyfrowania kluczy szyfrowania za pomocą operacji WrapKey i pobieranie oraz rozwijanie DEK przy użyciu operacji UnwrapKey podczas odszyfrowywania danych pacjentów, korzyść z rotacji kluczy KEK: wymaga tylko ponownego szyfrowania DEK zamiast całej bazy danych pacjentów.
• Integrowanie dzienników usługi Key Vault z usługą Microsoft Sentinel: Włącz ustawienia diagnostyczne dla usługi Key Vault i wysyłaj dzienniki do obszaru roboczego usługi Log Analytics, utwórz reguły analizy usługi Sentinel w celu wykrywania nietypowych wzorców dostępu kluczy, operacji zbiorczych kluczy, zmian administracyjnych poza godzinami pracy.
• Przesył BYOK (Bring Your Own Key) z lokalnego modułu HSM: Pobierz klucz transferu BYOK z usługi Key Vault, wyeksportuj klucz z lokalnego modułu HSM opakowanego za pomocą klucza publicznego BYOK usługi Key Vault, zachowaj kryptograficzny dowód pochodzenia klucza, zaimportuj opakowany klucz do usługi Key Vault, gdzie trafia on chroniony przez moduł HSM bez ujawnienia w postaci zwykłego tekstu.

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. Usługa Microsoft Sentinel wykrywa anomalie, takie jak nieznany dostęp do adresów 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 platformy 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 usługi Azure Key Vault , aby centralnie zarządzać pełnym cyklem życia certyfikatu: tworzenie, importowanie, odnawianie, rotacja, odwoływanie i bezpieczne usuwanie.
• Zdefiniuj zasady certyfikatów w usłudze Azure Key Vault, aby wymusić standardy 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 usługą 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 należy zintegrować wewnętrzny urząd certyfikacji organizacji (np. usługi certyfikatów Active Directory — ADCS) z usługą 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.

Nuta: W prostych scenariuszach można użyć certyfikatów zarządzanych usługi 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 platformy Azure, aby automatycznie pobierać odnowione certyfikaty z usługi Key Vault przy użyciu tożsamości zarządzanych, zmniejszając trud operacyjny i eliminując ryzyko zapomnianych odnawiań ręcznych podczas urlopów lub przejścia pracowników.

Konfigurowanie automatycznego odnawiania:

• Włącz automatyczne odnawianie certyfikatów w usłudze Azure Key Vault, konfigurując akcje dotyczące cyklu życia, aby wywołać odnowienie w określonym procentzie okresu istnienia certyfikatu.
  • Zalecany wyzwalacz: 80–90% okresu ważności (np. ~318 dni dla certyfikatu 397-dniowego).
  • Akcja: Automatyczne odnawianie (Key Vault żąda odnowienia od CA bez interwencji ręcznej).
• 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 platformy Azure, które obsługują automatyczną rotację certyfikatów (Azure App Service, Azure Application Gateway, Azure Front Door), skonfiguruj te usługi w celu automatycznego pobierania zaktualizowanych certyfikatów z usługi Key Vault przy użyciu tożsamości zarządzanych lub jednostek usługi z odpowiednimi zasadami dostępu usługi Key Vault:
  • Usługi platformy Azure automatycznie powiążą nowe wersje certyfikatów po odnowieniu (zazwyczaj w ciągu 24 godzin, bez wymaganego ponownego uruchomienia usługi).
• W przypadku aplikacji, które nie mogą automatycznie korzystać z certyfikatów usługi Key Vault, zaimplementuj ręczne przepływy pracy rotacji certyfikatów przy użyciu runbooków operacyjnych i alertów monitorowania, aby zapobiec awariom spowodowanym wygaśnięciem.
• Zachowaj spis wszystkich certyfikatów w usłudze Azure Key Vault śledzącej nazwę certyfikatu, cel, datę wygaśnięcia, usługi zależne i 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:

• Konfigurowanie alertów usługi Azure Monitor dla zdarzeń wygasania certyfikatów:
  • 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 usługi Azure Resource Graph do wykonywania zapytań dotyczących 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. usługi 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 usłudze 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 200+ publicznymi aplikacjami internetowymi scentralizowało zarządzanie cyklem życia certyfikatów poprzez użycie usługi Azure Key Vault zintegrowanej 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:

• Konfigurowanie integracji urzędu certyfikacji z usługą Azure Key Vault: Dodaj DigiCert (lub inny partnerski urząd certyfikacji) do usługi Key Vault za pomocą poświadczeń API w celu automatyzacji żądań certyfikatów.
• Tworzenie zasad certyfikatów wymuszających 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 CA/Forum przeglądarki), skonfiguruj akcję automatycznego odnawiania certyfikatu (ustaw wyzwalacz na około 318 dni, co odpowiada 80% okresu ważności certyfikatu dla 397-dniowego certyfikatu), akcja: automatyczne odnawianie (usługa Key Vault żąda odnowienia z firmy DigiCert bez interwencji użytkownika).
• Skonfiguruj automatyczne powiązanie certyfikatów dla usług platformy Azure: W przypadku importowania certyfikatu usługi Azure App Service z usługi Key Vault przypisz tożsamość zarządzaną przez użytkownika z rolą użytkownika sekretnych danych 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); w przypadku usługi Azure Application Gateway skonfiguruj odbiornik tak, aby pobierał certyfikat z usługi Key Vault, przypisz tożsamość zarządzaną przez użytkownika z rolami użytkownika sekretnych danych i certyfikatów usługi Key Vault, usługa Application Gateway automatycznie pobiera zaktualizowany certyfikat po odnowieniu go przez usługę Key Vault.
• Konfigurowanie alertów o wygaśnięciu certyfikatów: Utwórz dwie reguły alertów w usłudze Azure Monitor — 30-dniowe ostrzeżenie o wygaśnięciu (wysyłanie powiadomień do kanału inżynierskiego platformy Slack), 7-dniowy krytyczny alert o wygaśnięciu (otwórz zgłoszenie w Jira do ręcznego przeglądu i wyślij wiadomość e-mail do zespołu bezpieczeństwa).
• Wyeliminuj certyfikaty z symbolami wieloznacznymi na rzecz certyfikatów SAN: Skontroluj istniejące certyfikaty wieloznaczne (*.contoso.com) w usłudze Key Vault, zastąp je certyfikatami SAN zawierającymi jawne nazwy DNS (www.contoso.comapi.contoso.com), korzyść: jeśli klucz prywatny został skompromitowany, dotyczy to tylko wymienionych nazw FQDN (nie wszystkich domen podrzędnych).
• Monitorowanie wygaśnięcia certyfikatu: Usługa Azure Resource Graph umożliwia wykonywanie zapytań dotyczących spisu certyfikatów i identyfikowanie 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. Usługa Azure App Service i usługa Application Gateway pobierają zaktualizowane certyfikaty w ciągu 24 godzin za pośrednictwem tożsamości zarządzanych (nie jest wymagane ponowne uruchomienie). Alerty usługi Azure Monitor 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 platformy 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 usługi 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 usługi Key Vault, aby wymusić kontrolę dostępu opartą na zasadzie najmniejszych uprawnień.
  • W przypadku zarządzanego modułu HSM usługi Azure Key Vault: użyj lokalnego RBAC na poziomie klucza, tajemnicy i certyfikatu z wbudowanymi rolami (Managed HSM Crypto Officer, Crypto User, Crypto Auditor).
  • W przypadku Azure Key Vault w warstwie Standardowa/Premium: utwórz dedykowane skarbce dla aplikacji lub środowiska, aby wymusić separację logiczną i przypisać role RBAC (administrator Key Vault, oficer tajemnic, oficer certyfikatów) 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 platformy Azure (app services, maszyn wirtualnych, usługi Azure Functions itp.), aby uzyskać dostęp do usługi 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 usługę Azure AD Privileged Identity Management (PIM) na potrzeby dostępu administracyjnego just in time do usługi Key Vault:
  • Konfigurowanie kwalifikujących się przypisań dla roli administratora usługi Key Vault (nie trwałych przypisań).
  • 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 usługi Key Vault

Wyeliminuj powierzchnie ataków dostępne z Internetu, kierując cały dostęp do usługi Key Vault za pośrednictwem prywatnych punktów końcowych w sieciach wirtualnych, uniemożliwiając próby wypychania poświadczeń, ataki siłowe i rekonesans przez zewnętrznych aktorów 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óż usługę Private Link i skonfiguruj zaporę:

• Zabezpieczanie dostępu sieciowego do usługi Azure Key Vault przy użyciu usługi Azure Private Link w celu ustanowienia łączności prywatnej z sieci wirtualnych bez uwidaczniania usługi Key Vault do publicznego Internetu.
• Skonfiguruj zaporę usługi Key Vault , aby ograniczyć dostęp do określonych zakresów adresów IP lub sieci wirtualnych w scenariuszach, w których usługa Private Link nie jest możliwa:
  • Wyłącz dostęp publiczny, jeśli to możliwe (usługa Key Vault jest dostępna 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łączanie ochrony i monitorowania usługi 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 za pomocą Microsoft Defender dla Key Vault i Microsoft Sentinel, aby wykrywać nietypowe wzorce dostępu, nietypowe operacje kluczy i anomalia administracyjne, które wskazują na naruszenia, zagrożenia wewnętrzne lub działania rekonesansu skierowane przeciwko Twojej infrastrukturze kryptograficznej.

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

• Włącz miękkie usuwanie i ochronę przed trwałym usunięciem we wszystkich magazynach kluczy Azure Key Vault, aby zapobiec przypadkowemu lub złośliwemu usunięciu kluczy, sekretów 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 za pomocą usługi Azure Policy przy użyciu wbudowanych zasad: "Magazyny kluczy powinny mieć włączone usuwanie nietrwałe" i "Magazyny kluczy powinny mieć włączoną ochronę przed przeczyszczeniem" (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.
  • Tworzenie i testowanie procedur tworzenia kopii zapasowych usługi Key Vault na potrzeby scenariuszy 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 moduły HSM zgodne z FIPS 140-2 Poziom 2 (współdzielone wielodostępne).
  • Zarządzany moduł HSM usługi Azure Key Vault: klucze RSA-HSM i EC-HSM chronione przez zweryfikowane moduły HSM na poziomie 3 FIPS 140-3 (dedykowane pule jednokrotnego dzierżawcy).
• W przypadku scenariuszy BYOK (Bring Your Own Key) należy wygenerować klucze w lokalnych modułach HSM FIPS 140-2 poziomu 2+ i użyć mechanizmu klucza transferu BYOK, aby bezpiecznie zaimportować klucze do usługi Azure Key Vault, zachowując kryptograficzny dowód pochodzenia klucza i nadzór.

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

• Włącz rejestrowanie diagnostyczne dla usługi Azure Key Vault i kierowanie dzienników do usługi Azure Monitor, Log Analytics lub Microsoft Sentinel, aby przechwycić wszystkie operacje 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 usługę Microsoft Defender dla usługi Key Vault , aby wykrywać nietypowe wzorce dostępu, nietypowe operacje kluczy i potencjalne zagrożenia, takie jak nadużycie poświadczeń, podejrzane pobieranie kluczy lub anomalie administracyjne. Integrowanie alertów usługi Defender for Key Vault z przepływami pracy reagowania na zdarzenia.
• Zintegruj dzienniki usługi Key Vault z usługą Microsoft Sentinel , aby utworzyć reguły analizy dotyczące wykrywania anomalii, takich jak nietypowy dostęp regionalny, potencjalne próby ataku siłowego lub podejrzane operacje administracyjne. Zaimplementuj zautomatyzowane plany reakcji, aby odizolować tożsamości z naruszonymi zabezpieczeniami i powiadamiać zespoły bezpieczeństwa.

Uwaga: Wszystkie jednostki SKU usługi Key Vault uniemożliwiają eksportowanie kluczy z założenia; operacje kryptograficzne są wykonywane w ramach bezpiecznej granicy modułu HSM. Nigdy nie eksportuj ani nie przechowuj kluczy w postaci zwykłego tekstu poza usługą Azure Key Vault.

Przykład implementacji

Międzynarodowa firma technologiczna wdrożyła wielowarstwowe zabezpieczenia dla infrastruktury Azure Key Vault, chroniąc 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 oddzielny magazyn Key Vault dla każdego środowiska i jednostki biznesowej, stosując konwencję nazewnictwa kv-{jednostka biznesowa}-{środowisko}-{region} (np. kv-finance-prod-eastus2, kv-finance-dev-eastus2), wdrażając w osobnych grupach zasobów dla każdego środowiska, aby wymusić izolację (kompromitacja jednostki usługi deweloperskiej nie pozwala na dostęp do kluczy produkcyjnych).
• Konfigurowanie RBAC dla dostępu z minimalnymi uprawnieniami: Dla nieprodukcyjnych magazynów kluczy (deweloperskich/przejściowych) przypisz rolę użytkownika tajemnic Key Vault (tylko do odczytu) grupom zabezpieczeń deweloperów — deweloperzy mogą uzyskiwać dostęp do tajemnic w środowisku deweloperskim/przejściowym, ale nie mają dostępu do produkcyjnych magazynów kluczy; dla produkcyjnych magazynów kluczy przypisz użytkownika tajemnic Key Vault głównym tożsamościom CI/CD (tożsamości zarządzanym potoku Azure DevOps), ogranicz zakres do określonych nazwanych tajemnic, bez interaktywnego dostępu dla deweloperów do kluczy produkcyjnych.
• Wzmocnij sieć za pomocą 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 z siecią wirtualną), skonfiguruj zaporę Key Vault (wyłącz dostęp publiczny, udostępniając Key Vault wyłącznie przez prywatny punkt końcowy, jeśli dostęp publiczny jest wymagany dla CI/CD, zezwól na dostęp wyłącznie z wybranych sieci z zatwierdzonymi podsieciami Azure VNet oraz zakresami adresów IP agenta CI/CD).
• Włącz Microsoft Defender dla Key Vault: Włącz Microsoft Defender dla Key Vault na poziomie subskrypcji, Microsoft Defender monitoruje anomalie, w tym nietypowy dostęp geograficzny, podejrzane wyliczenia (szybkie operacje list wskazujące na rekonesans), nietypowe operacje administracyjne (zbiorcze usuwanie sekretów).
• Integracja z usługą Microsoft Sentinel w celu uzyskania automatycznej odpowiedzi: Dodaj łącznik danych usługi Microsoft Defender for Cloud do usługi Sentinel, utwórz reguły analizy usługi Sentinel dla nietypowego dostępu regionalnego, potencjalnego ataku siłowego, podejrzanych operacji administracyjnych, skonfiguruj automatyczne podręczniki reagowania, aby wyłączyć podejrzane tożsamości i powiadomić zespoły ds. zabezpieczeń.
• Przesyłanie strumieniowe dzienników diagnostycznych do usługi Log Analytics: Włącz rejestrowanie diagnostyczne dla usługi Key Vault przy użyciu funkcji AuditEvent (wszystkie operacje klucza/klucza/wpisu tajnego/certyfikatu), AllMetrics (częstotliwość użycia, opóźnienie), wysyłanie do obszaru roboczego usługi Log Analytics z 2-letnim przechowywaniem, tworzenie niestandardowych zapytań KQL na potrzeby wykrywania anomalii, w tym potencjalnego wykrywania ataków siłowych (10+ nieautoryzowanych prób w ciągu 5 minut), wyłączone operacje usuwania nietrwałego (wskaźnik sabotażu).
• Zaimplementuj dostęp Just-In-Time administratora za pomocą usługi Azure AD PIM: Konfiguracja kwalifikujących się przypisań dla roli administratora usługi Key Vault (dodaj członków zespołu zabezpieczeń jako uprawnionych, a nie stałych przypisanych, wymagaj uzasadnienia i uwierzytelniania wieloskładnikowego dla aktywacji, ustaw maksymalny czas trwania aktywacji na 8 godzin, wymagaj zatwierdzenia od starszego architekta zabezpieczeń), przeprowadzaj kwartalne przeglądy dostępu dla wszystkich przypisań ról administratora usługi Key Vault; cofnięcie niepotrzebnego dostępu.

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. Usługa Private Link eliminuje publiczne narażenie na internet. Usługa 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