שימוש ב-App Check כדי לאבטח את מפתח ה-API
Firebase App Check מספק הגנה על קריאות מהאפליקציה שלכם ל-Google Maps Platform, על ידי חסימת תעבורת נתונים שמגיעה ממקורות שאינם אפליקציות לגיטימיות. כדי לעשות את זה, הוא בודק אם יש טוקן מספק אישורים כמו Play Integrity. שילוב האפליקציות עם App Check עוזר להגן מפני בקשות זדוניות, כדי שלא תחויבו על קריאות לא מורשות ל-API.
האם App Check מתאים לי?
מומלץ להשתמש ב-App Check ברוב המקרים, אבל אין צורך ב-App Check או שאין תמיכה ב-App Check במקרים הבאים:
- אתם משתמשים ב-Places SDK המקורי. App Check נתמך רק ב-Places SDK (החדש).
- אפליקציות פרטיות או ניסיוניות. אם האפליקציה לא נגישה לכולם, אין צורך ב-App Check.
- אם האפליקציה שלכם משמשת רק לתקשורת בין שרתים, אין צורך ב-App Check. עם זאת, אם השרת שמתקשר עם GMP משמש לקוחות ציבוריים (כמו אפליקציות לנייד), כדאי להשתמש ב-App Check כדי להגן על השרת הזה במקום ב-GMP.
- ספקי האימות המומלצים של App Check לא יפעלו במכשירים שספק האימות שלכם קבע שהם לא מהימנים או שהאבטחה שלהם נפגעה. אם אתם צריכים לתמוך במכשירים כאלה, אתם יכולים לפרוס שירות אימות בהתאמה אישית. מידע נוסף זמין בהוראות.
סקירה כללית של שלבי ההטמעה
ככלל, אלה השלבים לשילוב האפליקציה עם App Check:
- מוסיפים את Firebase לאפליקציה.
- מוסיפים את ספריית App Check ומפעילים אותה.
- מוסיפים את ספק הטוקנים.
- מפעילים את ניפוי הבאגים.
- לעקוב אחרי הבקשות של האפליקציה ולהחליט על אכיפה.
אחרי שתשלבו את App Check, תוכלו לראות מדדי תנועה בקצה העורפי במסוף Firebase. המדדים האלה מספקים פירוט של הבקשות לפי השאלה אם הן מלוות באסימון App Check תקף. מידע נוסף זמין במאמרי העזרה של Firebase App Check.
אחרי שמוודאים שרוב הבקשות מגיעות ממקורות לגיטימיים ושהמשתמשים עדכנו את האפליקציה לגרסה העדכנית ביותר שכוללת את ההטמעה של App Check, אפשר להפעיל את האכיפה. אחרי שתפעילו את האכיפה, App Check ידחה את כל התנועה שלא כוללת אסימון App Check תקף.
שיקולים בתכנון שילוב של App Check
כמה דברים שכדאי להביא בחשבון כשמתכננים את השילוב:
לספק האימות שאנחנו ממליצים עליו, Play Integrity, יש מגבלת קריאות יומית ברמת השימוש הרגילה ב-API. מידע נוסף על מגבלות הקריאות זמין בדף הגדרה במאמרי העזרה למפתחים של Google Play Integrity.
אפשר גם להשתמש בספק אימות בהתאמה אישית, אבל זה תרחיש לדוגמה מתקדם. מידע נוסף זמין במאמר הטמעה של ספק App Check בהתאמה אישית.
-
המשתמשים באפליקציה יחוו זמן אחזור מסוים בזמן ההפעלה. עם זאת, לאחר מכן, כל אימות תקופתי יתרחש ברקע והמשתמשים לא אמורים לחוות יותר זמן אחזור. משך זמן האחזור המדויק בהפעלה תלוי בספק האימות שבחרתם.
משך הזמן שבו האסימון של App Check תקף (אורך החיים, או TTL) קובע את תדירות האימותים החוזרים. אפשר להגדיר את משך הזמן הזה במסוף Firebase. האימות מחדש מתרחש כשבערך חצי מה-TTL חלף. מידע נוסף זמין במסמכי התיעוד של Firebase לגבי ספק האימות שלכם.
שילוב האפליקציה עם App Check
דרישות מוקדמות ודרישות סף
- אפליקציה שמשולבת בה גרסה 4.1 ואילך של Places SDK.
- טביעת האצבע מסוג SHA-256 של האפליקציה.
- שם החבילה של האפליקציה.
- אתם צריכים להיות הבעלים של האפליקציה במסוף Cloud.
- צריך את מזהה הפרויקט של האפליקציה מ-Cloud Console
שלב 1: מוסיפים את Firebase לאפליקציה
פועלים לפי מאמרי העזרה למפתחים של Firebase כדי להוסיף את Firebase לאפליקציה.
שלב 2: מוסיפים את ספריית App Check ומפעילים את App Check
כדי לקבל מידע על השימוש ב-Play Integrity, ספק האימות שמוגדר כברירת מחדל, אפשר לעיין במאמר תחילת השימוש ב-App Check עם Play Integrity ב-Android.
- אם עדיין לא עשיתם זאת, שלבו את Places SDK באפליקציה.
לאחר מכן, מפעילים את App Check ואת לקוח Places.
// Initialize App Check FirebaseApp.initializeApp(/* context= */ this); FirebaseAppCheck firebaseAppCheck = FirebaseAppCheck.getInstance(); firebaseAppCheck.installAppCheckProviderFactory( PlayIntegrityAppCheckProviderFactory.getInstance()); // Initialize Places SDK Places.initializeWithNewPlacesApiEnabled(context, API_KEY); PlacesClient client = Places.createClient(context);.
שלב 3: מוסיפים את ספק הטוקנים
אחרי שמפעילים את Places API, שולחים קריאה ל-setPlacesAppCheckTokenProvider() כדי להגדיר את PlacesAppCheckTokenProvider.
Places.initializeWithNewPlacesApiEnabled(context, API_KEY); Places.setPlacesAppCheckTokenProvider(new TokenProvider()); PlacesClient client = Places.createClient(context);.
הנה דוגמה להטמעה של ממשק מאחזר הטוקנים:
/** Sample client implementation of App Check token fetcher interface. */ static class TokenProvider implements PlacesAppCheckTokenProvider { @Override public ListenableFuture<String> fetchAppCheckToken() { SettableFuture<String> future = SettableFuture.create(); FirebaseAppCheck.getInstance() .getAppCheckToken(false) .addOnSuccessListener( appCheckToken -> { future.set(appCheckToken.getToken()); }) .addOnFailureListener( ex -> { future.setException(ex); }); return future; } }
שלב 4: הפעלת ניפוי באגים (אופציונלי)
אם אתם רוצים לפתח ולבדוק את האפליקציה באופן מקומי, או להריץ אותה בסביבת שילוב רציף (CI), אתם יכולים ליצור גרסת build לניפוי באגים של האפליקציה שמשתמשת בסוד לניפוי באגים כדי לקבל אסימונים תקינים של App Check. כך אתם יכולים להימנע משימוש בספקי אימות אמיתיים בגרסת ה-build לניפוי באגים.
כדי להריץ את האפליקציה באמולטור או במכשיר בדיקה:
- מוסיפים את ספריית App Check לקובץ
build.gradle. - מגדירים את App Check כך שישתמש ב-factory של ספק אימות לצורכי ניפוי באגים בגרסת build לניפוי באגים.
- מפעילים את האפליקציה, והיא תיצור אסימון ניפוי באגים מקומי. מוסיפים את הטוקן הזה למסוף Firebase.
- מידע נוסף והוראות זמינים במסמכי התיעוד של App Check.
כדי להריץ את האפליקציה בסביבת CI:
- יוצרים אסימון ניפוי באגים במסוף Firebase ומוסיפים אותו למאגר המפתחות המאובטח של מערכת ה-CI.
- מוסיפים את ספריית App Check לקובץ
build.gradle. - מגדירים את וריאנט ה-build של ה-CI כך שישתמש בטוקן לניפוי באגים.
- עוטפים את הקוד במחלקות הבדיקה שצריכות אסימון App Check באמצעות
DebugAppCheckTestHelper. - מידע נוסף והוראות זמינים במסמכי התיעוד של App Check.
שלב 5: מעקב אחרי הבקשות לאפליקציות וקבלת החלטה לגבי אכיפה
לפני שמתחילים לאכוף את השימוש ב-App Check, חשוב לוודא שהאכיפה לא תפריע למשתמשים לגיטימיים באפליקציה. כדי לעשות את זה, נכנסים למסך המדדים של App Check ובודקים איזה אחוז מהתנועה באפליקציה מאומת, מיושן או לא לגיטימי. אחרי שמוודאים שרוב התנועה מאומתת, אפשר להפעיל את האכיפה.
מידע נוסף והוראות זמינים במסמכי התיעוד של Firebase App Check.