שכבת התעבורה של Android, יחד עם כל החיבור בין השרת, הקצה העורפי של FCM ומכשירי הלקוח, מאובטחת באמצעות Transport Layer Security (TLS). כך מתבצעת הצפנה חזקה מקצה לקצה של כל הנתונים בזמן ההעברה, כדי להגן עליהם מפני יירוט ברשת. מודל האבטחה החזק הזה מתאים לרוב האפליקציות. פרטים נוספים זמינים במסמכי התיעוד של ארכיטקטורת FCM.
אחת המגבלות של הצפנה מנקודה לנקודה היא שההודעה לא מוצפנת לכל אורך הנתיב שלה, ורק השולח והמקבל יכולים לפענח אותה. לכן, ב-FCM מומלץ להשתמש בהצפנה מקצה לקצה לתקשורת שרגישה לפרטיות, כמו הודעות צ'אט או עסקאות אימות. כדי להפיק את המקסימום מהצפנה מקצה לקצה, צריך להטמיע אותה ברמה גבוהה יותר, למשל בשרתים ובקוד של האפליקציה.
הוספת הצפנה מקצה לקצה למידע אישי רגיש
באפליקציות שמטפלות בנתונים רגישים במיוחד, כמו הודעות פרטיות או פרטי כניסה אישיים, אתם יכולים להוסיף שכבת הגנה נוספת באמצעות הצפנה מקצה לקצה (E2EE). התהליך כולל הצפנה של המטען הייעודי (payload) של ההודעה בשרת שלכם לפני שליחתה אל FCM, ופענוח שלה באפליקציה במכשיר של המשתמש. האפשרות הזו פועלת עם הודעות נתונים של FCM, כי מערכת ההפעלה מטפלת במטענים ייעודיים (payloads) רגילים של התראות, והאפליקציה לא יכולה לפענח אותם לפני שהם מוצגים.
חשוב לזכור ש-FCM לא מספק פתרון מובנה להצפנה מקצה לקצה. אתם אחראים להטמיע את שכבת האבטחה הזו באפליקציה שלכם. יש ספריות ופרוטוקולים חיצוניים שמיועדים למטרה הזו, כמו Capillary או DTLS.
דוגמה קונספטואלית
כך משתנה המטען הייעודי (payload) של FCM data כשמשתמשים ב-E2EE.
לפני ההצפנה (מטען ייעודי סטנדרטי):
{
"token": "DEVICE_REGISTRATION_TOKEN",
"data": {
"sender": "user123",
"message_body": "Your 2FA code is 555-123",
"timestamp": "1661299200"
}
}
אחרי ההצפנה (מטען ייעודי (payload) של E2EE):
{
"token": "DEVICE_REGISTRATION_TOKEN",
"data": {
"encrypted_payload": "aG9va2Vk...so much encrypted gibberish...ZW5jcnlwdA=="
}
}
אם הטמעתם את ההצפנה מקצה לקצה בצורה נכונה, אפליקציית הלקוח היא הגורם היחיד שיכול לפענח את המטען הייעודי (payload) המוצפן כדי לחשוף את ההודעה המקורית.
חלופה: שליפת תוכן ישירות מהשרת שלכם
אם הצפנה מקצה לקצה לא מתאימה לאפליקציה שלכם, אתם יכולים לשלוח הודעות נתונים ריקות. ההודעות האלה משמשות כאות לאפליקציה לאחזר את התוכן ישירות מהשרתים שלכם. כלומר, הנתונים הרגישים מועברים רק בין האפליקציה לשרתים שלכם, בלי לעבור דרך FCM.
החיסרון בשיטה הזו הוא העיכוב הפוטנציאלי שנגרם כשהאפליקציה מתחברת לשרת כדי לאחזר את הנתונים. כשאפליקציה מקבלת הודעת נתונים, בדרך כלל יש לה רק כמה שניות להציג התראה לפני שהיא עוברת לרקע. יכול להיות שאחזור הנתונים מהשרת לא יסתיים בפרק הזמן הזה. ההצלחה של אחזור הנתונים הזה תלויה בגורמים כמו הקישוריות של המכשיר של המשתמש.
לכן, כדאי לשקול חלופות לחוויית המשתמש במצבים שבהם אחזור הנתונים עלול להימשך זמן רב מדי. לדוגמה, אפשר להציג התראה כללית כמו "יש לך הודעה חדשה" ואז לעדכן אותה אחרי שהתוכן המלא מאוחזר.