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

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

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

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

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

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

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

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

SELinux

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

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

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

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

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

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

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

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

כלי פיתוח

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

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

ריכזנו כאן כמה הצעות נוספות שיעזרו לכם להטמיע את הגילוי הנאות וההסכמה:

גילוי נאות באפליקציה

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

בקשה לקבלת הסכמה

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

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

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

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

עדכוני אבטחה

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

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

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

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

ניהול מפתחות

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

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

חתימה על קובץ אימג' של מערכת

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

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

תוכנות אתחול שניתן לבטל את הנעילה שלהן

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

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

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

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

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

בדיקות חדירה למכשירים

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

בדיקות אבטחה

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

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