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
האות של Play Protect מציין לאפליקציה אם Play Protect מופעל ואם הוא זיהה במכשיר אפליקציות מזיקות ידועות.
environmentDetails:{
playProtectVerdict: "NO_ISSUES"
}
אם תוכנות זדוניות הן בעיה שחשוב לכם לפתור באפליקציה או בנתונים של המשתמשים, תוכלו לבדוק את התוצאה הזו ולבקש מהמשתמשים להפעיל את Play Protect או להסיר אפליקציות מזיקות לפני שתמשיכו.
הערך playProtectVerdict יכול להיות אחד מהערכים הבאים:
| תוצאה | הסבר | מה מומלץ לעשות? |
|---|---|---|
|
Play Protect מופעל ולא נמצאו בעיות באפליקציות במכשיר. |
Play Protect מופעל ולא נמצאו בעיות, כך שלא נדרשת פעולה מצד המשתמש. |
|
שירותי Play Protect מופעלים, אבל עדיין לא בוצעה סריקה. יכול להיות שהמכשיר או אפליקציית חנות Play אופסו לאחרונה. |
Play Protect מופעל ולא נמצאו בעיות, כך שלא נדרשת פעולה מצד המשתמש. |
|
שירות Play Protect מושבת. |
Play Protect מופעל ולא נמצאו בעיות, ולכן לא נדרשת פעולה מצד המשתמש. |
|
Play Protect מופעל ומצא אפליקציות שעלולות להזיק (PHA) שמותקנות במכשיר. |
בהתאם למידת הסיכון שאתם מוכנים לקחת, אתם יכולים לבקש מהמשתמש להפעיל את 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 APIs בצורה מתאימה. כדאי לעיין במדריך הזה בנושא אסטרטגיות לניסיון חוזר ולאכיפה על סמך קודי שגיאה.
- Play Integrity API מציע כלי בדיקה לתגובות.
- כדי לראות את תוצאת הבדיקה של תקינות המכשיר, פועלים לפי השלבים האלה.
- מומלץ לקרוא את השיקולים בנושא אבטחה כדי להכיר את השיטות המומלצות לשימוש ב-Play Integrity API.
הגנה אוטומטית על תקינות האפליקציה (API >= 23)
הגנה אוטומטית על תקינות האפליקציה היא שירות להגנה על הקוד מפני פגיעה, שמגן על האפליקציה מפני ניצול לרעה של תקינות האפליקציה בצורה של שינוי לא מאושר והפצה מחדש. ההגנה פועלת ללא חבילת גלישה, לא נדרשת פעולה מצד המפתח לפני הבדיקה ואין צורך בשילוב של שרת עורפי.
איך זה עוזר לצמצם את הסיכון להונאה
כשמפעילים את ההגנה האוטומטית על תקינות האפליקציה, מערכת Google Play מוסיפה בדיקות לקוד של האפליקציה, וקשה להסיר אותן כי היא משתמשת בטכניקות מתקדמות של ערפול קוד (obfuscation) והנדסה הפוכה. בזמן הריצה, ההגנה בודקת אם האפליקציה שלכם עברה שינוי לא מורשה או הופצה מחדש:
- אם בדיקת מנהל ההתקנה תיכשל, המשתמשים יתבקשו להוריד את האפליקציה מ-Google Play
- אם בדיקת השינויים תיכשל, האפליקציה לא תפעל
כך אנחנו יכולים להגן על המשתמשים מפני גרסאות ששונו של האפליקציה.
הטמעה
הגנה אוטומטית על תקינות האפליקציה זמינה כרגע רק לשותפי Play נבחרים. אם התכונה לא זמינה ב-Google Play Console ואתם רוצים להביע עניין בקבלת גישה, אתם יכולים לפנות לתמיכה למפתחים של Google Play.
אפשר להפעיל את ההגנה כשיוצרים גרסה חדשה או בדף מוגנת באמצעות Play. הגנה אוטומטית על תקינות האפליקציה מחייבת שהאפליקציה תשתמש בחתימת אפליקציה ב-Play.
חשוב לבדוק את האפליקציה המוגנת לפני שמעבירים את הגרסה לסביבת הייצור.
דברים שכדאי לזכור
- לא לפרסם גרסאות לא מוגנות של אפליקציות
- זהירות כשמשלבים פתרונות להגנה מפני חדירה לקוד
- בדיקת האפליקציה המוגנת לפני פרסום שלה בסביבת הייצור
- עוקבים אחרי הנתונים הסטטיסטיים כרגיל כדי לזהות עלייה במספר הקריסות
- אפשר לדווח ל-Google Play על גרסאות פרוצות של האפליקציה