סקירה כללית על שרת proxy לאימות זהויות (IAP)

בדף הזה מתוארים המושגים הבסיסיים של שירות Identity-Aware Proxy‏ (IAP), שהוא שירות גלובלי של Google Cloud .

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

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

מתי להשתמש ב-IAP

משתמשים ב-IAP כשרוצים לאכוף מדיניות של בקרת גישה לאפליקציות ולמשאבים. כדי לאבטח את האפליקציה, IAP פועל עם כותרות חתומות או עם Users API בסביבה הרגילה של App Engine. באמצעות IAP אתם יכולים להגדיר גישה לאפליקציה על סמך קבוצות: משאב יכול להיות נגיש לעובדים ולא נגיש לקבלנים, או נגיש רק למחלקה ספציפית.

איך IAP פועל

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

App Engine
נתיב הבקשה ל-App Engine כשמשתמשים ב-Cloud IAP
Cloud Run
נתיב הבקשה ל-Cloud Run כשמשתמשים ב-Cloud IAP
Compute Engine
נתיב הבקשה ל-Compute Engine ול-Kubernetes Engine כשמשתמשים ב-Cloud IAP
GKE
נתיב הבקשה ל-Compute Engine ול-Kubernetes Engine כשמשתמשים ב-Cloud IAP
On-premises
נתיב בקשה לאפליקציה מקומית כשמשתמשים ב-Cloud IAP

אימות

בקשות למשאבים של Google Cloud מגיעות דרך Cloud Run,‏ App Engine ו-Cloud Load Balancing (איזון עומסי HTTP(S) פנימי וחיצוני). קוד תשתית ההצגה של המוצרים האלה בודק אם IAP מופעל באפליקציה או בשירות לקצה העורפי. אם IAP מופעל, מידע על המשאב המוגן נשלח לשרת האימות של IAP. המידע הזה כולל פרטים כמו מספר הפרויקט, כתובת ה-URL של הבקשה וכל פרטי הכניסה ל-IAP בכותרות של הבקשה או בקובצי ה-Cookie. Google Cloud

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

  • חשבון Google: משתמשי Google Cloud עם חשבונות Google מופנים דרך תהליך הכניסה לחשבון Google כדי לגשת אל Google Cloud.
  • איחוד שירותי אימות הזהות של כוח עבודה: המשתמשים של Google Cloud בספק זהויות חיצוני מופנים דרך הכניסה לספק הזהויות כדי לגשת אל Google Cloud.
  • ‫Identity Platform: הלקוחות שלכם שמשתמשים בכתובת אימייל וסיסמה או בכניסה באמצעות רשתות חברתיות, כמו Facebook, ‏ Apple ו-Google‏ (Gmail), כדי לגשת לאפליקציה שלכם.

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

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

אם אתם משתמשים ב-Compute Engine או ב-Google Kubernetes Engine, משתמשים שיכולים לגשת ליציאה של המכונה הווירטואלית (VM) שמציגה את האפליקציה יכולים לעקוף את האימות של IAP. כללי חומת האש של Compute Engine ו-GKE לא יכולים להגן מפני גישה מקוד שפועל באותה מכונה וירטואלית כמו האפליקציה שמאובטחת באמצעות IAP. כללי חומת אש יכולים להגן מפני גישה ממכונה וירטואלית אחרת, אבל רק אם הם מוגדרים בצורה נכונה. מידע ולמידה על האחריות שלכם כדי להבטיח אבטחה.

אם אתם משתמשים ב-Cloud Run, אתם יכולים להפעיל את IAP בדרכים הבאות:

  • ישירות בשירותי Cloud Run. כך IAP יכול להגן על כל נתיבי הכניסה ל-Cloud Run, כולל כתובת ה-URL שהוקצתה אוטומטית וכל כתובת URL שהוגדרה למאזן העומסים. ההגדרה הזו שימושית כשיש לכם שירות Cloud Run אחד שאתם רוצים להפעיל בו את IAP.
  • באמצעות מאזן עומסים עם קצה עורפי של Cloud Run. ההגדרה הזו שימושית כשיש כמה שירותי Cloud Run באזורים שונים עם מאזן עומסים גלובלי אחד. בהגדרה הזו, כתובת ה-URL שהוקצתה באופן אוטומטי לא מוגנת על ידי IAP, ויכול להיות שאפשר לגשת אליה ישירות. מידע נוסף על תחומי האחריות שלכם כדי להבטיח את האבטחה.

אם שירות Cloud Run פועל עם מאזן עומסים, אל תפעילו את IAP גם במאזן העומסים וגם בשירות Cloud Run.

מידע נוסף על איחוד שירותי אימות הזהות של כוח עבודה איך מגדירים את IAP עם איחוד שירותי אימות הזהות של כוח עבודה לחלופין, אם אתם רוצים לסנכרן את הזהויות החיצוניות עם חשבונות Google משלהן, אתם יכולים להשתמש ב-Google Cloud Directory Sync כדי לסנכרן עם ה-IdP.

הרשאה

אחרי האימות, IAP מחיל את מדיניות ה-IAM הרלוונטית כדי לבדוק אם למשתמש יש הרשאה לגשת למשאב המבוקש. אם למשתמש יש את התפקיד משתמש באפליקציית אינטרנט שמאובטחת באמצעות IAP בפרויקט בGoogle Cloud מסוף שבו נמצא המשאב, יש לו הרשאה לגשת לאפליקציה. כדי לנהל את רשימת התפקידים של משתמש באפליקציית אינטרנט שמאובטחת באמצעות IAP, משתמשים בחלונית IAP ב Google Cloud מסוף.

כשמפעילים את IAP למשאב, נוצרים באופן אוטומטי מזהה לקוח וסוד לקוח ב-OAuth 2.0. אם תמחקו את פרטי הכניסה ל-OAuth 2.0 שנוצרו באופן אוטומטי, IAP לא יפעל כמו שצריך. אפשר לראות ולנהל את פרטי הכניסה של OAuth 2.0 בממשקי ה-API והשירותים במסוףGoogle Cloud .

בקרת גישה מבוססת הקשר

בשלב ההרשאה, אתם יכולים להשתמש בבקרת גישה מבוססת-הקשר כדי לספק גישה מאובטחת לסוגי המשאבים הבאים:

מסוףGoogle Cloud וממשקי API
  • שכבת ההגנה הראשונה על הגישה לתשתית של Google Cloud.
  • Google Cloud בקרת גישה מתקדמת מבוססת-הקשר למשתמשים.
מכונות וירטואליות (VM)
  • מאפשרת גישה ניהולית של SSH/RDP למכונות וירטואליות ב- Google Cloud ובעננים אחרים.

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

אפליקציות אינטרנט
  • מספק הרשאה ואימות לאפליקציות אינטרנט שמתארחות ב-Google Cloud ובעננים אחרים.

  • ההרשאה ניתנת באופן רציף כדי למנוע גישה לא מורשית ואובדן נתונים.

תחומי האחריות שלך

‫IAP מאבטח את האימות וההרשאה של כל הבקשות ל-Cloud Run, ל-App Engine, ל-Cloud Load Balancing (HTTPS) ולאיזון עומסים פנימי של HTTP.

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

  • אם אתם מפעילים את IAP במאזן עומסים, בדקו אם אפשר לגשת ישירות למשאבי הקצה העורפי.

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

    • אם המשאב לקצה העורפי הוא שירות Cloud Run, אפשר להשבית את כתובת ה-URL של run.app כדי לוודא שכל תעבורת הנתונים הנכנסת עוברת דרך מאזן העומסים. אם אתם בוחרים להשאיר את כתובת ה-URL של run.app מופעלת, כדאי להשתמש באמצעי בקרה על תעבורת נתונים נכנסת (ingress) כדי לחסום תנועה מחוץ לרשת.

  • מעדכנים את האפליקציה כך שתשתמש בכותרות חתומות או ב-Users API של סביבת ברירת המחדל ב-App Engine.

המאמרים הבאים