במאמר הזה מתוארות שיטות מומלצות לשימוש בבקרת גישה מבוססת-הקשר כדי להגן ביעילות על המשאבים שלכם ב- Google Cloud . בקרת גישה מבוססת-הקשר היא גישה לאבטחה שבה אתם שולטים בגישה של המשתמשים על סמך עוצמת האימות שלהם, מצב האבטחה של המכשיר, מיקום הרשת, מיקום גיאוגרפי או מאפיינים אחרים. הגישה הזו לא מסתמכת רק על זהויות משתמשים בסיסיות כדי לאפשר גישה מאובטחת, והיא יכולה לעזור לכם להטמיע מודל אבטחה של אפס אמון כדי לשפר את מצב האבטחה הכולל. במאמר בנושא אבטחת אפליקציות ומשאבים באמצעות בקרת גישה מבוססת-הקשר מוסבר איך להטמיע בקרת גישה מבוססת-הקשר לסוגים שונים של אפליקציות ומשאבים.
כדי לאבטח את האפליקציות והמשאבים שלכם, אתם יכולים להגדיר בקרת גישה פרטנית על סמך מגוון גורמים תלויי הקשר ושילובים שלהם. Google Cloud אתם יכולים להשתמש ב-Access Context Manager כדי להגדיר מדיניות גישה, שכוללת רמות גישה ופרמטרים של שירותים.
המסמך הזה מיועד לכל מומחה אבטחה שאחראי על ניהול זהויות והרשאות גישה (IAM) ועל האבטחה של משאבים ואפליקציות. Google Cloud במסמך הזה אנחנו מניחים שאתם כבר מכירים את Access Context Manager,Google Cloudואת ניהול הזהויות והרשאות הגישה (IAM).
גישות לבקרת גישה מבוססת-הקשר
כשמגדירים בקרת גישה מבוססת-הקשר בארגון, צריך להחליט אם רוצים להחיל את בקרת הגישה מבוססת-הקשר על אפליקציות, על משאבים או על שניהם. כדי לקבל החלטה כזו, כדאי להבחין בין סוגים שונים של אפליקציות ושירותים:
- אפליקציות אדמיניסטרטיביות: האפליקציות האלה מאפשרות למשתמשים לנהלGoogle Cloud משאבים כמו מכונות וירטואליות, מערכי נתונים של BigQuery או דליים של Cloud Storage, או ליצור איתם אינטראקציה. דוגמאות לאפליקציות אדמיניסטרטיביות כוללות את מסוף Google Cloud , Google Cloud CLI, Terraform ו-IAP Desktop.
- אפליקציות עסקיות: האפליקציות האלה כוללות אפליקציות אינטרנט שפועלות ב-Google Cloud ומשתמשות ב-SAML או בשרת proxy לאימות זהויות (IAP) לצורך אימות והרשאה. לפעמים האפליקציות האלה נקראות אפליקציות פנימיות. דוגמאות לאפליקציות עסקיות כוללות מערכות CRM, לוחות בקרה ואפליקציות מותאמות אישית אחרות.
- Google Workspace ושירותים אחרים של Google: השירותים האלה מסופקים על ידי Google, אבל הם לא קשורים ל- Google Cloud.
אפשר להבחין בין אפליקציות עסקיות לפי האופן שבו הן מטפלות באימות ובמתן הרשאות:
- SAML: אפליקציות שמשתמשות ב-SAML של Google Workspace לאימות. אפליקציות SaaS לרוב משתייכות לקטגוריה הזו.
- IAP: אפליקציות אינטרנט בהתאמה אישית שפרסתם מאחורי IAP.
- OAuth: אפליקציות אינטרנט או אפליקציות למחשב בהתאמה אישית שמשתמשות ב-OAuth 2.0 ומשתמשות באחד או יותר מהיקפי הרשאות OAuth.Google Cloud
בתרשים הבא מוצגת הגישה המתאימה ביותר לבקרת גישה מבוססת-הקשר עבור כל סוג של אפליקציה:
בתרשים מוצגים סוגי האפליקציות הבאים:
אפליקציות אדמיניסטרטיביות: בדרך כלל, חשוב יותר להגן עלGoogle Cloud המשאבים שהאפליקציה האדמיניסטרטיבית מאפשרת גישה אליהם, ולא על האפליקציה עצמה. כדאי להביא בחשבון את התרחישים הבאים:
- משתמש לא יכול לגשת לאף אחד מהמשאבים. בתרחיש הזה, סביר להניח שלגישה לאפליקציה אדמיניסטרטיבית אין ערך רב למשתמש.
- למשתמש יש גישה למשאב, אבל אין לו גישה לאפליקציית אדמין. במקרה כזה, יכול להיות שהוא יוכל למצוא אפליקציית אדמין אחרת שלא חסומה ותאפשר לו לגשת למשאב.
לכן, באפליקציות אדמיניסטרטיביות, מומלץ להתמקד במשאבים. כדי להחיל את אמצעי בקרת הגישה מבוססת-הקשר המתאימים על משאבים בצורה הכי יעילה, כדאי להשתמש בגבולות גזרה לשירות של ענן וירטואלי פרטי (VPC) עם כללי הכניסה המתאימים. אפשר להשתמש בהרשאות גישה כדי להשלים את הגדרת הגבולות של שירות ה-VPC.
אפליקציות עסקיות שמשתמשות ב-OAuth: חשוב להגן על הגישה לאפליקציות עצמן וגם על המשאבים שהאפליקציות עשויות להשתמש בהם. כדי להגן על האפליקציות באמצעות בקרת גישה מבוססת-הקשר, צריך להשתמש בהרשאות גישה.
אפליקציות עסקיות שמשתמשות ב-IAP: למרות ש-IAP משתמש ב-OAuth, אי אפשר להשתמש בהרשאות גישה כדי להגן על אפליקציות שמשתמשות ב-IAP לאימות משתמשים. במקום זאת, אפשר להגן על האפליקציות האלה באמצעות תנאי IAM.
אפליקציות עסקיות שמשתמשות ב-SAML: בדומה לאפליקציות עסקיות שמשתמשות ב-OAuth, חשוב להגן על הגישה לאפליקציות עצמן, וגם על המשאבים שהאפליקציות עשויות להשתמש בהם. כדי להגן על האפליקציות האלה, צריך להשתמש בבקרת גישה מבוססת-הקשר ב-Google Workspace.
Google Workspace ושירותים אחרים של Google: באפליקציות האלה, חשוב להגן על הגישה לאפליקציות עצמן, וגם על המשאבים שהאפליקציות עשויות להשתמש בהם. כדי להגן על האפליקציות האלה, צריך להשתמש בבקרת גישה מבוססת-הקשר של Google Workspace.
ניהול רמות גישה
בקטעים הבאים מתוארות השיטות המומלצות לשימוש כשמנהלים רמות גישה.
יצירה של רמות גישה לשימוש חוזר
רמות הגישה הן משאב גלובלי, והן מיועדות לשימוש במשאבים שונים בארגון שלכם. Google Cloud לכן, מומלץ להגביל את המספר הכולל של רמות הגישה, ולוודא שהן משמעותיות ורלוונטיות למספר משאבים. כמה נקודות שכדאי לחשוב עליהן:
- לא מומלץ להטמיע את השמות של משאבים או אפליקציות ספציפיים בשם של רמת גישה.
- אל תקודדו דרישות ספציפיות למשאבים או לאפליקציות ברמת גישה.
- משתמשים בשמות שמעידים על מצב אבטחה מסוים של משתמש או מכשיר, כמו
Fully Trusted Device.
שימוש ברמות גישה מורכבות
כדי לצמצם את התקורה של התחזוקה ולהבטיח עקביות כשמשנים את רשתות המשנה או האזורים, לא חוזרים על אותן דרישות בכמה רמות גישה. במקום זאת, כדאי להגדיר תלות בין רמות הגישה.
לדוגמה, אל תציינו את אותם אזורים מהימנים או רשתות משנה של כתובות IP בכמה רמות גישה, אלא צרו רמת גישה נוספת בשם Trusted location. רמת הגישה Trusted location יכולה לשמש כתלות לרמות גישה אחרות.
מתן פטור למשתמשים עם גישת חירום ברמות גישה
כדי למנוע נעילה בטעות, מומלץ להחריג לפחות משתמש אחד עם גישת חירום מכל רמות הגישה. כדי לוודא שהפטור חל על כל האפליקציות והמשאבים שרמת הגישה חלה עליהם, צריך להגדיר את הפטור ברמת הגישה עצמה:
- מוסיפים תנאי אחד שמגדיר את הדרישות הרגילות.
- מוסיפים תנאי נוסף עם
membersדרישה שמפרטת משתמש אחד או יותר עם גישת חירום. - מגדירים את פונקציית השילוב לתנאי
OR, כך שמשתמשים צריכים לעמוד רק באחד משני התנאים.
לדוגמה, רמת הגישה הבאה מגבילה את הגישה לשלושה אזורים, אבל
המשתמש emergencyaccess@example.net פטור מהדרישה הזו:
{
"name": "accessPolicies/…",
"title": "Example access level",
"basic": {
"conditions": [
{
"members": [
"user:emergencyaccess@example.net"
]
},
{
"regions": [
"DE",
"AU",
"SG"
]
}
],
"combiningFunction": "OR"
}
}
הגדרת הודעה לתיקון שגיאות
יכול להיות שהמשתמשים בארגון לא יודעים שהמיקום, המכשיר וגורמים אחרים יכולים להשפיע על האפשרות שלהם לגשת לאפליקציות מסוימות. כדי לעדכן את המשתמשים ולצמצם את מספר בקשות התמיכה, אפשר להגדיר הודעת תיקון שגיאות מותאמת אישית שתסביר למשתמשים מה הם צריכים לעשות כדי לקבל שוב גישה.
ניהול של הרשאות גישה
הגדרות של הרשאות גישה מאפשרות לכם להגדיר בקרת גישה מבוססת-הקשר לאפליקציות OAuth שמשתמשות בהיקף אחד או יותר של הרשאות. Google Cloud הקצאות גישה הן גם דרך יעילה לאכוף בקרת גישה מבוססת הקשר באפליקציות עסקיות.
בקטעים הבאים מתוארות שיטות מומלצות לשימוש בהרשאות גישה.
שימוש בקשירת גישה יחידה עם הגדרות בהיקף מוגבל
כשמשתמשים בהרשאות גישה, צריך לקחת בחשבון את המגבלות הבאות:
- לכל קבוצת Cloud Identity יכול להיות היקשר גישה אחד לכל היותר.
- אם יותר מהרשאת גישה אחת חלה על משתמש, הרשאת הגישה הפחות מגבילה מקבלת עדיפות.
כדי להתאים את עצמכם לשתי ההגבלות האלה, משתמשים בקשירת גישה יחידה שחלה על כל המשתמשים:
- יצירת קבוצה שמכילה באופן אוטומטי את כל המשתמשים בחשבון Cloud Identity או Google Workspace.
- יוצרים או משתמשים בקשירת גישה שמקשרת רמת גישה שמוגדרת כברירת מחדל לקבוצה. רמת הגישה שמוגדרת כברירת מחדל צריכה להתאים לרוב המשתמשים, המכשירים והאפליקציות.
- אם צריך, אפשר להשתמש בהגדרות גישה בהיקף מצומצם (
scopedAccessSettings) כדי להקצות רמות גישה חלשות יותר לאפליקציות נבחרות.
שימוש ברמת גישה מחמירה כברירת מחדל
אם בהרשאת גישה מוגדרים גם הגדרת גישה בהיקף וגם רמת גישה שמוגדרת כברירת מחדל, שתי רמות הגישה משולבות באמצעות סמנטיקה של OR.
להתנהגות הזו יש את ההשלכות הבאות:
- כדי שלמשתמש תהיה גישה לאפליקציית OAuth, הוא צריך לעמוד רק באחת מרמות הגישה.
- כשמוסיפים הגדרת גישה מצומצמת לאפליקציית OAuth, אפשר להפחית את דרישות הגישה בפועל.
- להגדרת גישה בהיקף מוגבל אין השפעה אם היא משתמשת ברמת גישה מחמירה יותר מרמת הגישה שמוגדרת כברירת מחדל בהרשאת הגישה.
כשבוחרים רמת גישה שמוגדרת כברירת מחדל לקישור גישה, מומלץ לבצע את הפעולות הבאות:
- שימוש ברמת גישה מחמירה כרמת הגישה שמוגדרת כברירת מחדל.
- אפשר להחיל רמות גישה נמוכות יותר על אפליקציות OAuth ספציפיות באמצעות הגדרות גישה בהיקף מוגבל.
כדאי להוסיף חלק מההגבלות הבאות או את כולן לרמת הגישה שמוגדרת כברירת מחדל:
- הגבלות על דפדפנים ומכשירים: דורשים מהמשתמשים לגשת לאפליקציות באמצעות דפדפן Chrome מנוהל ומכשיר שאושר על ידי האדמין.
- הגבלות גיאוגרפיות: אם הארגון שלכם פועל באופן בלעדי באזורים מסוימים, אתם יכולים להשתמש בהגבלות אזוריות כדי לכלול ברשימת ההיתרים רק את האזורים האלה. אפשר גם להשתמש בהגבלות אזוריות כדי להגביל את הגישה למיקומים גיאוגרפיים שמוטלות עליהם סנקציות או שלא רלוונטיים מסיבות אחרות.
- הגבלות על רשתות IP: אם משתמשים בארגון ניגשים אלGoogle Cloud באופן בלעדי מרשתות מסוימות, או אם הארגון משתמש בשרת proxy נפוץ ליציאה, אפשר לכלול הגבלות על רשתות IP.
אל תשתמשו ברמות גישה שדורשות אימות שמבוסס על אישורים כרמת גישה שמוגדרת כברירת מחדל. אימות מבוסס-אישור מתאים במיוחד לכללי תעבורת נתונים נכנסת (ingress) בגבולות גזרה לשירות VPC.
ניהול חריגים לפי אפליקציה
כדי לנהל חריגים לרמת הגישה שמוגדרת כברירת מחדל, מוסיפים חריגים לאפליקציות ספציפיות, ולא חריגים למשתמשים או לקבוצות.
רמת גישה מחמירה שמוגדרת כברירת מחדל עשויה להתאים לרוב האפליקציות, אבל לא לכל האפליקציות:
- יכול להיות שיש אפליקציות שהרגישות שלהן נמוכה יותר, ואתם רוצים לאפשר גישה אליהן למשתמשים שלא עומדים ברמת הגישה שמוגדרת כברירת מחדל. דוגמאות: אפליקציות שצריכות להיות נגישות לשותפים, לאורחים או לבוגרים.
- יכול להיות שחלק מהאפליקציות לא תואמות מבחינה טכנית לאחת מההגבלות שנאכפות על ידי רמת הגישה שמוגדרת כברירת מחדל.
כדי להחריג אפליקציות ספציפיות מרמת הגישה שמוגדרת כברירת מחדל, משתמשים בהגדרות של גישה בהיקף. לכל אפליקציה מושפעת, מוסיפים הגדרה בהיקף מוגבל ומקצים רמת גישה שמתאימה יותר לאפליקציה הספציפית.
אל תיצרו עוד קשרי גישה כדי לנהל חריגים לפי משתמש או קבוצה. קישורי גישה נוספים עלולים לגרום לבעיות הבאות:
- יכול להיות שתיצרו בטעות קשרי גישה חופפים.
- יכול להיות שיהיה קשה לקבוע אילו דרישות של בקרת גישה מבוססת-הקשר נאכפות בצורה יעילה באפליקציות ספציפיות.
הימנעות מחפיפה בין הרשאות גישה
הקצאות גישה משויכות לקבוצות. אם משתמש הוא חבר בכמה קבוצות, יכול להיות שיחולו עליו כמה הרשאות גישה. במקרה כזה, דרישות בקרת הגישה מבוססת-ההקשר של הרשאות הגישה האלה משולבות באמצעות סמנטיקה של OR.
התנהגות כזו עלולה לגרום לאפקטים לא רצויים. לדוגמה, אם מאפשרים למשתמשים להצטרף לקבוצות נוספות, יכול להיות שההגנה על אפליקציות מסוימות תיפגע.
כדי למנוע מצבים כאלה, מומלץ להימנע מחפיפה בין הרשאות הגישה:
- מומלץ לצמצם את מספר ההרשאות למינימום האפשרי, ואם אפשר, להגדיר רק הרשאה אחת.
- אם אתם צריכים כמה קשרי גישה, הקצו אותם לקבוצות שאין ביניהן חפיפה.
הגנה על קבוצות מפני שינויים לא מורשים
כברירת מחדל, ב-Cloud Identity חברי קבוצה יכולים לעזוב את הקבוצה. ההתנהגות הזו מתאימה לקבוצות גישה, אבל היא בעייתית לקבוצות עם קשרי גישה משויכים. אם משתמש עוזב קבוצה שיש לה קישור גישה משויך, הוא כבר לא כפוף לדרישות של בקרת הגישה מבוססת-הקשר שמוטלות על ידי קישורי הגישה. לכן, משתמשים יכולים לעקוף את הדרישות של בקרת גישה מבוססת הקשר על ידי יציאה מקבוצה.
כשמגדירים את הקישורים להרשאות גישה, צריך להשתמש תמיד בקבוצות לאכיפה ולא לאפשר למשתמשים לצאת מקבוצה לאכיפה. אפשרות אחרת היא ליצור קבוצה שתכיל באופן אוטומטי את כל המשתמשים בחשבון Cloud Identity או Google Workspace.
איך לא מאפשרים גישה למשתמשים חיצוניים כשמשתמשים בהרשאות גישה
הקצאות גישה משפיעות רק על משתמשים בחשבון Cloud Identity או בחשבון Google Workspace שאליו שייך Google Cloud הארגון שלכם. המשתמשים האלה עדיין כפופים להגבלות הגישה בארגון Google Cloud אם הם מנסים לגשת למשאבים בארגונים Google Cloud אחרים. השימוש הזה בהרשאות גישה למשתמשים שונה מההתנהגות בהקשרים אחרים ב-Cloud Identity.
אם אתם מאפשרים למשתמשים מחשבונות חיצוניים ב-Cloud Identity או ב-Google Workspace לגשת למשאבים בארגונים שלכם, הקשרים של ההרשאות לא משפיעים על המשתמשים האלה. Google Cloud
כדי לוודא שהרשאות הגישה שלכם אפקטיביות, אל תעניקו למשתמשים חיצוניים גישה לאפליקציות או למשאבים בארגון. Google Cloud בנוסף, אל תוסיפו משתמשים חיצוניים לקבוצות בחשבון Cloud Identity או בחשבון Google Workspace.
שימוש בקשרי גישה נפרדים לשליטה באורך הסשן
בנוסף לבקרת גישה מבוססת הקשר, אפשר גם להשתמש בהרשאות גישה כדי לנהל את משך הזמן של סשנים בדפדפן ואסימוני OAuth.
כשמשתמשים בקישורי גישה כדי לשלוט בבקרת גישה מבוססת-הקשר, מומלץ להימנע מקישורי גישה חופפים.
כשמשתמשים בהקצאות הרשאות גישה כדי לקבוע את משך הסשן, לא כדאי ליצור הקצאות הרשאות גישה חופפות. אם יותר מהרשאות הגישה האלה חלות על משתמש, רק הרשאת הגישה שעודכנה לאחרונה תיכנס לתוקף, וזה עלול להוביל לתוצאות לא רצויות.
כדי למנוע תוצאות לא רצויות כאלה, כדאי להשתמש בקשירת גישה נפרדת כדי לשלוט באורך הסשן.
המשתמשים לא יכולים לפעול בתור חשבון שירות
הקצאות גישה חלות על משתמשים ב-Cloud Identity וב-Google Workspace, אבל הן לא משפיעות על חשבונות שירות. אם תאפשרו למשתמשים לבצע אימות ולפעול בתור חשבון שירות, הם יוכלו לעקוף את בקרת הגישה מבוססת-הקשר שלכם.
יש סיכונים נוספים כשמשתמשים יכולים לפעול כחשבון שירות. אם רוצים לאפשר למשתמשים להגדיל את ההרשאות שלהם באופן זמני, מומלץ להשתמש בPrivileged Access Manager. אל תשתמשו בהתחזות לחשבון שירות, אלא למטרות פיתוח בלבד.
מידע נוסף על אבטחת חשבונות שירות ומפתחות של חשבונות שירות זמין במאמרים שיטות מומלצות לשימוש בחשבונות שירות ושיטות מומלצות לניהול מפתחות של חשבונות שירות.
כללים לתעבורת נתונים נכנסת (ingress) בגבולות הגזרה לשירות VPC
כללים לתעבורת נתונים נכנסת מאפשרים להעניק בקרת גישה מבוססת-הקשר מחוץ לגבולות הגזרה של השירות למשאבים בתוך גבולות הגזרה. אזורים של VPC Service Controls וכללי מדיניות תעבורת נתונים נכנסת (ingress) מגנים על Google Cloud משאבים, ולא על אפליקציות ספציפיות. לכן, גבולות גזרה לשירות עם כללי כניסה הם פתרון אידיאלי לאכיפת בקרת גישה מבוססת-הקשר לכלים אדמיניסטרטיביים כמו מסוף Google Cloud ו-ה-CLI של gcloud.
מידע נוסף ושיטות מומלצות בנושא גבולות גזרה לשירות ב-VPC זמינים במאמר שיטות מומלצות להפעלת VPC Service Controls.
בקטעים הבאים מתוארות שיטות מומלצות לשימוש בכללי Ingress כדי לאכוף בקרת גישה מבוססת-הקשר.
הכללת העברת TCP של IAP כשירות מוגבל
הסיבות הבאות מסבירות למה יכול להיות מסוכן לאפשר למשתמשים להתחבר למכונות וירטואליות בפרימטר של השירות באמצעות SSH או RDP:
- הכללים לתעבורה נכנסת לא חלים על החיבורים כי השימוש ב-SSH וב-RDP לא כולל גישה ל-API של Google.
- אחרי שהמשתמשים יוצרים סשן SSH או RDP, כל גישת API שמתבצעת מתוך הסשן הזה נחשבת כגישה שמקורה בתוך גבולות גזרה לשירות. לכן, כללי הכניסה לא חלים על גישה ל-API שמתחילה מתוך הסשן הזה.
כדי לצמצם את הסיכונים האלה, צריך לאפשר גישת SSH ו-RDP למכונות וירטואליות רק דרך העברת TCP של IAP:
- כוללים את השירות
iaptunnel.googleapis.comכשירות מוגבל. - אפשר להגדיר כללי חומת אש שמגבילים את הגישה ליציאות SSH ו-RDP באמצעות העברת TCP ב-IAP.
כדי לוודא שההגדרה של כללי התעבורה הנכנסת (ingress) ב-VPC service perimeter חלה על כל ניסיון גישה באמצעות SSH ו-RDP, אפשר להשתמש בהעברת TCP של IAP.
שימוש בגישה שמבוססת על אישורים למתחמי אבטחה רגישים
כברירת מחדל, אסימוני הגישה ואסימוני הרענון של Google לא משויכים למכשיר, ולכן הם עלולים להיות פגיעים לגניבה או להתקפות חוזרות. כדי לצמצם את הסיכונים האלה, אפשר להשתמש בגישה שמבוססת על אישורים (CBA), שמגבילה את הגישה למכשירים שיש להם אישור X.509 מהימן.
ה-CBA עוזר לחזק את האבטחה, אבל הגישה הזו מוסיפה גם דרישות תשתית נוספות:
- במכשיר של המשתמש צריך להיות אישור X.509 שהונפק על ידי רשות אישורים פנימית.
- המפתח שמשויך לאישור צריך להיות מאוחסן באופן שמונע ייצוא לא מורשה.
- אפליקציות לקוח צריכות להשתמש באימות TLS הדדי (mTLS) כדי להתחבר ל-Google Cloud APIs.
שימוש ב-CBA כדי להגן על הגישה להיקפי שירות ה-VPC הרגישים ביותר. הגישה הזו מאפשרת לכם לאזן בין רמת האבטחה לבין דרישות התשתית וההשפעה הכוללת.
שותפים ביצירת התוכן
מחבר: Johannes Passing | Cloud Solutions Architect
תורם נוסף: Ido Flatow | Cloud Solutions Architect