במאמר הזה מתוארות שיטות מומלצות לשימוש בבקרת גישה מבוססת-הקשר כדי להגן ביעילות על המשאבים ב- 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
כללי Ingress מאפשרים להעניק בקרת גישה מבוססת-הקשר מחוץ לגבולות גזרה לשירות למשאבים בתוך גבולות הגזרה. אזורים של VPC Service Controls וכללי תעבורת נתונים נכנסת (ingress) מגנים על Google Cloud משאבים, ולא על אפליקציות ספציפיות. לכן, היקף שירות עם כללי כניסה הוא פתרון אידיאלי לאכיפת גישה מודעת-הקשר לכלים אדמיניסטרטיביים כמו Google Cloud המסוף ו-gcloud CLI.
מידע נוסף ושיטות מומלצות בנושא גבולות גזרה לשירות ב-VPC זמינים במאמר שיטות מומלצות להפעלת VPC Service Controls.
בקטעים הבאים מתוארות שיטות מומלצות לשימוש בכללי כניסה כדי לאכוף בקרת גישה מבוססת-הקשר.
הכללת העברת TCP של IAP כשירות מוגבל
יש סיכון בהרשאת משתמשים להתחבר למכונות וירטואליות בפרימטר של השירות באמצעות SSH או RDP, מהסיבות הבאות:
- הכללים לתעבורה נכנסת לא חלים על החיבורים כי השימוש ב-SSH וב-RDP לא כולל גישה ל-API של Google.
- אחרי שהמשתמשים יוצרים סשן SSH או RDP, כל גישה ל-API שמתבצעת מתוך הסשן הזה נחשבת כגישה שמקורה בתוך גבולות גזרה לשירות. לכן, כללי הכניסה שלך לא חלים על גישה ל-API שהופעלה מתוך הסשן הזה.
כדי לצמצם את הסיכונים האלה, צריך לאפשר גישת SSH ו-RDP למכונות וירטואליות רק דרך העברת TCP ב-IAP:
- כוללים את השירות
iaptunnel.googleapis.comכשירות מוגבל. - אפשר להגדיר כללי חומת אש שמגבילים את הגישה ליציאות SSH ו-RDP באמצעות העברת TCP ב-IAP.
כדי לוודא שההגדרה של כללי תעבורת נתונים נכנסת (ingress) ב-service perimeter של ה-VPC חלה על כל ניסיון גישה באמצעות SSH ו-RDP, אפשר להשתמש בהעברת TCP של IAP.
שימוש בגישה שמבוססת על אישורים למתחמי אבטחה רגישים
כברירת מחדל, אסימוני גישה ואסימוני רענון של Google לא מקושרים למכשיר, ולכן הם עלולים להיות פגיעים לגניבה או להתקפות חוזרות. כדי לצמצם את הסיכונים האלה, אפשר להשתמש בגישה שמבוססת על אישורים (CBA), שמגבילה את הגישה למכשירים שיש להם אישור X.509 מהימן.
אימות באמצעות כרטיס חכם עוזר לחזק את האבטחה, אבל הגישה הזו גם מוסיפה דרישות תשתיתיות נוספות:
- במכשיר של המשתמש צריך להיות אישור X.509 שהונפק על ידי רשות אישורים פנימית.
- המפתח שמשויך לאישור צריך להיות מאוחסן באופן שמונע ייצוא לא מורשה.
- אפליקציות לקוח צריכות להשתמש באימות TLS הדדי (mTLS) כדי להתחבר ל-Google Cloud APIs.
שימוש ב-CBA כדי להגן על הגישה להיקפי שירות ה-VPC הרגישים ביותר. הגישה הזו מאפשרת לאזן בין רמת האבטחה לבין דרישות התשתית וההשפעה הכוללת.
שותפים ביצירת התוכן
מחבר: Johannes Passing | Cloud Solutions Architect
תורם נוסף: Ido Flatow | Cloud Solutions Architect