איך משתפים לקוחות OAuth

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

סקירה כללית

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

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

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

  • הגישה מותרת רק למשתמשים בארגון (משתמשים פנימיים)
  • הצגת Google Cloud מיתוג במסך הסכמה במקום המיתוג של הארגון

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

  • אפשר לשתף אותו בכמה אפליקציות
  • מאפשרת התאמה אישית של המיתוג במסך ההסכמה
  • תמיכה בגישה למשתמשים חיצוניים (מחוץ לארגון)

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

• מפחית את העלויות האדמיניסטרטיביות של ניהול כמה לקוחות
• מפשט את ההפעלה של IAP לחברי צוות שלא אמורה להיות להם גישה לדף Credentials (פרטי כניסה)
• מאפשר גישה פרוגרמטית (לא דרך דפדפן) לאפליקציות שמוגנות על ידי IAP

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

לפני שמתחילים

יוצרים לקוח OAuth חדש לפי השלבים במאמר בנושא יצירת לקוח OAuth או משתמשים בלקוח OAuth קיים.

גישה פרוגרמטית

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

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

במאמרים מדריך לאימות פרוגרמטי וניהול הגדרות IAP מוסבר איך להטמיע את התכונה.

gcloud

1. מכינים קובץ הגדרות עם מזהי הלקוחות של OAuth:

   cat << EOF > SETTINGS_FILENAME
     access_settings:
       oauth_settings:
         programmatic_clients: [clientId1, clientId2, ..]
   EOF
   

2. מחילים את ההגדרות באמצעות הפקודה gcloud iap settings set:

   gcloud iap settings set SETTINGS_FILENAME \
     [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
     [--resource-type=RESOURCE_TYPE] \
     [--service=SERVICE] \
     [--version=VERSION]
   

   דוגמאות לפקודות:

   # Organization level
   gcloud iap settings set SETTINGS_FILENAME --organization=ORGANIZATION
   
   # Folder level
   gcloud iap settings set SETTINGS_FILENAME --folder=FOLDER
   
   # Project level (web resources)
   gcloud iap settings set SETTINGS_FILENAME \
     --project=PROJECT \
     --resource-type=iap_web
   
   # App Engine service in a project
   gcloud iap settings set SETTINGS_FILENAME \
     --project=PROJECT \
     --resource-type=app-engine \
     --service=SERVICE
   

   כאשר:

   • ‫SETTINGS_FILENAME: קובץ ה-YAML שהכנתם.
   • ‫ORGANIZATION: מזהה הארגון
   • ‫FOLDER: מזהה התיקייה
   • ‫PROJECT: מזהה הפרויקט
   • ‫RESOURCE_TYPE: סוג משאב IAP ‏(app-engine,‏ iap_web,‏ compute,‏ organization או folder)
   • ‫SERVICE: שם השירות (אופציונלי לסוגי משאבים compute או app-engine)
   • ‫VERSION: שם הגרסה (לא רלוונטי ל-compute, אופציונלי ל-app-engine)

API

1. מכינים קובץ JSON עם הגדרות:

   cat << EOF > iap_settings.json
   {
     "access_settings": {
       "oauth_settings": {
         programmatic_clients: [clientId1, clientId2, ..]
       }
     }
   }
   EOF
   

2. אחזור שם המשאב:

   gcloud iap settings get \
     [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
     [--resource-type=RESOURCE_TYPE] \
     [--service=SERVICE] \
     [--version=VERSION]
   

3. מעדכנים את ההגדרות באמצעות שם המשאב:

   curl -X PATCH \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Accept: application/json" \
   -H "Content-Type: application/json" \
   -d @iap_settings.json \
   "https://iap.googleapis.com/v1/RESOURCE_NAME:iapSettings?updateMask=iapSettings.accessSettings.oauthSettings.programmaticClients"
   

   כאשר:

   • ‫ORGANIZATION: מזהה הארגון
   • ‫FOLDER: מזהה התיקייה
   • ‫PROJECT: מזהה הפרויקט
   • ‫RESOURCE_TYPE: סוג משאב IAP ‏(app-engine,‏ iap_web,‏ compute,‏ organization או folder)
   • ‫SERVICE: שם השירות (אופציונלי לסוגי משאבים compute או app-engine)
   • ‫VERSION: שם הגרסה (לא רלוונטי ל-compute, אופציונלי ל-app-engine)

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

גישה לדפדפן

כדי לאפשר ל-IAP להשתמש במזהה הלקוח ובסוד הלקוח דרך מסוףGoogle Cloud , צריך לבצע את ההוראות הבאות:

• הגדרת לקוח OAuth ל-Compute Engine (Compute Engine)
• הגדרת לקוח OAuth ל-Google Kubernetes Engine‏ (GKE)
• הגדרת לקוח OAuth עבור App Engine
• הגדרת לקוח OAuth ל-Cloud Run

הסיכונים

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

נקודת כשל בודדת

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

כדי לנהל את הסיכון התפעולי הזה בצורה יעילה:

• הטמעה של אמצעי בקרת גישה מתאימים כדי למנוע שינויים או מחיקות לא מכוונים
• הגבלת הגישה ללקוחות OAuth באמצעות הרשאות של clientauthconfig.clients.*
• אפשר להשתמש בGoogle Cloud יומני ביקורת כדי לעקוב אחרי פעילויות אדמין שקשורות ללקוחות OAuth

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

הדלפות של סודות לקוח

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

כדי לצמצם את הסיכון:

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

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

שיקולים לגבי היקף ההרשאה

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

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