Play Integrity API עוזר לכם לוודא שהאינטראקציות ובקשות השרת מגיעות מהקובץ הבינארי האמיתי של האפליקציה שלכם שפועל במכשיר Android אמיתי. כשהמערכת מזהה אינטראקציות שעלולות להיות מסוכנות או כאלה שמקורן בתרמית, כמו גרסאות אפליקציה שהושחתו וסביבות לא מהימנות, השרת העורפי של האפליקציה יכול להגיב בהתאם כדי למנוע התקפות ולצמצם את הניצול לרעה.
כשמשתמשים באפליקציה או במשחק במכשיר Android עם חנות Google Play ומבוסס על Google Play Services, ה-Play Integrity API מספק תגובה שעוזרת לכם לקבוע אם אתם מבצעים אינטראקציה עם הגורמים הבאים:
- קוד בינארי מקורי של האפליקציה: מאפשר לכם לקבוע אם האינטראקציה מתבצעת עם הקוד הבינארי המקורי, כפי שמערכת Google Play מזהה אותו.
- התקנה מקורית מ-Play: אפשר לקבוע אם חשבון המשתמש הנוכחי ברישיון, כלומר אם המשתמש התקין את האפליקציה או את המשחק או שילם עליהם ב-Google Play.
- מכשיר Android מקורי: האפליקציה פועלת במכשיר Android מקורי שמבוסס על Google Play Services (או דרך שירות מקורי של Google Play Games במחשב).
אפשר גם לבחור לקבל מידע על הסביבה בתגובה מ-Play Integrity API, כולל:
- סיכון לגישה לאפליקציה: בודקים אם פועלות אפליקציות שיכולות לשמש להקלטת המסך, להצגת שכבות-על או לשליטה במכשיר.
- סיכון מתוכנות זדוניות ידועות: הסטטוס מציין אם Google Play Protect מופעל ואם התגלו במכשיר אפליקציות שרמת הסיכון שלהן נחשבת בינונית או גבוהה.
סקירה כללית
כשמשתמש מבצע פעולה באפליקציה, אפשר לקרוא ל-Play Integrity API כדי לוודא שהיא התרחשה בקוד הבינארי המקורי של האפליקציה, שהותקן על ידי Google Play ומופעל במכשיר Android מקורי. אפשר גם להביע הסכמה לקבלת מידע נוסף בתגובה, כולל נפח הבקשות שהמכשיר שלח לאחרונה וסימנים לגבי הסביבה, כולל תוצאת הבדיקה של סיכון הגישה לאפליקציה ותוצאת הבדיקה של Play Protect. אם יש בעיה בפסקי הדין, השרת העורפי של האפליקציה יכול להחליט מה לעשות כדי להגן על האפליקציה מפני בעיות כמו ניצול לרעה והונאה, שימוש לרעה ורמאות, גישה לא מורשית והתקפות.
שיקולי אבטחה
כדי להפיק את הערך המקסימלי מ-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 מגרסה 5.0 (רמת API 21) ואילך | Android 4.4 (API ברמה 19) ואילך |
| נדרש חימום של ה-API | ✔️ (כמה שניות) | ❌ |
| זמן האחזור של בקשה טיפוסי | כמה מאות אלפיות שנייה | כמה שניות |
| תדירות הבקשות הפוטנציאליות | תדירות גבוהה (בדיקה על פי דרישה של כל פעולה או בקשה) | לא תכופות (בדיקה חד-פעמית של הפעולות בעלות הערך הגבוה ביותר או של הבקשות הרגישות ביותר) |
| צמצום הסיכון להתקפות חוזרות והתקפות דומות | הפחתה אוטומטית על ידי Google Play | שימוש בשדה nonce עם לוגיקה בצד השרת |
טבלה עם הבדלים נוספים מופיעה בקטע שיקולים לגבי בקשות קלאסיות.
שליחת בקשה לקביעת תקינות בזמן המתאים
כדי למנוע מתחזים לעקוף את בדיקת תקינות האפליקציה, מומלץ לבקש את תוצאת הבדיקה של סיכוני הגישה לאפליקציה כמה שיותר קרוב למועד הפעולה או לבקשת השרת שרוצים להגן עליהם מפני גישה.
איך להקשות על העתקה של בקשות ה-API
לבקשות API רגילות יש שדה שנקרא requestHash, שמטרתו להגן מפני פגיעה והתקפות דומות. בשדה הזה צריך לכלול סיכום של כל הערכים הרלוונטיים מהבקשה של האפליקציה. כדי להגן על הבקשות הרגילות של האפליקציה, פועלים לפי ההוראות לשימוש בקישור תוכן.
לבקשות דרך Classic API יש שדה שנקרא nonce (קיצור של 'מספר חד-פעמי') שמשמשים להגנה מפני סוגים מסוימים של התקפות, כמו התקפות של השמעה חוזרת והתקפות של פגיעה. כדי להגן על הבקשות הקלאסיות של האפליקציה, פועלים לפי ההוראות ליצירת ערכים חד-פעמיים.
הימנעות משמירת קביעות תקינות במטמון
שמירת קביעות תקינות במטמון מגבירה את הסיכון לשימוש בשרת proxy. זוהי התקפה שבה גורם זדוני משתמש שוב בקביעת תקינות ממכשיר תקין למטרות זדוניות בסביבה אחרת. במקום לשמור תשובות במטמון, אפשר לשלוח בקשת API רגילה כדי לקבל את התוצאה על פי דרישה.
יש לכם אסטרטגיית אכיפה שכוללת רמות שונות
לתהליך קביעת התקינות של Play Integrity API יש מגוון תגובות אפשריות, מה שמאפשר לבנות אסטרטגיה למניעת ניצול לרעה עם כמה שכבות אכיפה. כדי לעשות זאת, מגדירים את שרת הקצה העורפי של האפליקציה לפעול באופן שונה בהתאם לכל תגובה אפשרית או קבוצת תגובות.
אפשר גם לחלק את אסטרטגיית האכיפה לפי רמת האמינות של המכשיר. לשם כך, צריך להביע הסכמה לקבלת תוויות מכשיר נוספות בתשובת ה-API מ-Play Console. כל מכשיר יחזיר את כל התוויות שעומדות בקריטריונים שלו. לדוגמה, אחרי שתבחרו לקבל את כל תוויות המכשיר, תוכלו לבחור לתת אמון במכשיר שמחזיר את הערכים MEETS_STRONG_INTEGRITY, MEETS_DEVICE_INTEGRITY ו-MEETS_BASIC_INTEGRITY יותר מאשר במכשיר שמחזיר רק את הערך MEETS_BASIC_INTEGRITY. אפשר להשיב מהשרת באופן שונה בכל תרחיש.
שליחת מגוון תגובות מהשרת לאפליקציה
קשה יותר לשכפל מגוון תוצאות של החלטות מאשר לשלוח תגובה בינארית של אישור/דחייה מהשרת חזרה לאפליקציה לכל תגובה. לדוגמה, אפשר להשתמש בסדרה של תגובות קשורות כמו 'אישור', 'אישור עם הגבלות', 'אישור עם הגבלות לאחר השלמת CAPTCHA' ו'דחייה'.
זיהוי ניצול לרעה בקנה מידה נרחב באמצעות פעילות במכשיר מהזמן האחרון
אתם יכולים להשתמש בתכונה פעילות במכשיר מהזמן האחרון ב-Play Integrity API כדי למצוא מכשירי שמבקשים מספר גדול של אסימוני תקינות. בדרך כלל, מתעללים עם נפח פעילות גבוה יוצרים תוצאות אימות תקינות ממכשירים אמיתיים ומספקים אותן לבוטים כדי לבצע באופן אוטומטי התקפות על מכשירים עם הרשאת root ועל מכונות וירטואליות. אתם יכולים להשתמש ברמת הפעילות במכשיר מהזמן האחרון כדי לבדוק כמה אימותים נוצרו על ידי האפליקציה במכשיר הזה בשעה האחרונה.
הצגת הודעות שגיאה עם פעולות שאפשר לבצע
כשהדבר אפשרי, כדאי להציג למשתמשים הודעות שגיאה מועילות ולהסביר להם מה אפשר לעשות כדי לתקן את הבעיה, למשל לנסות שוב, להפעיל את חיבור האינטרנט או לבדוק אם אפליקציית Play Store מעודכנת.
יש לכם תוכנית למקרה של בעיות או הפסקות זמניות בשירות לא צפויות
בלוח הבקרה של סטטוס Play מוצג מידע על סטטוס השירות של Play Integrity API, וגם מידע על שיבושים והפסקות זמניות בשירות. כדאי לתכנן מראש איך רוצים שהשרת העורפי יפעל במקרה הלא סביר של הפסקה זמנית בפעולת Play Integrity API בקנה מידה נרחב. שימו לב ששרת הקצה העורפי צריך להיות מוכן לפעול גם במקרה שבוטל מפתח אימות של מפתח פלטפורמה של Android שספציפי למכשירים.
כדאי לשקול פתרונות ארגוניים מקצה לקצה למניעת הונאות
לקוחות ארגוניים שמחפשים פתרון מלא לניהול תרמיות ובוטים יכולים לרכוש את 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.