دليل الشركات المصنّعة للحفاظ على أمان Android على المدى الطويل

يوضّح هذا الدليل أفضل الممارسات التي تنصح بها Google لتطبيق حِزم الأمان التي يتم تقييمها من خلال "مجموعة أدوات اختبار التوافق" (CTS) في Android. وهي مخصّصة للشركات المصنّعة لمعدات OEM المتوافقة مع Android (المصنّعون) التي سيتم توفير الدعم لها لمدة تزيد عن ثلاث سنوات، مثل المركبات وأجهزة التلفزيون وأجهزة استقبال البث وأجهزة المنزل. لا يهدف هذا الدليل إلى استهداف المستخدمين النهائيين (مثل مالكي المركبات).

الإقرارات وبيانات إخلاء المسؤولية

لا يفرض هذا الدليل أي التزامات قانونية أو تعاقدية على Google أو الشركات المصنّعة الأخرى، ولا يهدف إلى أن يكون مجموعة من المتطلبات. بل إنّ هذا الدليل هو أداة تعليمية تصف الممارسات المقترَحة.

الملاحظات

هذا الدليل ليس شاملاً، ونحن نخطّط لإجراء مراجعات إضافية. يمكنك إرسال ملاحظاتك إلى manufacturers-guide-android@googlegroups.com.

مسرد المصطلحات

العبارة التعريف
ACC التزام التوافق مع Android يُعرف هذا الاتفاق سابقًا باسم "اتفاقية مكافحة التجزئة في Android"‏ (AFA).
مشروع مفتوح المصدر لنظام Android‏ (AOSP) مشروع مفتوح المصدر لنظام Android
ASB نشرة أمان Android
BSP حزمة دعم لوحة الجهاز
CDD مستند تعريف معايير التوافق
CTS مجموعة أدوات اختبار التوافق
FOTA البرامج الثابتة عبر شبكة غير سلكيّة
نظام تحديد المواقع العالمي (GPS) نظام تحديد المواقع العالمي
MISRA Motor Industry Software Reliability Association
المعهد الوطني للمعايير والتكنولوجيا (NIST) المعهد الوطني للمعايير والتكنولوجيا
OBD نظام التشخيص على متن المركبة (OBD-II هو تحسين لنظام OBD-I من حيث الإمكانات والتوحيد القياسي)
المصنّع الأصلي للجهاز المصنّع الأصلي للجهاز
نظام التشغيل نظام التشغيل
SEI معهد هندسة البرمجيات
منظومة على رقاقة (SoC) منظومة على رقاقة
إجراءات التشغيل المعيارية بداية الإنتاج
SPL مستوى رمز تصحيح الأمان
TPMS نظام مراقبة ضغط الإطارات

لمحة عن نظام التشغيل Android

‫Android هو حزمة برامج كاملة مفتوحة المصدر تستند إلى Linux ومصمَّمة لمجموعة متنوعة من الأجهزة وأحجامها. منذ إطلاقه لأول مرة في عام 2008، أصبح Android نظام التشغيل الأكثر انتشارًا، إذ يعمل على أكثر من 1.4 مليار جهاز في جميع أنحاء العالم (2016). يستخدم حوالي% 67 من هذه الأجهزة الإصدار Android 5.0 (Lollipop)‎ أو إصدارًا أحدث اعتبارًا من آذار (مارس) 2017 (تتوفّر أحدث الأرقام على لوحة بيانات Android). مع أنّ الغالبية العظمى من الأجهزة هي هواتف جوّالة وأجهزة لوحية، إلا أنّ Android يتوسّع ليشمل الساعات الذكية وأجهزة التلفزيون وأجهزة الترفيه داخل المركبات.

بلغ عدد تطبيقات Android المتاحة في "متجر Google Play" أكثر من 2.2 مليون تطبيق (2016). يستند تطوير تطبيقات Android إلى "برنامج التوافق مع Android" الذي يحدّد مجموعة من المتطلبات من خلال مستند تعريف التوافق (CDD) ويوفر أدوات الاختبار من خلال مجموعة أدوات اختبار التوافق (CTS). تضمن برامج التوافق مع Android إمكانية تشغيل أي تطبيق Android على أي جهاز متوافق مع Android ويتيح الميزات المطلوبة للتطبيق.

تطرح Google بانتظام إصدارات جديدة من نظام التشغيل وتحديثات أمان لنظام التشغيل ومعلومات حول الثغرات الأمنية التي تم رصدها. على المصنّعين مراجعة نشرات أمان Android لمعرفة ما إذا كانت هذه التحديثات تنطبق على المنتجات التي تتوافق مع نظام التشغيل Android. للاطّلاع على مراجعة لأمان Android وتوافقه وأنظمة الإصدار، يُرجى الاطّلاع على ما يلي:

لمحة عن المركبات المرتبطة (المنتجات الأساسية الطويلة الأمد)

بدأت السيارات تصبح متصلة مع طرح راديو AM في عشرينيات القرن الماضي. ومنذ ذلك الحين، بدأ عدد الاتصالات الخارجية السلكية واللاسلكية في الازدياد مع توجه الجهات التنظيمية وشركات صناعة السيارات إلى استخدام الإلكترونيات لتسهيل عمليات التشخيص والصيانة (مثل منفذ OBD-II) وتحسين السلامة (مثل نظام مراقبة ضغط الإطارات) وتحقيق أهداف كفاءة استهلاك الوقود. أما الموجة التالية من تكنولوجيا الاتصال، فقد قدّمت ميزات تزيد من راحة السائق، مثل نظام الدخول بدون مفتاح عن بُعد وأنظمة القياس عن بُعد وميزات ترفيهية متقدّمة، مثل البلوتوث وشبكة Wi-Fi وعرض محتوى الهاتف الذكي على الشاشة. في الوقت الحالي، تتيح أدوات الاستشعار والاتصال المدمجة (مثل نظام تحديد المواقع العالمي (GPS)) أنظمة السلامة والقيادة شبه الذاتية.

ومع زيادة عدد اتصالات المركبات، تزداد مساحة السطح المعرَّض للهجوم المحتمل على المركبة. تتضمّن الأجهزة المتصلة مجموعة مشابهة من المخاوف المتعلقة بالأمن السيبراني كما هو الحال بالنسبة إلى الأجهزة الإلكترونية الاستهلاكية. ومع ذلك، في حين أنّ عمليات إعادة التشغيل وتحديثات التصحيح اليومية والسلوكيات غير المفسّرة هي أمر طبيعي بالنسبة إلى الأجهزة الإلكترونية الاستهلاكية، فإنّها غير متسقة بالنسبة إلى المنتجات التي تتضمّن أنظمة بالغة الأهمية للسلامة، مثل المركبات.

على الشركات المصنّعة اتّخاذ نهج استباقي لضمان استمرار أمان المنتج وسلامته أثناء استخدامه. باختصار، يجب أن يكون المصنّعون على دراية بالثغرات الأمنية المعروفة في المنتج وأن يتّبعوا نهجًا قائمًا على تقييم المخاطر لمعالجتها.

ضمان الأمان على المدى الطويل

تحتوي المركبة المتصلة غالبًا على وحدة تحكّم إلكترونية واحدة أو أكثر (ECU) تتضمّن عدة مكونات برمجية، مثل نظام التشغيل والمكتبات والأدوات المساعدة وما إلى ذلك. على المصنّعين تتبُّع هذه المكونات وتحديد الثغرات الأمنية المعروفة المنشورة من خلال التحليل الاستباقي، بما في ذلك:

  • تقييم المنتج بانتظام استنادًا إلى قاعدة بيانات الثغرات والمخاطر الأمنية الشائعة (CVE)
  • جمع معلومات عن الثغرات الأمنية المتعلّقة بالمنتج
  • اختبار الأمان
  • تحليل "نشرات أمان Android" بشكل نشط

أمثلة على تحديثات نظام التشغيل ورموز تصحيح الأمان (أنظمة المعلومات والترفيه داخل المركبة التي تعمل بنظام التشغيل Android):

الشكل 1: مثال على طرح تحديثات رئيسية لنظام التشغيل وتحديثات الأمان على مدار عمر المركبة

# الخطوة الأنشطة

①

 فرع التطوير تختار الشركة المصنّعة إصدارًا من Android (Android X). في هذا المثال، يصبح "Android X" أساس ما سيتم شحنه في السيارة قبل عامَين من تاريخ بدء الإنتاج الأوّلي.
‫② الإطلاق الأوّلي قبل بضعة أشهر من طرح Android X كأول إصدار من نظام التشغيل في المنتج، يتم الحصول على تحديثات الأمان من "نشرات أمان Android" (ASB) وربما من مصادر أخرى تعتبرها الشركة المصنّعة قيّمة. y2 = نشرة الأمان الثانية للإصدار X من Android، والتي طبّقتها الشركة المصنّعة (نقلتها إلى إصدار أقدم) على Android X. يتم طرح هذا التحديث في المنتج، ويبدأ احتساب الوقت منذ الإصدار الأوّلي مع Android X.y2.

في هذا المثال، اتّخذت الشركة المصنّعة قرارًا بعدم شحن الإصدار السنوي الأحدث من Android X+1. تشمل أسباب إصدار أحدث إصدار إضافة ميزات جديدة، ومعالجة الثغرات الأمنية الجديدة، و/أو توفير خدمات من Google أو من جهات خارجية تتطلّب إصدار Android الأحدث. تتضمّن الأسباب التي تحول دون الشحن باستخدام أحدث إصدار عدم توفّر الوقت اللازم لعملية تطوير المركبة وإطلاقها، والذي يتطلّبه دمج التغييرات واختبارها والتحقّق من صحتها، بما في ذلك الامتثال لجميع المتطلبات التنظيمية ومتطلبات شهادات الاعتماد.
③ تحديث نظام التشغيل بالكامل بعد تاريخ بدء البيع، تُصدر الشركة المصنّعة تحديثًا لنظام التشغيل Android X+2، وهو إصداران من Android بعد الإصدار المستخدَم في المنتج الأولي (Android X0). تتوفّر تحديثات أمان ASB لمستوى واجهة برمجة التطبيقات (اعتبارًا من تاريخ الشحن)، لذا يتم طرح التحديث على النحو التالي: X+2.y0 بعد حوالي 1.25 عام من تاريخ إصدار البرنامج. قد يكون تحديث نظام التشغيل هذا متوافقًا مع المنتجات الميدانية أو لا يكون متوافقًا معها. إذا كان الأمر كذلك، يمكن إنشاء خطة لتعديل المركبات التي تم نشرها.

ما لم تكن هناك اتفاقيات تجارية أخرى سارية، يكون قرار إجراء تحديث كامل لنظام التشغيل خاضعًا بالكامل لتقدير الشركة المصنّعة.
④ تحديث الأمان بعد عامَين من بدء إنتاج السيارة، أصدرت الشركة المصنّعة حزمة أمان لنظام التشغيل Android X+2. ويستند هذا القرار إلى تقييم المخاطر الذي تجريه الشركة المصنّعة. تختار الشركة المصنّعة تحديث الأمان الثالث من "نشرة أمان Android" للإصدار X+2 كأساس للتحديث. أصبحت المنتجات التي تتلقّى تحديث الأمان تعمل الآن بنظام التشغيل (X+2.y3) ومستوى رمز تصحيح أمان Android.

على الرغم من أنّه يمكن للمصنّعين اختيار رموز تصحيحات الأمان الفردية من أي نشرة أمان فردية، عليهم إصلاح جميع المشاكل المطلوبة في النشرة لاستخدام مستوى تصحيح الأمان في Android (SPL) المرتبط بالنشرة (على سبيل المثال، 2017-02-05). وتقع على عاتق الشركة المصنّعة مسؤولية تنفيذ عملية النقل إلى إصدار أقدم وإصدار تحديث الأمان للمنتج المتوافق.
⑤ تحديث نظام التشغيل بالكامل تكرار الخطوة 3 (تحديث نظام التشغيل الكامل): يؤدي تحديث نظام التشغيل الكامل الثاني إلى ترقية المنتج إلى Android X+4، وذلك بعد ثلاث سنوات من بدء فترة إنتاج المركبة. وتعمل الشركة المصنّعة حاليًا على الموازنة بين متطلبات الأجهزة الحديثة التي يفرضها إصدار Android الأخير ومواصفات الأجهزة المضمّنة في المنتج، بالإضافة إلى المزايا التي سيحصل عليها المستخدم من خلال تحديث نظام التشغيل Android. أصدر المصنّع تحديثًا بدون تحديثات أمان، فأصبح المنتج الآن يعمل بالإصدار (X+4.y0) من نظام التشغيل ومستوى رمز تصحيح أمان Android.

في هذا المثال، وبسبب القيود المفروضة على الأجهزة، فإنّ الإصدار X+4 هو آخر إصدار رئيسي من Android سيتم توفيره لهذا المنتج، على الرغم من أنّ العمر المتوقّع للمركبة الذي يزيد عن 6 سنوات يتطلّب توفير دعم الأمان.
⑥ تحديث الأمان كرِّر الخطوة 4 (تحديث الأمان). تتولى الشركة المصنّعة مهمة الحصول على تحديثات أمان ASB من إصدار أحدث بكثير من Android (الإصدار X+6) ونقل بعض أو كل هذه التحديثات إلى الإصدار Android X+4. وتقع على عاتق الشركة المصنّعة مسؤولية دمج التحديثات وتضمينها وتنفيذها (أو التعاقد مع طرف ثالث). وعلى الشركة المصنّعة أيضًا أن تعلم أنّ المشاكل الأمنية في إصدارات Android التي لم يعُد متاحًا لها الدعم غير مشمولة في "إطار عمل أمان Android".
⑦ تحديث الأمان بعد ثماني سنوات من بدء دورة الإنتاج للسيارة، وأربعة إصدارات من Android منذ آخر تحديث لنظام التشغيل في الخطوة 5 (تحديث كامل لنظام التشغيل)، وعشر سنوات منذ تحديد مواصفات Android X، تقع مسؤولية تنظيم حِزم الأمان ونقلها إلى الإصدارات القديمة على عاتق الشركة المصنّعة بالكامل بالنسبة إلى الإصدارات الأقدم من ثلاث سنوات من تاريخ الإصدار العلني لمستوى واجهة برمجة التطبيقات.

أفضل ممارسات الأمان

لتصعيب اختراق الأمان، تنصح Google باستخدام أفضل الممارسات المقبولة بشكل عام في مجال الأمان وهندسة البرامج، كما هو موضّح في مقالة تنفيذ الأمان، وتطبّق هذه الممارسات.

إرشادات الأمان

تشمل الممارسات المقترَحة المتعلّقة بالأمان ما يلي:

  • استخدِم أحدث إصدارات المكتبات الخارجية ومكوّنات البرامج المفتوحة المصدر.
  • عدم تضمين وظائف تصحيح الأخطاء المتطفلة في الإصدارات المتاحة من نظام التشغيل
  • إزالة الوظائف غير المستخدَمة (لتقليل الأجزاء المعرضة للهجوم غير الضرورية)
  • اتّبِع مبدأ الحدّ الأدنى من الأذونات المميّزة وأفضل الممارسات الأخرى لتطوير تطبيقات Android.

إرشادات تطوير البرامج

تشمل الممارسات المقترَحة لتطوير البرامج الآمنة خلال دورة حياة النظام ما يلي:

  • إجراء نمذجة التهديدات لترتيب الأصول والتهديدات وإجراءات التخفيف المحتملة وتحديدها
  • إجراء مراجعة للبنية/التصميم لضمان تصميم آمن وسليم
  • إجراء مراجعات منتظمة للرموز البرمجية لتحديد الأنماط المضادة والأخطاء في أقرب وقت ممكن
  • تصميم اختبارات الوحدات وتنفيذها وتشغيلها مع توفير تغطية عالية للرموز، بما في ذلك:
    • الاختبار الوظيفي (بما في ذلك حالات الاختبار السلبية)
    • اختبار الانحدار المنتظم (لضمان عدم ظهور الأخطاء التي تم إصلاحها مرة أخرى)
    • اختبار عدم التوافق (كجزء من مجموعة اختبارات الوحدات)
  • استخدِم أدوات تحليل الرموز المصدرية الثابتة (مثل scan-build وlint وما إلى ذلك) لتحديد المشاكل المحتملة.
  • استخدِم أدوات تحليل الرموز المصدرية الديناميكية، مثل AddressSanitizer وUndefinedBehaviorSanitizer وFORTIFY_SOURCE (للمكوّنات الأصلية) لتحديد المشاكل المحتملة والحدّ منها أثناء تطوير النظام.
  • يجب أن تتوفّر استراتيجية إدارة لرمز المصدر الخاص بالبرنامج وإعدادات الإصدار/النسخة.
  • وضع استراتيجية لإدارة التصحيحات من أجل إنشاء تصحيحات البرامج ونشرها

سياسة نقل إصدارات الأمان القديمة

تقدّم Google حاليًا دعمًا نشطًا لعمليات نقل إصدارات الأمان القديمة من الثغرات الأمنية التي تم رصدها والإبلاغ عنها لمدة ثلاث (3) سنوات من تاريخ الإصدار العلني لمستوى واجهة برمجة التطبيقات. يتضمّن الدعم النشط ما يلي:

  1. تلقّي تقارير الثغرات الأمنية والتحقيق فيها
  2. إنشاء تحديثات الأمان واختبارها وإصدارها
  3. توفير إصدارات متكرّرة من تحديثات الأمان وتفاصيل نشرة الأمان
  4. إجراء تقييم لدرجة الخطورة وفقًا للإرشادات المحدّدة

بعد ثلاث سنوات من تاريخ الإصدار العلني لمستوى واجهة برمجة التطبيقات، تنصح Google باتّباع الإرشادات التالية:

  • استخدام جهة خارجية (مثل مورّد نظام على شريحة أو موفّر نواة) لتوفير دعم النقل إلى إصدار أقدم لتحديثات أمان نظام التشغيل التي مرّ عليها أكثر من ثلاث سنوات منذ إصدار واجهة برمجة التطبيقات
  • استخدام جهة خارجية لإجراء مراجعات للتعليمات البرمجية باستخدام بيانات "سلامة التطبيق" المقدَّمة بشكل علني في حين أنّ حِزم أمان Android تحدّد الثغرات الأمنية للإصدار المتوافق حاليًا، يمكن للمصنّع استخدام المعلومات المقدَّمة لمقارنة التحديثات التي تم إصدارها حديثًا بالإصدارات السابقة. ويمكن استخدام هذه البيانات لإجراء تحليل التأثير وربما إنشاء حِزم تصحيح مشابهة لإصدارات نظام التشغيل التي مرّت عليها أكثر من ثلاث سنوات منذ إصدار واجهة برمجة التطبيقات.
  • عند الاقتضاء، حمِّل تحديثات الأمان إلى "مشروع Android المفتوح المصدر" ‏ (AOSP).
  • على الشركة المصنّعة تنسيق عملية التعامل مع تحديثات الأمان للرموز البرمجية الخاصة بالمورّد (على سبيل المثال، الرموز البرمجية الخاصة بالجهاز).
  • على الشركة المصنّعة الانضمام إلى مجموعة إشعارات "معاينة نشرة أمان Android" الخاصة بالشركاء بموجب اتفاقية عدم الإفصاح (يتطلّب ذلك توقيع اتفاقيات قانونية، مثل اتفاقية عدم الإفصاح الخاصة بالمطوّرين). يجب أن تتضمّن النشرات ما يلي:
    • الإشعارات
    • ملخّص للمشاكل حسب مستوى رمز التصحيح، بما في ذلك الثغرات الأمنية الشائعة ومستوى الخطورة
    • تفاصيل الثغرة الأمنية عند الاقتضاء

مراجع إضافية

للحصول على تعليمات حول ممارسات الترميز الآمن وتطوير البرامج، يُرجى الرجوع إلى ما يلي:

تشجّع Google على اتّباع الممارسات المقترَحة التالية.

يُنصح بشكل عام بإطلاق أي منتج متصل بأحدث إصدار من نظام التشغيل، ويجب أن تحاول الشركة المصنّعة استخدام أحدث إصدار من نظام التشغيل قبل إطلاق المنتج. مع أنّ حصر الإصدار ضروري لتحقيق الاستقرار قبل الاختبار والتحقّق من الصحة، على الشركة المصنّعة تحقيق التوازن بين استقرار المنتج الذي توفّره إصدارات نظام التشغيل القديمة وإصدارات نظام التشغيل الجديدة التي تتضمّن عددًا أقل من الثغرات الأمنية المعروفة وتوفّر حماية أمنية محسّنة.

تشمل الإرشادات المقترَحة ما يلي:

  • بسبب المهل الطويلة اللازمة للتطوير والمتأصلة في عملية تطوير المركبات، قد تحتاج الشركات المصنّعة إلى إطلاق المركبات باستخدام الإصدار n-2 أو إصدار أقدم من نظام التشغيل.
  • الحفاظ على التوافق مع Android لكل إصدار من نظام التشغيل Android يتم طرحه من خلال حملة تحديث عبر الأثير (OTA).
  • توفير منتج متوافق مع تحديثات البرامج الثابتة عبر الأثير (FOTA) لنظام Android، ما يتيح إجراء تحديثات سريعة وسهلة للمستخدمين يجب إجراء تحديثات البرامج عبر الأثير (FOTA) باستخدام أفضل ممارسات الأمان، مثل توقيع الرموز البرمجية واتصال بروتوكول أمان طبقة النقل (TLS) بين المنتج ونظام تكنولوجيا المعلومات الخلفي.
  • إرسال الثغرات الأمنية في Android التي تم رصدها بشكل مستقل إلى فريق أمان Android

ملاحظة: فكّرت Google في إدراج إشعارات خاصة بنوع الجهاز أو المجال في "نشرات أمان Android". ومع ذلك، بما أنّ Google لا تعرف النواة أو برامج التشغيل أو شرائح المعالجة لجهاز معيّن (مركبة أو تلفزيون أو جهاز قابل للارتداء أو هاتف أو غير ذلك)، ليس لدى Google طريقة حتمية لتصنيف أي مشكلة أمان معيّنة حسب نوع الجهاز.

على الشركة المصنّعة بذل كل جهد ممكن لاستخدام أحدث إصدار من نظام التشغيل أو تحديثات الأمان للإصدار المستخدَم أثناء تحسينات دورة حياة المنتج. يمكن إجراء التحديثات أثناء التحديثات الدورية المتكررة للمنتج، أو لإصلاح الأخطاء الطارئة بهدف معالجة مشاكل الجودة و/أو مشاكل أخرى. تشمل الممارسات المقترَحة ما يلي:

  • وضع خطة لتناول تحديثات برامج التشغيل والنواة والبروتوكول
  • استخدام طريقة مناسبة للمجال لتوفير التحديثات للمركبات التي تم نشرها

مستند تعريف معايير التوافق (CDD)

يصف "مستند تعريف معايير التوافق" (CDD) المتطلبات التي يجب أن يستوفيها الجهاز لكي يُعدّ متوافقًا مع Android. إنّ مستند تعريف التوافق متاح للجميع ويمكنك تنزيل إصدارات مستند تعريف التوافق من Android 1.6 إلى أحدث إصدار من source.android.com.

يتضمّن استيفاء هذه المتطلبات لمنتج ما الخطوات الأساسية التالية:

  1. يوقّع الشريك على "اتفاقية التوافق مع Android" (ACC) مع Google. بعد ذلك، يتم تعيين مستشار حلول تقنية (TSC) ليكون مرشدًا لك.
  2. يُكمل الشريك مراجعة "التصميم المتوافق مع نظام التشغيل" لإصدار نظام التشغيل Android الخاص بالمنتج.
  3. يُجري الشريك اختبارات CTS ويرسل النتائج (الموضّحة أدناه) إلى أن تصبح النتائج مقبولة للتوافق مع Android.

مجموعة أدوات اختبار التوافق (CTS)

تتحقّق أداة اختبار "مجموعة أدوات اختبار التوافق" (CTS) من أنّ تنفيذ المنتج متوافق مع Android وأنّه يتضمّن آخر حِزم الأمان. مجموعة أدوات اختبار التوافق (CTS) متاحة للجميع ومفتوحة المصدر، ويمكنك تنزيل إصدارات CTS من Android 1.6 إلى أحدث إصدار من source.android.com.

يجب أن يثبت كل إصدار من برنامج Android يتم طرحه للجمهور (صور التثبيت من المصنع وتحديثات الأجهزة) توافقه مع Android من خلال نتائج مجموعة اختبار التوافق (CTS). على سبيل المثال، إذا كان الجهاز يعمل بالإصدار 7.1 من نظام التشغيل Android، يجب الرجوع إلى أحدث إصدار متوافق من مستند تعريف التوافق 7.1 ومجموعة اختبار التوافق 7.1 عند إنشاء صورة إصدار-intent واختبارها. ننصح المصنّعين بشدة باستخدام CTS في وقت مبكر وبشكل متكرر لتحديد المشاكل وحلّها.

ملاحظة: قد يحتاج الشركاء الذين يوقّعون اتفاقيات أخرى، مثل خدمات Google للأجهزة الجوّالة (GMS)، إلى استيفاء متطلبات أخرى.

سير عمل مجموعة أدوات اختبار التوافق (CTS)

يتضمّن سير عمل مجموعة أدوات اختبار التوافق إعداد بيئة الاختبار وإجراء الاختبارات وتفسير النتائج وفهم رمز المصدر لمجموعة أدوات اختبار التوافق. تهدف الإرشادات التالية إلى مساعدة مستخدمي CTS (مثل المطوّرين والمصنّعين) على استخدام CTS بفعالية وكفاءة.

  • إجراء الاختبارات بشكل متكرّر: تم تصميم CTS كأداة آلية تتكامل مع نظام الإنشاء. يمكن أن يساعدك تنفيذ CTS بشكل متكرّر في العثور على العيوب بسرعة وفي وقت مبكر عند حدوث تدهور أو تراجع في أداء البرنامج.
  • تنزيل رمز المصدر لمجموعة أدوات اختبار التوافق (CTS) وفحصه رمز المصدر الكامل لمجموعة اختبار التوافق (CTS) هو برنامج مفتوح المصدر يمكن لأي شخص تنزيله واستخدامه (يمكن إنشاء رمز المصدر الذي تم تنزيله وتشغيله بالكامل). عندما يتعذّر إجراء اختبار على الجهاز، يمكن أن يساعدك فحص القسم ذي الصلة من رمز المصدر في تحديد السبب.
  • الحصول على أحدث إصدار من مجموعة أدوات اختبار التوافق (CTS) يمكن أن تعمل إصدارات Android الجديدة على تعديل مجموعة اختبار التوافق (CTS) من خلال إصلاح الأخطاء وإدخال تحسينات وإضافة اختبارات جديدة. راجِع عمليات تنزيل مجموعة أدوات اختبار التوافق (CTS) بشكل متكرّر وعدِّل برنامج مجموعة أدوات اختبار التوافق (CTS) حسب الحاجة. يجب أن يتفق المصنّع وGoogle على إصدار CTS الذي يجب اجتيازه لإطلاق المنتج، لأنّه يجب تجميد المنتج في مرحلة ما أثناء استمرار تحديث CTS.

اجتياز مجموعة أدوات اختبار التوافق (CTS)

بالنسبة إلى المنتجات المتوافقة مع Android، تضمن Google أنّ نتائج اختبارات CTS وCTS Verifier على الجهاز مقبولة. من حيث المبدأ، يجب أن تجتاز جميع الاختبارات. ومع ذلك، يخضع أي اختبار يتعذّر إجراؤه لأسباب أخرى غير عدم امتثال الجهاز لمتطلبات التوافق مع Android لمراجعة من Google. خلال هذه العملية:

  1. تقدّم الشركة المصنّعة إلى Google حِزم تصحيح CTS المقترَحة وعمليات التحقّق من صحة حِزم التصحيح والمستندات التي تثبت صحة الحجج.
  2. تراجع Google المواد المُرسَلة، وفي حال قبولها، تعدّل اختبارات CTS ذات الصلة لكي يجتاز الجهاز الإصدار التالي من CTS.

إذا تعذّر اجتياز أحد اختبارات CTS فجأةً بعد تطبيق حزمة أمان، على الشركة المصنّعة تعديل حزمة الأمان كي لا تؤدي إلى حدوث مشاكل في التوافق أو إثبات أنّ الاختبار غير صحيح وتقديم حلّ له (كما هو موضّح أعلاه).

سيظلّ نظام CTS متاحًا لمراجعة إصلاحات الاختبار. على سبيل المثال، يواصل نظام التشغيل Android 4.4 قبول الإصلاحات (راجِع https://android-review.googlesource.com/c/platform/cts/+/273371).

الأسئلة الشائعة

س: مَن المسؤول عن تطبيق تحديثات الأمان على إصدار معيّن من Android؟

ج: الشركة المصنّعة التي توفّر الجهاز مباشرةً هي المسؤولة. هذه الجهة ليست Google، التي تنشر تحديثات الأمان في مشروع Android مفتوح المصدر (AOSP) وليس لجهاز معيّن (مثل مركبة).

س: كيف تتعامل Google مع مشاكل الأمان في Android؟

ج: تبحث Google باستمرار عن المشاكل وتعمل على تطوير حلول محتملة لها، وتتيحها لجميع مستويات واجهة برمجة التطبيقات المتوافقة كجزء من عملية تحديث الأمان المنتظمة. منذ آب (أغسطس) 2015، حافظت Google على وتيرة منتظمة لنشر النشرات وروابط التحديثات على source.android.com، كما تنشر Google تحديثات الأمان كجزء من إصدارات نظام التشغيل الرئيسية. يمكنك أيضًا الاطّلاع على سياسة نقل إصدارات الأمان القديمة.

س: إذا دمجت الشركة المصنّعة جميع تصحيحات AOSP من "نشرة أمان Android" ولكنها لم تدمج التصحيحات من مورّد "نشرة أمان الشريك" المذكور في النشرة نفسها، هل يمكنها رفع مستوى الأمان (على سبيل المثال، تطبيق التصحيح المقابل على النظام الأساسي/الإصدار)؟

ج: للإفصاح عن مستوى رموز تصحيح الأمان (SPL) في Android، على الشركة المصنّعة معالجة جميع المشاكل المطلوبة المنشورة في "نشرة أمان Android" (بما في ذلك النشرات السابقة) والمحدّدة لمستوى رموز تصحيح أمان معيّن في Android. على سبيل المثال، عالجت الشركة المصنّعة التي تستخدم نشرة الأمان لشهر آذار (مارس) 2017 (حزمة تصحيح الأمان بتاريخ 2017-03-01) جميع المشاكل المطلوبة الموضّحة في نشرة آذار (مارس) 2017 لحزمة تصحيح الأمان هذه وجميع التحديثات السابقة، بما في ذلك التحديثات الخاصة بالجهاز لجميع نشرات أمان Android السابقة، بما في ذلك التحديثات الخاصة بالجهاز المرتبطة بحزمة تصحيح الأمان بتاريخ 2017-02-05.

س: ماذا يحدث عندما لا توافق الشركة المصنّعة على تحديثات الأمان التي يقدّمها مورّد حزمة دعم اللوحة (BSP) أو عندما لا يقدّم المورّدون تحديثات الأمان التي يفرضها إطار عمل ASB؟

ج: يصف نشرة أمان Android الثغرات الأمنية (المدرَجة في قائمة الثغرات والمخاطر الأمنية الشائعة) وغالبًا ما توفّر اختبارات أمان مطابقة. والهدف من ذلك هو ضمان عدم إمكانية إعادة إنتاج الثغرات الأمنية المدرَجة على الجهاز وأن يتمكّن الجهاز من اجتياز اختبارات الأمان ذات الصلة. وبالتالي، لا تتعلّق المشكلة بتلقّي تحديث أمان مقدَّم من Google أو مورّد خارجي، بل تتعلّق بتأكيد الشركة المصنّعة على أنّ الجهاز ليس عرضة لقائمة الثغرات الأمنية الشائعة والتعرّض لها (CVE) في "شهادة تقييم أمان Android". ويحق للشركة المصنّعة استخدام تحديثات الأمان المقدَّمة أو استخدام تغيير آخر أكثر ملاءمة لجهازها.

على سبيل المثال، لنفترض أنّ Google عالجت ثغرة أمنية في AOSP باستخدام تغيير في الرمز البرمجي يتيح للمكوّن أن يظل يعمل بكامل وظائفه ويتوافق مع مستند تعريف التوافق. إذا قرّرت الشركة المصنّعة أنّ المكوّن غير مطلوب على الجهاز أو غير إلزامي بموجب مستند تعريف التوافق (أو اختبارات الشهادات ذات الصلة)، يمكنها إزالة المكوّن للحدّ من احتياجات الصيانة المستقبلية وتقليل الأجزاء المعرَّضة للهجوم. على الرغم من أنّ الشركة المصنّعة لم تستخدِم تحديث الأمان المقدَّم، إلا أنّها حرصت على ألا يكون الجهاز عرضةً لثغرة CVE الموضّحة في نشرة الأمان. ومع ذلك، عندما يبتعد المصنّع عن تحديث الأمان المقترَح، فإنّه يخاطر بمعالجة المشكلة بشكل غير صحيح أو إدخال ثغرات أمنية جديدة أو تقليل وظائف الإصدار النهائي بأي شكل آخر.

على الرغم من أنّنا نعمل مع جميع شركاء المنظومة على الرقاقة (SoC) لضمان توفّر إصلاحات لجميع المشاكل في حزمة أمان Android، ننصح المصنّعين بإبرام اتفاقية صيانة مع مورّدي المنظومة على الرقاقة طوال دورة حياة الجهاز. قد تتوقف الشركات المصنّعة للأنظمة على الرقاقات عن تقديم الخدمات لمجموعة شرائح في وقت أبكر من المتوقع، لذا فإنّ إبرام اتفاقيات قبل اختيار مجموعة شرائح الجهاز هو جزء مهم من عملية إطلاق الجهاز.

أخيرًا، في الحالات التي يتعذّر فيها الحصول مباشرةً على إصلاح لمشكلة موثّقة في نشرة أمان Android أو إنشاؤه بشكل مستقل، يمكن للمصنّع الاحتفاظ بإصدار نشرة أمان Android السابق مع إضافة الإصلاحات الجديدة المتاحة إلى الإصدار. ومع ذلك، ستؤدي هذه الممارسة في النهاية إلى حدوث مشاكل في شهادة اعتماد الإصدار (لأنّ Android يضمن توفُّر أحدث مستوى لرموز تصحيح الأمان على الأجهزة المعتمَدة). تنصح Google بالعمل مع مركز العمليات الأمنية مسبقًا لتجنُّب هذه الممارسة.

س: إذا قرّرت الشركة المصنّعة أنّ أحد بنود ASB غير منطبق على منتجها، هل يجب تطبيق هذا البند أو تصحيحه من أجل استيفاء متطلبات Google الأخرى أو اجتياز اختبار التوافق مع نظام التشغيل Android؟

ج: لا نشترط استخدام رموز تصحيح الأمان للإفصاح عن مستوى رموز تصحيح الأمان (SPL) في Android، ولكنّنا نشترط أن تؤكّد الشركة المصنّعة أنّ الإصدار غير معرَّض للمشكلة.

أحد الأمثلة على ذلك هو عدم توفّر أحد المكوّنات التي يتم تصحيحها في نظام الشركة المصنّعة، أو إزالة أحد المكوّنات من نظام الشركة المصنّعة لمعالجة مشكلة. في هذه الحالة، قد يكون النظام متوافقًا بدون أن تضطر الشركة المصنّعة إلى تطبيق تصحيح.

ويختلف ذلك بشكل أساسي عن رغبة الشركة المصنّعة، على سبيل المثال، في إصلاح التصحيحات الحرجة فقط، مع عدم تطبيق التصحيحات الأخرى التي قد تؤدي إلى عدم اجتياز اختبار الأمان. في هذه الحالة، يُفترض أنّه لم يتم استيفاء متطلبات SPL.