איך משתפים לקוחות 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 הם היקפי ההרשאות הנדרשים היחידים. השיקול הזה לבדו לא מהווה סיכון משמעותי, אבל חשוב להבין:

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