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.

זיהוי ומניעה של פעילויות הונאה שקשורות לחשבון באתרים

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

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

פעילויות חשודות
חשבונות עם התנהגויות דומות
בקשות שמגיעות ממכשירים שסומנו כמהימנים עבור משתמשים ספציפיים

על סמך הניתוח של Account defense והמודל הספציפי לאתר, אפשר לבצע את הפעולות הבאות:

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

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

הגדרת דפי אינטרנט להגנה על החשבון

כדי להפעיל זיהוי יעיל של פעילות חשודה, צריך להבין באופן מקיף את הפעילויות בחשבון. כדי להתחיל להעביר פעילויות שקשורות לחשבון אל Account defense, וכדי ליצור ולשפר את המודל הספציפי לאתר, צריך לבצע את הפעולות הבאות:

הפעלת איסוף נתוני טלמטריה אופקיים.
דיווח על פעולות משתמשים קריטיות.
הערכת אירועים קריטיים של משתמשים.
הוספת הערות לאירועים של משתמשים כדי לשפר את המודל הספציפי לאתר.

הפעלה של איסוף נתוני טלמטריה אופקיים

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

בדוגמה הבאה אפשר לראות איך טוענים את סקריפט ה-JavaScript של reCAPTCHA בדף אינטרנט.

    <head>
    <script src="https://www.google.com/recaptcha/enterprise.js?render=KEY_ID"></script>
    ....
    </head>

דיווח על פעולות משתמשים קריטיות

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

מומלץ לדווח על כל פעולות המשתמשים הקריטיות, כי זה עוזר באיסוף אותות נוספים. לכל פעולת משתמש שרוצים לדווח עליה, מחליפים את הערך של הפרמטר action של grecaptcha.enterprise.execute() בשם של פעולה שמתארת את פעולת המשתמש.

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

שם פעולה	אירוע ביוזמת המשתמש או פעולת משתמש
`LOGIN`	מתחברים לאתר.
`REGISTRATION`	הרשמה באתר.
`SECURITY_QUESTION_CHANGE`	בקשה לשנות את שאלת האבטחה.
`PASSWORD_RESET`	שולחים בקשה לאיפוס הסיסמה.
`PHONE_NUMBER_UPDATE`	בקשה לעדכן את מספר הטלפון.
`EMAIL_UPDATE`	בקשה לעדכן את כתובת האימייל.
`ACCOUNT_UPDATE`	בקשה לעדכן מידע שקשור לחשבון, כמו פרטים ליצירת קשר.
`TRIGGER_MFA`	פעולה שמפעילה אתגר MFA.
`REDEEM_CODE`	בקשה למימוש קוד.
`LIST_PAYMENT_METHODS`	שליפת רשימת אמצעי התשלום.

בדוגמה הבאה אפשר לראות איך מפעילים את grecaptcha.enterprise.execute() בעדכון של מספר טלפון:

    <script>
    function onClick(e) {
      e.preventDefault();
      grecaptcha.enterprise.ready(async () => {
        const token = await grecaptcha.enterprise.execute('KEY_ID', {action: 'PHONE_NUMBER_UPDATE'});
      });
    }
    </script>

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

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

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

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

מזהי משתמשים

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

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

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

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

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

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

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

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

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

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

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

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

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

גוף בקשת JSON:

{
  "event": {
    "token": "TOKEN",
    "siteKey": "KEY_ID",
    "userInfo": {
      "accountId": "ACCOUNT_ID",
      "userIds": [
        {
          "email": "EMAIL_ADDRESS"
        },
        {
          "phoneNumber": "PHONE_NUMBER"
        },
        {
          "username": "USERNAME"
        }
      ]
    }
  }
}

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

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 שדומה לזו:

{
  "tokenProperties": {
    "valid": true,
    "hostname": "www.google.com",
    "action": "login",
    "createTime": "2019-03-28T12:24:17.894Z"
  },
  "riskAnalysis": {
    "score": 0.6,
  },
  "event": {
    "token": "TOKEN",
    "siteKey": "KEY",
    "userInfo": {
      "accountId": "ACCOUNT_ID"
    }
  },
  "name": "projects/PROJECT_NUMBER/assessments/b6ac310000000000",
  "accountDefenderAssessment": {
    "labels": ["SUSPICIOUS_LOGIN_ACTIVITY"]
  }
}

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

דוגמת קוד

Java

כדי לבצע אימות ב-Fraud Defense, צריך להגדיר את Application Default Credentials. מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.


import com.google.cloud.recaptchaenterprise.v1.RecaptchaEnterpriseServiceClient;
import com.google.protobuf.ByteString;
import com.google.recaptchaenterprise.v1.AccountDefenderAssessment.AccountDefenderLabel;
import com.google.recaptchaenterprise.v1.Assessment;
import com.google.recaptchaenterprise.v1.CreateAssessmentRequest;
import com.google.recaptchaenterprise.v1.Event;
import com.google.recaptchaenterprise.v1.ProjectName;
import com.google.recaptchaenterprise.v1.RiskAnalysis.ClassificationReason;
import com.google.recaptchaenterprise.v1.TokenProperties;
import com.google.recaptchaenterprise.v1.UserId;
import com.google.recaptchaenterprise.v1.UserInfo;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException;
import java.util.List;
import java.util.UUID;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;

public class AccountDefenderAssessment {

  public static void main(String[] args)
      throws IOException, NoSuchAlgorithmException, InvalidKeyException {
    // TODO(developer): Replace these variables before running the sample.
    // projectId: Google Cloud Project ID
    String projectId = "project-id";

    // recaptchaSiteKey: Site key obtained by registering a domain/app to use recaptcha
    // services.
    String recaptchaSiteKey = "recaptcha-site-key";

    // token: The token obtained from the client on passing the recaptchaSiteKey.
    // To get the token, integrate the recaptchaSiteKey with frontend. See,
    // https://cloud.google.com/recaptcha-enterprise/docs/instrument-web-pages#frontend_integration_score
    String token = "recaptcha-token";

    // recaptchaAction: The action name corresponding to the token.
    String recaptchaAction = "recaptcha-action";

    // Unique ID of the user, such as email, customer ID, etc.
    String accountId = "default" + UUID.randomUUID().toString().split("-")[0];

    // User phone number
    String phoneNumber = "555-987-XXXX";

    // User email address
    String emailAddress = "john.doe@example.com";

    accountDefenderAssessment(projectId, recaptchaSiteKey, token, recaptchaAction, accountId, phoneNumber, emailAddress);
  }

  /**
   * This assessment detects account takeovers. See,
   * https://cloud.google.com/recaptcha-enterprise/docs/account-takeovers The input is the hashed
   * account id. Result tells if the action represents an account takeover. You can optionally
   * trigger a Multi-Factor Authentication based on the result.
   */
  public static void accountDefenderAssessment(
      String projectId,
      String recaptchaSiteKey,
      String token,
      String recaptchaAction,
      String accountId,
      String phoneNumber,
      String emailAddress)
      throws IOException {
    try (RecaptchaEnterpriseServiceClient client = RecaptchaEnterpriseServiceClient.create()) {

      // Set the properties of the event to be tracked.
      Event.Builder eventBuilder =
          Event.newBuilder()
              .setSiteKey(recaptchaSiteKey)
              .setToken(token);

      // Set the account id, email address and phone number (of the user).
      eventBuilder.setUserInfo(
        UserInfo.newBuilder()
          .setAccountId(accountId)
          .addUserIds(UserId.newBuilder().setEmail(emailAddress))
          .addUserIds(UserId.newBuilder().setPhoneNumber(phoneNumber)));

      Event event = eventBuilder.build();

      // Build the assessment request.
      CreateAssessmentRequest createAssessmentRequest =
          CreateAssessmentRequest.newBuilder()
              .setParent(ProjectName.of(projectId).toString())
              .setAssessment(Assessment.newBuilder().setEvent(event).build())
              .build();

      Assessment response = client.createAssessment(createAssessmentRequest);

      // Check integrity of the response token.
      if (!checkTokenIntegrity(response.getTokenProperties(), recaptchaAction)) {
        return;
      }

      // Get the reason(s) and the reCAPTCHA risk score.
      // For more information on interpreting the assessment,
      // see: https://cloud.google.com/recaptcha-enterprise/docs/interpret-assessment
      for (ClassificationReason reason : response.getRiskAnalysis().getReasonsList()) {
        System.out.println(reason);
      }
      float recaptchaScore = response.getRiskAnalysis().getScore();
      System.out.println("The reCAPTCHA score is: " + recaptchaScore);
      String assessmentName = response.getName();
      System.out.println(
          "Assessment name: " + assessmentName.substring(assessmentName.lastIndexOf("/") + 1));

      // Get the Account Defender result.
      com.google.recaptchaenterprise.v1.AccountDefenderAssessment accountDefenderAssessment =
          response.getAccountDefenderAssessment();
      System.out.println(accountDefenderAssessment);

      // Get Account Defender label.
      List<AccountDefenderLabel> defenderResult =
          response.getAccountDefenderAssessment().getLabelsList();
      // Based on the result, can you choose next steps.
      // If the 'defenderResult' field is empty, it indicates that Account Defender did not have
      // anything to add to the score.
      // Few result labels: ACCOUNT_DEFENDER_LABEL_UNSPECIFIED, PROFILE_MATCH,
      // SUSPICIOUS_LOGIN_ACTIVITY, SUSPICIOUS_ACCOUNT_CREATION, RELATED_ACCOUNTS_NUMBER_HIGH.
      // For more information on interpreting the assessment, see:
      // https://cloud.google.com/recaptcha-enterprise/docs/account-defender#interpret-assessment-details
      System.out.println("Account Defender Assessment Result: " + defenderResult);
    }
  }

  private static boolean checkTokenIntegrity(
      TokenProperties tokenProperties, String recaptchaAction) {
    // Check if the token is valid.
    if (!tokenProperties.getValid()) {
      System.out.println(
          "The Account Defender Assessment call failed because the token was: "
              + tokenProperties.getInvalidReason().name());
      return false;
    }

    // Check if the expected action was executed.
    if (!tokenProperties.getAction().equals(recaptchaAction)) {
      System.out.printf(
          "The action attribute in the reCAPTCHA tag '%s' does not match "
              + "the action '%s' you are expecting to score",
          tokenProperties.getAction(), recaptchaAction);
      return false;
    }
    return true;
  }
}

הסבר על פסיקת הסיכון של אירועים קריטיים שקשורים למשתמשים

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

הדוגמה הבאה היא תגובת JSON לדוגמה:

{
  "tokenProperties": {
    "valid": true,
    "hostname": "www.google.com",
    "action": "login",
    "createTime": "2019-03-28T12:24:17.894Z"
   },
  "riskAnalysis": {
    "score": 0.6,
  },
 "event": {
    "token": "TOKEN",
    "siteKey": "KEY_ID",
    "expectedAction": "USER_ACTION"
  },
  "name": "projects/PROJECT_ID/assessments/b6ac310000000000X",
  "accountDefenderAssessment": {
    labels: ["SUSPICIOUS_LOGIN_ACTIVITY"]
  }
}

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

ערך	תיאור
`SUSPICIOUS_LOGIN_ACTIVITY`	מציין שהבקשה מייצגת סיכון גבוה להחדרת פרטי כניסה או להשתלטות על חשבון.
`SUSPICIOUS_ACCOUNT_CREATION`	מציין שהבקשה מייצגת סיכון גבוה ליצירת חשבון עם התנהלות פוגעת.
`PROFILE_MATCH`	הערך הזה מציין שהמאפיינים של המשתמש תואמים למאפיינים שנראו קודם אצל המשתמש הספציפי הזה. הערך הזה מציין שהמשתמש נמצא במכשיר מהימן ששימש בעבר לגישה לאתר שלכם. הערך `PROFILE_MATCH` מוחזר רק בתרחישים הבאים: אתם משתמשים באימות רב-שלבי (MFA) או באימות דו-שלבי (2FA), ומערכת ההגנה על החשבון מסמנת את פרופילי המשתמשים כפרופילים מהימנים אחרי שהמשתמשים עוברים את אתגר האימות הרב-שלבי או האימות הדו-שלבי. אתם מוסיפים הערות להערכות כ-`LEGITIMATE` או כ-`PASSED_TWO_FACTOR`, ומערכת ההגנה על החשבון מסמנת את פרופיל המשתמש המתאים כפרופיל מהימן.
`RELATED_ACCOUNTS_NUMBER_HIGH`	מציין שבבקשה יש מספר גדול של חשבונות קשורים. המשמעות היא לאו דווקא שהחשבון בעייתי, אבל יכול להיות שנדרשת בדיקה נוספת.

הערה: אם השדה accountDefenderAssessment ריק, זה מצביע על כך שלא היה ל-Account Defense מה להוסיף לציון.

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

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

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

כדי להוסיף הערה להערכה:

קובעים את המידע והתוויות שרוצים להוסיף בגוף הבקשה ב-JSON, בהתאם לתרחיש השימוש.

בטבלה הבאה מפורטים התוויות והערכים שאפשר להשתמש בהם כדי להוסיף הערות לאירועים:

תווית תיאור דוגמה לבקשה

תווית	תיאור	דוגמה לבקשה
`reasons`	חובה. תווית שתעזור לכם בביצוע ההערכות. פרטי האירוע בזמן אמת מוצגים בתווית `reasons` תוך כמה שניות או דקות אחרי האירוע, כי הם משפיעים על הזיהוי בזמן אמת. רשימה של הערכים האפשריים זמינה במאמר ערכי הסיבות. דוגמה: כדי לזהות השתלטות על חשבון, מוסיפים הערה אם הסיסמה שהוזנה הייתה נכונה עם הערכים `CORRECT_PASSWORD` או `INCORRECT_PASSWORD`. אם פרסתם אימות רב-שלבי משלכם, אתם יכולים להוסיף את הערכים הבאים: `INITIATED_TWO_FACTOR`, ו- `PASSED_TWO_FACTOR` או `FAILED_TWO_FACTOR`.	{ "reasons": ["INCORRECT_PASSWORD"] }
`annotation`	זה שינוי אופציונלי. תווית שמציינת את הלגיטימיות של ההערכות. הוספת עובדות לגבי אירועי כניסה ורישום כדי לאמת או לתקן את הערכות הסיכון בתווית `annotation`. ערכים אפשריים: `LEGITIMATE` או `FRAUDULENT`. אפשר לשלוח את המידע הזה בכל שלב או כחלק ממשימה באצווה. עם זאת, מומלץ לשלוח את המידע הזה כמה שניות או דקות אחרי האירוע, כי הוא משפיע על הזיהוי בזמן אמת.	{ "annotation": "LEGITIMATE" }
`accountId`	זה שינוי אופציונלי. תווית לשיוך מזהה חשבון לאירוע. אם יצרתם הערכה ללא מזהה חשבון, אתם יכולים להשתמש בתווית הזו כדי לספק את מזהה החשבון של אירוע בכל פעם שהוא זמין.	{ "accountId": "`ACCOUNT_ID`" }

reasons

חובה. תווית שתעזור לכם בביצוע ההערכות.

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

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

דוגמה: כדי לזהות השתלטות על חשבון, מוסיפים הערה אם הסיסמה שהוזנה הייתה נכונה עם הערכים CORRECT_PASSWORD או INCORRECT_PASSWORD. אם פרסתם אימות רב-שלבי משלכם, אתם יכולים להוסיף את הערכים הבאים: INITIATED_TWO_FACTOR, ו- PASSED_TWO_FACTOR או FAILED_TWO_FACTOR.

      {
      "reasons": ["INCORRECT_PASSWORD"]
      }

annotation

זה שינוי אופציונלי. תווית שמציינת את הלגיטימיות של ההערכות.

הוספת עובדות לגבי אירועי כניסה ורישום כדי לאמת או לתקן את הערכות הסיכון בתווית annotation.

ערכים אפשריים: LEGITIMATE או FRAUDULENT.

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

      {
       "annotation": "LEGITIMATE"
      }

accountId

זה שינוי אופציונלי. תווית לשיוך מזהה חשבון לאירוע.

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

  {
   "accountId": "ACCOUNT_ID"
  }

יוצרים בקשת הערה עם התוויות המתאימות.

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:
- ‫ASSESSMENT_ID: הערך של השדה name שמוחזר מהקריאה projects.assessments.create.
- ‫ANNOTATION: אופציונלי. תווית שמציינת אם הבדיקה לגיטימית או שמקורה בתרמית.
- ‫REASONS: אופציונלי. סיבות שתומכות בהערה שלכם. רשימת הערכים האפשריים מופיעה במאמר ערכי הסיבות.
- ‫ACCOUNT_ID: אופציונלי. המזהה שמשויך באופן ייחודי לחשבון המשתמש באתר שלכם.
מידע נוסף זמין במאמר בנושא תוויות להערות.

ה-method של ה-HTTP וכתובת ה-URL:
```
POST https://recaptchaenterprise.googleapis.com/v1/ASSESSMENT_ID:annotate
```
גוף בקשת JSON:
```
{
  "annotation": ANNOTATION,
  "reasons": REASONS,
  "accountId": ACCOUNT_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/ASSESSMENT_ID:annotate"
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/ASSESSMENT_ID:annotate" | Select-Object -Expand Content
אמורים לקבל קוד סטטוס של הצלחה (2xx) ותגובה ריקה.

דוגמת קוד

Java


import com.google.cloud.recaptchaenterprise.v1.RecaptchaEnterpriseServiceClient;
import com.google.protobuf.ByteString;
import com.google.recaptchaenterprise.v1.AnnotateAssessmentRequest;
import com.google.recaptchaenterprise.v1.AnnotateAssessmentRequest.Annotation;
import com.google.recaptchaenterprise.v1.AnnotateAssessmentRequest.Reason;
import com.google.recaptchaenterprise.v1.AnnotateAssessmentResponse;
import com.google.recaptchaenterprise.v1.AssessmentName;
import java.io.IOException;
import java.security.NoSuchAlgorithmException;
import java.util.UUID;

public class AnnotateAccountDefenderAssessment {

  public static void main(String[] args) throws IOException, NoSuchAlgorithmException {
    // TODO(developer): Replace these variables before running the sample.
    // projectID: GCloud Project id.
    String projectID = "project-id";

    // assessmentId: Value of the 'name' field returned from the CreateAssessment call.
    String assessmentId = "account-defender-assessment-id";

    // accountId: Set the accountId corresponding to the assessment id.
    String accountId = "default" + UUID.randomUUID().toString().split("-")[0];

    annotateAssessment(projectID, assessmentId, accountId);
  }

  /**
   * Pre-requisite: Create an assessment before annotating. Annotate an assessment to provide
   * feedback on the correctness of recaptcha prediction.
   */
  public static void annotateAssessment(
      String projectID, String assessmentId, String accountId) throws IOException {

    try (RecaptchaEnterpriseServiceClient client = RecaptchaEnterpriseServiceClient.create()) {
      // Build the annotation request.
      // For more info on when/how to annotate, see:
      // https://cloud.google.com/recaptcha-enterprise/docs/annotate-assessment#when_to_annotate
      AnnotateAssessmentRequest annotateAssessmentRequest =
          AnnotateAssessmentRequest.newBuilder()
              .setName(AssessmentName.of(projectID, assessmentId).toString())
              .setAnnotation(Annotation.LEGITIMATE)
              .addReasons(Reason.PASSED_TWO_FACTOR)
              .setAccountId(accountId)
              .build();

      // Empty response is sent back.
      AnnotateAssessmentResponse response = client.annotateAssessment(annotateAssessmentRequest);
      System.out.println("Annotated response sent successfully ! " + response);
    }
  }
}

שימוש בציון הסיכון של השתלטות על החשבון והסבר שלו

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

קבלת ציון הסיכון

כדי לקבל את ציון הסיכון ואת הסיבות להסבר, שולחים CreateAssessment בקשה וכוללים את event.userInfo.accountId בבקשה.

קריאת ציון הסיכון והפרטים

ציון הסיכון והנימוקים להסבר מופיעים באובייקט accountDefenderAssessment.accountTakeoverVerdict בתגובת ההערכה.

ניקוד הסיכון: accountDefenderAssessment.accountTakeoverVerdict.risk
סיבות לסיכון: accountDefenderAssessment.accountTakeoverVerdict.riskReasons
סיבות להרשאות שיתוף: accountDefenderAssessment.accountTakeoverVerdict.trustReasons

בקטע הקוד הבא מוצגת דוגמה לשדות בתשובה של הערכה:

  "accountDefenderAssessment": {
    "labels": ["PROFILE_MATCH"],
    "accountTakeoverVerdict": {
      "risk": 0.249,
      "riskReasons": [{"reason": "CLIENT_ACCESSED_MANY_ACCOUNTS"}],
      "trustReasons": [{"reason": "PROFILE_MATCH"}, {"reason": "ACCOUNT_HISTORY_REPUTABLE"}]
    }
  }

פירוש של ציון הסיכון של ATO

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

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

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

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

if (assessment.accountDefenderAssessment.accountTakeoverVerdict.risk > YOUR_CHOSEN_THRESHOLD) {
  // Treat as suspicious
  // Implement protective actions
}

ערכי סף סטנדרטיים של ציון סיכון

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

שיעור חיוביים כוזבים צפוי	סף דירוג הסיכונים
0.1%	1.0
‫0.25%	0.9
0.5%	0.8
‫1%	0.7
2%	0.6
‫4%	‫0.5
‫8%	0.4
15%	0.3
30%	0.2
60%	0.1
100%	0.0

שינוי הסף

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

חישוב ערכי ביניים

כדי לאמוד את שיעור התוצאות החיוביות השגויות (FPR) עבור ערך סף בין הערכים הרגילים, משתמשים באינטרפולציה לינארית. בדוגמה הבאה אפשר לראות איך מחשבים את שיעור התוצאות החיוביות השגויות (FPR) עבור סף של 0.85:

FPR(T: 0.85) = (FPR(T: 0.8) + FPR(T: 0.9)) / 2 = (0.5% + 0.25%) / 2 = 0.375%

כדי למצוא ערך סף לFPR ספציפי, צריך לבצע אינטרפולציה בין הערכים הרגילים. בדוגמה הבאה אפשר לראות איך מוצאים את ערך הסף של FPR של 5%:

Threshold = 0.4 + (0.5 − 0.4) × (8% − 5%) / (8% − 4%)
Threshold = 0.4 + 0.1 × (3 / 4)
Threshold = 0.4 + 0.075 = 0.475

הערך של סף מהימנות של 0.475 צפוי להניב FPR של 5%.

פירוש של סיבות להסבר

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

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

יכולות להופיע סיבות שקשורות לסיכון ולמהימנות בכל דירוג סיכון.

סיבה	סוג	פירוש
`PROFILE_MATCH`	אמון	הבקשה תואמת לפרופיל מהימן שמשויך לחשבון הזה. התוצאה שוות ערך לתווית `AccountDefenderLabel.PROFILE_MATCH`.
`ACCOUNT_HISTORY_REPUTABLE`	אמון	הפעילות ההיסטורית בחשבון היא בעלת מוניטין טוב. סביר להניח שהחשבון לא נפרץ בעבר.
`CLIENT_HISTORICAL_BOT_ACTIVITY`	סיכון	זוהה בעבר שהלקוח שולח תנועת גולשים שדומה לבוטים לאתר הזה. הסיבה הזו משלבת נתונים היסטוריים על המוניטין ומציינת שהלקוח ידוע בשימוש בבוטים, גם אם הבקשה הנוכחית מגיעה מאדם.
`ACCOUNT_IN_LARGE_RELATED_GROUP`	סיכון	החשבון הוא חלק מקבוצה גדולה של חשבונות קשורים, מה שמצביע על כך שהוא עשוי להיות חלק מרשת הונאה. זיהוי חשבונות קשורים מתבצע על סמך דפוסי תנועה דומים ומאפייני בקשות דומים.
`CLIENT_ACCESSED_MANY_ACCOUNTS`	סיכון	זוהתה גישה של הלקוח למספר רב של חשבונות באתר הזה.

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

זיהוי חשבונות שמציגים התנהגויות קשורות באמצעות ממשקי API.

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

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

הגדרת דפי אינטרנט להגנה על החשבון

הפעלה של איסוף נתוני טלמטריה אופקיים

דיווח על פעולות משתמשים קריטיות

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

מזהי משתמשים

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

curl

PowerShell

דוגמת קוד

Java

הסבר על פסיקת הסיכון של אירועים קריטיים שקשורים למשתמשים

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

curl

PowerShell

דוגמת קוד

Java

שימוש בציון הסיכון של השתלטות על החשבון והסבר שלו

קבלת ציון הסיכון

קריאת ציון הסיכון והפרטים

פירוש של ציון הסיכון של ATO

ערכי סף סטנדרטיים של ציון סיכון

שינוי הסף

חישוב ערכי ביניים

פירוש של סיבות להסבר

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

זיהוי ומניעה של פעילויות הונאה שקשורות לחשבון באתרים