Microsoft AZ-400: Bezpieczeństwo, zgodność i DevSecOps — Przewodnik do nauki

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

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

Przegląd

Bezpieczeństwo, zgodność i DevSecOps w potokach dostarczania zorientowanych na Azure wymagają przesunięcia wykrywania ryzyka na jak najwcześniejsze etapy, ciągłego egzekwowania polityk i automatyzacji zbierania dowodów. Skuteczne wdrożenia unifikują testowanie bezpieczeństwa aplikacji (SAST/DAST/SCA), zarządzanie sekretami, skanowanie infrastruktury jako kod (IaC) oraz kontrole regulacyjne w cyklu życia CI/CD. W Azure DevOps i GitHub oznacza to uruchamianie analizatorów przy każdym pull requeście, bramkowanie merge’y za pomocą progów jakości, wdrażanie z użyciem tożsamości o najniższych uprawnieniach, które pobierają ograniczone czasowo sekrety z Azure Key Vault, oraz ciągłe monitorowanie postawy bezpieczeństwa za pomocą Microsoft Defender for DevOps i Defender for Cloud. Celem jest nie tylko znajdowanie problemów, ale także zapobieganie dotarciu niebezpiecznych zmian do chronionych zasobów, udowadnianie zgodności poprzez ścieżki audytu i utrzymanie bezpiecznej szybkości działania.

Bezpieczeństwo typu shift-left, mitygacje OWASP Top 10 i umacnianie potoku

Bezpieczeństwo typu shift-left zaczyna się od SAST i SCA w czasie obsługi pull requestów, wzbogaconych o skanowanie sekretów i ukierunkowane DAST przed promocją do kolejnego środowiska. SAST ujawnia podatności na poziomie kodu, takie jak punkty wstrzyknięcia (injection points), niebezpieczne deserializatory i brakujące kodowanie danych wyjściowych. Zintegruj SonarQube/SonarCloud lub GitHub code scanning (np. CodeQL), aby analizować każdy zestaw zmian; ozdabiaj pull requesty problemami powiązanymi z konkretnymi liniami kodu; i egzekwuj bramki jakości, które przerywają build, gdy progi podatności lub pokrycia kodu nie są spełnione. Skup SAST na klasach z OWASP Top 10:

Injection: wymagaj użycia zparametryzowanych zapytań/ORM, waliduj/normalizuj dane wejściowe i zabroń dynamicznego SQL/konkatenacji stringów. Wymuszaj to za pomocą zestawów reguł SAST i testów jednostkowych, które potwierdzają użycie sprawdzonych pomocników dostępu do danych.
Cross-Site Scripting (XSS): wymagaj kodowania danych wyjściowych i Content Security Policy. Analiza skażenia (taint analysis) w SAST powinna śledzić niezaufane dane wejściowe do miejsc docelowych (sinks), takich jak innerHTML czy Response.Write.
Cross-Site Request Forgery (CSRF): wymuszaj użycie tokenów anty-CSRF i ciasteczek SameSite. Potoki mogą uruchamiać analizatory frameworka, aby upewnić się, że odpowiednie middleware/ustawienia są włączone.
Insecure Deserialization: zabroń używania niebezpiecznych serializatorów binarnych/XML, ogranicz dozwolone typy i preferuj serializatory JSON skonfigurowane z bezpiecznymi ustawieniami domyślnymi. Sprawdzenia SAST i polityki zależności zapobiegają użyciu bibliotek o znanych podatnościach.

DAST waliduje działające buildy w środowisku stagingowym. Zautomatyzuj OWASP ZAP lub jego odpowiednik jako zadanie w potoku po wdrożeniu na środowisko nieprodukcyjne, używając uwierzytelnionych skanów i zestawu reguł dostosowanego do profilu Twojej aplikacji. Bramkuj promocję na podstawie bazowego poziomu podatności: blokuj przy nowo wprowadzonych znaleziskach o statusie High/Critical i utrwalaj zaakceptowane wyjątki z datą wygaśnięcia.

Software Composition Analysis (SCA) wykrywa podatne na ataki pakiety firm trzecich przed mergem. Użyj Dependabot do tworzenia PR-ów podbijających wersje oraz OWASP Dependency-Check do generowania raportów SBOM i CVE w CI. Wymuszaj zgodność licencyjną, definiując listy dozwolonych/zabronionych licencji (np. zabroń licencji copyleft dla produktów własnościowych) i przerywając buildy, które zawierają niedozwolone licencje. Skanowanie sekretów musi być uruchamiane przy commicie i w CI: wdrożyć GitHub Advanced Security secret scanning lub zintegrować Gitleaks/Microsoft Security DevOps, aby wyłapywać zahardkodowane poświadczenia, tokeny i klucze; blokuj merge, gdy wzorzec sekretu zostanie wykryty, i rotuj poświadczenia, których to dotyczy.

Umacnianie potoku (pipeline hardening) nie podlega negocjacjom. Zablokuj zabezpieczenia gałęzi (branch protections), wymagaj przeglądów PR i wymuszaj sprawdzanie statusu dla SAST/SCA/DAST. W Azure Pipelines używaj chronionych zasobów (protected resources), zatwierdzeń i sprawdzeń środowisk (environment approvals and checks) oraz wymaganych szablonów (required templates), aby standaryzować etapy bezpieczeństwa. Preferuj krótkotrwałe tokeny o najniższych uprawnieniach; całkowicie unikaj statycznych poświadczeń dzięki federacji tożsamości obciążeń (workload identity federation). Ogranicz agentów self-hosted do sieci prywatnych, nadawaj ich tożsamościom minimalne uprawnienia i wyłącz wstrzykiwanie skryptów, wymuszając szablony, które nie pozwalają na dowolne kroki skryptowe dla niezaufanych repozytoriów.

Sekrety, tożsamości, Azure Key Vault i rotacja certyfikatów

Azure Key Vault jest autorytatywnym magazynem dla sekretów, kluczy i certyfikatów. Zintegruj go bezpośrednio z CI/CD, aby wyeliminować sekrety w postaci jawnego tekstu:

Sekrety w potoku: w Azure DevOps połącz grupę zmiennych (variable group) z Key Vault za pomocą połączenia serwisowego (service connection) o zakresie ograniczonym tylko do wymaganych nazw sekretów. Sekrety są pobierane w czasie wykonania i maskowane w logach. W GitHub Actions użyj akcji azure/login z tożsamością federacyjną, aby uzyskać tokeny i wywoływać Key Vault; unikaj przechowywania kluczy klienta (client secrets) w ustawieniach repozytorium.
Dostęp z użyciem tożsamości zarządzanej: zawsze, gdy to możliwe, pozwól obciążeniom (workloads) i agentom wdrożeniowym uwierzytelniać się w Microsoft Entra ID za pomocą tożsamości zarządzanej (managed identity) lub federacji tożsamości obciążeń (workload identity federation), aby żadne sekrety nie były przechowywane. Ogranicz dostęp do Key Vault za pomocą RBAC lub polityk dostępu (access policies) zgodnie z zasadą najniższych uprawnień (tylko get/list dla określonych wersji sekretów; bez uprawnień purge/delete).
Rotacja certyfikatów: przechowuj certyfikaty TLS/MTLS w Key Vault Certificates z automatyczną rotacją za pośrednictwem zintegrowanych urzędów certyfikacji (CA). Skonfiguruj usługi konsumujące (App Service, Application Gateway, AKS Ingress przez CSI Secrets Store), aby odwoływały się do Key Vault, dzięki czemu odnowione certyfikaty będą pobierane bez ponownego wdrożenia. Użyj Event Grid dla zdarzeń certificateNearExpiry w Key Vault, aby wyzwolić runbook automatyzacji lub funkcję, która waliduje powiązania i rozgrzewa pamięć podręczną (cache). Śledź użycie wersji certyfikatów w manifestach wdrożeniowych; przypinaj wersje w razie potrzeby i świadomie przechodź na nowsze wersje podczas okien konserwacyjnych.

Zabezpiecz Key Vault za pomocą prywatnych punktów końcowych (private endpoints), reguł zapory sieciowej, ochrony przed trwałym usunięciem (purge protection), usuwania nietrwałego (soft-delete) oraz logowania do Log Analytics lub magazynu w celach audytowych. Odmów dostępu między tenantami, chyba że jest to wyraźnie uzasadnione, i rutynowo rotuj dostęp dla kont awaryjnych (break-glass accounts).

Zależności, kontenery, IaC i zgodność jako kod

Skanowanie zależności musi obejmować zarówno wady bezpieczeństwa, jak i licencjonowanie. Dependabot stale proponuje bezpieczne aktualizacje; używaj polityk przeglądu zależności, aby blokować PR-y wprowadzające podatne wersje. OWASP Dependency-Check (lub narzędzia natywne dla ekosystemu, takie jak npm audit, pip-audit) powinien być uruchamiany w CI w celu generowania SBOM-ów (CycloneDX/SPDX) i powodować niepowodzenie kompilacji, gdy naruszone zostaną progi krytyczności lub zasady licencyjne. W celu zaawansowanego zarządzania licencjami, połącz go z platformą SCA zdolną do egzekwowania polityk prawnych i przepływów pracy związanych z naprawą.

Bezpieczeństwo obrazów kontenerów zaczyna się w CI i jest kontynuowane w rejestrze oraz w środowisku uruchomieniowym:

Trivy: uruchamiaj jako krok w potoku (pipeline) do skanowania plików Dockerfile i zbudowanych obrazów pod kątem CVE w systemie operacyjnym/pakietach oraz błędnych konfiguracji; przerywaj kompilację w przypadku znalezisk o statusie Critical/High. Wymuszaj stosowanie minimalnych obrazów bazowych i kontenerów bez uprawnień roota (rootless).
Skanowanie podatności w Azure Container Registry: włącz Microsoft Defender for Containers, aby skanować obrazy podczas operacji push/import oraz zgodnie z harmonogramem. Prezentuj wyniki w Defender for Cloud, eksportuj je do elementów pracy (work items) i wymuszaj bramki wdrożeniowe (deployment gates), które blokują obrazy z nierozwiązanymi problemami o statusie Critical/High.
Defender for Containers: rozszerz ochronę na AKS/ECS/Kubernetes o wykrywanie zagrożeń w czasie rzeczywistym (runtime threat detection), kontrole w stylu kube-bench i kontrolę dostępu (admission control). Użyj polityki, aby pobierać obrazy tylko z zaufanych rejestrów ACR podpisanych za pomocą Notation/ACR content trust i weryfikuj podpisy w CI oraz przy przyjmowaniu do klastra (cluster admission).

Bezpieczeństwo IaC (Infrastructure as Code) zapewnia, że zasoby chmurowe są domyślnie bezpiecznie provisionowane:

Checkov i tfsec: skanuj manifesty Terraform i Kubernetes w poszukiwaniu niebezpiecznych konfiguracji (publiczny storage, otwarte grupy bezpieczeństwa, brak szyfrowania). Przerywaj kompilacje po przekroczeniu progów krytyczności; stwórz bazę referencyjną (baseline) dla istniejącego długu technicznego, aby skupić się na nowych/zmienionych zasobach.
Linting ARM/Bicep: włącz linter Bicep (bicepconfig.json) i ARM Template Tool Kit (arm-ttk), aby wymuszać zasady dotyczące tagowania, punktów końcowych tylko z HTTPS, kluczy zarządzanych przez klienta (customer-managed keys) i ustawień diagnostycznych. Połącz z wdrożeniami typu what-if, aby wykrywać dryf konfiguracji (drift) przed zastosowaniem zmian.

Zgodność jako kod (Compliance as Code) wykorzystuje Azure Policy i Defender for Cloud do ciągłego egzekwowania i raportowania kontroli:

Przypisuj inicjatywy Azure Policy zgodne z CIS, NIST, ISO 27001 lub wewnętrznymi standardami; wybieraj efekty takie jak Deny dla krytycznych zabezpieczeń (np. publiczne adresy IP w bazach danych), DeployIfNotExists dla diagnostyki i Audit dla obserwowalności. Przechowuj definicje polityk jako wersjonowane artefakty, testuj za pomocą potoków policy-as-code i promuj zmiany poprzez pull requesty.
Używaj pulpitów zgodności z przepisami (regulatory compliance dashboards) w Defender for Cloud, aby wizualizować zgodność kontroli w ramach subskrypcji i grup zarządzania. Integruj z Azure Monitor i eksportuj dowody (evidence) do Log Analytics lub Event Hubs w celu ich przyjęcia przez system SIEM.
Utrzymuj ścieżki audytu: Azure Activity Logs dla zdarzeń i przypisań polityk, Resource Graph dla zapytań o zgodność, logi audytowe Azure DevOps/GitHub dla zmian w repozytoriach i potokach oraz dowody wdrożeń (release evidence) przechwytywane automatycznie jako artefakty uruchomienia potoku.

SonarQube/SonarCloud, bezpieczeństwo potoków i Microsoft Defender for DevOps

SonarQube/SonarCloud dostarcza egzekwowalne bramki jakości (quality gates), które łączą jakość inżynierską z bezpieczeństwem. Zastosuj podejście „Clean as You Code”, ustawiając bramki dla nowego kodu: minimalne pokrycie kodu dla nowych/zmienionych linii (np. 80%+), zero nowych krytycznych podatności lub blokerów w postaci „code smells” oraz niska duplikacja. Niespełnienie warunków bramki musi powodować niepowodzenie potoku. Publikuj pokrycie z frameworków testowych (JaCoCo, Cobertura, VSTest) i dostosowuj profile jakości dla każdego języka, aby uwzględniały „security hotspots” i reguły zgodne z OWASP. Śledź wskaźniki długu technicznego i czasy naprawy; raportuj trendy, aby zwiększyć odpowiedzialność zespołu.

Bezpieczeństwo potoków opiera się na połączeniach usług z najmniejszymi uprawnieniami, chronionych zasobach i kompleksowym maskowaniu sekretów:

Połączenia usług powinny używać federacji tożsamości obciążeń roboczych lub tożsamości zarządzanych z wąskimi zakresami (subskrypcja/grupa zasobów, konkretny ACR lub Key Vault). Włącz zatwierdzenia i sprawdzenia dla połączeń usług i środowisk, aby właściciele musieli autoryzować ich użycie. Ogranicz uprawnienia „Użyj” do zaufanych potoków; wyłącz opcję „Udziel uprawnień dostępu wszystkim potokom”.
Chronione zasoby w Azure DevOps zabezpieczają połączenia usług, grupy zmiennych, bezpieczne pliki i środowiska. Wymagaj sprawdzeń, takich jak osoby zatwierdzające, okna czasowe w godzinach pracy, wyniki zapytań Azure Monitor i zewnętrzne silniki polityk REST. Traktuj je jako bramki przed wdrożeniami i jako warunki wstępne dla wrażliwych odczytów (np. pobierania sekretów produkcyjnych).
Maskowanie sekretów musi być egzekwowane we wszystkich logach; ogranicz rozwijanie zmiennych w skryptach; unikaj wyświetlania sekretów w konsoli (echoing); i preferuj API z zakresem system.accessToken zamiast przechowywania tokenów PAT. Okresowo skanuj logi potoków w poszukiwaniu przypadkowych wycieków sekretów i rotuj je po wykryciu.

Microsoft Defender for DevOps unifikuje stan bezpieczeństwa repozytoriów i potoków w GitHub i Azure DevOps. Połącz organizacje/projekty z Defender for Cloud, aby pozyskiwać sygnały o ryzyku z kodu, sekretów, IaC i zależności oraz prezentować skonsolidowane rekomendacje. Koreluje on znaleziska z właścicielami, wspiera przepływy pracy do wyciszania alertów z datą wygaśnięcia i mierzy adopcję zabezpieczeń gałęzi, wymaganych recenzentów i sprawdzeń statusu. Połącz Defender for DevOps z zadaniem/akcją Microsoft Security DevOps, aby zorkiestrować wiele analizatorów (np. Semgrep, Trivy, tfsec, Gitleaks, Bandit) w jednym kroku i publikować wyniki w formacie SARIF do skanowania kodu. Użyj Defender for Cloud do tworzenia inicjatyw zarządzania, które śledzą i egzekwują najlepsze praktyki DevOps (np. włączone skanowanie sekretów, wymagana liczba recenzentów ≥ 2, wyłączone merge przez osoby niebędące administratorami), podnosząc higienę repozytorium do rangi audytowalnej kontroli.

Praktyczny Scenariusz Problemu

Spotify musi ustandaryzować bezpieczne dostarczanie dla nowego stosu mikrousług hostowanego na AKS, obejmującego .NET i Node.js, z repozytoriami w GitHub Enterprise Cloud i wdrożeniami przez wieloetapowe potoki YAML w Azure DevOps. Wyzwaniem jest zatrzymanie podatnych zależności i błędnie skonfigurowanej infrastruktury przed merge, wyeliminowanie statycznych poświadczeń oraz zablokowanie promowania obrazów z krytycznymi CVE, jednocześnie tworząc audytowalne dowody zgodności.

Wymuszaj skanowanie SAST/SCA i sekretów na etapie PR

Wybierz SonarCloud dla wielojęzykowego SAST z dekoracją PR i bramkami jakości; ustaw pokrycie nowego kodu ≥ 80% i zero nowych krytycznych podatności. Dependabot jest włączony do automatycznego tworzenia PR z bezpiecznymi aktualizacjami, a GitHub dependency review blokuje PR wprowadzające znane CVE. Skanowanie sekretów GitHub Advanced Security oraz Gitleaks w CI zapewniają wielopoziomową ochronę (defense-in-depth) przed ujawnieniem poświadczeń.

Dodaj uwierzytelnione skanowanie DAST przed promocją do produkcji

Użyj OWASP ZAP na etapie potoku celującym w środowisko stagingowe z przygotowanymi kontami testowymi. Kontrola wydania (release check) blokuje przejście do produkcji, jeśli pojawią się nowe problemy o wysokiej/krytycznej ważności. ZAP został wybrany ze względu na pokrycie zgodne z OWASP i łatwą automatyzację w CI.

Zabezpiecz tożsamości i sekrety za pomocą Key Vault i federacji tożsamości obciążeń roboczych

Zastąp klucze klienta jednostek usługi (service principal) federacją tożsamości obciążeń roboczych Microsoft Entra dla połączeń usług, eliminując przechowywane sekrety. Potoki pobierają sekrety w czasie wykonania i poświadczenia do bazy danych z Azure Key Vault za pomocą uprawnień get/list o najmniejszym zakresie. Eliminuje to długożyjące poświadczenia i centralizuje ich rotację.

Zaimplementuj automatyzację certyfikatów

Przechowuj certyfikaty ingress i mTLS w Key Vault z automatyczną rotacją. AKS pobiera certyfikaty za pomocą sterownika Secrets Store CSI, aby uniknąć kopiowania sekretów do Kubernetes. Event Grid wyzwala funkcję Function w celu weryfikacji powiązań po odnowieniu. Taki projekt minimalizuje przestoje i błędy ludzkie podczas rotacji.

Wzmocnij bezpieczeństwo kontenerów i rejestrów

Uruchom Trivy w CI do skanowania plików Dockerfile i zbudowanych obrazów; potok kończy się niepowodzeniem przy wykryciu krytycznych/wysokich podatności. Wypychaj do ACR tylko czyste obrazy. Włącz Defender for Containers, aby skanował ACR przy wypychaniu i okresowo, prezentując wyniki w Defender for Cloud. Kontrole wydania oparte na politykach blokują wdrażanie obrazów z nierozwiązanymi krytycznymi/wysokimi CVE. Trivy zapewnia szybką informację zwrotną; Defender dodaje ciągłe, natywne dla rejestru zapewnienie bezpieczeństwa.

Skanuj IaC i lintuj Bicep/ARM

Użyj Checkov i tfsec do skanowania Terraform i chartów Helm; wymuszaj tagowanie, szyfrowanie i kontrole sieciowe. Linter Bicep i ARM TTK działają w CI dla natywnych szablonów Azure. Nieudane sprawdzenia blokują merge; linie bazowe (baselines) ograniczają szum do nowych/zmienionych zasobów. Te narzędzia zostały wybrane ze względu na szeroki zakres reguł i silne wsparcie dla Azure.

Skodyfikuj zgodność i dowody

Przypisz inicjatywy Azure Policy dla CIS Azure i firmowych linii bazowych; egzekwuj Deny dla krytycznych zabezpieczeń i DeployIfNotExists dla diagnostyki. Przekazuj wyniki do pulpitów zgodności regulacyjnej w Defender for Cloud. Eksportuj Activity Logs i rekomendacje Defender do Log Analytics w celu uzyskania niezmiennych dowodów. Polityka zapewnia ciągłe egzekwowanie; pulpity dają widoki gotowe do audytu.

Zablokuj potoki i chronione zasoby

Ogranicz połączenia usług do subskrypcji/grup zasobów o określonym zakresie; wymagaj zatwierdzeń środowisk i sprawdzeń zapytań Azure Monitor dla produkcji. Chroń grupy zmiennych i bezpieczne pliki; maskuj wszystkie sekrety. Wzmocnij bezpieczeństwo agentów self-hosted za pomocą prywatnej sieci. Te funkcje zmniejszają promień rażenia i zapewniają udział człowieka w procesie (human-in-the-loop) dla działań o wysokim ryzyku.

Skonsoliduj stan bezpieczeństwa za pomocą Microsoft Defender for DevOps

Połącz organizację GitHub i projekt Azure DevOps z Defender for Cloud, aby agregować znaleziska z kodu, sekretów i IaC oraz śledzić adopcję zabezpieczeń repozytoriów. Użyj akcji/zadania Microsoft Security DevOps do orkiestracji Semgrep, Trivy, tfsec i Gitleaks z publikowaniem SARIF, zapewniając ustandaryzowane skanowanie we wszystkich usługach. Centralizuje to zarządzanie ryzykiem i przepływy pracy związane z naprawą.

Każde narzędzie/funkcja jest wybierana pod kątem jak najwcześniejszego wykrywania, automatycznego egzekwowania i audytowalności: SonarCloud i ZAP stanowią bramki dla ryzyka w kodzie i w czasie wykonania; Dependabot i Trivy przyspieszają bezpieczne aktualizacje; Key Vault i federacja tożsamości eliminują statyczne sekrety; Checkov/tfsec i Azure Policy zapobiegają dryfowi konfiguracji; chronione zasoby i zatwierdzenia kontrolują promień rażenia; Defender for DevOps i Defender for Cloud dostarczają zunifikowane, praktyczne zarządzanie stanem bezpieczeństwa.

← Zarządzanie wydaniami i strategie wdrażania · Wszystkie domeny · Strategia testowania i inżynieria jakości →

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