הרשאות — מי רשאי לעשות מה, ואיך מוכיחים זאת

Control Center עונה על שתי שאלות הרשאה, והן שונות זו מזו באמת. “האם האדם הזה רשאי לקרוא לפעולה הזו?” עוסקת בבני אדם, בתפקידים ובמאגרים. “האם הסוכן הזה רשאי לגרום לתוצאה הזו?” עוסקת בפעולות, בארגומנטים ובהיקף הנזק — וזו נדונה במעקות בטיחות.

הדף הזה עוסק בשאלה הראשונה, וגם ברשומה ששתיהן משאירות אחריהן.

נקודת החלטה אחת

כל החלטת הרשאה בצד האנושי נפתרת דרך פונקציה אחת:

can(principal, permission, resource) → allow | deny + why

הרשאה היא <domain>:<tier> — tickets:write, members:administer, repos:read. הקטלוג נגזר ולא נכתב ביד: הוא מחושב ממשטח הפעולות עצמו (קידומת השם של הפעולה קובעת את התחום, והתפקיד המינימלי שהיא כבר אוכפת קובע את הדרגה), כך שכל ~550 הפעולות נושאות הרשאה בלי שאיש הקליד אותה.

הגזירה הזו היא התכונה שכדאי להגן עליה. היא מבטיחה שכל פעולה חדשה חסומה כברירת מחדל — מצב הכשל של מודל שמסומן ביד הוא שמישהו שוכח, ומה שהוא שוכח הוא השער עצמו. בדיקת ראצ’ט מקבעת את קבוצת התחומים הנובעת מכך, כך שהוספת פעולה תחת קידומת חדשה היא החלטת שמות שאדם מקבל, ולא תקלה.

ארבע הדרגות ממופות בדיוק לתפקידים המובנים:

דרגה	תפקיד מינימלי	דוגמה
read	אורח	tickets:read
write	חבר	tickets:write
administer	מנהל	members:administer
own	בעלים	workspace:own

תפקידים

חמישה תפקידים מובנים — בעלים, מנהל, חבר, צופה, אורח — הם ערכות מוכנות מעל אותו קטלוג. הבעלות היא מושב אחד לכל סביבת עבודה, והיא מועברת במפורש באמצעות העברת בעלות (בעלים שעוזב אינו ניתן להסרה בדרך אחרת: ביטול הקצאה ב-SCIM מסרב לגעת בבעלים של סביבת עבודה — יש להעביר בעלות קודם).

תפקידים מותאמים רק גורעים. תפקיד מותאם מציין ערכת בסיס (admin, member, viewer או guest — לעולם לא owner) וקבוצה של הרשאות שנגרעות ממנה — “מנהל, אבל בלי לנהל חברים”. הוא לעולם אינו יכול להעניק יותר מערכת הבסיס שלו, וזה מה שהופך אותם לבטוחים להכנסה להתקנה קיימת: כל בדיקה קיימת נשארת חסם עליון תקף. חברים מחזיקים אותו בתור custom:<id>, ולקוח ישן מכדי להבין את הערך הזה נופל חזרה לאורח במקום לנחש.

מתחת לתפקידים יושבות הענקות לפי מאגר (none / read / review / write): חברות בסביבת עבודה לעולם אינה מעניקה, בשקט, הרשאה גבוהה מזו שקיימת במארח הקוד. כל משטח שחושף קוד בודק אותן — כולל אלה שמגיעים לקוד בדרך עקיפה, כמו מסוף או הפעלת עורך על עץ העבודה של מרחב.

סמכות השרת

יש פעולות שאינן עוסקות בסביבת עבודה כלל: הגדרות ברמת ההתקנה, תצורת SSO, פרטי גישה של ספקים, ניהול מודלים וגיבויים של ההתקנה כולה. אלה מצהירות על סמכות שרת ומסורבות לכולם מלבד המפעיל של ההתקנה (בעל השרת הרשום). בכוונה יש זהות מפעיל אחת, והגדרה אחת שלה.

יומן הביקורת

כל החלטת הרשאה — אישור ודחייה — נכתבת בסוף יומן ביקורת משורשר בגיבוב, לכל סביבת עבודה בנפרד.

יומן שמתעד רק דחיות עונה על “מה חסמנו?” אבל לא על “מה הסוכן הזה באמת עשה, ומי אישר לו?”, וזו השאלה שממנה מתחיל תחקיר תקרית. לכן כל רשומה מתעדת את שרשרת הייחוס המלאה: הגורם הפועל, האדם שהוא פעל בשמו, ההאצלה שדרכה הפעולה הגיעה, הפעולה והארגומנטים שלה (כתמצית), ההחלטה, והכלל שהכריע.

הרשומות משורשרות: הגיבוב של כל אחת מכסה את זה של קודמתה, כך שעריכה, מחיקה או שינוי סדר של שורה כלשהי שוברים כל גיבוב שאחריה. אימות השרשרת גוזר מחדש את כל השרשרת ומצביע על החוליה הראשונה שאינה מתקיימת. יומן ביקורת שאי אפשר לבדוק הוא יומן; יומן שאפשר לגזור מחדש הוא ראיה.

שתי השלכות שכדאי להכיר:

• טבלת הביקורת פטורה מגיזום לפי גיל. אי אפשר לקצץ שרשרת גיבוב מהאמצע. מדיניות השמירה היא ייצוא ואחר כך קיצוץ, והקיצוץ מותיר נקודת ביקורת שנושאת את הגיבוב הסוגר של הקטע שהוסר, כך שמה שנשאר עדיין מאומת עד לתחילת השרשרת.
• היא יושבת לצד ציר הזמן של הפעילות, ולא מעליו. ציר הזמן מתעד מה אנשים עשו; היומן הזה מתעד מה אושר ומה נדחה. מזהה מתאם משותף מאפשר לקרוא קריאה אחת בשניהם.

הוא מיוצא כ-JSON מופרד בשורות חדשות ויכול לזרום ל-SIEM (Splunk, Elastic, Sentinel — נקודת קצה HTTP עם אסימון Bearer). הזרימה פועלת על בסיס מאמץ מיטבי, במכוון: SIEM שקרס לא אמור לחסום לעולם קריאת כלי של סוכן, והעותק העמיד והניתן לאימות נמצא ממילא על הדיסק.

סשנים

התקנה יכולה לקבוע גיל סשן מרבי וזמן קצוב של חוסר פעילות. שניהם נאכפים בבדיקת פרטי הגישה של המכשיר, שכל נתיב מאומת זורם דרכה — מגבלת סשן שלקוח יכול להתעלם ממנה היא מענה לשאלון, לא לתוקף. התקנה יכולה גם לדרוש SSO, מה שמשבית צימוד ידני של מכשירים חדשים (עם הגנה מפני נעילה: היא מסרבת כל עוד אין חיבור SSO שעובד).

מה זה לא

• לא ACL לפי אובייקט. אין הרשאה לפי כרטיס או לפי הודעה, וזה מכוון. ההפרדה ברמת המאגר היא מה שצוותים באמת מבקשים והיא קיימת; שיתוף לפי אובייקט הוא משטח קומבינטורי בלי ביקוש מוכח כאן.
• לא מנוע מדיניות שמגדירים ב-DSL. אוצר המילים סגור בכוונה, כך שאפשר להציג את כל המדיניות, להסביר אותה ולמנות אותה.
• לא נאכף בשום מקום מלבד השרת. בדיקות בצד הלקוח קיימות רק כדי לא להציע בקרה שתידחה. ההחלטה הקובעת היא תמיד של השרת.