לדלג לתוכן

פרק 2: משתמשים והרשאות (Users & Permissions) - Asset A (Instructor Reference)

1. סוגי חשבונות מקומיים: Admin לעומת Standard, וחשבונות אורח

1. High-Level Theory & History

הקונספט של חשבונות משתמשים ב-macOS נשען על יסודות ה-UNIX (ובאופן ספציפי משפחת BSD ו-Mach). היסטורית, במערכות הפעלה מוקדמות של אפל (Mac OS Classic), המערכת לא הייתה מרובת משתמשים (Multi-User) באמת, וכל משתמש היה בעל גישה מלאה למערכת הקבצים. עם המעבר ל-Mac OS X (ואילך ל-macOS), הוצגה הפרדה קשיחה בין משתמשים (Users) לקבוצות (Groups). מערכת ההפעלה מבדילה בין שני סוגי חשבונות מקומיים עיקריים שרלוונטיים למשתמש הקצה: מנהל (Admin) וחשבון סטנדרטי (Standard). Local Account מנהל מסוגל לשנות System Settings גלובליות, להתקין תוכנות ברמת /Applications, ולבצע פעולות שדורשות הרשאות root (דרך מנגנון sudo). Local Account סטנדרטי מוגבל לסביבת העבודה הפרטית שלו בלבד (תחת /Users/username), אינו יכול לשנות הגדרות TCC גלובליות או רשת, ואינו רשאי להתקין אפליקציות הדורשות הרשאות מערכתיות. קיימים גם חשבונות אורח (Guest) אשר מייצרים סביבה זמנית לחלוטין – בעת התנתקות, כל הקבצים והשינויים בסביבת האורח נמחקים ולמעשה לא מותירים עקבות קבועים על הדיסק.

2. Deep Technical Architecture

ברמה הטכנית, משתמשים וקבוצות ב-macOS מנוהלים על ידי ה-Open Directory, המבוסס על שד המערכת (Daemon) בשם opendirectoryd. שירות זה משמש כגשר בין מערכת ההפעלה למאגרי משתמשים, החל מהמסד המקומי וכלה ב-Active Directory או LDAP. כל משתמש מקבל מזהה ייחודי (UID). למשתמשי מערכת (כגון _spotlight או _windowserver) שמורים UID הנמוכים מ-500. משתמשים שנוצרים על ידי האדם, באמצעות ה-Setup Assistant, מתחילים ב-UID 501 וכן הלאה. ההבדל בין משתמש Admin ל-Standard מעוגן טכנית בשיוך לקבוצת ה-admin (Group ID 80). חברות בקבוצה זו מעניקה הרשאות בקובץ ה-sudoers ומאפשרת אישור פעולות בתיבות הדו-שיח של Authorization Services. במחשבי Apple Silicon, לחשבון Admin יש משמעות עמוקה נוספת הקשורה לבעלות על ה-Volume: רק משתמש המוגדר כבעלים, אשר מחזיק Secure Token (Secure Token) תקין, רשאי לשנות את רמת האבטחה דרך Startup Security Utility (Startup Security Utility) או לבצע פעולות קריטיות דרך Recovery Mode (Recovery Mode). חשבון Guest אינו שייך לקבוצת admin ומופעל מתוך תבנית משתמש קשיחה (User Template), תוך שימוש במערכת הרשאות מוגבלת.

3. Terminal Commands, Plists & Logs

  • Terminal Commands:
  • dscl . -read /Users/username - קריאת מאפייני החשבון המלאים ישירות ממסד הנתונים של Open Directory.
  • id username - הצגת ה-UID והשיוך לקבוצות השונות (GID), בהן ניתן לאתר האם המשתמש שייך לקבוצה 80 (admin).
  • dseditgroup -o edit -a username -t user admin - הוספת משתמש קיים לקבוצת מנהל דרך ה-CLI.
  • sysadminctl -addUser newuser -password "pass" -admin - יצירת Local Account מנהל חדש מתוך הטרמינל בצורה בטוחה.

  • Plists: המידע הקונפיגורטיבי אודות משתמשים מקומיים נשמר בנתיב המערכתי: /var/db/dslocal/nodes/Default/users/. בספרייה זו קיימים קבצי Plist (לרוב בפורמט בינארי) אותם המערכת קוראת בעת עליית opendirectoryd.

  • Logs: ניתן לחפש אירועי אימות דרך ה-Activity Monitor או ב-Console על ידי חיפוש בלוגים. קריטריון לחיפוש בטרמינל: log show --predicate 'subsystem == "com.apple.opendirectoryd"' --info

4. Edge Cases & Troubleshooting

  • אובדן הרשאות Admin: מצב שכיח בו המשתמש היחיד במחשב מאבד בטעות את שיוכו לקבוצת Admin (לעיתים עקב באג בשדרוג מערכת או קריסה במסד הנתונים של dslocal). הפתרון לרוב דורש אתחול למצב שחזור (Recovery Mode), פתיחת טרמינל ומחיקת קובץ הדגל /var/db/.AppleSetupDone ב-Data Volume. הפעולה הזו תאלץ את ה-Setup Assistant לפעול מחדש בעליית המערכת הבאה וליצור חשבון אדמין חדש, שדרכו ניתן יהיה לתקן את החשבון המקורי.
  • Guest User לא נמחק כראוי: לעיתים נדירות, קבצי חשבון האורח נשארים בתיקיית /Users במידה והתרחשה קריסת חומרה או הפסקת חשמל אלימה בדיוק בזמן ההתנתקות. במקרה כזה תיקיית האורח עשויה להישאר ותדרוש מחיקה ידנית באמצעות פקודות מערכת הדורשות הרשאות מנהל.

2. היררכיית תיקיות: מבנה ה-Home Folder (~) ותיקיית /Users/Shared

1. High-Level Theory & History

ה-Home Folder, המיוצג במערכות יוניקס (ומכאן גם ב-macOS) על ידי הסימן טילדה (~), הוא ה"ממלכה" הפרטית של המשתמש. באופן היסטורי, על מנת להבטיח את יציבות המערכת ולמנוע ממשתמשים לשבור קבצי מערכת קריטיים, אפל הפרידה לחלוטין את התוכן האישי (הנמצא בנתיב /Users/username) מקבצי המערכת הראשיים (הנמצאים תחת /System או /Library). כל חשבון מקבל באופן אוטומטי תבנית ספריות קבועה מראש (Desktop, Documents, Downloads, Library, Movies, Music, Pictures). חשוב לציין שתיקיית ה-Library האישית (~/Library) הוסתרה מהמשתמש החל מגרסאות OS X ישנות בכדי למנוע מחיקה בשוגג של העדפות תוכנה, קבצי Application Support ומסדי נתונים של דואר. תיקיית /Users/Shared נועדה לפתור בעיה מובנית ויומיומית: מכיוון שלמשתמש א' אסורה הגישה לתיקיית הבית של משתמש ב', תיקיית ה-Shared מספקת שטח ציבורי מקומי שבו כל המשתמשים באותו מחשב רשאים לקרוא ולכתוב קבצים לשם שיתוף נוח ובטוח.

2. Deep Technical Architecture

תהליך יצירת ה-Home Folder מבוסס על אובייקט שנקרא User Template המוסתר בנתיב המערכתי /System/Library/User Template. כאשר משתמש מתחבר בפעם הראשונה, Background Process של המערכת מתעורר ומעתיק את התבנית (בגרסה המקומית המתאימה לשפת המערכת) ומניח אותה תחת תיקיית /Users/. מבחינת פריסת מערכת הקבצים המודרנית של אפל, ספריות אלו חיות אך ורק על Volume נתונים (Data Volume) נפרד, משום שווליום המערכת מוגן ונעול על ידי מנגנון ה-Sealed System Volume (SSV). לכן, הנתיב הפיזי המלא במחשב הוא למעשה /System/Volumes/Data/Users/username, אך הודות למנגנון מתקדם הנקרא Firmlink (Firmlink), הנתיב מיוצג אבסטרקטית וחלק למשתמש כ-/Users/username. תיקיית Shared משתמשת בדגל מערכת מיוחד הנקרא Sticky Bit. משמעות הדגל היא שכל משתמש במחשב יכול לכתוב לתוך התיקייה הציבורית, אך רק הבעלים המקורי של קובץ ספציפי מורשה למחוק או לשנות אותו. מנגנון זה מונע ממשתמש סטנדרטי להשמיד קבצים שהונחו שם על ידי אדמין.

3. Terminal Commands, Plists & Logs

  • Terminal Commands:
  • pwd או פשוט echo ~ - הדפסת הנתיב הנוכחי או נתיב הבית המדויק של המשתמש.
  • ls -laO ~/ - הצגת כל הקבצים בתיקיית הבית, כולל קבצים נסתרים (כגון ~/Library) ודגלי קבצים מיוחדים (File Flags).
  • chflags nohidden ~/Library - חשיפה קבועה וגלויה של תיקיית ה-Library האישית ללא צורך בהקשת כפתור ה-Option בתפריט Go של ה-Finder.

  • Plists: N/A (מיפוי תיקיות המשתמשים מטופל אינטגרלית על ידי תשתית ה-File System ואינו נשלט ישירות דרך Plist קונפיגורטיבי שמשתמש יכול לערוך).

  • Logs: תהליך הקצאת התיקייה למשתמש חדש מתועד בלוגי שירות ה-loginwindow בשילוב opendirectoryd וניתן לשלוף זאת באמצעות Console בחיפוש ממוקד אחר ה-UID החדש שנוצר.

4. Edge Cases & Troubleshooting

  • אובדן הרשאות על תיקיית הבית: תופעה מוכרת בה משתמשים מאבדים בפתאומיות גישה לקבצים בתוך תיקיית הבית שלהם, מלווה בשגיאות כתיבה (למשל חוסר יכולת לרוקן את הפח). לרוב זה מתרחש עקב שימוש שגוי של משתמשים מתקדמים בפקודת chown באופן רקורסיבי, או בעת שחזור נתונים מדיסק חיצוני ללא תאימות בעלות. בגרסאות קודמות הפתרון שכן ב-Disk Utility ("Repair Disk Permissions"), אך במערכות המודרניות הפתרון הוא להשתמש בפקודת הטרמינל הייעודית diskutil resetUserPermissions / תוך ציון הנתיב המדויק של כונן המערכת וה-UID הבעייתי, כדי לאפס את הרשאות תיקיית הבית באופן מבוקר.
  • השחתת תיקיית Shared: לעיתים, מתקיני תוכנה גרועים או סקריפטים מוחקים את תיקיית /Users/Shared לחלוטין. למרות שהמערכת עשויה ליצור אותה מחדש בהפעלה הבאה, הדבר עלול לגרור בעיות הרשאה חמורות למתקיני פלאג-אינים (כגון שגיאות התקנה של סוויטות כבדות דוגמת Adobe או תוספי אודיו של Logic הדורשים גישה לתיקייה זו כדי להניח שם ספריות תוכן).

3. אבטחת קבצים: הרשאות POSIX (Read/Write/Execute) והיכרות בסיסית עם ACL

1. High-Level Theory & History

כדי לנהל מי רשאי לקרוא, לשנות או להפעיל קובץ, macOS משתמשת בשכבות רב-ממדיות של אבטחה והרשאות. השכבה הבסיסית והוותיקה ביותר, המגיעה ישירות מהמסורת של מערכות ה-UNIX, מכונה הרשאות POSIX (ראשי תיבות של Portable Operating System Interface). הרשאות אלו קשיחות ומתחלקות לשלוש רמות סיווג בלבד: בעלים (Owner), קבוצה (Group), ואחרים (Everyone), ולשלוש פעולות בסיסיות: קריאה (Read), כתיבה (Write) והפעלה (Execute). ככל שסביבות העבודה בארגונים הפכו למורכבות יותר, הרשאות POSIX התגלו כמוגבלות (לדוגמה, הקושי ליישם תרחיש בו רוצים לאפשר למשתמש א' ולמשתמש ב' לכתוב, אך למשתמש ג' לקרוא בלבד, מבלי לייצר קבוצה ייעודית מורכבת). לכן, הציגה אפל (החל מימי OS X Tiger) תמיכה במערכת חוקים עדינה יותר הנקראת Access Control Lists, או בקיצור ACL. מנגנון ACL פועל כשכבה מעל ה-POSIX ומאפשר הוספת כללי הרשאה כירורגיים ומדויקים למשתמשים ספציפיים על גבי מערכת הקבצים.

2. Deep Technical Architecture

אדריכלות הרשאות POSIX נשמרת ברמה הנמוכה ביותר כ-Metadata ישירות בתוך מבנה הנתונים (ה-Inodes) של Volume המערכת ב-APFS. ייצוג ההרשאות מתבצע ברוב המקרים בפורמט מספרי-אוקטלי (למשל 755 לקריאה וביצוע לכולם וכתיבה לבעלים, או 644 לקריאה לכולם וכתיבה לבעלים). כאשר לקובץ או לתיקייה מוגדרים גם כללי ACL, שכבת הקרנל המנהלת את מערכת הקבצים (vfs – Virtual File System) תעבד תמיד קודם את רשימת ה-ACL לפני שהיא בוחנת את חוקי ה-POSIX. מערכת ה-ACL פועלת בצורה סדרתית, ולסדר החוקים ברשימה יש חשיבות עליונה. אם ה-ACL פוגש חוק שאוסר מפורשות (Deny) את הפעולה המבוקשת, תהליך הבדיקה נעצר באופן מיידי והמשתמש מקבל סירוב גישה – גם אם הרשאות ה-POSIX שלו לכאורה אמורות להתיר את הפעולה. חשוב לזכור: כשקובץ מועבר (Move) בתוך אותו Container, הרשאות ה-ACL נשמרות בקפידה. אך כאשר קובץ מועתק (Copy) לווליום אחר או במיוחד לדיסק חיצוני (בפורמט ExFAT או אפילו APFS אחר שאינו מוגדר לשימור היררכיה), הרשאות ה-ACL לעיתים קרובות נשמטות ונופלות, ורק חוקי ה-POSIX השטחיים שורדים את המעבר.

3. Terminal Commands, Plists & Logs

  • Terminal Commands:
  • ls -l - מציג את פירוט הרשאות ה-POSIX במסוף (למשל -rwxr-xr-x). הופעת הסימן פלוס + בסוף המחרוזת (למשל -rwxr-xr-x+) מעידה על כך שלקובץ זה מצורפת רשימת חוקי ACL פעילה.
  • ls -le - מרחיב את הפלט של הפקודה הקודמת ומדפיס באופן מילולי את רשימת חוקי ה-ACL הספציפיים (מי מורשה לבצע איזה אקשן).
  • chmod 755 filename - הגדרת הרשאות POSIX מספריות קלאסיות.
  • chmod +a "user allow read,write" filename - הוספת חוק ACL מפורש המאפשר קריאה וכתיבה למשתמש ספציפי מבלי להשפיע על שאר הקבוצות.
  • chmod -N filename - מחיקה מלאה (ניקוי אגרסיבי) של כל חוקי ה-ACL המצורפים לקובץ, והחזרתו להסתמכות על הרשאות POSIX בלבד.
  • Plists: N/A (ניהול ההרשאות הוא תכונה טבעית ומולדת של ה-File System, המנוהלת ישירות ברמת הבלוקים והמטא-דאטא על הדיסק, ואינה קונפיגורציה שיושבת בקובץ טקסט).
  • Logs: אירועי חסימת גישה לקבצים עקב הרשאות (Permission Denied) ניתנים לאיתור ב-Unified Logging System, לרוב כשהם נתפסים על ידי מנגנון ה-sandbox (דרך תהליך שנקרא sandboxd). השד מתעד בניסיון פניה לנתיב ללא הרשאות מספקות.

4. Edge Cases & Troubleshooting

  • "You do not have permission to open this application": תופעה בה משתמש מוריד אפליקציה ותיקה מהאינטרנט או פותח ארכיון דחוס ישן, ומקבל שגיאה בעת הניסיון לפתוח את האפליקציה ב-Finder. הבעיה נובעת לרוב מכך שהקובץ הבינארי הראשי (זה שיושב עמוק בתוך החבילה, בנתיב Contents/MacOS/) איבד את דגל ההפעלה (Execute / +x) ברמת ה-POSIX שלו במהלך הכיווץ. הפתרון המהיר לאיש תמיכה הוא לפתוח את הטרמינל, לגרור את הקובץ הבינארי הראשי ולהריץ עליו פקודת chmod +x כדי להחזיר את האפליקציה לחיים.
  • חסימה הדדית (Deny Overrides Allow): בסביבות עבודה מרובות משתמשים על מחשב בודד (או בעת חיבור לשרת קבצים מבוסס SMB), עלול להיווצר מצב פרדוקסלי שבו מתווסף חוק ACL מסוג "Deny" לקבוצה שהמשתמש הראשי במקרה חבר בה. מכיוון שכללי ה-Deny מקבלים קדימות מוחלטת בקרנל על פני כללי Allow, המשתמש הראשי עלול למצוא עצמו נעול לחלוטין מחוץ לקבצים של עצמו למרות שהוא ה-Owner שלהם ב-POSIX. דרך המלך לפיתרון מבוססת על שימוש בפקודת chmod -N כדי למחוק את פלונטר ה-ACL הבעייתי ולהתחיל מחדש במצב נקי.

4. תיבול ארגוני: עבודה עם Managed Apple Accounts (MAID) והגבלות על שירותי iCloud בארגון

1. High-Level Theory & History

בסביבה צרכנית רגילה, משתמשי מק מחברים את המחשב לחשבון האפל האישי שלהם (שנקרא בעבר Apple ID). פעולה זו, על אף שהיא נוחה, מהווה סיוט אבטחת מידע לצוותי IT. החיבור מושך למחשב הארגוני סיסמאות אישיות דרך ה-Keychain, תמונות משפחתיות, והחשוב מכל - פותח ערוץ כיווני ופתוח של סנכרון דרך כונן ה-iCloud Drive, מה שיוצר סיכון עצום לזליגת מידע ארגוני מסווג למכשירי קצה פרטיים בבית העובד. על מנת להחזיר את השליטה לארגונים, הציגה אפל את תפיסת חשבונות אפל המנוהלים (Managed Apple Accounts, או בקיצור היסטורי MAID). אלו הם חשבונות המונפקים ישירות על ידי הארגון (באמצעות פלטפורמת Apple Business Manager) עבור העובדים. היתרון האסטרטגי העצום של מנגנון זה הוא שהעובד יכול להשתמש בחשבון כדי לשתף פעולה בכלים השייכים למערכת האקולוגית של אפל (דוגמת Freeform, Notes או Pages), אולם הבעלות הקניינית והמשפטית על החשבון והמידע נותרת באופן מוחלט בידי הארגון. ה-IT יכול לאפס סיסמאות, לנטרל את החשבון עם סיום העסקה, וכברירת מחדל – שירותי סנכרון רגישים מכובים וחלקם (כמו רכישת אפליקציות אישיות) כלל אינם נתמכים על מנת להגן על היגיינת המידע הארגוני.

2. Deep Technical Architecture

בשונה מחשבון צרכני רגיל, ה-Managed Apple Account משלב טכנולוגיית פדרציה מתקדמת (Federated Authentication). משמעות הדבר היא שצוות ה-IT לא נדרש לחלק סיסמאות נוספות לעובדים. כאשר עובד מזין את כתובת ה-MAID שלו בחלון ההגדרות, שירות ה-accountsd ב-macOS מזהה באופן מיידי כי הדומיין מנוהל (Claimed Domain). בשלב זה, במקום שרתי האותנטיקציה הרגילים של אפל, המערכת תבצע מעקף (Redirect) ותקפיץ דפדפן מאובטח אל שירות ה-Identity Provider (IdP) של הארגון עצמו (לדוגמה Microsoft Entra ID או Google Workspace). רק לאחר שה-IdP מחזיר טוקן SAML/OIDC תקני וחתום, ה-Account מורשה להתחבר למערכת. ברמת השירותים המערכתיים ב-macOS, ברגע שמתחבר MAID, מופעלת סדרת חסימות פנימיות. פיצ'רים פרטיים כמו Apple Pay, Find My, ו-iCloud Mail אינם פעילים כלל ברמת הארכיטקטורה. יתרה מזאת, מערכת ה-Keychain מסנכרנת רק נתונים תחת "Managed Keychain" שמופרד פיזית ולוגית ממפתחות אישיים, ובכך נמנע זיהום מידע (Cross-Pollination) בין זהות ארגונית לזהות פרטית אם המשתמש הכניס גם חשבונות אחרים במכשיר.

3. Terminal Commands, Plists & Logs

  • Terminal Commands: N/A (מנגנון האותנטיקציה והתחברות לחשבון MAID פועל ברמת ה-UI (ב-System Settings) או בצורה חלקה בזמן ה-Setup Assistant (OOBE) מול מנגנון ה-MDM/ADE, וכל ניסיון לערוך מסדי נתונים של זהויות ענן דרך CLI ייחסם על ידי מנגנוני SIP ו-TCC).

  • Plists & Configuration Profiles: מנהלי מערכת בעולמות ה-Enterprise משתמשים בפרופיל תצורה (Configuration Profile) המיושם על ידי מערכת ה-MDM – במקרה זה מדובר ב-Payload מסוג com.apple.applicationaccess – בכדי להדק ולנהל את שירותי הענן אף מעבר לחסימות ברירת המחדל. מקשי Plist בולטים בהקשר זה:

  • allowCloudDocumentSync מצב false חוסם כליל את היכולת לסנכרן קבצים דרך iCloud Drive.

  • allowCloudKeychainSync מצב false מונע סנכרון של סיסמאות מקומיות לענן. חשוב להדגיש: גם במידה והארגון מאפשר למשתמש להתחבר עם Apple Account צרכני פרטי (BYOD חלקי), פריסת פרופיל זה תעקוף את רצון המשתמש ותנעל באופן רוחבי את הגישה לשירותים אלו לאורך כל ה-OS.

  • Logs: מעקב אחר תהליך האותנטיקציה הפדרטיבית המורכב ומציאת כשלים בתקשורת SAML/IdP יכול להתבצע ב-Unified Logging System. לשם כך יש לסנן ולהאזין לשירות akd (AuthKit Daemon) ולשירות accountsd: log show --process accountsd --info

4. Edge Cases & Troubleshooting

  • התנגשות חשבונות (Account Conflict): זהו תרחיש תמיכה נפוץ ביותר בארגונים בוגרים. פעמים רבות, לפני שצוות ה-IT רשם ודרש בעלות רשמית על הדומיין הארגוני ב-Apple Business Manager, עובדים השתמשו בכתובת המייל הארגונית שלהם (לדוגמה john@company.com) כדי ליצור חשבון Apple פרטי לצורך הורדת אפליקציות. כאשר ה-IT מפעיל לבסוף פדרציה (Federation) ומייצר MAID זהה על גבי אותו דומיין, אפל מזהה התנגשות מיידית. המערכת שולחת לעובד התראה קשיחה שעליו לשנות את כתובת המייל של חשבונו האישי בתוך פרק זמן של 60 יום. לאחר מכן, החשבון האישי המקורי הופך באופן אוטומטי לחשבון בעל כתובת זמנית אקראית (Temporary Account), מה שגורם לעיתים לבלבול רב, חרדת איבוד תמונות ופניות דחופות למחלקת התמיכה כדי לסייע באיתור החשבון הישן.
  • אפליקציות צד-שלישי שבורות בסנכרון: כברירת מחדל אגרסיבית, משתמש המחזיק ב-MAID אינו יכול לאפשר לאפליקציות צד-שלישי (למשל אפליקציית כתיבה או שרטוט עצמאית) להשתמש באחסון ה-iCloud כערוץ סנכרון מאחורי הקלעים ב-Mac. אם המשתמש מתלונן על תקלת סנכרון של תוכן בין המק לאייפון שלו באפליקציה כזו, הסיבה אינה באג במחשב אלא חסימה מובנית. על מנהל המערכת להיכנס ידנית לפורטל Apple Business Manager, ובתוך הגדרות הארגון להעביר מתג ייעודי המאפשר למשתמשי MAID להסמיך אפליקציות צד-שלישי לגישה לענן, פעולה שהרבה צוותי אבטחה מהססים לאשר.