حل أزمة BitLocker — تحديث أبريل 2026

صباح 14 أبريل 2026 لن أنساه. تواصل معي زميلان من مكتبين مختلفين خلال نصف ساعة، كلاهما يسأل السؤال نفسه: لماذا فجأة عشرات الأجهزة تطلب مفتاح استرداد BitLocker؟ بصراحة، حين فتحت Entra ID لأول جهاز ولم أجد المفتاح أصلاً، شعرت بقشعريرة. هذا ليس بُعبع تقني، بل ثُغرة كانت موجودة منذ سنوات ولم نلاحظها.

السبب لم يكن هجوماً سيبرانياً، بل تحديثاً أمنياً اعتيادياً — KB5082063 على Windows Server 2025، وKB5083769 وKB5082052 على Windows 11 — كشف هشاشة في كيفية إدارة المؤسسات لـ BitLocker. وحين أقول "كثير من المؤسسات" فأنا أعني المؤسسات الكبيرة التي تظن أنها فعلت كل شيء صحيحاً.

هذا الدليل ليس مجرد توثيق للحادثة. هو خارطة طريق كاملة لمسؤولي الدعم الفني: إصلاح الأجهزة المتأثرة الآن، تحصين الأسطول قبل Patch Tuesday القادم، وفهم لماذا حصل ما حصل من جذره التقني (قياسات PCR7 وShahadat Secure Boot 2023). ستجد أوامر manage-bde الجاهزة، ونصوص PowerShell لإجبار رفع المفاتيح إلى Entra ID، وإعدادات Intune الصحيحة، وحلولاً لحالات طرفية مثل حدّ المئتي مفتاح وأقراص BitLocker To Go.

ما الذي حدث فعلاً في تحديث أبريل 2026؟

بدأت التقارير صباح 15 أبريل. أجهزة كثيرة تطلب مفتاح استرداد BitLocker بعد إعادة التشغيل التالية لتثبيت تحديث أبريل. الحوادث المؤكدة من Microsoft شملت:

Windows Server 2025 — تحديث KB5082063.
Windows 11 24H2 و25H2 — تحديث KB5083769.
Windows 11 23H2 — تحديث KB5082052.
كذلك أُبلِغ عن حالات في Windows 10 وWindows Server 2019 و2022 و23H2.

وهذه — انتبه — المرة الرابعة خلال أربع سنوات يتسبّب فيها Patch Tuesday بطلب غير متوقّع لمفاتيح BitLocker (الحالات السابقة كانت في أغسطس 2022، ويوليو 2024، ومايو 2025). نمط متكرّر يكشف أن المشكلة ليست في تحديث بعينه، بل في كيفية تكوين كثير من المؤسسات لسياسات BitLocker. إن لاحظت أن المشكلة تعود سنوياً، فالأرجح أن إعداد GPO لديك ليس على الإعدادات الافتراضية.

الجذر التقني: PCR7 وشهادة Secure Boot 2023

لفهم الحل لا بدّ من فهم الآلية. BitLocker لا يحرس القرص فقط، بل يحرس سلامة منصة الإقلاع. يقوم TPM (Trusted Platform Module، الرقاقة الصغيرة على اللوحة الأم) بقياس مراحل الإقلاع المختلفة ويخزّنها في سجلّات تُسمى Platform Configuration Registers (PCRs). إذا تغيّر أي قياس بطريقة غير متوقّعة، يفترض BitLocker أن المنصة قد جرى العبث بها ويطلب مفتاح الاسترداد.

السجل PCR7 هو المعني هنا. يقيس حالة Secure Boot والشهادات المستخدمة في توقيع Boot Manager. وفي تحديث أبريل 2026، أصبحت الأنظمة التي تملك شهادة Windows UEFI CA 2023 في قاعدة بيانات Secure Boot تستبدل تلقائياً Boot Manager بالنسخة الموقّعة بشهادة 2023. هذا التغيير يُعدّل قيمة PCR7. ومن وجهة نظر TPM، أي تغيير في PCR = ربما يكون هجوماً = اطلب المفتاح.

المشكلة تظهر فقط عند اجتماع خمسة شروط:

تفعيل BitLocker على قرص النظام.
سياسة Group Policy "Configure TPM platform validation profile for native UEFI firmware configurations" مُكوَّنة لتضمين PCR7 صراحةً.
أداة msinfo32 تُظهر أن Secure Boot State PCR7 Binding = Not Possible.
شهادة Windows UEFI CA 2023 موجودة في قاعدة Secure Boot DB.
الجهاز لا يستخدم بعد Boot Manager الموقّع بشهادة 2023.

Microsoft وصفت هذا التكوين بأنه "غير موصى به"، لكنه — للمفارقة — شائع جداً في المؤسسات التي شدّدت سياسات BitLocker دون الالتزام بالملف الافتراضي. وهنا تكمن المفارقة الحقيقية: المؤسسات الأكثر حرصاً على الأمن هي الأكثر تضرّراً. أنا شخصياً رأيت هذا في ثلاث بيئات مختلفة، وكلها كانت قد فعّلت PCR7 "احتياطاً" قبل سنوات.

كيف تعرف بسرعة إن كانت أجهزتك معرضة؟

قبل أن تطلق سياسة إصلاح على الأسطول، تحتاج إلى تشخيص دقيق. شغّل هذا الأمر على جهاز عيّنة:

msinfo32.exe

في نافذة System Information، ابحث عن السطر Secure Boot State وPCR7 Configuration. إذا ظهرت قيمة Binding Not Possible، فأنت على الأرجح ضمن النطاق المتأثر.

للتحقق برمجياً عبر PowerShell:

$msinfo = msinfo32 /report C:\temp\sysinfo.txt
Start-Sleep -Seconds 30
Select-String -Path "C:\temp\sysinfo.txt" -Pattern "PCR7 Configuration"

وللتحقق من سياسة Group Policy الفعلية على الجهاز:

gpresult /h C:\temp\gpresult.html
# افتح الملف وابحث عن:
# "Configure TPM platform validation profile for native UEFI firmware configurations"

إن وجدت السياسة مُفعَّلة وPCR7 ضمن قائمة التضمين، فأنت تحتاج إلى تطبيق الإصلاح أدناه. ولا تنتظر — كلّ يوم تأخير هو يوم آخر من المخاطرة.

الحلّ الفوري للأجهزة العالقة في شاشة الاسترداد

إذا كان لديك مستخدم يواجه الشاشة الآن (وأنا أعلم أن لديك واحداً منهم على الأقل)، اتبع هذه الخطوات:

الخطوة 1: استرجع مفتاح الاسترداد من Entra ID

افتح Microsoft Entra Admin Center < Devices < BitLocker keys، أو من Intune عبر:

Microsoft Intune admin center
> Devices
> Windows
> (اختر الجهاز)
> Recovery keys

إن لم تجد المفتاح هناك… حسناً، خذ نفساً عميقاً، وانظر قسم "استرداد المفاتيح المفقودة" أدناه قبل المتابعة.

الخطوة 2: أدخل المفتاح للمستخدم وأكمل الإقلاع

هذا حدث لمرة واحدة فقط. بعد دخول المفتاح، لن تتكرر الشاشة في عمليات إعادة التشغيل اللاحقة طالما لم تتغيّر سياسة GPO. لكن هذا لا يكفي — يجب إصلاح الربط حتى لا يتكرر مع التحديثات القادمة. وثق بي، التحديثات القادمة قادمة.

الخطوة 3: أعد ربط BitLocker بالملف الافتراضي

بعد دخول المستخدم إلى Windows، شغّل Command Prompt كمسؤول ونفّذ:

gpupdate /force
manage-bde -protectors -disable C: -rebootcount 0
manage-bde -protectors -enable C:

الأمر الثاني يُعطّل حماية BitLocker مؤقتاً، والثالث يعيد تفعيلها ويُجبر إعادة ربط ملف PCR على الإعدادات الافتراضية لـ Windows. تأكّد أن سياسة GPO قد عُدّلت أولاً (راجع القسم التالي)، وإلا فستعاود المشكلة الظهور — وستندم على عدم قراءة هذه الجملة.

الحلّ طويل الأمد عبر Group Policy

الإصلاح الجذري هو إزالة التكوين غير الموصى به. في Group Policy Management Editor، انتقل إلى:

Computer Configuration
 > Administrative Templates
   > Windows Components
     > BitLocker Drive Encryption
       > Operating System Drives
         > Configure TPM platform validation profile for native UEFI firmware configurations

غيّر الإعداد إلى Not Configured. لا تقم بتعطيله (Disabled) — هذه نقطة دقيقة كثيرون يخلطون فيها. اتركه غير مُكوَّن لتعود إلى ملف PCR الافتراضي الذي تحدّده Microsoft. ثم أعد تشغيل GP عبر gpupdate /force على الأجهزة، وأعد ربط BitLocker بالأمر السابق.

للمؤسسات التي تستخدم Intune بدلاً من GPO التقليدية، انتقل إلى:

Intune admin center
 > Endpoint security
   > Disk encryption
     > (سياسة BitLocker الخاصة بك)
       > Edit
         > ابحث عن "Configure TPM platform validation profile"
         > اضبطه على Not Configured

إذا لم تستطع تعديل السياسة فوراً: Known Issue Rollback (KIR)

في البيئات الكبيرة التي تتطلّب موافقات تغيير قبل تعديل GPO (والتي قد تستغرق أسابيع، نعم نعرف)، طرحت Microsoft KIR (Known Issue Rollback) كحلّ مؤقت. KIR يمنع التبديل التلقائي إلى Boot Manager الموقّع بشهادة 2023، فيُوقف ظهور شاشة الاسترداد.

للحصول عليه:

افتح Windows Release Health Dashboard.
ابحث عن إدخال هذه المشكلة وحمّل ملف KIR Group Policy MSI.
انشره عبر GPO على الأجهزة قبل تثبيت تحديث أبريل 2026 على دفعات جديدة.

تنبيه مهم: KIR حلّ تخفيفي وليس بديلاً عن إصلاح GPO. في الأشهر القادمة قد تُلزم Microsoft الجميع بشهادة UEFI CA 2023، وعندها سيتوقّف KIR عن العمل. باختصار: هو وقت إضافي، لا قرار نهائي.

ضمان رفع مفاتيح BitLocker إلى Entra ID — لماذا تختفي المفاتيح؟

الدرس الأكبر من حادثة أبريل 2026 ليس تقنياً بحتاً. كثير من المسؤولين فوجئوا أن جزءاً كبيراً من المفاتيح لم تكن موجودة في Entra ID أصلاً. وهذا هو الجزء المرعب فعلاً. السبب يعود إلى آلية عمل Intune BitLocker CSP:

يستدعي CSP عملية الرفع إلى Entra ID فقط عند تطبيق السياسة لأول مرة.
لا يرفع تلقائياً المفاتيح الموجودة مسبقاً ما لم يحدث rotation أو إعادة تشفير.
إخفاقات الرفع صامتة تماماً — لا يظهر خطأ على الجهاز، ولا إشعار للمستخدم، وقد يبقى الجهاز "متوافقاً" في تقرير Intune لأن السياسة تتحقّق من حالة التشفير لا من حالة رفع المفتاح.

النتيجة؟ لا تكتشف المؤسسة وجود ثغرة إلا في حادثة جماعية. الحلّ هو الرفع الاستباقي عبر PowerShell.

نصّ PowerShell لإجبار رفع المفتاح إلى Entra ID

هذا النص يأخذ مفتاح RecoveryPassword لقرص C: ويرفعه إلى Entra ID. آمن لإعادة التشغيل أكثر من مرة (idempotent بلغة المطورين):

$BLV = Get-BitLockerVolume -MountPoint "C:"
$KeyProtector = $BLV.KeyProtector | Where-Object {
    $_.KeyProtectorType -eq 'RecoveryPassword'
}

if ($null -eq $KeyProtector) {
    Write-Output "No RecoveryPassword protector found on C:"
    exit 1
}

foreach ($protector in $KeyProtector) {
    try {
        BackupToAAD-BitLockerKeyProtector `
            -MountPoint "C:" `
            -KeyProtectorId $protector.KeyProtectorId
        Write-Output "Backed up protector: $($protector.KeyProtectorId)"
    } catch {
        Write-Error "Failed to backup: $_"
    }
}

نشر النصّ عبر Intune

سجّل الدخول إلى Microsoft Intune admin center.
انتقل إلى Devices < Scripts and remediations (في القسم الجديد) أو Devices < Scripts في الواجهة الكلاسيكية.
أضف Windows PowerShell script باسم مثل Force-BitLocker-Backup-To-Entra.
ارفع ملف .ps1.
اضبط Run this script using the logged on credentials = No (يحتاج صلاحيات SYSTEM).
اضبط Enforce script signature check = No (إلا إذا وقّعت النصّ).
اضبط Run script in 64 bit PowerShell Host = Yes.
وزّعه على مجموعة أمان تحتوي الأجهزة المُدارة.

للتحقّق من نجاح الرفع، انتقل إلى Devices < Windows < Recovery keys أو افحص خاصية bitLockerRecoveryKey على كائن الجهاز في Entra ID.

اكتشاف الأجهزة المفتقدة للمفاتيح عبر Microsoft Graph

للمسؤولين الذين يريدون فحص الأسطول كله دون انتظار حادثة (وأنت يجب أن تكون منهم)، يمكن استخدام Microsoft Graph لاسترداد جميع مفاتيح BitLocker ومقارنتها بقائمة الأجهزة المدارة:

Connect-MgGraph -Scopes "BitLockerKey.Read.All", "DeviceManagementManagedDevices.Read.All"

$allKeys = Get-MgInformationProtectionBitlockerRecoveryKey -All
$keysByDevice = $allKeys | Group-Object -Property DeviceId

$managedDevices = Get-MgDeviceManagementManagedDevice -All -Filter "operatingSystem eq 'Windows'"

$missingKeys = $managedDevices | Where-Object {
    $_.AzureAdDeviceId -notin $keysByDevice.Name
}

$missingKeys | Select-Object DeviceName, UserPrincipalName, LastSyncDateTime |
    Export-Csv -Path "C:\Reports\Missing-BitLocker-Keys.csv" -NoTypeInformation

Write-Output "Found $($missingKeys.Count) devices without BitLocker keys in Entra ID"

شغّل هذا السكربت أسبوعياً ضمن مهمّة مجدولة، واستهدف الأجهزة المُكتشفة بنصّ الرفع السابق. شخصياً، أُشغّله كل اثنين قبل القهوة الأولى — وأنام أهنأ.

إعدادات Intune الصحيحة لمنع تكرار المشكلة

في ملف Disk Encryption في Endpoint Security، احرص على ضبط:

الإعداد	القيمة الصحيحة	السبب
Save BitLocker recovery information to Azure AD	Yes	يفعّل آلية الرفع التلقائي.
Store recovery information in Azure AD before enabling BitLocker	Block	يمنع تشفير القرص إن فشل رفع المفتاح أولاً.
Configure TPM platform validation profile	Not Configured	يتجنّب مشكلة PCR7 المُسبّبة لحادثة أبريل 2026.
Choose how BitLocker-protected OS drives can be recovered	Enabled مع Recovery Password	يضمن وجود RecoveryPassword كحماية افتراضية.

الإعداد الثاني تحديداً (Block) هو خط الدفاع الأهم. مع تفعيله، لن يكتمل تشفير أي قرص جديد قبل ضمان وصول المفتاح إلى Entra ID. لو طُبّق هذا الإعداد في كل المؤسسات قبل أبريل 2026، لكانت حادثة الشهر الماضي مجرد إزعاج بسيط لا أزمة كاملة.

استرداد المفاتيح المفقودة من الأجهزة المُتأثرة

إذا اكتشفت أثناء الحادثة أن جهازاً ليس له مفتاح في Entra ID، لديك ثلاثة مسارات حسب حالة الجهاز:

1. الجهاز ما زال داخل Windows (لم يصل لشاشة الاسترداد بعد)

هذه أفضل حالة بفارق كبير. شغّل النصّ السابق فوراً، ثم تأكّد من ظهور المفتاح في Entra ID قبل أي إعادة تشغيل.

2. الجهاز عالق في شاشة الاسترداد ولديك حسابات ConfigMgr/SCCM

إن كان الجهاز مُسجّلاً في SCCM/MECM، فالمفتاح غالباً مخزّن في قاعدة بيانات MBAM. استخرجه من بوابة الاسترداد:

https://<mbam-helpdesk-server>/HelpDesk

أو عبر استعلام T-SQL مباشر على قاعدة MBAM Recovery and Hardware:

SELECT RecoveryKeyId, RecoveryKey, LastUpdateTime
FROM RecoveryAndHardwareCore.Keys_Recovery
WHERE Volume_Id IN (
    SELECT Volume_Id FROM RecoveryAndHardwareCore.Volumes
    WHERE Machine_Id IN (
        SELECT Id FROM RecoveryAndHardwareCore.Machines
        WHERE Name = 'COMPUTER-NAME'
    )
)

3. الجهاز عالق ولا توجد نسخة احتياطية في أي مكان

هنا الحالة الكارثية. الخيار الوحيد هو إعادة تثبيت Windows مع حذف القسم المشفّر — مما يعني فقدان كامل لبيانات القرص. هذا السيناريو هو سبب وجوب تطبيق إصلاحات الرفع الاستباقي قبل أي Patch Tuesday قادم. واسأل المستخدم: هل لديك نسخة احتياطية على OneDrive؟ أحياناً نجد ضوءاً صغيراً في آخر النفق.

حالات طرفية يجب الانتباه لها

حدّ المئتي مفتاح لكل جهاز في Entra ID

Entra ID يدعم حدّاً أقصى قدره 200 مفتاح استرداد لكل جهاز. عند الوصول إلى هذا الحدّ، يفشل رفع أي مفاتيح جديدة. هذا قد يحدث في الأجهزة التي تمرّ بكثير من عمليات rotation أو إعادة تشفير. الحلّ هو سياسة تنظيف دورية تحذف المفاتيح القديمة.

التحديثات الأخيرة من Microsoft تتعرّف على هذا الحدّ وتحذف تلقائياً أقدم المفاتيح للسماح بالتشفير الصامت، لكن لا تعتمد على ذلك في الإصدارات الأقدم.

BitLocker To Go (الأقراص القابلة للإزالة)

الرفع التلقائي إلى Entra ID يغطّي فقط أقراص النظام والبيانات الثابتة. أقراص USB المُشفَّرة بـ BitLocker To Go لا تملك آلية رفع رسمية مدمجة. الحلّ هو نصّ PowerShell مجدول يفحص أحرف الأقراص ويستدعي:

BackupToAAD-BitLockerKeyProtector `
    -MountPoint "E:" `
    -KeyProtectorId $protectorId

هذا الحلّ غير رسمي ولا يدعمه Intune كآلية فرض، لكنه يعمل عملياً ويُنصح به في المؤسسات التي تعتمد على أقراص USB حسّاسة.

أجهزة Azure Virtual Desktop وAVD Multi-session

في AVD، BitLocker لا يُطبَّق على القرص الافتراضي للجلسة بل على القرص المُضيف. إذا كانت لديك سياسة Intune تستهدف AVD، تجنّب تطبيق سياسات تشفير القرص — قد تتسبّب في فشل بدء الجلسة. وقعت في هذا الفخ مرة، واستغرقت الجلسة المعطّلة ساعتين من التشخيص لاكتشاف السبب.

قائمة فحص قبل Patch Tuesday القادم

اطبع هذه القائمة وعلّقها بجانب شاشة المسؤول (نعم، اطبعها فعلاً):

تأكّد من ضبط Configure TPM platform validation profile = Not Configured.
شغّل تقرير Graph للكشف عن الأجهزة بلا مفاتيح في Entra ID.
طبّق نصّ الرفع الإجباري على الأجهزة المفتقدة.
تحقّق من أن سياسة Intune تضمّن Store recovery information in AAD before enabling BitLocker = Block.
اختبر التحديث على حلقة ring 0 صغيرة (5–10 أجهزة) قبل النشر العام.
راجع Windows Release Health Dashboard لإصدار KIR إن وُجد.
أبلغ مكتب الخدمة بمواقع المفاتيح الاحتياطية واطلب فتح ساعات تشغيل إضافية يوم النشر.

الأسئلة الشائعة

هل ستظهر شاشة استرداد BitLocker مرة أخرى بعد إدخال المفتاح؟

لا، حدث طلب مفتاح الاسترداد لمرة واحدة فقط بعد تحديث أبريل 2026، طالما لم تتغيّر سياسة Group Policy. لكن إن لم تُعدّل السياسة، فالمشكلة قد تتكرر مع أي تحديث مستقبلي يؤثّر على PCR7.

ماذا لو فقدت مفتاح BitLocker ولم يكن مرفوعاً إلى Entra ID؟

إن كان لديك بيئة hybrid مع MBAM/SCCM، تحقّق من قاعدة بياناتها أولاً. إن كان الجهاز محمياً بـ Active Directory التقليدية، استخدم Get-ADComputer -Filter * -Properties msFVE-RecoveryPassword. إن لم يوجد المفتاح في أيّ مكان… فالخيار الوحيد هو مسح القرص وإعادة التثبيت مع فقدان البيانات. نعم، مؤلم.

هل التحديث آمن للتثبيت الآن (مايو 2026)؟

نعم، أصدرت Microsoft إصلاحات لـ Windows 11 خلال مايو 2026، لكن إصلاح Windows 10 وWindows Server لا يزال يتطلّب تعديل سياسة GPO يدوياً. تأكّد من تطبيق إصلاح GPO قبل تثبيت تحديث أبريل على أي جهاز جديد.

ما الفرق بين BackupToAAD-BitLockerKeyProtector وManage-bde؟

BackupToAAD-BitLockerKeyProtector هي cmdlet PowerShell ترفع مفتاح RecoveryPassword إلى Entra ID فقط. manage-bde -protectors -aadbackup هي أداة سطر أوامر تقليدية تؤدي الدور نفسه، لكنها أقدم وأقلّ مرونة. أنصح باستخدام cmdlet الحديثة في النصوص الجديدة.

هل أحتاج إلى ترخيص خاصّ لتخزين مفاتيح BitLocker في Entra ID؟

لا، تخزين مفاتيح BitLocker في Entra ID مجاني ومتاح لجميع المستأجرين. ميزات إضافية مثل Self-Service Recovery للمستخدمين عبر بوابة myaccount.microsoft.com تتطلّب أن يكون الجهاز مسجّلاً في Entra ID Joined أو Hybrid Joined.

كيف أتعامل مع الأجهزة المُدارة بـ Co-management (Intune + SCCM)؟

في Co-management، يجب أن تكون مسؤولية BitLocker Encryption مُحوّلة إلى Intune (Sliders < Endpoint Protection = Intune). إن بقيت في SCCM، فلن يقوم Intune CSP بفرض رفع المفاتيح إلى Entra ID وستظلّ المفاتيح في قاعدة MBAM فقط — وهذا بالضبط ما لا تريده.