בדף הזה מופיעים כמה תרחישים לדוגמה נפוצים לשימוש באימות ובהרשאות, עם קישורים למידע נוסף על היישום בפועל בכל תרחיש לדוגמה.
בסקירה הכללית על אימות תוכלו ללמוד על תהליך האימות ב-Google.
אימות ל-Google APIs
לכל בקשה ב-Google APIs יש צורך באסימון גישה חוקי או במפתח API תקין. האופן שבו מספקים את פרטי הכניסה האלה תלוי במיקום שבו מריצים את הקוד ובסוגים של פרטי הכניסה שבהם ה-API תומך.
שימוש בספריות הלקוח וב-Application Default Credentials
מומלץ להשתמש ב-Google APIs יחד עם ספריית לקוח ו-Application Default Credentials (ADC). השירותApplication Default Credentials (ADC) משמש את ספריות האימות כדרך למצוא את פרטי הכניסה באופן אוטומטי על סמך הסביבה שבה פועלת האפליקציה. ספריות האימות מאפשרות לספריות הלקוח ב-Cloud ולספריות הלקוח של Google API לגשת לפרטי הכניסה האלה. כשעובדים עם ADC, הקוד יכול לפעול גם בסביבת הפיתוח וגם בסביבת הייצור, בלי שתצטרכו לשנות את שיטת האימות של האפליקציות מול Cloud de Confiance by S3NS השירותים וממשקי ה-API.
הגדרת ADC משתנה בהתאם למקום שבו מריצים את הקוד. האימות באמצעות ADC יכול להיות בתור חשבון שירות וגם בתור משתמש.
אימות מ-Google Kubernetes Engine (GKE)
באמצעות איחוד זהויות של עומסי עבודה ל-GKE אתם יכולים להריץ עומסי עבודה ב-GKE עם גישה מאובטחת ל-Google APIs. איחוד זהויות של עומסי עבודה ל-GKE מאפשר לחשבון שירות של GKE באשכול GKE לפעול כחשבון שירות לניהול זהויות והרשאות גישה (IAM).
אימות מ-Knative serving
את הגישה ל-Google APIs עבור שירותי Knative serving מאמתים באמצעות איחוד שירותי אימות הזהות של עומסי עבודה ל-GKE.
שימוש ב-API שתומך במפתחות API
אם ה-API תומך במפתחות API, אפשר לצרף לבקשה מפתח API במקום אסימון גישה. מפתחות API משייכים את הבקשה ל Cloud de Confiance פרויקט לצורכי חיוב ומכסה.
תוכלו להיעזר במסמכים של ה-API כדי לבדוק אם הוא תומך במפתחות API.
שימוש באסימוני JWT (JSON Web Tokens) בחתימה עצמית
בחלק מממשקי ה-API של Google תוכלו להשתמש באסימוני JWT (JSON Web Tokens) בחתימה עצמית במקום באסימוני גישה. המשמעות של השימוש בחתימה עצמית במקום באסימוני גישה היא שלא תצטרכו לשלוח בקשה ברשת לשרת האימות של Google. בשיטה הזו תצטרכו ליצור אסימון JWT בחתימה משלכם. מידע נוסף על אסימונים זמין במאמר סקירה כללית על אסימונים.
שימוש בחבילות ובספריות לאימות
אם אי אפשר להשתמש בסביבה שלכם ב-ADC ובהטמעת OAuth מספריות הלקוח של Cloud או מספריות הלקוח של Google API, תוכלו להשתמש בחבילות ובספריות לאימות.
אפשר להשתמש בחבילות ובספריות הבאות לאימות:
אתם גם יכולים להטמיע את ההרשאה באמצעות OAuth 2.0 תוך שימוש בנקודות הקצה של OAuth 2.0 של Google. בשיטה הזו צריך להבין יותר לעומק את המנגנונים של OAuth 2.0 ושל OpenID Connect. תוכלו להיעזר במאמר שימוש ב-OAuth 2.0 לאפליקציות אינטרנט.
Cloud de Confiance תרחישים לדוגמה שספציפיים לשירותים
חלק מהשירותים תומכים בתהליכי אימות ספציפיים. Cloud de Confiance
מתן גישה מוגבלת בזמן למשאבי Cloud Storage באמצעות כתובות URL חתומות
באמצעות כתובות URL חתומות אפשר לתת גישה מוגבלת בזמן למשאב ספציפי של Cloud Storage.
אימות לאשכולות GKE Enterprise
אתם יכולים לבצע אימות לאשכולות GKE Enterprise באמצעות Cloud de Confiance זהויות או ספק זהויות של צד שלישי:
- אימות באמצעות הזהויות של Cloud de Confiance , תוך שימוש ב-Connect gateway.
- אימות באמצעות ספק זהויות של צד שלישי שתומך ב-OIDC או ב-LDAP, תוך שימוש ב-GKE Identity Service.
הגדרת API שנפרס באמצעות API Gateway או Cloud Endpoints לצורך אימות
גם ב-API Gateway וגם ב-Cloud Endpoints אפשר לבצע אימות משירות לשירות ואימות למשתמשים באמצעות Firebase, אסימונים מזהים בחתימת Google, Okta, Auth0 ואסימוני JWT.
במסמכי העזרה של המוצרים תוכלו לקרוא מידע נוסף בנושא:
אימות לאפליקציות שמתארחות ב-Cloud Run או בפונקציות Cloud Run
כדי לבצע אימות לאפליקציות שמתארחות ב-Cloud Run ולפונקציות Cloud Run, יש צורך באסימונים מזהים.
במאמר קבלת אסימון מזהה תוכלו לקרוא על דרכים אחרות לקבלת אסימונים מזהים. מידע נוסף על אסימונים מזהים זמין במאמר אסימוני זהות.
Cloud Run
אפשר להגדיר שירות ב-Cloud Run בדרכים שונות, בהתאם לאופן שבו השירות יופעל. יכול להיות שתצטרכו גם לבצע אימות לשירותים אחרים משירות ב-Cloud Run שבו יש צורך באסימון מזהה מסוג OIDC.
כדי לאמת משתמשים בשירות שלכם מאפליקציית אינטרנט או מאפליקציה לנייד, צריך להשתמש ב-Identity Platform או באימות ב-Firebase. תוכלו גם להשתמש בשרת proxy לאימות זהויות (IAP) כדי לאמת משתמשים פנימיים.
פונקציות Cloud Run
כשאתם מפעילים פונקציה, אתם צריכים לאמת את ההפעלה. תוכלו להשתמש בפרטי כניסה של משתמש או באסימון מזהה מסוג OIDC.
אימות משתמשים באפליקציה
אתם יכולים לאמת משתמשי קצה באפליקציה שלכם בדרכים שונות, בהתאם לשאר הסביבה של האפליקציה. תוכלו להיעזר בתיאורים הבאים כדי להבין מה האפשרות שמתאימה לאפליקציה שלכם.
| שירות האימות | תיאור |
|---|---|
| Google Identity Services |
כחלק מ-Google Identity Services, מקבלים אפשרות כניסה באמצעות חשבון Google, לחצן של Google לכניסת משתמשים ואת Identity Services APIs ו-SDK. שירותי Google Identity Services מבוססים על הפרוטוקולים OAuth 2.0 ו-OpenID Connect (OIDC). אם אתם יוצרים אפליקציה לנייד, ואתם רוצים לאמת משתמשים באמצעות חשבונות Gmail ו-Google Workspace, כניסה באמצעות חשבון Google יכולה להיות אפשרות טובה. אפשרות הכניסה באמצעות חשבון Google תומכת גם בשימוש בחשבונות Google עם מערכת כניסה קיימת. מידע נוסף כשמשתמשים בכניסה באמצעות חשבון Google, אפשר להיכנס באמצעות חשבונות Gmail ו-Google Workspace ולהשתמש גם בסיסמאות חד-פעמיות (OTP). אפשרות הכניסה באמצעות חשבון Google מיועדת לחשבונות רק של Google או לחשבונות Google במערכת כניסה קיימת, לאפליקציות לנייד. אפשר להשתמש בכניסה באמצעות חשבון Google באפליקציות ל-iOS ול-Android ובאפליקציות אינטרנט. |
| אימות ב-Firebase |
כשמשתמשים באימות ב-Firebase מקבלים שירותים וספריות לאימות משתמשים עבור האפליקציות, שמתאימים למגוון רחב של סוגי חשבונות. אם רוצים לאפשר למשתמשים להיכנס לחשבון ממספר פלטפורמות שונות, אימות ב-Firebase הוא אפשרות טובה. מידע נוסף כשמשתמשים באימות ב-Firebase מקבלים תמיכה באימות שמתאימה למגוון רחב של סוגי חשבונות. עם אימות ב-Firebase אפשר לאמת משתמשים באמצעות סיסמה וגם לשלב כניסה באמצעות חשבון Google, Facebook, Twitter ופלטפורמות נוספות. אימות ב-Firebase משתמש ב-Identity Platform כפלטפורמת עורפית, אבל מיועד לקהל אחר:
למידע נוסף על ההבדלים בין המוצרים האלה, תוכלו לעיין במאמר ההבדלים בין Identity Platform לבין האימות ב-Firebase. בקישורים הבאים תוכלו לקרוא מידע נוסף:
|
| Identity Platform |
Identity Platform היא פלטפורמה לניהול זהויות והרשאות גישה של לקוחות (CIAM), שבעזרתה ארגונים יכולים להוסיף לאפליקציות שלהם יכולות ניהול זהויות ברמה ארגונית. מידע נוסף באמצעות Identity Platform אפשר לשלב ולהתאים אישית שירות זהויות ואימות שמיועד להרשמה ולכניסה של משתמשים. ב-Identity Platform יש תמיכה במספר שיטות אימות: SAML, OIDC, אימייל/סיסמה, רשתות חברתיות, מספר טלפון ואפשרויות בהתאמה אישית. אימות ב-Firebase משתמש ב-Identity Platform כפלטפורמת עורפית, אבל מיועד לקהל אחר:
למידע נוסף על ההבדלים בין המוצרים האלה, תוכלו לעיין במאמר ההבדלים בין Identity Platform לבין האימות ב-Firebase. |
| OAuth 2.0 ו-OpenID Connect |
באמצעות OpenID Connect אפשר לנהל אסימוני אימות ולהשתמש בהם עם הכי הרבה אפשרויות של התאמה אישית. אם אתם רוצים להיות עם כמה שיותר שליטה בהטמעת OAuth 2.0, ואתם מסתדרים עם הטמעת הרשאות באמצעות OAuth 2.0, כדאי לשקול את האפשרות הזו. מידע נוסף הטמעת OAuth 2.0 של Google תואמת למפרט של OpenID Connect ומאושרת על ידי OpenID. OpenID Connect היא שכבת זהות שמתלבשת על פרוטוקול OAuth 2.0. אתם יכולים להשתמש באפליקציה ב-OpenID Connect כדי לאמת את האסימון המזהה ולאחזר את פרטי הפרופיל של המשתמשים. אפשר להשתמש ב-OAuth 2.0 כדי להטמיע אימות פרוגרמטי במשאב שמאובטח באמצעות שרת proxy לאימות זהויות (IAP). |
| שרת proxy לאימות זהויות (IAP) |
שרת IAP מאפשר לשלוט בגישה לאפליקציה לפני שהבקשות מגיעות למשאבי האפליקציה. בניגוד לשירותי האימות האחרים שבטבלה הזו, שמוטמעים בתוך האפליקציה שלכם, האימות של IAP מתבצע לפני ההגעה לאפליקציה. מידע נוסף באמצעות IAP אתם יוצרים שכבת הרשאה מרכזית לאפליקציות ומשתמשים בכותרות חתומות לאבטחת האפליקציה. רק לחשבונות משתמשים עם התפקיד הנכון ב-IAM יש גישה לאפליקציות שמוגנות באמצעות IAP. כשמשתמש קצה מנסה לקבל גישה למשאב שמאובטח באמצעות IAP, האימות ובדיקת ההרשאות מתבצעים בשבילכם על ידי IAP. השימוש ב-IAP לא מגן מפני פעילות בתוך פרויקטים, כמו שירות אחר באותו פרויקט. לזהויות של Google, שרת IAP משתמש באסימונים מזהים. מידע נוסף זמין במאמר בנושא אימות פרוגרמטי. בסקירה הכללית על IAP תוכלו לקרוא איך משאבי האפליקציות מאובטחים באמצעות IAP. תוכלו גם להיעזר במדריכים הבאים ל-IAP לפי שפות תכנות: |
| App Engine Users API | אפשר להשתמש ב-Users API לאפליקציות שפועלות בסביבה הרגילה של App Engine כדי לקבל פונקציות אימות למשתמשים בשפות מסוימות. |
| מתן הרשאת גישה למשאבים למשתמשי הקצה | אם האפליקציה שלכם משתמשת במשאבים שבבעלות משתמשי הקצה, אתם צריכים לאבטח את הרשאות השימוש שלהם. התרחיש הזה נקרא לפעמים OAuth תלת-רגלי או 3LO, כי מעורבות בו שלוש ישויות: האפליקציה, שרת ההרשאות והמשתמש. |
אפשרויות אימות והרשאה ב- Cloud de Confiance וב-Google Workspace
Cloud de Confiance Google Cloud ו-Google Workspace מספקות אפשרויות שונות להגדרת גישה, לשיפור אבטחת החשבון ולניהול חשבונות.
מתן גישה למשאבי Cloud de Confiance לעומסי עבודה חיצוניים
איחוד שירותי אימות הזהות של עומסי עבודה מאפשר לתת לעומסי עבודה מקומיים או מרובי עננים גישה למשאבי Cloud de Confiance. בעבר, במקרים כאלה היה צריך להשתמש במפתחות של חשבונות שירות, אבל איחוד שירותי אימות הזהות של עומסי עבודה מונע את נטל התחזוקה והאבטחה שנובע מהשימוש במפתחות של חשבונות שירות. איחוד שירותי אימות הזהות של עומסי עבודה תומך בספקי זהויות שתואמים ל-OIDC או ל-SAML 2.0.
הגדרת ספק זהויות
באמצעות Cloud Identity או Google Workspace אתם יכולים להשתמש ב-Google בתור ספק הזהויות שלכם. אתם גם יכולים ליצור חשבון מאוחד ב-Cloud Identity או ב-Google Workspace עם ספק זהויות חיצוני. הגישה הזו מבוססת על SAML, כך שהעובדים שלכם יכולים להשתמש בזהות ובפרטי הכניסה הקיימים שלהם כדי להיכנס לשירותי Google.
הגדרת אימות דו-שלבי
אימות דו-שלבי הוא שיטה מומלצת למניעת גישה של גורמים זדוניים לחשבון, למקרה שהצליחו להשיג את פרטי הכניסה של אותו החשבון. כשמשתמשים באימות דו-שלבי, המשתמש צריך לספק פרט מידע או פרט מזהה נוסף כדי לעבור אימות. Google מציעה מספר פתרונות שתומכים בתקן FIDO (Fast IDentity Online).
Identity Platform תומכת באימות דו-שלבי לאפליקציות אינטרנט, ל-iOS ול-Android.
Google Identity Services תומך באימות FIDO (Fast IDentity Online).
Google תומכת במגוון פתרונות חומרה לאימות דו-שלבי, כמו מפתחות אבטחה Titan.
הגדרת גישה שמבוססת על אישורים
גישה שמבוססת על אישורים היא חלק מפתרון Chrome Enterprise Premium למודל אבטחה של אפס אמון, שמגבילה את הגישה רק למשתמשים מאומתים ממכשירים מהימנים, שזוהו באמצעות אישורי X.509. גישה שמבוססת על אישורים נקראת גם לפעמים Transport Layer Security (mTLS) הדדית.
מידע כללי על החשבון ועל אימות
קבלת עזרה בקשר לגישה לחשבון Google
אם אתם צריכים עזרה בקשר לגישה או לניהול של חשבון Google, תוכלו להיעזר בדף התמיכה לחשבונות Google.
טיפול בפרטי כניסה שנחשפו
אם לדעתכם פרטי הכניסה שלכם נחשפו, אתם או האדמין שלכם יכולים לבצע מספר פעולות כדי למזער את הפגיעה. למידע נוסף, ראו מה עושים אם פרטי הכניסה ל- Cloud de Confiance by S3NS נחשפו?
קבלת עזרה בקשר לבעיות עם רשות האישורים
אם הופיעו הודעות שגיאה שקשורות לאישור שלכם או לרשות האישורים (CA), כולל אישור הבסיס של רשות האישורים, תוכלו להיעזר בתשובות לשאלות הנפוצות בקשר ל-Google Trust Services.