‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

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

מזהי משתמשים

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

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

מגובבים או מוצפנים

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

בוחרים מזהה חשבון יציב כלשהו ומסתירים אותו לפני ששולחים אותו ל-Fraud Defense באמצעות הצפנה או גיבוב (hashing):

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

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

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

מוסיפים את מזהה החשבון הקבוע שנבחר לפרמטר accountId ב-method‏ 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 כדי לספק מזהה חשבון יציב ל-method‏ 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;
  }
}

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

כשיוצרים בדיקה עם התכונה "הגנה על החשבון" מופעלת, התכונה מחזירה את הערך 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), והתכונה "הגנה על החשבון" מסמנת את פרופילי המשתמשים כמהימנים אחרי שהמשתמשים עוברים את אתגר ה-MFA או ה-2FA. אתם מוסיפים הערות להערכות בתור `LEGITIMATE` או `PASSED_TWO_FACTOR`, והתכונה "הגנה על החשבון" מסמנת את פרופיל המשתמש התואם כמהימן.
`RELATED_ACCOUNTS_NUMBER_HIGH`	מציין שבבקשה יש מספר גבוה של חשבונות קשורים. זה לא בהכרח אומר שהחשבון לא תקין, אבל יכול להיות שצריך לבדוק אותו לעומק.

הערה: אם השדה accountDefenderAssessment ריק, סימן שלתכונה "הגנה על החשבון" לא היה מה להוסיף לניקוד.

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

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

כדי להוסיף הערה להערכה, שולחים בקשה למתודה 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

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


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.5	4%
בינוני	0.7	1%
גבוהה	0.9	0.25%

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

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

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

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

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

שינוי סף הסיכון להשתלטות על החשבון

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

שינוי סף החיוב

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

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

כדי להעריך את שיעור החיוביים השגויים (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%.

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

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

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

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

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

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

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

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

מזהי משתמשים

מגובבים או מוצפנים

curl

PowerShell

דוגמת קוד

Java

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

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

curl

PowerShell

דוגמת קוד

Java

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

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

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

פירוש ציון הסיכון של השתלטות על החשבון (ATO)

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

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

שינוי סף הסיכון להשתלטות על החשבון

שינוי סף החיוב

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

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

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