يصف هذا الدليل أفضل الممارسات التي تنصح بها Google لتطبيق تصحيحات الأمان التي يتم تقييمها من خلال مجموعة أدوات اختبار التوافق (CTS) لنظام التشغيل Android. وهو مخصّص لشركات تصنيع الأجهزة الأصلية المتوافقة مع Android (الشركات المصنّعة) التي ستوفّر الدعم لأكثر من ثلاث سنوات مثل المركبات وأجهزة التلفزيون وأجهزة فك التشفير والأجهزة المنزلية. لا يُقصد استخدام هذا الدليل من قِبل المستخدمين النهائيين (مثل مالكي المركبات).
الشكر وإخلاء المسؤولية
لا يُلزم هذا الدليل Google أو المصنّعين الآخرين من الناحية القانونية أو التعاقدية، ولا يهدف إلى أن يكون مجموعة من المتطلبات. بل هو دليل إرشادي يصف الممارسات المقترَحة.
الملاحظات
لا يهدف هذا الدليل إلى أن يكون شاملاً، بل سيتم إجراء مراجعات إضافية عليه. يُرجى إرسال الملاحظات إلى manufacturers-guide-android@googlegroups.com.
مسرد المصطلحات
| العبارة | التعريف |
|---|---|
| ACC | التزام التوافق مع Android كانت هذه الاتفاقية تُعرف سابقًا باسم "اتفاقية منع التجزئة في Android" (AFA). |
| مشروع مفتوح المصدر لنظام Android (AOSP) | مشروع مفتوح المصدر لنظام Android |
| ASB | نشرة أمان Android |
| صفحة ملخص الفوترة | حزمة دعم لوحة الجهاز |
| CDD | مستند تعريف معايير التوافق |
| مجموعة أدوات اختبار التوافق (CTS) | مجموعة أدوات اختبار التوافق |
| FOTA | البرامج الثابتة عبر شبكة غير سلكيّة |
| نظام تحديد المواقع العالمي (GPS) | نظام تحديد المواقع العالمي |
| MISRA | رابطة موثوقية البرامج في مجال السيارات |
| المعهد الوطني للمعايير والتكنولوجيا (NIST) | المعهد الوطني للمعايير والتكنولوجيا |
| OBD | بيانات التشخيص على متن المركبة (يُعدّ معيار OBD-II محسّنًا عن معيار OBD-I من حيث الإمكانات والتوحيد) |
| المصنّع الأصلي للجهاز | المصنّع الأصلي للجهاز |
| نظام التشغيل | نظام التشغيل |
| SEI | معهد هندسة البرمجيات |
| منظومة على رقاقة (SoC) | منظومة على رقاقة |
| إجراءات التشغيل المعيارية | بدء الإنتاج |
| SPL | مستوى رمز تصحيح الأمان |
| TPMS | نظام مراقبة ضغط الإطارات |
لمحة عن نظام التشغيل Android
Android هو حزمة برامج كاملة مفتوحة المصدر ومستندة إلى Linux ومصمّمة لمجموعة متنوعة من الأجهزة و أشكال الأجهزة. منذ إصداره الأول في عام 2008، أصبح Android نظام التشغيل (OS) الأكثر رواجًا، حيث يعمل على تشغيل أكثر من 1.4 مليار جهاز في جميع أنحاء العالم (2016). يستخدم ما يقرب من% 67 من هذه الأجهزة الإصدار Android 5.0 (Lollipop) أو إصدارًا أحدث اعتبارًا من آذار (مارس) 2017 (تتوفّر أرقام أحدث في لوحة بيانات Android). على الرغم من أنّ الغالبية العظمى من الأجهزة هي هواتف جوّالة وأجهزة لوحية، يزداد استخدام نظام التشغيل Android في الساعات الذكية وأجهزة التلفزيون وأجهزة الترفيه داخل المركبات (IVI).
وصل عدد تطبيقات Android المتاحة في "متجر Google Play" إلى أكثر من 2.2 مليون (2016). يستند تطوير تطبيقات Android إلى برنامج التوافق مع Android الذي يحدّد مجموعة من المتطلبات من خلال مستند تعريف التوافق (CDD) ويقدّم أدوات الاختبار من خلال مجموعة أدوات اختبار التوافق (CTS). تضمن برامج التوافق مع Android إمكانية تشغيل أي تطبيق Android على أي جهاز متوافق مع Android يتيح الميزات المطلوبة للتطبيق.
تُصدِر Google بانتظام إصدارات جديدة من نظام التشغيل وتحديثات أمان له ومعلومات عن نقاط الضعف المكتشفة. على الشركات المصنّعة مراجعة نشرة أمان Android لمعرفة مدى إمكانية تطبيق هذه التحديثات على المنتجات المتوافقة مع نظام التشغيل Android. للاطّلاع على مراجعة حول أمان Android وتوافقه وأنظمة الإنشاء، يُرجى الاطّلاع على ما يلي:
- تأمين جهاز Android
- تحديثات الأمان والموارد
- مجموعة أدوات اختبار التوافق
- الأسماء الرمزية والعلامات وأرقام الإصدار
لمحة عن المركبات المتصلة (المنتجات الأساسية التي تبقى لفترة طويلة)
بدأت المركبات بالاتصال مع إدخال راديو AM في عشرينيات القرن الماضي. ومن ثم، بدأ عدد عمليات الاتصال الخارجية السلكية واللاسلكية في الازدياد عندما لجأ المشرّعون ومصنّعو السيارات إلى الأجهزة الإلكترونية لتسهيل عمليات التشخيص والصيانة (مثل منفذ OBD-II) وتحسين السلامة (مثل نظام مراقبة ضغط الإطارات) وتحقيق أهداف استهلاك الوقود. في الموجة التالية من تقنيات الاتصال، تم تقديم ميزات لتسهيل القيادة، مثل نظام الدخول بدون مفتاح عن بُعد وأنظمة الاتصالات عن بُعد، بالإضافة إلى ميزات متقدمة لنظام المعلومات والترفيه، مثل البلوتوث وشبكة Wi-Fi وميزة عرض شاشة الهاتف الذكي. في الوقت الحالي، توفّر أنظمة الأمان وأنظمة القيادة شبه المستقلة إمكانية استخدام أجهزة الاستشعار المدمجة وإمكانية الاتصال (مثل نظام تحديد المواقع العالمي).
مع زيادة عدد عمليات ربط المركبات، تزداد مساحة سطح المركبة التي يمكن أن تتعرض للهجوم. تؤدي اتصالات الأجهزة إلى ظهور مجموعة مماثلة من المخاوف المتعلقة بالأمان السيبراني كما هو الحال مع الأجهزة الإلكترونية المخصّصة للمستهلكين. ومع أنّ عمليات إعادة التشغيل وتحديثات الرموز البرمجية اليومية والسلوكيات غير المُفترَضة هي أمر شائع في الأجهزة الإلكترونية الاستهلاكية، إلا أنّها غير متّسقة في المنتجات التي تتضمّن أنظمة بالغة الأهمية للسلامة، مثل المركبات.
على المصنّعين اتّخاذ نهج استباقي لضمان استمرار أمان وسلامة المنتج في الميدان. باختصار، يجب أن تكون الشركات المصنّعة على دراية بثغرات الأمان المعروفة في المنتج وأن تتّخذ نهجًا يستند إلى المخاطر لمعالجتها.
ضمان الأمان على المدى الطويل
غالبًا ما تحتوي المركبات المتصلة على وحدة تحكّم إلكترونية واحدة أو أكثر تتضمّن عدة مكونات برامج، مثل نظام التشغيل والمكتبات والأدوات وغيرها. على المصنّعين تتبُّع هذه المكونات وتحديد الثغرات الأمنية المنشورة المعروفة من خلال التحليل الاستباقي، بما في ذلك:
- تقييم المنتج بانتظام وفقًا لقاعدة بيانات الثغرات والمخاطر الأمنية الشائعة (CVE)
- جمع المعلومات عن الثغرات الأمنية المرتبطة بالمنتجات
- اختبار الأمان
- تحليل نشرات أمان Android بشكل نشط
أمثلة على تحديثات نظام التشغيل ورموز تصحيح الأمان (لأجهزة IVI التي تعمل بنظام التشغيل Android):
الشكل 1: مثال على طرح تحديثات الأمان ونظام التشغيل الرئيسية على مدار مدة استخدام المركبة
| # | الخطوة | الأنشطة |
|---|---|---|
|
① |
قسم التطوير | تختار الشركة المصنّعة إصدار Android (Android X). في هذا المثال، يصبح "Android X" أساسًا لما سيتم شحنه في السيارة قبل عامين من بدء الإنتاج الأولي (SOP). |
| ② | الإطلاق الأولي | قبل بضعة أشهر من توفّر الإصدار X من نظام التشغيل Android كأول إصدار يتم تضمينه في المنتج، يتم الحصول على تحديثات الأمان
من نشرات أمان Android (ASB) ومصادر أخرى قد يراها المصنّع مفيدة. السنة 2 = نشرة الأمان الثانية للإصدار X من Android،
التي طبّقتها الشركة المصنّعة (أعادت استخدامها) على الإصدار X من Android. يتم شحن هذا التحديث في المنتج ويُطلق عليه "السنة صفر"، ويبدأ العد التنازلي للإصدار العلني في العام صفر مع الإصدار Android X.y2.
في هذا المثال، اتّخذت الشركة المصنّعة قرار عدم شحن الإصدار السنوي الأحدث من Android X+1. تشمل أسباب طرح أحدث إصدار إضافة ميزات جديدة ومعالجة الثغرات الأمنية الجديدة و/أو طرح خدمات Google أو الخدمات التابعة لجهات خارجية التي تتطلّب إصدار Android الأحدث. تتمثل أسباب عدم الشحن باستخدام أحدث إصدار في عدم توفّر الوقت اللازم لعملية تطوير المركبة وإطلاقها، والتي تتطلّب دمج التغييرات واختبارها والتحقق من صحتها، بما في ذلك الامتثال لجميع المتطلبات التنظيمية وشهادات الاعتماد. |
| ③ | تحديث كامل لنظام التشغيل | بعد انتهاء فترة الضمان، تُصدر الشركة المصنّعة تحديثًا لنظام التشغيل Android X+2، أي إصدارَي Android
بعد الإصدار المستخدَم في المنتج الأوّلي (Android X0). تتوفّر تحديثات الأمان لبرنامج ASB
لمستوى واجهة برمجة التطبيقات (اعتبارًا من تاريخ الشحن)، لذلك يتم طرح التحديث على شكل X+2.y0 بعد 1.25
عام تقريبًا من تاريخ الطرح. قد يكون تحديث نظام التشغيل هذا متوافقًا مع المنتجات التي تم طرحها أو لا يكون متوافقًا معها. إذا كان الأمر كذلك،
يمكن إنشاء خطة لتعديل المركبات المُستخدَمة.
ما لم يتم إبرام اتفاقيات تجارية أخرى، يكون قرار إجراء تحديث كامل لنظام التشغيل كليًا حسب تقدير الشركة المصنّعة. |
| ④ | تحديث الأمان | بعد مرور عامين على بدء إنتاج السيارة، تُصدر الشركة المصنّعة تصحيحات لنظام التشغيل
Android X+2. يستند هذا القرار إلى تقييم المخاطر الذي تجريه الشركة المصنّعة. تختار الشركة المصنّعة
تحديث الأمان الثالث لبرنامج ASB للإصدار X+2 كأساس للتحديث. المنتجات التيتلقّى تحديث الأمان متوفّرة الآن بنظام التشغيل (X+2.y3) ومستوى رمز تصحيح أمان Android.
على الرغم من أنّه يمكن للمصنعين اختيار تصحيحات أمان فردية من أي نشرة ASB فردية، عليهم حلّ جميع المشاكل المطلوبة في النشرة لاستخدام مستوى تصحيح أمان Android (SPL) المرتبط بالنشرة (على سبيل المثال، 2017-02-05). تقع على عاتق الشركة المصنّعة مسؤولية إجراء عملية النقل إلى الإصدارات القديمة وإصدار الأمان للمنتج المتوافق. |
| ⑤ | تحديث كامل لنظام التشغيل | تكرار الخطوة 3 (تحديث كامل لنظام التشغيل)، يؤدي التحديث الكامل الثاني لنظام التشغيل إلى ترقية المنتج إلى
Android X+4 بعد مرور ثلاث سنوات على بدء إنتاج المركبة. توازن الشركة المصنّعة الآن
بين متطلبات الأجهزة الجديدة لإصدار Android حديث وتلك الخاصة بالأجهزة في
المنتج، ويستفيد المستخدم من نظام التشغيل Android المُحدَّث. تُصدر الشركة المصنّعة تحديثًا
بدون تحديثات أمان، وبالتالي أصبح المنتج الآن يعمل بالإصدار (X+4.y0) من نظام التشغيل + مستوى رمز تصحيح أمان Android.
في هذا المثال، بسبب قيود الأجهزة، فإنّ X+4 هو آخر إصدار رئيسي من Android سيتم توفيره لهذا المنتج، على الرغم من أنّ عمر المركبة المتوقع الذي يتجاوز 6 سنوات لا يزال يتطلّب توفير ميزات الأمان. |
| ⑥ | تحديث الأمان | تكرار الخطوة 4 (تحديث الأمان) على الشركة المصنّعة الحصول على تحديثات أمان ASB من إصدار أحدث من نظام Android (X+6) ونقل بعض هذه التحديثات أو جميعها مرة أخرى إلى الإصدار X+4 من Android. تقع على عاتق الشركة المصنّعة مسؤولية دمج التعديلات ودمجها وتنفيذها (أو التعاقد مع جهة خارجية). يجب أن تكون الشركة المصنّعة على دراية بأنّه لا يتم تغطية مشاكل الأمان في إصدارات Android التي لم تعُد متوافقة في ASB. |
| ⑦ | تحديث الأمان | بعد مرور ثماني سنوات على بدء دورة إنتاج المركبة، وإصدار أربعة إصدارات من Android منذ آخر تحديث لنظام التشغيل في الخطوة 5 (تحديث كامل لنظام التشغيل)، وعشر سنوات منذ تحديد Android X، يقع عبء تنظيم وإعادة استخدام الرموز البرمجية لإصلاحات الأمان بالكامل على عاتق الشركة المصنّعة لهذه الإصدارات التي مرّ عليها أكثر من ثلاث سنوات من الإصدار العلني على مستوى واجهة برمجة التطبيقات. |
أفضل ممارسات الأمان
ولتصعيب عمليات اختراق الأمان، تنصح Google باستخدام أفضل الممارسات المقبولة بشكل عام في مجال الأمان وهندسة البرامج، كما هو موضّح في مقالة تنفيذ الأمان.
إرشادات الأمان
تشمل الممارسات المقترَحة لتعزيز الأمان ما يلي:
- استخدِم أحدث إصدارات المكتبات الخارجية ومكونات البرامج المفتوحة المصدر.
- لا تُدرِج وظيفة تصحيح الأخطاء المزعجة في إصدارات نظام التشغيل العلنية.
- إزالة الوظائف غير المستخدَمة (لتقليل الأجزاء المُعرَّضة للهجوم غير الضرورية)
- اتّبِع مبدأ الحدّ الأدنى من الأذونات المميّزة وغيرها من أفضل الممارسات لتطوير تطبيقات Android.
إرشادات تطوير البرامج
تشمل الممارسات المقترَحة لتطوير البرامج الآمنة لمراحل حياة النظام ما يلي:
- يمكنك إجراء عملية نمذجة للتهديدات من أجل ترتيب أصول البيانات والتهديدات والإجراءات المحتملة للتخفيف من حدّتها وتحديدها.
- إجراء مراجعة للبنية/التصميم لضمان تصميم آمن وموثوق
- عليك إجراء مراجعات منتظمة للرمز البرمجي لتحديد الأنماط المضادة والأخطاء في أقرب وقت ممكن.
- تصميم اختبارات الوحدة ذات التغطية العالية للرمز البرمجي وتنفيذها وتشغيلها، بما في ذلك:
- الاختبار الوظيفي (بما في ذلك حالات الاختبار السلبية)
- اختبار الرجوع إلى الخلف بانتظام (لضمان عدم ظهور الأخطاء التي تم إصلاحها مرة أخرى)
- اختبار التداخل (كجزء من مجموعة اختبارات الوحدة)
- استخدِم أدوات تحليل الرموز المصدر الثابتة (مثل scan-build وlint وما إلى ذلك) لتحديد المشاكل المحتمَلة.
- استخدِم أدوات تحليل الرموز البرمجية الديناميكية، مثل AddressSanitizer وUndefinedBehaviorSanitizer وFORTIFY_SOURCE (للمكونات الأصلية) لتحديد المشاكل المحتمَلة والحدّ منها أثناء تطوير النظام.
- أن يكون لديك استراتيجية إدارة لرمز المصدر للبرامج وإعدادات/إصدارات الإصدار
- أن تتوفّر لديك استراتيجية لإدارة التصحيحات لإنشاء تصحيحات البرامج ونشرها
سياسة إعادة استخدام ميزات الأمان
توفّر Google حاليًا دعمًا نشطًا لعمليات إضافة الأمان إلى الإصدارات السابقة من مستويات واجهة برمجة التطبيقات التي تم رصد ثغراتها الأمنية والإبلاغ عنها لمدة ثلاث سنوات من تاريخ الإصدار العلني. يتألف الدعم النشط من العناصر التالية:
- تلقّي تقارير الثغرات الأمنية والتحقيق فيها
- إنشاء تحديثات الأمان واختبارها وإصدارها
- توفير إصدارات متكرّرة من تحديثات الأمان وتفاصيل نشرات الأمان
- إجراء تقييم لدرجة الخطورة وفقًا للإرشادات المتّبعة
بعد مرور ثلاث سنوات من تاريخ الإصدار العلني لمستوى واجهة برمجة التطبيقات، تنصح Google باتّباع التوجيهات التالية:
- استخدام جهة خارجية (مثل موفِّر شرائح المعالجة المتقدّمة أو موفِّر نظام التشغيل) للحصول على دعم لعمليات النقل الرجعي لتحديثات أمان نظام التشغيل التي مرّ عليها أكثر من ثلاث سنوات من تاريخ إصدار واجهة برمجة التطبيقات
- استخدام جهة خارجية لإجراء مراجعات للرمز البرمجي باستخدام أدوات تحليل السلوك الإعلاني المتاحة للجميع في حين أنّ تقارير ASBs تحدد نقاط الضعف في الإصدار المتوافق حاليًا، يمكن للشركة المصنّعة استخدام المَعلومات المقدَّمة لمقارنة التحديثات التي تم إصدارها حديثًا بالإصدارات السابقة. ويمكن استخدام هذه البيانات للقيام بتحليل للتأثير وربما إنشاء تصحيحات مشابهة لإصدارات نظام التشغيل التي مرّ عليها أكثر من ثلاثة أعوام من تاريخ إصدار واجهة برمجة التطبيقات.
- تحميل تحديثات الأمان إلى "مشروع Android المفتوح المصدر" (AOSP) عند الاقتضاء
- على الشركة المصنّعة تنسيق معالجة تحديثات الأمان للرمز الخاص بالمورّد (على سبيل المثال، الرمز الخاص بالجهاز المملوك).
- على الشركة المصنّعة الانضمام إلى مجموعة إشعارات معاينة الشركاء لنشرات أمان Android التي تتضمّن اتفاقية عدم الإفصاح (يتطلب ذلك توقيع اتفاقيات قانونية، مثل اتفاقية عدم الإفصاح بين المطوّرين). يجب أن تشمل النشرات
ما يلي:
- الإشعارات
- ملخّص للمشاكل حسب مستوى التصحيح، بما في ذلك CVE وشدة الخطورة
- تفاصيل الثغرة الأمنية عند الاقتضاء
مراجع إضافية
للحصول على تعليمات حول ممارسات الترميز الآمن وتطوير البرامج، يُرجى الرجوع إلى ما يلي:
- جمعية موثوقية برمجيات الصناعة المتعلّقة بالمحركات (MISRA)
- أدوات وطرق معهد هندسة البرامج (SEI)
- المعهد الوطني للمعايير والتكنولوجيا (NIST)
الممارسات المقترَحة للمنتجات
ننصح في Google باستخدام الممارسات المقترَحة التالية.
إرشادات عامة حول الإطلاق
ننصح بشكل عام بإطلاق أي منتج متصل باستخدام أحدث إصدار من نظام التشغيل، ويجب أن تحاول الشركة المصنّعة استخدام أحدث إصدار من نظام التشغيل قبل إطلاق المنتج. على الرغم من أنّ قفل الإصدار ضروري لتعزيز الاستقرار قبل الاختبار والتحقق، يجب أن يوازن المصنّع بين استقرار المنتج الذي يحصل عليه من إصدارات نظام التشغيل القديمة وإصدارات نظام التشغيل الأحدث التي تتضمن عددًا أقل من الثغرات الأمنية المعروفة ووسائل حماية أمان محسّنة.
تشمل الإرشادات المقترَحة ما يلي:
- بسبب المُدد الزمنية الطويلة لعملية تطوير المركبات، قد تحتاج الشركات المصنّعة إلى طرح الإصدار باستخدام الإصدار n-2 من نظام التشغيل أو إصدار أقدم.
- الحفاظ على التوافق مع Android لكل إصدار من نظام التشغيل Android تم طرحه من خلال حملة عبر الهواء (OTA)
- يجب أن يكون المنتج متوافقًا مع ميزة "تحديث البرامج الثابتة لنظام التشغيل Android عبر الهواء" (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). يمكن أن تُحدِّث إصدارات Android الجديدة مجموعة اختبار التوافق (CTS) من خلال إصلاح الأخطاء وإجراء التحسينات وإضافة اختبارات جديدة. تحقّق من عمليات تنزيل مجموعة أدوات اختبار التوافق (CTS) بشكل متكرّر وعدِّل برنامج CTS حسب الحاجة. على الشركة المصنّعة وGoogle الاتفاق على إصدار CTS الذي يجب أن يُقبل لإطلاق المنتج، لأنّه يجب تجميد المنتج في مرحلة معيّنة مع مواصلة تحديث CTS.
اجتياز CTS
بالنسبة إلى المنتجات المتوافقة مع Android، تضمن Google قبول نتائج اختبارات CTS وتقارير أداة التحقّق من CTS الخاصة بالجهاز. من المفترض أن تجتاز جميع الاختبارات. ومع ذلك، يخضع الاختبار الذي يتعذّر إكماله لعدة أسباب غير عدم امتثال الجهاز لمتطلبات التوافق مع Android لمراجعة Google. خلال هذه العملية:
- توفّر الشركة المصنّعة لشركة Google تصحيحات CTS المقترَحة وعمليات التحقّق من التصحيحات و التبريرات لإثبات صحة النقاش.
- تفحص Google المواد المرسَلة، وفي حال قبولها، تعدّل اختبارات CTS ذات الصلة لكي يجتاز الجهاز المراجعة التالية من CTS.
إذا تعذّر اجتياز أحد اختبارات CTS فجأة بعد تطبيق تصحيح أمان، على الشركة المصنّعة تعديل التصحيح لكي لا يؤدي إلى إيقاف التوافق أو إظهار أنّ الاختبار غير صحيح وتقديم حلّ ل الاختبار (على النحو الموضّح أعلاه).
سيظل CTS مفتوحًا لمراجعات الإصلاحات الاختبارية. على سبيل المثال، يستمر نظام التشغيل Android 4.4 في قبول الإصلاحات (راجِع https://android-review.googlesource.com/#/c/273371/).
الأسئلة الشائعة
س: من المسؤول عن تطبيق تحديثات الأمان على إصدار معيّن من Android؟
ج: تتحمّل الشركة المصنّعة للجهاز مباشرةً مسؤولية ذلك. هذا الكيان ليس Google، التي تنشر تحديثات الأمان في AOSP وليس لجهاز معيّن (مثل مركبة).
س: كيف تتعامل Google مع مشاكل الأمان في Android؟
ج: تحقّق Google باستمرار من المشاكل وتعمل على تطوير حلول محتملة، وهي حلول توفّرها Google لجميع مستويات واجهات برمجة التطبيقات المتوافقة كجزء من عملية تحديث الأمان العادية. منذ آب (أغسطس) 2015، حافظت Google على وتيرة منتظمة لنشر النشرات والروابط التي تؤدي إلى التحديثات على source.android.com، كما تنشر Google تحديثات الأمان كجزء من إصدارات نظام التشغيل الرئيسية. يمكنك أيضًا الاطّلاع على سياسة إعادة استخدام ميزات الأمان في الإصدارات القديمة.
س: إذا دمج المصنّع جميع تصحيحات AOSP من ASB ولكنّه لم يدمج التصحيحات من موفّر BSP المذكور في النشرة نفسها، هل سيظل بإمكانه رفع مستوى الأمان (على سبيل المثال، تطبيق التصحيح المقابل على النظام الأساسي/الإصدار)؟
ج: لإعلان مستوى رمز تصحيح أمان Android (SPL)، على المصنّع معالجة جميع الصعوبات المطلوبة التي تم نشرها في نشرة أمان Android (بما في ذلك النشرات السابقة) وربطها بمستوى رمز تصحيح أمان Android معيّن. على سبيل المثال، إذا كانت الشركة المصنّعة تستخدم نشرة الأمان الصادرة في آذار (مارس) 2017 (SPL 01-03-2017)، يجب أن تكون قد عالجت جميع المشاكل المطلوبة الموثَّقة في نشرة آذار (مارس) 2017 الخاصة بهذه الحزمة وجميع التحديثات السابقة، بما في ذلك التحديثات الخاصة بالأجهزة لجميع نشرات أمان Android السابقة، بما في ذلك التحديثات الخاصة بالأجهزة المرتبطة بالحزمة SPL 05-02-2017.
س: ماذا يحدث عندما لا توافق الشركة المصنّعة على تحديثات الأمان التي يوفّرها موفّر BSP أو عندما لا يوفّر المورّدون تحديثات الأمان التي يفرضها معيار ASB؟
ج: يصف ASB الثغرات الأمنية (المُدرَجة في قائمة الثغرات الأمنية الشائعة) ويقدّم غالبًا اختبارات أمان مطابقة. والهدف من ذلك هو التأكّد من أنّه لم يعُد بإمكان أحدٍ إعادة إنتاج الثغرات الأمنية المُدرَجة على الجهاز وأنّه يمكن للجهاز اجتياز اختبارات الأمان المرتبطة بها. وبالتالي، لا تتعلّق المشكلة بتلقّي تحديث أمان تقدّمه Google أو مورّد خارجي، بل تتعلّق بشهادة الشركة المصنّعة التي تشهد على أنّ الجهاز ليس عرضة لقائمة نقاط ضعف CVE في ASB. يحقّ للمصنّع استخدام تحديثات الأمان المقدَّمة أو استخدام تغيير بدلاً منها إذا كان أكثر ملاءمةً لجهازه.
على سبيل المثال، لنفترض أنّ Google تعالج ثغرة أمنية في AOSP باستخدام تغيير في الرمز البرمجي يسمح للمكوّن بمواصلة العمل بشكل كامل ومتوافق مع CDD. إذا اعتبرت الشركة المصنّعة أنّ المكوّن غير مطلوب في الجهاز أو أنّه غير مطلوب بموجب CDD (أو اختبار الاعتماد المرتبط)، يمكن للشركة المصنّعة إزالة المكوّن لتقليل احتياجات الصيانة في المستقبل والحدّ من الأجزاء المعرضة للهجوم. على الرغم من أنّ الشركة المصنّعة لم تستخدم تحديث الأمان المقدَّم، تأكّدت من أنّ الجهاز ليس عرضة للاختراق من خلال ثغرة CVE المُسجَّلة في نشرة الأمان. ومع ذلك، عند الانحراف عن تحديث الأمان المقترَح، يخاطر المصنّع بمعالجة المشكلة بشكلٍ غير صحيح أو إدخال ثغرات أمنية جديدة أو تقليل وظائف الإصدار النهائي.
ونحن نعمل مع جميع شركاء شرائح المعالجة المركزية (SoC) لضمان توفّر إصلاحات لجميع المشاكل في ASB، وننصحك بأن يحصل المصنّعون على اتفاقية صيانة مع مورّدي شرائح المعالجة المركزية طوال دورة حياة الجهاز. قد تتوقف وحدات المعالجة المركزية المتكاملة عن توفير خدمة شرائح المعالجة في وقت أبكر من المطلوب، لذا فإنّ إبرام الاتفاقيات قبل اختيار شريحة المعالجة للجهاز هو جزء مهم من عملية إطلاق الجهاز.
أخيرًا، في الحالات التي يكون فيها من المستحيل الحصول على حلّ مباشر أو إنشاء حلّ مستقل لمشكلة تم توثيقها في ملف ASB، يمكن للشركة المصنّعة الاحتفاظ بملف Android SPL السابق مع إضافة الإصلاحات الجديدة المتاحة إلى الإصدار. ومع ذلك، ستؤدي هذه الممارسة في النهاية إلى حدوث مشاكل في عملية منح شهادة الاعتماد للإصدار (لأنّ نظام التشغيل Android يضمن توفُّر أحدث مستوى لرمز تصحيح الأمان على الأجهزة المعتمَدة). تنصح Google بالعمل مع فريق SoC مسبقًا لتجنُّب هذه الممارسة.
س: إذا تبيّن للشركة المصنّعة أنّ أحد عناصر ASB غير قابلة للتطبيق على منتجها، هل يجب تطبيق العنصر أو تصحيحه لاستيفاء متطلبات Google الأخرى أو اجتياز CTS؟
ج: لا نطلب إجراء تصحيحات للإعلان عن مستوى رمز تصحيح أمان Android (SPL)، ولكننا نطلب من الشركة المصنّعة أن تشهد بأنّ الإصدار الخاص بها ليس عرضةً لل المشكلة.
على سبيل المثال، عندما لا يتوفّر المكوّن الذي يتم تصحيحه في نظام الشركة المصنّعة، أو تتم إزالة المكوّن من نظام الشركة المصنّعة لحلّ مشكلة. وفي هذه الحالة، قد يكون النظام متوافقًا بدون الحاجة إلى أن تُجري الشركة المصنّعة تصحيحًا.
يختلف ذلك اختلافًا جذريًا عن رغبة الشركة المصنّعة، على سبيل المثال، في إصلاح التصحيحات العميقة فقط، مع عدم تطبيق التصحيحات الأخرى السارية التي قد تؤدي إلى تعذُّر اجتياز اختبار الأمان. في هذه الحالة، يُفترض أنّه لم يتم استيفاء الحدّ الأدنى لمستوى الخدمة.