reCAPTCHA is a part of Google Cloud Fraud Defense. For more information, see Google Cloud Fraud Defense.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

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

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

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

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

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

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

הערה: מומלץ מאוד לספק למשתמשי הקצה כמה שיטות אימות, כמו פנייה לתמיכת הלקוחות כדי לאמת את החשבון שלהם, כדי למנוע מצב שבו הם לא יוכלו לגשת לחשבונות שלהם כי אימות דו-שלבי לא זמין.
1. נכנסים לדף reCAPTCHA במסוף Google Cloud .
  
  מעבר אל reCAPTCHA
2. מוודאים ששם הפרויקט מופיע בבורר המשאבים.
  
  אם שם הפרויקט לא מופיע, לוחצים על בורר המשאבים ובוחרים את הפרויקט.
3. לוחצים על הגדרות.
4. בחלונית אימות רב-שלבי, לוחצים על הגדרה.
5. בתיבת הדו-שיח Configure MFA, מבצעים את הפעולות הבאות:
  1. כדי להפעיל אימות באמצעות אימייל, לוחצים על המתג הפעלת אימייל.
  2. בתיבה שם השולח, מזינים את השם שלכם.
  3. בתיבה כתובת האימייל של השולח, מזינים את כתובת האימייל.
6. לוחצים על Save.
הערה: כברירת מחדל, האימייל שנשלח הוא כללי ולא ממותג. אם אתם רוצים להוסיף מיתוג או להתאים אישית את האימייל הזה, אתם יכולים לפנות למומחה הטכני שהוקצה לכם.
אחרי שמגדירים את כתובת האימייל של השולח, צריך להגדיר את רשומות ה-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.
```
הגדרת reCAPTCHA באתר באמצעות מפתחות מבוססי-ניקוד

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

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

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

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

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

יצירת מבדק

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

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

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

מגדירים אימות ל-Fraud Defense.

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

סביבה	ממשק	שיטת אימות
Google Cloud	REST ספריות לקוח	להשתמש בחשבונות שירות שמצורפים.
באחסון מקומי או אצל ספק אחר של שירותי ענן	REST	משתמשים במפתחות API או באיחוד שירותי אימות הזהות של עומסי עבודה. אם אתם רוצים להשתמש במפתחות API, מומלץ לאבטח אותם על ידי החלת הגבלות על מפתחות API.
ספריות לקוח	מומלץ להשתמש במשאבים הבאים: ב-Python או ב-Java, משתמשים במפתחות API או באיחוד שירותי אימות הזהות של עומסי עבודה. אם אתם רוצים להשתמש במפתחות API, מומלץ לאבטח אותם על ידי החלת הגבלות על מפתחות API. בשפות אחרות, אפשר להשתמש באיחוד שירותי אימות הזהויות של עומסי עבודה.

סביבה

ממשק

שיטת אימות

Google Cloud

REST
ספריות לקוח

להשתמש בחשבונות שירות שמצורפים.

באחסון מקומי או אצל ספק אחר של שירותי ענן

REST

משתמשים במפתחות API או באיחוד שירותי אימות הזהות של עומסי עבודה.

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

ספריות לקוח

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

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

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

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

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

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

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

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login, או באמצעות Cloud Shell שמחבר אתכם אוטומטית ל-CLI של gcloud. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

שומרים את גוף הבקשה בקובץ בשם 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

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

שומרים את גוף הבקשה בקובץ בשם 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 מוצגת הפעולה האפשרית שאפשר לבצע לפני הפעלת אתגר האימות הרב-שלבי.

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

{
  [...],
  "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 שמושלם אחרי השלמת האתגר, או נדחה אם הייתה שגיאה או שהזמן הקצוב לתגובה הסתיים. בסיום התהליך, נוצר טוקן חדש שמכיל את המידע המעודכן, והוא נשלח להערכה.

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

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

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

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

// 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	אין מידע על האימות האחרון (מעולם לא אומת).

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

זיהוי ומניעה של פעילויות הונאה שקשורות לחשבון באמצעות reCAPTCHA Account defense