אבטחת הסביבה

Google מציעה קבוצה של ממשקי API ושירותים שיעזרו לכם לזהות אם האפליקציה שלכם פועלת בסביבה בטוחה ואמינה. הרכיב המרכזי הוא Play Integrity 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, שותף גישה מוקדמת

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

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

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

אפשר לזהות פעולות רגישות או בעלות ערך גבוה באפליקציה או במשחק כדי להגן עליהן באמצעות Play 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 Signal

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

environmentDetails:{
  playProtectVerdict: "NO_ISSUES"
}

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

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

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

תוצאה הסבר הפעולה המומלצת

NO_ISSUES

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

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

NO_DATA

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

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

POSSIBLE_RISK

שירות Play Protect מושבת.

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

MEDIUM_RISK

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

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

בקשה קלאסית

בקשה רגילה

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

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

שימוש לא תדיר.

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

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

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

שימוש על פי דרישה.

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

הטמעה

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

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

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

הגנה אוטומטית על תקינות (API מגרסה 23 ואילך)

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

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

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

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

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

הטמעה

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

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

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

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

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