Microsoft AZ-204: Azure Kimlik Doğrulama, Yetkilendirme ve Güvenlik — Çalışma kılavuzu

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Şunun bir parçası: Microsoft Azure Developer Associate AZ-204 — Ç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 kimlik doğrulama ve yetkilendirme, kimliklere (kullanıcılar, uygulamalar, iş yükleri) token’lar yayınlayan ve API’lere ve kaynaklara erişimi zorunlu kılan Microsoft Identity Platform’u temel alır. Uygulamalar, OAuth 2.0 ve OpenID Connect aracılığıyla entegre olur, MSAL kullanarak token’lar alır ve Azure AD uygulama kayıtlarında (app registration) beyan edilen izinleri talep eder. Azure’da çalışan iş yükleri, yönetilen kimlikler (managed identities) kullanarak kimlik bilgilerini tamamen ortadan kaldırabilir ve Key Vault, Storage ve Microsoft Graph gibi hizmetlere erişmek için Azure RBAC’ye güvenir. Gizli bilgi yönetimi (secrets management), kasa veri düzlemi (data-plane) erişimi ile yönetim düzlemi (management-plane) kontrolü arasında net bir ayrım ve geçici silme (soft delete) ile temizleme koruması (purge protection) sayesinde güçlü kurtarma garantileri sunan Azure Key Vault etrafında şekillenir. Depolama için, Paylaşılan Erişim İmzaları (SAS), hesap anahtarlarını ifşa etmeden istemcilere kapsamı belirlenmiş, zamanla sınırlı yetki devri sağlar.

Microsoft Identity Platform, OAuth 2.0, MSAL ve Uygulama Kayıtları

Microsoft Identity Platform, farklı uygulama türleri için optimize edilmiş birden fazla OAuth 2.0 akışını destekler:

• Yetkilendirme kodu akışı (Authorization code flow): Web uygulamaları, SPA’lar ve yerel (native) uygulamalar için standart akıştır. Genel istemciler (public clients), yetkilendirme kodunu korumak için PKCE kullanmalıdır. Uygulamalar, kullanıcıları yetkilendirme uç noktasına (authorize endpoint) yönlendirir, yönlendirme URI’sinde (redirect URI) bir yetkilendirme kodu alır ve ardından bu kodu token uç noktasında (token endpoint) bir erişim token’ı (access token) (ve isteğe bağlı olarak bir yenileme token’ı (refresh token)) almak için kullanır. SPA’lar için, yetkilendirme kodu + PKCE, eski örtük akışın (implicit flow) yerini alır ve token sızıntısı riskini azaltır.
• İstemci kimlik bilgileri akışı (Client credentials flow): Kullanıcı olmadan çalışan daemon’lar ve sunucudan sunucuya hizmetler tarafından kullanılır. Uygulama, bir istemci onayı (client assertion - sertifika) veya bir istemci parolası (client secret) kullanarak token talep eder. Burada yalnızca uygulama izinleri (app roles) mevcuttur ve bunların çoğu yönetici onayı (admin consent) gerektirir. Bu akış, statik olarak yapılandırılmış uygulama izinleri kümesini talep etmek için /.default kapsamını kullanır.
• Cihaz kodu akışı (Device code flow): Gömülü tarayıcısı olmayan cihazlar veya ortamlar için tasarlanmıştır. Uygulama, kimlik platformundan bir kullanıcı kodu ve doğrulama URL’si alır, kullanıcı ayrı bir cihazda kimliğini doğrular ve uygulama token uç noktasını yoklar (polling). Bir kullanıcı oturum açtığı için devredilmiş izinler (delegated permissions) geçerlidir.
• Örtük izin akışı (Implicit grant flow): Geçmişte SPA’lar tarafından token’ları doğrudan yetkilendirme uç noktasından almak için kullanılırdı. Artık PKCE ile yetkilendirme kodu akışı lehine kullanımı önerilmemektedir. Kullanılırsa, uygulama kaydı sırasında yine de bir yönlendirme URI’si (redirect URI) gereklidir.

MSAL (Microsoft Authentication Library), diller ve platformlar arasında tutarlı bir token alma deneyimi sağlar. Genel istemci uygulamaları (masaüstü, mobil, SPA), token’ları almak ve önbelleğe almak için AcquireTokenInteractive ve AcquireTokenSilent kullanır; yerel uygulamalar ayrıca cihaz kodu akışı için AcquireTokenByDeviceCode ve gizli istemci (confidential client) bağlamlarında yetkilendirme kodunu kullanmak için AcquireTokenByAuthorizationCode kullanır. Gizli istemciler (web uygulamaları/API’ler/daemon’lar), istemci kimlik bilgilerini kullanırken AcquireTokenForClient ile ve bir API’nin bir kullanıcının devredilmiş bağlamıyla alt API’leri çağırdığı OBO (On-Behalf-Of) senaryoları için AcquireTokenOnBehalfOf ile token alır.

Token önbelleğe alma (caching), MSAL’in ayrılmaz bir parçasıdır: erişim ve yenileme token’larını hesap, istemci ve kapsama göre anahtarlayarak saklar, bu da AcquireTokenSilent‘ın gereksiz etkileşimli istemleri önlemesini sağlar. Birden çok örnekte (instance) çalışan web uygulamaları ve API’ler, token önbelleğini paylaşılan, şifreli bir depolama alanı (örneğin, bekleme durumunda (at rest) ve aktarım sırasında (in transit) uygun şifrelemeye sahip dağıtılmış bir önbellek) kullanarak kalıcı hale getirmeli ve korumalıdır. MSAL’deki önbellek serileştirme kancaları (hooks), güvenli kalıcılığı mümkün kılar. Kapsamlar (scopes), bir uygulamanın talep ettiği izinleri tanımlar. Devredilmiş izinler için, en az düzeyde, kaynağa özgü kapsamları talep edin (örneğin, https://graph.microsoft.com/User.Read). İstemci kimlik bilgileri için, kaynağa dayalı /.default kapsamını talep edin; bu, uygulamaya statik olarak verilmiş uygulama izinleriyle eşleşir (örneğin, scope = https://graph.microsoft.com/.default). Kapsamları aşamalı olarak talep etmek ve kullanıcı deneyimindeki zorluğu azaltmak için artımlı onay (incremental consent) kullanın.

Azure AD uygulama kayıtları (app registrations), uygulama kimliğini, kimlik bilgilerini, yönlendirme URI’lerini ve izinleri tanımlar. Devredilmiş izinler (Delegated permissions) oturum açmış bir kullanıcı gerektirir ve genellikle kullanıcıların kendi verileri için kendileri tarafından onaylanabilir; uygulama izinleri (application permissions) ise uygulamanın kendisine verilir ve kiracı genelinde veya geniş bir alanda geçerli oldukları için neredeyse her zaman bir yöneticinin onayını gerektirir. API’leri kullanıma sunan uygulamalar, “Expose an API” (Bir API’yi kullanıma sun) bölümü altında kapsamları (devredilmiş izinler için) ve uygulama rollerini (app roles - uygulama izinleri için) beyan eder. Güven sınırlarına bağlı olarak tek kiracılı (single-tenant) veya çok kiracılı (multi-tenant) erişimi yapılandırın ve daha güçlü kimlik bilgileri ve daha kolay rotasyon için istemci parolaları (client secrets) yerine sertifikaları kullanın.

Microsoft Graph aynı token yayınlama mekanizmasını kullanır. Graph kaynağını hedefleyerek MSAL ile kimlik doğrulaması yapın ve en az ayrıcalık ilkesine uygun (least-privilege) kapsamları talep edin. Yaygın kullanılan uç noktalar şunlardır:

• GET https://graph.microsoft.com/v1.0/me, devredilmiş token’lar ile kullanıcı profili için (ör. User.Read)
• GET https://graph.microsoft.com/v1.0/users ve /groups, dizin nesneleri için (User.Read.All veya Group.Read.All gibi uygun devredilmiş veya uygulama izinleri gerektirir)
• GET https://graph.microsoft.com/v1.0/sites veya /drives, SharePoint/OneDrive işlemleri için İstemci kimlik bilgilerini kullanırken, /.default kapsamını talep edin ve gerekli uygulama izinleri için yönetici onayının (admin consent) mevcut olduğundan emin olun. Kullanıcıların nerede oturum açabileceğini ve token’ların nerede oluşturulabileceğini kontrol etmek için doğru yetkiliyi (authority) (kiracıya özgü ve ortak/kuruluşlar (common/organizations) karşılaştırması) seçin.

Yönetilen Kimlikler ve Azure Kaynaklarına Güvenli Erişim, ayrıca Key Vault Referansları

Azure kaynakları için yönetilen kimlikler, Azure’un hizmet sorumlusu kimlik bilgilerini yönetmesine olanak tanıyarak gizli anahtar (secret) ihtiyacını ortadan kaldırır. Sistem tarafından atanan yönetilen kimlikler bir kaynakla (App Service, Function App, VM, VMSS, Logic App vb.) 1’e 1 ilişkilidir ve onun yaşam döngüsünü paylaşır; kaynak silindiğinde kimlik de silinir. Kullanıcı tarafından atanan yönetilen kimlikler, birden çok işlem kaynağına eklenebilen ve herhangi bir iş yükünün yaşam döngüsünden bağımsız olarak var olan, tek başına Azure kaynakları olarak oluşturulur. Bu model, kimliğin yeniden kullanılmasını ve görevlerin ayrılmasını destekler.

Yönetilen bir kimlikle Azure kaynaklarına erişmek için, ona doğru kapsamda uygun Azure RBAC rolünü atayın:

• Azure AD ile Azure Storage veri düzlemi için, bir depolama hesabı, kapsayıcı veya RG/abonelik kapsamında Storage Blob Data Reader/Contributor gibi roller atayın.
• Key Vault (RBAC veri düzlemi modeli) için, Key Vault Secrets User veya Key Vault Crypto Officer gibi roller atayın.
• Uygulama izinleri aracılığıyla Microsoft Graph için, yönetilen kimlikler yalnızca bir uygulama kaydı ilişkilendirildikten sonra aşağı akış API’lerini çağırabilir. İş yükü kimlik federasyonunu kullanın veya gerektiğinde kurumsal uygulama izinlerini ve yönetici onayını yapılandırın.

Çalışma zamanında, belirteçleri (token) almak için VM’lerdeki Instance Metadata Service (IMDS) veya App Service tarafından yönetilen uç noktayı kullanın; Azure Identity’s DefaultAzureCredential gibi SDK’lar, kullanılabilir olduğunda yönetilen kimlik uç noktasını otomatik olarak kullanacaktır. Bu, gizli anahtarları saklama ihtiyacını ortadan kaldırır ve platform tarafından döndürülmelerini (rotation) destekler.

App Service ve Azure Functions’daki Key Vault referansları, kod değişikliği yapmadan gizli anahtarların uygulama ayarlarına güvenli bir şekilde alınmasını sağlar. Bir uygulama ayarı değerinde, @Microsoft.KeyVault(SecretUri=https://{kasa-adı}.vault.azure.net/secrets/{ad}/{sürüm}) referans sözdizimini kullanın. Platform, başlangıçta uygulamanın yönetilen kimliğini kullanarak referansı çözer ve periyodik olarak yeniler. Yönetilen kimliğin, Key Vault erişim ilkeleri aracılığıyla gizli anahtarlar için Get iznine veya RBAC veri düzlemi modeli kullanılırken Key Vault Secrets User rolüne sahip olduğundan emin olun. Key Vault referansları, uygulama yapılandırma deposunda asla düz metin olarak saklanmaması gereken yapılandırma değerleri için idealdir ve gizli anahtar işleme mantığını uygulama kodundan kaldırır.

Azure Key Vault: Gizli Anahtarlar, Anahtarlar, Sertifikalar ve Erişim Denetimi

Azure Key Vault üç nesne türü depolar:

• Gizli Anahtarlar (Secrets): Parolalar, bağlantı dizeleri veya API anahtarları gibi opak dizelerdir. Sürümlüdür; istemciler genellikle Get ve Set işlemlerini gerçekleştirir.
• Anahtarlar (Keys): İmzalama/doğrulama, şifreleme/şifre çözme ve sarmalama/sarmalamayı çözme (wrap/unwrap) işlemleri için kullanılan kriptografik anahtarlardır (RSA, EC). Anahtar materyali HSM destekli hizmet tarafından korunur; istemciler, özel anahtar materyalini dışa aktarmak yerine hizmet aracılığıyla kripto işlemlerini çağırır.
• Sertifikalar (Certificates): Yaşam döngüsü yönetimine sahip, isteğe bağlı olarak iş ortağı Sertifika Yetkilileri (CA) ile entegre olan X.509 nesneleridir. Sertifikalar, bir sertifika artı karşılık gelen bir gizli anahtar (PFX) ve isteğe bağlı olarak yönetilen bir anahtar olarak somutlaştırılır.

Geçici silme (soft delete) varsayılan olarak açıktır ve silinen nesneleri bir saklama süresi boyunca korur. Saklama süresi içinde geri döndürülemez silmeyi önlemek ve kurtarma garantilerini (genellikle 90 günlük bir saklama gereksinimi) zorunlu kılmak için temizleme korumasını (purge protection) etkinleştirin. Katı kurtarma ilkelerini karşılamak için geçici silme ve temizleme korumasını birleştirin. Ek olarak, kasa ağ erişimini özel uç noktalar (private endpoints) ile güvence altına alın ve mümkün olan yerlerde genel ağ erişimini devre dışı bırakın.

Erişim denetimi, veri düzlemi için eski kasa erişim ilkelerini (vault access policies) veya Azure RBAC’yi kullanabilir. Erişim ilkeleri kasa başına yapılandırılır ve sorumlulara (principal) açıkça izinler (Get, List, Set, Sign, Wrap) verir; kalıtsal değildirler ve büyük ölçekte operasyonel olarak ağırlaşabilirler. RBAC veri düzlemi modeli, Azure rollerini (ör. Key Vault Administrator, Key Vault Secrets Officer, Key Vault Secrets User, Key Vault Crypto Officer) kullanır ve Azure RBAC ile entegre denetim ile abonelik, kaynak grubu veya kasa düzeyinde kapsam belirlemeyi destekler. Bir model seçin; veri düzlemi için RBAC etkinleştirilirse, erişim ilkeleri yoksayılır. Yönetim düzlemi işlemleri (kasanın oluşturulması/güncellenmesi) her zaman Azure RBAC kullanır.

Azure SDK’larını (ör. SecretClient, KeyClient, CertificateClient) ve DefaultAzureCredential’ı kullanarak Key Vault’u uygulamalarla entegre edin. Kimlik doğrulama için yönetilen kimlikleri tercih edin, kimlik bilgilerini gömmekten kaçının ve Kasa API’lerini çağırırken yeniden deneme ve kısıtlama (throttling) ilkeleri uygulayın.

Azure Storage SAS ve Saklı Erişim İlkeleri

Paylaşılan Erişim İmzaları (Shared Access Signatures - SAS), hesap anahtarlarını ifşa etmeden Azure Storage’a ayrıntılı ve zaman sınırlı erişim yetkisi verir:

• Kullanıcı Yetkilendirme SAS’ı (Yalnızca Blob): Azure AD tarafından desteklenir. Uygulama, Azure AD kimlik bilgilerini kullanarak Blob hizmetinden bir kullanıcı yetkilendirme anahtarı alır, ardından istemciler için SAS belirteçleri oluşturur. Bu, hesap anahtarlarının kullanımını önlediği ve rol tabanlı yetkilendirme ile uyumlu olduğu için kullanıcı merkezli senaryolar için en güvenli yaklaşımdır.
• Hizmet SAS’ı: Belirli bir kaynakla (blob, container, kuyruk mesajı, tablo varlığı, dosya) sınırlıdır. Bir hesap anahtarıyla imzalanır. Hizmete bağlı olarak okuma, yazma, ekleme, oluşturma, silme, listeleme, değişmezlik ayarlama ve etiketler gibi izinleri destekler.
• Hesap SAS’ı: Birden çok hizmet (Blob, Queue, Table, File) ve kaynak türü üzerinde en geniş kapsama sahiptir. Geniş etki alanı nedeniyle idareli kullanılmalıdır.

SAS belirteçleri; sona erme zamanı (se), başlangıç zamanı (st), izinler (sp), IP aralıkları (sip), izin verilen protokoller (spr), imzalanan kaynak (sr) ve saklı bir erişim ilkesine bağlandığında imzalanan tanımlayıcı (si) gibi kısıtlamalar içerir. Yalnızca gerekli izinleri vererek, sona erme sürelerini kısa tutarak ve HTTPS’yi (spr=https) zorunlu kılarak en az ayrıcalık ilkesini izleyin. Mümkün olan yerlerde kullanıcı yetkilendirme SAS’ını tercih edin; aksi takdirde, iptal işlemi için saklı bir erişim ilkesiyle hizmet SAS’ı kullanın.

Saklı erişim ilkeleri; container’lar, dosya paylaşımları, kuyruklar veya tablolarda bulunur ve yeniden kullanılabilir bir kısıtlama seti (izinler, başlangıç, sona erme) tanımlar. Bir SAS oluştururken, ilkeye tanımlayıcısı aracılığıyla referans verin. Bu, tüm SAS belirteçlerini yeniden yayınlamak zorunda kalmadan merkezi olarak iptal etmeyi veya kapsamı daraltmayı sağlar; ilkeyi güncellemek veya silmek, ona bağlı tüm SAS belirteçlerini anında etkiler. Hizmet veya hesap SAS’ı kullanılıyorsa hesap anahtarlarını düzenli olarak döndürün ve kullanımı tanılama ayarları ve Azure Monitor günlükleri aracılığıyla izleyin.

Pratik Problem Senaryosu

Adobe, Azure üzerinde çok kiracılı bir medya işleme portalı sunuyor. Müşteriler kendi Microsoft Entra ID kiracılarıyla oturum açar, büyük medya dosyalarını doğrudan Blob depolama alanına yükler ve işlem durumunu takip eder. Çözüm, gizli anahtarları (secret) saklamaktan kaçınmalı, izinleri merkezileştirmeli ve gizli anahtarların en az 90 gün boyunca kurtarılabilir olmasını sağlamalıdır.

1. Uygulamaları Microsoft Entra ID’ye kaydetme:

   • Portal kullanıcı arayüzü için bir SPA ve arka uç API’si için bir gizli istemci (confidential client) oluşturun. Temsilci erişimi (delegated access) için API kapsamlarını (scope) kullanıma açın ve arka plan işleri için uygulama rolleri tanımlayın. SPA’yı, tam yönlendirme URI’leri ile yetkilendirme kodu + PKCE kullanacak şekilde yapılandırın. Bu, her istemciyi doğru OAuth akışıyla hizalar ve en az ayrıcalık onay sınırlarını zorunlu kılar.

2. SPA ve arka uçta MSAL’i uygulama:

   • SPA, artımlı onay (incremental consent) ile AcquireTokenInteractive/AcquireTokenSilent kullanarak arka uç API’si için belirteçler alır. Arka uç, oturum açmış kullanıcının temel profilini okumak için Microsoft Graph’ı çağırmak üzere AcquireTokenOnBehalfOf kullanır. Bu, kullanıcı bağlamını uçtan uca korur ve belirteç önbelleğe alma yoluyla istemleri en aza indirir.

3. App Service (API) ve Azure Functions’ta (medya işlemcileri) sistem tarafından atanan yönetilen kimlikleri etkinleştirme:

   • Medya container’ında Storage Blob Veri Katkıda Bulunanı (Storage Blob Data Contributor) ve kasada Key Vault Gizli Anahtar Kullanıcısı (Key Vault Secrets User) rollerini atayın. Yönetilen kimlikler, gizli anahtar dağınıklığını ortadan kaldırır ve platformun kimlik bilgilerini otomatik olarak döndürmesine olanak tanırken Azure RBAC aracılığıyla Storage ve Key Vault’a güvenli erişim sağlar.

4. Azure Key Vault’u RBAC veri düzlemi, geçici silme (soft delete) ve temizleme koruması (purge protection) ile yapılandırma:

   • Arka uç onayı (assertion) için imzalama sertifikalarını, üçüncü taraf API anahtarlarını ve AAD ile değiştirilemeyen tüm bağlantı gizli anahtarlarını saklayın. 90 gün boyunca kurtarmayı garanti etmek için geçici silmeye ek olarak temizleme korumasını zorunlu kılın. RBAC, denetimi basitleştirir ve kasaya özgü erişim ilkelerine kıyasla ortamlar arasında ölçeklenir.

5. Yapılandırma için Key Vault referanslarını kullanma:

   • App Service ve Functions uygulama ayarlarındaki gizli anahtarlara @Microsoft.KeyVault(SecretUri=…) kullanarak referans verin. Platform, yönetilen kimlikle değerleri çözer ve yeniler, bu da kod değişikliklerini ortadan kaldırır ve gizli anahtarların düz metin yapılandırmasında saklanmasını önler.

6. Doğrudan tarayıcı yüklemelerini SAS ile devretme:

   • Arka uç, IP ve HTTPS ile kapsamı belirlenmiş, belirli bir blob yoluna kısa ömürlü, yalnızca yazma erişimi için kullanıcı yetkilendirme SAS belirteçleri yayınlar. Operasyonel toplu işlem araçları için, container üzerinde saklı bir erişim ilkesine bağlı hizmet SAS’ı oluşturun, böylece ilkeyi güncelleyerek veya silerek belirteçler merkezi olarak iptal edilebilir. Bu, hesap anahtarlarını ifşa etmeden yüksek verimli istemci yüklemelerini mümkün kılar ve acil durum iptalini destekler.

7. Microsoft Graph’ı minimum düzeyde entegre etme:

   • SPA’da profil gösterimi için https://graph.microsoft.com/User.Read isteğinde bulunun ve herhangi bir uygulama izni gerekiyorsa (önceden yönetici onayı ile) arka uçta https://graph.microsoft.com/.default kullanın. /.default kullanmak, arka ucun merkezi olarak verilen uygulama izinlerini dikkate almasını sağlar ve çalışma zamanında aşırı kapsam talebinde bulunmaktan kaçınır.

Bu tasarım, SPA’yı güvence altına almak için yetkilendirme kodu + PKCE, kullanıcı bağlamını aşağı akışta korumak için OBO, gizli anahtarları ortadan kaldırmak için yönetilen kimlikler ve RBAC, güçlü kurtarma garantileriyle Key Vault, yapılandırma hijyeni için Key Vault referansları, en az ayrıcalık kapsamlarıyla Graph ve güvenli, iptal edilebilir istemci yüklemeleri için saklı erişim ilkelerine sahip SAS kullanır.

← Azure Konteyner Çözümleri · Tüm alanlar · Azure API Yönetimi →

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

Microsoft'a göz atın →