תפקידי משתמש בדומיינים לשליטה מאובטחת בצוות

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

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

למה הרשאה אחידה לא עובדת

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

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

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

תפקידי משתמש בדומיינים לפי אחריות בפועל

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

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

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

הרשאת DNS אינה הרשאת בעלות

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

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

איך בונים מודל הרשאות בלי ליצור צוואר בקבוק

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

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

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

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

תיעוד פעולות הוא חלק מההרשאה

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

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

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

גישת לקוחות: שקיפות בלי למסור את המפתחות

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

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

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

תחזוקת הרשאות היא תהליך, לא הגדרה חד-פעמית

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

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

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

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