Microsoft AZ-500: Bezpieczeństwo danych, pamięci masowej i baz danych — Przewodnik do nauki

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Część Microsoft Azure Security Engineer Associate AZ-500 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Bezpieczeństwo danych, magazynu i baz danych w Azure koncentruje się na minimalizacji zaufania, izolacji płaszczyzn danych, wszechobecnym szyfrowaniu oraz operacjonalizacji zasady najmniejszych uprawnień z audytowalnymi ścieżkami dostępu. Ta sekcja wyjaśnia, jak wzmocnić zabezpieczenia usług Azure Storage, Azure SQL i Azure Cosmos DB, wybrać odpowiednią strategię tożsamości i kluczy oraz zapobiegać eksfiltracji danych. Każdy opisany mechanizm kontrolny jest opatrzony uzasadnieniem operacyjnym, aby można było uzasadnić i utrzymać konfigurację w środowisku produkcyjnym.

Zabezpieczanie kont usługi Azure Storage i dostępu do danych

Autoryzacja i udostępnianie konta magazynu

• Azure RBAC dla Azure Storage: Preferuj autoryzację opartą na Azure AD (dla Blob i Queue) za pomocą wbudowanych ról, takich jak Storage Blob Data Reader/Contributor. Uzasadnienie: dostęp oparty na tokenach, ograniczony czasowo przez Conditional Access, logowany w Entra ID; unika się stałych kluczy konta i wspiera przypisywanie uprawnień just-in-time.
• Klucze współdzielone (shared keys): Główne/dodatkowe klucze konta przyznają pełne uprawnienia do płaszczyzny danych. Wyłącz użycie kluczy w kodzie i często je rotuj. Uzasadnienie: klucze współdzielone to sekrety typu „bearer” bez powiązania z użytkownikiem ani urzędem certyfikacji (CA); kompromitacja = całkowite ujawnienie danych.
• Typy SAS:
  • Service SAS: Przyznaje ograniczony (scoped) dostęp do określonych zasobów (blob, plik, kolejka, tabela) z uprawnieniami, adresem IP, protokołem i limitami czasowymi. Uzasadnienie: precyzyjna zasada najmniejszych uprawnień dla aplikacji, które nie mogą używać tokenów AD.
  • Account SAS: Szerszy zakres (np. obejmujący wiele usług); używaj oszczędnie. Uzasadnienie: zwiększa promień rażenia (blast radius) w przypadku wycieku.
  • User delegation SAS: Wydawany przy użyciu Azure AD i klucza delegowania użytkownika dla usługi Blob. Uzasadnienie: wiąże się z tożsamością Azure AD i urzędem certyfikacji (CA); zapewnia lepszą audytowalność i możliwość odwołania.
• Zapisane zasady dostępu (stored access policies): Definiują reużywalne ograniczenia (wygaśnięcie, uprawnienia) dla SAS na kontenerach/udziałach; odwołanie lub aktualizacja zasady unieważnia sygnatury SAS wydane na jej podstawie. Uzasadnienie: centralne odwoływanie dostępu bez konieczności ponownego generowania tokenów osadzonych w klientach.

Przykład: generowanie User Delegation SAS dla bloba przy użyciu Azure AD

az storage blob generate-sas \
  --account-name mystorage \
  --container-name data \
  --name report.csv \
  --permissions r \
  --expiry 2026-12-31T23:59Z \
  --as-user \
  --auth-mode login

Bezpieczeństwo usług według typu

• Blob/Queue/Table: Używaj Azure AD RBAC tam, gdzie jest to wspierane (Blob, Queue). Ustaw AllowBlobPublicAccess na false, wymagaj HTTPS, włącz wersjonowanie i usuwanie nietrwałe (soft delete). Uzasadnienie: eliminuje ścieżki anonimowego dostępu i umożliwia odzyskiwanie danych.
• Azure Files: Używaj Azure AD Kerberos dla SMB z Entra ID (lub integracją z AD DS) i wymuszaj uprawnienia do udziałów/plików zgodnie z zasadą najmniejszych uprawnień. Wymagaj szyfrowania SMB. Uzasadnienie: dostęp powiązany z tożsamością z zabezpieczeniem transportu przez SMB; brak kluczy współdzielonych w przestrzeni użytkownika.
• Usługa Table: Używaj SAS z rygorystycznymi ograniczeniami IP/czasu i unikaj Account SAS. Uzasadnienie: granularność na poziomie usługi nie jest tak bogata; agresywnie ograniczaj zakres.

Izolacja sieciowa dla wszystkich usług magazynu

• Reguły zapory sieciowej (firewall) dla magazynu: Ogranicz dostęp do wybranych publicznych zakresów IP tylko wtedy, gdy użycie Private Link nie jest możliwe. Uzasadnienie: zmniejsza powierzchnię ataku, ale ruch nadal przechodzi przez publiczny internet.
• Prywatne punkty końcowe (private endpoints): Preferuj Private Link dla usług Blob, Queue, Table i Files. Mapuj prywatne strefy DNS na nazwy specyficzne dla zasobów. Ustaw dostęp z sieci publicznej na Wyłączony (Disabled). Uzasadnienie: ruch pozostaje w sieci szkieletowej Azure; tożsamość zasobu jest weryfikowana przez prywatny DNS; łagodzi ryzyko eksfiltracji do podobnie wyglądających usług.
• Punkty końcowe usługi (service endpoints) i zasady: Jeśli Private Link nie jest opcją, włącz punkty końcowe usługi i zastosuj zasady punktów końcowych usługi, aby ograniczyć ruch wychodzący (egress) do określonych kont magazynu. Uzasadnienie: ogranicza ruch nawet przy wyjściu z sieci wirtualnej; ogranicza ryzyko wysłania danych na konta należące do atakującego.

Ustawienia operacyjne do standaryzacji

• Wymuszaj tylko HTTPS, minimum TLS 1.2.
• Wyłącz dostęp za pomocą kluczy współdzielonych dla Blob i Queue, jeśli używasz AD (zależne od wsparcia funkcji).
• Zasady niezmienności (immutability policies) na krytycznych kontenerach/udziałach w celu zapewnienia retencji regulacyjnej i odporności na ransomware.

Szyfrowanie i zarządzanie kluczami

Warstwy szyfrowania w spoczynku (at rest)

• Klucze zarządzane przez usługę (SMK): Domyślne szyfrowanie po stronie serwera zarządzane przez Azure. Uzasadnienie: zerowy narzut operacyjny; odpowiednie dla wielu obciążeń.
• Klucze zarządzane przez klienta (CMK): Klucze w Key Vault lub Managed HSM dla usług Storage, SQL i Cosmos DB. Uzasadnienie: eksternalizowana granica zaufania, kontrola klienta nad rotacją/odwoływaniem kluczy oraz dowody zgodności (compliance).
• Szyfrowanie infrastruktury (podwójne szyfrowanie): Dodatkowa warstwa wykorzystująca oddzielne klucze. Uzasadnienie: obrona w głąb (defense-in-depth) na wypadek obejścia szyfrowania nośnika danych lub skompromitowania granicy kryptograficznej.

Rotacja kluczy i operacje

• Klucze SMK rotują się automatycznie; nie jest wymagane żadne działanie.
• Klucze CMK rotuje się, tworząc nową wersję klucza, nadając uprawnienia wrap/unwrap i ponownie wskazując zasób na najnowszą wersję (lub na referencję do klucza bez wersji, jeśli jest to wspierane). Uzasadnienie: rotacja bez zakłóceń z audytowalną zmianą.
• Chroń klucze za pomocą usuwania nietrwałego (soft delete) i ochrony przed przeczyszczeniem (purge protection) w Key Vault; kontroluj administratorów przez RBAC, a płaszczyznę danych przez zasady dostępu lub RBAC (dla Managed HSM użyj RBAC). Uzasadnienie: zapobiega nieodwracalnej utracie kluczy i wymusza zasadę najmniejszych uprawnień.

Przykład: ustawienie klucza CMK dla konta magazynu

az storage account update \
  --name mystorage \
  --resource-group rg-secure \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.KeyVault/vaults/mykv \
  --encryption-key-name stor-cmk

Zakresy szyfrowania (encryption scopes)

• Używaj zakresów szyfrowania na poziomie kontenera w usłudze Storage, gdy różne zestawy danych wymagają odrębnych kluczy. Uzasadnienie: segmentacja promienia rażenia i umożliwienie zróżnicowanych cykli życia kluczy.

Bezpieczeństwo platformy bazodanowej: Azure SQL i Azure Cosmos DB

Uwierzytelnianie i dostęp w Azure SQL

• Uwierzytelnianie Microsoft Entra: Utwórz administratora Azure AD na poziomie serwera; używaj użytkowników zawartych w bazie danych (contained database users) (CREATE USER FROM EXTERNAL PROVIDER). Uzasadnienie: unika loginów/haseł SQL i umożliwia stosowanie Conditional Access oraz PIM.
• Użytkownicy zawarci (Contained users): Tożsamość istnieje w bazie danych, a nie w bazie master. Uzasadnienie: upraszcza przywracanie geograficzne (geo-restore) i przełączanie awaryjne (failover) bez konieczności ponownego aprowizowania loginów.
• Reguły zapory sieciowej (Firewall): Unikaj ogólnych reguł dla adresów IP klientów; preferuj Private Link z wyłączonym publicznym dostępem sieciowym. Jeśli reguły IP są wymagane, ogranicz je do dokładnych adresów i zautomatyzuj ich przegląd. Uzasadnienie: zawęża powierzchnię ataku i ogranicza wykrywalność przez publiczne punkty końcowe.
• Prywatne punkty końcowe (Private endpoints): Kieruj cały ruch płaszczyzny danych (data-plane) przez VNet z prywatnym DNS. Uzasadnienie: eliminuje ekspozycję na sieć publiczną i upraszcza zapobieganie eksfiltracji danych.
• Wzorce uwierzytelniania: Używaj uwierzytelniania zintegrowanego z Active Directory (Active Directory Integrated) (dla urządzeń przyłączonych do domeny) lub interaktywnego/kodu urządzenia (interactive/device code) w celu uzyskania tokenów; obciążenia usługowe powinny używać tożsamości zarządzanych (managed identities). Uzasadnienie: eliminuje hasła i umożliwia zarządzanie cyklem życia/politykami tokenów.

Funkcje ochrony danych

• Transparent Data Encryption (TDE): Domyślnie włączone; szyfruje dane/logi/kopie zapasowe. Uzasadnienie: chroni dane w spoczynku (at-rest) bez zmian w aplikacji. Używaj TDE z kluczem zarządzanym przez klienta (CMK) dla zewnętrznej kontroli.
• Always Encrypted: Szyfrowanie po stronie klienta dla wrażliwych kolumn z kluczami w Key Vault. Uzasadnienie: uniemożliwia operatorom SQL lub silnikowi bazy danych wgląd w tekst jawny; stosuj dla pól PII/PCI.
• Dynamic Data Masking (DDM): Maskuje (zaciemnia) wyniki zapytań dla nieuprzywilejowanych użytkowników. Uzasadnienie: ogranicza przypadkową ekspozycję danych, ale nie jest granicą bezpieczeństwa; łącz z RBAC.
• Inspekcja (Auditing): Wysyłaj logi do Log Analytics, Event Hubs lub Storage. Uzasadnienie: tworzy niezmienny ślad audytowy na potrzeby dochodzeń i zgodności z regulacjami.

Przykład: włączenie inspekcji na poziomie serwera do Log Analytics

az sql server audit-policy update \
  --name sql-secure \
  --resource-group rg-secure \
  --state Enabled \
  --log-analytics-workspace /subscriptions/<subId>/resourceGroups/rg-secure/providers/Microsoft.OperationalInsights/workspaces/la-secure

Microsoft Defender for SQL

• Vulnerability Assessment (VA): Tworzy wzorce bazowe (baselines) i skanuje schemat/konfigurację; eksportuje wyniki do storage; integruje z bramkami DevSecOps. Uzasadnienie: zapewnia ciągłą higienę i wykrywanie zmian (drift detection) z jasnymi wskazówkami dotyczącymi naprawy.
• Threat Detection: Wykrywa SQL injection, anomalne logowania, logowania z nietypowych lokalizacji, nadużycia uprawnień. Uzasadnienie: zarządzane wykrywanie z niskim narzutem operacyjnym; uzupełnia kontrole sieciowe.
• Reakcja na alerty: Kieruj alerty do Logic Apps, e-mail, SIEM. Twórz podręczniki (playbooks) do wstępnej analizy (triage), zawieszania użytkowników, unieważniania tokenów i zaostrzania reguł zapory. Uzasadnienie: skodyfikowana reakcja skraca średni czas powstrzymania zagrożenia (MTTC).

Bezpieczeństwo Azure Cosmos DB

• Klucze i tokeny: Klucze podstawowe/dodatkowe (primary/secondary) mają wysokie uprawnienia; regularnie je rotuj. Preferuj Azure AD RBAC dla operacji na płaszczyźnie danych (data-plane) z rolami takimi jak Cosmos DB Built-in Data Contributor/Reader. Uzasadnienie: dostęp powiązany z tożsamością z możliwością użycia Conditional Access i inspekcji.
• Kontrole sieciowe: Lista dozwolonych adresów IP w zaporze sieciowej jako rozwiązanie awaryjne; Private Endpoints jako domyślna ścieżka; wyłącz dostęp publiczny, jeśli to możliwe. Uzasadnienie: gwarantowana kontrola ścieżki i walidacja punktu końcowego.
• Szyfrowanie: Domyślnie włączone dla danych w spoczynku (at rest); włącz klucze zarządzane przez klienta (CMK) dla dodatkowej kontroli. Uzasadnienie: spełnia zewnętrzne wymagania kryptograficzne i zapewnia rozdział obowiązków.
• Logi diagnostyczne i metryki: Włącz DataPlaneRequests, ControlPlaneRequests i kategorie specyficzne dla API (np. MongoRequests). Uzasadnienie: zapewnia kompleksową obserwowalność (observability) dla wzorców dostępu, dławienia (throttling) i anomalnych żądań.

Monitorowanie, klasyfikacja i kontrole eksfiltracji

Wpisy tajne i parametry połączenia oparte na Key Vault

• Używaj tożsamości zarządzanych do pobierania wpisów tajnych/kluczy w czasie rzeczywistym; nigdy nie przechowuj wpisów tajnych w kodzie lub ustawieniach. Uzasadnienie: eliminuje to rozprzestrzenianie się poświadczeń i konieczność rotacji wpisów tajnych w aplikacjach.
• Referencja do Key Vault w App Service/Functions

ConnectionStrings__Sql=@Microsoft.KeyVault(SecretUri=https://mykv.vault.azure.net/secrets/sql-connstr/)

• Gdy to możliwe, preferuj tokeny dostępu Azure AD do SQL zamiast parametrów połączenia opartych na wpisach tajnych. Uzasadnienie: silniejsze zasady i możliwość odwołania.

Ochrona informacji i klasyfikacja danych

• Etykiety poufności Microsoft Purview Information Protection: Stosuj etykiety z szyfrowaniem i prawami użytkowania dla dokumentów i e-maili; zintegruj z automatycznym etykietowaniem. Uzasadnienie: trwała ochrona wykraczająca poza granice przechowywania.
• SQL Information Protection (Azure SQL): Używaj wbudowanego odkrywania i klasyfikacji danych, rekomenduj etykiety dla kolumn i eksportuj do Purview. Uzasadnienie: centralne zarządzanie i spójne zasady w całym ekosystemie danych.

Kontrole eksfiltracji danych i bezpieczne wzorce dostępu

• Priorytet dla Private Link: Dla usług Storage, SQL i Cosmos DB. Wyłącz publiczne punkty końcowe. Uzasadnienie: zapobiega dostępowi z publicznego internetu i wymusza pochodzenie ruchu z zatwierdzonych sieci VNet.
• Filtrowanie ruchu wychodzącego (egress): Używaj Azure Firewall z tagami FQDN i regułami DNAT, które zezwalają tylko na wymagane punkty końcowe Azure; dodaj zasady punktów końcowych usług (service endpoint policies), gdy Private Link jest niepraktyczny. Uzasadnienie: lista dozwolonych połączeń wychodzących blokuje wyciek danych do punktów końcowych kontrolowanych przez atakującego.
• Reguły instancji zasobów: W zaporze sieciowej Storage zezwalaj na dostęp tylko określonym zaufanym instancjom zasobów (np. obszarowi roboczemu Synapse). Uzasadnienie: wiąże dostęp ze znanymi producentami/konsumentami, a nie tylko z sieciami.
• Wzmacnianie zabezpieczeń SAS: W miarę możliwości używaj SAS z delegowaniem użytkownika, ograniczaj do HTTPS, stosuj restrykcje adresów IP, minimalne uprawnienia i najkrótszy możliwy czas życia; powiąż z przechowywanymi zasadami dostępu w celu odwołania. Uzasadnienie: zmniejsza ryzyko niewłaściwego użycia tokenu i upraszcza jego unieważnienie w sytuacjach awaryjnych.
• AKS i punkty końcowe usług: Jeśli polegasz na punktach końcowych usług, użyj Azure CNI, aby pody otrzymywały adresy IP z VNet i dziedziczyły dostęp do punktu końcowego. Uzasadnienie: przenosi ruch kontenerów do natywnych mechanizmów kontroli VNet; w przeciwnym razie punkty końcowe nie mają zastosowania do ruchu podów poddanego translacji NAT.
• Rejestrowanie i analityka: Włącz dzienniki diagnostyczne Storage, SQL i Cosmos DB do Log Analytics; utwórz alerty dotyczące anomalii w wolumenie danych, nagłych wzrostów wydawania tokenów SAS i częstych błędów 403. Uzasadnienie: wczesne wykrywanie prób eksfiltracji.

Praktyczny scenariusz problemowy

Spotify musi zapobiec eksfiltracji danych z podsieci deweloperskich i obciążeń AKS do nieautoryzowanych punktów końcowych Storage i SQL, jednocześnie umożliwiając potokom CI/CD uruchamianie testów integracyjnych.

1. Wyłącz publiczny dostęp sieciowy i utwórz prywatne punkty końcowe (Private Endpoints) dla wszystkich produkcyjnych kont Storage i serwerów Azure SQL. Uzasadnienie: Wymusza przepływ całego ruchu w płaszczyźnie danych przez Private Link, eliminując publiczny ruch przychodzący/wychodzący i umożliwiając ścisłe egzekwowanie pochodzenia za pośrednictwem sieci VNet i prywatnego DNS.

2. Skonfiguruj prywatne strefy DNS z rekordami A mapującymi nazwy FQDN zasobów storage i baz danych na adresy IP prywatnych punktów końcowych; połącz wszystkie wymagane sieci VNet. Uzasadnienie: Zapobiega wyciekowi zapytań DNS do publicznych punktów końcowych i zapewnia, że klienci rozpoznają nazwy na docelowe zasoby prywatne.

3. W zaporach sieciowych Storage dodaj reguły instancji zasobów tylko dla tożsamości produkcyjnego klastra AKS i zestawu skalowania agentów kompilacji; ustaw domyślną akcję na odrzucenie (deny). Uzasadnienie: Nawet w obrębie tej samej sieci VNet tylko zatwierdzone tożsamości zasobów mogą uzyskać dostęp do konta, co udaremnia ruch boczny (lateral movement) i eksfiltrację z niezaufanych obciążeń.

4. Wymuś stosowanie Azure CNI w AKS i włącz punkty końcowe usług z zasadami punktów końcowych usług (service endpoint policies), aby zezwolić przestrzeniom nazw deweloperskich na dostęp tylko do dedykowanego, nieprodukcyjnego konta storage. Uzasadnienie: Pody deweloperskie uzyskują adresy IP z VNet, dzięki czemu zasady sieciowe mają zastosowanie; zasady punktów końcowych ograniczają każdy ruch nieprywatny wyłącznie do zatwierdzonych kont.

5. Zastąp klucze współdzielone mechanizmem Azure AD RBAC dla Blob i Queue w kodzie aplikacji; tam, gdzie współdzielenie jest nieuniknione na potrzeby testów, wydawaj tokeny SAS z delegowaniem użytkownika, używając przechowywanych zasad dostępu i 1-godzinnego czasu wygaśnięcia. Uzasadnienie: Tokeny powiązane z tożsamością są audytowalne i odwoływalne; krótki czas życia SAS minimalizuje ryzyko w przypadku ujawnienia tokenu w logach kompilacji.

6. Włącz Defender for SQL z wykrywaniem zagrożeń i oceną podatności (Vulnerability Assessment); przekieruj alerty i dzienniki audytu SQL do centralnego obszaru roboczego Log Analytics z automatycznymi aplikacjami Logic Apps do wstępnej analizy (triage) (wyłączanie użytkownika, odwoływanie sesji, dodawanie tymczasowej reguły blokującej w zaporze). Uzasadnienie: Zarządzane mechanizmy wykrywania przyspieszają powstrzymywanie ataków SQL injection i anomalii w dostępie, a scenariusze (playbooks) standaryzują i przyspieszają reakcję.

7. Użyj Key Vault dla kluczy zarządzanych przez klienta (CMK) chroniących TDE i zakresy szyfrowania Storage; włącz usuwanie nietrwałe (soft delete) i ochronę przed przeczyszczeniem (purge protection); dokonuj rotacji kluczy kwartalnie i aktualizuj odwołania do zasobów do najnowszej wersji klucza. Uzasadnienie: Zewnętrzna kontrola kryptograficzna z bezpieczną rotacją spełnia wymogi zgodności i zmniejsza ryzyko błędu operacyjnego.

8. Sklasyfikuj wrażliwe kolumny w Azure SQL za pomocą SQL Information Protection i dołącz je do Microsoft Purview; zastosuj etykiety poufności MIP do dalszych eksportów. Uzasadnienie: Trwałe etykietowanie podróżuje wraz z eksportowanymi danymi, ograniczając ich niewłaściwe użycie i umożliwiając narzędziom DLP egzekwowanie kontroli w różnych narzędziach i na różnych urządzeniach.

9. Zablokuj ruch wychodzący za pomocą Azure Firewall, zezwalając tylko na usługi Azure wymagane przez procesy kompilacji/testowania, używając tagów FQDN dla Storage i SQL oraz blokując wychodzący ruch HTTP(S) z użyciem symboli wieloznacznych. Uzasadnienie: Pozytywny model bezpieczeństwa zapewnia, że ruch może dotrzeć tylko do zatwierdzonych punktów końcowych, zapobiegając opuszczaniu danych do domen atakującego.

Ta sekwencja działań zapobiega dostępowi publicznemu, ogranicza, kto i co może uzyskać dostęp do danych, wiąże dostęp z tożsamościami, a nie z wpisami tajnymi, oraz operacjonalizuje monitorowanie i szybką reakcję – wszystko to przy jednoczesnym zachowaniu szybkości pracy deweloperów dzięki ograniczonym zakresowo i czasowo wyjątkom.

← Bezpieczeństwo Compute · Wszystkie domeny · Zarządzanie kluczami →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Microsoft →