שיטות אימות ב-Google

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

מבוא

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

האימות דרוש כדי להשתמש בממשקי API ובשירותים רבים של Google. בנוסף, Google מספקת כמה שירותים שמארחים אפליקציות שכתבו הלקוחות שלנו. גם באפליקציות האלה דרושה יכולת לאמת את זהות המשתמשים.

המסגרת של OAuth 2.0 מוטמעת בממשקים של Google API, עם תוספות.

פעולה הוראות
אימות ל-Vertex AI במצב אקספרס (גרסת Preview). משתמשים במפתח ה-API שנוצר עבורכם במהלך תהליך הכניסה כדי לבצע אימות ל-Vertex AI. מידע נוסף זמין במאמר סקירה כללית על Vertex AI במצב אקספרס.
אימות מול שירות מהאפליקציה שלכם באמצעות שפת תכנות ברמה גבוהה. Google Cloud מגדירים את פרטי הכניסה ב-Application Default Credentials, ואז משתמשים באחת מספריות הלקוח ב-Cloud.
אימות לאפליקציה שנדרש בה אסימון מזהה. מקבלים אסימון מזהה של OpenID Connect ‏(OIDC) ומצרפים אותו לבקשה.
הטמעת אימות למשתמשים באפליקציה שמשתמשת בשירותים ובמשאבים של Google או של Google Cloud . במאמר אימות משתמשים באפליקציות מוצגת השוואה בין האפשרויות השונות.
התנסות בכמה פקודות gcloud מסביבת הפיתוח המקומית שלכם. הפעלת ה-CLI של gcloud
התנסות בכמה בקשות ל-API בארכיטקטורת REST בסביבת הפיתוח המקומית שלכם. Google Cloud שימוש בכלי שורת הפקודה כמו curl כדי לקרוא ל-API ל-REST.
התנסות בקטע קוד שכלול במסמכי התיעוד של המוצר. הגדרת ADC לסביבת פיתוח מקומית והתקנת ספריית הלקוח של המוצר בסביבה המקומית. ספריית הלקוח תמצא את פרטי הכניסה באופן אוטומטי.
קבלת עזרה בתרחיש אחר של אימות. נעזרים בהסברים שבדף תרחישים לדוגמה לאימות.
הצגת רשימת המוצרים ש-Google מספקת במרחב לניהול הזהויות והרשאות הגישה. המוצרים מפורטים בדף המוצרים של Google לניהול זהויות והרשאות גישה.

בחירת שיטת האימות שמתאימה לתרחיש שלכם לדוגמה

כשנכנסים לשירותים Google Cloud באמצעות ה-CLI של Google Cloud, ספריות הלקוח של Cloud, כלים שתומכים ב- Application Default Credentials‏ (ADC) כמו Terraform או בקשות REST, תוכלו להיעזר בדיאגרמה שכאן כדי לבחור שיטת אימות:

עץ החלטות שנועד לעזור בבחירת שיטת אימות בהתאם לתרחיש לדוגמה

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

  1. אתם מפעילים קוד בסביבת פיתוח למשתמש יחיד, כמו תחנת עבודה משלכם, Cloud Shell או ממשק של מחשב וירטואלי?
    1. אם כן, ממשיכים לשאלה 4.
    2. אם לא, ממשיכים לשאלה 2.
  2. אתם מריצים את הקוד ב- Google Cloud?
    1. אם כן, ממשיכים לשאלה 3.
    2. אם לא, ממשיכים לשאלה 5.
  3. אתם מריצים קונטיינרים ב-Google Kubernetes Engine?
    1. אם כן, משתמשים ב- איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE כדי לחבר חשבונות שירות לקבוצות Pod ב-Kubernetes.
    2. אם לא, מחברים חשבון שירות למשאב.

  4. בתרחיש לדוגמה שלכם יש צורך בחשבון שירות?

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

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

שיטות הרשאה לשירותים של Google Cloud

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

אפשר להחיל שכבת הרשאה נוספת באמצעות היקפי הרשאות של OAuth 2.0. כשמבצעים אימות מול שירות Google Cloud , אפשר להשתמש בהיקף גלובלי שמאשר גישה לכל השירותים Google Cloud (https://www.googleapis.com/auth/cloud-platform), או, אם השירות תומך בכך, אפשר להגביל את הגישה באמצעות היקף מוגבל יותר. היקפים מוגבלים יכולים לעזור לצמצם את הסיכון אם הקוד שלכם פועל בסביבות שבהן אסימונים שנחשפו עלולים להיות בעיה, כמו באפליקציות לנייד.

היקפי ההרשאות שמתקבלים על ידי שיטת API מפורטים במסמכי העזרה של ה-API לכל שירות Google Cloud .

Application Default Credentials

השירותApplication Default Credentials (ADC) משמש את ספריות האימות כדרך למצוא את פרטי הכניסה באופן אוטומטי על סמך הסביבה שבה פועלת האפליקציה. ספריות האימות מאפשרות לספריות הלקוח ב-Cloud ולספריות הלקוח של Google API לגשת לפרטי הכניסה האלה. כשעובדים עם ADC, הקוד יכול לפעול גם בסביבת הפיתוח וגם בסביבת הייצור, בלי שתצטרכו לשנות את שיטת האימות של האפליקציות מול Google Cloud השירותים וממשקי ה-API.

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

כדי שתוכלו להשתמש ב-ADC אתם צריכים לספק את פרטי הכניסה ל-ADC בהתאם לסביבה שבה אתם רוצים שהקוד יפעל. אפשר להשתמש ב-ADC מאחורי הקלעים כדי לאתר את פרטי הכניסה באופן אוטומטי ולקבל את האסימון, כך שאותו קוד אימות יכול לרוץ בסביבות השונות ללא שינוי. לדוגמה, תוכלו להריץ את אותה גרסה של קוד האימות מול ממשקי ה-API שלGoogle Cloud הן בעמדת פיתוח והן ב-Compute Engine.

פרטי הכניסה ל-gcloud שונים מפרטי הכניסה שאתם מספקים ל-ADC באמצעות ה-CLI של gcloud. למידע נוסף, ראו הגדרת אימות ב-CLI של gcloud והגדרת ADC.

הסברים על המונחים

חשוב להכיר ולהבין את המונחים הבאים בנושא של אימות והרשאה.

אימות

אימות הוא תהליך לבדיקת הזהות של חשבון המשתמש שאיתו מנסים לקבל גישה למשאב.

הרשאה

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

פרטי כניסה

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

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

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

הסוג של פרטי הכניסה שאתם צריכים להעביר משתנה בהתאם לגורם שמולו אתם מבצעים את האימות.

במסוףGoogle Cloud אפשר ליצור את סוגי פרטי הכניסה הבאים:

  • מפתחות API

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

    מידע נוסף על מפתחות API זמין במאמר מפתחות API. מידע נוסף על מפתחות API שמקושרים לחשבון שירות זמין בשאלות הנפוצות על מצב אקספרס ב-Google Cloud.

  • מזהי לקוחות ב-OAuth

    מזהי לקוחות ב-OAuth משמשים לזיהוי של אפליקציות מול Google Cloud. הם נדרשים כדי לקבל גישה למשאבים שבבעלות משתמשי הקצה שלכם, בגישה שנקראת גם OAuth תלת-רגלי (3LO). מידע נוסף על קבלת מזהה לקוח ב-OAuth ושימוש בו מופיע במאמר בנושא הגדרת OAuth 2.0.

  • מפתחות של חשבונות שירות

    מפתחות של חשבונות שירות מזהים את הגורם הראשי (חשבון השירות) ואת הפרויקט שמשויך לחשבון השירות.

אפשר גם ליצור פרטי כניסה באמצעות ה-CLI של gcloud. פרטי הכניסה האלה כוללים את הסוגים הבאים:

חשבון משתמש

חשבון הוא זהות שאפשר להעניק לה גישה למשאב. ממשקי Google API תומכים בשני סוגים של חשבונות לאימות: חשבונות משתמשים וחשבונות שירות.

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

חשבונות משתמשים

חשבונות משתמשים מייצגים מְפַתֵּחַ, אדמין או כל אדם אחר שמנהל אינטראקציה עם ממשקי ה-API והשירותים של Google.

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

אפשר להשתמש בחשבון משתמש לאימות מול ממשקי ה-API והשירותים של Google בדרכים הבאות:

תוכלו לקרוא איך מגדירים זהויות למשתמשים ב- Google Cloudבמאמר זהויות של משתמשים.

חשבונות שירות

חשבונות שירות הם חשבונות שלא מייצגים בני אדם. הם מספקים דרך לנהל את האימות וההרשאות בלי מעורבות ישירה של בני אדם, למשל כדי לתת לאפליקציות גישה למשאבים. Google Cloud חשבונות השירות מנוהלים על ידי הממשק לניהול זהויות והרשאות גישה (IAM).

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

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

אסימון

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

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

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

עומס עבודה וכוח עבודה

Google Cloud מוצרי זהויות והרשאות גישה מאפשרים גישה לשירותים ולמשאבים גם באופן פרוגרמטי (לאפליקציות) וגם למשתמשים (לבני אדם). Google Cloud משתמשים במונחים עומס עבודה כדי להתייחס לגישה פרוגרמטית וכוח עבודה כדי להתייחס לגישה של משתמשים.Google Cloud

איחוד שירותי אימות הזהות של עומסי עבודה מאפשר לתת גישה לעומסי עבודה מקומיים או מרובי עננים (multi-cloud) בלי ליצור ולנהל מפתחות של חשבונות שירות.

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

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