פרק 4: בעלות מערכת והצפנה (System Ownership & FileVault) - Asset A (Instructor Reference)

1. אסימוני אבטחה: Secure Token ומי רשאי לאשר שינויים קריטיים.

1. High-Level Theory & History מאז שילוב מערכת הקבצים APFS במערכת ההפעלה macOS 10.13 High Sierra, אפל שינתה לחלוטין את מודל "בעלות המערכת" ואת האופן שבו משתמשים מקבלים הרשאות קריפטוגרפיות. בעבר, כל משתמש עם הרשאות מנהל (Admin) יכל לשלוט באופן מוחלט במערכת. כיום, כדי שמשתמש יוכל לבצע פעולות רגישות - כגון הפעלת FileVault, עדכון מערכת הפעלה בסביבת Apple Silicon, או אישור תהליכים ברמת הקרנל - הוא חייב להחזיק ב-Secure Token (Secure Token). ה-Secure Token הוא למעשה שרשרת אמון קריפטוגרפית. המשתמש הראשון שנוצר במק (בין אם ב-Setup Assistant ובין אם דרך תהליך התקנה) מקבל באופן אוטומטי Secure Token. כל משתמש שנוצר לאחר מכן חייב לקבל את ה-Secure Token שלו ממשתמש שכבר מחזיק בו. הדבר נועד למנוע מצב שבו פורץ או תוכנה זדונית יוצרים חשבון מנהל נסתר ומקבלים גישה למידע מוצפן של משתמשים אחרים.

2. Deep Technical Architecture: מבחינה טכנית, Secure Token (Secure Token) הוא גרסה עטופה (Wrapped) של ה-Key Encryption Key (KEK), אשר בתורו מגן על ה-Volume Encryption Key (VEK) של ה-APFS Data Volume. במחשבי Apple Silicon, מנגנון זה קשור באופן הדוק לרכיב ה-Secure Enclave. כאשר משתמש מוזן למערכת ומקבל Secure Token, סיסמת ההתחברות שלו עוברת סדרה של פעולות מתמטיות בשילוב עם מזהה החומרה הייחודי של המק (UID של ה-Secure Enclave). התוצאה היא מפתח שמאפשר למערכת לפענח את ה-VEK בעת ההפעלה. לכן, משתמש ללא Secure Token לעולם לא יוכל לפתוח את הדיסק ממצב כבוי (Cold Boot), מכיוון שהסיסמה שלו אינה קשורה לפענוח ה-VEK ב-Secure Enclave. יתרה מזאת, במחשבי Apple Silicon, ה-Secure Token מתקשר גם עם מושג של "Volume Ownership" (בעלות על ה-Volume), הקובע אילו משתמשים מורשים לשנות את רמת האבטחה בכלי אבטחת האתחול (Startup Security Utility) או לאשר התקנת עדכוני מערכת.

3. Terminal Commands, Plists & Logs: כדי לבדוק את סטטוס ה-Secure Token של משתמש ספציפי, נשתמש בפקודה sysadminctl בטרמינל. הפקודה מחייבת ציון שם המשתמש: sysadminctl -secureTokenStatus <username>

כדי להעניק Secure Token למשתמש אחר באופן ידני (פעולה שלרוב מתבצעת אוטומטית בממשק המשתמש דרך ה-System Settings, אך נדרשת לעיתים כפעולת IT), יש להשתמש בסיסמה של מנהל קיים (שכבר מחזיק בטוקן): sysadminctl -secureTokenOn <target_user> -password <target_password> -adminUser <admin_user> -adminPassword <admin_password>

ניתן לחפש ברישומי המערכת (Logs) תהליכים הקשורים להנפקת הטוקן באמצעות השאילתה ב-Console או בטרמינל: log show --predicate 'subsystem == "com.apple.opendirectoryd"' --info תהליכים הקשורים ליצירת משתמשים ולשיוך קריפטוגרפי יופיעו תחת שירות opendirectoryd.

4. Edge Cases & Troubleshooting: מקרה קיצון נפוץ הוא "Secure Token Deadlock" (מבוי סתום). תרחיש זה מתרחש כאשר משתמשים נמחקים או מנוהלים באופן שגוי (למשל מחיקת האדמין הראשון לפני העברת הטוקן), ונוצר מצב שבו לא נותר באף חשבון במק טוקן מאושר. במצב כזה, לא ניתן להפעיל FileVault ולא ניתן לעדכן מערכת ב-Apple Silicon. אם זה קורה על מק שאינו מנוהל (ללא Bootstrap Token), הפתרון היחיד כדי להחזיר את האבטחה לסדרה הוא לבצע Erase All Content and Settings (EACS) (EACS) או לפרמט את Volume הנתונים ויצירת המשתמש הראשון מחדש. תקלות נוספות יכולות להתרחש כאשר מגדירים משתמשי רשת (Network/Mobile Accounts) מול שרתי ספריה כמו Active Directory. מכיוון שהם לא מקבלים אוטומטית את ה-Secure Token, יש לדאוג להעבירו באמצעות מנהל קיים או להסתמך על תהליכי MDM.

2. הצפנת APFS: איך FileVault עובד (ללא האטה בביצועים) במחשבי Apple Silicon.

1. High-Level Theory & History FileVault עבר גלגולים רבים לאורך ההיסטוריה. בגרסאותיו הראשונות (FileVault 1) הוא הצפין רק את תיקיית הבית של המשתמש כקובץ תמונת דיסק (DMG). עם השנים הוא עבר ל-FileVault 2 שהצפין Volumes שלמים ברמת מערכת הקבצים HFS+ תוך שימוש במעבד הראשי (מה שגרם לעיתים להאטה קלה בביצועים). כיום, בעידן ה-Apple Silicon, התמונה שונה לחלוטין. הצפנת הנתונים מובנית ברמת החומרה ומתבצעת באופן אקטיבי על ידי רכיב ה-AES Engine המסונכרן עם ה-Secure Enclave. המשמעות היא שכל מק מודרני מנתב את כל הקריאות והכתיבות לדיסק דרך מנוע הצפנה חומרתי ללא קשר לסיסמת המשתמש (תהליך שנקרא Data Protection). הפעלת FileVault בפועל אינה גורמת להצפנה מחדש של הדיסק שתיקח שעות, אלא מבצעת פעולה שקופה שקושרת את מפתחות ההצפנה הקיימים (VEK) לסיסמת המשתמש תוך שניות ספורות (תהליך שנקרא Wrapping). התוצאה: אפס פגיעה בביצועי קריאה/כתיבה.

2. Deep Technical Architecture: במחשבי Apple Silicon, מנוע ההצפנה (AES Crypto Engine) ממוקם כחוליה מקשרת בין בקר הזיכרון לבין אחסון הפלאש המובנה (NAND). הוא משתמש במפתח הנקרא Volume Encryption Key (VEK), אשר נוצר משילוב של מזהה חומרה קשיח (UID של הלשכה המאובטחת) ומפתח אקראי הנקרא xART. מאחר והתהליך חומרתי, Volume הנתונים תמיד מוצפן. כאשר משתמש מפעיל FileVault, מערכת ההפעלה macOS יוצרת Key Encryption Key (KEK) המבוסס על סיסמת המשתמש. ה-KEK "עוטף" את ה-VEK. בעת אתחול המחשב (Cold Boot), ה-Secure Enclave לא ימסור את ה-VEK לפענוח הדיסק עד שהמשתמש יקליד את סיסמתו במסך ה-Pre-boot. חשוב לציין שההצפנה מתבצעת על Volume הנתונים (Data Volume), בעוד שווליום המערכת החתום (SSV) נותר מוגן על ידי חתימות קריפטוגרפיות ולא מוצפן לחלוטין ב-FileVault, כדי לאפשר למערכת לבצע בוט בסיסי להצגת מסך ה-Login.

3. Terminal Commands, Plists & Logs: הכלי המרכזי לניהול FileVault דרך ממשק שורת הפקודה (CLI) הוא fdesetup (Full Disk Encryption Setup). כדי לבדוק האם הדיסק מוצפן כעת (והאם FileVault מופעל באופן פעיל עם KEK של משתמש): fdesetup status

כדי להפעיל את FileVault באופן יזום ולקבל Recovery Key לטרמינל (דורש משתמש עם Secure Token): sudo fdesetup enable

כדי להציג רשימה של המשתמשים שרשאים לפתוח את הדיסק בעת בוט: sudo fdesetup list

הגדרות קשורות ל-FileVault שמורות לעיתים בפרופילי תצורה של המערכת במסלול: /Library/Preferences/com.apple.fdesetup.plist

4. Edge Cases & Troubleshooting: בעיה שכיחה מתרחשת כאשר משתמש משנה את סיסמתו מחוץ להגדרות הסטנדרטיות (למשל במערכת ניהול זהויות ארגונית, או דרך פקודות MDM שלא סינכרנו את ה-Keychain). במצב זה, סיסמת ההתחברות החדשה (Login) אינה מסונכרנת עם סיסמת ה-FileVault (ה-KEK הישן עדיין עוטף את ה-VEK). המשתמש יגלה שהוא נדרש להקליד את הסיסמה הישנה עם הדלקת המחשב (כדי לשחרר את הצפנת הדיסק) ואז שוב את הסיסמה החדשה במסך הנעילה של macOS. הפתרון הוא לעדכן את הסיסמה בצורה מוסדרת בממשק ה-System Settings כדי לעדכן את מפתח ה-KEK ב-Secure Enclave. מקרה קיצון נוסף: בעת תקלה לוגית נדירה במבנה ה-APFS (העץ הלוגי של המכל), נראה ש-fdesetup status יחזיר הודעת שגיאה על אי-זמינות הדיסק. במצב כזה, יש להפעיל במצב התאוששות (Recovery Mode), להפעיל First Aid ב-Disk Utility ולפענח ידנית עם מפתח השחזור כדי לתקן את נתיבי המערכת.

3. שחזור דיסק נעול: מפתחות שחזור (PRK לעומת iCloud).

1. High-Level Theory & History FileVault נועד למנוע גישה לנתונים ללא סיסמה. עם זאת, זיכרון אנושי הוא שביר, ואם משתמש שוכח את סיסמתו, הנתונים שלו אבודים. כדי לספק רשת ביטחון, אפל מציעה "Recovery Key" (Recovery Key) במהלך הפעלת FileVault. לצרכנים ולמשתמשים שאינם מנוהלים ב-MDM קיימות שתי אופציות מרכזיות: האפשרות הראשונה היא Recovery Key אישי - Personal Recovery Key (PRK). מדובר במחרוזת אלפא-נומרית אקראית וארוכה (למשל, ABCD-EFGH-IJKL-MNOP-QRST-UVWX), שנוצרת באופן מקומי. המשתמש מחויב לרשום אותה במקום בטוח שאינו על המק עצמו. האפשרות השנייה היא שימוש בחשבון ה-Apple Account כדי לגבות את מפתח השחזור ב-iCloud (iCloud Recovery). אפשרות זו חוסכת למשתמש את הצורך לשמור את ה-PRK הפיזי, ומאפשרת לו לאפס את הסיסמה במסך ה-Recovery באמצעות סיסמת ה-Apple Account שלו (מנגנון המיועד ללקוחות קצה פרטיים, אך פחות מומלץ לארגונים).

2. Deep Technical Architecture: מבחינה ארכיטקטונית, יצירת Recovery Key פירושה שהמערכת מייצרת Key Encryption Key (KEK) נוסף בתוך ה-Secure Enclave. כלומר, ה-Volume Encryption Key (VEK) הופך להיות עטוף גם על ידי סיסמת המשתמש וגם על ידי מפתח ה-PRK. כאשר המשתמש בוחר לגבות את המפתח ל-iCloud, ה-PRK נשמר באופן מאובטח ומוצפן א-סימטרית באמצעות המפתח הציבורי של השרתים של אפל. המפתח נשלח לחשבון ה-iCloud של המשתמש. אפל עצמה אינה יכולה לקרוא את מפתח השחזור ללא האימות הדו-שלבי (2FA) או המכשיר המהימן של המשתמש. ברגע שהמשתמש שוכח את סיסמתו ונכנס ל-Recovery Mode, מערכת ההפעלה מתחברת לרשת, מבקשת מ-iCloud את מפתח השחזור לאחר אימות, ומעבירה אותו חזרה ל-Secure Enclave המקומי כדי לפענח את ה-VEK ולפתוח את ה-Volume. הגישה הישנה של Recovery Key ארגוני קבוע (Institutional Recovery Key - IRK), המבוסס על תעודת PKI ציבורית/פרטית שהותקנה על כלל המחשבים, הפכה למיושנת ואינה נתמכת או מומלצת עוד על ידי אפל עבור מחשבי Apple Silicon עקב סיכוני פריצה (אם המפתח הפרטי הארגוני דולף, כל המחשבים בארגון פרוצים).

3. Terminal Commands, Plists & Logs: ליצירת Recovery Key אישי (PRK) חדש דרך הטרמינל ללא מעורבות ה-iCloud (פעולה שימושית לרענון מפתח ישן): sudo fdesetup changerecovery -personal המערכת תדרוש את סיסמת מנהל המערכת ותציג פלט עם מחרוזת ה-PRK החדשה.

כדי לאמת שמפתח השחזור הרשום במסמכי ה-IT תקין ויכול לפתוח את ה-FileVault (מבלי לעשות ריסטרט למחשב): sudo fdesetup validaterecovery לאחר הרצת הפקודה, תתבקשו להקליד את ה-PRK (הטקסט לא יופיע על המסך). המערכת תחזיר "true" אם המפתח זהה למה שנשמר ב-Secure Enclave, או "false" אם הוא שגוי.

4. Edge Cases & Troubleshooting: מקרה קיצון קלאסי בארגונים נוצר כאשר עובדים בוחרים באופציית ה-iCloud Recovery מתוך נוחות בזמן תהליך ההתקנה. מכיוון שה-Apple Account אינו תמיד חשבון מנוהל (Managed Apple Account), לארגון ול-IT אין גישה לשחזר את הדיסק אם העובד עוזב. מסיבה זו, Best Practice ארגוני מחייב לחסום את אופציית ה-iCloud דרך פרופילי ניהול ולחייב שימוש ב-PRK (שינוהל אוטומטית כפי שנראה בפרק הבא). פתרון תקלות נוסף: כאשר מחשב נעול במצב FileVault ולא עולה בכלל, טכנאי IT ישתמשו במצב כונן יעד (Mac Sharing Mode ב-Apple Silicon) לחבר כבל Thunderbolt ממק תקין, ויפתחו את ה-Volume הנעול מהמק התקין בעזרת הזנת ה-PRK בממשק ה-Disk Utility המארח.

4. תיבול ארגוני: ה-Bootstrap Token כמנוף ארגוני (Escrow ל-MDM), ואיך MDM "אוגר" מפתחות הצפנה.

1. High-Level Theory & History מנגנון ה-Secure Token חולל מהפכת אבטחה, אך הוא יצר כאב ראש עצום למנהלי IT. ארגונים שרצו להפיץ מחשבים למשתמשים מרוחקים באמצעות Zero-Touch Deployment (רישום אוטומטי ב-ADE), או ארגונים שרצו לאפשר למשתמשי רשת להתחבר ולהפעיל עצמאית את ה-FileVault, גילו שמשתמשים חדשים פשוט לא מקבלים Secure Token מכיוון שה-IT לא הזין סיסמת אדמין ראשונית ידנית באופן פיזי על המחשב. התוצאה: Secure Token Deadlock ארגוני. כדי לפתור זאת, אפל הציגה את אסימון האתחול (Bootstrap Token). זהו פתרון קסם עבור סביבות מנוהלות. בעת ה-Setup Assistant, המק מייצר "Bootstrap Token" מיוחד שמגובה אוטומטית (Escrow) בשרת הניהול (MDM). כל פעם שמשתמש חדש מתחבר למחשב המנוהל, מערכת ההפעלה מתקשרת בשקט מול ה-MDM, מבקשת לאמת את ה-Bootstrap Token, וברגע שהיא מקבלת אישור - המערכת מעניקה לאותו משתמש Secure Token באופן אוטומטי ושקוף, מבלי לבקש סיסמת אדמין ישנה.

2. Deep Technical Architecture: אסימון האתחול (Bootstrap Token) מתפקד כ"מפתח שלד" קריפטוגרפי. במחשבים המנוהלים על ידי MDM, מערכת ההפעלה אוספת נתוני אבטחה ברגע שהמשתמש הראשון (ה-Volume Owner ההתחלתי) משלים את ה-Setup. המערכת אורזת את ה-Bootstrap Token בתוך Payload (Payload) מוצפן ושולחת אותו לשרת הניהול באמצעות פרוטוקול MDM מאובטח. עותק של ה-Bootstrap Token נשמר גם באופן מוגן בתוך ה-Secure Enclave של המק המקומי. בנוסף למתן Secure Tokens למשתמשים מקומיים או רשתיים חדשים, ה-Bootstrap Token מהווה מרכיב חיוני במחשבי Apple Silicon לשליטה מרחוק של ה-MDM במנגנוני המערכת: בעזרתו, ה-MDM יכול להתקין עדכוני תוכנה (Software Updates) וארכיטקטורות Kext ללא אישור פיזי מצד ה-Volume Owner. לצד זה, ארגונים משתמשים ב-MDM גם כדי "לאגור" (Escrow) את מפתחות ה-PRK של ה-FileVault עצמו. הארגון דוחף Configuration Profile שאוסר הצגת חלון קופץ של iCloud Recovery למשתמש, מייצר את ה-PRK בשקט מאחורי הקלעים, ושולח את ה-PRK מוצפן ישירות לדאטה-בייס של ה-MDM. זה מבטיח שלצוות התמיכה תמיד יהיה את ה-PRK לשחרור נעילות ללא תלות בעובד.

3. Terminal Commands, Plists & Logs: מנהלי IT שמבצעים דיאגנוסטיקה יכולים לבדוק האם ה-Bootstrap Token נוצר ונשלח בהצלחה לשרת ה-MDM. פעולה זו מתבצעת דרך כלי ה-MDM הפנימי של macOS (ולא דרך sysadminctl): sudo profiles status -type bootstraptoken הפלט התקין אמור להציג: Bootstrap Token supported on server: YES Bootstrap Token escrowed to server: YES

במידה ותהליך הסנכרון הראשוני כשל (למשל עקב בעיות רשת באתחול), ניתן לאלץ את המק לשלוח את האסימון ל-MDM באופן ידני (פעולה זו תדרוש הקלדת סיסמה של מנהל שמחזיק בטוקן רגיל): sudo profiles install -type bootstraptoken

לאימות ה-Bootstrap Token השמור מקומית: sudo profiles validate -type bootstraptoken

את לוגיקת התקשורת והפקודות מול ה-MDM ניתן למצוא ברישומי ה-mdmclient: log show --predicate 'process == "mdmclient"' --info

4. Edge Cases & Troubleshooting: תקלה קלאסית בסביבה ארגונית: עובד פותח מחשב חדש (Zero-Touch), אך עקב חסימת רשת ארגונית (Firewall) ה-Mac נכשל בהעלאת ה-Bootstrap Token לשרת ה-MDM (הפקודה תחזיר escrowed to server: NO). כאשר עובד שני או חשבון אדמין רשתי ינסו להתחבר, המערכת תסרב להעניק להם Secure Token. כתוצאה מכך, הם לא יוכלו לאשר עדכונים, ואם FileVault יופעל בהמשך, לא יראו את החשבון שלהם במסך פתיחת הדיסק. הפתרון במקרה זה הוא לאמת את שחרור החסימה ברשת ולהריץ מידית sudo profiles install -type bootstraptoken תחת משתמש מורשה כדי לתקן את שרשרת האבטחה מול השרת. חשוב שמנהלי תמיכה ידעו לזהות את ההבדל: sysadminctl מנהל הרשאות משתמשים לוקאליות, בעוד פקודת profiles אחראית בלעדית לתקשורת ה-Bootstrap Token הארגונית.