אבטחת הסביבה

Google מציעה כמה ממשקי API ושירותים שיעזרו לכם לזהות אם האפליקציה שלכם פועל בסביבה בטוחה ומהימנה. החלק המרכזי הוא יושרה של Play ל-API, שעוזר לבדוק שהאינטראקציות אמינות על ידי זיהוי אינטראקציות מסוכנות וכאלה שמקורן בתרמית. בנוסף לתקינות האפליקציה והמכשיר, Play ב-Integrity API יש עכשיו מידע על סיכונים שקשורים לגישה ולנגישות, Google Play Protect ופעילות אחרונה במכשיר. כדי להקשיח עוד יותר האסטרטגיה שלכם למניעת הונאות, פלטפורמת Android מציעה ממשקי API לתרחישים ספציפיים שעשויים להיות רלוונטיים לאפליקציה.

Play Integrity API

התכונות של Play Integrity API

ב-Play Integrity API אפשר לקבל מידע על מצב האבטחה של המכשיר שהאפליקציה שלהם פועלת בו. כך תוכלו להיות בטוחים שהמשתמש הנכון ניגש למידע רגיש.

הוא עוזר לוודא שאינטראקציות ובקשות מהשרת מגיעות בינארי אמיתי של אפליקציה בסביבה מהימנה:

  • קובץ בינארי של אפליקציה בפועל: מציין אם אתם מבצעים אינטראקציה עם בינארי ללא שינויים ש-Google Play מזהה.
  • התקנה ראשונית ב-Play: מציין אם חשבון המשתמש הנוכחי ברישיון, כלומר המשתמש התקין את האפליקציה או את המשחק או שילם עליהם Google Play.
  • מכשיר Android מקורי: מציין אם האפליקציה פועלת במכשיר מקורי מכשיר מבוסס Android שמופעל על ידי Google Play Services.
  • נקי מתוכנות זדוניות ידועות: מציין אם Google Play Protect מופעל והאם הוא מצא אפליקציות מסוכנות או מסוכנות במכשיר.
  • סיכון נמוך לגישה של אפליקציות אחרות: בדיקה אם אפליקציות אחרות פועלות שיכולים לצלם את המסך או לשלוט במכשיר ובקלט של האפליקציה.

איך הפעולות האלה עוזרות לצמצם הונאות

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

תהליך קבלת ההחלטות של Play Integrity API

סיכון הגישה לאפליקציה

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

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

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

לסיכון הגישה לאפליקציה יש רמות סיכון שונות:

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

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

אכיפת סיכון הגישה לאפליקציה

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

הטבלה הזו כוללת כמה הגדרות לדוגמה:

דוגמה לתגובה לקביעת סיכון הגישה לאפליקציה פירוש
appsDetected:
["KNOWN_INSTALLED"] 		רק אפליקציות מותקנות ש-Google Play מזהה או בטעינה מראש של מחיצת המערכת על ידי יצרן המכשיר. לא פועלות אפליקציות שיכולות להוביל להקלטה, שליטה בקביעות או בשכבות-על של קביעות.
appsDetected:
["KNOWN_INSTALLED",
"UNKNOWN_INSTALLED",
"UNKNOWN_CAPTURING"] 		יש אפליקציות שהותקנו על ידי Google Play או שנטענו מראש מחיצת מערכת על ידי יצרן המכשיר. יש אפליקציות אחרות שפועלות והופעלו בהן הרשאות שעלולות יכול לשמש לצפייה במסך או לתיעוד קלט ופלט אחרים.
appsDetected:
["KNOWN_INSTALLED",
"KNOWN_CAPTURING",
"UNKNOWN_INSTALLED",
"UNKNOWN_CONTROLLING"] 		יש Play או מערכת הפעלה שמופעלות בהן הרשאות יכול לשמש לצפייה במסך או לתיעוד קלט ופלט אחרים. יש גם אפליקציות פועלות אחרות שמופעלות בהן הרשאות יכול לשמש לשליטה במכשיר ולשליטה ישירה בקלט באפליקציה שלך.
appAccessRiskVerdict: {} לא מתבצעת הערכה של סיכון הגישה לאפליקציה כי דרישה הכרחית לא הוגשו. לדוגמה, המכשיר לא היה מספיק מהימן.

אות Play Protect

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

environmentDetails:{
  playProtectVerdict: "NO_ISSUES"
}

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

הפעלת תיבת דו-שיח של Play Protect

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

תוצאה הסבר מה מומלץ לעשות?

NO_ISSUES

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

Play Protect מופעל ולא נמצאו בעיות כלשהן, ולכן לא תתבצע פעולה מצד המשתמש נדרש.

NO_DATA

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

Play Protect מופעל ולא נמצאו בעיות כלשהן, ולכן לא תתבצע פעולה מצד המשתמש נדרש.

POSSIBLE_RISK

Play Protect מושבת.

שירות Play Protect מופעל ולא נמצאו בעיות כלשהן, לכן לא מתבצעת פעולה מצד המשתמש הוא שדה חובה.

MEDIUM_RISK

שירות Play Protect מופעל ונמצאו בו אפליקציות שעלולות להזיק (PHA) במכשיר.

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

HIGH_RISK

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

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

UNEVALUATED

לא התבצעה הערכה של ההחלטה של Play Protect.

הפעולה הזו יכולה יכולות להיות לכך כמה סיבות, כולל הסיבות הבאות:

  • המכשיר לא מספיק מהימן.
  • משחקים בלבד: לחשבון המשתמש אין רישיון.

פעילות במכשיר מהזמן האחרון

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

אם מביעים הסכמה לקבלת recentDeviceActivity, השדה deviceIntegrity יש שני ערכים:

deviceIntegrity: {
  deviceRecognitionVerdict: ["MEETS_DEVICE_INTEGRITY"]
  recentDeviceActivity: {
    // "LEVEL_2" is one of several possible values.
    deviceActivityLevel: "LEVEL_2"
  }
}

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

בקשות רגילות לעומת בקשות קלאסיות

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

בקשה קלאסית

בקשה רגילה

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

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

לשימוש לעיתים רחוקות.

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

בקשה רגילה מורכבת משני חלקים:

  • הכנת ספק אסימוני התקינות (באופן חד פעמי)
  • בקשה לאסימון תקינות (על פי דרישה)

שימוש על פי דרישה (VOD).

במסמכי התיעוד של Play Integrity אפשר לקבל מידע נוסף על הגרסה הרגילה בקשות קלאסיות.

הטמעה

כדי להתחיל להשתמש ב-Play Integrity API:

כברירת מחדל, Play Integrity API מאפשר עד 10,000 בקשות ביום לכל אפליקציה. שפת תרגום מעוניינים בהגדלת מספר הבקשות המקסימלי היומי שלכם, פועלים לפי הוראות להתאמה אישית. זכאות להגדלת המספר היומי המקסימלי מהבקשות, האפליקציה שלך צריכה להטמיע את Play Integrity API בצורה תקינה ולהיות שזמינות ב-Google Play בנוסף לערוצי הפצה אחרים.

דברים שכדאי לזכור לגבי Play Integrity API

הגנה אוטומטית על שלמות האפליקציה (API >= 23)

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

איך הפעולות האלה עוזרות לצמצם הונאות

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

  • אם בדיקת מנהל ההתקנה תיכשל, המשתמשים יתבקשו להוריד את האפליקציה מ-Google Play.
  • אם בדיקת השינוי תיכשל, האפליקציה לא תפעל

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

הטמעה

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

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

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

דברים שכדאי לזכור

  • אסור לפרסם גרסאות לא מוגנות של אפליקציות
  • יש להיזהר כשמשלבים פתרונות הגנה מפני זיוף
  • בדיקת האפליקציה המוגנת לפני שמעבירים אותה לסביבת הייצור
  • מעקב אחרי הנתונים הסטטיסטיים כרגיל לכל עלייה במספר הקריסות
  • ניתן לדווח ל-Google Play על גרסאות סדוקות של האפליקציה