แนวทางปฏิบัติที่ดีที่สุดของระบบความปลอดภัย

ส่วนนี้ประกอบด้วยคำแนะนำในการรับรองความปลอดภัยของระบบปฏิบัติการและอุปกรณ์ Android หลัก

การรับรองความถูกต้องทางชีวภาพ

รับ จัดเก็บ และประมวล ผลข้อมูลไบโอเมตริกซ์ เพื่อการตรวจสอบสิทธิ์ผู้ใช้อย่างระมัดระวัง คุณควร:

• กำหนดวิธีการรับรองความถูกต้องหลักก่อนที่จะใช้รูปแบบการรับรองความถูกต้องอื่น ๆ (รวมถึงไบโอเมตริกซ์)
• ต้องมีการยืนยันอย่างชัดเจนเพื่อระบุเจตนาเมื่อใช้รูปแบบไบโอเมตริกซ์แบบพาสซีฟ เช่น การจดจำใบหน้า สำหรับธุรกรรม (เช่น การชำระเงิน) ที่เกี่ยวข้องกับคีย์ที่ผูกกับการรับรองความถูกต้อง
• ต้องใช้วิธีการตรวจสอบสิทธิ์หลักทุก 72 ชั่วโมง
• ใช้ไปป์ไลน์ที่ปลอดภัยอย่างสมบูรณ์สำหรับข้อมูลไบโอเมตริกซ์และการจัดการทั้งหมด
• อย่าส่งข้อมูลไบโอเมตริกซ์ (รวมถึงการวัดเซ็นเซอร์ดิบและคุณสมบัติที่ได้รับ) นอกอุปกรณ์ หากเป็นไปได้ ให้เก็บข้อมูลนี้ไว้ในสภาพแวดล้อมแบบแยกที่ปลอดภัย เช่น Trusted Execution Environment (TEE) หรือ Secure Element

อุปกรณ์ที่มีข้อมูลไบโอเมตริกซ์ควรรองรับ BiometricPrompt API ซึ่งมีอินเทอร์เฟซทั่วไปและสอดคล้องกันสำหรับนักพัฒนาแอปเพื่อใช้ประโยชน์จากการตรวจสอบสิทธิ์โดยใช้ข้อมูลไบโอเมตริกซ์ในแอปของตน เฉพาะ ไบโอเมตริกซ์ที่แข็งแกร่ง เท่านั้นที่สามารถทำงานร่วมกับ BiometricPrompt ได้ และการผสานรวมจะต้องเป็นไปตามแนวทาง เอกสารคำจำกัดความความเข้ากันได้ของ Android (CDD)

สำหรับคำแนะนำด้านไบโอเมตริกซ์เพิ่มเติม โปรดดู คำแนะนำในการใช้งาน Biometric HAL

ซีลีนุกซ์

SELinux ให้คำจำกัดความและการบังคับใช้โมเดลความปลอดภัยของ Android ส่วนใหญ่ การใช้ SELinux อย่างถูกต้องมีความสำคัญอย่างยิ่งต่อความปลอดภัยของอุปกรณ์ Android และสามารถช่วยบรรเทาผลกระทบจากช่องโหว่ด้านความปลอดภัยได้ อุปกรณ์ Android ทั้งหมดควรใช้ นโยบาย SELinux ที่มีประสิทธิภาพ ด้วยเหตุผลนี้

• ใช้นโยบายสิทธิ์ขั้นต่ำ
• หลีกเลี่ยงการให้สิทธิ์ CAP_DAC_OVERRIDE , CAP_SYS_ADMIN และ CAP_NET_ADMIN
• อย่าบันทึกข้อมูลระบบลงในการ์ด SD
• ใช้ประเภทที่ให้มาสำหรับการเข้าถึงไดรเวอร์ เช่น gpu_device , audio_device ฯลฯ
• ใช้ชื่อที่มีความหมายสำหรับกระบวนการ ไฟล์ และประเภท SELinux
  • ตรวจสอบให้แน่ใจว่าไม่ได้ใช้ป้ายกำกับเริ่มต้นและไม่ได้รับอนุญาตให้เข้าถึง
• นโยบายเฉพาะอุปกรณ์ควรคิดเป็น 5-10% ของนโยบายโดยรวมที่ทำงานบนอุปกรณ์ การปรับแต่งในช่วง 20%+ เกือบจะมีโดเมนที่มีสิทธิ์การใช้งานมากเกินไปและนโยบายที่ไม่ทำงาน นโยบายขนาดใหญ่โดยไม่จำเป็นจะทำให้หน่วยความจำเปลือง เปลืองเนื้อที่ดิสก์โดยต้องใช้อิมเมจสำหรับบูตที่ใหญ่กว่า และส่งผลเสียต่อเวลาในการค้นหานโยบายรันไทม์

การโหลดนโยบาย SELinux แบบไดนามิก

อย่าโหลดนโยบาย SELinux แบบไดนามิกบนอุปกรณ์ Android การทำเช่นนี้อาจส่งผลให้เกิดปัญหาต่างๆ เช่น:

• ป้องกันการยอมรับแพตช์รักษาความปลอดภัยที่สำคัญ
• การเปิดเผยความสามารถในการรูทอุปกรณ์ผ่านการโหลดนโยบายซ้ำ
• การเปิดเผยเวกเตอร์สำหรับการโจมตีแบบแทรกกลางกับผู้อัปเดตนโยบาย
• ส่งผลให้อุปกรณ์ติดขัดเนื่องจากข้อผิดพลาดในการอัปเดตนโยบาย

แบ็คดอร์

แอป Android ไม่ควรมีแบ็คดอร์หรือวิธีเข้าถึงระบบหรือข้อมูลที่เลี่ยงผ่านกลไกความปลอดภัยปกติ ซึ่งรวมถึงการวินิจฉัย การแก้ไขจุดบกพร่อง การพัฒนา หรือการซ่อมแซมการรับประกัน การเข้าถึงพิเศษที่ควบคุมโดยความลับที่นักพัฒนาทราบ เพื่อป้องกันแบ็คดอร์:

• สแกนแอปของบุคคลที่สามทั้งหมดโดยใช้เครื่องมือสแกนช่องโหว่ของแอปที่เป็นที่ยอมรับในอุตสาหกรรม
• ดำเนินการตรวจสอบโค้ดของโค้ดทั้งหมดที่มีการเข้าถึงที่ละเอียดอ่อน รวมถึงไลบรารีของบุคคลที่สาม
• ใช้ Google Play Protect โดยการอัปโหลดแอปไปยัง Google Play เพื่อทำการสแกน คุณสามารถอัปโหลดแอปสำหรับการสแกนโดยไม่ต้องเผยแพร่ไปยัง Google Play
• อย่าโหลดเครื่องมือวินิจฉัยหรือซ่อมแซมล่วงหน้าในรุ่นรีลีส ติดตั้งเครื่องมือเหล่านี้ตามความต้องการเพื่อแก้ไขปัญหาเฉพาะเท่านั้น นอกจากนี้ เครื่องมือเหล่านี้จะต้องไม่ดำเนินการหรืออัปโหลดข้อมูลเฉพาะบัญชีใดๆ

เครื่องมือในการพัฒนา

เครื่องมือการพัฒนา เช่น เครื่องมือแก้ไขจุดบกพร่อง การทดสอบ และการวินิจฉัย มักจะสร้างช่องว่างด้านความปลอดภัยโดยไม่ได้ตั้งใจบนอุปกรณ์ของคุณโดยการเปิดเผยวิธีการทำงานของเครื่องมือและข้อมูลที่รวบรวม เพื่อให้แน่ใจว่าเครื่องมือการพัฒนาไม่รวมอยู่ในรุ่นที่ใช้งานจริง:

• พัฒนาบัญชีดำของแฮชของเครื่องมือแก้ไขและทดสอบภายในองค์กร และสแกนบิลด์สำหรับ APK เหล่านี้ก่อนที่จะใช้อิมเมจระบบ
• สแกนแอปบุคคลที่หนึ่งทั้งหมดโดยใช้เครื่องมือสแกนช่องโหว่ของแอปที่เป็นที่ยอมรับในอุตสาหกรรม
• จ้างบริษัททดสอบความปลอดภัยของแอปจากภายนอกเพื่อประเมินแอปวินิจฉัยที่สำคัญในอุปกรณ์ทั้งหมดก่อนการอัปเดตครั้งใหญ่ โดยเฉพาะอย่างยิ่งหากแอปได้รับการพัฒนาโดยบุคคลที่สาม
• ตรวจสอบให้แน่ใจว่ามีเพียงผู้ใช้เท่านั้นที่สามารถเปิดใช้งานเครื่องมือได้ทั้งทางวาจาหรือผ่านการแชทในระหว่างเซสชั่นการสนับสนุน จัดเก็บสิ่งประดิษฐ์ของการยินยอมและปิดการใช้งานเครื่องมือหลังจากรวบรวมข้อมูลการวินิจฉัยที่จำเป็น
• เก็บบันทึกการใช้งานของเครื่องมือนี้ไว้ในบันทึกที่ผู้ใช้เข้าถึงได้ในบัญชีผู้ให้บริการของตน
• ตรวจสอบให้แน่ใจว่าข้อมูลส่วนบุคคลที่สามารถระบุตัวตนได้ (PII) หรือข้อมูลการวัดและส่งข้อมูลทางไกลของอุปกรณ์ที่รวบรวมโดยเครื่องมือนั้นอยู่ภายใต้แนวทางปฏิบัติในการไม่เปิดเผยตัวตน การเก็บรักษา และการลบที่เกี่ยวข้องกับประเทศ ควรรวบรวมเฉพาะข้อมูลที่เกี่ยวข้องกับการโทรสนับสนุนเท่านั้น ข้อมูลนี้ควรถูกลบหลังการโทรแต่ละครั้ง
• ตรวจสอบให้แน่ใจว่าเทคนิคที่สามารถใช้สำหรับสปายแวร์ เช่น การบันทึกการกดแป้นพิมพ์ การใช้ไมโครโฟน หรือการใช้กล้อง จะไม่ถูกใช้โดยไม่ได้รับความยินยอมจากผู้ใช้อย่างชัดแจ้ง แอปที่ใช้วิธีการที่อาจรุกล้ำความเป็นส่วนตัวเหล่านี้ควรได้รับการเปิดเผยอย่างชัดเจนพร้อมกับนโยบายความเป็นส่วนตัวที่ผู้ใช้ต้องยินยอม ไม่ควรเปิดใช้งานแอปประเภทนี้โดยไม่ได้รับความยินยอมอย่างชัดแจ้งจากผู้ใช้

คำแนะนำเพิ่มเติมบางประการที่ควรอ้างอิงเมื่อดำเนินการเปิดเผยข้อมูลและความยินยอม:

การเปิดเผยในแอป

• แสดงการใช้งานปกติของแอปโดยตรงในแอป ไม่ต้องการให้ผู้ใช้นำทางไปยังเมนูหรือการตั้งค่า
• อธิบายประเภทของข้อมูลที่ถูกรวบรวมและอธิบายว่าข้อมูลจะถูกนำไปใช้อย่างไร
• ตามหลักการแล้ว อย่าฝังข้อมูลนี้ไว้ในนโยบายความเป็นส่วนตัวหรือข้อกำหนดในการให้บริการ อย่ารวมไว้กับการเปิดเผยอื่น ๆ ที่ไม่เกี่ยวข้องกับการเก็บรวบรวมข้อมูลส่วนบุคคลหรือข้อมูลที่ละเอียดอ่อน

ขอความยินยอม

• ความยินยอมจะต้องได้รับการยืนยัน อย่าถือว่าการออกจากการเปิดเผยข้อมูล รวมถึงการแตะออกหรือกดปุ่มย้อนกลับหรือปุ่มโฮมเป็นการยินยอม
• นำเสนอกล่องโต้ตอบการยินยอมในลักษณะที่ชัดเจนและไม่คลุมเครือ
• กำหนดให้ผู้ใช้ต้องดำเนินการยืนยัน เช่น แตะเพื่อยอมรับหรือพูดคำสั่งเพื่อยอมรับ
• อย่าเก็บรวบรวมข้อมูลส่วนบุคคลหรือข้อมูลที่ละเอียดอ่อนก่อนที่จะได้รับความยินยอมโดยยืนยัน
• อย่าใช้ข้อความปิดอัตโนมัติหรือข้อความที่หมดอายุ

ฟังก์ชันการทำงานแบบฝังใน AOSP

การฝังฟังก์ชันเพิ่มเติมใน AOSP มักมีพฤติกรรมและผลที่ตามมาที่ไม่คาดคิด ดำเนินการด้วยความระมัดระวัง

• ตรวจสอบให้แน่ใจว่าผู้ใช้ได้รับแจ้งหากต้องการใช้แอปเริ่มต้นอื่น (เช่น เครื่องมือค้นหา เว็บเบราว์เซอร์ ตัวเรียกใช้งาน) และเปิดเผยการส่งข้อมูลออกจากอุปกรณ์
• ตรวจสอบให้แน่ใจว่า AOSP APK ลงนามด้วยใบรับรอง AOSP
• เรียกใช้การทดสอบการถดถอยและเก็บบันทึกการเปลี่ยนแปลงเพื่อพิจารณาว่า AOSP APK มีการเพิ่มโค้ดหรือไม่

การอัปเดตความปลอดภัย

อุปกรณ์ Android ควรได้รับการสนับสนุนด้านความปลอดภัยอย่างต่อเนื่องเป็นเวลาอย่างน้อยสองปีนับจากเปิดตัว ซึ่งรวมถึงการได้รับการอัปเดตเป็นประจำเพื่อแก้ไขจุดอ่อนด้านความปลอดภัยที่ทราบ

• ทำงานร่วมกับพันธมิตรด้านฮาร์ดแวร์ เช่น ผู้จำหน่าย SoC ของคุณ เพื่อจัดทำข้อตกลงการสนับสนุนที่เหมาะสมสำหรับส่วนประกอบทั้งหมดบนอุปกรณ์ Android ของคุณ
• ตรวจสอบให้แน่ใจว่าสามารถติดตั้งการอัปเดตความปลอดภัยโดยมีการโต้ตอบกับผู้ใช้น้อยที่สุดเพื่อเพิ่มโอกาสที่ผู้ใช้จะยอมรับและติดตั้งการอัปเดตบนอุปกรณ์ Android ของตน ขอแนะนำอย่างยิ่งให้ใช้การ อัปเดตระบบที่ราบรื่น หรือคุณลักษณะความปลอดภัยที่เทียบเท่า
• ตรวจสอบให้แน่ใจว่าคุณเข้าใจข้อกำหนดสะสมของ Android Security Patch Level (SPL) ตามที่ประกาศไว้ใน Android Security Bulletin ตัวอย่างเช่น อุปกรณ์ที่ใช้ระดับแพตช์รักษาความปลอดภัย 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 และใหม่กว่า หมายถึงการใช้การลบหรือตัดแต่งตามปกติตามด้วยการดำเนินการฆ่าเชื้อ
• หากอุปกรณ์บล็อกพื้นฐานไม่รองรับ BLKSECDISCARD จะต้องใช้ ioctl(BLKDISCARD) แทน บนอุปกรณ์ eMMC นี่เป็นการดำเนินการตัดแต่งตามปกติ
• หากไม่รองรับ BLKDISCARD การเขียนทับอุปกรณ์บล็อกด้วยเลขศูนย์ทั้งหมดก็เป็นที่ยอมรับ
• ผู้ใช้ต้องมีตัวเลือกในการกำหนดให้ล้างข้อมูลผู้ใช้ก่อนทำการแฟลชพาร์ติชัน ตัวอย่างเช่น อุปกรณ์ Nexus จะใช้คำสั่ง fastboot oem lock เพื่อล้างข้อมูลผู้ใช้
• อุปกรณ์อาจบันทึกผ่าน eFuses หรือกลไกที่คล้ายกัน ไม่ว่าอุปกรณ์จะถูกปลดล็อคและ/หรือล็อคซ้ำก็ตาม อย่างไรก็ตาม เราขอแนะนำอย่างยิ่งว่าการรีล็อกบูตโหลดเดอร์ด้วยการรีเซ็ตเป็นค่าเริ่มต้นจากโรงงานควรคืนค่าฟังก์ชันการทำงานของอุปกรณ์ทั้งหมด

ข้อกำหนดเหล่านี้ช่วยให้แน่ใจว่าข้อมูลทั้งหมดจะถูกทำลายเมื่อการดำเนินการปลดล็อคเสร็จสิ้น ความล้มเหลวในการดำเนินการป้องกันเหล่านี้ถือเป็น ช่องโหว่ด้านความปลอดภัยระดับปานกลาง

อุปกรณ์ที่ถูกปลดล็อคอาจถูกล็อคซ้ำในภายหลังโดยใช้คำสั่ง fastboot oem lock การล็อคบูตโหลดเดอร์จะให้การปกป้องข้อมูลผู้ใช้ด้วยระบบปฏิบัติการแบบกำหนดเองใหม่ เช่นเดียวกับที่มีในระบบปฏิบัติการของผู้ผลิตอุปกรณ์ดั้งเดิม (เช่น ข้อมูลผู้ใช้จะถูกล้างหากอุปกรณ์ถูกปลดล็อคอีกครั้ง)

การทดสอบอุปกรณ์

อุปกรณ์ควรได้รับการตรวจสอบโดยเพนเทสเตอร์ที่มีความสามารถก่อนจัดส่ง Pentesting ควรกำหนดว่าอุปกรณ์ปฏิบัติตามคำแนะนำด้านความปลอดภัยที่ให้ไว้ที่นี่ รวมถึงคำแนะนำด้านความปลอดภัยภายในของ OEM

การทดสอบความปลอดภัย

ใช้เครื่องมือ ทดสอบความปลอดภัย ที่ AOSP จัดให้ โดยเฉพาะอย่างยิ่ง

• ใช้ เครื่องมือความปลอดภัยของหน่วยความจำ ในระหว่างการพัฒนา: ใช้ MTE ในกรณีที่รองรับ (ARMv9 ขึ้นไป) และใช้ HWASan ในกรณีที่ไม่รองรับ ทำการทดสอบให้มากที่สุดเท่าที่จะเป็นไปได้โดยเปิดใช้งานเครื่องมือเหล่านี้
• ใช้ GWP-ASan และ KFENCE ในการผลิตเพื่อการตรวจจับปัญหาด้านความปลอดภัยของหน่วยความจำที่น่าจะเป็นไปได้