BitLocker בפועל — מתחילים מניהול recovery key

“אתחלתי את המחשב, ובאתחול הבא הופיע מסך כחול שמעולם לא ראיתי, שביקש מפתח בן 48 ספרות.” “רק עדכנתי את ה-BIOS, והגענו ישר למסך recovery key — אף אחד לא מסר לי מפתח כזה.” “הסתכלתי בהגדרות של מחשב חדש ומצאתי ש-Device Encryption נדלקה מעצמה. נראה שזה יאט את היישומים העסקיים, אז אפשר פשוט לכבות?” — בערך בשנה האחרונה, פניות מהסוג הזה מלקוחות עלו באופן בולט.

הרקע ברור. מ-Windows 11 גרסה 24H2 ואילך, מחשב בהתקנה נקייה מריץ Device Encryption (הפעלה אוטומטית של BitLocker) כברירת מחדל. גם דרישות החומרה הוקלו, ולכן מאגר המחשבים הזכאים התרחב משמעותית. כלומר BitLocker כבר אינו דבר שארגונים גדולים מגלגלים במודע — הוא הפך לדבר שנכנס בשקט גם למחשבים של עסקים קטנים ובינוניים. במצב הזה, רשת הביטחון היחידה היא ה-recovery key, והמצב המסוכן ביותר הוא כשההצפנה מתקדמת בזמן שהמפתח הזה אינו תחת ניהול של אף אחד.

המאמר הזה מיועד לאנשי IT ולמנהלים בעסקים קטנים ובינוניים, ולמפתחים שאחראים ליישומים עסקיים ולמחשבי ציוד, ומסדר את BitLocker לא כמשהו לכבות אלא כמשהו להשתמש בו נכון. על בסיס מקורות ראשוניים כמו Microsoft Learn נכון לאוגוסט 2026, הוא מכסה את ההבדלים בין מהדורות, את המינימום של הקשר בין TPM למפתחות, טבלת החלטה לאן לשמור את ה-recovery key, הפעלה ותפעול בארגון, טיפול בתקריות, והקשר לגריטה.

1. קודם המסקנות

• BitLocker הוא תכונת Windows שמצפינה כונן שלם, ומונעת דליפת נתונים מאובדן, גניבה או גריטה לא נאותה. גם מול התקפה שבה שולפים את הדיסק ומחברים אותו למחשב אחר, כל עוד הוא מוצפן אי אפשר לקרוא את הנתונים.¹
• BitLocker במלואו ניתן להפעיל רק ב-Pro, Enterprise, Pro Education ו-Education. המקבילה הפשוטה, Device Encryption, זמינה בכל המהדורות כולל Home.¹
• מ-Windows 11 24H2 ואילך, דרישות Device Encryption האוטומטית הוקלו. דרישת HSTI/Modern Standby ודרישת “אין ממשקי DMA לא מורשים” הוסרו, ולכן אחרי השלמת OOBE (ההגדרה הראשונית) בהתקנה נקייה, ההצפנה מאותחלת כברירת מחדל במחשבים רבים שעומדים ב-TPM + UEFI Secure Boot.²
• “התחלת” ההצפנה ו”הפעלת” ההגנה הם דברים שונים. ההגנה אינה מופעלת (armed) עד שה-recovery key מגובה בהצלחה לחשבון Microsoft, ל-Entra ID, או (כשמדיניות השחזור הוגדרה) ל-AD DS. מחשב שמשתמש רק בחשבון מקומי, בלי יעד גיבוי, נשאר לא מוגן גם כשהוא מוצפן.¹²
• יש בפועל ארבעה מקומות לשמור את ה-recovery key (recovery password בן 48 ספרות): Entra ID, AD DS, חשבון Microsoft, או עותק מודפס/קובץ. הזרימה כברירת מחדל: Entra ID אם המכשיר מצורף ל-Entra ID, AD DS אם הוא מצורף לדומיין AD, ואחרת חשבון Microsoft של המנהל.¹³
• בקשה ל-recovery key אינה רק סימן לחריגה. עדכון firmware, שינוי בהגדרת Secure Boot, ניקוי ה-TPM, החלפת motherboard, העברת הכונן למכונה אחרת — כל שינוי בסביבת האתחול יכול להפעיל את זה. הנוהל הקבוע לפני עבודה מתוכננת הוא להשעות קודם את ההגנה.³
• שיטת ההצפנה כברירת מחדל היא XTS-AES 128-bit. שינוי השיטה אחר כך דורש פענוח ואז הצפנה מחדש, ולכן משתלם לקבע אותה מההתחלה. לכונן חדש לגמרי, Used Space Only מקצר מאוד את זמן ההצפנה הראשוני.⁴⁵
• אם מחשב מבקש את ה-recovery key ואי אפשר להציג אותו, הנתונים אבודים. גם התמיכה של Microsoft אינה יכולה לשלוף מפתח שאבד. לכן בדיוק נושא המאמר אינו “האם להצפין” אלא “לאן לשמור את ה-recovery key ומי יכול לשלוף אותו”.⁶

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 48, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. BitLocker מול Device Encryption — מה זמין לפי מהדורה

קודם מסדרים את המונחים. BitLocker ו-Device Encryption הם שני פנים של אותה טכנולוגיית הצפנה.

• BitLocker (המלא): מפעילים לפי כונן, כולל שיטות authentication כמו TPM+PIN ו-startup key, שליטה ב-Group Policy / Intune, וניהול ב-manage-bde.exe וב-PowerShell — הצורה שמיועדת למנהלים.
• Device Encryption: מנגנון שמפעיל BitLocker אוטומטית במחשבים שעומדים בדרישות. בהגדרות מופיע מתג Device Encryption, והוא מצפין רק את כונן ה-OS וכוננים פנימיים קבועים (כוננים חיצוניים / USB מחוץ להיקף).¹

התמיכה לפי מהדורה:¹

מה השתנה ב-Windows 11 24H2

Device Encryption אוטומטית הייתה קיימת גם קודם, אבל היעד היה בעיקר מחשבים ניידים חדשים יחסית שעמדו ב-“Modern Standby או HSTI” ו-“אין פורט עם DMA חיצוני”. ב-Windows 11 גרסה 24H2 שתי הדרישות האלה הוסרו, והתנאים העיקריים שנותרו הם “TPM (1.2 או 2.0)” ו-“UEFI Secure Boot פעיל”. גם הרישום של OEM ב-registry (AllowedBuses) לאוטובוסי DMA לא מורשים כבר לא נחוץ; המפתח עצמו מתעלמים ממנו מ-24H2 ואילך. ההקלה הזו לא חלה על מהדורות Windows IoT.²

התוצאה: אחרי שמסיימים OOBE בהתקנה נקייה (כולל איפוס והתקנה מחדש), גם desktop רגיל מאתחל הצפנה כברירת מחדל. כאן חשוב להבחין בין “אתחול” לבין “הפעלת הגנה”.

• בשלב סיום OOBE, הכונן מוצפן ב-clear key (מפתח זמני בלי הגנה). ב-Explorer מופיע אייקון אזהרה.¹
• sign-in עם חשבון Microsoft או Entra ID, או במחשב domain-joined גיבוי ל-AD DS (כשמדיניות השחזור הוגדרה) מצליח — ואז נוצר TPM protector וה-clear key מוסר. רק כאן ההגנה באמת נדלקת (armed).¹²
• מחשב שעובד רק עם חשבון מקומי נשאר מוצפן בלי הגנה.¹

הזרימה בתרשים:

flowchart TB
    A["התקנה נקייה / איפוס<br/>(Windows 11 24H2 ואילך)"] --> B{"עומד בדרישות<br/>TPM + UEFI Secure Boot וכו'?"}
    B -- "לא" --> Z["לא מוצפן"]
    B -- "כן" --> C["בסיום OOBE מאתחלים הצפנה<br/>(clear key = מפתח זמני בלי הגנה)"]
    C --> D{"לאן מגבים את<br/>ה-recovery key?"}
    D -- "חשבון Microsoft / Entra ID /<br/>AD DS (מדיניות שחזור הוגדרה)" --> E["גיבוי recovery key הצליח"]
    E --> F["יוצרים TPM protector ומסירים clear key<br/>= ההגנה נדלקת (armed)"]
    D -- "חשבון מקומי בלבד<br/>(אין יעד גיבוי)" --> G["מוצפן, אבל ההגנה כבויה<br/>(מופיע אייקון אזהרה)"]

זה מה שעומד מאחורי “פתאום גילינו שזה מוצפן”. ארגונים שמחליפים מחשבים ל-Windows 11 בגלל סיום התמיכה ב-Windows 10 (החלטה אחרי Windows 10 EOL) צריכים להניח שמחשבים חדשים מגיעים במצב הזה, ולהכניס ניהול recovery key ל-kitting.

את מצב התמיכה במחשב שלכם בודקים ב-System Information (msinfo32.exe) כ-Administrator, בשורה Device Encryption Support. “Meets prerequisites” אומר שהמחשב ביעד.¹

3. המינימום של המנגנון — TPM והמפתחות

מי שמגן על מפתחות BitLocker הוא TPM (Trusted Platform Module). TPM בודק בזמן שה-OS כבוי שהמכשיר לא שונה, ומשחרר את מפתח ההצפנה רק כשאימות האתחול עובר. לכן אפשר להשתמש במחשב בלי להזין כלום כש-Windows עולה כרגיל, ובאותו זמן דיסק שנשלף לבד לא קריא.¹ את המנגנון עצמו של TPM (מבנה שלא מוציא מפתחות, PCR, Measured Boot) פירטנו ב”מהו TPM ב-Windows”.

מה קורה בכל אתחול:

flowchart TB
    ON["הדלקת חשמל"] --> M["TPM מודד את סביבת האתחול<br/>(firmware, boot configuration וכו')"]
    M --> Q{"המדידה זהה<br/>לרגיל?"}
    Q -- "כן" --> UN["TPM משחרר את מפתח ההצפנה"]
    UN --> BOOT["אתחול רגיל<br/>(המשתמש לא מזין כלום)"]
    Q -- "לא" --> REC["recovery mode<br/>דורש recovery key בן 48 ספרות"]
    REC --> K1["אם מזינים recovery key — האתחול ממשיך"]
    REC --> K2["אם אי אפשר להזין —<br/>אי אפשר לשלוף את הנתונים"]

אפשר גם להוסיף ל-TPM PIN באתחול, או startup key (קובץ מפתח ב-USB) כ-MFA. גם במחשב בלי TPM אפשר להצפין את כונן ה-OS בשיטת startup key, אבל שיטת סיסמה חלשה ל-brute force כי אין lockout, ולכן היא כבויה כברירת מחדל.¹

מתי מבקשים recovery key

TPM בודק אם סביבת האתחול זהה לרגיל, ולכן כשהסביבה משתנה גם הבעלים הלגיטימי נכנס ל-recovery mode. הטריגרים ש-Microsoft מונה:³

• עדכון רכיבי אתחול מוקדמים, כמו עדכון BIOS/UEFI firmware
• כיבוי, השבתה או ניקוי של TPM, או כשל self-test של TPM
• שינוי ב-PCR (Platform Configuration Registers) שפרופיל האימות של TPM משתמש בהם — שינוי הגדרת Secure Boot נכנס לכאן
• החלפת motherboard (החלפה ל-TPM חדש)
• העברת כונן מוגן BitLocker למחשב אחר
• חיבור/ניתוק docking station, שינוי בטבלת מחיצות NTFS, שינוי boot manager, PXE boot
• הזנת PIN שגויה חוזרת, או (בדגמי TPM 1.2) שינוי סדר התקני האתחול

כלומר “ביקשו recovery key אחרי עדכון BIOS” אינו תקלה ואינו התקפה — זו התנהגות לפי התכנון. לפני עבודה מתוכננת (עדכון firmware או החלפת חומרה) משעים את ההגנה (suspend). גם בהשעיה הכונן נשאר מוצפן, ואחרי העבודה אפשר להמשיך בלי להזין recovery key. כברירת מחדל ההגנה מתחדשת אוטומטית אחרי restart (אפשר גם לציין מספר restart-ים).³

# משעים לפני עדכון firmware. כברירת מחדל ההגנה מתחדשת אחרי restart אחד,
# ולכן עדכון שמאתחל כמה פעמים עלול לעצור במסך שחזור מהפעם השנייה.
# -RebootCount 0 עוצר חידוש אוטומטי, ומכניסים Resume לשלב אחרי העבודה
Suspend-BitLocker -MountPoint C: -RebootCount 0
# אחרי העבודה חייבים לחדש (עם -RebootCount 0 אין חידוש אוטומטי, אז הפקודה הזו חובה)
Resume-BitLocker -MountPoint C:

לגבי המונחים: במסמכים טכניים מבחינים בין recovery password בן 48 ספרות לבין recovery key כקובץ .bek ב-USB,³ אבל במסכים לקהל הרחב ובמאמר הזה נקרא ל-48 הספרות recovery key, כפי שרוב האנשים אומרים.

4. טבלת החלטה ל-recovery key — איך בוחרים מבין ארבעה יעדים

זה לב המאמר. יעד השמירה של recovery key הוא בפועל ארבעה אפשרויות, וצורת ה-sign-in של המחשב כמעט קובעת אותו אוטומטית. קודם טבלת ההחלטה.

במכשיר hybrid-joined (גם AD וגם Entra ID) ה-recovery password מגובה לשניהם.⁴

שלוש נקודות לארגון:

1. קובעים יעד ארגוני אחד. אם Entra ID מתקדם — Entra ID; אם AD מקומי — AD DS. recovery key של מחשב חברה שיושב בחשבון Microsoft אישי של העובד קורס מיד בפרישה או במעבר תפקיד.
2. לא מניחים ש-AD DS “נכנס לבד”. גיבוי ל-AD DS דורש הגדרת מדיניות (בהמשך). בנוסף, Active Directory שומר היסטוריה של recovery passwords, ומפתחות ישנים לא נמחקים אוטומטית כל עוד לא מוחקים את אובייקט המחשב.³
3. אם בוחרים שמירה לקובץ, מחמירים במקום. קובץ recovery key חייב להישמר במקום שאינו המחשב עצמו (תיקיית רשת וכו’).⁵ מי שמחזיק recovery key יכול לגשת לכל הנתונים בכונן, לכן חובה להפריד את האחסון מהמחשב המוגן ולשלוט בגישה.³

איך בודקים מה המצב במחשב שלכם

מריצים באחד מאלה בטרמינל עם הרשאות Administrator:⁵

# PowerShell: מצב הצפנה וסוג ה-protectors
Get-BitLockerVolume C: | Format-List
# recovery password (48 ספרות) וה-ID שלו
(Get-BitLockerVolume -MountPoint C).KeyProtector

:: Command Prompt: בדיקת מצב
manage-bde -status
:: רשימת protectors (TPM, recovery password וכו') והערך בן 48 הספרות
manage-bde -protectors -get C:

מה שמופיע ב-manage-bde -protectors -get C: כ-Numerical Password הוא ה-recovery key בן 48 הספרות, ו-8 הספרות הראשונות של ה-ID שמוצג איתו הן הרמז במסך השחזור לאיזה מפתח מדובר.⁶

אפשר גם לגבות אחר כך recovery password של מחשב שכבר מוצפן ל-Entra ID או ל-AD DS.⁵

# אחרי שמאשרים את ה-ID של ה-recovery password
# גיבוי ל-Entra ID
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId "{ID}"
# גיבוי ל-AD DS
Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId "{ID}"

:: עם manage-bde
manage-bde -protectors -aadbackup C: -id {ID}
manage-bde -protectors -adbackup C: -id {ID}

מלאי של “האם ה-recovery key של כל מחשב נמצא ביעד הארגוני” הוא כמו אמצעי אבטחת המידע הבסיסיים בהנחיות IPA לעסקים קטנים: לא פעם אחת ונגמר, אלא עבודה על גבי פנקס (מאיפה עסקים קטנים ובינוניים מתחילים באבטחה).

5. הפעלה ותפעול בארגון — מדיניות, פקודות ושיטת הצפנה

5.1. אוסרים במדיניות הפעלה בלי recovery key

אפשר להגדיר BitLocker גם מ-Group Policy (GPO) וגם מ-MDM (BitLocker CSP של Intune וכו’).⁴ המדיניות החשובה ביותר לניהול recovery key היא “Choose how BitLocker-protected operating system drives can be recovered”. כאן מגדירים:⁴³

• שמירת פרטי שחזור ב-AD DS (רק recovery password, או גם key package)
• הפעלת “Do not enable BitLocker until recovery information is stored in AD DS” — לא מתחילים הצפנה עד שהגיבוי מצליח. זה עמוד התווך למניעת תאונות. בתצורה הזו recovery password נוצר אוטומטית

גם במכשירי Entra ID שמנוהלים ב-Intune הרעיון זהה: מחייבים גיבוי recovery key ואז מפעילים הצפנה. recovery keys ב-Entra ID ניתנים לשליפה מ-Entra admin center, Intune admin center, PowerShell ו-Microsoft Graph, ואפשר גם להאציל ל-helpdesk.³

5.2. שיטת הצפנה — ברירת המחדל היא XTS-AES 128

אם לא מגדירים שיטה, BitLocker משתמש ב-XTS-AES 128-bit. גם Device Encryption כברירת מחדל היא XTS-AES 128. במדיניות “Choose drive encryption method and cipher strength” אפשר לשנות ל-XTS-AES 256 וכו’, אבל ההמלצה של Microsoft היא XTS-AES בכל הכוננים, ולבחור 128/256 לפי ביצועי המכשיר (ולפי דרישות רגולציה בענף).⁴¹

שימו לב: אי אפשר לשנות אחר כך את השיטה של כונן שכבר מוצפן. שינוי שיטה או אורך מפתח דורש פענוח ואז הצפנה מחדש.¹ אם יש דרישת רגולציה ל-256-bit, מקבעים את זה בהפצה הראשונה.

5.3. Used Space Only מול הצפנת הכונן כולו

בהפעלה בוחרים גם טווח הצפנה. ההנחיה של Microsoft ברורה:⁵

• Used Space Only: לכונן חדש שמעולם לא החזיק נתונים. ההצפנה הראשונית מהירה
• הצפנת הכונן כולו: לכונן שכבר היה בשימוש — כונן שהחזיקו בו נתונים, כולל קבצים שנמחקו שעדיין יכולים להישאר

הסיבה: אזור של קבצים שנמחקו נראה ל-file system כשטח פנוי, ולכן Used Space Only לא מצפין אותו, ואפשר לשחזר אותו בכלים forensic עד שהוא נדרס.⁵ בפועל: מחשב חדש אחרי kitting —‏ Used Space Only; מחשב משומש שמפעילים עליו אחר כך — הצפנה מלאה.

5.4. הפעלה ב-PowerShell

הצורה הבסיסית לפריסת סקריפט:⁵

# 1. קודם מוסיפים protector מסוג recovery password (48 ספרות). בשלב הזה ההצפנה עוד לא מתחילה.
#    כדי לזהות רק את ה-ID שהוספנו עכשיו גם אם נשארו כמה recovery passwords מניסיונות קודמים,
#    לוקחים את ההפרש בין ה-IDs לפני ואחרי
$before = (Get-BitLockerVolume -MountPoint C).KeyProtector.KeyProtectorId
Add-BitLockerKeyProtector -MountPoint C: -RecoveryPasswordProtector | Out-Null
$rpId = (Get-BitLockerVolume -MountPoint C).KeyProtector |
    Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' -and $_.KeyProtectorId -notin $before } |
    Select-Object -ExpandProperty KeyProtectorId

# 2. מגבים את ה-recovery password שהוספנו ליעד הארגוני. אם זה נכשל אסור להמשיך להצפנה,
#    לכן -ErrorAction Stop עוצר את העיבוד בשגיאה
#    (השלב כולל אישור שהמפתח נראה ב-Entra admin center / AD)
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $rpId -ErrorAction Stop
# ל-AD DS: Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $rpId -ErrorAction Stop

# 3. רק אחרי שהגיבוי הצליח מתחילים הצפנה. 3a ו-3b הם בלעדיים —
#    מריצים רק אחד מהם (גם השיטה והטווח נקבעים כאן)

# 3a. תצורה רגילה: TPM בלבד (מסופים שצריכים restart בלי אדם)
Enable-BitLocker C: -EncryptionMethod XtsAes256 -UsedSpaceOnly -TpmProtector

# 3b. תצורת TPM+PIN (מסוף נייח ברמת אבטחה גבוהה). במקום 3a.
#     מזינים PIN שונה לכל מסוף במקום. הטמעה ב-plaintext בסקריפט נותנת
#     אותו PIN לכל המסופים, והסקריפט עצמו הופך לנקודת דליפה
$Pin = Read-Host -AsSecureString -Prompt "PIN של המסוף הזה"
Enable-BitLocker C: -EncryptionMethod XtsAes256 -UsedSpaceOnly -Pin $Pin -TPMandPinProtector

הסדר “קודם מפקידים recovery password, ורק אז מתחילים הצפנה” הוא החשוב. אם מתחילים מ-Enable-BitLocker -TpmProtector, עצירה באמצע משאירה מחשב עם הגנת TPM בלי עותק של אמצעי שחזור, והעדכון הבא של firmware או שינוי חומרה עלול לאבד את הנתונים כולם. בסדר למעלה, גם אם עוצרים באמצע ההצפנה עוד לא התחילה, ומספיק לנסות שוב. בפריסה ארגונית, אם מפעילים קודם את מדיניות 5.1 “לא להפעיל BitLocker עד שפרטי השחזור נשמרים”, גם המדיניות עצמה חוסמת את המצב החצי-גמור הזה. הכלל בפריסה ארגונית: לא מתחילים הצפנה לפני שאישרתם שהגיבוי הצליח.

6. טיפול בתקריות — “ביקשו recovery key” / “לא מוצאים”

6.1. במסך השחזור, קודם 8 הספרות הראשונות של ה-key ID

במסך השחזור הכחול מוצג recovery key ID. גם אם יש כמה עותקים, התאמה של 8 הספרות הראשונות של ה-ID מזהה את המפתח הנכון.⁶ מחפשים לפי טבלת פרק 4, בסדר הזה.

1. היעד הארגוני (Entra admin center / Intune, או AD DS) — דרך מנהל / helpdesk
2. החשבון של המשתמש עצמו — חשבון עבודה ב-aka.ms/aadrecoverykey, חשבון Microsoft אישי ב-aka.ms/myrecoverykey⁶
3. עותק מההפעלה — נייר מודפס, קובץ ב-USB, קובץ טקסט שנשמר⁶

flowchart TB
    REC["מסך שחזור כחול<br/>מוצג recovery key ID"] --> ID["רושמים את 8 הספרות הראשונות של ה-ID"]
    ID --> ORG["1. היעד הארגוני<br/>(Entra admin center / Intune / AD DS)"]
    ORG -- "יש מפתח עם ID תואם" --> INPUT["מזינים 48 ספרות והאתחול ממשיך"]
    ORG -- "לא נמצא" --> SELF["2. החשבון של המשתמש<br/>aka.ms/aadrecoverykey / aka.ms/myrecoverykey"]
    SELF -- "יש מפתח תואם" --> INPUT
    SELF -- "לא נמצא" --> PAPER["3. עותק מההפעלה<br/>(נייר / USB / קובץ)"]
    PAPER -- "יש מפתח תואם" --> INPUT
    PAPER -- "לא נמצא" --> LOST["לא נשאר אלא איפוס (כל הנתונים אבודים)<br/>גם Microsoft לא יכולה לשלוף"]
    INPUT --> AFTER["בודקים את הסיבה, מבטלים את ה-recovery key<br/>ששומש ומנפיקים מחדש (סעיף 6.3)"]

במקביל, הופכים להרגל לבדוק למה נכנסתם ל-recovery mode. אם אתמול עדכנתם BIOS או נגעתם ב-Secure Boot, זו התנהגות לפי התכנון. אם זה חוזר בלי סיבה ברורה, שווה לבדוק גם תקלת חומרה וגם אפשרות של שינוי עם גישה פיזית.³

6.2. אם בכל זאת לא מוצאים

המסקנה קשה, אבל בלי recovery key אין דרך לשלוף את הנתונים מהכונן המוצפן. במחשב בניהול הארגון, בדיקה מול צוות ה-IT היא קו ההגנה האחרון; אחרת לא נשאר אלא איפוס המכשיר (כל הנתונים אבודים). התמיכה של Microsoft לא יכולה לספק או ליצור מחדש recovery key שאבד.⁶

לקרוא לזה “ההצפנה מחקה את הנתונים” הופך את הסיבתיות. הסיבה היא שלא הפכתם ניהול recovery key למנגנון; אותו חור ניהול היה מתגלה בגניבה כדליפת מידע.

6.3. recovery key ששומש זורקים — תיקון, אובדן, פרישה

• כשמוסרים לתיקון: אם מסרתם recovery key לטכנאי (או שיש סיכוי שמסרתם), אחרי שהמחשב חוזר קודם מוסיפים recovery password חדש, מאשרים שגיבוי ל-Entra ID / AD DS הצליח, ורק אז מוחקים את ה-recovery password שנמסר. אם מוחקים קודם, כשל בהוספה או בגיבוי משאיר את הכונן בלי אמצעי שחזור. גם Microsoft ממליצה לבטל recovery password אחרי שימוש, והרצף הוספה → גיבוי → מחיקה מסתיים בפקודות.⁵ במכשירי Entra ID יש גם מדיניות שמסובבת אוטומטית recovery password ששומש. ברירת המחדל דולקת במכשירי Entra ID, אבל היא עובדת רק כשמדיניות שמחייבת גיבוי פרטי שחזור (5.1) הוגדרה. לפני שסומכים על סיבוב אוטומטי, מאשרים את התצורה הזו ושוודאים שהמפתח באמת מתחלף.⁴
• כשמחשב אבד: בודקים בפלט הפקודות של פרק 4 או בכלי הניהול אם ההגנה הייתה דלוקה (TPM protector נוצר, clear key הוסר). אם כן, אפשר להסביר ש”הנתונים על הדיסק לא קריאים”. זו הסיבה העיקרית לעשות מלאי בזמן שקט.
• בפרישה / החזרת מחשב: הדבר הראשון הוא לא להשאיר מצב שבו ה-recovery key של המחשב המוחזר יושב רק בחשבון Microsoft האישי של העובד שעזב. אם ריכזתם ליעד הארגוני (פרק 4), העבודה בהחזרה היא kitting מחדש והנפקה מחדש של recovery password.

למשל בתיקון הזרימה היא:

flowchart LR
    S["מוסרים לתיקון<br/>(ייתכן שנמסר recovery key)"] --> B["המחשב חוזר"]
    B --> N["מוסיפים recovery password חדש"]
    N --> BK["מאשרים שגיבוי ל-Entra ID / AD DS הצליח"]
    BK --> D["מבטלים (מוחקים) את<br/>ה-recovery password שנמסר"]
    D --> OK["מעדכנים את הפנקס ומסיימים"]

7. הקשר לגריטה — דיסק מוצפן מקל על הגריטה

BitLocker לא עוזר רק בזמן שימוש. אם הכונן מוצפן מההתחלה, מה שנשאר על הדיסק בגריטה הוא ciphertext בלבד. BitLocker תוכנן מלכתחילה למנוע דליפת נתונים לא רק מאובדן וגניבה אלא גם ממכשיר שנזרק בצורה לא נאותה, והמטרה כוללת להפוך נתונים ללא קריאים בגריטה ובמחזור של מכשיר מוגן.¹

עם זאת, זה שהכונן מוצפן לא אומר שאפשר לדלג על נוהל מחיקה בגריטה (איפוס, כלי מחיקה ייעודי, השמדה פיזית). הצפנה היא ביטוח שמוריד את הסיכון לקרוא plaintext מהדיסק לפני מחיקה או כשמחיקה נכשלת, לא תחליף למחיקה שניתן לאמת. בנוסף, לארגון שמפעיל הצפנה יש משימה ייחודית אחת: סידור עותקי recovery key (נייר, קובץ, רישום ב-AD או ב-Entra ID). גם אחרי שמחקתם את הדיסק, recovery key שנשאר אומר שהגריטה בפנקס לא הסתיימה. מכניסים מחיקת מפתחות ישנים לנוהל הגריטה.

לגריטת מחשב יש גם נושאים מחוץ להצפנה — ביטול חשבונות ורישיונות, פנקס נכסים, תיעוד. את הנוהל המלא ריכזנו כרשימת בדיקה ב”מה לעשות לפני שזורקים מחשב Windows”; כשבונים זרימת גריטה שמניחה הצפנה, משתמשים גם בה.

8. מנקודת מבט של מפתח יישומים עסקיים — ביצועים, מחשבי ציוד, פריסת clone

לבסוף, נקודות למי שאחראי ליישומים עסקיים או למחשבי בקרת ציוד.

• השפעת ביצועים: קודם מודדים ב-128-bit ברירת המחדל. Microsoft עצמה קובעת את אורך המפתח לפי “ביצועי המכשיר”: 256-bit לכונן ולמעבד חזקים, אחרת 128-bit.⁴ במילים אחרות, ב-PC מודרני נדיר ש-XTS-AES 128 ברירת המחדל ישנה את התחושה ביישום עסקי, ואצלנו כמעט לא נתקלנו בזה מחוץ ליישומים עם I/O כבד במיוחד. אם יש חשד, מודדים I/O לפני ואחרי הצפנה בכמות נתונים שקולה לייצור, ואז מחליטים. לכבות כי “נראה שזה יאט” הופך את הסדר.
• ההצפנה שקופה ליישום. BitLocker מצפין את ה-volume כולו, והתנהגות ה-file API לא משתנה. מצד שני, סודות שהיישום מטפל בהם במחשב שכבר ב-logon (connection string, API key) BitLocker לא מגן עליהם. במחשב אחרי logon הכונן נראה מפוענח. לזה נכנס DPAPI (“איפה שומרים סודות ביישום Windows”).
• מחשב ציוד / kiosk נקבע לפי “האם אפשר restart בלי אדם”. בתצורת TPM בלבד חזרה מהפסקת חשמל עולה לבד, אבל TPM+PIN או startup key דורשים אדם בכל אתחול, ולא מתאימים למכשיר unattended. מצד שני, תצורת TPM בלבד נושאת את הסיכון לעצור במסך שחזור בטריגרים של פרק 3 (עדכון firmware וכו’), לכן מניחים recovery key במקום מרוחק מהשטח (אחסון נעול + פנקס) וכותבים בנוהל התחזוקה “Suspend-BitLocker לפני העבודה”. את חיזוק מסוף unattended בכלל כיסינו ב”לקבע מסוף עסקי ב-kiosk mode”. שימו לב: הקלת הדרישות של Device Encryption האוטומטית ב-24H2 לא חלה על מהדורות Windows IoT,² וזה לא אומר ש”ב-IoT אין הצפנה אוטומטית”. בדגמים שעמדו בדרישות הישנות (HSTI/Modern Standby וכו’) הצפנה אוטומטית עדיין אפשרית כמו קודם, לכן גם במחשב ציוד מכניסים בדיקת מצב ב-manage-bde -status ל-kitting.
• בפריסת clone לא עושים “מצפינים ואז יוצרים image”. recovery password ייחודי למכשיר שבו נוצר.³ לא משכפלים image של מכונת אב שההגנה כבר דלוקה בה. אחרי הפריסה מפעילים לכל מחשב בנפרד (או נותנים ל-OOBE להצפין אוטומטית) ואז מגבים recovery key. אם ה-kitting כבר בסקריפט (“אוטומציית PC kitting עם winget + PowerShell”), מוסיפים את ההפעלה ואישור הגיבוי של סעיף 5.4 כשלב אחרון.

9. סיכום

• בהתקנה נקייה של Windows 11 24H2 ואילך, Device Encryption מאותחלת כברירת מחדל במחשבים שעומדים ב-TPM + UEFI Secure Boot. דרישות HSTI/Modern Standby ו-DMA הוסרו, והיעד התרחב עד desktop רגיל.
• התגובה הנכונה ל”הוצפן לבד” אינה כיבוי אלא אישור איפה ה-recovery key. כיבוי מאבד הגנה באובדן, בגניבה ובגריטה, ואחרי כיבוי זה לא נדלק מחדש אוטומטית.
• יעד ה-recovery key הוא Entra ID / AD DS / חשבון Microsoft / הדפסה-קובץ, וכמעט נקבע לפי צורת ה-sign-in. קובעים יעד ארגוני אחד ובודקים שכל המחשבים שם.
• הבדיקה היא manage-bde -protectors -get C: או (Get-BitLockerVolume -MountPoint C).KeyProtector, וגיבוי בדיעבד מסתיים ב-BackupToAAD-BitLockerKeyProtector / Backup-BitLockerKeyProtector.
• recovery key נדרש גם מבעלים לגיטימי אחרי עדכון firmware, שינוי Secure Boot, החלפת חומרה וכו’. מכניסים Suspend-BitLocker לפני עבודה מתוכננת לנוהל.
• השיטה כברירת מחדל היא XTS-AES 128, ושינוי אחר כך דורש פענוח ואז הצפנה מחדש. לכונן חדש Used Space Only מספיק.
• recovery key ששומש מבטלים ומנפיקים מחדש, לא משאירים מפתחות בחשבון של עובד שעזב, ובגריטה קוברים גם את העותקים — recovery key מנוהל במחזור חיים, לא “מנפיקים ונגמר”.
• הצפנה היא גם ביטוח בגריטה, אבל לא תחליף לנוהל מחיקה (איפוס, כלי מחיקה, השמדה פיזית). הפתרון המציאותי לעסק קטן ובינוני אינו לכבות BitLocker אלא להשתמש בו יחד עם ניהול recovery key.

מאמרים קשורים

• מהו TPM ב-Windows — vault שלא מוציא מפתחות, ו-Measured Boot
• מה לעשות לפני שזורקים מחשב Windows — רשימת בדיקה למחיקת נתונים, ביטול חשבונות וגיבוי
• מה באמת עושים אחרי סיום התמיכה ב-Windows 10 — טבלת החלטה ל-ESU, LTSC והחלפה
• מאיפה עסקים קטנים ובינוניים מתחילים באבטחה — סיור ב”הנחיות אבטחת מידע לעסקים קטנים ובינוניים” של IPA, מהדורה 4
• לקבע מסוף עסקי ב-kiosk mode — בחירה בין Assigned Access ל-Shell Launcher ותכנון תפעול
• אוטומציית PC kitting עם winget + PowerShell — להפוך את נוהל ההרצה לניתן-להרצה
• איפה שומרים סודות ביישום Windows — best practices סביב DPAPI

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בתכנון תפעול הצפנה בסביבת Windows שכוללת יישומים עסקיים ומחשבי ציוד (תכנון יעד recovery key, שילוב ב-kitting, תצורת BitLocker במחשב ציוד), ובייעוץ על בדיקת ביצועים וחקירת תקלות של יישום עסקי בסביבה מוצפנת. אפשר להתחיל מ”לבדוק אם אפשר להצפין את מחשב הציוד”.

• ייעוץ טכני וסקירת תכנון
• פיתוח אפליקציות Windows
• חקירת תקלות ואיתור גורמים
• יצירת קשר

מקורות

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

שמתי לב ש-Device Encryption נדלקה מעצמה. אפשר לכבות?

כיבוי אינו מומלץ. בהתקנה נקייה של Windows 11 גרסה 24H2 ואילך, Device Encryption מאותחלת כברירת מחדל במחשבים שעומדים בתנאים כמו TPM ו-Secure Boot, ולכן זה נראה כאילו נדלק לבד. זה המנגנון שמגן על הנתונים באובדן או גניבה. כיבוי מאבד את ההגנה, ואחרי שכיביתם זה לא נדלק מחדש אוטומטית. מה שצריך לעשות אינו לכבות, אלא לבדוק את ה-recovery key בפקודה כמו manage-bde -protectors -get C: ולוודא שהוא נשמר במקום שהארגון קבע — חשבון Microsoft, Entra ID או AD, למשל.

איפה נמצא ה-recovery key של BitLocker?

מקום השמירה נקבע לפי אופן ה-sign-in למחשב. במחשב שהוגדר עם חשבון Microsoft אישי, כניסה ל-https://aka.ms/myrecoverykey באותו חשבון מציגה את הרשימה. במחשב שצורף ל-Entra ID של החברה (חשבון עבודה), בודקים BitLocker keys ב-https://aka.ms/aadrecoverykey. במחשב שצורף לדומיין AD מקומי, אם המדיניות הוגדרה, מנהל יכול לשלוף אותו מתחת לאובייקט המחשב. ייתכן גם עותק מודפס, USB או קובץ שמור. התאמה של 8 הספרות הראשונות של recovery key ID שמוצג במסך השחזור מאפשרת לזהות את המפתח הנכון.

אפשר להשתמש ב-BitLocker במחשב Windows 11 Home?

היכולות משתנות לפי המהדורה. BitLocker במלואו, כולל הוספת PIN וניהול במדיניות, ניתן להפעיל רק במשפחת Pro/Enterprise/Education; ב-Home זה לא זמין. המקבילה הפשוטה, Device Encryption, זמינה בכל המהדורות כולל Home, ונדלקת אוטומטית אם מתקיימים תנאים כמו TPM ו-UEFI Secure Boot. אבל הפעלת ההגנה דורשת sign-in עם חשבון Microsoft בעל הרשאות Administrator — חשבון מקומי לבדו אינו מגן. אם מנהלים את זה כמחשב חברה, מומלץ תצורה שמניחה Pro ומנהלת recovery keys באופן מרכזי דרך Entra ID או AD.

אחרי עדכון BIOS (קושחת UEFI) ביקשו ממני את ה-recovery key. למה?

BitLocker משתמש ב-TPM כדי לוודא שסביבת האתחול לא שונתה. כשמדידות האתחול משתנות — בגלל עדכון firmware, שינוי בהגדרת Secure Boot, ניקוי ה-TPM, החלפת motherboard וכו' — הוא קובע שהסביבה שונה מהרגיל ונכנס ל-recovery mode. זו לא תקלה; זו התנהגות לפי התכנון. לפני עדכון מתוכנן, השעיית ההגנה ב-Suspend-BitLocker (או manage-bde -protectors -disable C:) מאפשרת לבצע את העבודה בלי להזין recovery key. הכונן נשאר מוצפן בזמן ההשעיה, וכברירת מחדל ההגנה מתחדשת אוטומטית באתחול הבא.

אם ה-recovery key לא נמצא, אפשר בכל זאת לשלוף את הנתונים?

בלי ה-recovery key הנכון (recovery password בן 48 ספרות) או אמצעי שחרור אחר, אין דרך לשלוף את הנתונים מהכונן המוצפן. גם התמיכה של Microsoft מצהירה במפורש שהיא אינה יכולה להנפיק מחדש או לשלוף recovery key שאבד. במחשב בניהול הארגון, בודקים קודם מול צוות ה-IT; במחשב אישי, בודקים את דף ה-recovery keys של חשבון Microsoft, עותק מודפס, או קובץ .bek/.txt ב-USB. אם שום דבר מזה לא מעלה מפתח, לא נשאר אלא לאתחל (להתקין מחדש) את המחשב, והנתונים אבודים. לכן בדיוק, לפני שדנים אם לכבות את ההצפנה, צריך קודם לאשר שה-recovery key של כל מחשב נמצא בשליטת הארגון.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.