סקירה כללית של Play Integrity API

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

ה-API מחזיר קביעות שעוזרות לכם לזהות איומים פוטנציאליים, כולל:

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

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

• מכשירים שלא הוחלו עליהם תיקונים: התגובה MEETS_STRONG_INTEGRITY בתוצאת הבדיקה deviceIntegrity עוזרת לכם לקבוע אם הוחלו על המכשיר עדכוני אבטחה מהזמן האחרון (למכשירים עם Android 13 ומעלה).
• גישה מסוכנת של אפליקציות אחרות: האות appAccessRiskVerdict עוזר לכם לקבוע אם פועלות אפליקציות שיכולות לשמש לצילום המסך, להצגת שכבות-על או לשליטה במכשיר (לדוגמה, על ידי שימוש לרעה בהרשאת הנגישות).
• תוכנות זדוניות מוכרות: הסטטוס playProtectVerdict מציין אם Google Play Protect מופעל ואם התגלו במכשיר אפליקציות שרמת הסיכון שלהן נחשבת בינונית או גבוהה.
• פעילות יתר: הרמה recentDeviceActivity עוזרת לכם לקבוע אם מכשיר מסוים שלח לאחרונה נפח גבוה באופן חריג של בקשות, מה שיכול להעיד על תנועה אוטומטית ועל מתקפה.
• ניצול לרעה חוזר ומכשירים שנעשה בהם שימוש חוזר: deviceRecall (בטא) עוזרת לכם לקבוע אם אתם מבצעים אינטראקציה עם מכשיר שסימנתם בעבר, גם אם האפליקציה הותקנה מחדש או שהמכשיר אופס.

אפשר להשתמש ב-API בכל הפלטפורמות של Android, כולל טלפונים, טאבלטים, מכשירים מתקפלים, Android Auto, ‏ Android TV, ‏ Android XR, ‏ ChromeOS, ‏ Wear OS וב-Google Play Games למחשב.

שיקולי אבטחה

כדי להפיק את הערך המרבי מ-Play Integrity API עבור האפליקציה, מומלץ לפעול לפי השיטות המומלצות הבאות:

יש לכם אסטרטגיה למניעת ניצול לרעה

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

איסוף טלמטריה והבנת הקהל לפני נקיטת פעולה

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

איך מבקשים קביעות תקינות

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

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

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

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

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

שליחת בקשה לקביעת תקינות ברגע המתאים

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

איך מקשים על שכפול בקשות API

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

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

הימנעות משמירת קביעות תקינות במטמון

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

אסטרטגיית אכיפה מדורגת

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

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

שליחת טווח של תגובות מהשרת לאפליקציה

קשה יותר לשכפל מגוון של תוצאות החלטה מאשר לשלוח תגובה בינארית של אישור או דחייה מהשרת בחזרה לאפליקציה לכל תגובה. לדוגמה, אפשר להשתמש בסדרה של תגובות קשורות כמו Allow (אישור), Allow with limits (אישור עם הגבלות), Allow with limits after CAPTCHA completion (אישור עם הגבלות אחרי השלמת CAPTCHA) ו-Deny (דחייה).

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

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

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

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

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

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

הצגת הודעות שגיאה עם אפשרות לביצוע פעולה

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

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

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

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

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

הצגת אתגר לתנועת גולשים מסוכנת כשניגשים לתכונות רגישות או לתכונות עם ערך גבוה

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

תנאים והגבלות ובטיחות נתונים

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

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