המלצות לניהול זהויות נכון בAWS IAM
המלצות לניהול זהויות נכון בAWS IAM
1) הגבלת השימוש בחשבון הבסיס של AWS
כאשר רושמים חשבון AWS חשבון המשתמש ההתחלתי שנוצר נקרא חשבון root לחשבון זה יש גישה מלאה לכל משאב של AWS כולל פרטי חיוב, מה שהופך אותו לחשבון המשתמש החסוי ביותר. מאחר שאין אפשרות להגביל את הרשאות אישורי חשבון הבסיס, מומלץ לגשת אל חשבון הבסיס למשימות שניתן להשלים רק באמצעות חשבון הבסיס (כגון יצירת חשבון הניהול הראשון). עבור כל המשימות האחרות, צור משתמש IAM בעל הרשאות ניהול, והשתמש בו כדי לנהל את סביבת ה- AWS שלך על בסיס יומיומי.
2) "סובב" את מקשי הגישה לחשבון השורש ואפשר אימות של multifactor (MFA)
לא משנה כמה פעמים נעשה שימוש בחשבון הבסיס של AWSמומלץ מאוד שמפתחות הגישה לחשבון ייסובו על בסיס קבוע באמצעות דף אישורי האבטחה, ו- MFA שמופעל לשימוש בחשבון הבסיס.
3) לעולם אל תשתף אישורי חשבון AWS
במקום לשתף חשבונות AWS צרו משתמשי IAM נפרדים עבור עובדים שצריכים לגשת למשאבי AWS זה יאפשר להקצות קבוצה ייחודית של הרשאות למשתמשים שונים על פי דרישות העבודה שלהם.
4) אם ניתן, השתמש במדיניות מנוהלת של AWS כדי להקצות הרשאות
אמזון מספקת קבוצה מוגדרת מראש של מדיניות מנוהלת לחלוטין על ידי AWS ולקוחות אינם רשאים לערוך את ההרשאות. מדיניות זו מיועדת לשמש במקרים נפוצים, תוך הקלת אכיפת מדיניות גישה, מאשר יצירת מדיניות בעצמך מחדש.
5) הקצאת הרשאות ברמת קבוצה / תפקיד ולא ברמת IAM בודדת
הימנע מהקצאת מדיניות מנוהלת על-ידי הלקוח למשתמשי IAM נפרדים או הגדרת מדיניות מוטבעת בעת יצירת משתמש IAM במקום זאת הקצו מדיניות לקבוצה של משתמשי IAM או כתבו מדיניות מוטבעת בעת יצירת קבוצת פעולה. הדבר מפחית את הסיכון של מתן בטעות הרשאות גבוהות שלא לצורך למשתמשים פרטיים.
6) לעולם אין להעניק הרשאות מעבר למינימום הנדרש עבור משתמש או קבוצה כדי למלא את דרישות העבודה שלהם
אחת הטעויות הנפוצות ביותר בעת הקצאת משתמשי AWS היא להעניק להם הרשאות מעבר למה שנדרש מינימלית. למרות שזה יכול להיות מהיר יותר כדי ליצור משתמשי IAM מבלי לבחון את הרשאות שהוקצו, הדבר מגדיל באופן משמעותי את הנזק הפוטנציאלי במקרה של אובדן או גניבת משתמש הרשאות.
7) קבע מקצב קבוע כדי לבדוק הרשאות IAM
כנוהג המומלץ לאבטחה, חשוב לעיין בקביעות במדיניות ה- IAM של הארגון. כל מדיניות מגיעה עם סיכום מדיניות, וזה מקום טוב להתחיל בו בעת ביקורת מדיניות IAM .AWS מספקת ארבע רמות גישה לכל אחד משירותיה: רשימה, קריאה, כתיבה וניהול הרשאות.
יש להעניק את רמת הגישה לרשומות כתיבה וניהול הרשאות בזהירות. ניהול הרשאות מאפשר למשתמש להעניק או להגביל הרשאות משאבים עבור הארגון כולו ומשתמשי ה- AWS שלו.
8) לאכוף מדיניות סיסמה חזקה עבור כל משתמשי AWS
רוב המשתמשים יבחר סיסמה קלה לנחש למרות הסיכונים האבטחה שלה. הגדר אורך סיסמה מינימלי של לפחות 14 תווים
דרוש תווים שאינם אלפביתיים, לפחות אלפבית אחד גדול, וסמל
הגדר מדיניות תפוגה של סיסמה ולא מאופשר שימוש חוזר בסיסמה
לבטל שימוש במילות מפתח בסיסמאות שלהם.
9) אפשרו אימות "רב-גורמים" MFA עבור כל משתמשי IAM
ארגונים צריכים להניח שלפחות חלק מאישורי המשתמשים בשירות הענן שלהם כבר נפגעו. מאחר שלעובדים יש נטייה להשתמש מחדש בסיסמאות בכל השירותים, הפעלת MFA צריכה להיות דרישה לא רק עבור AWS אלא גם לכל שירות ענן הנמצא בשימוש בארגון.
קביעת תצורה של AWS עם ספק כניסה יחיד כגון Okta, Ping Identity או Azure Active Directory יכולה להקל על החיכוך באמצעות הפעלת MFA על ידי תקנון גורמי אימות בכל היישומים של העובדים.
10) השתמשו בתפקידים (roles) של IAM עבור יישומים מותאמים אישית הפועלים ב- AWS EC2
כל יישום המחייב גישה לשירות AWS אחר כדי לתפקד יצטרך אישורים משלו. כאימון הטוב ביותר, השתמשו בתפקידים של IAM כדי לספק אישורים ליישום. כאשר משתמשים מפעילים לראשונה מופע EC2 הם יכולים לקבוע את התפקיד עבור מופע זה, כל יישום שנפרס באותו מופע EC2 יכול להשתמש באישורי התפקיד כדי לגשת למשאבי AWS אחרים. האישורים יהיו דינמיים ו- AWS יסובב אותם באופן אוטומטי לאבטחה נוספת.
11) להסיר משתמשים שאינם בשימוש
כדי למזער את הסיכון של אישורי משתמש IAM להגנב, כל משתמש IAM מיותר צריך להמחק או גישתו אמורה להחסם. עובדים שאינם עובדים עוד בארגונים או אלה שעברו לעבוד במחלקה אחרת שאינה זקוקה לגישה ל – AWS אינם אמורים לקבל גישה ל – AWS ארגונים צריכים לבדוק את פעילות המשתמשים שלהם ב- IAM כדי לראות אילו משתמשים לא נכנסו ל- AWS לפחות 90 יום, וגם לבטל את ההרשאות שלהם.
12) ארגונים המשתמשים במידע רגיש או מוסדר מאוד (כגון שירותי בריאות, כספים, ממשל פדרלי) צריכים להשתמש בתנאי מדיניות כאמצעי אבטחה נוסף
תנאי המדיניות הם משתנים הקובעים האם קיימת התאמה בין מדיניות לבין בקשה. יש מספר בלתי מוגבל של תנאים שיכולים לשמש למדיניות IAM תנאי המדיניות שימושיים במיוחד כאשר עובדים עם שותפים וספקים של צד שלישי הזקוקים לגישה למשאבי ה- AWS של הארגון שלך. להלן כמה מהתנאים המומלצים שיש להשתמש בהם:
השתמש ב תאריך / שעה כדי להגביל את הגישה למשאבים כך שמשתמשי IAM יוכלו לגשת למשאב רק במהלך ימי השבוע למשך יום העבודה / משמרת שלהם.
הגדר תנאים המוסיפים כתובות IP שמותר להן לגשת למשאבי AWS כדי להבטיח שרק כתובות IP מהימנות יוכלו לגשת למשאב של AWS.
לעובדי חוזה / שותפים, יש לקבוע תאריך סיום, לחסום גישה למשאבי AWS לאחר מועד סיום החוזה.
השתמש רק בתנאי מדיניות שעומדים בדרישות האבטחה והתאימות של הארגון שלך, מבלי לפגוע בפרודוקטיביות העובדים.
13) מעקב אחר פעילות המשתמשים בכל שירותי הענן (כולל פעילות משתמשי IAM כדי לזהות פעילות חריגה המעידה על איומים הנובעים מחשבונות שנפגעו, או על ידי עובד פנימי זדוני / רשלני
אמזון תומך בניטור פעילות AWS עם AWS CloudTrail עם זאת, ארגונים צריכים לפקח על פעילות AWS לצד כל שירותי הענן האחרים כדי להשיג תצוגה מאוחדת של כל פעילות הענן. זה יעזור להפריד במדויק איום אמיתי מפני התראה חיובית שקרית .
מדריך הטמעה אינטראקטיבי:
שירות ה (IAM (Identity and Access Management הינו שירות המאפשר לנו ניהול זהויות והרשאות לשימוש בתשתיות ושירותי הענן השונים.
מדריך זה ילווה אתכם (בחמישה שלבים קצרים) בהגדרות הראשוניות שמומלץ לבצע לאחר הקמת חשבון AWS חדש ובהענקת הרשאות למשתמש בשירותי Ec2 ו S3
ראשית התחברו לקונוסול הניהול של AWS שימו לב לכל אורך המדריך אנחנו מנהלים את הרשאות המשתמשים ומדיניות האבטחה באמצעות משתמש הroot שהינו משתמש ברירת המחדל שעמו יצרתם את החשבון.
לאחר החיבור יש לגשת לקונוסול הניהול של שירות ה IAM, ניתן לגשת באמצעות שורת החיפוש או דרך התפריט Services->Security, Identity & Compliance.
שלב ראשון – מחיקת Access key למשתמש ה root
ה Access key מאפשר למשתמשים גישה באמצעות API על מנת לגשת ולתפעל שירותים שונים.
כפי שציינתי קודם משתמש ה root הינו משתמש ברירת המחדל ולכן בעל הרשאות הגישה הגבוהות ביותר.
שימוש בחשבון זה לתפעול שירותי AWS למעט IAM ובילינג אינו מומלץ ולכן יש להגביל אותו לשימוש קונסול הניהול בלבד.
כעת אם נחזור לDashboard שלנו נוכל לראות כי סיימנו את המשימה הראשונה ביישום המלצות האבטחה של AWS.
שלב שני – הפעלת MFA לחשבון ה root
אני מאמין שעד כאן כבר הבנתם את חשיבות משתמש ה root ואבטחתו ולכן נעבור להפעלת ה MFA
על מנת להוסיף שכבת אבטחה נוספת מלבד שם המשתמש והסיסמא אמזון עושה שיתוף פעולה עם פתרון ה OTP של Google
כדי לסנכרן את המכשיר הנייד לקבלת סיסמא חד פעמית בחיבור לקונסול הניהול , יש להוריד למכשיר את אפליקציית Google Authenicator. לאחר מכן סריקת הברקוד על המסך והכנסת 2 סיסמאות רצופות כדי לסנכרן את ה OTP של גוגל עם חשבון ה root באמזון.
שימו לב: ניתן להגדיר MFA בהמשך גם למשתמשים הארגוניים שלכם (מומלץ) ולא רק למשתמש ה root
מצ"ב אנימציה בהוספת MFA:
שלב שלישי – יצירת משתמשים
לאחר שאבטחנו את חשבון ה root ניתן להתקדם וליצור את המשתמש הראשון שלנו.
לצורך הדגמה ניצור משתמש admin שאליו נשייך בהמשך הרשאות מלאות על שירותי EC2 ו S3.
שימו לב כי ניתן ליצור משתמש בעל גישה ל API בלבד בדוגמא שלנו ניצור משתמש שניתן להתחבר עמו לקונסול בלבד.
יצירת מפתחות גישה תמיד זמינה לאחר יצירת המשתמש. באופציית הסיסמא ביקשתי מהמערכת לספק לי סיסמא עבור המשתמש.
כעת נשייך הרשאות Full access לשירות ec2.
בסיום לאחר יצירת המשתמש ניתן לצפות בסיסמא ולהעבירה אל המשתמש.
שימו לב כפתור ה send email ישלח למשתמש לינק לקונסול הניהול הארגוני שלנו (נרחיב עליו בהמשך) ללא סיסמא.
שלב רביעי – יצירת קבוצות משתמשים
ניהול קבוצות משתמשים מאפשר לנו לנהל הרשאות בצורה קלה יותר ולשייך אותן לקבוצת משתמשים בנוסף להרשאות הספציפיות שניתנו להם .
כעת ניצור קבוצה בשם s3-fullaccess עם הרשאה תואמת לשירות s3. בסיום נשייך את המשתמש שלנו אל הקבוצה.
יצירת קבוצה בשם s3-fullaccess.
שיוך policy עם הרשאות S3FullAccess.
ולסיום לאחר שיצרנו את הקבוצה ניגש אל תפריט ה groups מצד שמאל ל Dashboard ונשייך משתמשים אל הקבוצה.
כעת אם נסתכל על הרשאות המשתמש נוכל לראות כי הוא ירש את ההרשאות מהקבוצה והספציפיות שניתנו לו קודם לכן.
גשו ל Users->admin->Permissions.
שלב חמישי – הקשחת מדיניות סיסמאות
מומלץ להקשיח מדיניות סיסמאות במיוחד בסביבות מרובות משתמשים. יש לזכור כי משתמשים מסוימים יכולים לקבל הרשאות לאיפוס סיסמאת משתמש ה IAM ולכן חשוב על כל מקרה להקשיח את מדיניות קביעת הסיסמאות.
להלן דוגמא:
שינוי דומיין גישה לפורטל הארגוני
כפי שציינתי בשלב השלישי (יצירת משתמש) , משתמשים ניגשים לקונסול הניהול דרך דומיין נפרד מחשבון ה root.
הדומיין שמתקבל מכיל את קוד הארגון ש AWS יצרה עבורכם, מדובר במספר ארוך שלא נוח לזכור.
ניתן להגדיר את אותו דומיין כשם הארגון (במידה ופנוי) ולהקל על המשתמשים לזכור את כתובת ממשק הניהול שבברירת המחדל.
כעת ניתן להפנות משתמשים תפעוליים ללינק החדש
דוגמא לסקריפט שעושה אודיט על IAM בAWS:
1 Identity and Access Management *********************************
1.1 Avoid the use of the root account (Scored). Last time root account was used
1.2 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password (Scored)
1.3 Ensure credentials unused for 90 days or greater are disabled (Scored)
User list:
k1.4 Ensure access keys are rotated every 90 days or less (Scored)
Users with access key 1 older than 90 days:
<root_account>
Users with access key 2 older than 90 days:
1.5 Ensure IAM password policy requires at least one uppercase letter (Scored)
FALSE
1.6 Ensure IAM password policy require at least one lowercase letter (Scored)
FALSE
1.7 Ensure IAM password policy require at least one symbol (Scored)
FALSE
1.8 Ensure IAM password policy require at least one number (Scored)
FALSE
1.9 Ensure IAM password policy requires minimum length of 14 or greater (Scored)
FALSE
1.10 Ensure IAM password policy prevents password reuse (Scored)
FALSE
1.11 Ensure IAM password policy expires passwords within 90 days or less (Scored)
FALSE
1.12 Ensure no root account access key exists (Scored)
Found access key 1
OK No access key 2 found
1.13 Ensure hardware MFA is enabled for the root account (Scored)
OK
1.14 Ensure security questions are registered in the AWS account (Not Scored)
No command available for check 1.14
Login to the AWS Console as root, click on the Account
Name -> My Account -> Configure Security Challenge Questions
1.15 Ensure IAM policies are attached only to groups or roles (Scored)
Users with policy attached to them instead to groups: (it may take few seconds…)
toni
מעט כל ארגון משתמש כיום במספר סוגי אפליקציות ושירותי ענן, גם אם הוא אינו מודע לכך.
זה יכול להיות משהו קטן כגון פייסבוק ארגוני, טוויטר ארגוני או לינקדאין, DropBox וכו'
זו יכולה להיות מערכת מרכזית בארגון כגון CRM בענן מייקרוסופט, SalesForce וגם Office365.
מן הסתם לכל מערכת יש את סוג ההזדהות משלה (משתמשים וסיסמאות) אותה מנהלים המשתמשים.
זה מתחיל להסתבך כשמשתמש צריך לזכור יותר מסיסמא אחת (סיסמת דומיין שמימלא מתחלפת אחת לכמה זמן).
גם להגדיר single sign on עבור כל מערכת בנפרד זה חתיכת כאב ראש.
ואיך בכלל עוקבים אחרי Logins של משתמשים ומנהלים הסרת אפליקציות ממשתמשים? בוודאי במצבים של אפליקציות המאפשרות גישה ממכשירים סלולאריים או מכל ממשק אינטרנטי.
לדוגמא, מערכת פייסבוק \ טוויטר ארגונית. מספר עובדים אחראים להכניס תוכן. לכולם יש את נתוני הכניסה למערכת. מה קורה כשאחד מהעובדים עוזב או עובר מחלקה? צריך לשנות את הסיסמא וליידע את כולם. סביר להניח שזה לא ייקרה במיידי אם בכלל (וזה בעייתי שבעתיים במערכות קריטיות).
בואו נראה מהם הצרכים של מחלקות ה IT ממערכת של ניהול זהויות גלובאלית:
- אפשרות לקשר למשתמש אפליקציה עננית עם הסיסמא והמשתמש כבר בפנים (באופן שהוא אינו יודע אותה) והכניסה לכל מערכת כזו הייתה רק עם המשתמש הדומיין שלוSSO) )
- בעת ביצועDisable למשתמש בדומיין, יבוצע ניטרול של אותו משתמש מכל אפליקציה עננית (הרי הוא אינו יודע את המשתמש והסיסמא לאפליקציה).
- התממשקות מלאה לאפליקציות ענן – משתמש לאפליקציה נניח SaleForce וזה היה בונה את המשתמש באפליקציה – Provision ולחילופין לבצע Disable למשתמש הדומיין וזה היה מבצע Deprovision
- לספק למשתמש מנגנון איפוס סיסמא (דומיין) דרך האפליקציה וזה היה מאפס את הסיסמא גם בדומיי.
- מנגנון Audit מלא שלא רק יתריע, אלא יחסום במקרה של זיהוי מספר כניסות ממקומות גיאוגרפים שונים וכו'
הענן של מייקרוסופט, Azure, מאפשר לנו להקים מערך זהויות שנקרא Azure Active Directory במערך הנ"ל אפשר להקים משתמשים או לחילופין לסנכרן משתמשים מה Active Directory On Prem שלנו. ממש כפי שמתבצע באופיס 365. בנוסף נותן לנו מספר כלי Audit אשר מאפשרים חקירה ותיעוד של משתמשים ברמה מאוד פרטנית ונוחה לשימוש – מערכת siem ואנומליה מאוד שימושית המתאימה לתקני אבט"מ מחמירים.
מייקרוסופט בשום אופן אינה מחזיקה את הסיסמאות של הדומיין On Prem בענן.
כיום, כאשר מספר רב של ארגונים עבר לאופיס 365, הוא למעשה מחזיק את ההזדהויות שלנו
ב Azureיש באפשרותנו להשתמש במנגנון זיהוי זה, ולבצע SSO עבור מגוון גדל והולך של אפליקציות SAAS. כמובן שניתן להרים מנגנון זה ללא אופיס 365.
מיקרוסופט הוציאה כלי Azure Active Directory Connect Tool שמחליף את כלי הסנכרון הישנים ומבצע התקנה פשוטה ומהירה. ברשותנו האפשרות לבחור למשל, הגדרת AD FS או סנכרון Password Hash המועדף עלי, גם מטעמי אבטחה הכלי הזה מאפשר גם לבצע Password Write Back מהענן אל הOn Prem.
דוגמא,
מה שעלי לבצע הוא לגשת ל Application Tab ולבחור אפליקציה מהגלריה או אפליקציה שפיתחתי בעצמי או מקומית
להגדיר SSO ולאיזה משתמשים תהיה גישה.
כל מה שהמשתמש צריך לבצע הוא לגלוש ל https://myapps.microsoft.com . ולקבל את כל האפליקציות המאופשרות עבורו. יש גם ממשק דרך אפליקציות לסלולארי
נכנס עם הסיסמא מאחורי הקלעים וישר מבצע login באופן אוטומטי