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

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

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

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

	בקשת API רגילה	בקשת API קלאסית
נדרשת גרסת Android SDK מינימלית	Android 5.0 (רמת API 21) ואילך	Android 4.4 (רמת API 19) ואילך
נדרש הכנה של API	✔️ (כמה שניות)	❌
זמן אחזור אופייני של בקשה	כמה מאות אלפיות שנייה	כמה שניות
תדירות הבקשה הפוטנציאלית	לעיתים קרובות (בדיקה על פי דרישה של כל פעולה או בקשה)	לעיתים רחוקות (בדיקה חד פעמית של הפעולות עם הערך הגבוה ביותר או רוב הבקשות הרגישות)
צמצום של ניסיון חוזר והתקפות דומות	צמצום אוטומטי של Google Play	שימוש בשדה nonce עם לוגיקה בצד השרת

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

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

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

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

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

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

זהירות: נתונים שבהם אתה משתמש בשדות requestHash ו-nonce גלויים בטקסט ללא הצפנה לאפליקציה ול-Google. עליך להצפין או לגבב את הנתונים לפני ההעברה ל-Play Integrity API.

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

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

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

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

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

טיפ: התווית MEETS_STRONG_INTEGRITY מציעה את העמידות הגבוהה ביותר נגד מתקפות ועקיפה, כי מכשירים שמחזירים את התווית הזו כוללים אחריות לתקינות, כגון בגיבוי חומרה הוכחה לתקינות האתחול. אבל, לפעמים פחות מכשירים מחזירים את התווית הזו בהשוואה לתווית MEETS_DEVICE_INTEGRITY לכן מומלץ להשתמש בהן כחלק מאסטרטגיית אכיפה מדורגת או בתרחישים ספציפיים שבהם אתם בטוחים שלמשתמשים שלכם יש מכשירים שמותקנת בהם גרסת Android 11 (רמת API 30) ומעלה שתוצג להם הודעת שגיאה תקינות.

שליחת מגוון תגובות מהשרת לאפליקציה שלכם

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

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

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

הצגת הודעות שגיאה פרקטיות

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

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

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

פתרונות להונאה מקצה לקצה בארגון

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

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

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

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

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

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