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

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

การรับทราบและการปฏิเสธความรับผิดชอบ

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

ข้อเสนอแนะ

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

อภิธานศัพท์

ภาคเรียน คำนิยาม
บัญชี ความมุ่งมั่นในความเข้ากันได้ของ Android เดิมชื่อข้อตกลงต่อต้านการกระจายตัวของ Android (AFA)
อสป โครงการโอเพ่นซอร์ส Android
เอเอสบี กระดานข่าวความปลอดภัยของ Android
บีเอสพี แพ็คเกจสนับสนุนบอร์ด
ซีดีดี เอกสารคำจำกัดความความเข้ากันได้
ซีทีเอส ชุดทดสอบความเข้ากันได้
โฟต้า เฟิร์มแวร์ผ่านทางอากาศ
จีพีเอส ระบบกำหนดตำแหน่งบนโลก
มิสรา สมาคมความน่าเชื่อถือซอฟต์แวร์อุตสาหกรรมยานยนต์
NIST สถาบันมาตรฐานและเทคโนโลยีแห่งชาติ
โอบีดี การวินิจฉัยออนบอร์ด ( OBD-II เป็นการปรับปรุงมากกว่า OBD-I ทั้งในด้านความสามารถและมาตรฐาน )
OEM ผู้ผลิตอุปกรณ์ดั้งเดิม
ระบบปฏิบัติการ ระบบปฏิบัติการ
SEI สถาบันวิศวกรรมซอฟต์แวร์
โซซี ระบบบนชิป
สบส เริ่มการผลิต
สปล ระดับแพตช์ความปลอดภัย
ทีพีเอ็มเอส ระบบตรวจสอบแรงดันลมยาง

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

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

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

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

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

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

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

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

มั่นใจในความปลอดภัยในระยะยาว

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

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

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

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

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

①

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

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

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

เว้นแต่จะมีข้อตกลงทางธุรกิจอื่นๆ การตัดสินใจอัปเดตระบบปฏิบัติการแบบเต็มจะขึ้นอยู่กับดุลยพินิจของผู้ผลิต ทั้งหมด

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

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

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

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

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

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

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

แนวทางการรักษาความปลอดภัย

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

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

แนวทางการพัฒนาซอฟต์แวร์

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

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

นโยบาย backport ความปลอดภัย

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

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

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

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

การอ้างอิงเพิ่มเติม

สำหรับคำแนะนำเกี่ยวกับการเขียนโค้ดอย่างปลอดภัยและแนวปฏิบัติในการพัฒนาซอฟต์แวร์ โปรดดูที่ต่อไปนี้:

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

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

แนวทางที่แนะนำได้แก่:

  • เนื่องจากกระบวนการพัฒนายานพาหนะต้องใช้เวลาในการพัฒนาที่ยาวนาน ผู้ผลิตจึงอาจจำเป็นต้องเปิดตัวระบบปฏิบัติการเวอร์ชัน n-2 หรือเก่ากว่า
  • รักษาความสอดคล้องกับความเข้ากันได้ของ Android สำหรับระบบปฏิบัติการ Android แต่ละเวอร์ชันที่วางจำหน่ายด้วยแคมเปญแบบ over-the-air (OTA)
  • ใช้ผลิตภัณฑ์ Android Firmware-over-the-air (FOTA) ซึ่งสามารถรองรับการอัปเดตที่รวดเร็วและเป็นมิตรกับลูกค้า 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 Services (GMS) อาจต้องปฏิบัติตามข้อกำหนดอื่นๆ

ขั้นตอนการทำงานของซีทีเอส

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

  • ทำการทดสอบบ่อยๆ CTS ได้รับการออกแบบให้เป็นเครื่องมืออัตโนมัติที่รวมเข้ากับระบบการสร้างของคุณ การใช้งาน CTS บ่อยครั้งสามารถช่วยให้คุณค้นหาข้อบกพร่องได้อย่างรวดเร็วและเร็วเมื่อซอฟต์แวร์เสื่อมสภาพหรือถดถอยเกิดขึ้น
  • ดาวน์โหลดและตรวจสอบซอร์สโค้ด CTS ซอร์สโค้ด CTS แบบเต็มเป็นซอฟต์แวร์โอเพ่นซอร์สที่ใครๆ ก็สามารถ ดาวน์โหลดและใช้งานได้ (ซอร์สโค้ดที่ดาวน์โหลดมาสามารถสร้างและรันได้อย่างสมบูรณ์) เมื่อการทดสอบบนอุปกรณ์ล้มเหลว การตรวจสอบส่วนที่เกี่ยวข้องของซอร์สโค้ดสามารถช่วยคุณระบุสาเหตุได้
  • รับ CTS ล่าสุด Android รุ่นใหม่สามารถอัปเดต CTS ด้วยการแก้ไขข้อบกพร่อง การปรับปรุง และการทดสอบใหม่ ตรวจสอบ การดาวน์โหลด CTS บ่อยๆ และอัปเดตโปรแกรม CTS ของคุณตามความจำเป็น ผู้ผลิตและ Google จะตกลงเกี่ยวกับเวอร์ชัน 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/273371/ )

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

ถาม: ใครเป็นผู้รับผิดชอบในการใช้การอัปเดตความปลอดภัยกับการใช้งาน Android โดยเฉพาะ

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

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

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

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

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

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

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

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

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

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

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

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

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

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