Microsoft AZ-500: Kimlik ve Erişim Yönetimi — Ç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ış

Microsoft Azure’da Kimlik ve Erişim Yönetimi (IAM), Microsoft Entra ID (eski adıyla Azure AD) merkezlidir. Hangi kaynaklara, hangi koşullar altında ve hangi ayrıcalıklarla kimin erişebileceğini yönetir. Etkili bir IAM mimarisi, kalıcı ayrıcalıkları en aza indirir, koşullu ve risk tabanlı erişimi zorunlu kılar ve hem insanlar hem de iş yükleri için modern kimlik doğrulamasını benimserken hibrit ve harici iş birliği senaryolarını destekler.

Microsoft Entra Kimlik Yapıları ve Kapsamları

• Kiracılar, kullanıcılar ve gruplar
  • Bir kiracı, kuruluşunuzun kimlik sınırını ve güven yapısını temsil eder. Kullanıcılar üye veya misafir (B2B) hesapları olabilir. Yetkilendirme için güvenlik gruplarını, iş birliği özellikleri için ise Microsoft 365 gruplarını kullanın; manuel üyelik yönetimini azaltmak için dinamik grupları tercih edin.
• Yönetim Birimleri (AUs)
  • Yönetim Birimleri (AU’lar), dizin rollerini bir kullanıcı/cihaz alt kümesine devretmenize olanak tanır (örneğin, bölgesel yardım masası yalnızca Avrupa’daki kullanıcıları yönetebilir). Bu, dizin görevleri için en az ayrıcalık ilkesini destekler.
• Dizin rolleri ve rol atama kapsamları
  • Dizin rolleri (ör. Global Administrator, User Administrator) Microsoft Entra kaynaklarına uygulanır. Etki alanını (blast radius) kısıtlamak için mümkün olduğunda dizin rollerini bir AU kapsamında belirleyin. Privileged Identity Management (PIM) yapılandırmasını başlangıçta yapmak için Global Administrator rolü gereklidir.
• Azure rol tabanlı erişim denetimi (Azure RBAC) kapsamları
  • Azure RBAC, Azure kaynaklarına erişimi yönetir. Rolleri yönetim grubu, abonelik, kaynak grubu veya kaynak kapsamında atayın. Kalıtım aşağı doğru işler; aşırı ayrıcalığı azaltmak için her zaman pratik olan en dar kapsamı seçin.
• Operasyonel gerekçe
  • Dizin rollerini (Entra) Azure RBAC’den (kaynak yetkilendirmesi) ayırın. Yönetimsel erişimi sınırlamak, yanal hareket fırsatlarını azaltmak ve erişim gözden geçirmelerini basitleştirmek için AU’ları ve sıkı RBAC kapsamlarını kullanın.

Azure RBAC ve En Az Ayrıcalık İlkesi ile Erişim Denetimi

• Yerleşik roller ve en az ayrıcalık ilkesi
  • Göreve uyan en spesifik yerleşik rolü tercih edin. Örnek: Geniş kapsamlı Contributor rolü yerine, AcrPull ile yalnızca container imajı çekme (pull) erişimi ve AcrPush ile yükleme/gönderme (push) erişimi verin. Key Vault için, RBAC aracılığıyla yönetimsel denetimi yalnızca kasa yöneticilerine verirken, sertifika yönetimi gibi belirli nesne işlemleri için ayrıntılı erişim ilkeleri kullanın.
• Rol ataması kalıtımı
  • Mümkün olan en düşük kapsamda atama yapın. Yönetim grubu veya abonelik atamaları basamaklı olarak aşağıya doğru akar; kasıtlı olmadıkça geniş, kalıtsal haklardan kaçının. Abonelikler arasında tutarlı RBAC’ye ihtiyacınız olduğunda, manuel PIM ataması yerine Azure Blueprints (veya modern IaC alternatifleri) aracılığıyla tutarlı rol atamalarını damgalayın.
• Reddetme atamaları
  • Reddetme atamaları, izin atamalarından bağımsız olarak eylemleri açıkça engeller ve genellikle Azure Policy veya Blueprints gibi Azure hizmetleri tarafından oluşturulur. Pazarlık konusu olmayan koruma mekanizmalarını (örneğin, hassas kaynaklarda genel ağ kurallarını engellemek) zorunlu kılmak için bunları kullanın.
• Özel roller
  • Yerleşik roller çok geniş olduğunda, yalnızca gerekli eylemleri içeren özel roller tanımlayın. En az ayrıcalık testleri ve erişim gözden geçirmeleri yoluyla doğrulayın.

{
  "Name": "Storage Blob Reader (TagsBlocked)",
  "IsCustom": true,
  "Description": "Read blobs; no tag write",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotActions": [
    "Microsoft.Resources/tags/write"
  ],
  "AssignableScopes": ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}

• Operasyonel gerekçe
  • RBAC kapsamlandırması ve özel roller, aşırı yetkilendirmeleri ve denetim yüzeyini azaltır. Reddetme atamaları, yanlışlıkla yapılan geniş “izin” atamalarıyla aşılamayan “katı” uyumluluk kısıtlamalarını kodlayarak duruş direncini artırır.

Ayrıcalıklı Erişim, Koşullu Erişim ve Kimlik Koruması

• Privileged Identity Management (PIM)

  • Uygun (eligible) ve aktif (active) karşılaştırması: uygun atamalar kalıcı izinler vermez; kullanıcıların aktif hale gelmek için JIT (tam zamanında) aktivasyon yapması gerekir. Aktivasyon sırasında onay, gerekçe ve MFA’yı zorunlu kılın; sınırlı süreler belirleyin ve izlenebilirlik için bilet referansları isteyin. Mevcut riski anlamak için ayrıcalıklı rolleri keşfederek başlayın. İhtiyacın devam edip etmediğini doğrulamak için, ideal olarak kaynak veya grup sahiplerinin gözden geçiren olarak yer aldığı periyodik erişim gözden geçirmeleri kullanın.

• Koşullu Erişim (Conditional Access - CA)

  • Atamalar; kullanıcıları/grupları, iş yükü kimliklerini, bulut uygulamalarını ve eylemleri hedefler. Koşullar arasında oturum açma riski, cihaz platformu/durumu, konumlar, istemci uygulamaları ve cihazlar ile uygulamalar için filtreler bulunur. Erişim denetimleri (grant controls); MFA, uyumlu veya hibrit Azure AD’ye katılmış cihazlar, uygulama koruma ilkeleri veya kullanım koşulları gerektirebilir. Oturum denetimleri; oturum açma sıklığını, kalıcı oturumları ve uygulama tarafından zorlanan kısıtlamaları (ör. SharePoint için yalnızca web erişimi) sınırlar. İlke etkisini uygulamadan önce güvenli bir şekilde doğrulamak için yalnızca raporlama (report-only) modunu kullanın. Kilitlenmeleri önlemek için acil durum (break-glass) hesapları ve aşamalı dağıtımlar için istisnalar bulundurun.

• Identity Protection

  • Kullanıcı riski, bir hesabın ele geçirilme olasılığını yansıtır; oturum açma riski ise belirli bir oturumun riskli olma olasılığını yansıtır. Güvenli düzeltme gerektirecek şekilde ilkeleri yapılandırın:
    • Sızdırılmış kimlik bilgilerine sahip kullanıcılar: Yüksek kullanıcı riski olarak değerlendirin; parola sıfırlamayı zorunlu kılın ve düzeltilene kadar engelleyin.
    • Şüpheli etkinlik gösteren IP’lerden yapılan oturum açma işlemleri: En az Orta düzeyde oturum açma riski olarak değerlendirin; MFA ile doğrulama isteyin veya hassas uygulamalar için engelleyin.
  • Güveni gerçek zamanlı olarak uyarlamak için CA ile entegre edin. Etkinliği ölçmek için risk geçmişini ve düzeltmeleri izleyin.

• Operasyonel gerekçe

  • PIM, kalıcı ayrıcalığı ortadan kaldırır ve güçlü, denetlenebilir aktivasyonu zorunlu kılar. CA ve Identity Protection, sıfır güven (zero trust) ilkesini uygular — her erişim denemesini kullanıcıya, cihaza, oturuma ve riske göre doğrulayarak — başarılı kimlik bilgisi hırsızlığını ve token tekrar oynatma (replay) saldırılarını azaltır.

Hibrit ve İş Yükü Kimlikleri

• Hibrit kimlik seçenekleri
  • Parola karması eşitleme (PHS): Parola karmalarını Entra ID ile eşitler. Basit ve dayanıklıdır; kimlik doğrulama sırasında şirket içi oturum açma ilkelerini zorunlu kılmaz.
  • Doğrudan kimlik doğrulaması (PTA): Hafif bağlayıcılar aracılığıyla parolaları şirket içi DC’lere karşı doğrular; AD FS olmadan, şirket içi parola ilkelerini ve hesap kısıtlamalarını gerçek zamanlı olarak zorunlu kılar.
  • Federasyon (ör. AD FS): Kimlik doğrulamayı şirket içi STS’ye kaydırır. Yalnızca karmaşık talepler (claims) veya eski senaryolar için gerektiğinde kullanın; daha fazla sunucu ve operasyonel ek yük getirir.
  • Sorunsuz çoklu oturum açma (Seamless SSO): Kurumsal ağ içindeki etki alanına katılmış cihazlardaki kullanıcıların minimum istemle oturum açmasını sağlar.
  • Operasyonel tercih: Sunucuları en aza indirirken şirket içi parola ilkelerini ve hesap kısıtlamalarını zorunlu kılmak için, PTA ve Seamless SSO’yu dağıtın ve ayrıca PTA’ya bağlı olmayan senaryoların dayanıklılığı/yük devretmesi için PHS’yi etkinleştirin. Tek başına federasyon karmaşıklığı artırır ve “sunucuları en aza indirme” hedefini karşılamaz.
• Hibrit birleşik Windows cihazlarından Azure SQL’e uygulama kimlik doğrulaması
  • İstemleri en aza indirmek ve uygun olan yerlerde Kerberos/SSO’dan yararlanmak için Active Directory tümleşik kimlik doğrulamasını kullanın.
• Yönetilen kimlikler ve hizmet sorumluları
  • Yönetilen kimlikler (sistem tarafından atanan veya kullanıcı tarafından atanan), gizli anahtarları (secrets) ortadan kaldırdıkları ve kimlik bilgilerini otomatik olarak rotasyona tabi tuttukları için Azure’da barındırılan iş yükleri için ilk tercihtir. Kimliğe kaynak kapsamında en az ayrıcalıklı RBAC atayın.
  • Hizmet sorumluları, uygulama kayıtlarını (app registrations) destekler; istemci gizli anahtarları (client secrets) yerine sertifika kimlik bilgilerini kullanın ve mümkün olan en kısa yaşam süresini ayarlayın.
• İş yükü kimlik federasyonu
  • Harici iş yükü kimliklerinin (ör. GitHub Actions, Kubernetes) gizli anahtarları depolamadan Entra uygulamaları için token almasını sağlamak üzere OIDC federasyonunu kullanın. Kimlerin token takası yapabileceğini kısıtlamak için issuer, subject ve audience taleplerini (claims) hassas bir şekilde tanımlayın.

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"gh-actions-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:contoso/api:environment:prod",
    "audiences":["api://AzureADTokenExchange"]
  }'

• AKS’ten ACR’ye erişim
  • Yanlış atamaları önleyen ve doğru kapsamlandırmayı otomatikleştiren attach-acr akışını kullanarak AKS kümesinin yönetilen kimliğine hedef kayıt defterinde (registry) AcrPull izni verin.

az aks update -n aks-prod -g rg-aks --attach-acr myRegistry

• Operasyonel gerekçelendirme
  • PTA+PHS+Seamless SSO, bulut dayanıklılığını korurken gerçek zamanlı şirket içi denetimleri zorunlu kılar. Yönetilen kimlikler ve federasyon, işlem hatlarından (pipelines) ve çalışma zamanından (runtime) statik gizli anahtarları kaldırarak sık karşılaşılan kimlik bilgisi hırsızlığı yollarını kapatır.

Dış İşbirliği, Kimlik Doğrulama Yöntemleri ve Uygulama Erişimi

• Dış kimlikler ve B2B işbirliği
  • Kiracılar arası erişim ayarları, kullanım koşulları ve konukları hedefleyen Koşullu Erişim (CA) ile B2B konuk hesaplarını kullanın. Kimlerin davet gönderebileceğini kısıtlayın ve yetkilendirme yönetimi aracılığıyla tam zamanında erişimi tercih edin.
• Yetkilendirme yönetimi ve erişim paketleri
  • Grupları, uygulamaları ve SharePoint sitelerini; kimlerin talep edebileceğini (dış kullanıcılar dahil), onay akışlarını, atama sürelerini ve erişim gözden geçirmelerini tanımlayan politikalara sahip erişim paketleri halinde birleştirin. Gözden geçiren seçimi için, iş sorumluluğunu kaynak sahiplerinde tutmak amacıyla Grup Sahiplerini (Group Owners) kullanın.
• Kimlik doğrulama yöntemleri ve parolasız erişim
  • Güçlü yöntemleri standartlaştırın: FIDO2 güvenlik anahtarları, Windows Hello for Business ve Microsoft Authenticator telefonla oturum açma. Birleşik güvenlik bilgileri kaydını (SSPR + MFA) kullanın ve tüm kullanıcılar için MFA kayıt politikasını zorunlu kılın. Gerekirse şirket içi geri yazma (on-prem writeback) ile SSPR’ı etkinleştirin; güvenli yöntemler gerektirin ve mümkün olan yerlerde kurumsal olarak yönetilen faktörlerle sınırlayın. Eski/temel kimlik doğrulama protokollerini devre dışı bırakın ve riskin gerektirdiği durumlarda zayıf, yalnızca SMS tabanlı MFA’yı engelleyin.
• Microsoft Entra application proxy
  • Şirket içi web uygulamalarını gelen güvenlik duvarı açıklıkları olmadan yayımlayın. Yüksek kullanılabilirlik (HA) için bağlayıcı grupları, Entra ID ile ön kimlik doğrulama kullanın ve eski uygulamalarda sıfır güven (zero trust) için CA, cihaz uyumluluğu ve Identity Protection katmanlarını ekleyin.
• Uygulama kaydı güvenliği
  • Yönetici onayı iş akışlarını zorunlu kılın; uygulama oluşturabilecek kişileri sınırlayın; izinleri sınıflandırın; yalnızca kullanıcı bağlamı gerekmediğinde uygulama izinlerini tercih edin ve API’leri minimum düzeyde kapsayacak şekilde ayarlayın. Mümkün olan yerlerde örtük izin akışını (implicit grant) devre dışı bırakın, kurumsal uygulamalar için atama gerektirin ve gizli anahtarlar (secrets) yerine otomatik rotasyonlu sertifikaları tercih edin.

az ad app update --id <app-id> --required-resource-access @permissions.json
az ad sp update --id <sp-id> --set appRoleAssignmentRequired=true

• Operasyonel gerekçe
  • Erişim paketleri ve uygulama proxy’si, yönetilen ve denetlenebilir dış erişim sağlar. Güçlü, parolasız yöntemler kimlik avı saldırılarına karşı dayanıklılığı artırır. Sıkı uygulama kaydı kontrolleri, gereğinden geniş kapsamlı onayları önler ve uygulama kimliğine bürünme olasılığını azaltır.

Pratik Problem Senaryosu

Adobe Inc.‘in, üçüncü taraf bir tedarikçiye Azure kaynaklarının bir alt kümesine geçici yönetici erişimi vermesi ve bu tedarikçiye yönelik olarak güçlü kimlik doğrulaması ve sıfır kalıcı yetki ilkesini zorunlu kılarak şirket içi eski bir web uygulamasını yayımlaması gerekmektedir.

1. Erişimi kapsamlandırın ve modelleyin

• rg-vendor-ops adında bir kaynak grubu oluşturun ve yalnızca gerekli kaynakları bu gruba taşıyın. Minimum düzeyde Azure RBAC rollerini atayın (örneğin, rg-vendor-ops üzerinde Katkıda Bulunan (Contributor); bir tanılama kaynak grubu üzerinde Okuyucu (Reader)).
• Gerekçe: Dar kapsamlandırma yanal hareketi önler. Rol kalıtımı rg-vendor-ops ile sınırlı kalır ve bu da patlama yarıçapını (blast radius) daraltır.

2. Kimliği ve aktivasyonu PIM ile yönetin

• Tedarikçi yöneticilerini gerekli roller için kalıcı değil, uygun (eligible) yapın; aktivasyon sırasında onay, bilet ID’si ve MFA gerektirin ve aktivasyonu 4 saat ile sınırlayın. Başlangıç olarak, mevcut atamaları temel almak için PIM’in Ayrıcalıklı rolleri keşfet (Discover privileged roles) özelliğini çalıştırın.
• Gerekçe: Uygun atamalar kalıcı yetkiyi ortadan kaldırır. Onay ve MFA, destek pencereleriyle uyumlu tam zamanında (JIT) erişimi zorunlu kılar ve denetlenebilir bir kontrol sağlar.

3. Koşullu Erişim ve risk politikalarını zorunlu kılın

• Tedarikçi grubunu ve Azure portalı ile ARM API’lerini hedefleyen bir CA politikası oluşturun; MFA, uyumlu/hibrit birleşik cihaz gerektirin ve riskli konumlardan erişimi engelleyin. Önce yalnızca raporlama (report-only) modunda etkinleştirin; sonra zorunlu kılın. Identity Protection’ı yapılandırın: Yüksek kullanıcı riski (sızdırılmış kimlik bilgileri) durumunda parola sıfırlanana kadar erişimi engelleyin; Orta düzey oturum açma riski (şüpheli IP) için MFA gerektirin.
• Gerekçe: CA, erişimi gerçek zamanlı olarak cihaz güvenine ve risk durumuna bağlar. Yalnızca raporlama modu, dağıtım sırasında kesintileri önler. Risk politikaları, güvenliği ihlal edilmiş oturumları ve hesapları otomatik olarak düzeltir.

4. Eski uygulamayı Microsoft Entra application proxy ile yayımlayın

• Yüksek kullanılabilirlik (HA) için tedarikçiye açık ayrı alt ağlarda iki bağlayıcı dağıtın. Entra ID ile ön kimlik doğrulamayı yapılandırın, kurumsal uygulamaya atama gerektirin ve aynı CA politikasını uygulayın. Tedarikçi kullanıcılarına hem kurumsal uygulamaya hem de RG rollerine süresi sınırlı erişim vermek için erişim paketlerini kullanın; Grup Sahiplerini (Group Owners) gözden geçiren olarak ayarlayın.
• Gerekçe: Uygulama proxy’si gelen ağa maruz kalmayı ortadan kaldırır ve kimlik doğrulamayı merkezileştirir. Yetkilendirme yönetimi, işe alım/işten çıkarma süreçlerini standartlaştırır ve kaynak sahipleri tarafından periyodik gözden geçirmeleri sağlar.

5. İş yükü ve uygulama kimlik bilgilerini güvence altına alın

• Hizmet sorumluları için istemci gizli anahtarlarını (client secrets) sertifika kimlik bilgileriyle değiştirin; CI/CD için, gizli anahtarları depolamak yerine iş yükü kimlik federasyonunu (workload identity federation) kullanın. İmajlara ihtiyaç duyan AKS iş yükleri için, yönetilen kimliğe AcrPull izni vermek amacıyla ACR’yi kümeye ekleyin.
• Gerekçe: Statik gizli anahtarları kaldırmak, yaygın bir ihlal vektörünü kapatır; federasyon ve yönetilen kimlikler, en az ayrıcalıklı ve otomatik olarak yenilenen erişim sağlar.

6. Acil durum (break-glass) hesaplarını koruyun ve izleyin

• İki acil durum hesabını CA politikalarının dışında tutun, ancak bunları çevrimdışı olarak saklanan uzun, rastgele parolalarla koruyun. Erişim gözden geçirmelerini üç ayda bir etkinleştirin ve PIM ile CA günlüklerini, anormal aktivasyonlar için uyarılar içeren bir Log Analytics çalışma alanına aktarın.
• Gerekçe: Acil durum hesapları, operasyonel olarak güvende kalırken kiracı kilitlenmesini önler. Sürekli izleme, uyumluluğu sürdürerek ve olay müdahale hazırlığını sağlayarak kötüye kullanımı hızla tespit eder.

Tüm alanlar · Ağ Güvenliği Mimarisi →

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

Microsoft'a göz atın →