שיעור 03: אבטחת מידע¶
חלק א': מאגר ידע למדריך
[!NOTE] מדריך זה עודכן עבור macOS 26 Tahoe, והוא משלב פרדיגמות אבטחה מודרניות כגון Signed System Volume (SSV), מדיניות Secure Boot של מעבדי Apple Silicon, והארכיטקטורה העדכנית ביותר של XProtect, תוך שמירה על ההקשר ההיסטורי המסורתי שאנשי IT מנוסים זקוקים לו.
1. הגן הסגור: מנגנון ה-Gatekeeper, חתימות ונוטריון (Notarization)¶
תיאוריה ברמה גבוהה והיסטוריה¶
מנגנון ה-Gatekeeper נולד כדי לפתור את אחת הבעיות הגדולות ביותר של מחשוב אישי חופשי: הרצת קוד זדוני ללא ידיעת המשתמש. בעבר, כל קובץ שהורד מהאינטרנט היה יכול לרוץ בחופשיות. כיום, הגישה של Apple מחמירה בהרבה, ומבוססת על מודל אמון (Trust Model) קפדני. כאשר אפליקציה מורדת מחוץ ל-Mac App Store, ה-Gatekeeper נכנס לפעולה בטרם ההרצה הראשונה. הוא מוודא שלושה דברים מרכזיים:
- Code Signing (חתימת קוד): שהאפליקציה חתומה על ידי מפתח מוכר (Developer ID).
- Notarization (נוטריון): שהקוד שלה עבר תהליך סריקה אוטומטי בשרתי Apple כדי להבטיח שאין נוזקות מוכרות בטרם שחרורו.
- Integrity (שלמות): שהקוד לא עבר שום שינוי או שיבוש מאז שנחתם.
[!TIP] הקשר היסטורי: חתימות קוד במערכת ההפעלה של Mac לא היו קיימות ב-23 השנים הראשונות שלה. הן הוצגו לראשונה רק בשנת 2007 עם יציאת Mac OS X 10.5 Leopard, במקביל ליציאת ה-iPhone הראשון. המהנדס שהוביל זאת, המכונה 'Perry the Cynic', אמר למפתחים שאם הם חושבים שזה יוביל ל"גל שחור של פשיזם במערכת ההפעלה" - הם מוזמנים להאשים אותו, כי זה היה הרעיון שלו. Gatekeeper עצמו הופיע כהמשך טבעי רק ב-2012. בעבר, למשתמשים הייתה אפשרות פשוטה לבחור ב-"Anywhere" (מכל מקום) בהגדרות המערכת, אך אפשרות זו הוסתרה בסופו של דבר כדי להגן על המשתמשים מפני עצמם.
ארכיטקטורה טכנית עמוקה¶
התהליך מתחיל ברגע שאפליקציה פוגשת את מערכת הקבצים, בדרך כלל בעקבות הורדה דרך דפדפן (כמו Safari) או תוכנת מסרים. האפליקציה המורידה מצמידה לקובץ תגית מטא-דאטה מיוחדת בשם Extended Attribute (xattr), ובאופן ספציפי com.apple.quarantine.
כאשר המשתמש מנסה להפעיל את הקובץ, תהליך רקע בשם syspolicyd מזהה את התגית הזו ומיירט את ההפעלה עד לסיום תהליך אימות קריפטוגרפי. Gatekeeper בוחן את שרשרת החתימות מול שרתי Apple כדי לוודא שאישור המפתח לא נשלל (Revoked). הוא גם בודק את סטטוס ה-Notarization של הקוד. בדרך כלל, כרטיס אישור זה "מודק" (Stapled) לתוך קובץ האפליקציה עצמו, מה שמאפשר אימות והתקנה גם ללא חיבור אינטרנט פעיל.
בנוסף, מנגנון אבטחה בשם App Translocation (הידוע גם כ-Gatekeeper Path Randomization) נכנס לפעולה. הוא מעלה באופן שקוף את האפליקציה לנתיב זמני, נסתר ולקריאה בלבד (Read-Only) בזמן ההרצה הראשונה. זה מונע מאפליקציה זדונית לטעון בשקט קבצי עזר חיצוניים או תוספים מתוך התיקייה שבה הורדה (למשל, טעינה דינמית של ספרייה פגועה מתוך תיקיית ה-~/Downloads).
ב-macOS 26 Tahoe, מודל האבטחה הודק אף יותר. בעוד שמשתמשים עדיין יכולים לעקוף אזהרות אבטחה אם הם באמת צריכים לפתוח אפליקציה ממפתח לא מזוהה, האפשרויות הללו קבורות עמוק יותר בתוך System Settings > Privacy & Security > Advanced, ודורשות אימות מפורש של מנהל מערכת כדי לנהל הגדרות אבטחה ברמת המערכת.
פקודות טרמינל, Plists ולוגים¶
הניהול המקומי של Gatekeeper מבוצע בעיקר באמצעות הפקודה spctl (System Policy Control).
-
בדיקת אבחון של אפליקציה והחתימה שלה לפני הרצה:
spctl -a -vv /Applications/AppName.app -
הסרת תגית ההסגר (Quarantine) באופן ידני (כדי לעקוף את מנגנון האזהרה לחלוטין):
xattr -d com.apple.quarantine /path/to/AppName.app -
שחזור האפשרות הישנה של "Anywhere" בהגדרות המערכת (השתמש בזהירות):
sudo spctl --master-disable -
חיפוש לוגים על חסימות Gatekeeper בעזרת מערכת Unified Logging:
log show --predicate 'subsystem == "com.apple.syspolicy"' --info --last 1h
מקרי קצה ופתרון תקלות¶
מקרה קצה נפוץ הוא כאשר Gatekeeper חוסם אפליקציה לגיטימית מכיוון שהמפתח לא ביצע Notarization כראוי, או שהאישור שלו פג. המשתמש יקבל שגיאה מאיימת הקובעת "App is damaged and can't be opened" או שהיא מגיעה מ"unidentified developer". הפתרון הרשמי הוא להנחות את המשתמש לגשת ל-System Settings > Privacy & Security ולאשר ידנית את האפליקציה דרך כפתור "Open Anyway".
דרך עוקפת חלופית היא לחיצה ימנית (Control-Click) על האפליקציה ב-Finder ובחירה ב-Open, מה שמפעיל תיבת אזהרה המאפשרת הרצה תוך רישום חריגה (Exception) ב-Gatekeeper לפעמים הבאות.
תרחיש נוסף הוא כאשר App Translocation מתערב ושובר אפליקציות לגיטימיות המצפות שקבצי הרישיון שלהן או תיקיות המשאבים ימצאו באותה תיקייה. כדי לשבור את ההעברה (Translocation), לרוב מספיק פשוט להעביר את האפליקציה באופן ידני באמצעות ה-Finder מתיקיית ה-Downloads לתיקיית ה-/Applications לפני שמפעילים אותה בפעם הראשונה. ההעברה הידנית מנקה את דגל ההעברה.
2. האנטי-וירוס השקט: XProtect ו-XProtect Remediator¶
תיאוריה ברמה גבוהה והיסטוריה¶
בניגוד למיתוס ההיסטורי שמחשבי Mac חסינים לווירוסים, Apple פיתחה לאורך השנים מערכת הגנה חזקה ורב-שכבתית. השכבה השקטה ביותר היא XProtect, הפועלת לחלוטין מאחורי הקלעים ללא ממשק משתמש נראה לעין. XProtect מורכב משני רכיבים עיקריים:
- מנוע המניעה (XProtect): סורק כל קובץ בעת ההרצה הראשונה שלו או לאחר שינוי במערכת הקבצים, ומחפש חתימות זדוניות.
- XProtect Remediator: רכיב רקע פעיל המבצע סריקות תקופתיות לאיתור נוזקות מוכרות שאולי כבר חדרו למערכת, ומבצע פעולות תיקון והסרה (Remediation).
מערכת זו מעדכנת את עצמה באופן עצמאי, בנפרד מעדכוני גרסאות ראשיים של macOS, מה שמבטיח תגובה מהירה לאיומי זיהוי-אפס (Zero-day threats).
[!TIP] הקשר היסטורי: הארכיטקטורה של XProtect מסתמכת רבות על חוקי YARA. תקן תעשייתי זה לזיהוי תבניות פותח לפני יותר מ-12 שנים על ידי ויקטור אלברז מ-VirusTotal. מעניין לציין שהשם YARA הוא בדיחה פנימית שפירושה 'YARA: Another Recursive Acronym' (או לחלופין, 'Yet Another Ridiculous Acronym').
ארכיטקטורה טכנית עמוקה¶
הארכיטקטורה של XProtect בנויה על חוקי YARA, המגדירים תבניות סריקה לאיתור נוזקות. החל בערך מ-macOS Sequoia והמשך לתוך macOS 26 Tahoe, המבנה של XProtect עבר מהפכה שקטה. בעוד שהקבצים שכנו בעבר תחת CoreServices, המיקום הראשי עבור נתוני העדכונים הוא כעת /var/protected/xprotect/XProtect.bundle. זהו מיקום מוגן מאוד המושך עדכונים בתדירות גבוהה (לעתים קרובות מספר פעמים ביום) דרך שירותי CloudKit, ועוקף את מנגנון ה-Software Update הישן.
אם ה-bundle המוגן ריק (למשל, מיד לאחר שדרוג מערכת ההפעלה), המערכת מסתמכת זמנית על עותק גיבוי משני הממוקם ב-CoreServices. תהליך העדכון (XProtect Update Service) דוגם את הענן של Apple כדי לוודא שהחוקים הקריפטוגרפיים מעודכנים.
תהליכי ה-Remediator מנוהלים על ידי daemons שונים של launchd שמתעוררים באופן יזום ברקע (על בסיס לוחות זמנים רנדומליים חלקית, בדרך כלל כאשר ה-Mac ער, במצב חוסר פעילות, ומחובר לחשמל) כדי לסרוק את הזיכרון ומערכת הקבצים. כדי למנוע ירידה בביצועים, XProtect Remediator משתמש בטיימר במהלך הסריקות שלו, ומבטל אותן אוטומטית אם סריקה אורכת יותר מדי זמן מהמותר.
פקודות טרמינל, Plists ולוגים¶
כלי CLI ייעודי בשם xprotect הוצג לאחרונה לשליטה במערך זה (כשהוא מחליף את השימוש ב-softwareupdate למטרה ספציפית זו):
-
בדיקת הגרסה המותקנת כעת של XProtect במיקום הראשי:
xprotect version -
בדיקה מול הענן האם קיימים עדכונים זמינים ללא התקנה:
sudo xprotect check -
כפיית התקנה של העדכון האחרון מ-iCloud:
sudo xprotect update -
נתיב האפליקציה המבצעת את הסריקות הפעילות (Remediator):
/Library/Apple/System/Library/CoreServices/XProtect.app -
שאילתת לוגי סריקה של Remediator במהלך 24 השעות האחרונות:
log show --predicate 'subsystem == "com.apple.XProtectFramework.PluginAPI"' --info --last 24h
מקרי קצה ופתרון תקלות¶
תקלות מתרחשות לעיתים קרובות כאשר ה-Mac לא יכול לתקשר עם שרתי iCloud כדי למשוך עדכוני YARA חדשים, במיוחד ברשתות ארגוניות מוגבלות מאוד (Proxies/Firewalls) החוסמות תעבורה לדומיינים ספציפיים של CloudKit. במקרים כאלה, הפקודה xprotect check עלולה להחזיר שגיאת רשת, או שסריקות עשויות להפסיק לחלוטין.
במקרים נדירים, מסד הנתונים של XProtect עשוי להיתקע ולדווח על גרסה 0 במיקום הראשי, מה שמצביע על חוסר. כלי פיתוח ואבחון חיצוניים (כמו XProCheck או SilentKnight) יכולים לזהות זאת כאשר הם מנסים לקרוא את לוג המערכת ומוצאים שאין דיווח על סריקות במהלך 24-36 השעות האחרונות. הפתרון המהיר ביותר הוא להפעיל sudo xprotect update ולאמת קישוריות לאינטרנט. בנוסף, משתמשים המבחינים בזמני טעינה איטיים של אפליקציות עשויים לחוות סריקות אגרסיביות של חוקי YARA; אבחון של זה דורש בדיקת יומני ה-xprotect.
3. ניהול פרטיות (TCC) והגנות יסוד¶
תיאוריה ברמה גבוהה והיסטוריה¶
מערכת TCC (Transparency, Consent, and Control - שקיפות, הסכמה ובקרה) משמשת כמבצר של פרטיות המשתמש ב-macOS. היא נועדה להבטיח שאף תוכנה לא תוכל לגשת לנתונים אישיים רגישים (כמו המצלמה, המיקרופון, המיקום או תיקיית המסמכים) ללא הסכמה מפורשת מהמשתמש. מודל האבטחה כאן מבוסס לחלוטין על "כוונת המשתמש". כאשר אפליקציה מבקשת גישה למיקרופון בפעם הראשונה, המערכת מקפיאה את הפעולה ומציגה תיבת דו-שיח מוקפצת המבקשת רשות. לאחר שהמשתמש עושה בחירה, החלטה זו נרשמת באופן קבוע במערכת.
[!TIP] הקשר היסטורי: במהלך 15 השנים הראשונות של מערכת ההפעלה, מ-Classic Mac OS עד Mac OS 9 בשנת 1999, מחשבי Mac תוכננו עבור סביבות משתמש יחיד, ולכן הפרטיות בקושי היוותה דאגה. אפילו עד שנת 2011, חלונית הפרטיות ב-System Preferences הכילה רק שלושה פריטים: מיקום, אנשי קשר ונתוני שימוש. רק עם שחרורו של macOS 10.14 Mojave בשנת 2018 הופיעה ארכיטקטורת ה-TCC במלוא הדרה, והתרחבה לעשרות קטגוריות נפרדות שאנו מכירים כיום. System Integrity Protection (SIP), שמגן על מסדי הנתונים של TCC, הוצג מעט מוקדם יותר ב-macOS 10.11 El Capitan (2015).
ארכיטקטורה טכנית עמוקה¶
TCC מנוהל דרך שרשרת ייחוס (Attribution Chain). המערכת צריכה לדעת בדיוק "מי" מנסה לגשת לנתונים כדי לראות בו כאחראי. אם סקריפט המבוצע דרך ה-Terminal מנסה לגשת למצלמה, TCC מזהה ש-Terminal הוא יישום האב, וההודעה תבקש להעניק הרשאה ל-Terminal, לא לסקריפט הספציפי.
בקשות והרשאות נשמרות במסדי נתונים SQLite מוצפנים. הרשאות ברמת מערכת (כמו גישת דיסק מלאה - Full Disk Access, שעוקפת TCC עבור גישה לקבצים) נשמרות בנתיב המערכת: /Library/Application Support/com.apple.TCC/TCC.db. הרשאות אישיות (מצלמה, אנשי קשר) נשמרות בתוך התיקייה של המשתמש: ~/Library/Application Support/com.apple.TCC/TCC.db.
מנגנון ה-System Integrity Protection (SIP) מגן באופן מוחלט על קבצים אלו — אפילו משתמש root לא יכול לשנות או לערוך ישירות את מסד הנתונים באמצעות פקודות SQL. SIP מגביל באופן מהותי את גישת השורש (root), שומר את התצורה שלו ב-NVRAM ודורש אתחול למצב שחזור (Recovery Mode) כדי לבצע שינויים באמצעות פקודת csrutil. SIP מגן על קבצי מערכת, מונע הזרקת קוד בזמן ריצה, ואוכף הרחבות ליבה (kexts) חתומות בלבד.
במחשבי Mac עם Apple Silicon, מנגנון ה-TCC משלים את עצמו עם אבטחת אתחול מתקדמת. מצב Full Security מבטיח שה-Signed System Volume (SSV) נותר טהור ומונע טעינה של הרחבות ליבה (kexts) בלתי מורשות.
פקודות טרמינל, Plists ולוגים¶
מכיוון שמסדי הנתונים נעולים על ידי SIP, כלי שורת הפקודה המאושר היחיד לניהול הוא tccutil. עם זאת, Apple מגבילה בכוונה את tccutil רק כדי לאפס (Reset) הרשאות, ולעולם לא להעניק אותן באופן אקטיבי.
-
איפוס הרשאות מצלמה לכל האפליקציות:
tccutil reset Camera -
איפוס גישת מיקרופון עבור אפליקציה ספציפית (למשל, Zoom):
tccutil reset Microphone us.zoom.xos -
איפוס מלא של כל הרשאות הפרטיות לכל האפליקציות:
tccutil reset All -
בדיקת המצב של System Integrity Protection (SIP):
csrutil status -
ניטור חסימות TCC בזמן אמת כדי לזהות את גורם השורש לבעיות גישה:
log show --predicate 'subsystem == "com.apple.TCC"' --info --last 10m
מקרי קצה ופתרון תקלות¶
הנושא העיקרי עם TCC הוא "תקלות שקטות" (Silent Failures). אם משתמש דוחה בטעות בקשת הרשאה למיקרופון באפליקציית שיחות וידאו, האפליקציה בדרך כלל פשוט תקרוס במודול האודיו שלה או תציג מסך שחור במקום לבקש שוב. המערכת לא תטריד את המשתמש בפעם השנייה. פתרון זה דורש ניווט להגדרות Privacy & Security והפעלת המתג באופן ידני.
לפעמים, אפליקציה מאבדת סנכרון עם ה-Bundle ID שלה בעקבות שדרוג לקוי, וכתוצאה מכך סמלים כפולים ברשימה, או שהמתג פשוט מסרב לזוז. בתרחישים אלה, התרופה המהירה והיעילה ביותר היא לבצע איפוס tccutil reset עבור השירות הרלוונטי ולהפעיל מחדש את האפליקציה כדי לכפות בקשה (Prompt) נקייה ונכונה.
4. תיבול ארגוני: פרופילי PPPC ומגבלות אפליקציות (Blocklist)¶
תיאוריה ברמה גבוהה והיסטוריה¶
בסביבות Enterprise ו-MDM, בקשות TCC יוצרות בעיה פדגוגית ותפעולית חמורה המכונה "עייפות בקשות" (Prompt Fatigue). כלי תמיכה ארגוניים, סוכני אנטי-וירוס ארגוניים ותוכנות ניטור דורשים גישת מערכת עמוקה (כמו Full Disk Access). אם מחלקת ה-IT תסתמך על משתמשים סטנדרטיים כדי לאשר את כל הבקשות הללו, התוכנה בוודאות לא תצליח לפרוס כראוי.
כדי לפתור זאת, Apple הציגה פרופילי Privacy Preferences Policy Control (PPPC). אלה מאפשרים ל-MDM לפרוס Payload שמאשר מראש (או דוחה מראש) הרשאות מפורשות עבור יישומים ארגוניים באופן בלתי נראה, ללא שום צורך בהתערבות משתמש.
ארכיטקטורה טכנית עמוקה¶
כדי למנוע מאפליקציה זדונית להתחזות בשם של אפליקציה מאושרת, פרופיל PPPC אינו מסתמך אך ורק על ה-Bundle ID של האפליקציה (למשל, com.jamf.management.daemon). עליו לכלול מחרוזת מורכבת הידועה בשם Code Requirement - נתון קריפטוגרפי מדויק השייך לחתימה הספציפית של ספק התוכנה.
כאשר ה-MDM דוחף את פרופיל ה-Mobileconfig למק המקומי, תהליך הרקע tccd מפענח את הפרופיל, מצליב עם הרשימה הלבנה (Whitelist), ומעניק אישור חסין.
הערת תכנון אבטחה קריטית: בעוד שפרופיל PPPC ארגוני יכול להעניק אישור גורף לגישת דיסק מלאה (Full Disk Access), Apple חסמה לחלוטין את היכולת להעניק מרחוק גישה למצלמה (Camera), למיקרופון (Microphone) או להקלטת מסך (Screen Recording). עבור משאבים פולשניים מאוד אלה, פרופיל PPPC יכול לכל היותר למנוע גישה במפורש, או לאפשר למשתמש רגיל (Standard User) לאשר הקלטת מסך ללא אישורי מנהל מערכת (Admin). הוא לעולם לא יכול להעניק בשקט גישה למצלמה/מיקרופון בשם המשתמש.
בנוסף, MDMs יכולים לפרוס פרופילי Blocklist המנחים את Gatekeeper ומדיניות המערכת לחסום לחלוטין הפעלה של Bundle IDs מוגדרים.
פקודות טרמינל, Plists ולוגים¶
מכיוון שתהליך זה מנוהל בתור Payload מרוחק, שינוי מקומי אינו אפשרי, אך ניתן לבקר את המדיניות:
-
זיהוי ה-Code Requirement המדויק של אפליקציה כדי לבנות פרופיל PPPC:
codesign -dr - /Applications/App.app -
הערה: אין פקודת Terminal קסומה שתיצור את ה-XML עבור הפרופיל. מנהלי IT מסתמכים על כלים בקוד פתוח כמו "PPPC Utility", המאפשרים להם לגרור ולשחרר את האפליקציה כדי ליצור אוטומטית את קובץ ה-Mobileconfig המותאם להעלאה ל-MDM.
-
הצגת הפרופילים הארגוניים המותקנים כעת כדי לאמת את החלת המדיניות:
profiles list -
בדיקת פרופילי תצורה מפורטים:
profiles show -type configuration
מקרי קצה ופתרון תקלות¶
בעיה נפוצה בסביבות Enterprise היא פריסת תוכנת אבטחה חדשה שמעוררת באופן בלתי צפוי מטח של בקשות TCC, למרות שמחלקת ה-IT בטוחה שהיא דחפה פרופיל PPPC. כשל זה נובע, ב-99% מהמקרים, מחוסר התאמה בין ה-Code Requirement המוטמע בפרופיל ה-MDM לבין החתימה בפועל של התוכנה המותקנת. ספקי תוכנה מרבים לשנות רכיבים פנימיים (למשל, הוספת Daemon עזר חדש הפועל באופן עצמאי), מה שמחייב עדכון של פרופיל ה-MDM כדי שיכיל את כל ה-Bundle IDs הרלוונטיים.
לגבי הגבלות Blocklist, משתמש קצה המנסה לפתוח אפליקציה מוגבלת (למשל, WhatsApp) ייתקל בשגיאת מערכת חמורה המציינת כי האפליקציה חסומה על ידי מנהל הרשת, הנשלטת על ידי הגבלות com.apple.applicationaccess המצטלבות עם LaunchServices.
💡 עזרים ויזואליים להרצאה (Presentation Visuals)¶
[!TIP] תמונות אלו ניתנות להקרנה בכיתה בעת הסבר על הנושא, או לשילוב במצגות.
