Microsoft AZ-500: Bezpieczeństwo aplikacji i DevSecOps — 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.

Omówienie

Bezpieczeństwo aplikacji i DevSecOps w Azure koncentrują się na zapobieganiu niewłaściwemu użyciu tożsamości, ochronie ruchu przychodzącego (ingress) i interfejsów API, przesuwaniu zabezpieczeń w lewo w potokach (pipelines), zabezpieczaniu sekretów w spoczynku (at rest) i w tranzycie (in transit) oraz egzekwowaniu solidnego nadzoru nad wydaniami. Efektywne projekty eliminują długożyjące sekrety, stosują zasadę najmniejszych uprawnień, walidują każdego wywołującego oraz instytucjonalizują ciągłe wykrywanie i naprawę w kodzie, zależnościach, infrastrukturze i środowisku uruchomieniowym.

Bezpieczna tożsamość aplikacji, ruch przychodzący i ochrona API

Bezpieczna tożsamość aplikacji w Microsoft Entra ID (Azure AD) zaczyna się od dobrze określonej rejestracji aplikacji i prawidłowego przepływu OAuth 2.0:

Uprawnienia delegowane mają zastosowanie, gdy użytkownik jest zalogowany, a zgoda może być ograniczona tylko do aplikacji zweryfikowanych wydawców lub zakresów zatwierdzonych przez administratora. Uprawnienia aplikacji (tylko dla aplikacji) zawsze wymagają zgody administratora, ponieważ autoryzują demony lub usługi działające w tle bez udziału użytkownika.
Wymuszaj zasadę najmniejszych uprawnień, przyznając tylko minimalne wymagane zakresy lub role aplikacji i wymagając przeglądu żądań zgody przez administratora. Wyłącz zgodę użytkownika końcowego lub zezwalaj na nią tylko dla zweryfikowanych wydawców o niskim ryzyku, aby ograniczyć phishing oparty na zgodach.
Preferuj poświadczenia certyfikatowe lub tożsamości federacyjne zamiast kluczy tajnych klienta (client secrets). Certyfikaty zapewniają silniejsze gwarancje i przewidywalną rotację. Konfiguruj krótki czas życia i automatyzuj rotację. Blokuj przepływy klienta publicznego, chyba że są niezbędne.
W przypadku usług Azure używaj tożsamości zarządzanych zamiast sekretów aplikacji. Przypisuj role płaszczyzny danych, takie jak Key Vault Secrets User lub Storage Blob Data Reader, i ograniczaj dostęp sieciowy za pomocą Private Endpoints, tam gdzie to stosowne.

Application Gateway WAF v2 i Azure Front Door WAF chronią publiczny ruch przychodzący (ingress) przed zagrożeniami z listy OWASP Top 10:

Włącz najnowszy, zarządzany przez Microsoft zestaw reguł OWASP Core Rule Set i uruchom go w trybie zapobiegania (Prevention) po dostrojeniu. Początkowo używaj oceny anomalii (anomaly scoring), aby zredukować fałszywe alarmy (false positives) na etapie uczenia się.
Skonfiguruj niestandardowe reguły do geofencingu, blokowania na podstawie reputacji IP, wymuszania nagłówków i limitów rozmiaru żądań. W przypadku Front Door dodaj reguły ograniczające szybkość (rate-limit) na adres IP klienta, aby osłabić ataki typu credential stuffing i podstawowe ataki L7 DoS.
Terminuj TLS przy użyciu silnych pakietów szyfrów (cipher suites) i polityk; używaj szyfrowania TLS na całej trasie (end-to-end) aż do serwera źródłowego (origin). W scenariuszach wymagających mTLS skonfiguruj walidację certyfikatu klienta na nasłuchach (listeners) Application Gateway.
Dołączaj polityki WAF precyzyjnie do nasłuchów/tras; używaj wykluczeń reguł tylko wtedy, gdy w pełni rozumiesz przyczynę fałszywego alarmu. Przesyłaj strumieniowo logi WAF do Log Analytics w celu inżynierii detekcji i reagowania na incydenty.

API Management (APIM) wymusza wielowarstwową postawę bezpieczeństwa:

Waliduj tokeny OAuth na bramie (gateway) z rygorystycznymi sprawdzeniami wystawcy (issuer), odbiorcy (audience) i zakresu (scope). Wymagaj wszędzie HTTPS i wymuszaj mTLS, gdy wymaga tego granica zaufania klienta.
Łącz klucze subskrypcji z OAuth w celu zapewnienia obrony w głąb (defense-in-depth) i do ograniczania przepustowości (throttling) na podstawie tożsamości. Używaj kluczy subskrypcji na poziomie produktu, aby partycjonować konsumentów i rotować klucze bez zakłócania działania innych.
Stosuj ograniczenia szybkości (rate limiting) i przydziały (quotas) z granularnością na konsumenta, na zakres lub na subskrypcję. Używaj filtrowania IP, aby dodawać do białej listy sieci partnerskie, gdy jest to stosowne.
Chroń usługi backendowe za pomocą wzajemnego TLS (mutual TLS) lub tożsamości zarządzanych. Przechowuj sekrety jako Nazwane Wartości (Named Values) oparte na odwołaniach do Key Vault, aby unikać jawnego tekstu w konfiguracji.

Przykładowa polityka APIM do wymuszania zakresu JWT i ograniczania przepustowości:

<policies>
  <inbound>
    <base />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401" require-scheme="Bearer">
      <openid-config url="https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration" />
      <audiences>
        <audience>api://your-api-app-id</audience>
      </audiences>
      <required-claims>
        <claim name="scp">
          <value>read.items</value>
        </claim>
      </required-claims>
    </validate-jwt>
    <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Subscription?.Key ?? context.Request.IpAddress)" />
  </inbound>
  <backend><base /></backend>
  <outbound><base /></outbound>
  <on-error><base /></on-error>
</policies>

Wzmacnianie bezpieczeństwa potoków DevSecOps i Defender for DevOps

Azure DevOps i GitHub Actions muszą uwierzytelniać się w Azure bez długożyjących sekretów:

Używaj federacji tożsamości obciążeń (workload identity federation, OIDC) dla połączeń usług (service connections). Utwórz rejestrację aplikacji/jednostkę usługi (service principal) w Entra ID, a następnie dodaj poświadczenie federacyjne, które wiąże repozytorium, gałąź i przepływ pracy/środowisko z tożsamością. Daje to krótkotrwałe tokeny bez przechowywanych sekretów i wspiera ograniczanie uprawnień zgodnie z zasadą najmniejszych uprawnień za pomocą Azure RBAC.
Zabezpiecz uprawnienia potoku: wymagaj zatwierdzeń do używania połączeń usług, ogranicz potok do chronionych gałęzi i wyłącz opcję „Zezwalaj skryptom na dostęp do tokenu OAuth”, chyba że jest to konieczne. Używaj grup zmiennych i sekretów z maskowaniem; nie zezwalaj na wyświetlanie sekretów w logach za pomocą poleceń logowania. W GitHub preferuj sekrety środowiskowe i organizacyjne nad sekretami repozytorium w celu scentralizowanej kontroli i używaj ustawień „zapobiegaj sekretom w logach” w hostowanych agentach (runners), jeśli to możliwe.
Zastosuj reguły ochrony środowiska: wymagani recenzenci, sprawdzenia (np. zgłoszenia zarządzania zmianą, zaliczone testy) i zatwierdzenia czasowe.

Tworzenie poświadczenia federacyjnego za pomocą Azure CLI (przykład dla GitHub OIDC):

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"github-oidc-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:org/repo:ref:refs/heads/main",
    "audiences":["api://AzureADTokenExchange"]
  }'

Microsoft Defender for DevOps integruje się z Azure Repos i GitHub, aby ujawniać:

Wyniki analizy bezpieczeństwa kodu (SAST) w popularnych językach; adnotacje w pull requestach podkreślają nowe problemy, aby zapobiegać regresjom.
Ryzyko związane z zależnościami (SCA) wykorzystujące dane o podatnościach dla bibliotek OSS wraz z zaleceniami dotyczącymi naprawy i wersjami z poprawkami.
Wykrywanie ujawnionych sekretów i zalecana rotacja dla wyciekniętych tokenów/kluczy.
Błędne konfiguracje w kodzie infrastruktury (Infrastructure-as-Code) w ARM/Bicep/Terraform (np. publiczny magazyn, zbyt liberalne NSG) z nadzorem opartym na politykach i śledzeniem zmian (drift tracking). Wyniki są agregowane w Defender for Cloud z kontekstem repozytorium i potoku w celu priorytetyzacji. Blokuj wydania (gate releases) na podstawie progów ważności, aby zatrzymać niebezpieczne wdrożenia.

Zarządzanie sekretami i integracja z platformą

Key Vault zapewnia scentralizowane zarządzanie sekretami, kluczami i certyfikatami z kompleksowymi mechanizmami kontroli:

Wymuszaj ochronę przed trwałym usunięciem (purge protection) i usuwanie nietrwałe (soft delete), aby zapobiec nieodwracalnej utracie danych. Preferuj RBAC zamiast zasad dostępu (access policies) w celu ujednoliconej autoryzacji; włączaj Private Endpoints i wyłączaj publiczny dostęp sieciowy tam, gdzie to możliwe; włączaj logowanie do bezpiecznego obszaru roboczego (workspace).
App Service i Functions używają referencji do Key Vault w ustawieniach aplikacji (app settings) z wykorzystaniem tożsamości zarządzanych (managed identities); rotuj sekrety w sposób transparentny, bez konieczności ponownego wdrażania.
AKS pobiera sekrety w czasie działania za pomocą Secrets Store CSI Driver z dostawcą (provider) dla Azure Key Vault, uwierzytelniając się za pomocą Azure AD Workload Identity (zalecane). Unikaj umieszczania sekretów w postaci jawnego tekstu w obiektach Kubernetes Secret.

Przykład referencji do Key Vault w App Service:

Name: DbConn
Value: @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnString/23a1...)

AKS SecretProviderClass (wersja skrócona):

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: kv-secrets
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "false"
    useWorkloadIdentity: "true"
    keyvaultName: kv-prod
    tenantId: <tenant-id>
    objects: |
      array:
        - | 
          objectName: api-key
          objectType: secret

Potoki (pipelines) powinny pobierać sekrety w czasie wykonywania zadania (job runtime):

Azure DevOps: Użyj zadania Key Vault (Key Vault task) z połączeniem usługi (service connection) opartym na tożsamości zarządzanej; ogranicz pobieranie sekretów do minimalnej niezbędnej liczby etapów (stages).
GitHub Actions: Użyj akcji azure/login do uwierzytelniania przez OIDC oraz azure/keyvault do pobierania tylko wymaganych sekretów.

Bezpieczny SDLC, kontenery, logowanie i wydania

Praktyki bezpiecznego cyklu rozwoju oprogramowania (Secure SDLC) redukują ryzyko przed wdrożeniem:

Wczesne modelowanie zagrożeń za pomocą STRIDE lub równoważnej metodyki zapewnia, że uwierzytelnianie, autoryzacja i przepływy danych są jawnie weryfikowane. Aktualizuj modele wraz z ewolucją architektury.
SAST jest uruchamiany przy każdym PR; przerywaj kompilacje w przypadku problemów o wysokiej wadze z jasno określoną odpowiedzialnością. DAST jest wykonywany po wdrożeniu do slotu/środowiska przejściowego (staging) z bezpiecznymi danymi testowymi.
SCA stale monitoruje pakiety; wymusza stosowanie ustalonych wersji i zgodność z licencjami.
Rygorystyczny przegląd kodu z politykami gałęzi: wymagani recenzenci, połączone elementy pracy, walidacja kompilacji i podpisane commity.

Bezpieczeństwo obrazów kontenerów jest fundamentalne dla integralności łańcucha dostaw:

Generuj i przechowuj SBOM (SPDX lub CycloneDX) podczas kompilacji, publikuj je obok obrazów jako artefakty OCI w celu zapewnienia identyfikowalności.
Skanuj obrazy przed wypchnięciem (pre-push) i w spoczynku (at-rest) w rejestrach za pomocą skanowania kontenerów w Defender for Cloud; blokuj promocję w przypadku krytycznych wykryć.
Podpisuj obrazy i atestacje za pomocą Notary v2/artefaktów OCI z użyciem cosign. Wymuszaj weryfikację podpisu przy kontroli dostępu (admission) (np. za pomocą Gatekeeper/OPA lub AKS Policy dla Kubernetes).
Mechanizmy kontroli w Azure Container Registry (ACR): wyłącz użytkownika administracyjnego, ogranicz dostęp sieciowy za pomocą Private Endpoints, włącz klucze zarządzane przez klienta, używaj tokenów o zakresie repozytorium dla szczegółowej kontroli dostępu oraz stosuj wzorce retencji i kwarantanny. Nadawaj tylko uprawnienie AcrPull środowiskom uruchomieniowym i AcrPush systemom CI. W przypadku AKS, dołącz ACR za pomocą wspieranego polecenia, aby utworzyć poprawne przypisanie, zamiast konfigurować role ręcznie.
Jeśli kontenery muszą używać punktów końcowych usługi VNet z hosta VM, zainstaluj wspieraną wtyczkę CNI, aby ruch z poszczególnych kontenerów pochodził z podsieci.

Logowanie aplikacji nie może prowadzić do wycieku sekretów ani danych osobowych (PII):

Skonfiguruj Application Insights do redagowania lub usuwania wrażliwych pól za pomocą Telemetry Processors; unikaj logowania surowych nagłówków, tokenów lub ładunków (payloads), które zawierają sekrety lub dane osobowe. Ogranicz pola danych do potrzeb biznesowych i włącz próbkowanie (sampling), aby zmniejszyć ekspozycję.
Kieruj diagnostykę do dedykowanego obszaru roboczego Log Analytics z rygorystycznym RBAC (co najmniej uprawnienie Log Analytics Reader) i niezmienną pamięcią masową przy eksporcie do Storage (blokady retencji oparte na czasie).
Chroń punkty końcowe przyjmowania i odpytywania telemetrii za pomocą Private Link, tam gdzie jest to dostępne. Przechowuj parametry połączenia instrumentacji w Key Vault i regularnie je rotuj.

Bezpieczne praktyki wydawania oprogramowania wymuszają kontrolowaną promocję:

Bramki zatwierdzania w Azure DevOps Environments lub GitHub Environments wymagają wyznaczonych recenzentów, zaliczenia testów jakości i powiązanych zgłoszeń zmian. Automatyzuj okna wstrzymania dla wdrożeń o wysokim ryzyku.
Stosuj zasadę najmniejszych uprawnień do połączeń usług i agentów; ograniczaj ich zakres do grup zasobów lub subskrypcji dla każdego środowiska. Używaj tożsamości zarządzanych z wąsko zdefiniowanymi rolami.
Segreguj środowiska Dev, Test i Prod za pomocą oddzielnych subskrypcji, VNetów, Key Vaults i ACR; nie zezwalaj na ruch boczny (lateral movement) między środowiskami i używaj różnych sekretów/kluczy w każdym z nich.

Praktyczny scenariusz problemu

Firma Fabrikam, Inc. publikuje w internecie wielodostępowe (multi-tenant) API SaaS. Wymagania: blokowanie ataków z listy OWASP Top 10, walidacja zakresów OAuth dla każdej operacji, zapobieganie przechowywaniu sekretów w repozytoriach, ograniczanie (throttling) nadużywających klientów i zapewnienie, że w środowisku produkcyjnym uruchamiane są tylko podpisane obrazy kontenerów.

Fronting i WAF

Wdróż Azure Front Door Standard z polityką WAF używającą najnowszego zarządzanego zestawu reguł OWASP w trybie zapobiegania (Prevention), a także niestandardowe reguły ograniczania szybkości (rate-limit) i blokowanie geograficzne. Uzasadnienie: scentralizowane, globalne wymuszanie zasad na brzegu sieci (edge) zmniejsza powierzchnię ataku i absorbuje ataki warstwy 7 (L7), zanim dotrą one do źródła (origin).

Polityka bramy API

Umieść Azure API Management za Front Door; zaimplementuj politykę validate-jwt ze sprawdzaniem wystawcy (issuer), odbiorcy (audience) i zakresu (scope) dla każdej operacji oraz klucze subskrypcji na poziomie produktu z limitami (quotas). Uzasadnienie: APIM zapewnia wymuszanie zasad z uwzględnieniem tożsamości oraz izolację dzierżawców; klucze w połączeniu z OAuth oferują obronę warstwową i precyzyjne ograniczanie ruchu.

Tożsamość i zgody

Zarejestruj aplikacje SPA i demony w Entra ID z delegowanymi zakresami dla przepływów użytkownika i rolami aplikacji dla demona; ogranicz zgodę użytkownika do zweryfikowanych wydawców i wymagaj zgody administratora dla uprawnień aplikacji. Użyj poświadczeń certyfikatowych dla demona. Uzasadnienie: eliminuje to słabe sekrety, wymusza zasadę najmniejszych uprawnień i zmniejsza ryzyko phishingu z wykorzystaniem zgód (consent phishing).

DevSecOps z OIDC

Skonfiguruj GitHub Actions do używania federacji OIDC z jednostką usługi (service principal) Azure o zakresie ograniczonym do subskrypcji nieprodukcyjnej dla kompilacji oraz z jednostką o zakresie produkcyjnym dla wydania, każda z minimalnymi rolami (AcrPush dla kompilacji, Contributor ograniczony do produkcyjnej grupy zasobów dla wydania). Uzasadnienie: brak przechowywanych sekretów; promień rażenia (blast radius) zminimalizowany dla każdego środowiska.

Łańcuch dostaw kontenerów

Buduj obrazy za pomocą ACR Tasks, generuj SBOM (CycloneDX) i podpisuj obrazy za pomocą cosign; przechowuj atestacje jako artefakty OCI. Skonfiguruj kontrolę dostępu (admission) w AKS za pomocą polityki wymagającej ważnych podpisów. Uzasadnienie: pochodzenie i integralność są weryfikowalne w momencie wdrożenia, co blokuje zmodyfikowane obrazy.

Kontrola rejestru i środowiska uruchomieniowego

Wyłącz użytkownika administracyjnego ACR, włącz Private Endpoint, przypisz rolę AcrPull do tożsamości kubelet w AKS za pomocą wspieranego przepływu attach-acr i włącz skanowanie obrazów w Defender for Cloud. Uzasadnienie: wzmocnienie zabezpieczeń sieci i tożsamości usuwa domyślne luki (backdoors); skanowanie wykrywa znane luki CVE przed uruchomieniem.

Secrety i konfiguracja

Używaj Key Vault z Private Endpoint i RBAC; App Service i Functions korzystają z odwołań do Key Vault, a AKS używa Secret Store CSI z Workload Identity. Uzasadnienie: sekrety nigdy nie znajdują się w repozytoriach ani w konfiguracjach aplikacji; ich rotacja jest scentralizowana i audytowalna.