בדף הזה מוסבר איך להגדיר אימות רב-שלבי (MFA) שמאפשר לאמת את זהות המשתמשים באמצעות שליחת קוד אימות באימייל. התכונה הזו מאפשרת לכם לוודא שהמשתמשים הם הבעלים של כתובת האימייל שמקושרת לחשבון שלהם. אימות רב-שלבי יכול לעזור לכם להגן על המשתמשים מפני התקפות של מילוי פרטי כניסה ופני השתלטות על חשבונות (ATO).
אימות רב-שלבי זמין למפתחות שמבוססים על ניקוד, ולא זמין למפתחות של תיבות סימון.
הסבר על תהליך ההגדרה של MFA
התכונה MFA של reCAPTCHA מיושמת בנוסף לתהליך העבודה הרגיל של reCAPTCHA.
באופן כללי, תהליך העבודה של MFA הוא כזה:
- לבצע אינסטרומנטציה של תהליך העבודה הקריטי באתר.
- יוצרים הערכה באמצעות האסימון שמוחזר על ידי הקריאה
execute()והפרמטרים של MFA כדי לקבל MFArequestToken. - הפעלת אתגר MFA באמצעות
requestTokenבהתאם לערוץ שבו רוצים להשתמש (רק אימייל נתמך). - מאמתים את קוד האימות שהזין משתמש הקצה באתר שלכם.
- יוצרים הערכה חדשה באמצעות האסימון שמוחזר בבקשת האימות.
לפני שמתחילים
אפשר לגשת ל-MFA אחרי בדיקת אבטחה, שמתחילה כשמוסיפים חשבון לחיוב לפרויקט. מוסיפים חשבון לחיוב כדי להפעיל את התכונה הזו באתר.
כדי להפעיל את תכונת האימות באימייל של MFA, צריך לבצע את הפעולות הבאות:
נכנסים לדף reCAPTCHA במסוף Google Cloud .
מוודאים ששם הפרויקט מופיע בבורר המשאבים.
אם שם הפרויקט לא מופיע, לוחצים על בורר המשאבים ובוחרים את הפרויקט.
לוחצים על הגדרות.
בחלונית אימות רב-שלבי, לוחצים על הגדרה.
בתיבת הדו-שיח Configure MFA, מבצעים את הפעולות הבאות:
- כדי להפעיל אימות באמצעות אימייל, לוחצים על המתג הפעלת אימייל.
- בתיבה שם השולח, מזינים את השם שלכם.
בתיבה כתובת האימייל של השולח, מזינים את כתובת האימייל.
לוחצים על Save.
אחרי שמגדירים את כתובת האימייל של השולח, צריך להגדיר את רשומות ה-DNS כדי למנוע בעיות בשליחת האימייל. בשלבים הבאים, מחליפים את
example.comבדומיין שלכם.מוסיפים רשומת SPF כדי לאפשר ל-reCAPTCHA לשלוח אימיילים בשמכם:
Host: example.com Value: v=spf1 include:_spf.recaptchamail.goog ~allכדי שהשרתים יוכלו למצוא את חתימת DKIM, צריך לכלול את רשומות ה-CNAME הבאות:
Host: recaptcha1._domainkey.example.com Value: recaptcha1._domainkey.recaptchamail.goog.Host: recaptcha2._domainkey.example.com Value: recaptcha2._domainkey.recaptchamail.goog.
הטמעה של כלי למעקב אחרי תהליך עבודה קריטי באתר
מעבירים את המידע הנדרש ל-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.
ספריות לקוח מומלץ להשתמש במשאבים הבאים:
- ב-Python או ב-Java, משתמשים במפתחות 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 שמושלם אחרי השלמת האתגר, או נדחית אם הייתה שגיאה או שהתרחש זמן קצוב לתפוגה.
בסיום, נוצר טוקן חדש שמכיל מידע מעודכן, ואז הוא נשלח לבדיקה.
כדי להפעיל בקשה לאימות רב-שלבי:
בודקים את השילוב של 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מועבר לפונקציה המשורשרת שמכילה את אסימון ההחלטה שצריך לאמת באמצעות הערכה שנוצרת בקצה העורפי.יוצרים אמצעי אימות ומתחילים באתגר עם הפרמטרים הבאים:
// 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 | אין מידע על האימות האחרון (מעולם לא אומת). |