לדלג לתוכן

Chapter 06: APFS Internals - Asset A (Instructor Reference)

1. מהפיכת APFS: Containers (Containers) לעומת Volumes (Volumes). שיתוף שטח דינמי.

High-Level Theory & History

המעבר ממערכת הקבצים המיושנת HFS+ ל-APFS (Apple File System) היווה את אחת מנקודות המפנה המשמעותיות ביותר בארכיטקטורה של מק. APFS נבנתה מאפס כדי לייעל עבודה עם כונני Flash (SSD), והיא הציגה פרדיגמה חדשה לניהול אחסון. במקום לחלק את הדיסק הפיזי למחיצות קשיחות מראש, APFS מבוססת על Containers המכילות בתוכן Volumes . הקונספט החשוב ביותר כאן הוא "שיתוף שטח דינמי" (Space Sharing): כל Volume בתוך ה-Container חולק את אותו מאגר אחסון פנוי. בניגוד לעבר, אין צורך להקצות שטח מוגדר מראש לכל Volume, והם יכולים לגדול ולהתכווץ באופן טבעי לפי כמות המידע שעליהם.

Deep Technical Architecture

ברמת הארכיטקטורה, ה-Container מתפקד כשכבת האבסטרקציה העיקרית מול החומרה, והוא זה שמאגד בתוכו את בלוקי האחסון הפנויים. כל Volume בתוך ה-Container מיוצג במערכת הקבצים העצמאית שלו, אך ברמת הבלוקים הפיזיים הם מצביעים לאותו חלל בדיסק. בנוסף, APFS מבוססת על מנגנון Copy-on-Write (CoW). משמעות הדבר היא ששכפול קובץ לא מעתיק את המידע (Data) אלא רק משכפל את ההפניה (Pointer) במטא-דאטה. שטח נוסף ייתפס רק כאשר תתבצע כתיבה או שינוי (Write) באחד מהעותקים. תכונה זו מאפשרת פעולות של שכפול ויצירת Snapshot להתרחש באופן כמעט מיידי וללא בזבוז שטח מיותר.

Terminal Commands, Plists & Logs

כדי לראות את מבנה ה-Container וה-Volumes, נשתמש בפקודות הבאות: diskutil list – הצגה כללית של הדיסקים הפיזיים והווירטואליים. diskutil apfs list – צלילה עמוקה לתוך הארכיטקטורה של APFS, מציג את ה-Containers (Containers), את ה-Volumes (Volumes) שבתוכן, ואת מצבם הקריפטוגרפי. df -h – צפייה בניצול שטח האחסון (אם כי בפלט זה קשה יותר להבין את השיתוף הדינמי). שאילתת לוג רלוונטית למעקב אחרי פעולות כתיבה ושגיאות של APFS: log show --predicate "subsystem == 'com.apple.apfs'" --last 1h

Edge Cases & Troubleshooting

מצב קצה נפוץ הוא שגיאות בתצוגת המקום הפנוי. משתמשים עשויים למחוק קבצים כבדים מה-Volume, אך כלי בדיקת המקום (כמו ה-Finder או df) יראו שהמקום לא התפנה. לרוב זה קורה מכיוון שקיימת Snapshot מקומית ב-APFS שנועלת את הבלוקים למקרה של שחזור. הפתרון הוא לאתר את ה-Snapshot (לרוב של Time Machine) ולמחוק אותו ידנית באמצעות tmutil listlocalsnapshots / ו-tmutil deletelocalsnapshots. תרחיש נוסף הוא שגיאות במטא-דאטה של ה-Container הדורשות הרצת First Aid מתוך ה-Disk Utility ב-Recovery Mode.

High-Level Theory & History

החל מ-macOS Catalina, אפל פיצלה את הדיסק הראשי לשני Volumes נפרדים: אחד עבור המערכת ואחד עבור המשתמש. עם יציאת macOS Big Sur והלאה, הצעד הזה הוקשח לכדי מנגנון הנקרא Sealed System Volume (SSV). Volume המערכת (System Volume) הוא כעת סגור, לקריאה בלבד (Read-Only) וחתום קריפטוגרפית. המטרה היא להבטיח ששום תוכנה זדונית או תקלה לא תוכל לשנות את קבצי הליבה של macOS. קבצי המשתמש, האפליקציות שהותקנו וההגדרות נשמרים ב-Data Volume. כדי לשמור על האשליה שמדובר בכונן יחיד (כפי שהמשתמש רואה ב-Finder), אפל המציאה מנגנון בשם Firmlinks.

Deep Technical Architecture

מנגנון ה-SSV מבוסס על מבנה נתונים מסוג עץ מרקל (Merkle Tree). כל קובץ ב-Volume המערכת עובר גיבוב (Hash), והגיבובים נאספים עד לשורש העץ, שם הם נחתמים באמצעות חותמת קריפטוגרפית מטעם אפל (ה-Seal). במהלך ה-Boot Process, מעבד ה-Apple Silicon מוודא שהחותמת תקפה. אם נמצא שינוי קל שבקלים (ביט בודד ששונה), המערכת תסרב לעלות. Firmlink (Firmlink) הוא לינק דו-כיווני עמוק ברמת ה-VFS (Virtual File System) המגשר בצורה שקופה בין תיקיות ב-System Volume (כמו /Users) לבין המיקום הפיזי שלהן ב-Data Volume. בניגוד ל-Symlink שפועל רק בשכבת מערכת הקבצים העליונה, Firmlink מאפשר לכל תהליך לטייל מעלה ומטה בעץ התיקיות מבלי להיות מודע לכך שהוא חוצה בין שני Volumes שונים.

Terminal Commands, Plists & Logs

בדיקת סטטוס החתימה (Seal) מתבצעת באמצעות הפקודה: diskutil apfs list – יש לחפש את השורה "Sealed: Yes" תחת ה-System Volume. ניתן לראות את רשימת הפירמלינקים (Firmlinks) המוגדרים במערכת על ידי קריאת הקובץ: cat /usr/share/firmlinks קובץ זה מציג אילו תיקיות ממופות בין ה-Volumes. (לדוגמה: /Users ממופה ל-Data/Users). כדי לראות את הנתיב האמיתי של הקבצים ב-Data Volume, ניתן לגשת אל: /System/Volumes/Data/.

Edge Cases & Troubleshooting

במידה וה-SSV נשבר (כלומר, ה-Seal אינו תקף), המק יסרב לאתחל את מערכת ההפעלה ויכנס ישירות ל-Recovery Mode עם דרישה להתקנה מחדש או עדכון תוכנה כדי להוריד את קבצי המערכת התקינים בחזרה אל המחשב. תיקון של SSV פגום אפשרי רק על ידי הרצת התקנת macOS מחודשת על גבי הכונן, שכן התהליך בונה מחדש את עץ התיקיות וחותם אותו מול שרתי אפל. כל ניסיון לכתוב ידנית אל System Volume על ידי ביטול SIP יגרור אי-התאמה בחתימה, אלא אם כן המחשב עבר למצב אבטחה Permissive, דבר שכמובן אינו מומלץ או רלוונטי לרוב סביבות הפרודקשן.

3. מעבדה: תרגולי אבחון מקום פנוי, הבנת עץ התיקיות, ומערך הפקודות של diskutil.

High-Level Theory & History

חלק זה מתמקד בהיכרות מעשית עם כלי העבודה המרכזיים לניהול ואבחון אחסון ב-macOS. מאחר והמעבר ל-APFS שינה את המבנה הלוגי מקצה לקצה, טכנאי IT חייבים לשלוט לא רק ב-Disk Utility הגרפי, אלא בראש ובראשונה בכלי ה-CLI העוצמתי diskutil. הבנת עץ התיקיות המודרני, על הפיצול בין ה-Data Volume ל-System Volume והכרת ה-Volumes הנסתרים (כמו Preboot, Recovery ו-VM), הם בגדר ידע חובה לפני ביצוע כל פעולת שחזור או פרמוט.

Deep Technical Architecture

הפקודה diskutil מתממשקת מול ה-Daemon שנקרא diskarbitrationd. תהליך זה אחראי על חיבור, ניתוק, ניהול ותשאול של כל התקני האחסון המחוברים למק (Local ו-Network). כשאנו מריצים diskutil list, אנו רואים מעבר לשני כרכי המשתמש גם Volumes תומכים קריטיים שמוסתרים מעיניו ב-Finder: ה-Preboot המחזיק את הנתונים הקריפטוגרפיים הדרושים לעליית המערכת ולתהליך פתיחת הצפנת FileVault לפני טעינת ה-OS; ה-Recovery המאחסן את הכלים הנדרשים למצב ההתאוששות (1TR); וה-VM (Virtual Memory) המאחסן את קבצי ה-Swap שנוצרים בזמן אמת כשה-Unified Memory מלא.

Terminal Commands, Plists & Logs

דוגמאות לפקודות מעבדה לניהול דיסקים וחיפוש מידע מדויק: יצירת Volume חדש ושותף ב-Container הקיים (במקום לבזבז מקום על מחיצה חדשה): diskutil apfs addVolume disk3 APFS "SharedData" מחיקת Volume ספציפי: diskutil apfs deleteVolume disk3s5 קבלת מידע נרחב על כונן בודד (כולל סטטוס הצפנה וזיהוי פנימי): diskutil info /dev/disk3s1 מעקב בזמן אמת אחרי אירועי עגינת דיסקים (Disk Arbitration) בלוג: log show --predicate "subsystem == 'com.apple.DiskArbitration'" --last 10m

Edge Cases & Troubleshooting

טעות נפוצה של משתמשים וטכנאים בעלי ניסיון מיושן היא לנסות להקצות שטח חדש להתקנת מערכת הפעלה נוספת על ידי יצירת Partition חדש, דבר אשר יוצר Container שני ומבודד (מצב שאינו מאפשר Dynamic Space Sharing). במעבדה נתרגל כיצד להוסיף Volume בלבד ל-Container הקיים. כמו כן, במידה ותהליך ה-Mounting כשל והכונן אינו עולה אל שולחן העבודה, לעיתים התקלה נעוצה ב-fsck_apfs שרץ ברקע ומנסה לתקן את הכונן. הפסקה אלימה של תהליך זה עלולה להשחית את נתוני הכונן ללא היכר, ולכן יש לבדוק בלוגים או ב-Activity Monitor האם סריקת תיקון רצה ברקע לפני גישה לניתוק הכבל.

4. תיבול ארגוני: השפעת ה-SSV על כלי ניהול צד-שלישי ואנטי-וירוסים של הארגון.

High-Level Theory & History

בעבר, תוכנות אבטחה ארגוניות (EDR/Antivirus) וכלי ניהול (Agents) נהגו להשתיל קבצים פנימיים עמוק בתוך תיקיות המערכת, ולעיתים אף לטעון קוד אל תוך הליבה באמצעות Kernel Extensions (Kexts). כניסת ה-Sealed System Volume טרפה את הקלפים והפכה את עולמם של מפתחי התוכנות הארגוניות. ה-System Volume נעול כעת באופן שלא מאפשר כתיבה, גם לא עם הרשאות ה-Root או פריבילגיות של MDM. עקב כך, הארגון נדרש לוודא שכל הכלים בהם הוא משתמש נבנו מחדש לעבודה עם הסביבה החדשה של מערכת ההפעלה.

Deep Technical Architecture

כתוצאה מחסימת גישת הכתיבה לליבת המערכת ול-SSV, סוכני ניהול ואנטי-וירוסים מותקנים היום על ה-Data Volume (בנתיבים כמו /Library/Extensions או /Applications). כדי להמשיך לספק הגנה עמוקה, הם משתמשים בממשק העדכני של אפל - Endpoint Security Framework (ESF) וב-System Extensions. גישה זו מאפשרת לתוכנת צד-שלישי לעקוב אחר אירועי מערכת ברמת המרחב של המשתמש (User Space), לקבל דיווח על גישה לקבצים ושינויי רשת מבלי צורך לגשת לקרנל ישירות. בנוסף, חתימת ה-SSV מבטיחה למנהלי ה-IT שאפילו במקרה של מתקפת כופר, קבצי מערכת ההפעלה הבסיסיים תמיד יישארו מוגנים ושלמים, ורק המידע שב-Data Volume ייחשף לשינויים.

Terminal Commands, Plists & Logs

ניהול ומעקב אחרי ה-System Extensions המריצים כלים אלו: systemextensionsctl list – הצגת כל הרחבות המערכת המותקנות כרגע מטעם תוכנות הארגון. חיפוש אירועים חריגים או דיווחים של מערכת Endpoint Security ב-Console: log show --predicate 'subsystem == "com.apple.endpointsecurity"' --last 24h N/A לנתיבי Plist במערכת ההפעלה שכן הכלים נכתבים חיצונית לסביבות ה-Data.

Edge Cases & Troubleshooting

מקרה קצה מרכזי מתרחש כאשר מנסים לפרוס בארגון תוכנת אבטחה ישנה (Legacy) שמנסה לכתוב לתיקיות כמו /usr/bin או להשתמש ב-Kext מיושן. התקנה כזו תיכשל בשקט או תציג שגיאה גנרית, והסוכן הארגוני לא יעלה לרשת. הפתרון במצב כזה הוא לאשרר מראש את ההרשאות הדרושות ל-System Extension העדכני של הכלי באמצעות Configuration Profile (Configuration Profile דרך MDM). Payload כזה ידריך את ה-Gatekeeper ואת ה-TCC להעניק לאפליקציה את כל הזכויות והרשאות הגישה מראש ללא התערבות המשתמש (Zero-Touch Deployment).