แนวทางปฏิบัติแนะนำด้านความปลอดภัยของระบบ

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

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

ตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริก

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

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

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

ดูหลักเกณฑ์เพิ่มเติมเกี่ยวกับข้อมูลไบโอเมตริกได้ที่หลักเกณฑ์การใช้งาน HAL ข้อมูลไบโอเมตริก

SELinux

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 ทำให้เกิดลักษณะการทำงานและผลลัพธ์ที่ไม่คาดคิด ดังนั้นโปรดดำเนินการด้วยความระมัดระวัง

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

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

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

• ทำงานร่วมกับพาร์ทเนอร์ฮาร์ดแวร์ เช่น ผู้ให้บริการ SoC เพื่อจัดทำข้อตกลงการสนับสนุนที่เหมาะสมสำหรับคอมโพเนนต์ทั้งหมดในอุปกรณ์ Android
• ตรวจสอบว่าผู้ใช้สามารถติดตั้งการอัปเดตความปลอดภัยได้โดยที่ไม่ต้องโต้ตอบมากนัก เพื่อเพิ่มโอกาสที่ผู้ใช้จะยอมรับและติดตั้งการอัปเดตในอุปกรณ์ Android เราขอแนะนําอย่างยิ่งให้ใช้การอัปเดตระบบที่ราบรื่นหรือฟีเจอร์ด้านความปลอดภัยที่เทียบเท่า
• โปรดตรวจสอบว่าคุณเข้าใจข้อกำหนดแบบสะสมของระดับแพตช์ความปลอดภัย (SPL) ของ Android ตามที่ประกาศไว้ในกระดานข่าวสารความปลอดภัยของ Android ตัวอย่างเช่น อุปกรณ์ที่ใช้ระดับแพตช์ด้านความปลอดภัย 2018-02-01 ต้องมีทุกปัญหาที่เกี่ยวข้องกับระดับแพตช์ด้านความปลอดภัยนั้น รวมถึงการแก้ไขสำหรับทุกปัญหาที่รายงานในกระดานข่าวสารด้านความปลอดภัยฉบับก่อนหน้าทั้งหมด

การอัปเดตเคอร์เนลแบบไดนามิก

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

การจัดการคีย์

รักษานโยบายและแนวทางปฏิบัติด้านการจัดการคีย์ที่ดีเพื่อรักษาความปลอดภัยของคีย์การรับรอง

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

การลงนามอิมเมจระบบ

ลายเซ็นของอิมเมจระบบมีความสำคัญอย่างยิ่งต่อการพิจารณาความสมบูรณ์ของอุปกรณ์

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

Bootloader ที่ปลดล็อกได้

อุปกรณ์ Android จํานวนมากรองรับการปลดล็อก ซึ่งช่วยให้เจ้าของอุปกรณ์แก้ไขพาร์ติชันระบบหรือติดตั้งระบบปฏิบัติการที่กําหนดเองได้ กรณีการใช้งานทั่วไป ได้แก่ การติดตั้งอิมเมจระบบของบุคคลที่สามและการพัฒนาระดับระบบในอุปกรณ์ เช่น หากต้องการปลดล็อกรูปภาพของระบบใน Google Nexus หรือ Pixel ผู้ใช้สามารถเรียกใช้ fastboot oem unlock ซึ่งจะแสดงข้อความนี้

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

• หลังจากผู้ใช้ยืนยันคำสั่งปลดล็อกแล้ว อุปกรณ์ต้องเริ่มล้างข้อมูลทันที คุณต้องตั้งค่า Flag unlocked หลังจากการลบอย่างปลอดภัยเสร็จสมบูรณ์แล้ว
• หากการลบอย่างปลอดภัยไม่สำเร็จ อุปกรณ์จะต้องอยู่ในสถานะล็อก
• หากอุปกรณ์บล็อกที่รองรับ ควรใช้ ioctl(BLKSECDISCARD) หรือเทียบเท่า สำหรับอุปกรณ์ MultiMediaCard (eMMC) แบบฝัง การดำเนินการนี้หมายถึงการใช้คำสั่ง Secure Erase หรือ Secure Trim สำหรับ eMMC 4.5 ขึ้นไป การดำเนินการนี้หมายถึงการใช้การลบแบบปกติหรือการลบข้อมูลตามด้วยการดำเนินการล้างข้อมูล
• หากอุปกรณ์บล็อกพื้นฐานไม่รองรับ BLKSECDISCARD ต้องใช้ ioctl(BLKDISCARD) แทน ในอุปกรณ์ eMMC การดําเนินการนี้เป็นการดำเนินการ Trim ตามปกติ
• หากระบบไม่รองรับ BLKDISCARD คุณสามารถเขียนทับอุปกรณ์บล็อกด้วยค่า 0 ทั้งหมดได้
• ผู้ใช้ต้องมีตัวเลือกในการกำหนดให้ล้างข้อมูลผู้ใช้ก่อนแฟลชพาร์ติชัน เช่น อุปกรณ์ Nexus ใช้คำสั่ง fastboot oem lock เพื่อล้างข้อมูลผู้ใช้
• อุปกรณ์อาจบันทึกผ่าน eFuse หรือกลไกที่คล้ายกันว่าอุปกรณ์ถูกปลดล็อกและ/หรือล็อกอีกครั้งหรือไม่ อย่างไรก็ตาม เราขอแนะนำให้ล็อก Bootloader อีกครั้งแล้วรีเซ็ตเป็นค่าเริ่มต้น ซึ่งควรคืนค่าฟังก์ชันการทำงานของอุปกรณ์ให้สมบูรณ์

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

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

การทดสอบการเจาะช่องโหว่ของอุปกรณ์

อุปกรณ์ควรได้รับการตรวจสอบโดยผู้ทดสอบความปลอดภัยทางไซเบอร์ที่มีความเชี่ยวชาญก่อนการจัดส่ง การทดสอบการเจาะควรระบุว่าอุปกรณ์เป็นไปตามคำแนะนำด้านความปลอดภัยที่ระบุไว้ที่นี่ รวมถึงคำแนะนำด้านความปลอดภัยภายในของ OEM

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

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

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