Microsoft AZ-500: Anahtar Yönetimi, Kriptografi ve Sertifikalar — Ç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 anahtar yönetimi, Azure Key Vault ve Azure Managed HSM hizmetleri etrafında şekillenir. Bu hizmetler, bekleme durumunda (at rest), aktarım sırasında (in transit) ve uygulama katmanında şifrelemeyi destekleyen kriptografik materyaller için güvenli depolama, tutarlı API’ler ve denetlenebilir operasyonlar sunar. Operasyonel amaç; anahtar saklama sorumluluğunu uygulama çalışma zamanından ayırmak, kapsamı belirlenmiş yetkilendirme ve ağ yapılandırması ile etki alanını en aza indirmek ve uzun ömürlü gizli anahtar riskini azaltmak için kurtarılabilirlik ve rotasyonu zorunlu kılmaktır.

Azure Key Vault ve Managed HSM Mimarisi ve Yetkilendirme

Azure Key Vault mimarisi

• Hizmet bileşimi: çok kiracılı ön uçlar, veri düzlemi için bölgesel bölümler, kiracı başına yalıtım ve Azure AD destekli kimlik doğrulama. Anahtarlar ya yazılım korumalıdır (Standart katman) ya da HSM korumalıdır (Premium katman). Gizli anahtarlar (secrets) ve sertifikalar her zaman yazılım korumalıdır.
• Katmanlar: Genel amaçlı kullanım ve maliyet verimliliği için Standart (yazılım anahtarları); FIPS 140-2 Seviye 2/3 eşdeğeri koruma veya anahtar materyali için adanmış bir HSM sınırı gerektiğinde Premium (HSM destekli anahtarlar). Düzenleyici gereksinimler veya “RSA-HSM” ya da “EC-HSM” içeren anahtarlar kullanıldığında Premium’u seçin.
• Geçici silme ve temizleme koruması: Geçici silme, yapılandırılabilir bir saklama süresiyle (7–90 gün, genellikle 90) her zaman açıktır. Temizleme koruması etkinleştirildiğinde, yüksek ayrıcalıklı kullanıcılar tarafından bile, saklama süresi dolana kadar kasanın veya nesnelerin kalıcı olarak silinmesini önler. Operasyonel gerekçe: müşteri tarafından yönetilen anahtarları (CMK) destekleyen herhangi bir kasada temizleme korumasını etkinleştirin. Bu koruma olmadan, kazara veya kötü niyetli bir temizleme işlemi, bağımlı verileri (örneğin, o anahtarla şifrelenmiş depolama veya veritabanları) kurtarılamaz hale getirebilir.
• Kurtarma: Silinen kasa nesneleri listelenebilir ve kurtarılabilir; kasa düzeyinde kurtarma desteklenir. Yedeklemeler, aynı Azure bölgesi ve bulutundaki uyumlu kasalara geri yüklenebilen şifrelenmiş bloblar üretir. Gerekçe: anahtar yedeklerini periyodik olarak dışa aktarın ve ayrı olarak güvence altına alın; RTO’yu doğrulamak için geri yüklemeleri test edin.

Yetkilendirme modeli

• İzin modelleri: Kasa erişim ilkeleri (eski) ve Azure RBAC (önerilen).
  • Erişim ilkeleri: kasa başına tanımlanır; anahtarlar, gizli anahtarlar ve sertifikalar için ayrıntılı izinler verir. Az sayıda sorumlu (principal) için çok sıkı, nesne türüne özgü çalışma zamanı haklarına ihtiyaç duyduğunuzda en iyisidir.
  • Azure RBAC: RBAC veri düzlemi rollerini kullanmak için kasanın İzin modelini Azure rol tabanlı erişim denetimi olarak ayarlayın. Avantajları: abonelik/kaynak grubu/kasa düzeyinde kapsam belirleme; PIM’e uygun atamalar; merkezi yönetim ve denetim. Yeni dağıtımlar ve idari operasyonlar için önerilir.
• Yerleşik kasa rolleri (örnekler): Key Vault Yöneticisi (tam yönetim), Key Vault Kripto Sorumlusu (anahtar yönetimi yapar ancak erişim ilkelerini yönetemez), Key Vault Gizli Anahtar Sorumlusu, Key Vault Sertifika Sorumlusu, Key Vault Okuyucusu. Operasyonel rehberlik:
  • Erişim modellerinin ve ağ ACL’lerinin yapılandırmasını devrederken RBAC kullanın (ör. Key Vault Yöneticisi).
  • Tek bir kasada en az ayrıcalık ilkesiyle sertifika ekleme/silme işlemleri için bir erişim ilkesi veya Key Vault Sertifika Sorumlusu gibi bir veri düzlemi RBAC rolü kullanın.
• Kapsam tasarımı: Aşırı yetkilendirmeyi önlemek için RBAC atamalarını kasa kapsamında yapmayı tercih edin. Kaynak grubu kapsamını yalnızca birden çok kasanın aynı operatör ekiplerini paylaştığı durumlarda kullanın; çalışma zamanı erişimi için abonelik kapsamındaki atamalardan kaçının.

Managed HSM

• Mimari ve güvenlik etki alanları: Managed HSM, müşteri başına tek kiracılı, FIPS 140-2 Seviye 3 onaylı bir HSM kümesidir. Bir güvenlik etki alanı, kümenin anahtar materyali taşınabilirliğini korur; kümeler arasında yedekleme/geri yükleme, güvenlik etki alanı özel anahtarlarından bir yeter sayısı (quorum) gerektirir. Gerekçe: etki alanı anahtarlarını farklı sorumlular arasında oluşturun ve emanete alın; bir DR HSM’e geri yüklemeyi test edin.
• Rol modeli: Azure RBAC ile entegredir. Roller arasında Managed HSM Yöneticisi, Kripto Sorumlusu, Kripto Kullanıcısı ve Okuyucu bulunur. Görevlerin ayrılığı: yöneticiler kümeyi yönetir; kripto sorumluları anahtarları yönetir; kripto kullanıcıları operasyonlar için anahtarları kullanır.
• Yüksek erişilebilirlik: Birden çok HSM bölümü ve SLA destekli bir hizmet ile bölgesel olarak yedeklidir; desteklenen bölgelerde alan (zone) yedekliliği mevcuttur. Bölgeler arası olağanüstü durum kurtarma için yedeklemelere ve güvenlik etki alanına güvenin.
• Kullanım senaryoları: Ödeme işlemleri, kod imzalama, zarf şifrelemesi için anahtar sarmalama ve Seviye 3 HSM sınırları gerektiren düzenlemeye tabi iş yükleri.

Nesneler ve Yaşam Döngüsü: Anahtarlar, Gizli Anahtarlar, Sertifikalar ve Rotasyon

Anahtarlar, gizli anahtarlar, sertifikalar

• Anahtarlar: Kriptografik işlemler için (imzalama, doğrulama, sarmalama/çözme, şifreleme/şifre çözme). Algoritma gücü ve performansa göre anahtar türünü/boyutunu seçin (örneğin, uyumluluk için RSA 3072/4096 veya performans için ECC P-256/P-384).
• Gizli Anahtarlar: Parolalar, bağlantı dizeleri ve API belirteçleri gibi rastgele baytlar/dizeler. Kriptografik işlemler için kullanılmazlar.
• Sertifikalar: Özel anahtarlara sahip X.509. Hem bir sertifika nesnesi hem de karşılık gelen bir gizli anahtar (PFX/PEM) olarak saklanır. TLS/MTLS ve kod imzalama yaşam döngüleri için kullanışlıdır.

Yaşam döngüsü işlemleri ve rotasyon

• Sürümlendirme: Her ayarlama veya içeri aktarma işlemi, değiştirilemez bir sürüm oluşturur. Uygulamalar, değişiklik yönetimi ihtiyaçlarına bağlı olarak deterministik davranış için sürümlü gizli anahtarlara veya en son sürümün otomatik olarak alınması için sürüm belirtmeyen URI’lere başvurmalıdır.
• Rotasyon stratejileri:
  • Anahtarlar: Bunları destekleyen Azure hizmetleri (örneğin, Storage, SQL TDE, AKV tarafından yönetilen gizli anahtarlar) için sürüm belirtmeyen anahtar URI’lerini tercih edin. Yeni bir sürüm ekleyerek rotasyon yapın; desteklendiğinde hizmetler otomatik olarak yeniden bağlanır. Bir hizmetin sabitlenmiş bir sürüm gerektirmesi durumunda, yeniden yapılandırma adımını otomatikleştirin. AKV rotasyon ilkeleri ve uyarılarla rotasyonu zorunlu kılın.
  • Gizli Anahtarlar: Event Grid bildirimleriyle tetiklenen Azure Automation, Functions veya Logic Apps aracılığıyla rotasyon yapın ya da sağlayıcıya özgü rotasyonu kullanın (örneğin, SAS veya veritabanı parolalarını döndürme). Mümkün olan her yerde yönetilen kimliklerle değiştirerek uzun ömürlü statik gizli anahtarlardan kaçının.
  • Sertifikalar: Süresi dolmadan önce otomatik yenileme için “yaşam süresi eylemleri” içeren sertifika ilkeleri tanımlayın; elle müdahale gerektirmeyen yenileme için entegre sertifika veren kuruluşları (issuer) kullanın.

Sertifika yönetimi

• İçeri aktarma/oluşturma: Mevcut PFX/PEM’i (özel anahtarla birlikte) içeri aktarın veya bir CSR oluşturun ve Key Vault’un yapılandırılmış bir CA ile sertifika verme işlemini tamamlamasını sağlayın.
• Otomatik yenileme ve sertifika veren kuruluşlar: Key Vault aracılığıyla DigiCert, GlobalSign veya kurumsal bir Microsoft CA gibi sertifika veren kuruluşları yapılandırın. Bildirim ve yenileme eşikleriyle otomatik yenilemeyi etkinleştirin.
• Uygulama entegrasyonu:
  • App Service ve Functions: yönetilen kimlikle Key Vault referanslarını kullanın; platform, rote edilmiş gizli anahtarları otomatik olarak senkronize eder.
  • Application Gateway/WAF: Key Vault’tan sertifika gizli anahtarı ID’sine referans verin; Gateway yeni sürümleri otomatik olarak alır.
  • AKS: Secrets Store CSI sürücüsü ve Azure Key Vault sağlayıcısı aracılığıyla sertifikaları bağlayın (mount).

En az ayrıcalıkla sertifika işlemleri için örnek RBAC ataması:

az role assignment create \
  --assignee <userObjectId> \
  --role "Key Vault Certificates Officer" \
  --scope $(az keyvault show -n kv-prod --query id -o tsv)

Ağ Güvenliği ve Hizmet Entegrasyonu

Key Vault ağ yapılandırması

• Güvenlik duvarı kuralları: Onaylanmış kaynaklarla kısıtlamak için “Seçili ağlar” (Selected networks) olarak ayarlayın. Gerekçe: geçerli belirteçlerle bile internet kaynaklı trafiği engeller.
• Sanal ağ hizmet uç noktaları: Belirli alt ağlardan gelen trafiğe özel IP’ler olmadan izin verin. Etkinleştirmesi basittir ve riski azaltır. Hızlı izolasyona ihtiyaç duyduğunuzda ve DNS değişiklikleri gerektirmediğinde kullanın.
• Özel uç noktalar (Private endpoints): Gerçek özel bağlantı için VNet’inizdeki kasaya (vault) özel bir IP atayın. Genel ağ erişimini engelleyin. Gerekçe: en güçlü veri sızdırma kontrolünü sağlar, yüksek güvenilirlikli ortamlarda ve giden internetin kısıtlandığı durumlarda gereklidir.
• Güvenilir hizmetler: “Güvenilir Microsoft hizmetlerine izin ver” (Allow trusted Microsoft services) seçeneği, belirli Azure hizmetlerinin ağ kısıtlamalarına rağmen kasaya ulaşmasını sağlar. Rotasyon sırasında Storage şifreleme tarama anahtarları gibi senaryolar için gereklidir. Kapsamı dar tutarak etkinleştirin ve bağımlılıkları belgeleyin.

Müşteri tarafından yönetilen anahtarlar (CMK) ve anahtar URI’leri

• Desteklenen hizmetler: Azure Storage, SQL Database (TDE), Synapse, Databricks, AKS’te bekleyen veriler için gizli anahtar şifrelemesi, App Configuration, Event Hubs, Service Bus ve Disk Encryption Set aracılığıyla Yönetilen Diskler (Managed Disks).
• Anahtar URI stratejisi:
  • Sürüm belirtmeyen URI’ler: Hizmet, yeni anahtar sürümlerinde otomatik yeniden bağlanmayı desteklediğinde tercih edin; hizmet güncellemeleri olmadan sorunsuz rotasyon sağlar.
  • Sürümlü URI’ler: Bazı hizmetler tarafından gereklidir; rotasyon olaylarına bağlı bir hizmet yapılandırma güncellemesini otomatikleştirin.
• Rotasyon desenleri:
  • Aşamalı rotasyon: Yeni bir anahtar sürümü oluşturun; hizmetin erişebildiğini doğrulayın; hataları izleyin; ardından güvenli bir sürenin ardından isteğe bağlı olarak eski sürümleri devre dışı bırakın.
  • Olay güdümlü: Doğrulama veya hizmet yeniden yapılandırma iş akışlarını tetiklemek için anahtar-yeni-sürüm olaylarında Event Grid’i kullanın.

Zarf şifreleme entegrasyonu

• Azure hizmetleri yerel olarak bir veri şifreleme anahtarı (DEK) (ör. AES-256) ve DEK’i sarmalamak için Key Vault/HSM’de bir Anahtar Şifreleme Anahtarı (KEK) kullanır. Operasyonel olarak, KEK’in kullanılabilirliğini ve ağ erişimini sağlayın, çünkü kayıp veya engellenen erişim hizmet operasyonlarını durdurabilir.

Örnek: bir DEK’i bir AKV anahtarıyla sarmalama

# base64-encode a 32-byte DEK; wrap using RSA-OAEP
az keyvault key wrap-key \
  --vault-name kv-prod \
  --name app-kek \
  --algorithm RSA-OAEP \
  --value $(openssl rand -base64 32)

Kriptografi, Duran Veri (Data-at-Rest) Seçenekleri ve Gizli Bilgi Hijyeni

Temel kriptografik kavramlar

• Simetrik şifreleme: Şifreleme/şifre çözme için tek bir anahtar kullanılır (ör. AES-GCM/CTR). Hızlıdır; toplu veriler için idealdir.
• Asimetrik şifreleme: Anahtar değişimi ve imzalar için genel/özel anahtar çiftleri (RSA/ECC) kullanılır. Daha yavaştır; güven oluşturmak ve DEK’leri sarmalamak (wrapping) için idealdir.
• Özetleme (Hashing): Tek yönlü bir özet (digest) oluşturur (ör. SHA-256). Bütünlük içindir; şifreleme değildir.
• İmzalama: Özel anahtar bir imza üretir; genel anahtar doğrular. İnkar edilemezlik ve bütünlük sağlar.
• Zarf şifrelemesi (Envelope encryption): Performans ve anahtar saklama sorumluluğunun izolasyonu için asimetrik KEK ile simetrik DEK’i birleştirir.

Azure Disk Encryption ve depolama şifrelemesi

• Yönetilen Diskler (Managed Disks) varsayılan şifrelemesi: Platform tarafından yönetilen anahtarlarla (PMK) sunucu tarafı şifreleme (SSE). Minimum operasyonel yük.
• Disk Encryption Set (DES) ile CMK: Diskler, anlık görüntüler (snapshots) ve imajlar için bir Key Vault veya Managed HSM anahtarına referans veren bir DES kullanın. Gerekçe: merkezi anahtar yaşam döngüsü kontrolü ve iptali; müşteri kontrolü için uyumluluk gereksinimlerini karşılar.
• ADE (Azure Disk Encryption): Konuk işletim sistemi içinde BitLocker (Windows) veya dm-crypt (Linux). İşletim sistemi düzeyinde şifreleme duruşuna, etki alanına (domain) bağlı disk düzeyinde anahtar koruyuculara veya mevcut uyumluluk zorunluluklarına ihtiyacınız olduğunda kullanılır. Operasyonel ödünleşim: daha yüksek karmaşıklık, eklenti yönetimi ve potansiyel VM sağlama (provisioning) etkisi.
• Çift şifreleme:
  • Diskler: İki bağımsız şifreleme katmanı elde etmek için altyapı katmanında PMK ile SSE’yi ve DES aracılığıyla CMK’yi birleştirin.
  • Depolama hesapları: Konteyner/iş yükü başına ayrı CMK’ler ile şifreleme kapsamlarını (encryption scopes) kullanın; iki katman için mevcut olduğunda altyapı şifrelemesiyle birleştirin.
• Şifreleme kapsamları (Encryption scopes - Azure Storage): Kiracı/iş yükü riskini izole etmek ve geniş bir etki yaratmadan hedeflenmiş anahtar rotasyonunu sağlamak için konteyner veya blob başına farklı CMK’ler ile kapsamlar tanımlayın.

Gizli bilgi hijyeni ve operasyonel uygulamalar

• Yönetilen kimlikler (Managed identities): Key Vault ve diğer hizmetler için token almak amacıyla Azure kaynakları için sistem veya kullanıcı tarafından atanan yönetilen kimlikleri kullanın, böylece gömülü kimlik bilgilerini ortadan kaldırın. RBAC veya erişim ilkelerini dar kapsamlı tutun.
• Gizli bilgi taraması (Secret scanning): Microsoft Defender for DevOps, GitHub Advanced Security gizli bilgi taraması ve depo korumalarını etkinleştirin. Bilinen kimlik bilgisi kalıplarını engellemek için pull request’lerle entegre edin.
• İş hatları (Pipelines) ve IaC: Kalıcı gizli bilgileri önlemek için Azure Pipelines’daki Key Vault görev entegrasyonlarını ve GitHub Actions’daki OIDC tabanlı birleşik kimlik bilgilerini (federated credentials) kullanın. Gizli bilgileri loglara yazdırmayın; çıktıları maskeleyin. Sızdırılan herhangi bir materyali derhal rote edin (değiştirin).
• Uygulama tasarımı: Güvenli olduğu durumlarda sürümsüz referansları tercih edin; minimum düzeyde önbelleğe alın ve rotasyon olaylarını desteklemek için token’ları yeniden alarak ve gizli bilgileri yeniden çekerek 401/403 hatalarını yönetin.

Sertifika Yönetimi Derinlemesine Bakış

• İlke tabanlı yayınlama: Bir Key Vault sertifika ilkesinde konu (subject), SAN’lar, anahtar kullanımı, EKU’lar, anahtar türü/boyutu ve anahtarın yeniden kullanım ayarlarını tanımlayın. Gerekçe: tüm altyapıda tutarlı bir TLS duruşu sağlamak.
• Yayıncı entegrasyonu: Key Vault’ta bir CA profili yapılandırın. Özel PKI için, özel bir yayıncı aracılığıyla Microsoft ADCS ile entegre olun veya Azure Key Vault’un Certificate Connector’ını kullanın. Genel CA’lar, özel anahtarları AKV dışında ifşa etmeden otomatik yenilemeye olanak tanır.
• Otomatik yenileme operasyonları: Yaşam döngüsü eylemlerini kullanın (örneğin, sürenin dolmasına 60 gün kala yenile; 90 gün kala bildir). Operasyonel olarak, yenileme pencerelerini değişiklik dondurma (change freeze) dönemleriyle hizalayın ve bağımlı hizmetlerin otomatik olarak senkronize olduğundan emin olun.
• Uygulama tarafından kullanım: Bir gizli anahtar (secret) olarak (PFX/PEM) alın veya platform hizmetlerinde referans ile bağlayın. Yeni sürümlerde sıfır kesintili geçiş (rollover) için App Service, Application Gateway gibi platforma özgü bağlamaları tercih edin. Kubernetes için, rotasyon sırasında sıralı yeniden başlatmaları (rolling restarts) tetiklemek üzere CSI aracılığıyla bağlayın (mount).

Pratik Problem Senaryosu

Siemens AG, Azure’daki IoT telemetrisini korumalı, bekleyen veri (data at rest) için güçlü anahtar velayetini zorunlu kılmalı ve küresel olarak dağıtılmış bir filo genelinde sertifika ve gizli anahtar rotasyonunu otomatikleştirmelidir.

1. Kasaları ve HSM sınırlarını oluşturma

• Uygulama gizli anahtarları/sertifikaları için bölgesel Premium Key Vault’lar ve KEK işlemleri için bir Managed HSM oluşturun.
• Gerekçe: Premium kasalar, gerektiğinde HSM destekli anahtarları etkinleştirir; Managed HSM, anahtar sarmalama (wrapping) işlemleri için Seviye 3 güvencesi ve bağımsız anahtar velayeti sağlar.

2. Kurtarılabilirliği ve koruma mekanizmalarını zorunlu kılma

• Tüm kasalarda ve Managed HSM’de kalıcı silme korumasını (purge protection) etkinleştirin; geçici silme (soft-delete) saklama süresini 90 gün olarak ayarlayın. Kalıcı silme koruması olmayan kasaları denetlemek/reddetmek için Azure Policy uygulayın.
• Gerekçe: Kalıcı silmelerden kaynaklanan feci veri kaybını önler; ilke, yapılandırma sapmalarının (drift) oluşmamasını sağlar.

3. RBAC kullanarak yetkilendirmeyi merkezileştirme

• Kasaları Azure RBAC izin modeline ayarlayın. PIM aracılığıyla küçük bir platform ekibine Key Vault Administrator rolünü atayın; uygulama ekiplerine kasa kapsamında Key Vault Secrets Officer rolünü atayın; güvenlik mühendislerine Managed HSM Crypto Officer rolünü atayın.
• Gerekçe: RBAC + PIM, en az ayrıcalık ilkesi, süresi sınırlı yetki yükseltme ve tutarlı denetim sağlar. Görevler ayrılığı, yöneticilerin anahtarları kullanmasını engeller.

4. Özel uç noktalarla ağ erişimini kısıtlama

• Hub VNet’lerinde özel uç noktalar oluşturun; genel ağ erişimini devre dışı bırakın. “Güvenilir hizmetler” seçeneğini yalnızca CMK kullanan Storage hesapları için etkinleştirin.
• Gerekçe: Özel uç noktalar, genel erişimi ortadan kaldırır ve veri sızdırma yollarını engellerken, gerekli hizmetten kasaya akışları korur.

5. CMK ve şifreleme stratejisini uygulama

• Storage için, Premium kasadaki sürümsüz KEK URI’ları ile iş yükü başına şifreleme kapsamları (encryption scopes) tanımlayın; Managed Disks için, HSM’den gelen CMK ile Disk Encryption Set’leri kullanın. Çift şifreleme için altyapı düzeyinde şifrelemeyi etkinleştirin.
• Gerekçe: İş yükü başına anahtarlar etki alanını (blast radius) azaltır; sürümsüz URI’lar sorunsuz rotasyon sağlar; çift şifreleme, katı uyumluluk gereksinimlerini karşılar.

6. Anahtar ve gizli anahtar rotasyonunu otomatikleştirme

• AKV anahtar rotasyon ilkelerini (örneğin, yıllık süre sonu, 9 ayda bir döndürme) ve doğrulama işlerini tetikleyen Event Grid bildirimlerini yapılandırın. Hizmetlerde yönetilen kimlikleri (managed identities) kullanın; statik kimlik bilgilerini kaldırın.
• Gerekçe: Öngörülebilir, otomatik rotasyon, uzun ömürlü anahtarlardan ve gizli anahtarlardan kaynaklanan riski azaltır; yönetilen kimlikler, kırılgan paylaşılan gizli anahtarların yerini alır.

7. Sertifikaları operasyonel hale getirme

• DigiCert yayıncı entegrasyonu ile Key Vault sertifika ilkelerini kullanın; sürenin dolmasından 60 gün önce otomatik yenilemeyi ayarlayın. Sertifikaları Application Gateway ve App Service’te referans ile bağlayın.
• Gerekçe: Otomatik yenileme, kesintileri önler ve manuel anahtar işlemlerini ortadan kaldırır; platform bağlamaları, yeniden dağıtım yapmadan yeni sürümleri alır.

8. Doğrulama ve izleme

• Key Vault ve Managed HSM tanılama günlüklerini Log Analytics’e göndererek etkinleştirin; yetkisiz denemeler, güvenlik duvarı reddetmeleri ve süresi dolmak üzere olan olaylar için uyarılar ayarlayın. Güvenlik alanı yeter sayısını (security domain quorum) kullanarak kasa ve HSM yedeklemeleri için üç ayda bir geri yükleme testleri yapın.
• Gerekçe: Sürekli izleme, yanlış yapılandırmaları veya saldırıları anında tespit eder; geri yükleme testi, baskı altında kurtarılabilirliği sağlar.

← Veri · Tüm alanlar · Güvenlik Duruşu Yönetimi ve Yönetişim →

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

Microsoft'a göz atın →