Microsoft AZ-500: Uygulama Güvenliği ve DevSecOps — Çalışma kılavuzu

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

Şunun bir parçası: Microsoft Azure Security Engineer Associate AZ-500 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Microsoft sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Azure’da Uygulama Güvenliği ve DevSecOps; kimliklerin kötüye kullanılmasını önlemeye, giriş (ingress) ve API’leri korumaya, güvenliği pipeline’larda erken aşamalara (shift left) taşımaya, bekleyen (at rest) ve aktarılan (in transit) gizli bilgileri güvence altına almaya ve sağlam sürüm yönetişimini zorunlu kılmaya odaklanır. Etkili tasarımlar, uzun ömürlü gizli bilgileri ortadan kaldırır, en az ayrıcalık ilkesini (least privilege) kullanır, her çağrıyı doğrular ve kod, bağımlılıklar, altyapı ve çalışma zamanı (runtime) genelinde sürekli tespiti ve düzeltmeyi kurumsallaştırır.

Güvenli Uygulama Kimliği, Giriş ve API Koruması

Microsoft Entra ID’de (Azure AD) güvenli uygulama kimliği, kapsamı iyi belirlenmiş bir uygulama kaydı (app registration) ve doğru OAuth 2.0 akışının seçilmesiyle başlar:

• Temsilci izinleri (Delegated permissions), bir kullanıcı oturum açtığında uygulanır ve onay (consent), yalnızca doğrulanmış yayıncı uygulamaları (verified publisher apps) veya yönetici tarafından onaylanmış kapsamlarla (admin-approved scopes) sınırlandırılabilir. Uygulama izinleri (Application permissions / app-only), kullanıcı olmadan hareket eden arka plan servislerini veya daemon’ları yetkilendirdiği için her zaman yönetici onayı gerektirir.
• Yalnızca gereken minimum kapsamları (scopes) veya uygulama rollerini (application roles) vererek ve onay taleplerinin yönetici tarafından incelenmesini zorunlu kılarak en az ayrıcalık ilkesini (least privilege) uygulayın. Onay oltalama (consent phishing) saldırılarını azaltmak için son kullanıcı onayını devre dışı bırakın veya yalnızca düşük riskli, doğrulanmış yayıncılar için izin verin.
• Client secret’lar yerine sertifika kimlik bilgilerini (certificate credentials) veya birleşik kimlikleri (federated identities) tercih edin. Sertifikalar daha güçlü güvence ve öngörülebilir rotasyon sağlar. Kısa ömür süreleri yapılandırın ve rotasyonu otomatikleştirin. Gerekli olmadıkça genel istemci akışlarını (public client flows) engelleyin.
• Azure servisleri için uygulama gizli anahtarları (app secrets) yerine yönetilen kimlikleri (managed identities) kullanın. Key Vault Secrets User veya Storage Blob Data Reader gibi veri düzlemi (data-plane) rolleri atayın ve uygun olan yerlerde Private Endpoints kullanarak ağ erişimini kısıtlayın.

Application Gateway WAF v2 ve Azure Front Door WAF, genel girişi (public ingress) OWASP Top 10 tehditlerine karşı korur:

• En son Microsoft tarafından yönetilen OWASP Core Rule Set’i etkinleştirin ve ayarlama (tuning) yaptıktan sonra Önleme (Prevention) modunda çalıştırın. Öğrenme aşamasında yanlış pozitifleri (false positives) azaltmak için başlangıçta anomali puanlamasını (anomaly scoring) kullanın.
• Coğrafi sınırlama (geofencing), IP itibarına göre engelleme, başlık (header) zorlaması ve istek boyutu limitleri için özel kurallar yapılandırın. Front Door için, kimlik bilgisi doldurma (credential stuffing) ve temel L7 DoS saldırılarını engellemek amacıyla istemci IP’si başına hız limiti (rate-limit) kuralları ekleyin.
• TLS’i güçlü şifreleme takımları (cipher suites) ve politikalarla sonlandırın; kaynağa (origin) kadar uçtan uca TLS (end-to-end TLS) kullanın. mTLS gerektiren senaryolar için Application Gateway listener’larında istemci sertifikası doğrulamasını (client certificate validation) yapılandırın.
• WAF politikalarını listener’lara/rotalara (routes) hassas bir şekilde ekleyin; kural istisnalarını (rule exclusions) yalnızca yanlış pozitifin nedenini tam olarak anladığınızda kullanın. Tespit mühendisliği (detection engineering) ve olay müdahalesi (incident response) için WAF loglarını Log Analytics’e aktarın.

API Management (APIM), çok katmanlı bir güvenlik duruşu uygular:

• Ağ geçidinde (gateway) OAuth token’larını katı issuer, audience ve scope kontrolleriyle doğrulayın. Her yerde HTTPS’i zorunlu kılın ve istemci güven sınırı (client trust boundary) gerektirdiğinde mTLS’i uygulayın.
• Derinlemesine savunma (defense-in-depth) ve kimlik bazlı kısıtlama (throttling) için abonelik anahtarlarını (subscription keys) OAuth ile birleştirin. Tüketicileri (consumers) bölümlere ayırmak ve diğerlerini etkilemeden anahtarları döndürmek (rotate) için ürün seviyesinde (product-level) abonelik anahtarları kullanın.
• Tüketici başına, kapsam başına veya abonelik başına ayrıntı düzeyinde hız sınırlaması (rate limiting) ve kotalar uygulayın. Uygun olduğunda iş ortağı ağlarını izin listesine (allowlist) eklemek için IP filtrelemeyi kullanın.
• Arka uç (backend) servislerini karşılıklı TLS (mutual TLS) veya yönetilen kimlikler (managed identities) kullanarak koruyun. Yapılandırma içinde düz metin (plaintext) bulunmasını önlemek için gizli bilgileri, Key Vault referansları ile desteklenen Adlandırılmış Değerler (Named Values) olarak saklayın.

JWT kapsam (scope) zorlaması ve kısıtlama (throttling) için örnek APIM politikası:

<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>

DevSecOps Pipeline Sertleştirmesi ve Defender for DevOps

Azure DevOps ve GitHub Actions, Azure’da uzun ömürlü gizli anahtarlar olmadan kimlik doğrulamalıdır:

• Hizmet bağlantıları (service connections) için iş yükü kimlik federasyonunu (workload identity federation - OIDC) kullanın. Entra ID’de bir uygulama kaydı/hizmet sorumlusu (app registration/service principal) oluşturun, ardından repoyu, branch’i ve iş akışını/ortamı (workflow/environment) bu kimliğe bağlayan bir birleşik kimlik bilgisi (federated credential) ekleyin. Bu, saklanan gizli bilgi olmadan kısa ömürlü token’lar üretir ve Azure RBAC aracılığıyla en az ayrıcalık ilkesine uygun kapsamlandırmayı destekler.
• Pipeline izinlerini sıkılaştırın: hizmet bağlantılarını kullanmak için onay isteyin, pipeline’ı korumalı dallarla (protected branches) kısıtlayın ve gerekmedikçe “Allow scripts to access OAuth token” seçeneğini devre dışı bırakın. Maskeleme (masking) ile değişken grupları (variable groups) ve gizli bilgileri (secrets) kullanın; loglama komutları aracılığıyla gizli bilgilerin yansıtılmasına (echo) izin vermeyin. GitHub’da, merkezi kontrol için repo gizli bilgileri yerine ortam (environment) ve organizasyon (organization) gizli bilgilerini tercih edin ve uygun olan yerlerde barındırılan runner’larda (hosted runners) “prevent secrets in logs” ayarlarını kullanın.
• Ortam koruma kurallarını (environment protection rules) uygulayın: zorunlu gözden geçirenler (required reviewers), kontroller (ör. değişiklik yönetimi biletleri, testlerin başarılı olması) ve zamana dayalı onaylar.

Azure CLI ile birleşik kimlik bilgisi (federated credential) oluşturma (GitHub OIDC örneği):

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, aşağıdaki bulguları ortaya çıkarmak için Azure Repos ve GitHub ile entegre olur:

• Yaygın dillerde kod güvenliği bulguları (SAST); pull request ek açıklamaları (annotations), gerilemeleri (regressions) önlemek için yeni sorunları vurgular.
• Açık kaynak (OSS) kütüphaneler için güvenlik açığı istihbaratını kullanan bağımlılık riski (SCA), düzeltme rehberliği ve düzeltilmiş sürümlerle birlikte.
• Sızdırılmış token’lar/anahtarlar için gizli bilgi sızıntısı tespiti ve önerilen rotasyonlar.
• ARM/Bicep/Terraform genelinde Altyapı olarak Kod (Infrastructure-as-Code) yanlış yapılandırmaları (ör. genel erişime açık depolama, serbest NSG’ler), ilke tabanlı yönetişim (policy-driven governance) ve sapma takibi (drift tracking) ile birlikte. Bulgular, önceliklendirme için depo (repository) ve pipeline bağlamıyla birlikte Defender for Cloud’a toplanır. Güvensiz dağıtımları durdurmak için sürümleri önem derecesi eşiklerine göre denetleyin (gate).

Gizli Bilgi Yönetimi ve Platform Entegrasyonu

Key Vault, kapsamlı kontrollerle merkezi gizli bilgi, anahtar ve sertifika yönetimi sunar:

• Yıkıcı kayıpları önlemek için kalıcı silme korumasını (purge protection) ve geçici silmeyi (soft delete) zorunlu kılın. Birleşik yetkilendirme için erişim ilkeleri (access policies) yerine RBAC’yi tercih edin; mümkün olan yerlerde Private Endpoints’i etkinleştirin ve genel ağ erişimini devre dışı bırakın; güvenli bir çalışma alanına günlük kaydını etkinleştirin.
• App Service ve Functions, uygulama ayarlarında (app settings) yönetilen kimlikler (managed identities) ile Key Vault referanslarını kullanır; gizli bilgileri yeniden dağıtım yapmadan şeffaf bir şekilde döndürün.
• AKS, Azure AD Workload Identity (önerilir) ile kimliği doğrulanarak, Azure Key Vault sağlayıcısı ile Secrets Store CSI Sürücüsü aracılığıyla çalışma zamanında gizli bilgileri alır. Kubernetes Secret nesnelerine düz metin (plaintext) gizli bilgiler yerleştirmekten kaçının.

App Service Key Vault referans örneği:

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

AKS SecretProviderClass (kısaltılmış):

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

Pipeline’lar, işin çalışma zamanında gizli bilgileri almalıdır:

• Azure DevOps: Yönetilen kimlik (managed identity) destekli hizmet bağlantısıyla (service connection) Key Vault görevi; gizli bilgi indirmeyi en az sayıda aşama ile kısıtlayın.
• GitHub Actions: OIDC için azure/login ve yalnızca gerekli adları çekmek için azure/keyvault.

Güvenli SDLC, Konteynerler, Günlük Kaydı ve Sürümler

Güvenli SDLC uygulamaları, dağıtımdan önce riski azaltır:

• STRIDE veya eşdeğeri ile erken aşamada tehdit modellemesi yapmak, kimlik doğrulama, yetkilendirme ve veri akışlarının açıkça doğrulanmasını sağlar. Mimari geliştikçe modelleri güncelleyin.
• SAST her PR’da çalışır; yüksek önem dereceli sorunlarda derlemeleri durdurun ve sorumlulukları net bir şekilde belirleyin. DAST, güvenli test verileriyle bir hazırlık (staging) yuvasına/ortamına dağıtım sonrası çalıştırılır.
• SCA, paketleri sürekli olarak izler; sabitlenmiş sürümleri ve lisans uyumluluğunu zorunlu kılar.
• Dal (branch) politikaları ile sıkı kod incelemesi: zorunlu gözden geçirenler, bağlantılı iş öğeleri, derleme doğrulaması ve imzalı commit’ler.

Konteyner imaj güvenliği, tedarik zinciri bütünlüğünün temelidir:

• Derlemeler sırasında SBOM’lar (SPDX veya CycloneDX) oluşturun ve saklayın, izlenebilirlik için imajlarla birlikte OCI artifact’leri olarak yayınlayın.
• Defender for Cloud’un konteyner taramasını kullanarak imajları push öncesi ve kayıt defterlerinde (registry) durağan haldeyken tarayın; kritik bulgularda bir sonraki aşamaya geçişi engelleyin.
• Notary v2/OCI artifact’lerini cosign ile kullanarak imajları ve onayları (attestation) imzalayın. Admission sırasında (örneğin, Kubernetes için Gatekeeper/OPA veya AKS Policy) imza doğrulamasını zorunlu kılın.
• Azure Container Registry (ACR) içindeki kayıt defteri kontrolleri: yönetici (admin) kullanıcısını devre dışı bırakın, ağı Private Endpoint’ler aracılığıyla kısıtlayın, müşteri tarafından yönetilen anahtarları etkinleştirin, ayrıntılı erişim için depo kapsamlı (repository-scoped) token’lar kullanın ve saklama (retention) ve karantina (quarantine) desenlerini uygulayın. Çalışma zamanı ortamlarına (runtime) yalnızca AcrPull ve CI’a AcrPush izni verin. AKS için, manuel rol yapılandırması yerine doğru atamayı oluşturmak üzere desteklenen komutla ACR’yi ekleyin.
• Konteynerlerin bir VM ana bilgisayarından VNet hizmet uç noktalarını kullanması gerekiyorsa, konteyner başına trafiğin alt ağdan kaynaklanması için desteklenen bir CNI eklentisi kurun.

Uygulama günlük kaydı, gizli bilgileri veya kişisel olarak tanımlanabilir bilgileri (PII) sızdırmamalıdır:

• Telemetry Processors ile hassas alanları redakte etmek veya çıkarmak için Application Insights’ı yapılandırın; gizli bilgileri veya PII içeren ham başlıkları (header), token’ları veya payload’ları günlüklemekten kaçının. Veri alanlarını iş ihtiyacıyla sınırlayın ve maruziyeti azaltmak için örneklemeyi (sampling) etkinleştirin.
• Tanılama verilerini, katı RBAC (en az ayrıcalıkla Log Analytics Reader) ve Storage’a dışa aktarırken değişmez depolama (zamana dayalı saklama kilitleri) ile ayrılmış bir Log Analytics çalışma alanına yönlendirin.
• Mümkün olan yerlerde telemetri alım (ingestion) ve sorgu uç noktalarını Private Link ile koruyun. İzleme (instrumentation) bağlantı dizelerini Key Vault’ta saklayın ve düzenli olarak döndürün.

Güvenli sürüm uygulamaları, kontrollü yükseltmeyi zorunlu kılar:

• Azure DevOps Environments veya GitHub Environments’daki onay kapıları (approval gates), belirlenmiş gözden geçirenler, kalite kontrollerini geçme ve değişiklik biletleri gerektirir. Yüksek riskli dağıtımlar için bekletme pencerelerini otomatikleştirin.
• Hizmet bağlantılarına (service connection) ve aracılara (agent) en az ayrıcalık ilkesini uygulayın; ortam başına kaynak gruplarına veya aboneliklere göre kapsam belirleyin. Dar kapsamlı rollere sahip yönetilen kimlikleri (managed identity) kullanın.
• Geliştirme (Dev), Test ve Üretim (Prod) ortamlarını ayrı abonelikler, VNet’ler, Key Vault’lar ve ACR’ler ile ayırın; ortamlar arası yanal harekete izin vermeyin ve her ortamda farklı gizli bilgiler/anahtarlar kullanın.

Pratik Problem Senaryosu

Fabrikam, Inc., internete çok kiracılı (multi-tenant) bir SaaS API yayınlıyor. Gereksinimler: OWASP Top 10 saldırılarını engellemek, her operasyon için OAuth kapsamlarını doğrulamak, repolarda gizli bilgilerin bulunmasını önlemek, kötüye kullanan istemcileri yavaşlatmak (throttle) ve üretimde yalnızca imzalı konteyner imajlarının çalışmasını sağlamak.

1. Ön Uç ve WAF

• Önleme (Prevention) modunda en son OWASP yönetilen kural setini kullanan bir WAF politikası, ayrıca özel oran sınırlama (rate-limit) kuralları ve coğrafi engelleme (geo blocking) ile Azure Front Door Standard’ı dağıtın. Gerekçe: merkezi küresel uç (edge) nokta zorlaması, saldırı yüzeyini azaltır ve L7 saldırılarını kaynağa (origin) ulaşmadan önce emer.

2. API Gateway Politikası

• Azure API Management’ı Front Door’un arkasına yerleştirin; her operasyon için issuer/audience/scope kontrolleri ile validate-jwt uygulayın ve kotalarla ürün düzeyinde abonelik anahtarları kullanın. Gerekçe: APIM, kimlik tabanlı zorlama ve kiracı yalıtımı sağlar; anahtarlar ve OAuth, katmanlı savunma ve hassas yavaşlatma (throttling) sunar.

3. Kimlik ve Onay (Consent)

• Kullanıcı akışları için delege edilmiş (delegated) kapsamlar ve daemon için uygulama rolleri ile SPA ve daemon uygulamalarını Entra ID’ye kaydedin; kullanıcı onayını doğrulanmış yayıncılarla sınırlayın ve uygulama izinleri için yönetici onayı gerektirin. Daemon için sertifika kimlik bilgilerini kullanın. Gerekçe: zayıf gizli bilgileri ortadan kaldırır, en az ayrıcalık ilkesini zorunlu kılar ve onay oltalama (consent phishing) maruziyetini azaltır.

4. OIDC ile DevSecOps

• GitHub Actions’ı, derleme için üretim dışı bir aboneliğe ve sürüm için üretim kapsamlı bir hizmet sorumlusuna (service principal) OIDC federasyonu kullanacak şekilde yapılandırın; her biri minimum rollerle (derleme için AcrPush, sürüm için bir üretim RG’si ile sınırlı Contributor) donatılmalıdır. Gerekçe: saklanan gizli bilgi yoktur; patlama yarıçapı (blast radius) her ortam için en aza indirilir.

5. Konteyner Tedarik Zinciri

• ACR Tasks aracılığıyla imajları derleyin, SBOM’lar (CycloneDX) oluşturun ve imajları cosign ile imzalayın; onayları (attestation) OCI artifact’leri olarak saklayın. AKS admission’ı, geçerli imzaları gerektirecek şekilde politika ile yapılandırın. Gerekçe: köken (provenance) ve bütünlük, dağıtım zamanında doğrulanabilir, bu da üzerinde oynanmış imajları engeller.

6. Kayıt Defteri ve Çalışma Zamanı Kontrolleri

• ACR yönetici kullanıcısını devre dışı bırakın, Private Endpoint’i etkinleştirin, desteklenen attach-acr akışıyla AKS kubelet kimliğine AcrPull atayın ve Defender for Cloud imaj taramasını etkinleştirin. Gerekçe: ağ ve kimlik sıkılaştırması, varsayılan arka kapıları kaldırır; tarama, bilinen CVE’leri çalışma zamanından önce yakalar.

7. Gizli Bilgiler ve Yapılandırma

• Private Endpoint ve RBAC ile Key Vault kullanın; App Service ve Functions, Key Vault referanslarını kullanır ve AKS, Workload Identity ile Secret Store CSI kullanır. Gerekçe: gizli bilgiler asla repolarda veya uygulama yapılandırmalarında bulunmaz; döndürme (rotation) merkezileştirilmiştir ve denetlenebilirdir.

8. Sürüm Yönetişimi

• GitHub main dalını zorunlu gözden geçirmeler ve kontrollerle koruyun; üretim dağıtımından önce ortam onayları ve güvenlik kapılarından geçmeyi (kritik SAST/SCA/IaC bulgusu olmaması) zorunlu kılın. Gerekçe: yalnızca doğrulanmış, güvenli derlemelerin ilerlemesini sağlar; yüksek riskli değişiklikler için insan denetimi devam eder.

9. Gözlemlenebilirlik Hijyeni

• Özel Telemetry Processors ile PII’yi redakte etmek için Application Insights’ı yapılandırın ve WAF/APIM tanılama verilerini en az ayrıcalıklı Reader erişimiyle güvenli bir Log Analytics çalışma alanına yönlendirin. Gerekçe: hassas verileri ifşa etmeden adli (forensic) değeri korur; erişim denetlenebilir ve kısıtlıdır.

← Microsoft Sentinel ve Güvenlik Operasyonları · Tüm alanlar · Hibrit ve Çoklu Bulut Güvenliği →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →

Microsoft'a göz atın →