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

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

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

• גישה לא מורשית: פסק הדין accountDetails עוזר לכם לקבוע אם המשתמש התקין את האפליקציה או את המשחק או שילם עליהם ב-Google Play.
• שיבוש קוד: פסק הדין appIntegrity עוזר לכם לקבוע אם האינטראקציה מתבצעת עם הקוד הבינארי המקורי, כפי שמערכת Google Play מזהה אותו.
• מכשירים מסוכנים וסביבות מדומה: deviceIntegrity הקביעה עוזרת לכם לקבוע אם האפליקציה פועלת במכשיר Android מקורי ומאושר או במופע מקורי של 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 קלאסית
גרסת Android SDK מינימלית נדרשת*	‫Android 6.0 (רמת API‏ 23) ומעלה	‫Android 6.0 (רמת API‏ 23) ומעלה
נדרש חימום של ה-API	✔️ (כמה שניות)	❌
זמן האחזור האופייני של הבקשה	כמה מאות אלפיות שנייה	כמה שניות
תדירות פוטנציאלית של בקשות	תדירות גבוהה (בדיקה לפי דרישה של כל פעולה או בקשה)	לא תדיר (בדיקה חד-פעמית של פעולות עם הערך הגבוה ביותר או של בקשות רגישות במיוחד)
צמצום הסיכון להתקפות חוזרות ולהתקפות דומות	הפחתת הסיכון באופן אוטומטי על ידי Google Play	שימוש בשדה nonce עם לוגיקה בצד השרת

‫* בספריית Play Integrity API v1.4.0 ואילך, ערכת Android SDK המינימלית הנתמכת זהה לשני סוגי הבקשות, והיא נקבעת על ידי minSdkVersion של הספרייה. בגרסה v1.3.0 ובגרסאות קודמות, גרסת Android SDK המינימלית הנדרשת היא Android 5.0 (רמת API‏ 21) לבקשות API רגילות ו-Android 4.4 (רמת API‏ 19) לבקשות API קלאסיות.

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

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

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

הקשו על שכפול בקשות ה-API

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

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

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

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

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

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

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

• פרטי הבקשה: מוודאים שהערכים של requestDetails תואמים לערכים הצפויים, ובמיוחד מוודאים את הערכים של requestHash או nonce כדי למנוע מתקפות שידור חוזר.
• תקינות האפליקציה: בדיקה שהערך של appRecognitionVerdict הוא PLAY_RECOGNIZED, כדי לוודא שאישור החתימה של האפליקציה מזוהה על ידי Play ולא נעשה בו שינוי.
• פרטי החשבון: בודקים ש-appLicensingVerdict הוא LICENSED, כדי לוודא שהמשתמש התקין או עדכן את האפליקציה מ-Google Play.

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

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

• ‫MEETS_STRONG_INTEGRITY (Android 13 ואילך): רמת האמון הגבוהה ביותר במכשיר, שדורשת אותות אבטחה ברמת החומרה ותיקון אבטחה עדכני.
• ‫MEETS_DEVICE_INTEGRITY (Android 13 ומעלה) ו-MEETS_STRONG_INTEGRITY (גרסאות Android מלפני 13): רמת האמון הבאה. שניהם מסתמכים על אותות אבטחה שמגובים בחומרה.
• ‫MEETS_DEVICE_INTEGRITY (לפני Android 13): הרמה הבאה, שמשתמשת באימות שמגובה בחומרה כשהוא זמין, ובאימות שמגובה בתוכנה כגיבוי.
• ‫MEETS_BASIC_INTEGRITY: רמת האמון הכי נמוכה, ממש לפני שלא מתקבלות תוויות של מכשירים בכלל.

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

אחר כך תוכלו להוסיף אותות אחרים לאסטרטגיית האכיפה שלכם, כמו התייחסות למכשירים כאל מכשירים פחות מהימנים שמחזירים רמות גבוהות יותר בrecentDeviceActivity.

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

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

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

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