يصف هذا الدليل أفضل الممارسات الموصى بها من Google لتطبيق تصحيحات الأمان التي يتم تقييمها بواسطة مجموعة اختبار توافق Android (CTS). إنه مخصص لمصنعي معدات OEM (الشركات المصنعة) المتوافقة مع Android والتي سيتم دعمها لفترة أطول من ثلاث سنوات مثل المركبات وأجهزة التلفزيون وأجهزة الاستقبال والأجهزة المنزلية. هذا الدليل غير مخصص للمستخدمين النهائيين (على سبيل المثال، أصحاب المركبات).
إقرارات وإخلاء المسؤولية
لا يُلزم هذا الدليل شركة Google أو الشركات المصنعة الأخرى قانونيًا أو تعاقديًا وليس المقصود منه أن يكون مجموعة من المتطلبات. بل إن هذا الدليل عبارة عن أداة تعليمية تصف الممارسات الموصى بها.
تعليق
ليس المقصود من هذا الدليل أن يكون شاملاً؛ ومن المقرر إجراء مراجعات إضافية. أرسل تعليقاتك إلى Manufacturer-guide-android@googlegroups.com.
قائمة المصطلحات
| شرط | تعريف |
|---|---|
| لجنة التنسيق الإدارية | التزام التوافق مع Android. كانت تُعرف سابقًا باسم اتفاقية مكافحة تجزئة Android (AFA). |
| AOSP | مشروع أندرويد مفتوح المصدر |
| ASB | نشرة أمان Android |
| بسب | حزمة دعم المجلس |
| العناية الواجبة | وثيقة تعريف التوافق |
| CTS | مجموعة اختبار التوافق |
| فوتا | البرامج الثابتة عبر الهواء |
| نظام تحديد المواقع | نظام تحديد المواقع العالمي |
| ميسرا | جمعية موثوقية برامج صناعة السيارات |
| نيست | المعهد الوطني للمعايير والتكنولوجيا |
| او بي دي | التشخيص على متن الطائرة ( OBD-II هو تحسين مقارنة بـOBD-I في كل من القدرة والتوحيد القياسي ) |
| تصنيع المعدات الأصلية | مصنع للأدوات الأصلية |
| نظام التشغيل | نظام التشغيل |
| SEI | معهد هندسة البرمجيات |
| شركة نفط الجنوب | النظام على الشريحة |
| إجراءات التشغيل القياسية | بداية الانتاج |
| SPL | مستوى تصحيح الأمان |
| نظام مراقبة ضغط الإطارات | نظام مراقبة ضغط الهواء في الإطارات |
حول نظام التشغيل أندرويد
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، راجع ما يلي:
- تأمين جهاز أندرويد
- التحديثات والموارد الأمنية
- مجموعة اختبار التوافق
- الأسماء الرمزية والعلامات وأرقام البناء
حول المركبات المتصلة (المنتجات الأساسية طويلة العمر)
بدأ ربط المركبات مع إدخال راديو AM في عشرينيات القرن الماضي. ومن هنا، بدأ عدد الاتصالات المادية واللاسلكية الخارجية في النمو مع تحول الهيئات التنظيمية وشركات صناعة السيارات إلى الإلكترونيات لتسهيل التشخيص والخدمة (على سبيل المثال، منفذ OBD-II)، وتحسين السلامة (على سبيل المثال، TPMS)، وتحقيق أهداف الاقتصاد في استهلاك الوقود. . قدمت الموجة التالية من الاتصال ميزات راحة السائق مثل الدخول عن بعد بدون مفتاح، وأنظمة الاتصالات عن بعد، وميزات المعلومات والترفيه المتقدمة مثل Bluetooth، وWi-Fi، وعرض الهاتف الذكي. واليوم، تدعم أجهزة الاستشعار المدمجة ووسائل الاتصال (على سبيل المثال نظام تحديد المواقع العالمي) أنظمة السلامة والقيادة شبه الذاتية.
ومع زيادة عدد وصلات المركبات، تزداد أيضًا مساحة سطح الهجوم المحتمل للمركبة. تجلب الاتصالات معها مجموعة مماثلة من مخاوف الأمن السيبراني كما هو الحال بالنسبة للإلكترونيات الاستهلاكية. ومع ذلك، على الرغم من أن عمليات إعادة التشغيل وتحديثات التصحيح اليومية والسلوكيات غير المبررة هي القاعدة بالنسبة للإلكترونيات الاستهلاكية، إلا أنها غير متسقة مع المنتجات ذات الأنظمة الحيوية للسلامة مثل المركبات.
يجب على الشركات المصنعة اتخاذ نهج استباقي لضمان استمرار وضع الأمن والسلامة للمنتج في الميدان. باختصار، يجب على الشركات المصنعة أن تكون على دراية بالثغرات الأمنية المعروفة في المنتج وأن تتخذ نهجًا قائمًا على المخاطر لمعالجتها.
ضمان الأمن على المدى الطويل
غالبًا ما تحتوي السيارة المتصلة على وحدة تحكم إلكترونية واحدة أو أكثر (ECUs) تتضمن مكونات برمجية متعددة مثل نظام التشغيل والمكتبات والأدوات المساعدة وما إلى ذلك. ويجب على الشركات المصنعة تتبع هذه المكونات وتحديد نقاط الضعف المعروفة المنشورة من خلال التحليل الاستباقي، بما في ذلك:
- تقييم المنتج بانتظام مقابل قاعدة بيانات نقاط الضعف والتعرض الشائعة (CVE).
- جمع المعلومات الاستخبارية عن العيوب الأمنية المتعلقة بالمنتج.
- اختبار الأمان.
- تحليل نشرات أمان Android بنشاط.
مثال على تحديثات نظام التشغيل وتصحيح الأمان (أجهزة IVI التي تعمل بنظام التشغيل Android):
الشكل 1. عينة من التحديثات الرئيسية لنظام التشغيل والأمان على مدار عمر السيارة.
| # | خطوة | أنشطة |
|---|---|---|
① | فرع التطوير | تختار الشركة المصنعة إصدار Android (Android X). في هذا المثال، يصبح "Android X" أساسًا لما سيتم شحنه في السيارة قبل عامين من بدء الإنتاج الأولي (SOP). |
| ② | الإطلاق الأولي | قبل بضعة أشهر من أن يصبح Android X أول إصدار لنظام التشغيل يتم تضمينه في المنتج، يتم أخذ التحديثات الأمنية من Android Security Bulletins (ASBs) ومن المحتمل أن تكون مصادر أخرى تعتبرها الشركة المصنعة ذات قيمة. y2 = نشرة الأمان الثانية للإصدار X من Android، والتي تم تطبيقها (بنقل خلفي) من قبل الشركة المصنعة على Android X. يأتي هذا التحديث في المنتج وتبدأ ساعة الإنتاج في العام صفر مع Android X.y2. في هذا المثال، اتخذت الشركة المصنعة قرارًا بعدم شحن الإصدار السنوي الأحدث من Android X+1. تتضمن أسباب شحن الإصدار الأحدث إضافة ميزات جديدة، ومعالجة الثغرات الأمنية الجديدة، و/أو شحن خدمات Google أو الجهات الخارجية التي تتطلب الإصدار الأحدث من Android. الأسباب التي تمنع الشحن باستخدام أحدث إصدار هي قلة الوقت الملازم لعملية تطوير السيارة وإطلاقها اللازمة لدمج التغييرات واختبارها والتحقق من صحتها، بما في ذلك الامتثال لجميع المتطلبات التنظيمية ومتطلبات الشهادات. |
| ③ | تحديث نظام التشغيل الكامل | بعد إجراء SOP، تقوم الشركة المصنعة بإصدار تحديث لنظام التشغيل Android X+2، وهو إصداران من Android بعد الإصدار المستخدم للمنتج الأولي (Android X0). تتوفر تحديثات أمان ASB لمستوى واجهة برمجة التطبيقات (اعتبارًا من تاريخ الشحن)، لذا يتم إصدار التحديث كـ X+2.y0 بعد 1.25 سنة تقريبًا من إجراء التشغيل المعياري (SOP). قد يكون تحديث نظام التشغيل هذا متوافقًا أو غير متوافق مع المنتجات الميدانية. إذا كان الأمر كذلك، فيمكن إنشاء خطة لتحديث المركبات المنتشرة. وما لم تكن هناك اتفاقيات عمل أخرى، فإن قرار إجراء تحديث كامل لنظام التشغيل يكون وفقًا لتقدير الشركة المصنعة تمامًا . |
| ④ | التحديث الأمني | بعد عامين من عمر إنتاج السيارة، قامت الشركة المصنعة بتصحيح نظام التشغيل Android X+2. يعتمد هذا القرار على تقييم المخاطر الخاص بالشركة المصنعة. تختار الشركة المصنعة التحديث الأمني ASB الثالث للإصدار X+2 كأساس للتحديث. المنتجات التي تتلقى التحديث الأمني موجودة الآن في مستوى (X+2.y3) OS + Android Security Patch. بينما يمكن للشركات المصنعة تحديد تصحيحات أمان فردية من أي ASB فردي، يجب عليها إصلاح جميع المشكلات المطلوبة في النشرة لاستخدام مستوى تصحيح أمان Android (SPL) المرتبط بالنشرة (على سبيل المثال، 05-02-2017). تقع على عاتق الشركة المصنعة مسؤولية تنفيذ الإصدار الخلفي والأمان للمنتج المدعوم. |
| ⑤ | تحديث نظام التشغيل الكامل | تكرار الخطوة 3 (التحديث الكامل لنظام التشغيل)، التحديث الكامل الثاني لنظام التشغيل يعمل على رفع المنتج إلى Android X+4، بعد ثلاث سنوات من عمر إنتاج السيارة. تعمل الشركة المصنعة الآن على موازنة متطلبات الأجهزة الأحدث لإصدار Android الحديث مع الأجهزة الموجودة في المنتج ويستفيد المستخدم من نظام التشغيل Android المحدث. تقوم الشركة المصنعة بإصدار تحديث بدون تحديثات أمنية، وبالتالي فإن المنتج الآن في مستوى (X+4.y0) OS + Android Security Patch Level. في هذا المثال، نظرًا لقيود الأجهزة، يعد X+4 هو الإصدار الرئيسي الأخير من Android الذي سيتم توفيره لهذا المنتج، على الرغم من أن العمر المتوقع للمركبة يزيد عن 6 سنوات لا يزال يتطلب دعمًا أمنيًا. |
| ⑥ | التحديث الأمني | تكرار الخطوة 4 (التحديث الأمني). تتولى الشركة المصنعة مهمة أخذ تحديثات أمان ASB من إصدار أحدث بكثير من Android (X+6) وإعادة بعض أو كل هذه التحديثات إلى Android X+4. وتقع على عاتق الشركة المصنعة مسؤولية دمج التحديثات وتكاملها وتنفيذها (أو التعاقد مع جهة خارجية). وأيضًا، يجب أن تدرك الشركة المصنعة أن مشكلات الأمان في إصدارات Android التي لم تعد مدعومة لا يتم تناولها في ASB. |
| ⑦ | التحديث الأمني | بعد مرور ثماني سنوات على دورة حياة إنتاج السيارة، وأربعة إصدارات لنظام التشغيل Android منذ آخر تحديث لنظام التشغيل في الخطوة 5 (التحديث الكامل لنظام التشغيل)، وعشر سنوات منذ تحديد Android X، يقع عبء تنظيم التصحيحات الأمنية ونقلها بالكامل على عاتق الشركة المصنعة تلك الإصدارات الأقدم من ثلاث سنوات من الإصدار العام لمستوى واجهة برمجة التطبيقات (API). |
أفضل الممارسات الأمنية
ولجعل التسويات الأمنية أكثر صعوبة، توصي Google وتستخدم أفضل الممارسات المقبولة عمومًا للأمان وهندسة البرمجيات، كما هو موضح في تنفيذ الأمان .
المبادئ التوجيهية الأمنية
تشمل الممارسات الموصى بها للأمان ما يلي:
- استخدام أحدث الإصدارات من المكتبات الخارجية والمكونات مفتوحة المصدر.
- لا تقم بتضمين وظيفة تصحيح الأخطاء المتطفلة في إصدارات إصدار نظام التشغيل.
- إزالة الوظائف غير المستخدمة (لتقليل سطح الهجوم غير الضروري).
- استخدم مبدأ الامتياز الأقل وأفضل ممارسات تطوير تطبيقات Android الأخرى.
المبادئ التوجيهية لتطوير البرمجيات
تتضمن الممارسات الموصى بها لتطوير البرامج الآمنة طوال دورة حياة النظام ما يلي:
- إجراء نمذجة التهديدات لتصنيف وتحديد الأصول والتهديدات وعمليات التخفيف المحتملة.
- قم بإجراء مراجعة للهندسة المعمارية / التصميم لضمان تصميم آمن وسليم.
- قم بإجراء مراجعات منتظمة للتعليمات البرمجية لتحديد الأنماط المضادة والأخطاء في أسرع وقت ممكن.
- تصميم وتنفيذ وتشغيل اختبارات وحدة التغطية عالية الكود، بما في ذلك:
- الاختبارات الوظيفية (بما في ذلك حالات الاختبار السلبية)
- اختبار الانحدار المنتظم (لضمان عدم ظهور الأخطاء التي تم إصلاحها مرة أخرى)
- اختبار الزغب (كجزء من مجموعة اختبار الوحدة)
- استخدم أدوات تحليل كود المصدر الثابت (إنشاء المسح الضوئي، والوبر، وما إلى ذلك) لتحديد المشكلات المحتملة.
- استخدم أدوات تحليل التعليمات البرمجية المصدر الديناميكية، مثل AddressSanitizer وUnifiedBehaviorSanitizer وFORTIFY_SOURCE (للمكونات الأصلية) لتحديد المشكلات المحتملة وتخفيفها أثناء تطوير النظام.
- لديك استراتيجية إدارة للكود المصدري للبرنامج وتكوين/إصدار الإصدار.
- لديك إستراتيجية لإدارة التصحيح لإنشاء تصحيحات البرامج ونشرها.
سياسة backport الأمنية
توفر Google حاليًا دعمًا نشطًا للتقارير الأمنية للثغرات الأمنية المكتشفة والمبلغ عنها لمدة ثلاث (3) سنوات من الإصدار العام على مستوى واجهة برمجة التطبيقات . يتكون الدعم النشط مما يلي:
- تلقي تقارير الضعف والتحقيق فيها.
- إنشاء التحديثات الأمنية واختبارها وإصدارها.
- توفير الإصدارات المتكررة من التحديثات الأمنية وتفاصيل النشرة الأمنية.
- إجراء تقييم الخطورة وفقًا للمبادئ التوجيهية المعمول بها.
بعد ثلاث سنوات من تاريخ الإصدار العام على مستوى واجهة برمجة التطبيقات، توصي Google بالإرشادات التالية:
- استخدم جهة خارجية (مثل بائع SoC أو موفر Kernel) لدعم المنفذ الخلفي لتحديثات أمان نظام التشغيل الأقدم من ثلاث سنوات من إصدار API.
- استخدم جهة خارجية لإجراء مراجعات التعليمات البرمجية باستخدام ASBs المتوفرة بشكل عام. بينما تحدد ASBs الثغرات الأمنية للإصدار المدعوم حاليًا، قد تستخدم الشركة المصنعة المعلومات المقدمة لمقارنة التحديثات التي تم إصدارها حديثًا بالإصدارات السابقة. يمكن استخدام هذه البيانات لإجراء تحليل التأثير وربما إنشاء تصحيحات مماثلة لإصدارات نظام التشغيل الأقدم من ثلاث سنوات من إصدار واجهة برمجة التطبيقات (API).
- عندما يكون ذلك مناسبًا، قم بتحميل التحديثات الأمنية إلى Android Open Source Project (AOSP).
- يجب أن تقوم الشركة المصنعة بتنسيق معالجة التحديثات الأمنية للتعليمات البرمجية الخاصة بالمورد (على سبيل المثال، التعليمات البرمجية الخاصة بالجهاز).
- يجب أن تنضم الشركة المصنعة إلى مجموعة إشعارات Partner Preview لـ NDA Android Security Bulletin (يتطلب توقيع اتفاقيات قانونية مثل Developer NDA). يجب أن تتضمن النشرات ما يلي:
- الإعلانات
- ملخص المشكلات حسب مستوى التصحيح، بما في ذلك مكافحة التطرف العنيف وخطورته
- تفاصيل الضعف عند الاقتضاء
مراجع إضافية
للحصول على إرشادات حول ممارسات الترميز الآمن وتطوير البرامج، راجع ما يلي:
- جمعية موثوقية برمجيات صناعة السيارات (MISRA) .
- أدوات وأساليب معهد هندسة البرمجيات (SEI) .
- المعهد الوطني للمعايير والتكنولوجيا (NIST).
ممارسات المنتج الموصى بها
تشجع Google على استخدام الممارسات الموصى بها التالية.
المبادئ التوجيهية العامة للإطلاق
يوصى عمومًا بتشغيل أي منتج متصل بأحدث إصدار من نظام التشغيل، ويجب على الشركة المصنعة محاولة استخدام أحدث إصدار من نظام التشغيل قبل تشغيل المنتج. في حين أن تأمين الإصدار ضروري لتحقيق الاستقرار قبل الاختبار والتحقق من الصحة، يجب على الشركة المصنعة موازنة استقرار المنتج المكتسب من إصدارات نظام التشغيل الأقدم مع إصدارات نظام التشغيل الأحدث التي تحتوي على عدد أقل من الثغرات الأمنية المعروفة وحماية أمنية محسنة.
تتضمن الإرشادات الموصى بها ما يلي:
- نظرًا للفترات الزمنية الطويلة للتطوير والمتأصلة في عملية تطوير السيارة، قد تحتاج الشركات المصنعة إلى التشغيل باستخدام إصدار نظام التشغيل n-2 أو أقدم.
- حافظ على التوافق مع توافق Android لكل إصدار من إصدارات نظام التشغيل Android من خلال حملة عبر الهواء (OTA).
- تنفيذ منتج Android Firmware-over-the-air (FOTA) - القادر على إجراء تحديثات سريعة وصديقة للعملاء. يجب أن يتم تنفيذ FOTA باستخدام أفضل ممارسات الأمان مثل توقيع التعليمات البرمجية واتصال TLS بين المنتج والمكتب الخلفي لتكنولوجيا المعلومات.
- قم بإرسال الثغرات الأمنية التي تم تحديدها بشكل مستقل في Android إلى فريق Android Security.
ملاحظة: لقد فكرت Google في نوع الجهاز أو الإشعارات الخاصة بالصناعة في نشرات أمان Android. ومع ذلك، نظرًا لأن Google لا تعرف النواة أو برامج التشغيل أو مجموعات الشرائح لجهاز معين (مركبة أو تلفزيون أو جهاز يمكن ارتداؤه أو هاتف وما إلى ذلك)، فليس لدى Google طريقة محددة لتصنيف أي مشكلة أمنية معينة مع نوع الجهاز .
المبادئ التوجيهية لدورة المنتج
يجب على الشركة المصنعة بذل كل محاولة لاستخدام أحدث إصدار من نظام التشغيل أو التحديثات الأمنية للإصدار المستخدم أثناء تحسينات دورة المنتج. يمكن إجراء التحديثات أثناء تحديثات المنتج الدورية المتكررة، أو للإصلاحات العاجلة لمعالجة مشكلات الجودة و/أو المشكلات الأخرى. تشمل الممارسات الموصى بها ما يلي:
- قم بإنشاء خطة لمعالجة تحديثات برنامج التشغيل والنواة والبروتوكول.
- استخدم طريقة مناسبة للصناعة لتوفير التحديثات للمركبات المنتشرة.
مستند تعريف التوافق (CDD)
تصف وثيقة تعريف التوافق (CDD) متطلبات الجهاز الذي يعتبر متوافقًا مع Android. إن CDD عام ومتاح للجميع؛ يمكنك تنزيل إصدارات CDD من Android 1.6 إلى الإصدار الأحدث من source.android.com .
تتضمن تلبية هذه المتطلبات للمنتج الخطوات الأساسية التالية:
- يوقع الشريك على التزام توافق Android (ACC) مع Google. يتم بعد ذلك تعيين مستشار الحلول التقنية (TSC) كدليل.
- يكمل الشريك مراجعة CDD لإصدار نظام التشغيل Android الخاص بالمنتج.
- يقوم الشريك بتشغيل نتائج CTS وإرسالها (الموضحة أدناه) حتى تصبح النتائج مقبولة للتوافق مع Android.
مجموعة اختبار التوافق (CTS)
تتحقق أداة اختبار Compatibility Test Suite (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. خلال هذه العملية:
- تزود الشركة المصنعة 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 SPL معين. على سبيل المثال، قامت الشركة المصنعة التي تستخدم نشرة الأمان لشهر مارس 2017 (2017-03-01 SPL) بمعالجة جميع المشكلات المطلوبة الموثقة في نشرة مارس 2017 الخاصة بـ SPL وجميع التحديثات السابقة بما في ذلك التحديثات الخاصة بالجهاز لجميع نشرات أمان Android السابقة، بما في ذلك التحديثات الخاصة بالجهاز المرتبطة بـ 2017-02-05 SPL.
س: ماذا يحدث عندما لا توافق الشركة المصنعة على التحديثات الأمنية المقدمة من بائع BSP أو عندما لا يتم توفير التحديثات الأمنية التي يفرضها ASB من قبل البائعين؟
ج: يصف ASB الثغرات الأمنية (التي تم تعدادها من خلال قائمة التهديدات الشائعة) وغالبًا ما يوفر اختبارات أمان مطابقة. الهدف هو التأكد من أنه لم يعد من الممكن إعادة إنتاج الثغرات الأمنية المدرجة على الجهاز وأن الجهاز يمكنه اجتياز اختبارات الأمان المرتبطة. على هذا النحو، لا تتعلق المشكلة بالحصول على تحديث أمني مقدم من Google أو بائع خارجي، ولكن تتعلق بشهادة الشركة المصنعة بأن الجهاز ليس عرضة لقائمة التهديدات الشائعة في ASB. تتمتع الشركة المصنعة بحرية استخدام التحديثات الأمنية المتوفرة، أو إذا كان لديها تغيير أكثر ملاءمة لأجهزتها، فاستخدم هذا التغيير بدلاً من ذلك.
على سبيل المثال، خذ بعين الاعتبار حالة قامت فيها Google بمعالجة ثغرة أمنية في AOSP باستخدام تغيير التعليمات البرمجية الذي يسمح للمكون بالبقاء يعمل بكامل طاقته ومتوافقًا مع CDD. إذا قررت الشركة المصنعة أن المكون غير مطلوب على الجهاز أو أنه غير مفوض من قبل CDD (أو اختبار الشهادات ذي الصلة)، فيمكن للشركة المصنعة إزالة المكون لتقليل احتياجات الخدمة المستقبلية وتقليل سطح الهجوم. على الرغم من أن الشركة المصنعة لم تستخدم التحديث الأمني المقدم، إلا أنها تأكدت من أن الجهاز ليس عرضة لـ CVE الموثق في نشرة الأمان. ومع ذلك، بالانحراف عن التحديث الأمني الموصى به، فإن الشركة المصنعة تخاطر بمعالجة المشكلة بشكل غير صحيح، أو تقديم ثغرات أمنية جديدة، أو تقليل وظائف الإصدار النهائي.
بينما نعمل مع جميع شركاء SoC لضمان وجود إصلاحات لجميع المشكلات في ASB، فإننا نوصي بأن تقوم الشركات المصنعة بتأمين اتفاقية خدمة مع موردي SoC الخاصين بها طوال دورة حياة الجهاز. قد تتوقف شركات نفط الجنوب عن خدمة مجموعة الشرائح في وقت أبكر مما هو مطلوب، لذا فإن إنشاء اتفاقيات قبل اختيار مجموعة شرائح الجهاز يعد جزءًا مهمًا من عملية تشغيل الجهاز.
أخيرًا، في الحالات التي يكون فيها من المستحيل الحصول على إصلاح لمشكلة موثقة في ASB بشكل مباشر أو إنشاءه بشكل مستقل، يمكن للشركة المصنعة الاحتفاظ بإصدار Android SPL السابق مع الاستمرار في إضافة الإصلاحات الجديدة المتاحة إلى الإصدار. ومع ذلك، ستؤدي هذه الممارسة في النهاية إلى مشكلات تتعلق بشهادة البناء (حيث يضمن Android توفر أحدث مستوى من التصحيح الأمني على الأجهزة المعتمدة). توصي Google بالعمل مع شركة نفط الجنوب الخاصة بك مسبقًا لتجنب هذه الممارسة.
س: إذا قررت الشركة المصنعة أن عنصر ASB غير قابل للتطبيق على منتجها، فهل لا يزال العنصر بحاجة إلى تطبيقه أو تصحيحه من أجل تلبية متطلبات Google الأخرى أو اجتياز CTS؟
ج: لا نطلب إجراء التصحيحات من أجل الإعلان عن مستوى تصحيح أمان Android (SPL)؛ نحن نطلب من الشركة المصنعة أن تشهد أن بنيتها ليست عرضة لهذه المشكلة.
أحد الأمثلة على ذلك هو عدم وجود مكون يتم تصحيحه في نظام الشركة المصنعة، أو تتم إزالة مكون من نظام الشركة المصنعة لمعالجة مشكلة ما. في هذه الحالة، قد يكون النظام متوافقًا دون مطالبة الشركة المصنعة بإجراء تصحيح.
ويختلف هذا اختلافًا جوهريًا عن رغبة الشركة المصنعة، على سبيل المثال، في إصلاح التصحيحات المهمة فقط، مع عدم استخدام تصحيحات أخرى قابلة للتطبيق والتي قد تتسبب في فشل اختبار الأمان. في هذه الحالة، يُفترض أنه لم يتم استيفاء SPL.