המלצות לגבי אבטחה לגיבויים

קטגוריה ב-OWASP: MASVS-CODE: איכות הקוד

סקירה כללית

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

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

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

השפעה

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

פעולות מיטיגציה

שימוש במערכת הגיבוי הרגילה של Android

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

באופן כללי, חשוב לפעול בהתאם להנחיות לאחסון נתונים ולהנחיות האבטחה.

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

לא כולל נתונים מהגיבוי

אפשר לציין אילו נתונים לא לכלול בגיבוי באמצעות קובץ כללים, שנקרא בדרך כלל backup_rules.xml וממוקם בתיקיית האפליקציה res/xml. יש הבדלים מסוימים באופן ההגדרה של כללי הגיבוי בהתאם לגרסת Android שבה משתמשים:

  • בגרסאות Android 12 (רמת API 31) ואילך, מוסיפים את המאפיין android:dataExtractionRules לרכיב <application> בתוך AndroidManifest.xml:
  • xml xml <application android:name="com.example.foo" android:dataExtractionRules="@xml/backup_rules_extraction"> … </application>

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

הפורמט שנדרש לתצורת הקובץ backup_rules.xml מאפשר למפתחים להגדיר כללי גיבוי מותאמים אישית גם ב-Cloud וגם להעברות ממכשיר למכשיר (D2D). אם המאפיין <device-transfer> לא מוגדר, כל נתוני האפליקציה יועברו במהלך העברה מ-D2D. חשוב לציין שגם אם אפליקציית היעד מטרגטת ל-Android 12 ואילך, תמיד צריך לציין קובץ נפרד עם קבוצה נוספת של כללי גיבוי למכשירים עם Android מגרסה 11 (רמת API‏ 30) ואילך.

  • בגרסאות Android 11 ומטה, מוסיפים מאפיין android:fullBackupContent לאלמנט <application> בתוך AndroidManifest.xml:
  • xml xml <application android:name="com.example.foo" android:fullBackupContent="@xml/backup_rules_full"> … </application>

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

דרישה להצפנה מקצה לקצה

אם אי אפשר להחריג נתונים רגישים מהגיבוי, מומלץ לדרוש הצפנה מקצה לקצה. כלומר, לאפשר גיבויים רק ב-Android מגרסה 9 ואילך, ורק כשמסך הנעילה מוגדר. אפשר לעשות זאת באמצעות הדגל requireFlags="clientSideEncryption", שצריך לשנות את שמו ל-disableIfNoEncryptionCapabilities ולהגדיר אותו ל-true החל מ-Android 12.

אם אין לכם אפשרות להשתמש במערכת הגיבוי הרגילה של Android

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

משאבים