คู่มือนี้จะอธิบายแนวทางปฏิบัติแนะนำของ Google สำหรับการใช้แพตช์ความปลอดภัยที่ผ่านการทดสอบโดยชุดเครื่องมือทดสอบความเข้ากันได้ของ Android (CTS) โปรแกรมนี้มีไว้สำหรับผู้ผลิตอุปกรณ์ OEM (ผู้ผลิต) ที่เข้ากันได้กับ Android ซึ่งจะได้รับการรองรับนานกว่า 3 ปี เช่น ยานพาหนะ ทีวี กล่องรับสัญญาณ และเครื่องใช้ไฟฟ้าในบ้าน คำแนะนำนี้ไม่ได้มีไว้สำหรับผู้ใช้ปลายทาง (เช่น เจ้าของยานพาหนะ)
รับทราบและข้อจำกัดความรับผิด
คำแนะนำนี้ไม่ได้ผูกมัด Google หรือผู้ผลิตรายอื่นๆ ทางกฎหมายหรือสัญญา และไม่ได้มีไว้เพื่อเป็นชุดข้อกำหนด แต่คู่มือนี้จะเป็นตัวช่วยการเรียนการสอนที่ แนวทางปฏิบัติที่แนะนำ
ความคิดเห็น
คู่มือนี้ไม่ได้มีวัตถุประสงค์เพื่อให้ครอบคลุม โดยมีการวางแผนการแก้ไขเพิ่มเติม ส่งความคิดเห็นไปที่ manufacturers-guide-android@googlegroups.com
อภิธานศัพท์
| คำศัพท์ | คำจำกัดความ |
|---|---|
| ACC | สัญญาผูกมัดความเข้ากันได้กับ Android เดิมเรียกว่าข้อตกลงป้องกันการแยกตัวของ Android (AFA) |
| AOSP | โครงการโอเพนซอร์ส Android |
| รหัส ASB | กระดานข่าวสารเกี่ยวกับความปลอดภัยของ Android |
| BSP | แพ็กเกจการสนับสนุนบอร์ด |
| CDD | เอกสารคำจำกัดความความเข้ากันได้ |
| CTS | ชุดเครื่องมือทดสอบความเข้ากันได้ |
| FOTA | เฟิร์มแวร์ผ่านอากาศ (OTA) |
| GPS | ระบบกำหนดตำแหน่งเป้าหมายทั่วโลก |
| มิสรา | Motor Industry Software Reliability Association |
| NIST | สถาบันมาตรฐานและเทคโนโลยีแห่งชาติ |
| OBD | การวินิจฉัยบนเครื่อง (OBD-II เป็นการปรับปรุงจาก OBD-I ทั้งในด้านความสามารถและมาตรฐาน) |
| OEM | ผู้ผลิตอุปกรณ์ดั้งเดิม |
| ระบบปฏิบัติการ | ระบบปฏิบัติการ |
| SEI | สถาบันวิศวกรรมซอฟต์แวร์ |
| 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, ความเข้ากันได้ และระบบบิลด์ โปรดดูรายการต่อไปนี้
- รักษาความปลอดภัยให้อุปกรณ์ 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 การอัปเดตระบบปฏิบัติการนี้อาจเข้ากันได้หรือไม่กับผลิตภัณฑ์ภาคสนาม หากใช่
สามารถสร้างแผนเพื่ออัปเดตยานพาหนะที่ทำให้ใช้งานได้แล้ว
การตัดสินใจที่จะอัปเดตระบบปฏิบัติการอย่างเต็มรูปแบบจะขึ้นอยู่กับดุลยพินิจของผู้ผลิตโดยสมบูรณ์ เว้นแต่จะมีข้อตกลงทางธุรกิจอื่นๆ อยู่ |
| 4 | การอัปเดตความปลอดภัย | 2 ปีในอายุการใช้งานการผลิตของยานพาหนะ ผู้ผลิตได้แพตช์
ระบบปฏิบัติการ Android X+2 การตัดสินใจนี้อิงตามการประเมินความเสี่ยงของผู้ผลิต ผู้ผลิตเลือกการอัปเดตความปลอดภัย ASB ครั้งที่ 3 สำหรับรุ่น X+2 เป็นพื้นฐานของการอัปเดต ผลิตภัณฑ์ที่รับการอัปเดตความปลอดภัยอยู่ในระบบปฏิบัติการ (X+2.y3) + ระดับแพตช์ความปลอดภัยของ Android
แม้ว่าผู้ผลิตจะเลือกแพตช์ความปลอดภัยแต่ละรายการจาก ASB รายการใดก็ได้ แต่จะต้องแก้ไขปัญหาที่จำเป็นทั้งหมดในกระดานข่าวสารเพื่อใช้ระดับแพตช์ความปลอดภัย Android (SPL) ที่เชื่อมโยงกับกระดานข่าวสาร (เช่น 2017-02-05) เป็นผลิตภัณฑ์ของผู้ผลิต ในการจัดทำ Backport และการรักษาความปลอดภัยสำหรับผลิตภัณฑ์ที่สนับสนุน |
| ⑤ | การอัปเดตระบบปฏิบัติการแบบเต็ม | ทำซ้ำขั้นตอนที่ 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 เป็นความรับผิดชอบของผู้ผลิตในการรวม ผสานรวม และดำเนินการ การปรับปรุง (หรือทำสัญญากับบุคคลที่สาม) นอกจากนี้ ผู้ผลิตควรทราบว่า ปัญหาด้านความปลอดภัยใน Android เวอร์ชันที่ไม่รองรับอีกต่อไปไม่ครอบคลุมอยู่ใน ASB |
| 7 คน | การอัปเดตความปลอดภัย | 8 ปีในวงจรการผลิตของยานพาหนะ Android 4 รุ่นนับตั้งแต่เปิดตัว อัปเดตระบบปฏิบัติการครั้งล่าสุดในขั้นตอนที่ 5 (การอัปเดตระบบปฏิบัติการเต็มรูปแบบ) และ 10 ปีนับตั้งแต่มีการระบุ Android X ค่า ภาระในการดูแลจัดการและย้อนกลับแพตช์ด้านความปลอดภัยนั้นล้วนแต่เป็นที่ผู้ผลิตสำหรับ เวอร์ชันเก่ากว่า 3 ปีนับจากรุ่นที่เผยแพร่สู่สาธารณะระดับ API |
แนวทางปฏิบัติแนะนำสำหรับการรักษาความปลอดภัย
เพื่อทำให้การรักษาความปลอดภัยพบความยุ่งยากมากขึ้น Google ได้แนะนำและใช้ เป็นที่ยอมรับในแนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับความปลอดภัยและวิศวกรรมซอฟต์แวร์ตามที่อธิบายไว้ใน การใช้การรักษาความปลอดภัย
หลักเกณฑ์ด้านความปลอดภัย
แนวทางปฏิบัติแนะนำเพื่อความปลอดภัยมีดังนี้
- ใช้ไลบรารีภายนอกและคอมโพเนนต์โอเพนซอร์สเวอร์ชันล่าสุด
- อย่ารวมฟังก์ชันการแก้ไขข้อบกพร่องที่รบกวนไว้ในเวอร์ชันที่เผยแพร่ของระบบปฏิบัติการ
- นำฟังก์ชันที่ไม่ได้ใช้ออก (เพื่อลดพื้นที่ในการโจมตีที่ไม่จำเป็น)
- ใช้หลักการให้สิทธิ์ขั้นต่ำที่สุดและแนวทางปฏิบัติแนะนำอื่นๆ สำหรับการพัฒนาแอป Android
หลักเกณฑ์การพัฒนาซอฟต์แวร์
แนวทางปฏิบัติที่แนะนำสำหรับการพัฒนาซอฟต์แวร์ที่ปลอดภัยตลอดอายุของระบบ รวมข้อมูลต่อไปนี้
- สร้างแบบจำลองภัยคุกคามเพื่อจัดอันดับและระบุเนื้อหา ภัยคุกคาม และการลดความเสี่ยงที่อาจเกิดขึ้น
- ดำเนินการตรวจสอบด้านสถาปัตยกรรม/การออกแบบเพื่อให้แน่ใจว่ามีการออกแบบเสียงที่ปลอดภัย
- ตรวจสอบโค้ดเป็นประจำเพื่อระบุรูปแบบต่อต้านและข้อบกพร่องโดยเร็วที่สุด
- ออกแบบ ใช้งาน และเรียกใช้การทดสอบหน่วยที่ครอบคลุมเกี่ยวกับโค้ดระดับสูง ซึ่งรวมถึงสิ่งต่อไปนี้
- การทดสอบฟังก์ชันการทำงาน (รวมถึงเทสเคสเชิงลบ)
- การทดสอบรีเกรดเป็นประจำ (เพื่อให้แน่ใจว่าข้อบกพร่องที่แก้ไขแล้วจะไม่ปรากฏขึ้นอีก)
- การทดสอบแบบ Fuzz (เป็นส่วนหนึ่งของชุดการทดสอบ 1 หน่วย)
- ใช้เครื่องมือวิเคราะห์ซอร์สโค้ดแบบคงที่ (scan-build, lint ฯลฯ) เพื่อระบุปัญหาที่อาจเกิดขึ้น
- ใช้เครื่องมือวิเคราะห์ซอร์สโค้ดแบบไดนามิก เช่น AddressSanitizer, UndefinedBehaviorSanitizer และ FORTIFY_SOURCE (สำหรับคอมโพเนนต์ที่มาพร้อมเครื่อง) เพื่อระบุและลดปัญหาที่อาจเกิดขึ้นระหว่าง การพัฒนาระบบ
- มีกลยุทธ์การจัดการสำหรับซอร์สโค้ดของซอฟต์แวร์และการกำหนดค่า/เวอร์ชันของรุ่น
- มีกลยุทธ์การจัดการแพตช์สำหรับการสร้างและทำให้แพตช์ซอฟต์แวร์ใช้งานได้
นโยบายการพอร์ตความปลอดภัยย้อนหลัง
ปัจจุบัน Google ให้บริการสนับสนุนแบ็กพอร์ตความปลอดภัยของช่องโหว่ด้านความปลอดภัยที่ค้นพบและรายงานเป็นเวลา 3 ปีนับจากระดับ API ที่เผยแพร่ต่อสาธารณะ การสนับสนุนแบบใช้งานอยู่ประกอบด้วยสิ่งต่อไปนี้
- รับและตรวจสอบรายงานช่องโหว่
- สร้าง ทดสอบ และเผยแพร่การอัปเดตความปลอดภัย
- เผยแพร่การอัปเดตความปลอดภัยและรายละเอียดกระดานข่าวสารด้านความปลอดภัยเป็นระยะๆ
- ประเมินความรุนแรงตามหลักเกณฑ์ที่กำหนด
หลังจากผ่านไป 3 ปีนับจากวันที่เปิดตัวระดับ API สู่สาธารณะ Google ขอแนะนำให้ดำเนินการต่อไปนี้ หลักเกณฑ์:
- ใช้บุคคลที่สาม (เช่น ผู้ให้บริการ SoC หรือผู้ให้บริการเคอร์เนล) เพื่อขอรับการสนับสนุนการพอร์ตย้อนกลับสำหรับการอัปเดตความปลอดภัยของระบบปฏิบัติการที่เก่ากว่า 3 ปีนับจากรุ่น API
- ใช้บุคคลที่สามในการตรวจสอบโค้ดโดยใช้ ASB ที่เผยแพร่ต่อสาธารณะ แม้ว่า ASB จะระบุช่องโหว่สำหรับเวอร์ชันที่รองรับในปัจจุบัน แต่ผู้ผลิตอาจใช้ข้อมูลที่ให้ไว้เพื่อเปรียบเทียบการอัปเดตที่เพิ่งเปิดตัวกับเวอร์ชันก่อนหน้า ข้อมูลนี้อาจใช้เพื่อ วิเคราะห์ผลกระทบและอาจสร้างแพตช์ที่คล้ายกันสำหรับระบบปฏิบัติการเวอร์ชันเก่ากว่า 3 ปีนับจากวันที่ API เปิดตัว
- อัปโหลดการอัปเดตความปลอดภัยไปยังโครงการโอเพนซอร์ส Android (AOSP) เมื่อเหมาะสม
- ผู้ผลิตต้องประสานงานการจัดการการอัปเดตความปลอดภัยสำหรับรหัสเฉพาะผู้ให้บริการ (เช่น รหัสเฉพาะอุปกรณ์ที่เป็นกรรมสิทธิ์)
- ผู้ผลิตควรเข้าร่วมกลุ่มการแจ้งเตือนพาร์ทเนอร์ตัวอย่างข่าวความปลอดภัยของ Android ภายใต้ NDA (ต้องมีการลงนามในข้อตกลงทางกฎหมาย เช่น NDA ของนักพัฒนาแอป) กระดานข่าวสารควรมีข้อมูลต่อไปนี้
- ประกาศ
- สรุปปัญหาตามระดับแพตช์ รวมถึง CVE และความรุนแรง
- รายละเอียดช่องโหว่ตามความเหมาะสม
ข้อมูลอ้างอิงเพิ่มเติม
สำหรับคำแนะนำเกี่ยวกับการเขียนโค้ดและการพัฒนาซอฟต์แวร์ที่ปลอดภัย โปรดดูแหล่งข้อมูลต่อไปนี้
- สมาคมความน่าเชื่อถือของซอฟต์แวร์อุตสาหกรรมยานยนต์ (Motor Industry Software Reliability Association หรือ MISRA)
- สถาบันวิศวกรรมซอฟต์แวร์ (SEI) เครื่องมือและ เมธอด
- สถาบันมาตรฐานแห่งชาติและ เทคโนโลยี (NIST)
แนวทางปฏิบัติแนะนำสำหรับผลิตภัณฑ์
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
การปฏิบัติตามข้อกำหนดของผลิตภัณฑ์มีขั้นตอนพื้นฐานดังต่อไปนี้
- พาร์ทเนอร์ลงนามในข้อตกลงความเข้ากันได้กับ Android (ACC) กับ Google จากนั้นระบบจะมอบหมายที่ปรึกษาด้านโซลูชันทางเทคนิค (TSC) ให้เป็นไกด์
- พาร์ทเนอร์ตรวจสอบ CDD สำหรับเวอร์ชันระบบปฏิบัติการ Android ของผลิตภัณฑ์เรียบร้อยแล้ว
- พาร์ทเนอร์แสดงและส่งผลลัพธ์ 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 ตั้งแต่เนิ่นๆ และบ่อยครั้งเพื่อระบุและแก้ไขปัญหา
เวิร์กโฟลว์ 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 สิ่งที่จะเกิดในระหว่างกระบวนการ
- ผู้ผลิตต้องส่งแพตช์ CTS ที่เสนอ การยืนยันแพตช์ และเหตุผลเพื่อพิสูจน์ข้อโต้แย้งให้ Google
- 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 เป็นระยะๆ นอกจากนี้ เรายังเผยแพร่การอัปเดตความปลอดภัยเป็นส่วนหนึ่งของการเปิดตัวระบบปฏิบัติการเวอร์ชันหลักด้วย ดูเพิ่มเติม นโยบาย Backport ความปลอดภัย
ถาม: ในกรณีที่ผู้ผลิตผสานรวมแพตช์ AOSP ทั้งหมดจาก ASB แต่ไม่ได้ผสานรวม แพตช์จากผู้ให้บริการ BSP ที่กล่าวถึงในกระดานข่าวสารเดียวกัน จะสามารถยกระดับความปลอดภัยได้ (เช่น ใช้แพตช์ที่เกี่ยวข้องกับแพลตฟอร์ม/บิลด์)
ตอบ: หากต้องการประกาศระดับแพตช์ความปลอดภัยของ Android (SPL) ผู้ผลิตต้องดําเนินการทั้งหมดที่จําเป็น ปัญหาที่เผยแพร่ในกระดานข่าวสารด้านความปลอดภัยของ Android (รวมถึงกระดานข่าวสารก่อนหน้านี้) และที่ทำแผนที่ สำหรับ Android SPL โดยเฉพาะ ตัวอย่างเช่น ผู้ผลิตที่ใช้ประกาศข่าวสารด้านความปลอดภัยของเดือนมีนาคม 2017 (2017-03-01 SPL) ได้แก้ไขปัญหาที่จำเป็นทั้งหมดตามที่บันทึกไว้ในประกาศข่าวสารของเดือนมีนาคม 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 ไม่เป็นไปตามนโยบายดังกล่าว