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

נתמך ב:

במאמר הזה מתוארת גישה שיטתית, שלב אחר שלב, לאבחון של מופע 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. אם התפקיד חסר, לוחצים על edit Edit ומוסיפים אותו מחדש.

אימות ההגדרה של 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. מאתרים את הבקשה: בסרגל המסננים של הכרטיסייה רשת, מחפשים את 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 (מיפוי קבוצות) מופעלת גישת ברירת מחדל.

כדי לאמת את הגישה של המשתמשים לקבוצה, מוסיפים כמה מיפויי קבוצות של ספק זהויות (IdP) למופע החדש של SOAR. כברירת מחדל, בדפים של מופעים חדשים אין מיפויי קבוצות. כדי לאמת את הגישה של משתמשים אחרים לקבוצה, מוסיפים מיפויי קבוצות של ספק זהויות למופע החדש של 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 מוגדרת לקוד.
    • שימו לב לפרמטר 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 (מיפוי קבוצות) מופעלת גישת ברירת מחדל.

כדי לאמת את הגישה של המשתמשים לקבוצה, מוסיפים כמה מיפויי קבוצות של ספק זהויות (IdP) למופע החדש של SOAR. כברירת מחדל, בדפים של מופעים חדשים אין מיפויי קבוצות. כדי לאמת את הגישה של משתמשים אחרים לקבוצה, מוסיפים מיפויי קבוצות של ספק זהויות למופע החדש של 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: מוודאים שהמיפוי של הטענות הנכנסות מוגדר בצורה נכונה בקטע WIF Attribute Mapping (לדוגמה, google.groups=assertion.groups). אם טענה מופיעה באסימון אבל לא ממופה ב-WIF, יכול להיות שפלטפורמת SOAR לא תאשר את המשתמש. כדי לוודא שהמיפוי של המאפיינים מניב את התוצאות הרצויות, אפשר לעיין במאמר בנושא אימות הגדרות הספק.

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

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

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

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