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

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

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

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

ความคิดเห็น

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

อภิธานศัพท์

คำศัพท์ คำจำกัดความ
ACC ความมุ่งมั่นด้านความเข้ากันได้กับ Android เดิมเรียกว่าข้อตกลงป้องกันการแยกตัวของ Android (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 เพื่อดูว่าผลิตภัณฑ์ที่รองรับระบบปฏิบัติการ 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) ครั้งแรก
② การเปิดตัวครั้งแรก 2-3 เดือนก่อนที่ 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) OS + ระดับแพตช์ความปลอดภัยของ Android

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

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

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

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

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

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

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

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

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

นโยบายการพอร์ตความปลอดภัยย้อนหลัง

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ถาม: จะเกิดอะไรขึ้นเมื่อผู้ผลิตไม่เห็นด้วยกับการอัปเดตความปลอดภัยที่ได้จากผู้ให้บริการ 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