שיטות עבודה מומלצות לאבטחת מערכת

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

אימות ביומטרי

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

• קבע את שיטת האימות הראשית לפני השימוש בכל צורה אחרת של אימות (כולל ביומטריה).
• דרוש אישור מפורש כדי לציין כוונה בעת שימוש באופנים ביומטריים פסיביים, כגון זיהוי פנים, עבור עסקאות (לדוגמה, תשלומים) הכוללות מפתחות הקשורים לאימות.
• דרוש את שיטת האימות הראשית כל 72 שעות.
• השתמש בצינור מאובטח לחלוטין עבור כל הנתונים הביומטריים והטיפול.
• לעולם אל תשלח נתונים ביומטריים (כולל מדידות חיישנים גולמיים ותכונות נגזרות) מחוץ למכשיר. במידת האפשר, שמור את הנתונים הללו בסביבה מבודדת מאובטחת, כגון סביבת ביצוע מהימנה (TEE) או Secure Element.

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

להנחיות ביומטריות נוספות, ראה הנחיות ליישום HAL ביומטרי .

SELinux

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

• יש ליישם מדיניות הפחות זכויות יתר.
• הימנע מהענקת הרשאות CAP_DAC_OVERRIDE , CAP_SYS_ADMIN ו- CAP_NET_ADMIN .
• אל תרשום נתוני מערכת לכרטיס ה-SD.
• השתמש בסוגים שסופקו לגישה לנהג, כגון gpu_device , audio_device וכו'.
• השתמש בשמות משמעותיים עבור תהליכים, קבצים וסוגי SELinux.
  • ודא שלא נעשה שימוש בתוויות ברירת מחדל ושלא ניתנת להם גישה.
• מדיניות ספציפית למכשיר צריכה להוות 5-10% מהמדיניות הכוללת הפועלת במכשיר. התאמות אישיות בטווח של 20%+ מכילות כמעט בוודאות דומיינים בעלי זכויות יתר ומדיניות מתה. מדיניות גדולה שלא לצורך מבזבזת זיכרון, מבזבזת שטח דיסק על ידי צורך בתמונת אתחול גדולה יותר, ומשפיעה לרעה על זמני בדיקת מדיניות בזמן ריצה.

טעינה דינמית של מדיניות SELinux

אל תטען באופן דינמי את מדיניות SELinux במכשירי אנדרואיד. פעולה זו עלולה לגרום לבעיות, כגון:

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

דלתות אחוריות

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

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

כלי פיתוח

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

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

הנה כמה הצעות נוספות שיש להתייחס אליהן בעת ​​יישום גילוי והסכמה:

חשיפה בתוך האפליקציה

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

בקשה להסכמה

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

פונקציונליות משובצת ב-AOSP

הטמעת פונקציונליות נוספת ב-AOSP עלולה לגרום לרוב להתנהגות והשלכות בלתי צפויות; להמשיך בזהירות.

• ודא שהמשתמש מקבל הנחיה אם הוא רוצה להשתמש ביישומי ברירת מחדל שונים (לדוגמה, מנוע חיפוש, דפדפן אינטרנט, משגר) ולחשוף שליחת נתונים מהמכשיר.
• ודא שחבילות APK של AOSP חתומות עם אישור AOSP.
• הפעל מבחני רגרסיה ושמור יומן שינויים כדי לקבוע אם נוספו קוד ל-AOSP APK.

עדכוני אבטחה

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

• עבוד עם שותפי חומרה, כגון ספקי ה-SoC שלך, כדי להקים הסכמי תמיכה מתאימים עבור כל הרכיבים במכשיר האנדרואיד שלך.
• ודא שניתן להתקין עדכוני אבטחה עם אינטראקציה מינימלית של המשתמש כדי להגדיל את הסבירות שמשתמשים יקבלו ויתקינו עדכונים במכשיר האנדרואיד שלהם. מומלץ מאוד ליישם עדכוני מערכת חלקים או תכונת אבטחה מקבילה.
• ודא שאתה מבין את הדרישה המצטברת של רמת תיקון האבטחה של Android (SPL) כפי שהוצהר בעלון האבטחה של Android . לדוגמה, מכשירים המשתמשים ברמת תיקון האבטחה של 2018-02-01 חייבים לכלול את כל הבעיות הקשורות לרמת תיקון האבטחה הזו, כמו גם תיקונים עבור כל הבעיות שדווחו בכל עלוני האבטחה הקודמים.

עדכוני ליבה דינמיים

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

ניהול מפתח

שמור על מדיניות ונהלים טובים לניהול מפתחות כדי להבטיח את האבטחה של חתימת מפתחות.

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

חתימה על תמונת מערכת

החתימה של תמונת המערכת היא קריטית לקביעת שלמות המכשיר.

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

מטעני אתחול בלתי ניתנים לנעילה

מכשירי אנדרואיד רבים תומכים בביטול נעילה, מה שמאפשר לבעל המכשיר לשנות את מחיצת המערכת או להתקין מערכת הפעלה מותאמת אישית. מקרי שימוש נפוצים כוללים התקנת תמונת מערכת של צד שלישי וביצוע פיתוח ברמת המערכת במכשיר. לדוגמה, כדי לבטל את נעילת תמונת המערכת ב-Google Nexus או Pixel, משתמש יכול להפעיל את fastboot oem unlock , המציג את ההודעה הזו:

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

• לאחר שהמשתמש מאשר את פקודת ביטול הנעילה, על המכשיר להתחיל מחיקת נתונים מיידית. אסור להגדיר את הדגל לא unlocked עד לאחר השלמת המחיקה המאובטחת.
• אם לא ניתן להשלים מחיקה מאובטחת, המכשיר חייב להישאר במצב נעול.
• אם נתמך על ידי התקן הבלוק הבסיסי, יש להשתמש ioctl(BLKSECDISCARD) או שווה ערך. עבור התקני MultiMediaCard (eMMC) משובצים, המשמעות היא שימוש בפקודה Secure Erase או Secure Trim. עבור eMMC 4.5 ואילך, משמעות הדבר היא שימוש במחיקה או חיתוך רגילה ולאחריה פעולת חיטוי.
• אם BLKSECDISCARD אינו נתמך על ידי התקן הבלוק הבסיסי, יש להשתמש ioctl(BLKDISCARD) במקום זאת. בהתקני eMMC, זוהי פעולת Trim רגילה.
• אם BLKDISCARD אינו נתמך, החלפת התקני החסימה עם כל האפסים מקובלת.
• למשתמש חייבת להיות אפשרות לדרוש מחיקת נתוני משתמש לפני הבהוב של מחיצה. לדוגמה, מכשירי Nexus משתמשים בפקודת fastboot oem lock כדי למחוק נתוני משתמש.
• מכשיר עשוי להקליט, באמצעות eFuses או מנגנון דומה, אם מכשיר נעול ו/או ננעל מחדש. עם זאת, אנו ממליצים בחום שנעילה מחדש של טוען האתחול עם איפוס להגדרות היצרן לאחר מכן אמורה לשחזר את הפונקציונליות המלאה של המכשיר.

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

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

בדיקת מכשיר

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

בדיקות אבטחה

השתמש בכלי בדיקת האבטחה המסופקים על ידי AOSP. באופן מיוחד

• השתמש בכלי בטיחות זיכרון במהלך הפיתוח: השתמש ב-MTE היכן שנתמך (ARMv9 ומעלה), וב- HWASan היכן שלא. הפעל כמה שיותר בדיקות כשהכלים האלה מופעלים.
• השתמש ב-GWP-ASan וב-KFENCE בייצור, לזיהוי הסתברותי של בעיות בטיחות בזיכרון.