คู่มือสำหรับผู้ผลิตเกี่ยวกับความปลอดภัยของ Android ในระยะยาว

คู่มือนี้อธิบายแนวทางปฏิบัติแนะนำที่ Google แนะนำสำหรับการใช้แพตช์ความปลอดภัยที่ ประเมินโดยชุดเครื่องมือทดสอบความเข้ากันได้ (CTS) ของ Android โดยมีไว้สำหรับผู้ผลิต อุปกรณ์ OEM ที่ใช้ร่วมกับ Android ได้ (ผู้ผลิต) ซึ่งจะได้รับการสนับสนุนนานกว่า 3 ปี เช่น ยานพาหนะ ทีวี กล่องรับสัญญาณ และเครื่องใช้ในบ้าน คู่มือนี้ไม่ได้ มีไว้สำหรับผู้ใช้ปลายทาง (เช่น เจ้าของยานพาหนะ)

การรับทราบและข้อจำกัดความรับผิด

คู่มือนี้ไม่ได้ผูกมัด Google หรือผู้ผลิตรายอื่นๆ ตามกฎหมายหรือสัญญา และไม่ได้มีวัตถุประสงค์เพื่อเป็นชุดข้อกำหนด แต่คู่มือนี้เป็นเครื่องมือช่วยสอนที่อธิบายแนวทางปฏิบัติที่แนะนำ

ความคิดเห็น

คู่มือนี้ไม่ได้มีไว้เพื่อเป็นข้อมูลที่ครอบคลุมทั้งหมด แต่เราวางแผนที่จะแก้ไขเพิ่มเติม ส่งความคิดเห็น ไปที่ manufacturers-guide-android@googlegroups.com

อภิธานศัพท์

คำศัพท์ คำจำกัดความ
ACC ความมุ่งมั่นด้านความเข้ากันได้กับ Android เดิมเรียกว่าข้อตกลงต่อต้านการแยกส่วนของ Android (Android Anti-Fragmentation Agreement หรือ AFA)
AOSP โครงการโอเพนซอร์ส Android
ASB กระดานข่าวสารเกี่ยวกับความปลอดภัยของ Android
BSP แพ็กเกจการสนับสนุนบอร์ด
CDD เอกสารนิยามความเข้ากันได้
CTS ชุดเครื่องมือทดสอบความเข้ากันได้
FOTA เฟิร์มแวร์ผ่านอากาศ
GPS ระบบดาวเทียมนำร่อง
MISRA Motor Industry Software Reliability Association
NIST สถาบันมาตรฐานและเทคโนโลยีแห่งชาติ
OBD การวินิจฉัยบนบอร์ด (OBD-II เป็นการปรับปรุง OBD-I ทั้งในด้านความสามารถและ การสร้างมาตรฐาน)
OEM ผู้ผลิตอุปกรณ์ดั้งเดิม
ระบบปฏิบัติการ ระบบปฏิบัติการ
SEI Software Engineering Institute
SoC ระบบวงจรรวมบนชิป
SOP เริ่มการผลิต
SPL ระดับแพตช์ความปลอดภัย
TPMS ระบบตรวจวัดลมยาง

เกี่ยวกับระบบปฏิบัติการ Android

Android เป็นสแต็กซอฟต์แวร์แบบเต็มที่ใช้ Linux และเป็นโอเพนซอร์ส ซึ่งออกแบบมาสำหรับอุปกรณ์และรูปแบบของอุปกรณ์ที่หลากหลาย นับตั้งแต่เปิดตัวครั้งแรกในปี 2008 Android ได้กลายเป็นระบบปฏิบัติการ (OS) ที่ได้รับความนิยมมากที่สุด โดยขับเคลื่อนอุปกรณ์กว่า 1.4 พันล้านเครื่องทั่วโลก (2016) ประมาณ 67% ของอุปกรณ์เหล่านั้นใช้ Android 5.0 (Lollipop) ขึ้นไป ณ เดือนมีนาคม 2017 (ดูตัวเลขล่าสุดได้ในแดชบอร์ด Android) แม้ว่าอุปกรณ์ส่วนใหญ่จะเป็นโทรศัพท์มือถือและแท็บเล็ต แต่ Android ก็ เติบโตในสมาร์ทวอทช์ ทีวี และอุปกรณ์สาระบันเทิงในรถยนต์ (IVI)

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

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

เกี่ยวกับยานพาหนะที่เชื่อมต่อ (ผลิตภัณฑ์ที่ใช้งานได้นานตามมาตรฐาน)

ยานพาหนะเริ่มเชื่อมต่อเมื่อมีการเปิดตัววิทยุ AM ในช่วงทศวรรษ 1920 จากนั้น จำนวนการเชื่อมต่อแบบไร้สายและแบบมีสายภายนอกก็เริ่มเพิ่มขึ้น เนื่องจากหน่วยงานกำกับดูแลและ ผู้ผลิตรถยนต์หันมาใช้อุปกรณ์อิเล็กทรอนิกส์เพื่ออำนวยความสะดวกในการวินิจฉัยและบริการ (เช่น พอร์ต OBD-II) ปรับปรุง ความปลอดภัย (เช่น TPMS) และบรรลุเป้าหมายด้านการประหยัดน้ำมัน การเชื่อมต่อในยุคถัดมา ได้เปิดตัวฟีเจอร์อำนวยความสะดวกแก่ผู้ขับ เช่น ระบบรีโมตแบบไม่ใช้กุญแจ ระบบเทเลเมติกส์ และ ฟีเจอร์สาระบันเทิงขั้นสูง เช่น บลูทูธ, Wi-Fi และการฉายภาพจากสมาร์ทโฟน ปัจจุบัน เซ็นเซอร์และการเชื่อมต่อแบบผสานรวม (เช่น GPS) รองรับระบบความปลอดภัยและการขับขี่กึ่งอัตโนมัติ

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

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

รับประกันความปลอดภัยในระยะยาว

ยานพาหนะที่เชื่อมต่อมักจะมีหน่วยควบคุมอิเล็กทรอนิกส์ (ECU) อย่างน้อย 1 หน่วย ซึ่งประกอบด้วย คอมโพเนนต์ซอฟต์แวร์หลายรายการ เช่น ระบบปฏิบัติการ ไลบรารี ยูทิลิตี ฯลฯ ผู้ผลิตควรติดตาม คอมโพเนนต์ดังกล่าวและระบุช่องโหว่ที่ทราบแล้วซึ่งเผยแพร่ด้วยการวิเคราะห์เชิงรุก ซึ่งรวมถึง

  • ประเมินผลิตภัณฑ์เทียบกับฐานข้อมูล Common Vulnerabilities and Exposures (CVE) เป็นประจำ
  • การรวบรวมข้อมูลเกี่ยวกับข้อบกพร่องด้านความปลอดภัยที่เกี่ยวข้องกับผลิตภัณฑ์
  • การทดสอบความปลอดภัย
  • วิเคราะห์กระสุนด้านความปลอดภัยของ Android อย่างต่อเนื่อง

ตัวอย่างการอัปเดตแพตช์ระบบปฏิบัติการและความปลอดภัย (IVI ที่ใช้ Android)

รูปที่ 1 ตัวอย่างการเปิดตัวการอัปเดตระบบปฏิบัติการและการอัปเดตความปลอดภัยที่สำคัญตลอดอายุการใช้งานของยานพาหนะ

# ขั้นตอน กิจกรรม

①

 ฝ่ายพัฒนา ผู้ผลิตเลือก Android เวอร์ชันหนึ่ง (Android X) ในตัวอย่างนี้ "Android X" จะกลายเป็นพื้นฐานของสิ่งที่ติดตั้งในรถยนต์ 2 ปีก่อนเริ่มการผลิต (SOP) ครั้งแรก
② การเปิดตัวครั้งแรก ในอีกไม่กี่เดือนก่อนที่ Android X จะกลายเป็นเวอร์ชันระบบปฏิบัติการแรกที่จัดส่งในผลิตภัณฑ์ ระบบจะนำข้อมูลอัปเดตด้านความปลอดภัยจากประกาศข่าวสารด้านความปลอดภัยของ Android (ASB) และอาจนำมาจากแหล่งข้อมูลอื่นๆ ที่ผู้ผลิตเห็นว่ามีประโยชน์ y2 = ประกาศข่าวสารด้านความปลอดภัยฉบับที่ 2 สำหรับ Android เวอร์ชัน X ซึ่งผู้ผลิตนำไปใช้ (ย้อนกลับ) กับ Android X การอัปเดตนี้จะมาพร้อมกับผลิตภัณฑ์ และ นาฬิกาการผลิตจะเริ่มนับที่ปีที่ 0 ด้วย Android X.y2

ในตัวอย่างนี้ ผู้ผลิตตัดสินใจไม่จัดส่ง Android X+1 เวอร์ชันล่าสุดประจำปี เหตุผลที่ต้องจัดส่งรุ่นล่าสุด รวมถึงการเพิ่มฟีเจอร์ใหม่ การแก้ไขช่องโหว่ด้านความปลอดภัยใหม่ และ/หรือการจัดส่ง บริการของ Google หรือบุคคลที่สามที่ต้องใช้ Android เวอร์ชันใหม่กว่า เหตุผลที่ไม่อนุญาต ให้จัดส่งพร้อมกับรุ่นล่าสุดคือการขาดเวลาในการพัฒนาและเปิดตัวยานพาหนะ ซึ่งจำเป็นต่อการผสานรวม ทดสอบ และตรวจสอบการเปลี่ยนแปลง รวมถึง การปฏิบัติตามข้อกำหนดด้านกฎระเบียบและการรับรองทั้งหมด
③ การอัปเดตระบบปฏิบัติการแบบเต็ม หลัง SOP ผู้ผลิตจะเผยแพร่การอัปเดตระบบปฏิบัติการ Android X+2 ซึ่งเป็นการเผยแพร่ Android 2 ครั้ง หลังจากเวอร์ชันที่ใช้สำหรับผลิตภัณฑ์เริ่มต้น (Android X0) มีการอัปเดตความปลอดภัยของ ASB สำหรับระดับ API (ณ วันที่จัดส่ง) ดังนั้นการอัปเดตจึงเป็น X+2.y0 โดยประมาณ 1.25 ปีหลังจาก SOP การอัปเดตระบบปฏิบัติการนี้อาจใช้งานร่วมกับผลิตภัณฑ์ที่ใช้งานจริงได้หรือไม่ก็ได้ หากเป็นเช่นนั้น คุณจะสร้างแผนเพื่ออัปเดตรถที่ใช้งานอยู่ได้

เว้นแต่จะมีข้อตกลงทางธุรกิจอื่นๆ การตัดสินใจที่จะอัปเดตระบบปฏิบัติการแบบเต็มจะขึ้นอยู่กับดุลยพินิจของ ผู้ผลิตโดยสมบูรณ์
④ การอัปเดตความปลอดภัย เมื่อรถยนต์มีอายุการใช้งาน 2 ปี ผู้ผลิตจะแก้ไขข้อบกพร่องของระบบปฏิบัติการ Android X+2 การตัดสินใจนี้อิงตามการประเมินความเสี่ยงของผู้ผลิต ผู้ผลิต เลือกการอัปเดตความปลอดภัย ASB รายการที่ 3 สำหรับรุ่น X+2 เป็นพื้นฐานของการอัปเดต ผลิตภัณฑ์ ที่ได้รับการอัปเดตความปลอดภัยจะใช้ระบบปฏิบัติการ (X+2.y3) + ระดับแพตช์ด้านความปลอดภัยของ Android

แม้ว่าผู้ผลิตจะเลือกแพตช์ความปลอดภัยแต่ละรายการจาก ASB แต่ละฉบับได้ แต่ก็ต้องแก้ไขปัญหาที่จำเป็นทั้งหมดในประกาศข่าวสารเพื่อใช้ระดับแพตช์ความปลอดภัยของ Android (SPL) ที่เชื่อมโยงกับประกาศข่าวสาร (เช่น 2017-02-05) ผู้ผลิตมีหน้าที่รับผิดชอบในการดำเนินการย้อนกลับและเผยแพร่การรักษาความปลอดภัยสำหรับผลิตภัณฑ์ที่รองรับ

⑤ การอัปเดตระบบปฏิบัติการแบบเต็ม การทำซ้ำขั้นตอนที่ 3 (การอัปเดตระบบปฏิบัติการแบบเต็ม) การอัปเดตระบบปฏิบัติการแบบเต็มครั้งที่ 2 จะทำให้ผลิตภัณฑ์เป็น Android X+4 ซึ่งเป็นช่วง 3 ปีแรกของอายุการใช้งานของยานพาหนะ ตอนนี้ผู้ผลิตกำลัง พิจารณาข้อกำหนดด้านฮาร์ดแวร์ใหม่ของ Android เวอร์ชันล่าสุดเทียบกับฮาร์ดแวร์ใน ผลิตภัณฑ์ และผู้ใช้จะได้รับประโยชน์จากระบบปฏิบัติการ Android ที่อัปเดต ผู้ผลิตเผยแพร่ การอัปเดตที่ไม่มีการอัปเดตความปลอดภัย ผลิตภัณฑ์จึงใช้ระบบปฏิบัติการ (X+4.y0) + ระดับแพตช์ความปลอดภัยของ Android ในปัจจุบัน

ในตัวอย่างนี้ เนื่องจากข้อจำกัดด้านฮาร์ดแวร์ X+4 จึงเป็น Android เวอร์ชันหลักสุดท้ายที่จะมีให้สำหรับผลิตภัณฑ์นี้ แม้ว่าอายุการใช้งานที่คาดไว้ของยานพาหนะจะอยู่ที่ 6 ปีขึ้นไป แต่ก็ยังต้องมีการสนับสนุนด้านความปลอดภัย
⑥ การอัปเดตความปลอดภัย ทำซ้ำขั้นตอนที่ 4 (อัปเดตความปลอดภัย) ผู้ผลิตมีหน้าที่รับข้อมูลอัปเดตด้านความปลอดภัยของ ASB จาก Android เวอร์ชันที่ใหม่กว่ามาก (X+6) และพอร์ตข้อมูลอัปเดตบางส่วนหรือทั้งหมดกลับไปยัง Android X+4 ผู้ผลิตมีหน้าที่ผสานรวมและดำเนินการอัปเดต (หรือทำสัญญากับบุคคลที่สาม) นอกจากนี้ ผู้ผลิตควรทราบว่าปัญหาด้านความปลอดภัยใน Android เวอร์ชันที่ระบบไม่รองรับแล้วจะไม่รวมอยู่ใน ASB
⑦ การอัปเดตความปลอดภัย ในวงจรการผลิตของยานพาหนะเป็นเวลา 8 ปี มีการเปิดตัว Android 4 รุ่นนับตั้งแต่ การอัปเดตระบบปฏิบัติการครั้งล่าสุดในขั้นตอนที่ 5 (การอัปเดตระบบปฏิบัติการแบบเต็ม) และ 10 ปีนับตั้งแต่มีการระบุ Android X ภาระในการดูแลจัดการและย้อนกลับแพตช์ความปลอดภัยจึงตกอยู่กับผู้ผลิตทั้งหมดสำหรับเวอร์ชันที่เก่ากว่า 3 ปีนับจากการเปิดตัวระดับ API ต่อสาธารณะ

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

Google ขอแนะนำและใช้แนวทางปฏิบัติแนะนำด้านความปลอดภัยและวิศวกรรมซอฟต์แวร์ที่ยอมรับกันโดยทั่วไปตามที่อธิบายไว้ในการใช้การรักษาความปลอดภัย เพื่อให้การประนีประนอมด้านความปลอดภัยเป็นไปได้ยากยิ่งขึ้น

หลักเกณฑ์ด้านความปลอดภัย

แนวทางปฏิบัติแนะนำเพื่อความปลอดภัยมีดังนี้

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

หลักเกณฑ์การพัฒนาซอฟต์แวร์

แนวทางปฏิบัติแนะนำสำหรับการพัฒนาซอฟต์แวร์ที่ปลอดภัยสำหรับวงจรของระบบ มีดังนี้

  • ทำการประเมินภัยคุกคามเพื่อจัดอันดับและระบุชิ้นงาน ภัยคุกคาม และการลดความเสี่ยงที่อาจเกิดขึ้น
  • ดำเนินการตรวจสอบสถาปัตยกรรม/การออกแบบเพื่อให้มั่นใจว่าการออกแบบมีความปลอดภัยและเหมาะสม
  • ตรวจสอบโค้ดเป็นประจำเพื่อระบุรูปแบบที่ไม่ควรใช้และข้อบกพร่องโดยเร็วที่สุด
  • ออกแบบ สร้าง และเรียกใช้การทดสอบหน่วยที่มีความครอบคลุมของโค้ดสูง ซึ่งรวมถึง
    • การทดสอบการทำงาน (รวมถึงกรณีทดสอบเชิงลบ)
    • การทดสอบการถดถอยเป็นประจำ (เพื่อให้แน่ใจว่าข้อบกพร่องที่แก้ไขแล้วจะไม่กลับมาอีก)
    • การทดสอบแบบฟัซ (เป็นส่วนหนึ่งของชุดการทดสอบหน่วย)
  • ใช้เครื่องมือวิเคราะห์ซอร์สโค้ดแบบคงที่ (scan-build, lint ฯลฯ) เพื่อระบุปัญหาที่อาจเกิดขึ้น
  • ใช้เครื่องมือวิเคราะห์ซอร์สโค้ดแบบไดนามิก เช่น AddressSanitizer, UndefinedBehaviorSanitizer และ FORTIFY_SOURCE (สําหรับคอมโพเนนต์ดั้งเดิม) เพื่อระบุและลดปัญหาที่อาจเกิดขึ้นระหว่าง การพัฒนาระบบ
  • มีกลยุทธ์การจัดการสำหรับซอร์สโค้ดของซอฟต์แวร์และการกำหนดค่า/เวอร์ชันการเผยแพร่
  • มีกลยุทธ์การจัดการแพตช์สำหรับการสร้างและการติดตั้งใช้งานแพตช์ซอฟต์แวร์

นโยบายการย้อนกลับด้านความปลอดภัย

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

  1. รับและตรวจสอบรายงานช่องโหว่
  2. สร้าง ทดสอบ และเผยแพร่การอัปเดตความปลอดภัย
  3. เผยแพร่การอัปเดตความปลอดภัยและรายละเอียดกระดานข่าวความปลอดภัยเป็นประจำ
  4. ประเมินระดับความรุนแรงตามหลักเกณฑ์ที่กำหนด

หลังจาก 3 ปีนับจากวันที่เผยแพร่ API ระดับสาธารณะ Google ขอแนะนำแนวทางต่อไปนี้

  • ใช้บุคคลที่สาม (เช่น ผู้จำหน่าย SoC หรือผู้ให้บริการเคอร์เนล) เพื่อรองรับการย้อนพอร์ตสำหรับการอัปเดตความปลอดภัยของ OS ที่เก่ากว่า 3 ปีนับจากวันที่เผยแพร่ API
  • ใช้บุคคลที่สามเพื่อตรวจสอบโค้ดโดยใช้ ASB ที่เผยแพร่ต่อสาธารณะ แม้ว่า ASB จะระบุช่องโหว่สำหรับเวอร์ชันที่รองรับในปัจจุบัน แต่ผู้ผลิตอาจใช้ข้อมูลที่ระบุ เพื่อเปรียบเทียบการอัปเดตที่เพิ่งเผยแพร่กับการอัปเดตเวอร์ชันก่อนหน้า ข้อมูลนี้สามารถใช้เพื่อ วิเคราะห์ผลกระทบและอาจสร้างแพตช์ที่คล้ายกันสำหรับ OS เวอร์ชันที่เก่ากว่า 3 ปีนับจาก การเปิดตัว API
  • อัปโหลดการอัปเดตความปลอดภัยไปยังโครงการโอเพนซอร์ส Android (AOSP) เมื่อเหมาะสม
  • ผู้ผลิตต้องประสานงานการจัดการการอัปเดตความปลอดภัยสำหรับโค้ดเฉพาะผู้ให้บริการ (เช่น โค้ดเฉพาะอุปกรณ์ที่เป็นกรรมสิทธิ์)
  • ผู้ผลิตควรเข้าร่วมกลุ่มการแจ้งเตือนการแสดงตัวอย่างสำหรับพาร์ทเนอร์ในกระดานข่าวความปลอดภัยของ Android ภายใต้ NDA (ต้องลงนามในข้อตกลงทางกฎหมาย เช่น NDA สำหรับนักพัฒนาแอป) โดยควรมีข้อมูลดังต่อไปนี้
    • ประกาศ
    • สรุปปัญหาตามระดับแพตช์ รวมถึง CVE และความรุนแรง
    • รายละเอียดช่องโหว่ตามความเหมาะสม

ข้อมูลอ้างอิงเพิ่มเติม

ดูวิธีการเขียนโค้ดและการพัฒนาซอฟต์แวร์ที่ปลอดภัยได้ที่

Google สนับสนุนให้ใช้แนวทางปฏิบัติที่แนะนำต่อไปนี้

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

หลักเกณฑ์ที่แนะนำมีดังนี้

  • เนื่องจากระยะเวลานำในการพัฒนาที่ยาวนานซึ่งเป็นกระบวนการพัฒนาของยานพาหนะ ผู้ผลิต อาจต้องเปิดตัวด้วยเวอร์ชันระบบปฏิบัติการ n-2 หรือเก่ากว่า
  • รักษาการปฏิบัติตามข้อกำหนดด้านความเข้ากันได้ของ Android สำหรับระบบปฏิบัติการ Android แต่ละเวอร์ชันที่เผยแพร่ด้วยแคมเปญ แบบ Over-the-Air (OTA)
  • ใช้เฟิร์มแวร์ของผลิตภัณฑ์ผ่านอากาศ (FOTA) ของ Android เพื่อการอัปเดตที่รวดเร็วและเป็นมิตรกับลูกค้า ควรดำเนินการ FOTA โดยใช้แนวทางปฏิบัติแนะนำด้านความปลอดภัย เช่น การลงนามในโค้ดและการเชื่อมต่อ TLS ระหว่างผลิตภัณฑ์และแบ็กออฟฟิศไอที
  • ส่ง ช่องโหว่ด้านความปลอดภัยของ Android ที่พบโดยอิสระไปยังทีมความปลอดภัยของ Android

หมายเหตุ: Google ได้พิจารณาประเภทอุปกรณ์หรือการแจ้งเตือนเฉพาะอุตสาหกรรม ในกระสุนความปลอดภัยของ Android อย่างไรก็ตาม เนื่องจาก Google ไม่ทราบเคอร์เนล ไดรเวอร์ หรือชิปเซ็ตสำหรับอุปกรณ์ที่กำหนด (ยานพาหนะ ทีวี อุปกรณ์ที่สวมใส่ได้ โทรศัพท์ ฯลฯ) Google จึงไม่มี วิธีที่แน่นอนในการติดป้ายกำกับปัญหาด้านความปลอดภัยที่กำหนดด้วยประเภทอุปกรณ์

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

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

เอกสารนิยามความเข้ากันได้ (CDD)

เอกสารนิยามความเข้ากันได้ (CDD) อธิบายข้อกำหนดสำหรับอุปกรณ์ที่จะถือว่า เข้ากันได้กับ Android CDD เป็นเอกสารแบบสาธารณะที่ทุกคนเข้าถึงได้ คุณสามารถดาวน์โหลด CDD เวอร์ชันต่างๆ ตั้งแต่ Android 1.6 จนถึงเวอร์ชันล่าสุดได้จาก source.android.com

การปฏิบัติตามข้อกำหนดเหล่านี้สำหรับผลิตภัณฑ์มีขั้นตอนพื้นฐานต่อไปนี้

  1. พาร์ทเนอร์ลงนามในข้อผูกมัดด้านความเข้ากันได้ของ Android (ACC) กับ Google จากนั้นระบบจะมอบหมายที่ปรึกษาด้านโซลูชันทางเทคนิค (TSC) ให้เป็นผู้แนะนำ
  2. พาร์ทเนอร์ตรวจสอบ CDD สำหรับเวอร์ชันระบบปฏิบัติการ Android ของผลิตภัณฑ์เสร็จสมบูรณ์
  3. พาร์ทเนอร์จะเรียกใช้และส่งผลลัพธ์ CTS (อธิบายไว้ด้านล่าง) จนกว่าผลลัพธ์จะเป็นที่ยอมรับ สำหรับการทำงานร่วมกันของ Android

ชุดเครื่องมือทดสอบความเข้ากันได้ (CTS)

เครื่องมือทดสอบชุดเครื่องมือทดสอบความเข้ากันได้ (CTS) จะยืนยันว่าการติดตั้งใช้งานผลิตภัณฑ์นั้น เข้ากันได้กับ Android และมีแพตช์ความปลอดภัยล่าสุด CTS เป็นโอเพนซอร์สแบบสาธารณะ และพร้อมให้บริการแก่ทุกคน คุณสามารถดาวน์โหลด CTS เวอร์ชันต่างๆ ตั้งแต่ Android 1.6 จนถึงเวอร์ชันล่าสุด ได้จาก source.android.com

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

หมายเหตุ: พาร์ทเนอร์ที่ลงนามในข้อตกลงอื่นๆ เช่น บริการของ Google Mobile (GMS) อาจต้องปฏิบัติตามข้อกำหนดอื่นๆ

เวิร์กโฟลว์ของ CTS

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

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

ผ่าน CTS

สำหรับผลิตภัณฑ์ที่ใช้งานร่วมกับ Android ได้ Google จะตรวจสอบว่ารายงาน CTS และ CTS Verifier ของอุปกรณ์ มีผลการทดสอบที่ยอมรับได้ โดยหลักการแล้ว การทดสอบทั้งหมดต้องผ่าน อย่างไรก็ตาม การทดสอบที่ไม่ผ่านเนื่องจาก เหตุผลอื่นๆ นอกเหนือจากอุปกรณ์ไม่เป็นไปตามข้อกำหนดด้านความเข้ากันได้ของ Android จะได้รับการตรวจสอบจาก Google ในระหว่างกระบวนการนี้

  1. ผู้ผลิตจะส่งแพตช์ CTS ที่เสนอ การตรวจสอบแพตช์ และ เหตุผลให้ Google เพื่อพิสูจน์ข้อโต้แย้ง
  2. Google จะตรวจสอบเนื้อหาที่ส่งมา และหากยอมรับ ก็จะอัปเดตการทดสอบ CTS ที่เกี่ยวข้องเพื่อให้ อุปกรณ์ผ่านการทดสอบใน CTS ฉบับแก้ไขครั้งถัดไป

หากการทดสอบ CTS ล้มเหลวอย่างกะทันหันหลังจากใช้แพตช์ความปลอดภัย ผู้ผลิตต้องแก้ไข แพตช์เพื่อให้ไม่ทำลายความเข้ากันได้ หรือแสดงว่าการทดสอบไม่ถูกต้องและแก้ไข การทดสอบ (ตามที่อธิบายไว้ข้างต้น)

CTS จะยังคงเปิดให้ตรวจสอบการแก้ไขการทดสอบ เช่น Android 4.4 ยังคงยอมรับ การแก้ไข (ดู https://android-review.googlesource.com/c/platform/cts/+/273371)

คำถามที่พบบ่อย

คำถาม: ใครมีหน้าที่รับผิดชอบในการใช้การอัปเดตความปลอดภัยกับการใช้งาน Android ที่เฉพาะเจาะจง

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

ถาม: Google จัดการปัญหาด้านความปลอดภัยใน Android อย่างไร

ตอบ: Google ตรวจสอบปัญหาและพัฒนาวิธีแก้ไขที่อาจเกิดขึ้นอย่างต่อเนื่อง ซึ่ง Google จะเผยแพร่ให้ API ระดับที่รองรับทั้งหมดเป็นส่วนหนึ่งของกระบวนการอัปเดตความปลอดภัยเป็นประจำ ตั้งแต่เดือนสิงหาคม 2015 Google ได้เผยแพร่ประกาศและลิงก์ไปยังการอัปเดตใน source.android.com เป็นประจำ นอกจากนี้ Google ยังเผยแพร่การอัปเดตความปลอดภัยเป็นส่วนหนึ่งของการเปิดตัวระบบปฏิบัติการเวอร์ชันหลักด้วย โปรดดู นโยบายการย้อนกลับด้านความปลอดภัยด้วย

คำถาม: หากผู้ผลิตผสานรวมแพตช์ AOSP ทั้งหมดจาก ASB แต่ไม่ได้ผสานรวม แพตช์จากผู้ให้บริการ BSP ที่ระบุไว้ในกระดานข่าวเดียวกัน ผู้ผลิตจะยังคงเพิ่มระดับความปลอดภัย (เช่น ใช้แพตช์ที่เกี่ยวข้องกับแพลตฟอร์ม/บิลด์) ได้ไหม

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

ถาม: จะเกิดอะไรขึ้นเมื่อผู้ผลิตไม่เห็นด้วยกับการอัปเดตความปลอดภัยที่ผู้ให้บริการ BSP จัดให้ หรือเมื่อผู้ให้บริการไม่ได้จัดหาการอัปเดตความปลอดภัยตามที่ ASB กำหนด

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

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

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

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

คำถาม: หากผู้ผลิตพิจารณาว่ารายการ ASB ไม่เกี่ยวข้องกับผลิตภัณฑ์ของตน จะยังต้องใช้หรือแก้ไขรายการดังกล่าวเพื่อให้เป็นไปตามข้อกำหนดอื่นๆ ของ Google หรือผ่าน CTS หรือไม่

ตอบ: เราไม่กำหนดให้ต้องใช้แพตช์เพื่อประกาศระดับแพตช์ความปลอดภัยของ Android (SPL) แต่กำหนดให้ผู้ผลิตรับรองว่าบิลด์ของตนไม่มีช่องโหว่ที่ ปัญหา

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

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