הגדרת AWS IAM (Identity and Access Management)

IAM AWS: מדוע הרשאות הופכות לצוואר בקבוק

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

איש אינו זוכר מדוע כל הרשאה נמצאת שם, וניסיון להסיר אותה עלול להפיל תהליך עבודה, ולכן משאירים אותה. כך IAM AWS מכלי בקרה הופך למקור של אי-ודאות: פורמלית הרשאות יש לכל מי שאמור, אך בפועל — לכל מי שאי פעם ביקש.

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

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

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

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

מה נותנת מודל גישה בנוי היטב

הנפקת גישות תוך דקות במקום ימים

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

שגיאות הרשאות מפסיקות להפיל את הפרודקשן

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

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

משטח התקיפה מצטמצם, הביקורת מואצת

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

ניהול סיכונים הופך למדיד

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

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

גישות לארגון גישה: השוואה

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

כיצד לבחור ביניהם

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

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

שלבי יישום ניהול הרשאות גישה

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

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

1. ביקורת הרשאות גישה. מרכזים חשבונות, קבוצות, תפקידים ומדיניויות במרשם אחד, ומצליבים אותם עם יומני הפניות. מסמנים הרשאות שאינן בשימוש, הרשאות עודפות ומפתחות שירות ללא בעלים.
2. עיצוב תפקידים. מפרקים את האחריות לתפקידים: קריאה בנפרד, שינוי בנפרד, ניהול בנפרד. קובעים היכן נדרשת גישה זמנית והיכן קבועה, ומי משמש כבעלים של כל תפקיד.
3. הגדרת מדיניויות. כותבים מדיניויות עם איסור מפורש כברירת מחדל והרשאה ממוקדת לפעולות ולמשאבים ספציפיים. התנאים מגבילים את הגישה לפי מקור הבקשה, תגיות המשאב ודרישת אימות רב-גורמי.
4. בדיקת גישה. מריצים תרחישים מנקודת המבט של כל תפקיד: מה אמור לעבוד ומה חייב להידחות. בודקים מקרי קצה — גישה למשאבים של אחרים, ניסיונות הסלמת הרשאות, עבודה מרשת שאינה מהימנה.
5. העברת עומסי עבודה. מעבירים שירותים וצוותים לתפקידים החדשים בקבוצות קטנות, ומשאירים את ההרשאות הישנות ברזרבה עד לאישור ששום דבר לא נשבר.
6. תיעוד. מתעדים את מודל התפקידים, את ייעודה של כל מדיניות, את הבעלים ואת סדר הענקת הגישה הזמנית. מתארים כיצד להוסיף עובד חדש וכיצד לשלול הרשאות עם עזיבתו.
7. מסירה ותקנון. מוסרים לצוות את סכמת הגישה ואת כללי בחינת ההרשאות מחדש, ומסכמים על ביקורת תקופתית כדי שהמודל לא יתמלא בחריגים.

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

מדיניות גישה ותפקידים: מה מגדירים

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

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

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

מקרה בוחן: קיצור זמן מתן ההרשאה פי 4

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

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

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

מה השתנה במספרים

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

במה נבדלות תפקידים ממדיניות ב-IAM של AWS?

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

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

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

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

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

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

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

ספקות טכניים נפוצים

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

יש לנו כמה חשבונות. האם יהיה צורך להגדיר תפקידים בכל אחד בנפרד?

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

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

כיצד להבטיח ביקורת ולהוכיח מי ומתי קיבל גישה?

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

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

מה יקרה אם תפקיד הוגדר עם שגיאה והגישה תהיה רחבה מהנדרש?

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

תארו את סכמת הגישה הנוכחית שלכם ומספר החשבונות — נחזור עם הערכה ותוכנית מיגרציה.

נדון במשימה שלכם בנושא הרשאות גישה

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

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

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

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