הגדרת אימות רב-גורמי

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

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

הסבר על תהליך ההגדרה של MFA

התכונה MFA של reCAPTCHA מיושמת בנוסף לתהליך העבודה הרגיל של reCAPTCHA.

באופן כללי, תהליך העבודה של MFA הוא כזה:

  1. לבצע אינסטרומנטציה של תהליך העבודה הקריטי באתר.
  2. יוצרים הערכה באמצעות האסימון שמוחזר על ידי הקריאה execute() והפרמטרים של MFA כדי לקבל MFA requestToken.
  3. הפעלת אתגר MFA באמצעות requestToken בהתאם לערוץ שבו רוצים להשתמש (רק אימייל נתמך).
  4. מאמתים את קוד האימות שהזין משתמש הקצה באתר שלכם.
  5. יוצרים הערכה חדשה באמצעות האסימון שמוחזר בבקשת האימות.

לפני שמתחילים

  1. הכנת הסביבה ל-reCAPTCHA

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

  3. כדי להפעיל את תכונת האימות באימייל של MFA, צריך לבצע את הפעולות הבאות:

    1. נכנסים לדף reCAPTCHA במסוף Google Cloud .

      מעבר אל reCAPTCHA

    2. מוודאים ששם הפרויקט מופיע בבורר המשאבים.

      אם שם הפרויקט לא מופיע, לוחצים על בורר המשאבים ובוחרים את הפרויקט.

    3. לוחצים על הגדרות.

    4. בחלונית אימות רב-שלבי, לוחצים על הגדרה.

    5. בתיבת הדו-שיח Configure MFA, מבצעים את הפעולות הבאות:

      1. כדי להפעיל אימות באמצעות אימייל, לוחצים על המתג הפעלת אימייל.
      2. בתיבה שם השולח, מזינים את השם שלכם.
      3. בתיבה כתובת האימייל של השולח, מזינים את כתובת האימייל.

        הגדרת MFA

    6. לוחצים על Save.

  4. אחרי שמגדירים את כתובת האימייל של השולח, צריך להגדיר את רשומות ה-DNS כדי למנוע בעיות בשליחת האימייל. בשלבים הבאים, מחליפים את example.com בדומיין שלכם.

    1. מוסיפים רשומת SPF כדי לאפשר ל-reCAPTCHA לשלוח אימיילים בשמכם:

      Host: example.com
      Value: v=spf1 include:_spf.recaptchamail.goog ~all
      
    2. כדי שהשרתים יוכלו למצוא את חתימת DKIM, צריך לכלול את רשומות ה-CNAME הבאות:

      Host: recaptcha1._domainkey.example.com
      Value: recaptcha1._domainkey.recaptchamail.goog.
      
      Host: recaptcha2._domainkey.example.com
      Value: recaptcha2._domainkey.recaptchamail.goog.
      
  5. הגדרת reCAPTCHA באתר באמצעות מפתחות מבוססי-ניקוד

הטמעה של כלי למעקב אחרי תהליך עבודה קריטי באתר

מעבירים את המידע הנדרש ל-reCAPTCHA באמצעות הפונקציה execute() לצורך הערכת סיכונים. הפונקציה execute() מחזירה אובייקט promise שמוגדר כ-resolved עם יצירת הטוקן.

מוסיפים פרמטר twofactor נוסף לפונקציה execute(), כמו בדוגמת הקוד הבאה:

  grecaptcha.enterprise.execute(KEY_ID, {
    action: 'login',
    twofactor: true
  }).then(token => {
    // Handle the generated token.
  });

מחליפים את KEY_ID במפתח מבוסס הניקוד שיצרתם לאתר.

יצירת מבדק

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

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

לפני שיוצרים כלי הערכה, צריך לבצע את הפעולות הבאות:

  • מגדירים אימות ל-reCAPTCHA.

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

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

    אם אתם רוצים להשתמש במפתחות API, מומלץ לאבטח אותם על ידי החלת הגבלות על מפתחות API.

    ספריות לקוח

    מומלץ להשתמש במשאבים הבאים:

  • צריך לבחור מזהה חשבון יציב accountId שהמשתמש לא משנה לעיתים קרובות, ולספק אותו להערכה בשיטה projects.assessments.create. למזהה החשבון הקבוע הזה צריך להיות אותו ערך בכל האירועים שקשורים לאותו משתמש. אפשר לספק את הפרטים הבאים כמזהה החשבון:

    מזהי משתמשים

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

    לחלופין, אם יש לכם מזהה משתמש פנימי שמשויך באופן ייחודי לכל חשבון, אתם יכולים לספק אותו כaccountId.

    גיבוב או הצפנה

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

    בוחרים מזהה חשבון יציב והופכים אותו לאטום לפני השליחה אל reCAPTCHA באמצעות הצפנה או גיבוב:

    • הצפנה (מומלץ): מצפינים את מזהה החשבון באמצעות שיטת הצפנה דטרמיניסטית שמפיקה טקסט מוצפן יציב. הוראות מפורטות זמינות במאמר בנושא הצפנת נתונים באופן דטרמיניסטי. כשבוחרים בהצפנה סימטרית במקום בגיבוב, לא צריך לשמור מיפוי בין מזהי המשתמשים לבין מזהי המשתמשים האטומים התואמים. צריך לפענח את המזהים האטומים שמוחזרים על ידי reCAPTCHA כדי להפוך אותם למזהה המשתמש.

    • גיבוב: מומלץ לגבב את מזהה החשבון באמצעות שיטת SHA256-HMAC עם מלח מותאם אישית לפי בחירתכם. מכיוון שגיבוב הוא חד-כיווני בלבד, צריך לשמור מיפוי בין הגיבובים שנוצרו לבין מזהי המשתמשים, כדי שתוכלו למפות את מזהה החשבון המגובב שמוחזר בחזרה לחשבונות המקוריים.

מוסיפים את הפרמטר accountId ונקודת קצה, כמו כתובת אימייל לאימות בהערכה, בשיטה projects.assessments.create.

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

  • PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
  • TOKEN: האסימון שמוחזר מהקריאה grecaptcha.enterprise.execute().
  • KEY_ID: המפתח שמבוסס על ניקוד שהתקנתם באתר.
  • ACCOUNT_ID: מזהה של חשבון משתמש שהוא ייחודי לאתר שלכם.
  • EMAIL_ID: כתובת האימייל שצריך להפעיל בשבילה את בקשת האימות.

ה-method של ה-HTTP וכתובת ה-URL:

POST https://recaptchaenterprise.googleapis.com/v1/projects/PROJECT_ID/assessments

גוף בקשת JSON:

{
  "event": {
    "token": "TOKEN",
    "siteKey": "KEY_ID",
    "userInfo": {
       "accountId": "ACCOUNT_ID"
    }
  }
  "accountVerification": {
    "endpoints": [{
      "emailAddress": "EMAIL_ID",
    }]
  }
}

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

curl

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json; charset=utf-8" \
-d @request.json \
"https://recaptchaenterprise.googleapis.com/v1/projects/PROJECT_ID/assessments"

PowerShell

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
-Method POST `
-Headers $headers `
-ContentType: "application/json; charset=utf-8" `
-InFile request.json `
-Uri "https://recaptchaenterprise.googleapis.com/v1/projects/PROJECT_ID/assessments" | Select-Object -Expand Content

אתם אמורים לקבל תגובת JSON שדומה לזו:


{
  [...],
  "accountVerification": {
    "endpoints": [{
      "emailAddress": "foo@bar.com",
      "requestToken": "tplIUFvvJUIpLaOH0hIVj2H71t5Z9mDK2RhB1SAGSIUOgOIsBv",
      "lastVerificationTime": "",
    }],
    "latestVerificationResult": "RESULT_UNSPECIFIED"
  }
}

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

אם הפעלתם את reCAPTCHA Account defense בפרויקט, תגובת ההערכה תכיל מידע שקשור ל-Account defense בנוסף למידע שקשור ל-MFA. בשדה recommended_action מוצגת הפעולה האפשרית שאפשר לבצע לפני הפעלת אתגר ה-MFA.

בדוגמה הבאה מוצגת הערכה לדוגמה שבה הפעולה המומלצת היא דילוג על אימות דו-שלבי:

{
  [...],
  "accountDefenderAssessment": {
    labels: ["PROFILE_MATCH"],
    "recommended_action": "SKIP_2FA"
  }
}

השדה recommended_action יכול לקבל כל אחד מהערכים הבאים:

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

הפעלת אתגר MFA באתר

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

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

כדי להפעיל בקשה לאימות רב-שלבי:

  1. בודקים את השילוב של MFA.

    מפעילים אתגר MFA באמצעות קריאה ל-challengeAccount() עם הערכים הבאים:

    • KEY_ID: המפתח שמבוסס על ניקוד שהתקנתם באתר.
    • REQUEST_TOKEN_FROM_ASSESSMENT: הערך של השדה requestToken מהתשובה של ההערכה.
    • CONTAINER_HTML_COMPONENT_ID: מזהה של רכיב ה-HTML שבו צריך לעבד את אתגר האימות. אם לא מציינים את הפרמטר הזה, האתגר מעובד בשכבת-על מעל הדף.

    בדוגמה הבאה אפשר לראות איך מפעילים את אתגר האימות הרב-שלבי באמצעות קריאה ל-challengeAccount():

    grecaptcha.enterprise.challengeAccount(KEY_ID, {
      'account-token': REQUEST_TOKEN_FROM_ASSESSMENT,
      'container': CONTAINER_HTML_COMPONENT_ID
    }).then(newToken => {
      // Handle the new token.
    });
    

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

  2. יוצרים אמצעי אימות ומתחילים באתגר עם הפרמטרים הבאים:

    // Initialize verification handle.
    const verificationHandle = grecaptcha.enterprise.eap.initTwoFactorVerificationHandle(
      KEY_ID,
      REQUEST_TOKEN_FROM_ASSESSMENT
    );
    
    // Call the challenge API.
    verificationHandle.challengeAccount().then(
      (challengeResponse) => {
        if (challengeResponse.isSuccess()) {
          // Handle success: This means displaying an input for the end user to
          // enter the PIN that they received and then call the `verifyAccount(pin)`
          // method.
        } else {
          // Handle API failure
        }
      });
    

אימות קוד MFA מדף אינטרנט

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

כדי לאמת את קוד האימות, מתקשרים אל verificationHandle.verifyAccount() עם קוד האימות שהוזן על ידי משתמש הקצה.

verificationHandle.verifyAccount(pin).then(
  (verifyResponse) => {
    if (verifyResponse.isSuccess()) {
      // Handle success: Send the result of `verifyResponse.getVerdictToken()`
      // to the backend in order to determine if the code was valid.
    } else {
      // Handle API failure
    }
  },
  (error) => {
    // Handle other errors
  }
);

יצירת הערכה חדשה

יוצרים הערכה חדשה באמצעות accountId ו-endpoints. הוראות מפורטות זמינות במאמר בנושא יצירת הערכה לאימות דו-שלבי.

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

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

{
  [...],
  "accountVerification": {
    "endpoints": [{
      "emailAddress": "foo@bar.com",
      "requestToken": "tplIUFvvJUIpLaOH0hIVj2H71t5Z9mDK2RhB1SAGSIUOgOIsBv",
      "lastVerificationTime": "2020-03-23 08:27:12 PST",
    }],
    "latestVerificationResult": "SUCCESS_USER_VERIFIED"
  }
}

בשדה latestVerificationResult יכול להופיע סטטוס אחר, כמו שמפורט בטבלה הבאה:

סטטוס תוצאת האימות תיאור
SUCCESS_USER_VERIFIED המשתמש אומת.
ERROR_USER_NOT_VERIFIED המשתמש לא עבר את אתגר האימות.
ERROR_SITE_ONBOARDING_INCOMPLETE לא בוצע באתר תהליך ההצטרפות הנדרש לשימוש בתכונה.
ERROR_RECIPIENT_NOT_ALLOWED הנמען הזה לא אושר לשליחת אימייל אל (במהלך בדיקה בלבד).
ERROR_RECIPIENT_ABUSE_LIMIT_EXHAUSTED הנמען הזה כבר קיבל יותר מדי קודי אימות בפרק זמן קצר.
ERROR_CUSTOMER_QUOTA_EXHAUSTED חרגתם מהמכסה הזמינה של אימות דו-שלבי.
ERROR_CRITICAL_INTERNAL האימות לא הושלם בגלל שגיאה פנימית במערכות שלנו.
RESULT_UNSPECIFIED אין מידע על האימות האחרון (מעולם לא אומת).

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