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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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