מדריך לאימות לפני העברה

נתמך ב:

במאמר הזה מפורטת גישה שיטתית של אבחון שלב אחר שלב כדי לאמת את מופע Google Security Operations ואת הגדרת האימות לפני העברת SOAR. המדריך הזה מתמקד בתקנים SAML ו-OIDC שמשמשים לאימות ולאישור של משתמשים.

אימות הגדרת Chronicle API

כדי לבדוק אם Chronicle API מוגדר בצורה נכונה ב Google Cloud פרויקט שלכם:

  1. נכנסים אל Google Cloud המסוף ובוחרים את הפרויקט הנכון Google Cloud מתוך רשימת הפרויקטים בסרגל הניווט העליון.
  2. פותחים את תפריט הניווט (≡) ועוברים אל APIs & Services (ממשקי API ושירותים) > Enabled APIs & services (ממשקי API ושירותים מופעלים).
  3. עוברים לרשימה Enabled APIs & Services כדי למצוא את Chronicle API.

  4. אם הוא מופיע: ה-API מופעל.

    אם הוא לא מופיע: לוחצים על + ENABLE APIS AND SERVICES בחלק העליון, מחפשים את Chronicle API ולוחצים על Enable.

כדי לבדוק אם חשבון השירות נוצר:

  1. נכנסים לדף IAM במסוף Google Cloud .
  2. הצגת חשבונות מוסתרים (שלב חשוב): צריך לסמן את התיבה בצד שמאל של סרגל המסננים עם הכיתוב Include Google-provided role grants.
  3. מחפשים את הסוכן: בסרגל הסינון, מקלידים chronicle. אתם מחפשים כתובת אימייל שתואמת לתבנית הספציפית הזו: service-[PROJECT_NUMBER]@gcp-sa-chronicle.iam.gserviceaccount.com
  4. בדיקת ההרשאות: מוודאים שמוקצה לו התפקיד Chronicle Service Agent. אם התפקיד חסר, לוחצים על עריכה עריכה ומוסיפים אותו מחדש.

אימות ההגדרה של Google SecOps

  1. במסוף Google Cloud , בוחרים את הפרויקט הנכון Google Cloud מהרשימה.
  2. עוברים אל אבטחה > Google SecOps, ומופיעה הכרטיסייה כניסה יחידה.
  3. אם Google SecOps מופעל, אמורה להופיע כרטיסייה בשם כניסה יחידה. אם לא, התהליך של יצירת הלקוח הפוטנציאלי לא הושלם. מזינים את Google Cloud מזהה הפרויקט בטופס Google שמופיע בהתראה במוצר. מאשרים את התאריך והשעה של ההעברה ושולחים את הטופס. אם לא תקבלו תשובה תוך 72 שעות ממועד השליחה, תוכלו לפנות לכתובת soar-migration-to-gcom@google.com.
  4. אם הכרטיסייה קיימת, לוחצים על מעבר אל SecOps. אם הכניסה מצליחה, זה אומר שהגדרת האימות נכונה. אם הכניסה נכשלת, משתמשים בקטע הבא כדי לנפות באגים בהגדרה. אם הכניסה נכשלת, משתמשים בקטע הבא כדי לנפות באגים בהגדרה.

תהליך SAML ופתרון בעיות

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

ארכיטקטורה של תהליך האימות

כדי לבודד נקודות כשל, חשוב להבין את זרימת הבקשות. הדיאגרמה הבאה ממחישה את הנתיב הרציף של התחברות מוצלחת.

ארכיטקטורה של תהליך האימות

הליך מפורט לפתרון בעיות

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

‫Google לא ממליצה על מוצר מסוים, אבל ידוע שהכלים הבאים עוזרים לפתור בעיות בתהליך:

  • אימות SAML: https://www.samltool.io/
    • מטרה: משמש לפענוח ולאימות של בקשות ותגובות גולמיות של SAML.
  • בדיקת JWT: https://www.jwt.io/
    • מטרה: משמש לבדיקת הטענות והתוכן של אסימוני JWT‏ (JSON Web Tokens).

שלב 1: הכנת הסביבה

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

  1. פותחים כרטיסייה חדשה בדפדפן או משתמשים בחלון פרטי.

  2. פותחים את הכלים למפתחים באמצעות קיצור הדרך של מערכת ההפעלה:

    • ‫Windows: מקישים על F12.
    • ‫Linux: מקישים על Ctrl + Shift + I
    • ‫macOS: מקישים על Cmd + Option + I

  3. עוברים לכרטיסייה Network (רשת).

  4. מסמנים את התיבה שמירת יומן הרישום כדי לוודא שלא יאבד מידע במהלך ההפניות האוטומטיות.

    שמירת יומן הרישום

  5. כדי להתחיל בתהליך הכניסה, עוברים לכתובת ה-URL של סביבת Google SecOps. כתובת ה-URL הזו תישלח אליכם באימייל אחרי שתשלימו את ההגדרה של Google SecOps בשלב 5 של שלב 1 במיגרציה ללקוחות עצמאיים של SOAR. נושא האימייל הוא Your Google SecOps instance is ready.

שלב 2: אימות בקשת SAML לספק הזהויות

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

  1. מאתרים את הבקשה: בסרגל המסננים של הכרטיסייה Network, מחפשים את saml.

    איתור הבקשה

  2. שליפת נתונים: בוחרים את הבקשה ולוחצים על הכרטיסייה מטען ייעודי (payload). מאתרים את הפרמטר של מחרוזת השאילתה עם התווית SAMLRequest.

    חילוץ נתונים

  3. פענוח: מעתיקים את ערך הבקשה ומדביקים אותו בכלי SAML Validation (samltool.io) כדי לפענח אותו.

    פענוח קוד

  4. אימות:

    • בודקים את יעד הבקשה.
    • מוודאים שכתובת ה-URL הזו תואמת להגדרות התצורה ב-IdP.

שלב 3: אימות תגובת ה-SAML מ-IdP

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

  1. מאתרים את התשובה: בסרגל המסננים של הכרטיסייה Network (רשת), מחפשים את signin-callback.

    איתור התשובה

  2. שליפת נתונים: בוחרים את הבקשה ולוחצים על הכרטיסייה מטען ייעודי (payload). מאתרים את נתוני SAMLResponse.

    איתור נתוני תגובת SAML

  3. פענוח: מעתיקים את ערך התגובה ומדביקים אותו בכלי SAML Validation.

  4. אימות:

    • בודקים את התביעות (מאפיינים) שמוחזרות, כמו groups,‏ first name, ‏ last name ו-email.
    • חשוב: צריך לוודא שהמאפיינים האלה תואמים להגדרות של מאגר כוח העבודה ב- Google Cloud.

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

      הגדרות של מאגר כוח עבודה

בתמונה הבאה מוצג מיפוי מאפיינים:

attribute-mapping

המיפוי בתמונה הוא כזה:

  • google.subject = assertion.subject
  • attribute.last_name = assertion.attributes.last_name[0]
  • attribute.user_email = assertion.attributes.user_email[0]
  • attribute.first_name = assertion.attributes.first_name[0]
  • google.groups = assertion.attributes.groups

החלק השמאלי תמיד זהה – זו התחביר של Google. הצד השמאלי הוא לפי מפתחות המאפיינים של הטענה שמוצגים בתגובת SAML.

המאפיין [0] הוא חיוני למאפיינים הספציפיים שצוינו (last_name,‏ user_email ו-first_name), ולא רלוונטי למאפיינים subject ו-groups.

שלב 4: אימות האימות של Google SecOps

בשלב הזה מאמתים אם Google Cloud מאמת את המשתמש כדי להיכנס ל-Google SecOps SOAR.

  1. איתור האסימון בדפדפן של המשתמש: בסרגל הסינון של הכרטיסייה רשת, מחפשים את נקודת הקצה auth/siem.

    איתור הטוקן בדפדפן של המשתמש

  2. שליפת נתונים: בוחרים את הבקשה וצופים בכרטיסייה מטען ייעודי (payload). מאתרים את המחרוזת jwt.

  3. פענוח: מעתיקים את מחרוזת ה-JWT ומדביקים אותה בכלי JWT Inspection (jwt.io).

    מעתיקים את מחרוזת ה-JWT ומדביקים אותה

  4. אימות:

    • משווים את התלונות המפוענחות לגבי given_name,‏ family_name,‏ email ו-idpgroups.
    • אישור התאמה: הערכים האלה צריכים להיות זהים בדיוק למאפיינים שאומתו בשלב 3 (תגובת SAML).
    • אם הערכים זהים ועדיין אין לכם גישה, צריך לבדוק את הקצאת התפקידים ב-IAM. מוודאים שכל המשתמשים קיבלו הקצאה של אחד מהתפקידים המוגדרים מראש ב-Chronicle באמצעות פורמט המנהל הנכון להגדרת הזהויות (איחוד שירותי אימות הזהויות של כוח העבודה או Cloud Identity לחשבונות שמנוהלים על ידי Google).

שלב 5: אימות הגישה להרשאות SOAR

בשלב הזה מוודאים שהמערכת מקצה הרשאות ב-SOAR בצורה נכונה דרך הדף Group Mapping בפלטפורמה.

לאדמינים יש גישה אוטומטית ל-SOAR כי בדף Group Mapping (מיפוי קבוצות) מופעלת גישת ברירת מחדל.

כדי לוודא שהמשתמשים יכולים לגשת לקבוצה, אפשר להוסיף כמה מיפויי קבוצות של ספק הזהויות במופע החדש של SOAR. כברירת מחדל, בדף מיפוי קבוצות של מופעים חדשים לא מופיעות קבוצות. כדי לאמת את הגישה של משתמשים אחרים לקבוצה, מוסיפים מיפויים של קבוצות ב-IdP למופע החדש של SOAR, ופועלים לפי השלבים הבאים:

  1. מעתיקים את מיפויי הקבוצות מהדף Group Mappings (מיפויי קבוצות) במופע הקיים של SOAR.
  2. מבקשים ממשתמש בקבוצת ה-IdP לגשת לכתובת ה-URL החדשה של Google SecOps.

  3. אם למשתמש אין גישה ל-SOAR, אפשר לנסות את השלבים הבאים לפתרון בעיות:

    א. בדיקת התגובה: פותחים את בקשת auth/siem משלב 4 ובוחרים בכרטיסייה תצוגה מקדימה.

    ב. בדיקת הרשאות: מאתרים את האובייקט permissions בתגובת ה-JSON.

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

זרימת OIDC ופתרון בעיות

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

ארכיטקטורה של תהליך האימות

הבנת זרימת הבקשות חיונית לבידוד נקודות הכשל. הדיאגרמה הבאה ממחישה את הנתיב הרציף של התחברות מוצלחת.

ארכיטקטורה של תהליך אימות

הוראות מפורטות לפתרון בעיות ב-OIDC

כדי לאבחן ולעקוב ביעילות אחרי תהליך האימות של OIDC, אתם יכולים להשתמש בכלים למפתחים בדפדפן ובמפענחי JWT אונליין.

  • בדיקת JWT: https://www.jwt.io/
    • מטרה: משמש לבדיקת הטענות והתוכן של אסימוני JWT (‏JSON Web Tokens).

שלב 1: הכנת הסביבה

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

  1. פותחים כרטיסייה חדשה בדפדפן או חלון במצב פרטי.

  2. פותחים את הכלים למפתחים באמצעות קיצור הדרך של מערכת ההפעלה:

    • ‫Windows: מקישים על F12.
    • ‫Linux: מקישים על Ctrl + Shift + I
    • ‫macOS: מקישים על Cmd + Option + I

  3. עוברים לכרטיסייה Network (רשת).

  4. מסמנים את התיבה שמירת יומן הרישום כדי לוודא שלא יאבד מידע במהלך ההפניות האוטומטיות.

    שמירת יומן הרישום

  5. כדי להתחיל בתהליך הכניסה, עוברים לכתובת ה-URL של סביבת Google SecOps. כתובת ה-URL הזו תישלח אליכם באימייל אחרי שתשלימו את ההגדרה של Google SecOps בשלב 5 של שלב 1 במיגרציה ללקוחות עצמאיים של SOAR. נושא האימייל הוא YourGoogle SecOps instance is ready.

שלב 2: אימות בקשת ההרשאה לספק OIDC

בשלב הזה מאמתים את ההפניה הראשונית מ- Google Cloud אל ספק OpenID Connect‏ (IdP).

  1. איתור הבקשה: בכרטיסייה Network (רשת), מחפשים את ההפניה האוטומטית הראשונית לנקודת הקצה של ההרשאה של ספק ה-OIDC. כתובת ה-URL בדרך כלל מכילה פרמטרים כמו client_id,‏ redirect_uri,‏ scope,‏ response_type ו-state.

    איתור הבקשה

  2. אימות:

    • מוודאים ש-client_id זהה לזה שהוגדר בספק OIDC.
    • מוודאים שהערך של redirect_uri זהה בדיוק לערך של https://auth.backstory.chronicle.security/signin-callback/locations/global/workforcePools/POOL_ID/provider/PROVIDER_ID, ומחליפים את POOL_ID ואת PROVIDER_ID במאגר ובספק שלכם מאיחוד שירותי אימות הזהות של כוח העבודה.
    • בודקים שההגדרה response_type היא code.
    • שימו לב לפרמטר scope, שצריך לכלול openid וכל היקף אחר שנדרש כדי לשחרר את הטענות הנדרשות (לדוגמה, email, profile).

שלב 3: אימות הקריאה החוזרת והחלפת הטוקן

בשלב הזה מאמתים את התשובה של ה-IdP בחזרה אל Google Cloud.

  1. איתור הקריאה החוזרת: בכרטיסייה Network, מאתרים את הבקשה לכתובת ה-URL של הקריאה החוזרת להתחברות: (.../signin-callback/...).

    איתור הקריאה החוזרת

  2. בדיקת נתונים: בודקים את הפרמטרים של כתובת ה-URL של הבקשה הזו. הוא צריך להכיל פרמטר קוד שסופק על ידי ספק הזהויות שלכם שתומך ב-OIDC.

  3. מאחורי הקלעים: איחוד שירותי אימות הזהות של כוח העבודה מחליף את הקוד הזה באסימונים (אסימון מזהה, אסימון גישה) מנקודת הקצה של האסימון של ספק OIDC. שגיאות בשלב הזה מופיעות בדרך כלל ב-Cloud Logging עבור איחוד שירותי אימות הזהות של כוח העבודה.

    • כדי לוודא שהמאפיינים מועברים ושהאסימון מלא: כדי לוודא שמיפוי המאפיינים באיחוד שירותי אימות הזהות של כוח העבודה מניב את התוצאות הרצויות:
      • מוסיפים את ה-URI להפניה אוטומטית שמופיע בהגדרות של ספק איחוד שירותי אימות הזהויות של כוח העבודה אל ה-URI להפניה אוטומטית של הספק (לדוגמה, https://auth.cloud.google/signin-callback/locations/global/workforcePools/POOL_ID/providers/PROVIDER_ID).
      • עוברים לספק הזהויות של כוח העבודה כדי לנפות באגים באסימון ה-IdP. אפשר גם לבדוק את האסימון המלא. מידע נוסף מופיע במאמר בנושא אימות הגדרת המוצר.

    הצגת הטוקן המלא אימות מאפיינים

שלב 4: אימות האימות של Google SecOps

בשלב הזה מאמתים אם Google Cloud מאמת את המשתמש כדי להיכנס ל-Google SecOps SOAR.

  1. איתור האסימון בדפדפן של המשתמש: בסרגל הסינון של הכרטיסייה רשת, מחפשים את נקודת הקצה auth/siem.

    איתור הטוקן בדפדפן של המשתמש

  2. שליפת נתונים: בוחרים את הבקשה וצופים בכרטיסייה מטען ייעודי (payload). מאתרים את המחרוזת jwt.

  3. פענוח: מעתיקים את מחרוזת ה-JWT ומדביקים אותה בכלי JWT Inspection (jwt.io).

    מעתיקים את מחרוזת ה-JWT ומדביקים אותה

  4. אימות:

    • משווים את התביעות שפוענחו עבור sub,‏ given_name,‏ family_name,‏ email ו-idpgroups.
    • אישור התאמה: הערכים האלה צריכים להתאים למאפיינים שמועברים על ידי ספק ה-OIDC ולמיפוי שלהם במיפוי המאפיינים של איחוד הזהויות של כוח העבודה. לדוגמה, attribute.first_name in Google Cloud צריך להיות ממופה ל-given_name ב-JWT.
    • תפקידים ב-IAM: אם הטענות נכונות אבל הגישה נדחית עם הודעה כמו Cannot Authenticate user, because user does not have access to the GCP project...,, צריך לבדוק את הקצאות התפקידים ב-IAM. מוודאים שלקבוצות של המשתמש (idp_groups ב-JWT) מוקצים התפקידים הנדרשים באמצעות הפורמט הנכון של principalSet (לדוגמה, principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/IDP_GROUP_NAME).

שלב 5: אימות הגישה להרשאות SOAR

בשלב הזה מוודאים שהמערכת מקצה הרשאות ב-SOAR בצורה נכונה דרך הדף Group Mapping בפלטפורמה.

לאדמינים יש גישה אוטומטית ל-SOAR כי בדף Group Mapping (מיפוי קבוצות) מופעלת גישת ברירת מחדל.

כדי לוודא שהמשתמשים יכולים לגשת לקבוצה, אפשר להוסיף כמה מיפויי קבוצות של ספק הזהויות במופע החדש של SOAR. כברירת מחדל, בדף מיפוי קבוצות של מופעים חדשים לא מופיעות קבוצות. כדי לאמת את הגישה של משתמשים אחרים לקבוצה, מוסיפים מיפויים של קבוצות ב-IdP למופע החדש של SOAR, ופועלים לפי השלבים הבאים:

  1. מעתיקים את מיפויי הקבוצות מהדף Group Mappings (מיפויי קבוצות) במופע הקיים של SOAR.
  2. מבקשים ממשתמש בקבוצת ה-IdP לגשת לכתובת ה-URL החדשה של Google SecOps.

  3. אם למשתמש אין גישה ל-SOAR, אפשר לנסות את השלבים הבאים לפתרון בעיות:

    א. בדיקת התגובה: פותחים את בקשת auth/siem משלב 4 ובוחרים בכרטיסייה תצוגה מקדימה.

    ב. בדיקת הרשאות: מאתרים את האובייקט permissions בתגובת ה-JSON.

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

שגיאות נפוצות ב-OIDC:

  • invalid_redirect_uri מ-IdP: מוודאים שערך ה-URI להפניה שהוגדר ב-IdP זהה בדיוק לערך https://auth.backstory.chronicle.security/signin-callback/locations/global/workforcePools/POOL_ID/provider/PROVIDER_ID, כשמחליפים את POOL_ID ואת PROVIDER_ID במאגר ובספק מאיחוד שירותי אימות הזהות של כוח העבודה. גם אם יש הבדל בין כתובות האתרים, למשל אם באחת מהן יש לוכסן בסוף (/) ובשנייה אין, או אם באחת מהן יש http ובשנייה יש https, המערכת תזהה את זה.

  • הצהרות חסרות ב-JWT:

    1. בצד IdP: מוודאים שלקוח OIDC מוגדר לשחרור ההצהרות הנדרשות (שממופות ב-WIF, כמו sub,‏ groups,‏ email,‏ given_name,‏ family_name) בטוקן של מזהה.

    2. בצד של WIF: מוודאים שהטענות הנכנסות ממופות בצורה נכונה בקטע Attribute Mapping (מיפוי מאפיינים) של WIF (לדוגמה, google.groups=assertion.groups). אם יש טענה באסימון אבל היא לא ממופה ב-WIF, יכול להיות שפלטפורמת ה-SOAR לא תצליח לאשר את המשתמש. כדי לוודא שמיפוי המאפיינים מניב את התוצאות הרצויות, אפשר לעיין במאמר בנושא אימות הגדרות הספק.

מיפוי קבוצות אחרי ההעברה

מיפוי קבוצות נשאר חיוני ב-Google SecOps אחרי שההעברה מסתיימת

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

הבעיה עדיין לא נפתרה? קבלת תשובות מחברי הקהילה וממומחי Google SecOps.