לדלג לתוכן

Chapter 13: Boot Process Architecture (תהליך האתחול ואדריכלות אבטחה)

Asset A: Instructor Reference (Book-Book)

1. שרשרת האתחול: מ-Boot ROM דרך LLB ועד הקרנל במחשבי Apple Silicon

1. High-Level Theory & History מבחינה היסטורית, מחשבי מק מבוססי Intel השתמשו במערכת EFI (Extensible Firmware Interface) כדי לנהל את תהליך ה-Boot, ולטעון את קובץ ה-boot.efi ובסופו של דבר את הקרנל. תהליך זה היה רגיש לשינויים חיצוניים, Rootkits, ונוזקות Firmware. עם המעבר לארכיטקטורת Apple Silicon (מערכת על שבב - SoC), אפל שינתה לחלוטין את מודל האתחול והעתיקה את הארכיטקטורה ממכשירי ה-iOS. המודל החדש אינו מסתמך רק על תוכנה שטוענת תוכנה, אלא מבוסס על שרשרת אמון המעוגנת בחומרה (Hardware-Rooted Chain of Trust). כל שלב בשרשרת חייב לבדוק את החתימה הקריפטוגרפית (Digital Signature) של הרכיב הבא לפני שהוא מעביר אליו את השליטה, מה שמבטיח שהמערכת תריץ אך ורק קוד חתום ומאושר על ידי אפל.

2. Deep Technical Architecture תהליך ה-Boot במחשבי Apple Silicon (שרשרת האתחול) מורכב משלבים קפדניים:

  1. Boot ROM: זהו השלב הראשון והוא צרוב פיזית (Hardcoded) בתוך ה-SoC במהלך הייצור (Read-Only). הוא מכיל את המפתח הציבורי של אפל (Apple Public Key) ומהווה את שורש האמון (Root of Trust). לא ניתן לשנות או לעדכן אותו.
  2. LLB - Low-Level Bootloader: ה-Boot ROM קורא את ה-LLB מהאחסון הפנימי, מוודא את חתימתו באמצעות המפתח הציבורי, ומריץ אותו. ה-LLB אחראי לאתחול בסיסי של החומרה וטעינת רכיב ה-Secure Enclave.
  3. iBoot - Stage 2 Bootloader: ה-LLB מוודא וטוען את ה-iBoot. תפקידו של ה-iBoot הוא לטעון את סביבת ההתאוששות (Recovery Mode) במידה ונדרש, או לאמת את קרנל המערכת (macOS Kernel) ולטעון אותו מתוך ה-Sealed System Volume (SSV).
  4. macOS Kernel & SSV: הקרנל מאתחל את המערכת, מעגן (Mount) את ה-SSV ומוודא שעץ הגיבוב (Hash Tree) של APFS תואם את החותמת (Seal) של אפל. רכיב ה-Secure Enclave מהווה שחקן מרכזי בשרשרת, שכן הוא מספק את מפתחות ההצפנה החומרתיים הדרושים לפענוח ה-Data Volume. אם חתימה כלשהי נכשלת באחד השלבים, תהליך ה-Boot נעצר מיד, מה שמונע ממערכת נגועה לעלות.

3. Terminal Commands, Plists & Logs

  • בדיקת מצב ה-Boot ורמת ה-Secure Boot הנוכחית: system_profiler SPSoftwareDataType

  • בדיקת חותמת ה-SSV של המערכת: diskutil apfs list (חפשו את השורה "Seal: Broken" או "Seal: Intact").

  • קריאת לוגים מתהליך האתחול והקרנל: log show --predicate 'subsystem == "com.apple.kernel"' --last boot (הערה: אין פקודות טרמינל המאפשרות שינוי או גישה ישירה ל-Boot ROM, LLB או iBoot. רכיבים אלו סגורים לחלוטין למניעת שינוי זדוני "N/A").

4. Edge Cases & Troubleshooting אם שרשרת האתחול קורסת או מושחתת (למשל כשל בעדכון קושחה שפגע ב-LLB או ב-iBoot), המק לא ידלק בכלל וייכנס למצב DFU (Device Firmware Update). במצב זה, המק מתפקד כ"לבנה" פסיבית וממתין שמק אחר יתחבר אליו באמצעות כבל וידחוף אליו קובץ IPSW חתום מחדש בעזרת אפליקציית Apple Configurator (או Finder בגרסאות macOS מודרניות). התהליך נקרא Revive (תיקון קושחה ללא איבוד נתונים) או Restore (מחיקת כל הנתונים צריבה מחדש של הקושחה), והוא המוצא היחידי להחייאת מק מבוסס Apple Silicon עם Boot Chain שבור.

2. Startup Security Utility: שינוי רמות האבטחה (Full Security מול Reduced Security) ולמה שנרצה להוריד אבטחה

1. High-Level Theory & History בעידן מחשבי אינטל עם שבב ה-T2, אפל הציגה את ה-Startup Security Utility כדי לאכוף Secure Boot ולמנוע אתחול מכוננים חיצוניים. עם המעבר ל-Apple Silicon, פרדיגמת האבטחה השתנתה: כעת, לכל Volume במערכת יכולה להיות מדיניות אבטחה מקומית (Local Policy) משלו. Startup Security Utility (Startup Security Utility), הנגיש אך ורק מתוך Recovery Mode, מאפשר למשתמש בעל הרשאות מיוחדות לשנות את רמת האבטחה של מערכת ההפעלה ולהתיר טעינה של רכיבי צד-שלישי שאינם חתומים ישירות על ידי אפל כחלק מהמערכת הבסיסית.

2. Deep Technical Architecture במחשבי Apple Silicon קיימות שתי רמות אבטחה מרכזיות הקובעות כיצד שרשרת ה-Boot מתייחסת לקרנל:

  • אבטחה מלאה (Full Security - ברירת מחדל): מערכת ההפעלה מתנהגת בדיוק כמו מכשיר iOS. המק יאתחל אך ורק אם מערכת ההפעלה והקרנל חתומים בצורה מלאה על ידי אפל ללא שינויים. במצב זה נמנעת טעינת הרחבות קרנל צד-שלישי.
  • אבטחה מופחתת (Reduced Security): מצב המאפשר למשתמש להתקין הרחבות קרנל (Kexts) חיצוניות או פרופילי MDM מתקדמים ללא חתימה מחמירה של אפל. שינוי למצב זה מעדכן את ה-Local Policy (הנשמר בקונטיינר ה-iSCPreboot ב-APFS) שמנחה את ה-iBoot להרשות טעינת Auxiliary Kernel Collection (אוסף קרנל עזר). מוריד את הרף מול אפל, אך דורש אמון במנהל המקומי.
  • Mac Sharing Mode: במצבי קצה שבהם המערכת פגומה והמשתמש זקוק לחלץ מידע דחוף, ניתן להפעיל מתוך סביבת ה-Recovery את Mac Sharing Mode (Mac Sharing Mode / Target Disk Mode ההיסטורי). מצב זה מדלג על טעינת מערכת ההפעלה ומריץ שרת SMB וירטואלי מעל כבל Thunderbolt, כך שמק מארח יוכל להתחבר לכונן, לאמת סיסמה מול ה-Secure Enclave, ולהעתיק קבצים מה-Data Volume.

3. Terminal Commands, Plists & Logs

  • הצגת סטטוס האבטחה (Local Policy) (ב-Recovery): bputil -d

  • בדיקת מנגנוני ה-SIP ומדיניות ההגנה בסביבה החיה: csrutil status

  • בדיקת סטטוס הסכמת הרחבות הקרנל: spctl kext-consent status (הערה: לא קיימת פקודת טרמינל המאפשרת הורדת רמת האבטחה מתוך סביבת מערכת חיה. השינוי מחייב אתחול ל-Recovery Mode).

4. Edge Cases & Troubleshooting אם משתמש נכנס לכלי אבטחת האתחול ומנסה לשנות ל-Reduced Security אך המערכת מסרבת לקבל את הסיסמה שלו (או שהמשתמש לא מופיע ברשימה), המשמעות היא שהמשתמש אינו "Volume Owner". אין לו Secure Token (Secure Token) צמוד לחשבון, ולכן ה-Secure Enclave אינו מכיר בו כגורם מוסמך לעריכת ה-Local Policy. בנוסף, שינוי של רמת אבטחה מחייב פעמים רבות חיבור אינטרנט זמין (או כרטיס אישור מקומי) מכיוון שה-iBoot מנסה "לצלצל הביתה" לשרתי החתימות של אפל (Tatsu Signing Server) כדי לחתום קריפטוגרפית על המדיניות החדשה. ללא אינטרנט בסביבת ה-Recovery, השינוי עשוי להיכשל.

3. הרחבות קרנל (Kexts): למה אפל הורגת אותן ואיך מתקינים אותן בכל זאת במק מודרני

1. High-Level Theory & History הרחבות קרנל (Kernel Extensions או Kexts) הן פיסות קוד נמוכות הנטענות ישירות לתוך מרחב הליבה של macOS, ומעניקות להן שליטה מוחלטת ואקסלוסיבית על חומרת המערכת והרשת. היסטורית, כלים ארגוניים כמו אנטי-וירוס, פיירוולים חכמים (VPN), ודרייברים לחומרה עשו שימוש ב-Kexts. הבעיה היא שקרש אחד קטן בקוד של Kext מביא לקריסת המערכת כולה (Kernel Panic), ו-Kext זדוני מוביל להשתלטות עוינת מוחלטת. כיום, אפל מבצעת Deprecation (הוצאה משימוש) של Kexts לטובת System Extensions הרצות במרחב המשתמש הרגיל. עם זאת, עדיין קיימות תוכנות עמוקות המחייבות טעינת Kext.

2. Deep Technical Architecture במערכות macOS מודרניות, התקנת Kext היא אירוע מורכב. תחילה, המערכת חייבת להיות מוגדרת תחת Reduced Security. כאשר מתקינים Kext, ה-macOS לא מכניסה אותו ישירות לתוך הקרנל המקורי החתום של המערכת (אשר נעול בתוך ה-SSV). במקום זאת, המערכת מרכיבה קולקציית ליבה נפרדת הנקראת Auxiliary Kernel Collection (AKC). במהלך ה-Boot, ה-iBoot קורא את ה-Local Policy, ואם אישור ה-Kext קיים שם, הוא טוען את ה-AKC במקביל לקרנל המקורי. ארכיטקטורה זו מבטיחה שאם מנהל המערכת מחליט להחזיר את האבטחה ל-Full Security, ה-AKC מפסיק להיטען והמחשב חוזר למצבו הבתולי ללא כל קוד ליבה צד-שלישי.

3. Terminal Commands, Plists & Logs

  • הצגת Kexts פעילים שאינם של אפל: kmutil showloaded --list-only | grep -v com.apple

  • ניקוי מערך ההכנה של ה-AKC (כלי פתרון תקלות עמוק ב-Terminal): sudo kmutil clear-staging

  • הצגת הרחבות מערכת מודרניות (המחליפות של Kexts): systemextensionsctl list

4. Edge Cases & Troubleshooting תרחיש נפוץ בארגונים: משתמש מתקין כלי אבטחה ישן מבוסס Kext. התוכנה נראית מותקנת, אך היא לא פועלת בפועל מכיוון שהמשתמש לא נכנס ל-Recovery Mode להוריד את רמת האבטחה ולא אישר אותה באופן ידני ב-System Settings. במקרה שהמשתמש כן אישר, וה-Kext תקול ויוצר Kernel Panic מיד עם האתחול, המחשב ייכנס ללולאת הפעלות מחדש (Boot Loop). הפתרון הוא לבצע אתחול ל-Safe Mode, אשר מדלג אוטומטית על טעינת ה-AKC ומעלה רק את הקרנל הנקי של אפל, ואז להסיר את התוכנה התקולה או לבטל את אישור ה-Kext.

4. תיבול ארגוני: אבטחת ה-Firmware, ניהול מפתחות שחזור מוסדיים במצב Boot, והגבלת משתמשים מלשנות רמת אבטחה

1. High-Level Theory & History בסביבה ארגונית מנוהלת, ה-IT לא יכול לסמוך על כך שמשתמשים יכנסו ידנית למצב Recovery, ישנו הגדרות בכלי אבטחת האתחול (Startup Security Utility), ויאשרו הרחבות ליבה (Kexts) או עדכוני תוכנה כבדים. יותר מכך, הארגון לא רוצה שלמשתמשים תהיה את האפשרות לעשות זאת ללא פיקוח. בעבר, ה-IT השתמש בסיסמת Firmware (Firmware Password) במחשבי אינטל למנוע גישה לדיסקים חלופיים. ב-Apple Silicon אין יותר Firmware Password, והניהול הארגוני השקט נשען לחלוטין על שירות ה-MDM בשילוב Bootstrap Token (Bootstrap Token).

2. Deep Technical Architecture ה-Bootstrap Token הוא מנגנון הצפנה והפקדה (Escrow) קריטי. כאשר Mac עובר תהליך הרשמה (Automated Device Enrollment), הוא מייצר את האסימון ושולח אותו באופן מאובטח לשרת ה-MDM. אסימון זה משמש כמיופה כוח בעל הרשאות של "Volume Owner" מול ה-Secure Enclave.

  • ניהול Kexts ללא משתמש: כאשר ה-MDM שולח פרופיל מסוג Kernel Extension Policy, ה-macOS בודקת אם קיים Bootstrap Token תקף. אם כן, היא יכולה לאשר את ה-Kext ולבנות את ה-AKC (Auxiliary Kernel Collection) מאחורי הקלעים, מבלי לבקש מהמשתמש להיכנס ל-Recovery.
  • הגבלת רמות אבטחה: ה-MDM יכול לשלוח תצורה המונעת ממשתמשים לשנות את ה-Startup Security Utility בעצמם.
  • תחליף ל-Firmware Password: במקום סיסמת קושחה, ארגונים מסתמכים היום על תכונת Activation Lock המקושרת ל-MDM ועל מחיקה מרחוק (Remote Wipe), המגנים על המחשב מבוסס Apple Silicon כמעט באופן הרמטי במקרה של גניבה, באמצעות נעילת ה-Volume עם ה-Secure Enclave.

3. Terminal Commands, Plists & Logs

  • בדיקה האם אסימון ה-Bootstrap נתמך והופקד בהצלחה מול ה-MDM: profiles status -type bootstraptoken

  • יצירה והפקדה ידנית של Secure Token ל-MDM במקרה של כשל: sudo profiles install -type bootstraptoken

  • חקירת בקשות פרופילים מול הרחבות קרנל: profiles show | grep KernelExtensionPolicy

  • בדיקת לוגים הקשורים לפעילות ה-MDM עם האסימון: log show --predicate 'subsystem == "com.apple.ManagedClient" AND composedMessage contains "Bootstrap"' --info

4. Edge Cases & Troubleshooting אם מערכת ה-MDM מנסה לדחוף למק שדרוג מערכת מלא (Upgrade) או התקנת Kext והפקודה נכשלת שוב ושוב עם הודעת השגיאה "Authorization Required" (דרושה הרשאת Volume Owner), הבעיה נעוצה ב-Bootstrap Token. על התומך לפתוח טרמינל במק ולהריץ את פקודת profiles status -type bootstraptoken. אם הפלט מראה supported: YES, escrowed: NO, משמעות הדבר היא ששרת ה-MDM איבד או מעולם לא קיבל את המפתח הקריפטוגרפי. כדי לתקן זאת, תומך בעל הרשאות Owner במק חייב להריץ sudo profiles install -type bootstraptoken ולהקליד את סיסמתו כדי לשלוח את המפתח מחדש לשרת, מה שישחזר את היכולת לנהל את ה-Mac בצורה שקטה (Zero-Touch) מרחוק.