הגדרת Yandex IAM: היכן הגישה נשברת ומדוע
הרשאות בענן כמעט אף פעם לא ניתנות לפי חישוב. בדרך כלל מוסיפים תפקיד „ליתר ביטחון“, כדי שהמשימה לא תיתקע: תחילה לעצמך, אחר כך לעמית, ואחר כך לקבלן משנה לתקופת העבודה. כעבור חודשיים כבר אף אחד לא זוכר את מעגל הגישה השני והשלישי, וברשימת התפקידים תלוי סט שאי אפשר להסביר.
בהמשך מצטברים חשבונות שירות ומפתחות. יוצרים אותם עבור ייצוא דחוף או אינטגרציה, את המפתח שמים במשתני בנייה, במאגר ובהתכתבות, ואין רוטציה. בסופו של דבר מפתחות חיים ומתים נראים אותו דבר, ולא ברור אילו מהם עדיין עושים משהו בענן, ואילו זה מכבר יש לבטל.
שיא הכאב — עזיבת עובד. ביטול גישה הופך להגרלה של שבוע: חלק מהמשאבים קשורים לחשבון אישי, חלק לתפקיד שהוענק לפרויקט, וחלק למפתח של חשבון שירות שאיש לא ספר. בזמן הבירור, העובד לשעבר שומר על גישה לאחסון, ומשימות חדשות תקועות, כי לא ברור מה אפשר לכבות בלי השלכות.
זה לא נראה עד שמתרחשת בדיקה או תקרית. ואז מתברר שאי אפשר לענות על שאלה פשוטה: למי הייתה גישה לאחסון מסוים, מי העניק את ההרשאה ומה הספיקו לעשות עם המפתח הזה.
בדיוק משום כך הגדרת גישה בענן מתחילה לא בקונסולה, אלא בספירת מלאי: מה קיים, מי הבעלים, היכן הרשאות יתר של משתמשים ואילו מפתחות חיים יותר מהמשימה שלהם.
אנו מפרטים כיצד זה נסגר: ביקורת תפקידים ומדיניות, הפרדת חשבונות שירות לפי משימות, תוחלת חיים מוגבלת של מפתחות ונוהל ביטול שלוקח דקות, לא שבוע.
מה נותנת גישה מנוהלת: אפקטים מדידים
הרשאות מפסיקות להיות תכונה של אדם והופכות לתכונה של תפקיד. עקרון ההרשאות המינימליות ב-Yandex Cloud פועל באמצעות קישור תפקידים לקטלוג, לענן או למשאב נפרד: מפתח מקבל גישה לסביבה שלו, ולא לכל החשבון.
ניתוח סמכויות בהתחלה בדרך כלל מראה שלשליש מהחשבונות יש הרשאות יותר ממה שדרוש לעבודה; לאחר המעבר לתפקידים, שיעור הרשאות היתר יורד לאחוזים בודדים.
חשבון שירות נפרד לכל שירות מסיר מפתחות גישה משותפים מהקונפיגים, ממשימות הבנייה וממכונות העבודה. דליפת מפתח גישה מפסיקה להיות כשל טוטאלי: התקרית מוגבלת לשירות אחד, המפתח מבוטל בפעולה אחת, והשאר ממשיכים לעבוד. זמן ביטול הגישה נמדד בדקות — גם לעובד וגם לשירות, בלי לחפש את כל המקומות שבהם היה הסוד המשותף.
הפרדת סמכויות מבוססת על כך שתפקידי ניהול ניתנים בנפרד מתפקידי עבודה, ולא „ליתר ביטחון“. נעלם סוג מצבים שבהם אותה גישה מאפשרת לשנות הגדרה, לאשר שינוי ולא להשאיר עקבות: התפקידים מפוזרים לפי פונקציות, והפעולות נרשמות ביומן עם קישור לבעלים מסוים.
בהמשך, הגישות מתנהלות לפי תקנון, לא לפי זיכרון: סקירה תקופתית לפי היומן מציגה תפקידים שלא היו בשימוש חודשים, ומסירים אותם; עם פיטורין או החלפת צוות, ההרשאות מבוטלות תוך דקות, כי הן לא תלויות בחשבון משותף. בפלט — מתאר גישה מנוהל: רואים למי יש מה, באמצעות מה זה הוענק וכמה מהר זה נסגר.
אפשרויות ארגון גישה: תפקידים, קבוצות, חשבונות
הרשאות בענן ניתנות בכמה דרכים, וכל אחת מתנהגת אחרת בעת ביטול. תפקיד ישיר למשתמש נוח לעבודה חד-פעמית, אבל כעבור חצי שנה איש כבר לא זוכר לשם מה הוא ניתן. קבוצות אוספות הרשאות זהות של צוות במקום אחד, ירושה לקטלוג מפיצה אותן לכל מה שכלול, וחשבון שירות מכסה אוטומציה בלי מעורבות אדם. בחירת הסכמה היא בראש ובראשונה בחירה של כמה בזול תוכלו לקחת את הגישה בחזרה.
| סכמה | מתי מתאימה | מגבלות |
|---|---|---|
| תפקיד ישירות למשתמש | הקצאה חד-פעמית למשאב מסוים, עבודות קצרות | אינה עוברת בירושה; עם עזיבת אדם יש לזכור את כל נקודות ההקצאה |
| קבוצות משתמשים ותפקידים | צוות עם סט משימות זהה והרכב יציב | לא מתאים לחריגים אישיים — תצטרכו להרבות קבוצות |
| הרשאות ברמת משאב (קטלוג, ענן) | מדיניות אחידה וירושת הרשאות לכל מה שכלול | קל לתת יותר ממה שדרוש לשירות אחד; צמצום דורש קטלוג נפרד |
| חשבון שירות | בנייה, אינטגרציות, אוטומציה ברקע | מפתח ארוך-חיים דולף בשקט — רוטציה וביקורת חובה |
| גישה זמנית | ביקורת, החלפות, עבודות קבלן | עם תום התקופה לא תמיד מתבטל מעצמו, נדרש פיקוח |
בפועל משלבים סכמות: הרכב קבוע מקבל תפקידים דרך קבוצות עם ירושה מהקטלוג, עבודות חד-פעמיות נסגרות בגישה זמנית, ואוטומציה חיה בחשבון שירות נפרד עם סט הרשאות מינימלי. אז ביטול גישה הוא פעולה אחת בקבוצה או פקיעה של מועד, ולא חיפוש הקצאות ישירות בעשרות משאבים. בדיוק ההבדל הזה קובע כמה זמן ייקח הבירור בבדיקה או בעזיבת עובד.
סדר הגדרת גישה: מביקורת ועד מסירה
גישות בענן כמעט תמיד גדלות באופן ספונטני: חשבונות שירות נוצרים למשימה מסוימת, מפתחות חיים שנים, תפקידים ניתנים „כדי שזה יעבוד“. לשנות זאת בעיוורון מסוכן יותר מאשר להשאיר כמו שזה — תחילה מתעדים את המצב הנוכחי, אחר כך מתכננים, ורק אז מחליפים.
- ספירת מלאי של חשבונות. אוספים חשבונות שירות, מפתחות סטטיים, קישורים למכונות וירטואליות ולמערכות חיצוניות. בנפרד מסמנים רשומות ללא בעלים — מהן לרוב מתחיל בירור תקלות.
- סכמת גישה. מציגים מי פונה לאילו משאבים: שירות לשירות, אינטגרציות חיצוניות, אנשים. בסכמה מיד נראים קשרים מיותרים ותפקידים שניתנו „ליתר ביטחון“.
- מטריצת סמכויות. מכנסים את ההרשאות לסט מינימלי נדרש ברמת הקטלוג, קטלוג המשאבים והמשאב הנפרד. בכל שורה — הסיבה שלשמה הגישה נדרשת.
- הגדרה והעברת שירותים. נותנים תפקידים חדשים, מפתחות הופכים לקצרי-חיים, והקודמים מבוטלים בהדרגה. תוכנית חזרה לאחור מוכנה: אם שירות מאבד גישה, החזרה אורכת דקות, לא חיפושי לילה של הסיבה.
- בדיקה במתאר ניסוי. מריצים תרחישים טיפוסיים — בנייה, פריסה, קריאת סודות, פניות לאחסון. המתאר מראה הרשאות מיותרות וחסרות לפני שהן פוגעות בסביבת העבודה.
- מסירה והדרכה. מוסרים תיעוד, תקנון בקשת גישה ונוהל רוטציית מפתחות. מכאן ואילך צוות הלקוח מנהל את הגישות בעצמו.
חבילת מסירה: קונפיגורציות, סכמות ותקנונים
בסיום הגדרת Yandex IAM נשאר לצוות לא „גישה שעובדת“, אלא חבילת ארטיפקטים שלפיה תמשיכו לחיות בלעדינו. כל מסמך מונח לצד קונפיגורציית הגישה, מתעדכן באותו שינוי ועובר בדיקה לפני יישום — אחרת הוא מתיישן בשבוע השני.
- תיאור תפקידים — מה כל תפקיד פותח, היכן הגבולות בין הרשאות קרובות ואיזו לקחת כברירת מחדל למפתח, לתורן ולמתאר הבנייה.
- מטריצת סמכויות — טבלה „צוות / משאב / תפקיד / תחום פעולה / תוקף“: מיד רואים למי יש גישה לפרודקשן ובאיזה בסיס.
- סכמות גישה — כיצד קשורים חשבונות שירות, פדרציית חשבונות וקבלנים חיצוניים, דרך איזו נקודת כניסה כל אחד נכנס.
- תקנון גישה — סדר הקצאה, הארכה וביטול: מי מאשר, תוך כמה זמן, מה לעשות עם פיטורי עובד או עזיבת קבלן.
- הוראות לתורן — מה לבדוק ביומנים, איזה תפקיד להסיר מיד, כיצד לתת גישה זמנית לבירור ולהחזיר את הקונפיגורציה למצב ההתחלתי.
- ספירת מלאי של חשבונות שירות — רשימת מפתחות עם בעלים ומועדי רוטציה; חסרי בעלים ופגי תוקף מנותקים, ולא נשכחים.
- מסירה להפעלה — מעבר לפי רשימת בקרה יחד עם המהנדס שלכם: הגישות משוחזרות מהקונפיגורציה, ולא חיות בהתכתבות.
החבילה מיועדת להחלפת הרכב הצוות: מהנדס חדש נכנס לגישות לפי ההוראות, ולא לפי הודעות של אחרים בצ׳אט. לאחר המסירה נישאר בקשר לבירור מקרים שנויים במחלוקת, עד שתתחילו לנהל את המתאר לגמרי בעצמכם.
מקרה בוחן: הרשאות יתר בסביבת ענן וביטולן
לפני העבודות, מתאר הענן נבנה באופן ספונטני: לכל צוות היו חשבונות שירות משלו, תפקידים ניתנו ישירות לאנשים „כדי לא לעכב שחרור“, ומפתחות גישה סטטיים נשמרו במאגרים וחיו עד ביטול ידני.
איש לא יכול היה לענות למי יש כעת הרשאות מנהל ואילו מהן באמת בשימוש — ביקורת בסביבת ענן לא נערכה אצלנו אף פעם.
מה הראה ניתוח הגישה
הוצאנו את כל קישורי התפקידים ב-Yandex Cloud, השווינו אותם ליומני הפניות בפועל בתקופה מקבילה ואספנו תמונה לגבי כל גורם. התברר שיותר ממחצית הסמכויות שהוקצו לא היו בשימוש אף פעם, ושליש מחשבונות השירות החזיקו בהרשאות ברמת מנהל במקום שבו הספיקה גישה לקריאה בלבד של האובייקט. ממצא נפרד היו מפתחות ללא בעלים: העובד עזב, החשבון נשאר פעיל, והחתימה המשיכה לעבוד.
מה שינו בסכמה
קישורי תפקידים ישירים לאנשים הוסרו — גישה ניתנת רק דרך קבוצות, וההרשאות מתוארות במדיניות ברמת הקטלוג והמשאב. לכל משימה נוצר חשבון שירות נפרד עם תפקיד מינימלי מספיק במקום חשבון משותף „להכול“, ומפתחות סטטיים הוחלפו בקצרי-חיים עם רוטציה אוטומטית. לכל מפתח נוצר בעלים ותוקף, והארכה — רק בפעולה מודעת, לא מאינרציה.
מדדים לפני ואחרי
שיעור הרשאות היתר הצטמצם מ-48% ל-7% מהסמכויות שהוקצו, מספר המפתחות הפעילים — כמעט פי שלושה, ואף תהליך עבודה לא נעצר. זמן ביטול הגישה עם פיטורין או החלפת תפקיד ירד מכמה ימי התכתבות ידנית לפעולה אחת עם קבוצה — דקות, עם רישום ביומן.
בירור תקרית מתחיל כעת לא בשאלה „למי בכלל יש גישה“, אלא ברשימה מוכנה: ההרשאות מתוארות דקלרטיבית, והמצב הנוכחי של המתאר משוחזר מהקונפיגורציה, לא מזיכרון המנהל.
במה שונים תפקידים ברמת הארגון והמשאב?
תפקיד ברמת הארגון ניתן לכל הארגון: הגישה חלה על כל העננים, הקטלוגים והמשאבים שבתוכו, כולל אלה שייווצרו מאוחר יותר. הרשאות למשאב מסוים מוקצות לנקודה — קטלוג, דלי, אשכול, מכונה וירטואלית — ואינן פועלות מחוץ לגבולותיו.
ב-Yandex Cloud פועלת ירושה לפי היררכיה: ארגון → ענן → קטלוג → משאב. תפקיד שניתן ברמה העליונה עובר בירושה למטה אוטומטית, ואין במודל כללי איסור — ההרשאות רק מצטברות. לכן אי אפשר לצמצם גישה שניתנה לארגון בדיעבד: נותר לבטל את התפקיד כולו ולהקצות מחדש באופן נקודתי.
מכאן כלל מעשי. תפקידים ברמת הארגון מתאימים למעגל מצומצם: מנהלי חיוב, אבטחת מידע, ביקורת — אלה שלפי התקנון זקוקים לסקירה של כל הקטלוגים. לחשבונות שירות ולקבוצות עבודה אנו נותנים הרשאות על קטלוג או משאב מסוים: אז תחום פעולת ההרשאות חופף לאזור האחריות של הצוות.
הסיכון של סמכויות רחבות מתגלה בשני מקומות. חשיפה של מפתח חשבון שירות עם תפקיד בארגון פותחת גישה לכל התשתית, והביטול דורש לעבור על כל המערכות שבהן מונחת עותק של המפתח. ביומן הביקורת הפעולה נראית, אבל מאחורי חשבון אחד עומדים עשרות תרחישים — בירור התקרית הופך לחיפוש ידני.
בביקורת אנו סוגרים זאת כך: אוספים מלאי של תפקידים וקישורים, משווים את תחום פעולת ההרשאות למשימות בפועל, מסירים מיותר, ומנפיקים מחדש מפתחות עבור קטלוגים מסוימים. הגישה נשארת מנוהלת עם גידול מספר השירותים.
ספקות טכניים נפוצים בנוגע לגישה ולמפתחות
צוות הלקוח לפני ההתחלה שואל אותן שאלות: האם הפרודקשן ייעצר עם החלפת תפקידים, מה לעשות עם הרשאות שהצטברו במשך שנים, ואיך להתמודד עם קבלנים שיש להם כעת גישה משותפת. להלן כיצד אנו עונים עליהן בפועל.
בנפרד שואלים על חזרה לאחור: אם ההקצאה תתגלה כשגויה, כמה זמן לוקחת החזרה למצב הקודם והאם נשאר עקבות של מי בדיוק הקצה את הגישה.
החלפת הרשאות תעצור שירותים פעילים?
לא, אם מחליפים בסדר הנכון. תחילה מסירים מפה של פניות בפועל לפי יומן הביקורת, אחר כך נותנים קישורי תפקידים חדשים, ורק לאחר תקופת פיקוח מחליטים לבטל את הישנים.
הביטול נעשה בקבוצות עם הפסקות — חוסר זמינות אפשרי רק במקום שבו השירות מחזיק מפתח ארוך-חיים, ומקומות כאלה אנו מוצאים לפני השינויים, לא אחריהם.
הצטברו אצלנו במשך שנים הרשאות מיותרות — האם נצטרך לבטל אותן בעיוורון?
לא. אוספים מפה „חשבון שירות — תפקיד — משאב“ ומשווים לפניות אמיתיות בתקופת הפיקוח. תפקידים שאין אליהם פניות מסומנים כמועמדים לביטול, אך איננו נוגעים בהם עד שהלקוח יאשר שהשירות אינו בשימוש עונתי. הביטול מלווה ביומן: רואים מה היה, מה נהיה ומה הוחזר לאחור.
קבלנים חיצוניים זקוקים לגישה — איך לא לתת מיותר?
הקבלן מקבל חשבון שירות משלו, מוגבל לקטלוג הנדרש ולתקופת תוקף, ולא מפתח של חשבון משותף. עם סיום העבודות, הגישה מבוטלת בפעולה אחת, בלי לחפש עקבות בקונפיגורציות זרות. מפתחות הקבלן מסובבים לפי לוח זמנים עם חפיפה: מפתח חדש ניתן ונבדק לפני ביטול הישן, כדי שלא יהיה חלון של חוסר זמינות.
איך לוודא שההרשאות מוגדרות נכון?
מריצים בקשות בדיקה בשם כל חשבון שירות — גם חיוביות וגם שליליות: גישה לקטלוגים זרים צריכה להיות אסורה. קונפיגורציות הגישה מנוהלות כקוד, לכן כל שינוי מתועד בגרסאות ומוחזר למצב הקודם. סקירת ההרשאות נכנסת למחזור קבוע, כדי שהצטברות לא תתחיל מחדש.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי שביקורת תפקידים וחשבונות שירות ב-Yandex IAM תניב תוצאה, יש צורך בגישה לתמונה אמיתית של ההרשאות, לא לתיאור שלה. השיחה הראשונה נמשכת כשעה: מפרטים אילו צוותים וקבלנים חיצוניים עובדים עם הענן, היכן מונפקים מפתחות סטטיים, וכיצד בנוי קו הבנייה והפריסה. בנפרד מדברים על מה שכבר כואב: כשלי פריסה, תפקידי יתר, מפתחות שאיש לא ביטל.
מה להכין לקראת ההתחלה:
- רשימת העננים, הקטלוגים והפרויקטים שנכללים בביקורת;
- רשימת חשבונות שירות וייעודם: בנייה, פריסה, ניטור, גישה לאחסון;
- כיצד ההרשאות ניתנות כעת — דרך קונסולה, מניפסטים של תשתית כקוד, סקריפטים או ידנית;
- נקודות אינטגרציה: קו פריסה, תזמור, קבלנים חיצוניים עם גישה;
- דרישות להפרדה: אילו סביבות ונתונים אסור לערבב, היכן נדרשת הפרדת תפקידים;
- מהנדס שאחראי על הגישות ומאשר החלטות במהלך העבודות.
גישות לצורך הביקורת אנו מבקשים מינימליות — קריאת מדיניות ומטא-נתונים של חשבונות. בתפקידים ובמפתחות עצמם איננו נוגעים בשלב הבירור: השינויים מתבצעים בשלב נפרד, לאחר אישור הסכמה.
בסיום אנו חוזרים עם תוכנית עבודה לגישה: שלבים, סדר העברת חשבונות שירות, נקודות חזרה לאחור, הערכת לוחות זמנים ומודל תפקידים יעד. אם חלק מהנתונים חסוי — מתעדים זאת בתוכנית ומציעים במה להחליפו.
תארו את המשימה — נחזור עם הערכה ותוכנית.