Google מציעה קבוצה של ממשקי API ושירותים שיעזרו לכם לזהות אם האפליקציה שלכם פועלת בסביבה בטוחה ואמינה. הרכיב המרכזי הוא Play Integrity API, שמזהה אינטראקציות מסוכנות ותרמיתיות פוטנציאליות כדי לוודא שהאינטראקציות הן אמיתיות. בנוסף לתקינות האפליקציות והמכשירים, Play Integrity API מציע עכשיו מידע על סיכוני גישה ונגישות, על Google Play Protect ועל פעילות במכשיר מהזמן האחרון. כדי לשפר את אסטרטגיית המאבק בתרמית, פלטפורמת Android מציעה ממשקי API לתרחישים ספציפיים שעשויים להיות רלוונטיים לאפליקציה שלכם.
Play Integrity API
Play Integrity API מאפשר לכם לקבל מידע על מצב האבטחה של המכשיר שבו האפליקציה שלכם פועלת. כך תוכלו להיות בטוחים שהמשתמש הנכון מקבל גישה למידע רגיש.
הוא עוזר לכם לוודא שהאינטראקציות ובקשות השרת מגיעות מהקוד הבינארי המקורי של האפליקציה בסביבה מהימנה:
- קוד בינארי מקורי של האפליקציה: מאפשר לכם לקבוע אם האינטראקציה מתבצעת עם הקוד הבינארי המקורי, כפי שמערכת Google Play מזהה אותו.
- התקנה מקורית מ-Play: בודקים אם לחשבון המשתמש הנוכחי יש רישיון, כלומר אם המשתמש התקין את האפליקציה או את המשחק או שילם עליהם ב-Google Play.
- מכשיר Android מקורי: אפשר לבדוק אם האפליקציה פועלת במכשיר Android מקורי שמופעל על ידי Google Play Services.
- ללא תוכנות זדוניות מוכרות: הסטטוס מציין אם Google Play Protect מופעל ואם התגלו במכשיר אפליקציות שרמת הסיכון שלהן נחשבת בינונית או גבוהה.
- סיכון נמוך לגישה מאפליקציות אחרות: אפשר לבדוק אם פועלות אפליקציות אחרות שיכולות לצלם את המסך או לשלוט במכשיר ובקלט באפליקציה.
איך הפעולה הזו עוזרת לצמצם הונאות
כשמשתמש מבצע פעולה חשובה באפליקציה, אפשר לקרוא ל-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 או להסיר אפליקציות מזיקות לפני שהם ממשיכים.
הערך של playProtectVerdict
יכול להיות אחד מהערכים הבאים:
תוצאה | הסבר | הפעולה המומלצת |
---|---|---|
|
שירות Play Protect מופעל ולא נמצאו בעיות באפליקציות במכשיר. |
Play Protect מופעל ולא נמצאו בעיות, ולכן לא נדרשת פעולה מצד המשתמש. |
|
שירותי Play Protect מופעלים, אבל עדיין לא בוצעה סריקה. יכול להיות שהמכשיר או אפליקציית Play Store אופסו לאחרונה. |
Play Protect מופעל ולא נמצאו בעיות, ולכן לא נדרשת פעולה מצד המשתמש. |
|
שירות Play Protect מושבת. |
Play Protect מופעל ולא נמצאו בעיות, ולכן לא נדרשת פעולה מצד המשתמש. |
|
Play Protect מופעל ונמצאו במכשיר אפליקציות שעלולות להזיק. |
בהתאם לסף הסיכונים שלכם, תוכלו לבקש מהמשתמש להפעיל את Play Protect ולפעול בהתאם לאזהרות של Play Protect. אם המשתמש לא יכול לעמוד בדרישות האלה, תוכלו לחסום אותו מהפעלת השרת. |
|
Play Protect מופעל ונמצאו במכשיר אפליקציות מסוכנות. |
בהתאם לסף הסיכונים שלכם, תוכלו לבקש מהמשתמש להפעיל את Play Protect ולפעול בהתאם לאזהרות של Play Protect. אם המשתמש לא יכול לעמוד בדרישות האלה, תוכלו לחסום אותו מפני הפעולה בשרת. |
|
לא בוצעה הערכה של התוצאה של 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 ב-Google Play Console ומקשרים לפרויקט ב-Google Cloud.
- משלבים את Play Integrity API באפליקציה.
- מחליטים איך לטפל בפסקי הדין.
כברירת מחדל, Play Integrity API מאפשר לשלוח עד 10,000 בקשות לכל אפליקציה ביום. כדי להביע עניין בהגדלת מספר הבקשות היומי המקסימלי, פועלים לפי ההוראות האלה. כדי לעמוד בדרישות להגדלת המספר המקסימלי של בקשות ביום, האפליקציה שלכם צריכה לכלול הטמעה תקינה של Play Integrity API ולהיות זמינה ב-Google Play בנוסף לכל ערוץ הפצה אחר.
דברים שכדאי לזכור לגבי Play Integrity API
- חשוב לטפל בשגיאות בתגובות של Play Integrity API בצורה מתאימה. פועלים לפי המדריך הזה בנושא אסטרטגיות לניסיון חוזר ולאכיפה על סמך קודי שגיאה.
- ב-Play Integrity API יש כלים לבדיקת התגובות.
- כדי לראות את תוצאת תקינות הנתונים מהמכשיר, פועלים לפי השלבים האלה.
- כדאי לעיין בשיקולי האבטחה האלה כדי לקבל שיטות מומלצות לשימוש ב-Play Integrity API.
הגנה אוטומטית על תקינות (API מגרסה 23 ואילך)
הגנה אוטומטית על שלמות האפליקציה היא שירות להגנה על קוד מפני פגיעה, שמגן על האפליקציה מפני ניצול לרעה של השלמות שלה בצורה של שינוי לא מורשה והפצה מחדש. היא פועלת ללא חיבור לאינטרנט, ללא צורך בפעולות מצד המפתח לפני הבדיקה וללא שילוב של שרת עורפי.
איך הפעולה הזו עוזרת לצמצם הונאות
כשמפעילים את ההגנה האוטומטית על שלמות האפליקציה, מערכת Google Play מוסיפה בדיקות לקוד של האפליקציה ומקשה על ההסרה שלהן באמצעות טכניקות ערבוב מתקדמות וטכניקות נגד הנדסה הפוכה. בזמן הריצה, ההגנה בודקת אם האפליקציה נפרצה או הופצה מחדש:
- אם הבדיקה של מנהל ההתקנה נכשלת, המשתמשים יתבקשו להוריד את האפליקציה מ-Google Play.
- אם בדיקת השינויים נכשלת, האפליקציה לא תפעל
כך המשתמשים מוגנים מפני גרסאות משופרות של האפליקציה.
הטמעה
נכון לעכשיו, ההגנה האוטומטית על שלמות האפליקציה זמינה רק לשותפי Play נבחרים. אם התכונה לא זמינה ב-Google Play Console ואתם רוצים לקבל גישה אליה, תוכלו לפנות לתמיכה למפתחים של Google Play.
אפשר להפעיל את ההגנה כשיוצרים גרסה או בדף תקינות האפליקציה ('גרסה' > 'תקינות האפליקציה'). כדי להשתמש בהגנה האוטומטית על תקינות האפליקציה, צריך להשתמש בשירות Play App Signing.
חשוב לבדוק את האפליקציה המוגנת לפני שמשיקים אותה בסביבת הייצור.
דברים שכדאי לזכור
- לא לפרסם גרסאות של אפליקציות ללא הגנה
- חשוב להיזהר כשמשלבים פתרונות להגנה מפני פגיעה
- בדיקת האפליקציה המוגנת לפני השקתה בסביבת הייצור
- כדאי לעקוב אחרי הנתונים הסטטיסטיים כרגיל כדי לראות אם יש עלייה במספר הקריסות.
- אתם יכולים לדווח ל-Google Play על גרסאות פרוצות של האפליקציה