BitLocker policy’sini Intune’dan gönderip cihazın şifrelendiğini görmek işin kolay kısmı. Asıl kritik soru şu: recovery key gerçekten ne zaman Entra ID’ye yazılıyor, bu yazma işlemi başarısız olursa cihaz şifresiz mi kalıyor yoksa key’siz mi encrypt oluyor, ve bir key bir kere kullanıldıktan sonra hâlâ geçerli mi? Bu sorulara “policy’yi doğru kurdum, recovery key backup Yes görünüyor” cevabı yetmiyor; escrow’un arka planda nasıl işlediğini bilmeden bir olay anında (kayıp cihaz, sızmış key, helpdesk üzerinden paylaşılan şifre) doğru karar vermek zor.
Bu yazıda BitLocker recovery key’in cihazda üretilmesinden Entra ID’de veya AD DS’te saklanmasına kadar olan escrow mimarisini, escrow başarısız olduğunda encryption’ın davranışını, key rotation’ın hangi koşulda tetiklendiğini, self-service erişimin yetkilendirme modelini ve audit log tarafında gerçekte neyin kaydedildiğini anlatıyorum. Policy’nin nasıl kurulacağı ayrı bir konu; burada odak, kurulu bir policy’nin arkasında ne olduğu.
Recovery Key Ne Zaman Escrow Ediliyor?
BitLocker bir sürücüyü şifrelemeye başladığında iki şey üretir: sürücünün gerçek şifreleme anahtarı olan Volume Master Key (VMK) ve bu VMK’yı açığa çıkarmak için kullanılan 48 haneli recovery password. Escrow edilen şey VMK değil, bu recovery password; VMK hiçbir zaman cihaz dışına çıkmıyor, sadece recovery password ile korunan protector’ları değişiyor.
Escrow’un encryption’dan önce mi sonra mı gerçekleştiği tek bir ayara bağlı: Intune’da BitLocker profilinde Store recovery information in Microsoft Entra ID before enabling BitLocker ayarı. Bu ayar Required yapıldığında, BitLocker CSP tarafında karşılığı olan SystemDrivesRecoveryOptions node’undaki “Do not enable BitLocker until recovery information is stored” bayrağı devreye giriyor ve Windows, recovery password Entra ID’ye (ya da AD DS’e) başarıyla yazılmadan encryption’ı başlatmıyor. Bu ayar Required değilse, escrow ile encryption arasında böyle bir bağımlılık yok; cihaz recovery password’ü sunucuya yazmayı dener ama bu yazma bitene kadar beklemez.
Pratikte bu, iki farklı riski birbirinden ayırıyor. Required ayarlıyken escrow başarısız olursa cihaz şifresiz kalır ama en azından key’siz bir cihaz oluşmaz. Required değilken escrow başarısız olursa cihaz encrypt olur, recovery password sadece cihazın kendi üzerinde durur; o cihaz kaybolduğunda ya da kullanıcı kilitlendiğinde helpdesk’in elinde hiçbir key olmaz.
Escrow Hangi Depoya, Hangi Formatta Gidiyor?
Microsoft Entra joined bir cihazda recovery password sadece Entra ID’ye yazılıyor. Hybrid joined bir cihazda hem Entra ID’ye hem AD DS’e yazılıyor; ikisi ayrı sistemler olduğu için biri başarılı olup diğeri başarısız olabilir, bu da encryption report’ta bazen kafa karıştıran karışık durumlara yol açabiliyor.
Entra ID tarafında key, Microsoft Graph’ta bitlockerRecoveryKey resource tipi olarak tutuluyor. Bu obje sadece id, createdDateTime, volumeType ve deviceId gibi metadata alanları döndürüyor; anahtarın kendisi (key alanı) varsayılan olarak dönmüyor, ayrıca sorgulanması gerekiyor. Bunun audit tarafındaki etkisine birazdan geliyorum.
AD DS tarafında ise recovery bilgisi cihazın bilgisayar objesinin altında ms-FVE-RecoveryInformation adlı bir child object olarak duruyor. Bu objenin ms-FVE-RecoveryPassword, ms-FVE-RecoveryGuid, ms-FVE-VolumeGuid gibi attribute’ları var; policy’de Backup recovery password and key package seçiliyse buna ek olarak ms-FVE-KeyPackage de yazılıyor. Key package, disk fiziksel olarak bozulduğunda BitLocker Repair Tool ile veri kurtarmak için kullanılan ayrı bir yapı ve Entra ID’de saklanamıyor; sadece AD DS’e veya bir dosyaya yazılabiliyor. Yani tamamen Entra joined, hybrid olmayan bir ortamda key package’a ihtiyacınız varsa Entra ID escrow bunu karşılamıyor, elle manage-bde -KeyPackage ile ayrıca almanız gerekiyor.
Bir başka fark: AD DS bir cihaz için üretilmiş tüm recovery password geçmişini tutuyor, eski key’ler bilgisayar objesi silinmeden otomatik temizlenmiyor. Entra ID tarafında ise cihaz başına saklanabilecek key sayısı 200 ile sınırlı; bu limite ulaşıldığında yeni escrow denemesi başarısız oluyor ve Required ayarlıysa encryption da bu yüzden başlamıyor. Sık reset edilen pilot veya test cihazlarında bu limite gerçekten ulaşılabiliyor.
Escrow Başarısız Olursa Ne Görüyoruz?
Encryption report’ta bir cihaz “Recovery key backup failed” ile takılı kaldığında ilk kontrol edilecek yer cihazın gerçekten Entra ID’ye bağlı olup olmadığı. Escrow bir ağ işlemi; cihaz OOBE sırasında henüz internet çıkışı almamışsa veya Entra join tamamlanmadan encryption tetiklenmeye çalışılıyorsa yazma denemesi başarısız oluyor.
Required ayarlıyken bu durumda encryption hiç başlamıyor, cihaz unencrypted kalıyor ve bir sonraki check-in’de tekrar deniyor. Required değilken ise encryption başlıyor ve escrow arka planda ayrı bir işlem olarak yeniden denenmeye devam ediyor; bu ara dönemde cihaz encrypt olmuş ama recovery password hiçbir yerde kayıtlı olmayabiliyor.
Key Rotation: Ne Zaman ve Neden Otomatik Tetikleniyor?
BitLocker CSP’de ConfigureRecoveryPasswordRotation node’u, bir recovery password kullanıldığında (self-service portaldan görüntülendiğinde veya helpdesk tarafından açıklandığında) cihazın otomatik olarak yeni bir recovery password üretip escrow etmesini kontrol ediyor. Intune’daki karşılığı BitLocker profilindeki Client-driven recovery password rotation ayarı. Bu node üç değer alıyor: 0 rotasyonu kapatıyor, 1 (varsayılan) sadece Microsoft Entra joined cihazlarda rotasyonu açıyor, 2 hem Entra joined hem hybrid joined cihazlarda açıyor.
Burada önemli bir bağımlılık var: bu rotasyon sadece Entra ID veya AD DS’e recovery password yazımı Required olarak ayarlandığında çalışıyor. Required ayarlı değilse rotasyon policy’si etkisiz kalıyor, çünkü Windows’un yeni üretilen key’i güvenle escrow edebileceğini garanti edemiyor. Bir diğer pratik nokta: bu ayarın Group Policy karşılığı yok, tamamen MDM/CSP üzerinden yönetiliyor; yani domain-joined ama Intune’a hiç bağlanmamış klasik AD ortamlarında bu otomatik rotasyonu GPO ile açamazsınız.
Varsayılan değer 1 olduğu için, Entra joined bir cihazda escrow Required ayarlıysa ve rotasyon ayarına özellikle dokunulmadıysa, bir kullanıcı kendi recovery key’ini Company Portal üzerinden görüntülediği anda cihaz arka planda yeni bir key üretip escrow ediyor; eski key artık geçerli bir protector değil. Bu davranış “birisi key’i gördü, artık tekrar kullanılabilir” riskini otomatik olarak kapatıyor, ayrı bir aksiyon almanıza gerek kalmıyor.
Manuel tarafta ise Intune’daki BitLocker key rotation device action’ı ile rotasyonu istediğiniz an tetikleyebiliyorsunuz; bu işlem RBAC tarafında Remote tasks altındaki Rotate BitLockerKeys hakkını gerektiriyor, Help Desk Operator ve Endpoint Security Manager built-in rollerinde bu hak zaten var. Aynı işlemi Graph üzerinden otomasyona bağlamak isterseniz rotateBitLockerKeys action’ı kullanılıyor, şu an beta endpoint altında.
Self-Service Recovery: Kullanıcı Kendi Key’ine Nasıl Ulaşıyor?
Kullanıcının recovery key almak için helpdesk aramasına gerek yok. Company Portal uygulaması, portal.manage.microsoft.com Company Portal web sitesi ve Microsoft Entra joined cihazlar için myaccount.microsoft.com üzerindeki Devices sekmesi bu erişimi sağlıyor. Company Portal web sitesinde key gösterildikten 5 dakika sonra ekrandan kayboluyor, tekrar görmek için yeniden istemeniz gerekiyor.
Bu erişimin arkasında iki ayrı yetkilendirme katmanı var. Birincisi Entra ID tarafındaki tenant-wide toggle: Restrict users from recovering the BitLocker key(s) for their owned devices. Varsayılan olarak kapalı, yani tüm kullanıcılar kendi cihazlarının key’ini görebiliyor; bunu Entra device settings üzerinden kısıtlayabilirsiniz. İkincisi Conditional Access: recovery key erişimi de kurumsal bir kaynak olarak ele alınıyor, “Require compliant device” gibi bir CA policy’si tanımlıysa noncompliant bir cihazdan bu key’e erişilemiyor.
Graph API üzerinden programatik erişimde yetkilendirme biraz daha katmanlı. BitlockerKey.ReadBasic.All izni sadece metadata’yı (id, oluşturulma tarihi, cihaz id’si) döndürüyor; anahtarın kendisini almak için BitlockerKey.Read.All gerekiyor. Delegated senaryoda çağıran kullanıcı ya cihazın kayıtlı sahibi olmalı ya da Cloud Device Administrator, Helpdesk Administrator, Intune Service Administrator, Security Administrator, Security Reader veya Global Reader rollerinden birine sahip olmalı. Bu liste, Intune admin center üzerinden key görüntülemek için gereken microsoft.directory/bitlockerKeys/key/read izninin bağlı olduğu rol listesinden (Cloud Device Administrator, Helpdesk Administrator, Global Administrator) biraz farklı; iki erişim yolunun ayrı yetkilendirme setleri olduğunu bilmek, “portalda göremiyorum ama Graph’ta erişimim var” gibi tutarsız görünen durumları açıklıyor.
Audit Log’da Gerçekte Ne Kaydediliyor?
Bir recovery key’e erişildiğinde bu Microsoft Entra audit log’una Key Management kategorisi altında Read BitLocker key aktivitesi olarak düşüyor; kayıtta erişen kullanıcının UPN’i ve key id bulunuyor. Intune admin center’dan Show Recovery Key tıklandığında da aynı kategoriye bir kayıt ekleniyor.
Graph API tarafında ilginç bir detay var: bitlockerRecoveryKey objesini $select=key olmadan sorgularsanız (yani sadece metadata istiyorsanız) bu bir audit kaydı oluşturmuyor. Audit kaydı, sorguya $select=key eklenip anahtarın kendisi gerçekten istendiğinde tetikleniyor. Bu ayrım şu anlama geliyor: bir script tüm cihazların key id’lerini listeliyorsa audit log’da iz bırakmaz, ama gerçek 48 haneli şifreyi çekiyorsa bırakır.
Import-Module Microsoft.Graph.Identity.SignIns
# Sadece metadata - audit kaydı olusturmaz
Get-MgInformationProtectionBitlockerRecoveryKey -BitlockerRecoveryKeyId $keyId
# Anahtarin kendisini de ceker - Entra audit log'una Read BitLocker key olarak duser
Get-MgInformationProtectionBitlockerRecoveryKey -BitlockerRecoveryKeyId $keyId -Property "key"Bir cihaz için tuttuğunuz recovery key sayısı zamanla artıyor: her rotasyon, her yeni encryption denemesi, her manuel reset yeni bir key üretiyor ve AD DS’te eskiler otomatik silinmiyor. Escrow’u Required yapmak, rotasyonu açık bırakmak ve audit log’u kim ne zaman hangi key’i gördü sorusuna cevap verecek şekilde takip etmek, recovery key’in sadece “cihaz kaybolursa lazım olur” değil, gerçek bir güvenlik kontrolü olarak çalışmasını sağlıyor.
