راهنمای سازنده برای امنیت طولانی مدت اندروید

این راهنما بهترین روش‌های توصیه‌شده Google را برای اعمال وصله‌های امنیتی که توسط مجموعه تست سازگاری Android (CTS) ارزیابی می‌شوند، شرح می‌دهد. این برای سازندگان تجهیزات OEM سازگار با Android (تولیدکنندگان) در نظر گرفته شده است که بیش از سه سال پشتیبانی می شوند مانند وسایل نقلیه، تلویزیون ها، ستاپ باکس ها و لوازم خانگی. این راهنما برای کاربران نهایی (به عنوان مثال، صاحبان وسایل نقلیه) در نظر گرفته نشده است.

قدردانی و سلب مسئولیت

این راهنما به‌طور قانونی یا قراردادی Google یا سایر تولیدکنندگان را ملزم نمی‌کند و قرار نیست مجموعه‌ای از الزامات باشد. در عوض، این راهنما یک کمک آموزشی است که شیوه های توصیه شده را شرح می دهد.

بازخورد

این راهنما جامع نیست. بازنگری های اضافی برنامه ریزی شده است. بازخورد خود را به manufacturers-guide-android@googlegroups.com ارسال کنید.

واژه نامه

مدت، اصطلاح تعریف
ACC تعهد سازگاری اندروید. قبلاً به عنوان توافقنامه ضد پارگی اندروید (AFA) شناخته می شد.
AOSP پروژه متن باز اندروید
ASB بولتن امنیتی اندروید
BSP بسته پشتیبانی هیئت مدیره
CDD سند تعریف سازگاری
سی تی اس مجموعه تست سازگاری
FOTA سیستم عامل روی هوا
جی پی اس سیستم موقعیت یاب جهانی
MISRA انجمن قابلیت اطمینان نرم افزار صنعت موتور
NIST موسسه ی ملی استانداردها و تکنولوژی
OBD تشخیص روی برد ( OBD-II پیشرفتی نسبت به OBD-I در قابلیت و استانداردسازی است )
OEM سازنده تجهیزات اصلی
سیستم عامل سیستم عامل
SEI موسسه مهندسی نرم افزار
SoC سیستم روی تراشه
SOP شروع تولید
SPL سطح وصله امنیتی
TPMS سیستم مانیتورینگ فشار تایر

درباره سیستم عامل اندروید

Android یک پشته نرم‌افزاری متن‌باز و مبتنی بر لینوکس است که برای انواع دستگاه‌ها و فاکتورهای فرم طراحی شده است. از زمان اولین انتشار آن در سال 2008، اندروید به محبوب ترین سیستم عامل (OS) تبدیل شده است که بیش از 1.4 میلیارد دستگاه را در سراسر جهان تامین می کند (2016). تقریباً 67٪ از این دستگاه‌ها از Android 5.0 (Lollipop) یا جدیدتر از مارس 2017 استفاده می‌کنند (ارقام جدیدتر در داشبورد Android موجود است). در حالی که اکثریت قریب به اتفاق دستگاه‌ها را تلفن‌های همراه و تبلت تشکیل می‌دهند، اندروید در ساعت‌های هوشمند، تلویزیون‌ها و دستگاه‌های سرگرمی داخل خودرو (IVI) در حال رشد است.

تعداد برنامه های اندروید موجود در فروشگاه Google Play به بیش از 2.2 میلیون (2016) رسیده است. توسعه برنامه اندروید توسط برنامه سازگاری اندروید پشتیبانی می‌شود، که مجموعه‌ای از الزامات را از طریق سند تعریف سازگاری (CDD) تعریف می‌کند و ابزارهای تست را از طریق مجموعه تست سازگاری (CTS) ارائه می‌کند. برنامه‌های سازگاری Android تضمین می‌کنند که هر برنامه اندرویدی می‌تواند روی هر دستگاه سازگار با Android که از ویژگی‌های مورد نیاز برنامه پشتیبانی می‌کند، اجرا شود.

Google نسخه‌های جدید سیستم‌عامل، به‌روزرسانی‌های امنیتی سیستم‌عامل و اطلاعات مربوط به آسیب‌پذیری‌های کشف‌شده را به طور منظم منتشر می‌کند. بولتن امنیتی Android باید توسط سازندگان برای کاربرد این به‌روزرسانی‌ها برای محصولات پشتیبانی‌شده از سیستم عامل Android بررسی شود. برای بررسی امنیت، سازگاری و سیستم‌های ساخت اندروید، به موارد زیر مراجعه کنید:

درباره وسایل نقلیه متصل (محصولات متعارف با عمر طولانی)

وسایل نقلیه با معرفی رادیو AM در دهه 1920 شروع به اتصال کردند. از آنجا، تعداد اتصالات فیزیکی و بی سیم خارجی شروع به افزایش کرد زیرا تنظیم کننده ها و خودروسازان برای سهولت تشخیص و خدمات (به عنوان مثال، درگاه OBD-II)، بهبود ایمنی (به عنوان مثال، TPMS) و برآورده کردن اهداف مصرف سوخت به لوازم الکترونیکی روی آوردند. . موج اتصال زیر ویژگی‌های راحتی راننده مانند ورود بدون کلید از راه دور، سیستم‌های تله‌ماتیک و ویژگی‌های پیشرفته اطلاعات سرگرمی مانند بلوتوث، وای‌فای و نمایش تلفن هوشمند را معرفی کرد. امروزه، حسگرها و اتصالات یکپارچه (به عنوان مثال، GPS) از سیستم های ایمنی و رانندگی نیمه مستقل پشتیبانی می کنند.

با افزایش تعداد اتصالات وسیله نقلیه، مساحت سطح حمله احتمالی وسیله نقلیه نیز افزایش می یابد. اتصالات مجموعه ای مشابه از نگرانی های امنیت سایبری را با لوازم الکترونیکی مصرفی به همراه دارد. با این حال، در حالی که راه‌اندازی مجدد، به‌روزرسانی روزانه وصله‌ها، و رفتارهای غیرقابل توضیح برای لوازم الکترونیکی مصرفی عادی است، اما برای محصولاتی که دارای سیستم‌های ایمنی حیاتی هستند، مانند وسایل نقلیه، سازگار نیستند.

تولیدکنندگان باید رویکردی پیشگیرانه برای تضمین تداوم امنیت و وضعیت ایمنی محصول در این زمینه اتخاذ کنند. به طور خلاصه، تولیدکنندگان باید از آسیب‌پذیری‌های امنیتی شناخته شده در محصول آگاه باشند و رویکردی مبتنی بر ریسک برای رفع آنها اتخاذ کنند.

امنیت طولانی مدت را تضمین کنید

یک وسیله نقلیه متصل اغلب دارای یک یا چند واحد کنترل الکترونیکی (ECU) است که شامل چندین مؤلفه نرم‌افزاری مانند سیستم‌عامل، کتابخانه‌ها، ابزارهای کمکی و غیره است. سازندگان باید چنین اجزایی را ردیابی کنند و آسیب‌پذیری‌های منتشر شده شناخته شده را با تجزیه و تحلیل پیشگیرانه شناسایی کنند، از جمله:

  • ارزیابی منظم محصول در برابر پایگاه داده آسیب‌پذیری‌ها و مواجهه‌های رایج (CVE).
  • جمع آوری اطلاعات برای نقص های امنیتی مرتبط با محصول.
  • تست امنیتی
  • تجزیه و تحلیل فعال بولتن های امنیتی اندروید.

نمونه به‌روزرسانی‌های سیستم‌عامل و وصله امنیتی (IVI دارای Android):

شکل 1. نمونه ای از سیستم عامل اصلی و به روز رسانی امنیتی در طول عمر خودرو.

# گام فعالیت ها

①

 شعبه توسعه سازنده نسخه ای از اندروید (Android X) را انتخاب می کند. در این مثال، "Android X" مبنای آنچه که دو سال قبل از شروع اولیه تولید (SOP) در خودرو ارسال می شود، می شود.
② راه اندازی اولیه چند ماه قبل از اینکه Android X به اولین نسخه سیستم عامل عرضه شده در این محصول تبدیل شود، به روز رسانی های امنیتی از بولتن های امنیتی اندروید (ASB) و منابع بالقوه دیگر که توسط سازنده ارزشمند تلقی می شوند گرفته شده است. y2 = دومین بولتن امنیتی برای نسخه X اندروید، که توسط سازنده روی Android X اعمال شده (پشت‌پورت شده). این به‌روزرسانی در محصول ارسال می‌شود و ساعت تولید از سال صفر با Android X.y2 شروع می‌شود.

در این مثال، سازنده تصمیم گرفت نسخه سالانه جدیدتر Android X+1 را عرضه نکند . دلایل ارسال جدیدترین نسخه شامل افزودن ویژگی‌های جدید، رفع آسیب‌پذیری‌های امنیتی جدید و/یا ارسال سرویس‌های Google یا شخص ثالثی است که به نسخه جدیدتر Android نیاز دارند. دلایل مخالفت با حمل و نقل با جدیدترین نسخه، کمبود زمان ذاتی برای فرآیند توسعه و راه اندازی وسیله نقلیه مورد نیاز برای یکپارچه سازی، آزمایش و تأیید تغییرات، از جمله انطباق با تمام الزامات نظارتی و صدور گواهینامه است.

③ به روز رسانی کامل سیستم عامل پس از SOP، سازنده به‌روزرسانی سیستم‌عامل Android X+2 را منتشر می‌کند، که دو نسخه اندروید بعد از نسخه استفاده شده برای محصول اولیه (Android X0) است. به‌روزرسانی‌های امنیتی ASB برای سطح API (از تاریخ ارسال) در دسترس هستند، بنابراین به‌روزرسانی تقریباً 1.25 سال پس از SOP به عنوان X+2.y0 منتشر می‌شود. این به روز رسانی سیستم عامل ممکن است با محصولات فیلد سازگار باشد یا نباشد. اگر چنین باشد، می‌توان طرحی برای به‌روزرسانی خودروهای مستقر ایجاد کرد.

مگر اینکه قراردادهای تجاری دیگری وجود داشته باشد، تصمیم برای به‌روزرسانی کامل سیستم عامل کاملاً در اختیار سازنده است.

④ به روز رسانی امنیتی با گذشت دو سال از عمر تولید خودرو، سازنده سیستم عامل Android X+2 را اصلاح می کند. این تصمیم بر اساس ارزیابی ریسک سازنده است. سازنده سومین به‌روزرسانی امنیتی ASB را برای انتشار X+2 به عنوان مبنای به‌روزرسانی انتخاب می‌کند. محصولاتی که به‌روزرسانی امنیتی را دریافت می‌کنند اکنون در سطح (X+2.y3) OS + Android Security Patch هستند.

در حالی که سازندگان می‌توانند وصله‌های امنیتی جداگانه را از هر ASB جداگانه انتخاب کنند، باید تمام مشکلات مورد نیاز در بولتن را برطرف کنند تا از سطح وصله امنیتی Android (SPL) مرتبط با بولتن استفاده کنند (به عنوان مثال، 05/02/2017). این مسئولیت سازنده است که نسخه پشتیبان و امنیت را برای محصول پشتیبانی شده انجام دهد.

⑤ به روز رسانی کامل سیستم عامل با تکرار مرحله 3 (به‌روزرسانی کامل سیستم‌عامل)، دومین به‌روزرسانی کامل سیستم‌عامل، محصول را به Android X+4 می‌آورد، یعنی سه سال از عمر تولید خودرو می‌گذرد. سازنده اکنون در حال متعادل کردن نیازهای سخت افزاری جدیدتر نسخه اندروید اخیر با سخت افزار موجود در محصول است و کاربر از سیستم عامل اندروید به روز شده بهره می برد. سازنده یک به‌روزرسانی بدون به‌روزرسانی امنیتی منتشر می‌کند، بنابراین محصول اکنون در سطح (X+4.y0) OS + Android وصله امنیتی است.

در این مثال، به دلیل محدودیت‌های سخت‌افزاری، X+4 آخرین نسخه اصلی اندروید است که برای این محصول ارائه می‌شود، اگرچه عمر مورد انتظار ۶+ سال برای خودرو همچنان نیاز به پشتیبانی امنیتی دارد.

⑥ به روز رسانی امنیتی تکرار مرحله 4 (به روز رسانی امنیتی). سازنده وظیفه دارد به‌روزرسانی‌های امنیتی ASB را از نسخه بسیار بعدی اندروید (X+6) بگیرد و برخی یا همه آن به‌روزرسانی‌ها را به Android X+4 منتقل کند. ادغام، ادغام و انجام به روز رسانی ها (یا قرارداد با شخص ثالث) مسئولیت سازنده است. همچنین، سازنده باید بداند که مسائل امنیتی در نسخه‌های اندرویدی که دیگر پشتیبانی نمی‌شوند، در ASB پوشش داده نمی‌شوند.
⑦ به روز رسانی امنیتی هشت سال پس از چرخه عمر تولید خودرو، چهار نسخه اندروید از آخرین به‌روزرسانی سیستم‌عامل در مرحله 5 (به‌روزرسانی کامل سیستم‌عامل)، و ده سال از زمانی که Android X مشخص شد، بار مدیریت و پشتیبان‌گیری وصله‌های امنیتی کاملاً بر عهده سازنده است. نسخه های قدیمی تر از سه سال از انتشار عمومی سطح API.

بهترین شیوه های امنیتی

برای دشوارتر کردن خطرات امنیتی، Google استفاده از بهترین شیوه‌های پذیرفته‌شده برای مهندسی نرم‌افزار و امنیت را توصیه و استفاده می‌کند، همانطور که در پیاده‌سازی امنیت توضیح داده شده است.

دستورالعمل های امنیتی

اقدامات توصیه شده برای امنیت عبارتند از:

  • از آخرین نسخه های کتابخانه های خارجی و اجزای متن باز استفاده کنید.
  • عملکرد اشکال زدایی سرزده را در نسخه های منتشر شده سیستم عامل لحاظ نکنید.
  • عملکرد استفاده نشده را حذف کنید (برای کاهش سطح حمله غیر ضروری).
  • از اصل کمترین امتیاز و سایر بهترین شیوه های توسعه برنامه اندروید استفاده کنید.

دستورالعمل های توسعه نرم افزار

روش های توصیه شده برای توسعه نرم افزار ایمن برای چرخه حیات سیستم عبارتند از:

  • مدل‌سازی تهدید را برای رتبه‌بندی و شناسایی دارایی‌ها، تهدیدها و کاهش‌های احتمالی انجام دهید.
  • برای اطمینان از طراحی ایمن و سالم، بازبینی معماری/طراحی را انجام دهید.
  • برای شناسایی آنتی الگوها و اشکالات در اسرع وقت، بازبینی کدهای منظم را انجام دهید.
  • طراحی، پیاده سازی و اجرای تست های واحد پوشش با کد بالا، از جمله:
    • تست عملکردی (از جمله موارد تست منفی)
    • تست رگرسیون منظم (برای اطمینان از اینکه باگ های ثابت دوباره ظاهر نمی شوند)
    • تست فاز (به عنوان بخشی از مجموعه تست واحد)
  • برای شناسایی مشکلات احتمالی از ابزارهای تحلیل کد منبع استاتیک (اسکن ساخت، پرز و غیره) استفاده کنید.
  • از ابزارهای تجزیه و تحلیل کد منبع پویا، مانند AddressSanitizer، UndefinedBehaviorSanitizer، و FORTIFY_SOURCE (برای اجزای داخلی) برای شناسایی و کاهش مشکلات احتمالی در طول توسعه سیستم استفاده کنید.
  • یک استراتژی مدیریتی برای کد منبع نرم افزار و پیکربندی/نسخه انتشار داشته باشید.
  • یک استراتژی مدیریت پچ برای تولید و استقرار وصله های نرم افزاری داشته باشید.

سیاست پشتیبان امنیتی

Google در حال حاضر پشتیبانی فعالی از پس‌پورت‌های امنیتی آسیب‌پذیری‌های امنیتی کشف‌شده و گزارش‌شده را به مدت سه (۳) سال از زمان انتشار عمومی در سطح API ارائه می‌کند. پشتیبانی فعال شامل موارد زیر است:

  1. گزارش های آسیب پذیری را دریافت و بررسی کنید.
  2. به‌روزرسانی‌های امنیتی را ایجاد، آزمایش و منتشر کنید.
  3. نسخه‌های تکراری به‌روزرسانی‌های امنیتی و جزئیات بولتن امنیتی را ارائه دهید.
  4. ارزیابی شدت را طبق دستورالعمل های تعیین شده انجام دهید.

پس از گذشت سه سال از تاریخ انتشار عمومی سطح API، Google دستورالعمل‌های زیر را توصیه می‌کند:

  • از یک شخص ثالث (مانند فروشنده SoC یا ارائه‌دهنده هسته) برای پشتیبانی از پشتیبان برای به‌روزرسانی‌های امنیتی سیستم‌عامل قدیمی‌تر از سه سال پس از انتشار API استفاده کنید.
  • از یک شخص ثالث برای انجام بازبینی کد با استفاده از ASB های ارائه شده عمومی استفاده کنید. در حالی که ASB ها آسیب پذیری ها را برای نسخه پشتیبانی شده فعلی شناسایی می کنند، سازنده ممکن است از اطلاعات ارائه شده برای مقایسه به روز رسانی های جدید منتشر شده با نسخه های قبلی استفاده کند. این داده ها را می توان برای انجام تجزیه و تحلیل تاثیر و ایجاد پچ های مشابه برای نسخه های سیستم عامل قدیمی تر از سه سال پس از انتشار API استفاده کرد.
  • در صورت لزوم، به‌روزرسانی‌های امنیتی را در پروژه منبع باز Android (AOSP) آپلود کنید.
  • سازنده باید مدیریت به‌روزرسانی‌های امنیتی را برای کدهای خاص فروشنده (مثلاً کد اختصاصی دستگاه خاص) هماهنگ کند.
  • سازنده باید به گروه اعلان پیش‌نمایش شریک بولتن امنیتی NDA Android بپیوندد (نیاز به امضای قراردادهای قانونی مانند توسعه‌دهنده NDA دارد). بولتن ها باید شامل موارد زیر باشد:
    • اطلاعیه ها
    • خلاصه مسائل بر اساس سطح پچ، از جمله CVE و شدت
    • جزئیات آسیب پذیری در صورت لزوم

مراجع اضافی

برای دستورالعمل‌های مربوط به کدنویسی امن و شیوه‌های توسعه نرم‌افزار، به موارد زیر مراجعه کنید:

Google استفاده از روش های توصیه شده زیر را تشویق می کند.

به طور کلی توصیه می شود که هر محصول متصل با آخرین نسخه سیستم عامل راه اندازی شود و سازنده باید سعی کند قبل از راه اندازی محصول از جدیدترین نسخه سیستم عامل استفاده کند. در حالی که قفل کردن نسخه برای ایجاد ثبات قبل از آزمایش و اعتبار سنجی ضروری است، سازنده باید بین ثبات محصول به دست آمده از نسخه‌های قدیمی‌تر سیستم‌عامل با نسخه‌های سیستم‌عامل جدیدتر که دارای آسیب‌پذیری‌های امنیتی شناخته‌شده کمتر و حفاظت‌های امنیتی پیشرفته‌تر هستند، تعادل ایجاد کند.

دستورالعمل های توصیه شده عبارتند از:

  • با توجه به زمان‌های طولانی توسعه که مربوط به فرآیند توسعه خودرو است، ممکن است تولیدکنندگان نیاز به راه‌اندازی با سیستم‌عامل نسخه n-2 یا قدیمی‌تر داشته باشند.
  • مطابقت با سازگاری Android را برای هر نسخه سیستم عامل اندروید منتشر شده با یک کمپین هوایی (OTA) حفظ کنید.
  • محصول Android Firmware-over-the-air (FOTA) را پیاده سازی کنید که قادر به به روز رسانی سریع و مشتری پسند است. FOTA باید با استفاده از بهترین شیوه های امنیتی مانند امضای کد و اتصال TLS بین محصول و دفتر پشتیبان فناوری اطلاعات انجام شود.
  • آسیب‌پذیری‌های امنیتی اندروید را که به‌طور مستقل شناسایی شده‌اند به تیم امنیت Android ارسال کنید .

توجه: Google نوع دستگاه یا اعلان‌های مربوط به صنعت را در بولتن‌های امنیتی Android در نظر گرفته است. با این حال، از آنجایی که Google هسته، درایورها یا چیپ‌ست‌های یک دستگاه خاص (خودرو، تلویزیون، پوشیدنی، تلفن و غیره) را نمی‌شناسد، Google روش قطعی برای برچسب‌گذاری هر مشکل امنیتی با نوع دستگاه ندارد. .

سازنده باید تمام تلاش خود را برای استفاده از آخرین نسخه سیستم عامل یا به روز رسانی های امنیتی برای نسخه در حال استفاده در طول بهبود چرخه محصول انجام دهد. به‌روزرسانی‌ها را می‌توان در طول به‌روزرسانی‌های دوره‌ای محصول، یا برای رفع مشکلات کیفیت و/یا سایر مشکلات انجام داد. اقدامات توصیه شده عبارتند از:

  • یک طرح برای آدرس دهی به روز رسانی درایور، هسته و پروتکل ایجاد کنید.
  • از روش مناسب صنعتی برای ارائه به روز رسانی به وسایل نقلیه مستقر استفاده کنید.

سند تعریف سازگاری (CDD)

سند تعریف سازگاری (CDD) الزاماتی را برای دستگاهی که باید با Android در نظر گرفته شود، توضیح می دهد. CDD عمومی و در دسترس همه است. می توانید نسخه های CDD را از Android 1.6 تا آخرین نسخه از source.android.com دانلود کنید.

برآوردن این الزامات برای یک محصول شامل مراحل اساسی زیر است:

  1. شریک تعهد سازگاری Android (ACC) را با Google امضا می کند. سپس یک مشاور راه حل فنی (TSC) به عنوان راهنما تعیین می شود.
  2. Partner بررسی CDD را برای نسخه سیستم عامل Android محصول تکمیل می کند.
  3. تا زمانی که نتایج برای سازگاری Android قابل قبول باشد، شریک نتایج CTS را اجرا می کند (که در زیر توضیح داده شده است).

مجموعه تست سازگاری (CTS)

ابزار تست Compatibility Test Suite (CTS) تأیید می‌کند که اجرای محصول با Android سازگار است و آخرین وصله‌های امنیتی موجود است. CTS عمومی، منبع باز و در دسترس همه است. می توانید نسخه های CTS را از Android 1.6 تا آخرین نسخه از source.android.com دانلود کنید.

هر بیلد نرم‌افزار اندرویدی که برای عموم منتشر می‌شود (تصاویر نصب کارخانه و به‌روزرسانی میدانی) باید سازگاری Android را از طریق نتایج CTS ثابت کند. به عنوان مثال، اگر دستگاه دارای Android 7.1 باشد، هنگام ایجاد و آزمایش یک تصویر ساخت با هدف انتشار، باید به آخرین نسخه مربوط به CDD 7.1 و CTS 7.1 اشاره کرد. تولیدکنندگان به شدت تشویق می‌شوند که از CTS در مراحل اولیه و مکرر برای شناسایی و رفع مشکلات استفاده کنند.

توجه: شرکایی که قراردادهای دیگری مانند خدمات تلفن همراه Google (GMS) را امضا می کنند، ممکن است نیاز به رعایت سایر شرایط داشته باشند.

گردش کار CTS

گردش کار CTS شامل تنظیم محیط تست، اجرای تست ها، تفسیر نتایج و درک کد منبع CTS است. دستورالعمل های زیر برای کمک به کاربران CTS (به عنوان مثال، توسعه دهندگان، تولید کنندگان) در استفاده موثر و کارآمد از CTS در نظر گرفته شده است.

  • به طور مکرر تست ها را اجرا کنید . CTS به عنوان یک ابزار خودکار طراحی شده است که در سیستم ساخت شما ادغام می شود. اجرای مکرر CTS می تواند به شما کمک کند تا در زمان وقوع تخریب یا رگرسیون نرم افزار، به سرعت و زود عیوب را پیدا کنید.
  • کد منبع CTS را دانلود و بررسی کنید . کد منبع کامل CTS یک نرم افزار متن باز است که هر کسی می تواند آن را دانلود و استفاده کند (کد منبع دانلود شده کاملاً قابل ساخت و اجرا است). هنگامی که یک تست روی دستگاه با شکست مواجه می شود، بررسی بخش مربوطه از کد منبع می تواند به شما در شناسایی علت کمک کند.
  • آخرین CTS را دریافت کنید . نسخه‌های جدید اندروید می‌توانند CTS را با رفع اشکال، بهبودها و آزمایش‌های جدید به‌روزرسانی کنند. بارها دانلودهای CTS را بررسی کنید و در صورت لزوم برنامه CTS خود را به روز کنید. سازنده و Google باید در مورد تصویب نسخه CTS برای راه‌اندازی محصول به توافق برسند، زیرا در زمانی که CTS همچنان به‌روزرسانی می‌شود، محصول باید ثابت شود.

CTS را پاس کنید

برای یک محصول سازگار با Android، Google اطمینان حاصل می کند که نتایج آزمایش CTS دستگاه و گزارش تأییدکننده CTS قابل قبول است. در اصل، تمام آزمون ها باید قبول شوند. با این حال، آزمایشی که به دلایلی غیر از عدم انطباق دستگاه با الزامات سازگاری Android انجام شود، توسط Google بررسی می‌شود. در طی این فرآیند:

  1. سازنده، وصله‌های CTS پیشنهادی، اعتبارسنجی وصله‌ها و توجیه‌هایی را برای اثبات استدلال به گوگل ارائه می‌کند.
  2. Google مطالب ارسال شده را بررسی می‌کند و در صورت پذیرش، آزمایش‌های CTS مربوطه را به‌روزرسانی می‌کند تا دستگاه در ویرایش بعدی CTS قبول شود.

اگر یک آزمایش CTS پس از اعمال یک وصله امنیتی به طور ناگهانی با شکست مواجه شود، سازنده باید وصله را طوری تغییر دهد که سازگاری را به هم نزند یا نشان دهد که آزمایش اشتباه است و یک راه حل برای آزمایش ارائه دهد (همانطور که در بالا توضیح داده شد).

CTS برای بررسی اصلاحات آزمایشی باز است. به عنوان مثال، Android 4.4 همچنان اصلاحات را می پذیرد (به https://android-review.googlesource.com/#/c/273371/ مراجعه کنید).

سوالات متداول (سؤالات متداول)

س: چه کسی مسئول اعمال به روز رسانی های امنیتی برای پیاده سازی خاص اندروید است؟

پاسخ: سازنده مستقیماً دستگاه را ارائه می دهد. این نهاد Google نیست که به‌روزرسانی‌های امنیتی را در AOSP منتشر می‌کند و نه برای دستگاه خاصی (مانند یک وسیله نقلیه).

س: گوگل چگونه مسائل امنیتی را در اندروید مدیریت می کند؟

پاسخ: Google به طور مداوم مشکلات را بررسی می کند و راه حل های بالقوه ای را ایجاد می کند، که Google آنها را به عنوان بخشی از فرآیند به روز رسانی امنیتی منظم در دسترس همه سطوح API پشتیبانی شده قرار می دهد. از آگوست 2015، Google آهنگ منظمی از انتشار بولتن ها و پیوندهای به روز رسانی به source.android.com را حفظ کرده است. گوگل همچنین به‌روزرسانی‌های امنیتی را به عنوان بخشی از نسخه‌های اصلی سیستم عامل منتشر می‌کند. همچنین به سیاست پشتیبان امنیتی مراجعه کنید.

س: اگر سازنده‌ای تمام وصله‌های AOSP را از یک ASB ادغام کند اما وصله‌های فروشنده BSP ذکر شده در همان بولتن را ادغام نکرده باشد، آیا همچنان می‌تواند سطح امنیتی را افزایش دهد (مثلاً وصله مربوطه را روی پلتفرم/build اعمال کنید)؟

پاسخ: برای اعلام سطح وصله امنیتی Android (SPL)، سازنده باید تمام مسائل مورد نیاز منتشر شده در بولتن امنیتی Android ( از جمله بولتن های قبلی ) و نگاشت به یک Android SPL خاص را برطرف کند. برای مثال، سازنده‌ای که از بولتن امنیتی مارس 2017 (2017-03-01 SPL) استفاده می‌کند، تمام مسائل مورد نیاز مستند شده در بولتن مارس 2017 برای آن SPL و همه به‌روزرسانی‌های قبلی از جمله به‌روزرسانی‌های خاص دستگاه برای همه بولتن‌های امنیتی قبلی Android، از جمله به روز رسانی های خاص دستگاه مرتبط با SPL 05-02-2017.

س: وقتی سازنده با به‌روزرسانی‌های امنیتی ارائه‌شده توسط فروشنده BSP موافقت نمی‌کند یا زمانی که به‌روزرسانی‌های امنیتی اجباری توسط ASB توسط فروشندگان ارائه نمی‌شوند، چه اتفاقی می‌افتد؟

A: یک ASB آسیب پذیری های امنیتی را توصیف می کند (که توسط لیستی از CVE ها برشمرده شده است) و اغلب تست های امنیتی منطبق را ارائه می دهد. هدف این است که اطمینان حاصل شود که آسیب‌پذیری‌های فهرست‌شده دیگر نمی‌توانند در یک دستگاه بازتولید شوند و دستگاه می‌تواند تست‌های امنیتی مرتبط را پشت سر بگذارد. به این ترتیب، موضوع در مورد دریافت به‌روزرسانی امنیتی ارائه‌شده توسط Google یا یک فروشنده شخص ثالث نیست، بلکه در مورد تأیید سازنده این است که دستگاه در برابر لیست CVE‌ها در ASB آسیب‌پذیر نیست. سازنده مختار است از به‌روزرسانی‌های امنیتی ارائه‌شده استفاده کند یا اگر تغییری مناسب‌تر برای دستگاهش دارد، به جای آن از آن تغییر استفاده کند.

به عنوان مثال، موردی را در نظر بگیرید که در آن Google یک آسیب‌پذیری امنیتی AOSP را با استفاده از تغییر کدی که به این مؤلفه اجازه می‌دهد کاملاً کاربردی و مطابق با CDD باقی بماند، برطرف می‌کند. اگر سازنده تشخیص دهد که قطعه مورد نیاز دستگاه نیست یا توسط CDD (یا آزمایش گواهی مربوطه) الزامی نشده است، سازنده می‌تواند قطعه را حذف کند تا نیازهای خدمات بعدی را کاهش دهد و سطح حمله را کاهش دهد. اگرچه سازنده از به روز رسانی امنیتی ارائه شده استفاده نکرده است، اما اطمینان حاصل می کند که دستگاه در برابر CVE مستند شده در بولتن امنیتی آسیب پذیر نیست. با این حال، در انحراف از به‌روزرسانی امنیتی توصیه‌شده، سازنده خطر رسیدگی نادرست به این مشکل، معرفی آسیب‌پذیری‌های امنیتی جدید یا کاهش عملکرد ساخت نهایی را به جان می‌خرد.

در حالی که ما با همه شرکای SoC کار می کنیم تا اطمینان حاصل کنیم که برای همه مشکلات موجود در ASB رفع وجود دارد، توصیه می کنیم که سازندگان یک توافق نامه خدمات را با فروشندگان SoC خود برای چرخه عمر یک دستگاه تضمین کنند. SoCها ممکن است زودتر از زمان مورد نظر سرویس یک چیپست را متوقف کنند، بنابراین ایجاد توافقات قبل از انتخاب چیپست دستگاه، بخش مهمی از فرآیند راه اندازی دستگاه است.

در نهایت، در مواردی که غیرممکن است به طور مستقیم به دست آورید یا به طور مستقل یک اصلاح برای یک مشکل مستند شده در ASB ایجاد کنید، یک سازنده می تواند Android SPL قبلی را حفظ کند و همچنان اصلاحات جدید موجود را به بیلد اضافه کند. با این حال، این عمل در نهایت منجر به مشکلاتی در صدور گواهینامه خواهد شد (زیرا اندروید اطمینان می‌دهد که آخرین سطح وصله امنیتی در دستگاه‌های تایید شده در دسترس است). Google توصیه می‌کند از قبل با SoC خود کار کنید تا از این عمل اجتناب کنید.

س: اگر سازنده تشخیص دهد که یک مورد ASB برای محصولش قابل اجرا نیست، آیا برای برآورده کردن سایر الزامات Google یا گذراندن CTS همچنان باید مورد اعمال یا وصله شود؟

پاسخ: برای اعلام سطح وصله امنیتی اندروید (SPL) نیازی به دریافت وصله نداریم. ما نیاز داریم که سازنده تأیید کند که ساخت آنها در برابر این مشکل آسیب پذیر نیست.

یک مثال در جایی است که کامپوننتی که وصله می شود در سیستم سازنده وجود ندارد، یا برای رفع مشکل، یک جزء از سیستم سازنده حذف می شود. در این صورت ممکن است سیستم بدون نیاز به تولید وصله سازگار باشد.

این اساساً با تولیدکننده‌ای متفاوت است که مثلاً می‌خواهد فقط وصله‌های مهم را اصلاح کند، در حالی که سایر وصله‌های قابل‌اجرا را که باعث شکست تست امنیتی می‌شوند، استفاده نمی‌کند. در این مورد فرض می شود که SPL برآورده نشده است.