לדלג לתוכן

Asset A: Instructor Reference - פרק 3 (Security & TCC)

מסמך זה מהווה את ה-"Book-Book" (מדריך עומק טכני למדריך) עבור פרק 3. המסמך מרחיב לעומק על כל אחד מסעיפי הסילבוס במבנה קבוע של ארבעה חלקים, תוך שמירה על הכלל של 80% ארכיטקטורת מערכת ההפעלה המקומית ו-20% השפעות והגבלות של סביבה ארגונית (MDM).

1. הגן הסגור: מנגנון ה-Gatekeeper, חתימות ונוטריון (Notarization)

High-Level Theory & History

מנגנון ה-Gatekeeper נולד כדי לפתור את אחת הבעיות הגדולות ביותר של מחשוב אישי חופשי: הרצת קוד זדוני ללא ידיעת המשתמש. בעבר, כל קובץ שהורד מהאינטרנט היה יכול לרוץ בחופשיות. כיום, הגישה של Apple מחמירה בהרבה, ומבוססת על מודל אמון מחמיר (Trust Model). כאשר אפליקציה מורדת מחוץ ל-App Store, ה-Gatekeeper נכנס לפעולה בטרם ההרצה הראשונה. הוא מוודא שלושה דברים מרכזיים: שהאפליקציה חתומה על ידי מפתח מוכר (Developer ID), שהקוד שלה עבר תהליך סריקה אוטומטי במזרקות של Apple הידוע בשם Notarization (שמוודא כי אין נוזקות מוכרות בתוך הקוד בטרם שחרורו), ושהקוד לא עבר שום מודיפיקציה או שיבוש (Tampering) מאז שנחתם.

Deep Technical Architecture

התהליך מתחיל ברגע שאפליקציה פוגשת את מערכת הקבצים, בדרך כלל בעקבות הורדה דרך דפדפן (כמו Safari) או תוכנת מסרים. האפליקציה המורידה מצמידה לקובץ תגית מטא-דאטה מיוחדת בשם com.apple.quarantine (Extended Attribute). כאשר המשתמש מנסה להפעיל את הקובץ, תהליך בשם syspolicyd מזהה את התגית הזו וחוסם את ההרצה עד לסיום תהליך אימות קריפטוגרפי. ה-Gatekeeper בוחן את עץ החתימות מול שרתי Apple כדי לוודא שאישור המפתח (Certificate) לא נשלל, ואת סטטוס ה-Notarization של הקוד (אשר לרוב מוטמע מראש בתוך האפליקציה (Stapled) כדי לאפשר התקנה גם ללא אינטרנט). בנוסף, מנגנון אבטחה בשם App Translocation נכנס לפעולה ומעביר באופן אקראי את האפליקציה לתיקייה זמנית ונסתרת (Read-Only) בזמן הריצה הראשונה, מה שמונע מאפליקציה זדונית לטעון קבצי עזר (Plug-ins) מתוך התיקייה שבה היא הורדה (למשל, מתוך תיקיית Downloads).

Terminal Commands, Plists & Logs

הניהול המקומי של Gatekeeper מבוצע בעיקר באמצעות הפקודה spctl (System Policy Control).

  • בדיקת אבחון של אפליקציה והחתימה שלה לפני הרצה: spctl -a -vv /Applications/AppName.app

  • הסרת תגית ההסגר (Quarantine) באופן ידני במידה ורוצים לעקוף את מנגנון האזהרה: xattr -d com.apple.quarantine /path/to/AppName.app

  • חיפוש לוגים על חסימות שביצע ה-Gatekeeper מבוצע בעזרת מערכת ה-Unified Logging: log show --predicate 'subsystem == "com.apple.syspolicy"' --info --last 1h

Edge Cases & Troubleshooting

מקרה קצה נפוץ הוא שה-Gatekeeper חוסם אפליקציה לגיטימית משום שהמפתח לא ביצע לה Notarization כהלכה, או שתעודת המפתח פגה. המשתמש יקבל שגיאה בנוסח "App is damaged and can't be opened" או ש"אינה ממקור מזוהה". הפתרון הרשמי הוא לבקש מהמשתמש לגשת ל-System Settings -> Privacy & Security ולאשר ידנית את האפליקציה דרך כפתור "Open Anyway". פתרון עוקף נוסף הוא לחיצה ימנית (Control-Click) על האפליקציה ובחירה ב-Open, מה שפותח חלון התראה המאפשר להריץ אותה תוך רישום חריגה (Exception) ב-Gatekeeper לפעמים הבאות. מקרה נוסף הוא כש-App Translocation מתערב ושובר אפליקציות שמצפות שקבצי הרישיון שלהן יהיו באותה תיקייה. כדי לשבור את ה-Translocation, לרוב מספיק פשוט להזיז את האפליקציה ידנית מתיקיית Downloads אל תיקיית /Applications לפני שמפעילים אותה.

2. האנטי-וירוס השקט: איך XProtect ו-XProtect Remediator עובדים ברקע

High-Level Theory & History

בניגוד לדימוי ההיסטורי של מחשבי Mac כחסינים לווירוסים, Apple פיתחה לאורך השנים מערך הגנה רב-שכבתי. השכבה השקטה ביותר היא XProtect, הפועלת מאחורי הקלעים ללא ממשק משתמש גלוי. XProtect בנוי משני רכיבים עיקריים: מנוע המניעה (XProtect), שסורק כל קובץ בעת ההרצה הראשונה שלו או לאחר שינוי במערכת הקבצים בניסיון לאתר חתימות זדוניות, וה-XProtect Remediator, רכיב אקטיבי שפועל ברקע ומבצע סריקות תקופתיות לאיתור נוזקות מוכרות שכבר חדרו למערכת ולביצוע פעולות תיקון והסרה (Remediation). המערכת מתעדכנת עצמאית, בנפרד מעדכוני מערכת ההפעלה הגדולים.

Deep Technical Architecture

הארכיטקטורה מבוססת על חוקי YARA (Yet Another Recursive Acronym), שהם תקן תעשייתי להגדרת תבניות סריקה לאיתור נוזקות. החל מ-macOS Sequoia, המבנה של XProtect עבר מהפכה שקטה. בעוד שבעבר הקבצים ישבו תחת CoreServices, כיום המיקום הראשי (Primary) של חבילת הנתונים עבר ל-/var/protected/xprotect/XProtect.bundle, מיקום מוגן הקורא עדכונים בצורה תכופה הרבה יותר (פעמים רבות ביום) דרך שירותי CloudKit, תוך עקיפת מנגנון ה-Software Update הישן. אם ה-bundle המוגן ריק (למשל לאחר שדרוג מערכת), המערכת מסתמכת זמנית על עותק משני תחת CoreServices. תהליך העדכון (XProtect Update Service) דוגם את הענן של Apple ומוודא שהרולים הקריפטוגרפיים מעודכנים ביותר. תהליכי ה-Remediator מנוהלים על ידי קבצי launchd שונים שמתעוררים באופן יזום ברקע (על פי לוחות זמנים רנדומליים חלקית) כדי לסרוק את הזיכרון ומערכת הקבצים.

Terminal Commands, Plists & Logs

ב-macOS Sequoia התווסף כלי CLI ייעודי בשם xprotect לשליטה במערך (שמחליף את השימוש בפקודת softwareupdate לעניין זה):

  • בדיקת גרסת ה-XProtect הנוכחית המותקנת במיקום הראשי: xprotect version

  • בדיקה מול הענן האם קיימים עדכונים זמינים ללא התקנה: sudo xprotect check

  • כפיית התקנה של העדכון האחרון מ-iCloud: sudo xprotect update

  • נתיב האפליקציה המבצעת את הסריקות האקטיביות (Remediator): /Library/Apple/System/Library/CoreServices/XProtect.app

Edge Cases & Troubleshooting

תקלות מתרחשות לעיתים כאשר ה-Mac לא מצליח לתקשר עם שרתי iCloud לצורך משיכת עדכוני YARA חדשים, במיוחד ברשתות ארגוניות חסומות (Proxies/Firewalls) שלא מתירות תעבורה לשרתי CloudKit ספציפיים. במקרה כזה, הפקודה xprotect check עשויה להחזיר שגיאת רשת, או שהסריקות ייעצרו לחלוטין. במקרים נדירים, מסד הנתונים של XProtect עשוי להיתקע ולהחזיר גירסה 0 במיקום הראשי, מה שמעיד על חסר. כלי פיתוח חיצוניים (כמו XProCheck) יכולים לזהות זאת כשהם מנסים לקרוא את לוג המערכת ולא מוצאים דיווח על סריקות ביממה האחרונה. הפתרון המהיר הוא הרצת sudo xprotect update ווידוא תקשורת לאינטרנט.

3. ניהול פרטיות (TCC): איך מערכת TCC פועלת ומגבילה גישה למצלמה/מיקרופון/דיסק

High-Level Theory & History

מערכת TCC (Transparency, Consent, and Control) מהווה את חומת המגן של פרטיות המשתמש ב-macOS. היא נועדה להבטיח שאף תוכנה לא תוכל לגשת למידע אישי רגיש (כמו מצלמה, מיקרופון, מיקום, או תיקיית המסמכים) ללא אישור והסכמה מפורשת (Consent) של המשתמש. מודל האבטחה כאן מבוסס על "כוונת משתמש" (User Intent). כשאפליקציה מבקשת גישה למיקרופון בפעם הראשונה, המערכת מקפיאה את הפעולה ומציגה חלונית קופצת המבקשת רשות. לאחר שהמשתמש בחר, הבחירה מתועדת לנצח במערכת.

Deep Technical Architecture

TCC מנוהלת באמצעות ארכיטקטורת ייחוס (Attribution Chain). המערכת צריכה לדעת "מי" מנסה לגשת למידע כדי להטיל עליו אחריות. אם סקריפט שרץ דרך ה-Terminal מנסה לגשת למצלמה, ה-TCC מזהה ש-Terminal הוא תוכנת האב, וחלון האישור יבקש להעניק הרשאה ל-Terminal, לא לסקריפט הספציפי. הבקשות וההרשאות נשמרות במסדי נתונים מוצפנים מסוג SQLite. הרשאות ברמת מערכת (כמו Full Disk Access) נשמרות בנתיב המערכתי: /Library/Application Support/com.apple.TCC/TCC.db, בעוד שהרשאות פרסונליות (מצלמה, אנשי קשר) נשמרות תחת ספריית המשתמש: ~/Library/Application Support/com.apple.TCC/TCC.db. מנגנון ה-System Integrity Protection (SIP) מגן על קבצים אלו לחלוטין - אפילו משתמש root לא יכול לשנות או לערוך את בסיס הנתונים ישירות בעזרת פקודות SQL, כחלק ממדיניות האנטי-טמפרינג.

Terminal Commands, Plists & Logs

מכיוון שהמסדים נעולים על ידי SIP, הכלי המאושר היחיד לניהול שורת הפקודה הוא tccutil. עם זאת, Apple מתירה ל-tccutil אך ורק לאפס (Reset) הרשאות ולא להעניק אותן אקטיבית.

  • איפוס מצלמה לכל האפליקציות: tccutil reset Camera

  • איפוס גישת מיקרופון לאפליקציה ספציפית: tccutil reset Microphone us.zoom.xos

  • איפוס מלא לכל הרשאות הפרטיות לכל האפליקציות: tccutil reset All

  • מעקב לוגים אחר חסימות TCC בזמן אמת לאיתור שורש הבעיה: log show --predicate 'subsystem == "com.apple.TCC"' --info --last 10m

Edge Cases & Troubleshooting

הבעיה המרכזית עם TCC היא "כשלים שקטים" (Silent Failures). אם משתמש סירב בטעות לבקשת הרשאה למיקרופון בתוכנת שיחות וידאו, התוכנה לרוב פשוט תקריס את המודול של האודיו או תציג מסך שחור במקום לקפוץ שוב. המערכת לא תטריד את המשתמש פעם שנייה. פתרון התקלה דורש כניסה להגדרות הפרטיות והפיכת המתג (Toggle) באופן ידני. לעיתים תוכנה מאבדת סינכרון עם ה-Bundle ID שלה בעקבות שדרוג פגום, מה שגורם להופעת אייקונים כפולים ברשימה, או שהמתג פשוט לא מגיב. במקרים אלו התרופה המהירה והיעילה ביותר היא ביצוע tccutil reset לשירות הרלוונטי והפעלת האפליקציה מחדש כדי לאלץ את החלון הקופץ להופיע שוב בצורה תקינה.

4. תיבול ארגוני: שימוש בפרופיל PPPC לאישור אוטומטי של כלי IT, וחסימת אפליקציות באמצעות Blocklist

High-Level Theory & History

בסביבות ארגוניות (Enterprise / MDM), חלוניות ה-TCC יוצרות בעיה פדגוגית קשה הידועה בשם "Prompt Fatigue". כלי תמיכה ארגוניים, אנטי-וירוסים ארגוניים וכלי ניטור דורשים גישה עמוקה למערכת (כמו Full Disk Access). אם מחלקת ה-IT תסתמך על המשתמש הסטנדרטי שיאשר את כל החלוניות האלה, התוכנות לעולם לא יעבדו (או שהמשתמש יסרב בטעות). כדי לפתור זאת, Apple הציגה את פרופילי ה-Privacy Preferences Policy Control (PPPC), שמאפשרים ל-MDM לשלוח Payload שמעניק מראש (או שולל מראש) הרשאות מפורשות לאפליקציות ארגוניות באופן בלתי נראה, ללא התערבות משתמש כלל.

Deep Technical Architecture

כדי למנוע מנוזקה להסוות את עצמה תחת שם של אפליקציה מאושרת, פרופיל PPPC אינו מסתמך רק על ה-Bundle ID של התוכנה (למשל com.jamf.management.daemon). הוא נדרש להכיל מחרוזת מורכבת הנקראת Code Requirement – נתון קריפטוגרפי מדויק השייך לחתימה הספציפית של חברת התוכנה. כשה-MDM דוחף את פרופיל ה-Mobileconfig למחשב המקומי, תהליך בשם tccd מפענח את הפרופיל, בודק את הרשימה הלבנה, ומעניק אשור חסין. הערה קריטית לעיצוב אבטחה של Apple: פרופיל PPPC ארגוני יכול להעניק אישור גורף ל-Full Disk Access. אולם, Apple חסמה לחלוטין את האפשרות להעניק מרחוק אישור ל-מצלמה ול-מיקרופון - עבור משאבים חודרניים אלו, פרופיל PPPC ארגוני יכול לכל היותר למנוע (Deny) גישה, אך לעולם לא להעניק (Allow) במקום המשתמש. כמו כן ניתן לדחוף דרך MDM פרופילי Blocklist אשר מורים ל-Gatekeeper ולמדיניות המערכת לחסום הרצה של Bundle IDs מוגדרים.

Terminal Commands, Plists & Logs

מכיוון שהתהליך מנוהל כ-Payload מרחוק, ניהול מקומי לא קיים, אך ניתן לבחון את המדיניות:

  • איתור ה-Code Requirement המדויק של אפליקציה לשם בניית פרופיל ה-PPPC: codesign -dr - /Applications/App.app

  • אין פקודת Terminal קסומה שמייצרת את ה-XML לפרופיל. מנהלי IT משתמשים בכלים כמו פרויקט הקוד הפתוח "PPPC Utility" המאפשר לגרור פנימה את האפליקציה והוא מייצר אוטומטית את קובץ ה-Mobileconfig המותאם להעלאה ל-MDM.

  • בדיקת הפרופילים הארגוניים המותקנים כעת על המחשב למקרה שהאישור לא חל: profiles list

Edge Cases & Troubleshooting

תקלה נפוצה בסביבת Enterprise היא פריסה של תוכנת אבטחה חדשה המלווה בחלונות TCC קופצים רבים למרות שמחלקת ה-IT בטוחה שהיא שלחה פרופיל PPPC. כשל כזה נובע ב-99% מהמקרים מחוסר התאמה מדויקת (Mismatch) בין ה-Code Requirement שהוזן ב-MDM לבין החתימה בפועל של התוכנה. לעיתים חברת התוכנה משנה רכיבי פנימיים (כמו הוספת Daemon חדש שעובד בנפרד) ולכן חובה לעדכן את הפרופיל ב-MDM כדי שיכלול את כל ה-Bundle IDs של התוכנה. במקרה של חסימות Blocklist, משתמש הקצה ינסה לפתוח תוכנה מוגבלת (לדוגמה, WhatsApp) ויקבל הודעת שגיאה קשה מטעם המערכת המודיעה כי הפעלתה חסומה על ידי מנהל הרשת.