לדלג לתוכן

Chapter 4: System Ownership & FileVault

Asset B: Facilitator Guide (מדריך למרצה)

הנחיית מבנה למדריך (Facilitator): מסמך זה משמש אותך כתסריט ומערך שיעור. כל נושא כולל "מטרה" למיקוד, "דיון/תסריט" שניתן להקריא או להעביר בסגנון חופשי, "הדגמה" צעד-אחר-צעד, ו"העמקת מדריך" (בתוך רשימה נפתחת) שנועדה לתת לך גב טכני למענה על שאלות מתקדמות מהכיתה. שים לב לשימוש במושגי המפתח הרשמיים.

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

מטרה: להבין מהו Secure Token (אסימון אבטחה) (Secure Token), כיצד הוא מחליף את גישת ה-Admin המסורתית במשימות מאובטחות, ואיך הוא קובע מי רשאי לפתוח את ההצפנה ב-macOS.

דיון (תסריט הדרכה): "בואו נדבר על אחד המושגים שהכי מתסכלים אנשי IT שמגיעים מעולם ה-Windows או ממקים ישנים. בעבר, אם היית מנהל (Admin) בחשבון מקומי – היית אלוהים. יכלת לעשות הכל. במקים מודרניים עם שבב ה-T2 ובעיקר Apple Silicon, אפל שינתה את החוקים והציגה את ה-Secure Token (Secure Token (אסימון אבטחה)). תחשבו על ה-Secure Token בתור 'מפתח המאסטר' האמיתי לקרביים הקריפטוגרפיים של המק. כשהמק מותקן בפעם הראשונה, המשתמש הראשון שנוצר מקבל את ה-Secure Token הזה אוטומטית, והופך למשתמש מורשה לפתוח את ההצפנה של המערכת, מה שנקרא בעלות מערכת (System Ownership). הבעיה מתחילה כשאנחנו, אנשי התמיכה, יוצרים חשבונות חדשים. אם המשתמש הראשון לא 'מעביר' או מאשר הענקת אסימון למשתמש השני, המשתמש השני – אפילו אם הוא מוגדר כחשבון מקומי מנהל (Admin) – לא יוכל להפעיל את FileVault (מנגנון הצפנה), ולא יוכל לאשר שינויים קריטיים דרך Startup Security Utility (כלי אבטחת האתחול)."

הדגמה:

  1. פתחו את כלי השירות Directory Utility (ניתן למצוא דרך Spotlight או בנתיב /System/Library/CoreServices/Applications/).
  2. לחצו על המנעול והזינו סיסמת מנהל.
  3. עברו ללשונית Directory Editor ובחרו בתצוגת Users.
  4. אתרו את המשתמש שלכם ברשימה, וגללו למאפיין AuthenticationAuthority.
  5. הראו לכיתה את הערך המכיל את המחרוזת SecureToken. הסבירו שזוהי החותמת הקריפטוגרפית לכך שהמשתמש הזה מחזיק באסימון אבטחה.

העמקת מדריך (Instructor Deep-Dive):

לחץ להרחבה: איך Secure Token ו-Volume Ownership באמת עובדים מאחורי הקלעים * **Volume Ownership:** במחשבי Apple Silicon, נוסף רובד בשם Volume Owner. המשתמש הראשון שמגדיר את המק הופך לבעלים של Volume (ווליום) הנתונים (Data Volume). המידע הזה נשמר ברמת החומרה ב-Secure Enclave. * ה-Secure Token מקושר קריפטוגרפית למפתחות ה-KEK (Key Encryption Key) שמיוצרים מסיסמת המשתמש, ומשמשים לפתיחת ה-VEK (Volume Encryption Key). * **בדיקת סטטוס וניהול ב-CLI:** בטרמינל, הפקודה `sysadminctl -secureTokenStatus ` היא הדרך המהירה לבדוק אם למשתמש יש אסימון. * **הענקת Token ידנית בטרמינל:** `sysadminctl -adminUser -adminPassword -secureTokenOn -password `.

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

מטרה: להבין את היתרונות של FileVault (מנגנון הצפנה) במחשבי Mac מודרניים, ולנפץ את המיתוסים על פגיעה בביצועים.

דיון (תסריט הדרכה): "בואו נדבר על הצפנה. הרבה מכם בטח זוכרים את הימים שבהם הדלקת FileVault הייתה גזר דין מוות לביצועים של המק. המחשב היה הופך לאיטי בגלל עיבוד בתוכנה, וההצפנה הראשונית לקחה ימים שלמים. היום, עם ה-Apple Silicon, אפל שילבה מנוע AES חומרתי ייעודי ישירות למערכת. מה זה אומר? שכל המידע על Volume (ווליום) הנתונים שלכם מוצפן תמיד, 24/7, ישר מהקופסה! כשאנחנו מפעילים את FileVault אנחנו בעצם לא מתחילים להצפין את הקבצים, כי הם כבר מוצפנים. אנחנו רק 'עוטפים' את מפתח ההצפנה של הדיסק בסיסמת ההתחברות של המשתמש ובאסימון האבטחה שלו (Secure Token). לכן תהליך ההפעלה הוא כמעט מיידי, וחינמי לגמרי מבחינת ביצועי מעבד."

הדגמה:

  1. פתחו את אפליקציית Disk Utility.
  2. בחרו ב-Volume (בווליום) הנתונים (לרוב נקרא Macintosh HD - Data).
  3. הראו לכיתה שבמידע המפורט על ה-Volume (הווליום) מופיע APFS (Encrypted) – למרות ש-FileVault עדיין לא הופעל באופן רשמי במערכת!
  4. פתחו את System Settings, נווטו ל-Privacy & Security וגללו למטה עד שתראו את חלון ה-FileVault. הראו שהוא כבוי, למרות שהכונן עצמו כבר מוצפן חומרתית.

העמקת מדריך (Instructor Deep-Dive):

לחץ להרחבה: קריפטוגרפיה חומרתית, VEK לעומת KEK ו-CLI * **VEK - Volume Encryption Key:** המפתח שמצפין בפועל את המידע על הדיסק ברמת APFS. נשמר בתוך ה-Secure Enclave. * **KEK - Key Encryption Key:** מפתח המופק משילוב של סיסמת המשתמש יחד עם מזהה החומרה הייחודי. כאשר FileVault מופעל, ה-VEK נעטף (Wrapped) על ידי ה-KEK. * **ניהול שורת פקודה:** טכנאים יכולים לבדוק את מצב ההצפנה במהירות באמצעות הפקודה `fdesetup status`. * **מחיקה מאובטחת:** פעולת 'Erase All Content and Settings (EACS) (מחיקת כל התוכן וההגדרות)' משמידה בפועל את ה-VEK, מה שהופך את כל הנתונים לבלתי קריאים בשבריר שנייה.

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

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

דיון (תסריט הדרכה): "אז הדלקנו את FileVault (מנגנון הצפנה), והמערכת שלנו מאובטחת. אבל מה קורה אם המשתמש שוכח את הסיסמה שלו לחלוטין? בזמן הפעלת FileVault דרך System Settings, המערכת תאלץ אותנו לבחור Recovery Key (מפתח שחזור) (Recovery Key). יש לנו שתי אפשרויות: האפשרות הראשונה מתאימה למשתמשים ביתיים: לאפשר ל-iCloud לשחרר את הדיסק. המפתח שמור בענן של אפל ומשתחרר לאחר הזנת ה-Apple ID והסיסמה. האפשרות השנייה, שהיא המקובלת בארגונים, היא יצירת Recovery Key (מפתח שחזור) אישי (Personal Recovery Key או PRK). המערכת תייצר מחרוזת ארוכה שרק בעזרתה ניתן יהיה לפתוח את הדיסק ממצב התאוששות. בארגונים, אנחנו רוצים שליטה מלאה ולא רוצים תלות בחשבון ה-Apple הפרטי של העובד."

הדגמה:

  1. בתוך System Settings -> Privacy & Security -> FileVault, לחצו על כפתור Turn On.
  2. הראו לכיתה את חלון הבחירה שקופץ: הדילמה בין חיבור ל-iCloud לבין יצירת מפתח אישי.
  3. בחרו באפשרות של יצירת Recovery Key (מפתח שחזור).
  4. הציגו את המחרוזת הארוכה שנוצרת (PRK) והסבירו את החשיבות של שמירתה במערכת חיצונית בארגון.

העמקת מדריך (Instructor Deep-Dive):

לחץ להרחבה: אימות ויצירה מחדש של מפתחות בטרמינל * **Institutional Recovery Key - IRK:** בעבר ארגונים יצרו מפתח אב מוסדי אחיד (FileVaultMaster.keychain). כיום, בסביבות Apple Silicon, הגישה הזו נזנחה כמעט לחלוטין לטובת PRK אישי שעושה Escrow ל-MDM. * **אימות מפתח קיים:** הפקודה `sudo fdesetup validaterecovery` מאפשרת למנהל IT לוודא שהמפתח ששמור אצלו באמת פותח את המחשב מבלי לאתחל ל-Recovery. * **יצירת מפתח חדש ללא כיבוי והדלקה של המנגנון:** ניתן לייצר PRK חדש לחלוטין באמצעות הרצת הפקודה: `sudo fdesetup changerecovery -personal`.

4. תיבול ארגוני: ה-Bootstrap Token ואיך MDM "אוגר" מפתחות הצפנה

מטרה: להסביר כיצד שרת הניהול (MDM) פותר את כאב הראש של הענקת Secure Token ואחסון מפתחות FileVault בעזרת Bootstrap Token (אסימון אתחול) (Bootstrap Token).

דיון (תסריט הדרכה): "חבר'ה, הנה הקסם הארגוני. אם לכל יוזר חדש אנחנו צריכים להעניק ידנית Secure Token כדי שיוכל לנהל את המק, זה פשוט לא סקיילבילי בארגון של אלפי משתמשים. הפתרון של אפל הוא ה'Bootstrap Token (אסימון אתחול)' (Bootstrap Token). ברגע שהמק נרשם לשרת הניהול (MDM), המשתמש הראשון יוצר Bootstrap Token (אסימון אתחול) מאחורי הקלעים ושולח אותו כפיקדון (Escrow) ישירות ל-MDM. כשעובד חדש נכנס לאותו מק, המק מדבר עם ה-MDM, מושך את ה-Bootstrap Token, ובעזרתו מנפיק למשתמש החדש Secure Token משלו! הכל קורה אוטומטית. בנוסף, ה-MDM גם דואג להפעיל את FileVault ברקע באופן שקוף ולשלוח אליו את מפתח השחזור (PRK), כך שאם עובד שוכח סיסמה, טכנאי התמיכה יכול למצוא את המפתח בפורטל הניהול בקלות."

הדגמה:

  1. פתחו את אפליקציית Console (דרך Spotlight).
  2. התחילו את ההקלטה (Start) בשורת הכלים העליונה.
  3. בתיבת החיפוש העליונה, הקלידו bootstraptoken או mdmclient ולחצו Enter.
  4. הסבירו לכיתה שמאחורי הקלעים ניתן לראות כאן כיצד המק וה-MDM מנהלים תהליכי הפקדה ומשיכה של אסימונים. במק מנוהל (MDM), הרישומים (Logs) יראו את התקשורת החיה.

העמקת מדריך (Instructor Deep-Dive):

לחץ להרחבה: כלי CLI לבדיקת Bootstrap Token * **אבחון שורת פקודה:** הפקודה המרכזית לאבחון תקשורת ה-Token מול ה-MDM היא `sudo profiles status -type bootstraptoken`. הפלט יראה האם הוא נתמך והאם הוא הופקד (Escrowed). * **Deferred Enablement:** ה-MDM יכול לשלוח תצורה שדורשת הפעלת FileVault. המערכת תחכה עד שהמשתמש יתחבר למערכת, תשתמש בסיסמה שלו כדי לעטוף את המפתח, ותשלח את ה-PRK שנוצר ישירות ל-MDM. * ניתן לאלץ יצירה ומשלוח של Bootstrap Token (אסימון אתחול) ל-MDM באופן ידני בזמן אבחון תקלות על ידי הרצת `sudo profiles install -type bootstraptoken`.