לדלג לתוכן

שיעור 13: תהליך האתחול

חלק ב': מדריך העברה למרצה

הערה למדריך: מסמך זה משמש כמערך השיעור (Lesson Plan) וכולל את התסריט להעברת החומר מול הכיתה, תרחישי הדגמה, ומידע טכני מורחב שיעזור לך להתמודד עם שאלות קשות. שמור על טון שיחתי (Conversational), נגיש ומעשי, כפי שהוגדר בפרוטוקול הקורס. ההדגמות מבוססות על ממשק המשתמש הגרפי (GUI) וכלי הטרמינל המקומיים במחשב עצמאי (Standalone), בעוד תרשימי ה-MDM ונעילת ה-Recovery Lock מתוך המצגת משמשים להעמקה מאחורי הקלעים.

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

🎯 מטרת החלק: להסביר את השלבים שמערכת Apple Silicon עוברת מרגע הלחיצה על כפתור ההדלקה ועד לעליית הקרנל, בדגש על שרשרת האמון (Chain of Trust) וחתימות החומרה ב-Secure Enclave.

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

← בשיעור 06 למדנו על ה-SSV (Signed System Volume) — כאן רואים כיצד ה-SSV מהווה את החוליה הסופית בשרשרת האתחול, כאשר הקרנל מוודא שהמערכת כולה חתומה וללא שינוי.

🎤 הרצאה

  • שאלת פתיחה והשוואה לעבר:
    • "במחשבי אינטל הישנים היו לנו רכיבי חומרה נפרדים: שבב BIOS/UEFI, בקר SMC לניהול חשמל ותרמי, וזיכרון NVRAM להגדרות בוט."
    • "ב-Apple Silicon הכל אוחד לתוך מעגל מודפס אחד (System on Chip - SoC) המנוהל ע"י ה-Secure Enclave."
  • שרשרת האמון שלב-אחר-שלב (Chain of Trust):
    • 1. Boot ROM (צרוב בחומרה):
      • הקוד הראשון שרץ ברגע שמקבלים זרם חשמלי.
      • נמצא בזיכרון קריאה-בלבד (Read-Only) על גבי ה-SoC ואינו ניתן לשינוי או לפריצה ע"י תוכנה.
      • מכיל את ה-Apple Root Certificate Public Key ומאמת את שלב ה-LLB.
    • 2. LLB (Low-Level Bootloader):
      • מאתחל את הזיכרון האחוד (Unified Memory) והחומרה ההיקפית הבסיסית.
      • קורא את ה-LocalPolicy השמורה ב-Secure Enclave ומאמת את קובץ ה-iBoot הבא.
    • 3. iBoot (טוען מערכת ההפעלה הראשי):
      • זהו השלב שבו מופיע לראשונה סמל התפוח ומד ההתקדמות (Loading Bar) על המסך.
      • טוען את ה-DeviceTree, מאמת את הקרנל ואת ה-Boot Arguments.
    • 4. Kernel & launchd (מערכת ההפעלה):
      • הקרנל נטען, מאמת את ה-Snapshot החתום של ה-SSV ומרכיב אותו כקובץ מערכת קרוא-בלבד (Read-Only).
      • הקרנל מפעיל את תהליך האב launchd (PID 1), אשר מקים את כל שירותי המשתמש והממשק הגרפי.
  • מה קורה אם חוליה אחת נשברת?
    • אם חתימה קריפטוגרפית אינה תואמת — תהליך האתחול נעצר מיד!
    • המק לא יציג מסך שגיאה אלא ייכנס למצב שחזור קושחה מובנה (DFU Mode) לטעינה מחודשת של ה-LLB וה-iBoot.

🔗 עזרים ויזואליים

עזר מה מראה
📸 L13_LegacySlide_Slide138_image49.jpeg דיאגרמת שרשרת האמון (Chain of Trust) ב-Apple Silicon
📸 L13_LegacySlide_Slide138_image169.png שלבי המעבר מ-Boot ROM דרך LLB ו-iBoot עד לקרנל

🖥️ הדגמה

  • שלב 1: פתחו את אפליקציית System Information (דרך תפריט התפוח > About This Mac > More Info > System Report).
  • שלב 2: בחרו בקטגוריית Hardware בראש הרשימה.
  • שלב 3: הראו לתלמידים את השדות:
    • Chip: דגם המעבד (למשל Apple M2/M3/M4).
    • System Firmware Version: גרסת ה-iBoot הצרובה כרגע במכשיר.
    • OS Loader Version: גרסת טוען המערכת הפעיל.
  • שלב 4 (בטרמינל): הריצו את הפקודה לבדיקת רכיב האתחול והאבטחה: 
    system_profiler SPiBridgeDataType
Instructor Deep-Dive: ארכיטקטורת Boot ROM, LLB ו-LocalPolicy
  • Apple Root CA: ה-Boot ROM מכיל מפתח ציבורי של אפל שאינו ניתן למחיקה. כל שדרוג גרסה נחתם פרטנית מול שרתי ה-TSS של אפל (Personalized Ticket).
  • LocalPolicy ב-SEP: לכל מחיצת מערכת ב-Apple Silicon יש קובץ LocalPolicy מוצפן ב-Secure Enclave. ה-LLB קורא מדיניות זו כדי לקבוע אם לאפשר אתחול ב-Full Security או ב-Reduced Security.
  • ביטול קיצורי המקלדת המסורתיים: ב-Apple Silicon אין יותר איפוס PRAM (Cmd+Opt+P+R) או אתחול בטוח באמצעות מקש Shift בעת ההדלקה — כל אפשרויות האתחול רוכזו לתוך לחיצה ממושכת אחת על כפתור ההפעלה (1TR).

2. כלי אבטחת האתחול (Startup Security Utility) ורמות האבטחה (Full Security מול Reduced Security)

🎯 מטרת החלק: להדגים כיצד פועל מנגנון ה-Startup Security Utility ב-Recovery Mode, להבין את המשמעויות של שינוי מדיניות האבטחה (Security Policy), ומתי טכנאי או משתמש נדרשים להוריד את רמת האבטחה.

עכשיו כשהתלמידים מבינים איך המערכת עולה בצורה בטוחה, נציג כיצד שולטים ברמת האבטחה. הדגישו שהורדת אבטחה ל-Reduced Security אינה "פריצה של המק", אלא העברת הסמכות לקבלת החלטות מאפל למנהל המקומי של המחשב (Volume Owner).

← בשיעור 04 למדנו על ה-Volume Ownership וה-Secure Token — כניסה ל-Startup Security Utility מחייבת הזנת סיסמה של משתמש בעל Secure Token (Volume Owner).

🎤 הרצאה

  • איך מגיעים ל-Startup Security Utility ב-Apple Silicon?
    • מכבים את המחשב לחלוטין.
    • מבצעים לחיצה ממושכת (Long Press) על כפתור ההפעלה (Touch ID) עד שמופיע הכיתוב Loading startup options.
    • בוחרים ב-Options ונכנסים למסך ה-1TR.
    • בתפריט העליון בוחרים ב-Utilities > Startup Security Utility.
  • רמות האבטחה (Security Levels):
    • 1. Full Security (ברירת המחדל):
      • רמת האבטחה הגבוהה ביותר המגיעה מהמפעל (בדומה ל-iOS).
      • מתירה הרצה אך ורק של גרסת מערכת ההפעלה הנוכחית והמאושרת ביותר ע"י אפל.
      • דורשת אימות מקוון מול שרתי ה-TSS בעת התקנה כדי למנוע התקפות Rollback (הורדת גרסה למערכת ישנה עם פרצות אבטחה ידועות).
    • 2. Reduced Security (אבטחה מופחתת):
      • מאפשרת הרצת כל גרסת macOS ישנה שאי-פעם נחתמה ע"י אפל (גם אם החתימה פגה).
      • פותחת שתי תיבות סימון (Checkboxes) קריטיות:
        1. Allow user management of kernel extensions from identified developers: מאפשרת למנהלים מקומיים לאשר דרייברים ברמת הליבה (Kexts).
        2. Allow remote management of kernel extensions and automatic software updates: מאפשרת לשרת MDM לנהל Kexts ועדכונים ברקע באמצעות ה-Bootstrap Token.
    • 3. Permissive Security (רמה מוסתרת למפתחים):
      • ביטול מוחלט של בדיקות חתימה להרצת קרנל מותאם אישית (Custom Kernel) דרך כלי הפקודה bputil.

🔗 עזרים ויזואליים

עזר מה מראה
📸 L13_LegacySlide_Slide141_image170.jpg חלון ה-Startup Security Utility ובחירת כונן המערכת
📸 L13_LegacySlide_Slide142_image171.png הגדרות ה-Reduced Security ותיבות הסימון של Kexts

🖥️ הדגמה

  • שלב 1 (בדיקת רמת אבטחה בטרמינל):
    • הריצו בטרמינל: 
      system_profiler SPiBridgeDataType | grep -A 5 "Secure Boot"
    • הראו כי תחת Secure Boot מופיע הערך Full Security.
  • שלב 2 (הסבר על מסך ה-Recovery):
    • הקרינו את צילום המסך L13_LegacySlide_Slide141_image170.jpg והסבירו את תהליך הכניסה ל-1TR.
    • הצביעו על שתי תיבות הסימון תחת Reduced Security והסבירו מדוע כל איש תמיכה שמחבר כרטיס קול חיצוני ישן או תוכנת וירטואליזציה נתקל במסך הזה.
Instructor Deep-Dive: מנגנון ה-TSS Signing וה-APTicket
  • Tatsu Signing Server (TSS): בעת התקנה במצב Full Security, המק שולח בקשה הכוללת את ה-ECID הייחודי שלו. השרת מחזיר קובץ APTicket חתום קריפטוגרפית.
  • בידוד פר ווליום: ב-Apple Silicon, ניתן להתקין 3 גרסאות שונות של macOS ב-Containers שונים, כאשר ווליום אחד מוגדר ב-Full Security והשני ב-Reduced Security — לכל כרך יש LocalPolicy עצמאי ב-Secure Enclave!
  • אישור מנהל (Volume Owner): כל שינוי ב-Startup Security Utility דורש בחירת משתמש אדמין מקומי והקשת סיסמתו כדי לחתום על המדיניות החדשה.

3. הרחבות ליבה (Kexts) מול System Extensions ואיך מתקינים אותן ב-macOS מודרני

🎯 מטרת החלק: להסביר מדוע אפל חוסמת בהדרגה הרחבות ליבה (Kernel Extensions), כיצד ה-System Extensions פותרות את בעיית היציבות והאבטחה, ומהו תהליך ההתקנה המדויק של Kext במק מודרני.

רוב אנשי ה-IT הותיקים סובלים מהנושא של Kexts, כיוון שההתקנה הפכה למורכבת במכוון. המטרה כאן היא להסביר את ה"למה" – מדוע אפל מקשה על התקנת Kexts, כיצד הרחבות ב-User Space מונעות קריסות פתאומיות (Kernel Panics), ואיך טכנאי מתמודד עם תוכנה ישנה שעדיין דורשת Kext.

← בשיעור 08 (System Services) למדנו על תהליכים ב-User Space מול System Space — כאן רואים את אותו עיקרון מיושם על דרייברים.

🎤 הרצאה

  • מדוע אפל "הורגת" את ה-Kexts המסורתיים?
    • הבעיה היסטורית (Ring 0 / Kernel Space):
      • הרחבות קרנל רצות ישירות בתוך ליבת מערכת ההפעלה עם הרשאות בלתי מוגבלות.
      • כל באג קטן, דליפת זיכרון או שגיאת קוד בדרייבר של חברה חיצונית — מוביל מיד לקריסה טוטאלית של המק (Kernel Panic).
      • סכנת אבטחה: קוד זדוני שחודר לקרנל יכול לעקוף כל הגנת אבטחה (כולל SIP ו-TCC).
  • הפתרון המודרני: System Extensions (Ring 3 / User Space):
    • הדרייברים ותוכנות האבטחה רצים ב-User Space כתהליכים מבודדים (Sandbox).
    • אם האפליקציה או הדרייבר קורסים — מערכת ההפעלה ממשיכה לעבוד כרגיל ללא שום הפרעה!
    • 3 סוגי ה-System Extensions המרכזיים:
      1. Driver Extensions (DriverKit): דרייברים לחומרה חיצונית (כרטיסי קול, התקני USB, בקרי תקשורת).
      2. Network Extensions: תוכנות VPN, חומות אש (Firewalls) ומסנני תוכן.
      3. Endpoint Security Extensions: תוכנות אנטי-וירוס ו-EDR ארגוניות (CrowdStrike, SentinelOne).
  • סולם המכשולים: תהליך התקנת Kext במק מודרני (צעד-אחר-צעד):
      1. אתחול פיזי ל-1TR (לחיצה ארוכה על Power).
      1. כניסה ל-Startup Security Utility והורדה ל-Reduced Security.
      1. סימון תיבת האישור: Allow user management of kernel extensions from identified developers.
      1. אתחול רגיל למערכת והפעלת קובץ ההתקנה.
      1. אישור התרעת המערכת ב-System Settings > Privacy & Security תחת Security (לחיצה על Allow לצד שם המפתח).
      1. אתחול נוסף של המק — בשלב זה iBoot בונה את ה-Auxiliary Kernel Collection (AKC) וטוען את הדרייבר בבוט.

🔗 עזרים ויזואליים

עזר מה מראה
📸 L13_LegacySlide_Slide142_image172.png התראת System Extension Blocked ב-macOS
📸 L13_LegacySlide_Slide142_image174.png חלון אישור מפתח יצרן ב-Privacy & Security
📸 L13_LegacySlide_Slide142_image176.png מסך בנייה מחדש של ה-AKC בעת אתחול

🖥️ הדגמה

  • שלב 1 (בדיקת הרחבות ב-System Information):
    • פתחו את System Information > נווטו בתפריט הצדדי ל-Software > Extensions.
    • מיינו לפי עמודת Loaded והראו הרחבות פעילות (Loaded: Yes).
  • שלב 2 (חקירת תיקיית ההרחבות ב-Finder):
    • הקישו Cmd+Shift+G ב-Finder ונווטו אל /Library/Extensions.
    • הסבירו: "כאן יושבים קבצי ה-Kext של צד שלישי (אם הותקנו). בתיקיית /System/Library/Extensions יושבות הרחבות אפל המוגנות ב-SSV".
  • שלב 3 (בדיקת הרחבות בטרמינל עם kmutil):
    • הריצו את הפקודה המודרנית המציגה הרחבות צד שלישי שאינן של אפל: 
      kmutil showloaded --show-all | grep -v "com.apple"
Instructor Deep-Dive: ארכיטקטורת ה-AKC וכלי ה-kmutil
  • Auxiliary Kernel Collection (AKC): ב-Apple Silicon, הרחבות Kext אינן מוזרקות ישירות לזיכרון בזמן ריצה. המערכת מקמפלת אותן מראש לתוך קובץ אימג' אחוד (AKC) הנשמר ב-Preboot ונחתם ע"י ה-LocalPolicy.
  • כלי ה-CLI המודרני kmutil: החליף את הכלים ההיסטוריים kextstat, kextload ו-kextunload.
  • אבטחת Kext Consent: פקודת spctl kext-consent status בטרמינל מציגה האם מנגנון אישור ה-Kexts מאופשר ברמת המערכת.

4. תיבול ארגוני: אבטחת ה-Firmware, ה-Recovery Lock ב-Apple Silicon וה-Bootstrap Token

🎯 מטרת החלק: להבין את מנגנון ה-Recovery Lock הבלעדי ל-MDM ב-Apple Silicon (כיורש הארגוני של ה-Firmware Password), לדעת כיצד הוא חוסם לחלוטין גישה פיזית ל-1TR, וכיצד ה-Bootstrap Token מאפשר ניהול שקט של רמות אבטחה מרחוק.

זהו החלק שבו אנשי ה-IT בכיתה מתחברים למציאות היומיומית שלהם. הדגישו את ההבדל הדרמטי בין מחשבי אינטל למחשבי Apple Silicon: בעבר כל לקוח פרטי יכול היה לשים Firmware Password. כיום, נעילת ה-Recovery קיימת אך ורק דרך MDM ארגוני (Recovery Lock) ולא זמינה כלל ללקוחות פרטיים!

← בשיעור 04 ובשיעור 12 ראינו כיצד ה-Bootstrap Token פועל כמיופה כוח של Volume Owner — כאן רואים כיצד הוא מאפשר ל-MDM לאשר שינויי אבטחה ועדכונים שקטים ברקע.

🎤 הרצאה

  • שאלת פתיחה: מה קרה ל-Firmware Password הישן?
    • "במחשבי אינטל הישנים — מי יכל להגדיר Firmware Password? כולם! כל לקוח פרטי יכל להיכנס ל-Recovery ולהגדיר סיסמה מקומית."
    • "ב-Apple Silicon אפל ביטלה לחלוטין את ה-Firmware Password המקומי. לקוח פרטי עצמאי אינו יכול לנעול את ה-Recovery כלל!"
  • היורש האמיתי: Recovery Lock (SetRecoveryLockCommand):
    • פיצ'ר ארגוני בלעדי למערכות MDM!
    • מנהל ה-IT שולח פקודת SetRecoveryLock מתוך קונסולת הניהול (Jamf / Intune), והסיסמה נשמרת באופן מוצפן (Escrow) בכרטיס המכשיר בשרת.
  • מה קורה כשמוגדר Recovery Lock על המק?
    • כאשר משתמש או טכנאי מחזיק את כפתור ההפעלה כדי להיכנס ל-1TR (Startup Options), המק מקפיץ מסך שחור עם סמל מנעול המחייב את סיסמת ה-MDM.
    • חסימה הרמטית: ללא הסיסמה הזו, המשתמש (אפילו אם הוא Admin מקומי או Volume Owner ב-macOS!) חסום לחלוטין מ:
      1. פתיחת ה-Terminal במצב Recovery.
      2. גישה ל-Startup Security Utility (חסום מהורדת אבטחה ל-Reduced Security או אישור Kexts).
      3. הפעלת Disk Utility לפרמוט הכונן או איפוס המחשב.
  • אישור Kexts שקט בעזרת ה-Bootstrap Token:
    • פרופילי MDM מסוג Kernel Extension Policy מאפשרים ל-MDM לאשר Kexts ארגוניים ברקע בעזרת ה-Bootstrap Token, ללא צורך בהגעה פיזית של העובד למסך ה-1TR.

🔗 עזרים ויזואליים

עזר מה מראה
📸 L13_LegacySlide_Slide80_image19.jpg ארכיטקטורת אבטחת Firmware ופרופילי אבטחה בארגון
📸 L13_LegacySlide_Slide80_image93.png מסך נעילת Recovery Lock והפקדת מפתחות ב-MDM

🖥️ הדגמה

  • שלב 1 — בדיקת Secure Boot ו-SIP במק המקומי (ב-CLI):
    • הריצו בטרמינל: 
      system_profiler SPiBridgeDataType | grep -A 5 "Secure Boot"
    • הריצו: csrutil status כדי לאמת שה-System Integrity Protection מופעל.
  • שלב 2 — בדיקת סטטוס ה-Bootstrap Token:
    • הריצו בטרמינל: 
      sudo profiles status -type bootstraptoken
    • דגש פדגוגי מנצח למרצה: הצביעו על הפלט המציג escrowed: NO. הסבירו לכיתה: "רואים? המחשב שבו אנחנו לומדים הוא מחשב עצמאי (Standalone) שאינו מנוהל ב-MDM, ולכן לא הופקד מפתח. במחשב ארגוני המשויך ל-MDM, השורה הזו מציגה YES!".
  • שלב 3 — המלצה פדגוגית למרצה (עזרים ויזואליים):
    • הקרינו מתוך העזרים הוויזואליים של השיעור (שקף L13_LegacySlide_Slide80_image93.png) את צילום המסך של פקודת Set Recovery Lock ב-MDM ואת מסך המנעול השחור שננעל בפני משתמש שמנסה להיכנס ל-1TR.
Instructor Deep-Dive: פקודות MDM ל-Recovery Lock ו-LocalPolicy
  • פקודות ניהול ב-MDM:
    • הגדרת סיסמה: SetRecoveryLockCommand.
    • אימות מרחוק: VerifyRecoveryLockPasswordCommand.
    • הסרת נעילה בעת עזיבת עובד: ClearRecoveryLockCommand.
  • אי-תלות ב-FileVault: ה-Recovery Lock מגן על סביבת ה-1TR גם אם ה-FileVault כבוי או מבוטל, ומונע מכל אדם עם גישה פיזית לשנות את הגדרות האתחול של המק.
  • אכיפת Full Security ב-LocalPolicy: שרת ה-MDM יכול לכפות Full Security ולמנוע מכל מנהל מקומי להוריד את רמת האבטחה דרך כלי ה-GUI.

עזרים ויזואליים

המחשה ויזואלית (עזר לתלמיד)

תמונות אלו ממחישות את הממשק או המנגנון הרלוונטי לנושא השיעור.

Slide138_image169 Slide138_image49 Slide141_image170 Slide142_image171 Slide142_image172 Slide142_image173 Slide142_image174 Slide142_image175 Slide142_image176 Slide142_image177 Slide80_image19 Slide80_image93