این راهنما، بهترین شیوههای توصیهشدهی گوگل برای اعمال وصلههای امنیتی را که توسط مجموعهی تست سازگاری اندروید (CTS) ارزیابی میشوند، شرح میدهد. این راهنما برای تولیدکنندگان تجهیزات OEM (سازندگان) سازگار با اندروید که بیش از سه سال پشتیبانی میشوند، مانند وسایل نقلیه، تلویزیونها، گیرندههای دیجیتال و لوازم خانگی، در نظر گرفته شده است. این راهنما برای کاربران نهایی (به عنوان مثال، دارندگان وسایل نقلیه) در نظر گرفته نشده است.
تقدیر و تشکر و سلب مسئولیت
این راهنما از نظر قانونی یا قراردادی، گوگل یا سایر تولیدکنندگان را ملزم به رعایت آن نمیکند و قرار نیست مجموعهای از الزامات باشد. در عوض، این راهنما یک راهنمای آموزشی است که شیوههای توصیهشده را شرح میدهد.
بازخورد
این راهنما جامع نیست؛ اصلاحات بیشتری در آن برنامهریزی شده است. نظرات خود را به manufacturers-guide-android@googlegroups.com ارسال کنید.
واژهنامه
| مدت | تعریف |
|---|---|
| ای سی سی | تعهد سازگاری اندروید. قبلاً با نام توافقنامه ضد تکهتکه شدن اندروید (AFA) شناخته میشد. |
| آئوسپ | پروژه متنباز اندروید |
| ای اس بی | بولتن امنیتی اندروید |
| بی اس پی | بسته پشتیبانی هیئت مدیره |
| سی دی دی | سند تعریف سازگاری |
| سی تی اس | مجموعه تست سازگاری |
| فوتا | سیستم عامل از طریق هوا |
| جی پی اس | سیستم موقعیتیابی جهانی |
| میسرا | انجمن قابلیت اطمینان نرمافزار صنعت خودرو |
| نیست | موسسه ملی استانداردها و فناوری |
| او بی دی | عیبیابی داخلی ( OBD-II هم از نظر قابلیت و هم از نظر استانداردسازی، نسبت به OBD-I پیشرفت داشته است ) |
| نصب شده | سازنده تجهیزات اصلی |
| سیستم عامل | سیستم عامل |
| اس ای آی | موسسه مهندسی نرمافزار |
| تراشه | سیستم روی تراشه |
| روش استاندارد عملیاتی (SOP) | شروع تولید |
| اس پی ال | سطح وصله امنیتی |
| TPMS | سیستم نظارت بر فشار باد لاستیک |
درباره سیستم عامل اندروید
اندروید یک پشته نرمافزاری کامل متنباز و مبتنی بر لینوکس است که برای انواع دستگاهها و فرمفکتورها طراحی شده است. از زمان اولین انتشار آن در سال ۲۰۰۸، اندروید به محبوبترین سیستم عامل (OS) تبدیل شده است و ۱.۴+ میلیارد دستگاه در سراسر جهان (۲۰۱۶) از آن استفاده میکنند. تقریباً ۶۷٪ از این دستگاهها تا مارس ۲۰۱۷ از اندروید ۵.۰ (لالیپاپ) یا جدیدتر استفاده میکنند (ارقام جدیدتر در داشبورد اندروید موجود است). در حالی که اکثریت قریب به اتفاق دستگاهها تلفنهای همراه و تبلتها هستند، اندروید در ساعتهای هوشمند، تلویزیونها و دستگاههای سرگرمی داخل خودرو (IVI) در حال رشد است.
تعداد برنامههای اندروید موجود در فروشگاه گوگل پلی به بیش از ۲.۲ میلیون (۲۰۱۶) رسیده است. توسعه برنامههای اندروید توسط برنامه سازگاری اندروید پشتیبانی میشود که مجموعهای از الزامات را از طریق سند تعریف سازگاری (CDD) تعریف میکند و ابزارهای آزمایش را از طریق مجموعه تست سازگاری (CTS) ارائه میدهد. برنامههای سازگاری اندروید تضمین میکنند که هر برنامه اندروید میتواند روی هر دستگاه سازگار با اندروید که از ویژگیهای مورد نیاز برنامه پشتیبانی میکند، اجرا شود.
گوگل به طور منظم نسخههای جدید سیستم عامل، بهروزرسانیهای امنیتی سیستم عامل و اطلاعات مربوط به آسیبپذیریهای کشف شده را منتشر میکند. تولیدکنندگان باید بولتنهای امنیتی اندروید را برای کاربرد این بهروزرسانیها در محصولات پشتیبانی شده از سیستم عامل اندروید بررسی کنند. برای بررسی امنیت، سازگاری و سیستمهای ساخت اندروید، به موارد زیر مراجعه کنید:
- ایمنسازی دستگاه اندروید
- بهروزرسانیها و منابع امنیتی
- مجموعه تست سازگاری
- نامهای رمز، برچسبها و شمارههای ساخت
درباره وسایل نقلیه متصل (محصولات با عمر طولانی متعارف)
وسایل نقلیه با معرفی رادیو AM در دهه 1920 شروع به اتصال به یکدیگر کردند. از آنجا، تعداد اتصالات فیزیکی و بیسیم خارجی شروع به افزایش کرد، زیرا تنظیمکنندهها و خودروسازان برای سهولت در تشخیص و سرویس (به عنوان مثال، پورت OBD-II)، بهبود ایمنی (به عنوان مثال، TPMS) و دستیابی به اهداف مصرف سوخت، به الکترونیک روی آوردند. موج بعدی اتصال، ویژگیهای راحتی راننده مانند ورود بدون کلید از راه دور، سیستمهای تلهماتیک و ویژگیهای پیشرفته سرگرمی مانند بلوتوث، Wi-Fi و نمایش تلفن هوشمند را معرفی کرد. امروزه، حسگرها و اتصال یکپارچه (به عنوان مثال، GPS) از سیستمهای رانندگی ایمنی و نیمهخودران پشتیبانی میکنند.
با افزایش تعداد اتصالات وسایل نقلیه، سطح حمله بالقوه به وسایل نقلیه نیز افزایش مییابد. این اتصالات، مجموعهای مشابه از نگرانیهای امنیت سایبری را برای لوازم الکترونیکی مصرفی به همراه دارند. با این حال، در حالی که راهاندازی مجدد، بهروزرسانیهای روزانه وصلهها و رفتارهای غیرقابل توضیح برای لوازم الکترونیکی مصرفی امری عادی است، برای محصولاتی با سیستمهای ایمنی حیاتی مانند وسایل نقلیه، این موارد متناقض هستند.
تولیدکنندگان باید رویکردی پیشگیرانه برای اطمینان از وضعیت امنیتی و ایمنی مداوم یک محصول در این زمینه اتخاذ کنند. به طور خلاصه، تولیدکنندگان باید از آسیبپذیریهای امنیتی شناخته شده در محصول آگاه باشند و رویکردی مبتنی بر ریسک برای رفع آنها اتخاذ کنند.
تضمین امنیت بلندمدت
یک وسیله نقلیه متصل اغلب دارای یک یا چند واحد کنترل الکترونیکی (ECU) است که شامل چندین مؤلفه نرمافزاری مانند سیستم عامل، کتابخانهها، ابزارهای کاربردی و غیره میشود. تولیدکنندگان باید چنین مؤلفههایی را ردیابی کرده و آسیبپذیریهای شناخته شده منتشر شده را با تجزیه و تحلیل پیشگیرانه، از جمله موارد زیر، شناسایی کنند:
- ارزیابی منظم محصول در برابر پایگاه داده آسیبپذیریها و آسیبپذیریهای رایج (CVE).
- جمعآوری اطلاعات برای یافتن نقصهای امنیتی مرتبط با محصول.
- تست امنیتی.
- تجزیه و تحلیل فعال بولتنهای امنیتی اندروید.
مثالهایی از بهروزرسانیهای سیستم عامل و وصلههای امنیتی (IVIهای دارای سیستم عامل اندروید):
شکل ۱. نمونهای از بهروزرسانیهای عمده سیستم عامل و امنیت در طول عمر خودرو.
| # | قدم | فعالیتها |
|---|---|---|
۱. (۱) | شعبه توسعه | تولیدکننده، نسخهای از اندروید (اندروید X) را انتخاب میکند. در این مثال، «اندروید X» مبنای چیزی میشود که دو سال قبل از شروع تولید اولیه (SOP) در خودرو عرضه خواهد شد. |
| ② | راهاندازی اولیه | چند ماه قبل از اینکه اندروید X به عنوان اولین نسخه سیستم عامل عرضه شده در محصول قرار گیرد، بهروزرسانیهای امنیتی از بولتنهای امنیتی اندروید (ASB) و احتمالاً منابع دیگری که توسط سازنده ارزشمند تلقی میشوند، گرفته میشوند. y2 = دومین بولتن امنیتی برای نسخه X اندروید، که توسط سازنده به اندروید X اعمال (بکپورت) میشود. این بهروزرسانی در محصول عرضه میشود و ساعت تولید با اندروید X.y2 از Year Zero شروع به تیکتاک میکند. در این مثال، تولیدکننده تصمیم گرفت که جدیدترین نسخه سالانه Android X+1 را منتشر نکند . دلایل انتشار جدیدترین نسخه شامل اضافه کردن ویژگیهای جدید، رفع آسیبپذیریهای امنیتی جدید و/یا انتشار سرویسهای گوگل یا شخص ثالثی است که به نسخه جدیدتر اندروید نیاز دارند. دلایل مخالفت با انتشار جدیدترین نسخه، کمبود زمان ذاتی برای فرآیند توسعه و راهاندازی خودرو است که برای ادغام، آزمایش و اعتبارسنجی تغییرات، از جمله رعایت تمام الزامات نظارتی و صدور گواهینامه، مورد نیاز است. |
| ۳. (۳) | بهروزرسانی کامل سیستم عامل | پس از SOP، سازنده بهروزرسانی سیستم عامل اندروید X+2 را منتشر میکند که دو نسخه اندروید پس از نسخه مورد استفاده برای محصول اولیه (Android X0) است. بهروزرسانیهای امنیتی ASB برای سطح API (از تاریخ عرضه) در دسترس هستند، بنابراین بهروزرسانی تقریباً 1.25 سال پس از SOP با عنوان X+2.y0 منتشر میشود. این بهروزرسانی سیستم عامل ممکن است با محصولات میدانی سازگار باشد یا نباشد. در این صورت، میتوان طرحی برای بهروزرسانی خودروهای مستقر ایجاد کرد. مگر اینکه توافقنامههای تجاری دیگری وجود داشته باشد، تصمیم برای بهروزرسانی کامل سیستم عامل کاملاً به صلاحدید سازنده است. |
| ④ | بهروزرسانی امنیتی | دو سال پس از شروع تولید خودرو، سازنده سیستم عامل اندروید X+2 را بهروزرسانی میکند. این تصمیم بر اساس ارزیابی ریسک سازنده گرفته میشود. سازنده سومین بهروزرسانی امنیتی ASB را برای انتشار X+2 به عنوان مبنای بهروزرسانی انتخاب میکند. محصولاتی که بهروزرسانی امنیتی را دریافت میکنند، اکنون در سطح (X+2.y3) OS + Android Security Patch قرار دارند. اگرچه تولیدکنندگان میتوانند وصلههای امنیتی جداگانهای را از هر ASB جداگانه انتخاب کنند، اما باید تمام مشکلات مورد نیاز در بولتن را برطرف کنند تا از سطح وصله امنیتی اندروید (SPL) مرتبط با بولتن استفاده کنند (برای مثال، 2017-02-05). انجام پشتیبانگیری و انتشار امنیتی برای محصول پشتیبانیشده بر عهده تولیدکننده است. |
| ⑤ | بهروزرسانی کامل سیستم عامل | تکرار مرحله ۳ (بهروزرسانی کامل سیستم عامل)، دومین بهروزرسانی کامل سیستم عامل، محصول را به اندروید X+4 میرساند، که سه سال پس از شروع عمر تولید خودرو است. اکنون سازنده در حال ایجاد تعادل بین الزامات سختافزاری جدیدتر نسخه جدید اندروید و سختافزار موجود در محصول است و کاربر از یک سیستم عامل اندروید بهروز شده بهرهمند میشود. سازنده بهروزرسانی را بدون بهروزرسانیهای امنیتی منتشر میکند، بنابراین محصول اکنون در سطح (X+4.y0) OS + Android Security Patch قرار دارد. در این مثال، به دلیل محدودیتهای سختافزاری، X+4 آخرین نسخه اصلی اندروید است که برای این محصول ارائه خواهد شد، اگرچه 6+ سال از عمر مورد انتظار برای این وسیله نقلیه هنوز به پشتیبانی امنیتی نیاز دارد. |
| ⑥ | بهروزرسانی امنیتی | تکرار مرحله ۴ (بهروزرسانی امنیتی). تولیدکننده وظیفه دارد بهروزرسانیهای امنیتی ASB را از نسخه بسیار جدیدتر اندروید (X+6) دریافت کرده و برخی یا همه آن بهروزرسانیها را به اندروید X+4 منتقل کند. ادغام، یکپارچهسازی و انجام بهروزرسانیها (یا عقد قرارداد با شخص ثالث) بر عهده تولیدکننده است. همچنین، تولیدکننده باید آگاه باشد که مشکلات امنیتی در نسخههایی از اندروید که دیگر پشتیبانی نمیشوند، تحت پوشش ASB قرار نمیگیرند. |
| ⑦ | بهروزرسانی امنیتی | هشت سال از چرخه تولید خودرو میگذرد، چهار نسخه اندروید از آخرین بهروزرسانی سیستم عامل در مرحله ۵ (بهروزرسانی کامل سیستم عامل) منتشر شده است و ده سال از زمان مشخص شدن اندروید X میگذرد، بار انتخاب و پشتیبانگیری از وصلههای امنیتی برای نسخههایی که بیش از سه سال از انتشار عمومی سطح API آنها گذشته است، کاملاً بر عهده سازنده است. |
بهترین شیوههای امنیتی
برای دشوارتر کردن نفوذهای امنیتی، گوگل استفاده از بهترین شیوههای پذیرفتهشدهی رایج برای امنیت و مهندسی نرمافزار را توصیه و به کار میگیرد، همانطور که در بخش «پیادهسازی امنیت» توضیح داده شده است.
دستورالعملهای امنیتی
شیوههای پیشنهادی برای امنیت عبارتند از:
- از آخرین نسخههای کتابخانههای خارجی و اجزای متنباز استفاده کنید.
- قابلیت اشکالزدایی مزاحم را در نسخههای منتشر شده سیستم عامل قرار ندهید.
- قابلیتهای بلااستفاده را حذف کنید (برای کاهش سطح حمله غیرضروری).
- از اصل حداقل امتیاز و سایر شیوههای برتر توسعه برنامه اندروید استفاده کنید.
دستورالعملهای توسعه نرمافزار
شیوههای توصیهشده برای توسعه نرمافزار امن در چرخه حیات سیستم عبارتند از:
- مدلسازی تهدید را برای رتبهبندی و شناسایی داراییها، تهدیدها و راهکارهای کاهش بالقوه انجام دهید.
- برای اطمینان از طراحی ایمن و بینقص، بررسی معماری/طراحی را انجام دهید.
- بررسیهای منظم کد را انجام دهید تا در اسرع وقت، ضد الگوها و اشکالات را شناسایی کنید.
- طراحی، پیادهسازی و اجرای تستهای واحد با پوشش کد بالا، شامل:
- آزمایش عملکردی (شامل موارد آزمایش منفی)
- تست رگرسیون منظم (برای اطمینان از اینکه اشکالات رفع شده دوباره ظاهر نمیشوند)
- تست فاز (به عنوان بخشی از مجموعه تست واحد)
- از ابزارهای تحلیل استاتیک کد منبع (اسکن-ساخت، lint و غیره) برای شناسایی مشکلات احتمالی استفاده کنید.
- از ابزارهای تحلیل پویای کد منبع، مانند AddressSanitizer، UndefinedBehaviorSanitizer و FORTIFY_SOURCE (برای کامپوننتهای بومی) برای شناسایی و کاهش مشکلات احتمالی در طول توسعه سیستم استفاده کنید.
- یک استراتژی مدیریتی برای کد منبع نرمافزار و پیکربندی/نسخه انتشار آن داشته باشید.
- یک استراتژی مدیریت وصله برای تولید و استقرار وصلههای نرمافزاری داشته باشید.
سیاست پشتیبان امنیتی
گوگل در حال حاضر به مدت سه (3) سال از زمان انتشار عمومی در سطح API ، پشتیبانی فعالی را برای بکپورتهای امنیتی آسیبپذیریهای امنیتی کشفشده و گزارششده ارائه میدهد. پشتیبانی فعال شامل موارد زیر است:
- دریافت و بررسی گزارشهای آسیبپذیری
- بهروزرسانیهای امنیتی را ایجاد، آزمایش و منتشر کنید.
- انتشارهای دورهای بهروزرسانیهای امنیتی و جزئیات بولتن امنیتی را ارائه دهید.
- ارزیابی شدت را طبق دستورالعملهای تعیینشده انجام دهید.
پس از سه سال از تاریخ انتشار عمومی سطح API، گوگل دستورالعملهای زیر را توصیه میکند:
- از یک شخص ثالث (مانند فروشنده SoC یا ارائه دهنده هسته) برای پشتیبانی پشتیبان از بهروزرسانیهای امنیتی سیستم عامل که بیش از سه سال از انتشار API گذشته است، استفاده کنید.
- از یک شخص ثالث برای انجام بررسی کد با استفاده از ASB های عمومی ارائه شده استفاده کنید. در حالی که ASB ها آسیب پذیری های نسخه پشتیبانی شده فعلی را شناسایی می کنند، یک سازنده ممکن است از اطلاعات ارائه شده برای مقایسه به روزرسانی های تازه منتشر شده با نسخه های قبلی استفاده کند. این داده ها می توانند برای انجام تجزیه و تحلیل تأثیر و ایجاد وصله های مشابه برای نسخه های سیستم عامل قدیمی تر از سه سال از انتشار API استفاده شوند.
- در صورت لزوم، بهروزرسانیهای امنیتی را در پروژه متنباز اندروید (AOSP) بارگذاری کنید.
- تولیدکننده باید مدیریت بهروزرسانیهای امنیتی برای کد مخصوص فروشنده (برای مثال، کد اختصاصی مخصوص دستگاه) را هماهنگ کند.
- تولیدکننده باید به گروه اعلان پیشنمایش شریک بولتن امنیتی اندروید NDA بپیوندد (نیاز به امضای توافقنامههای قانونی مانند NDA توسعهدهنده دارد). بولتنها باید شامل موارد زیر باشند:
- اطلاعیهها
- خلاصهای از مشکلات بر اساس سطح وصله، شامل CVE و شدت آنها
- جزئیات آسیبپذیری در صورت لزوم
منابع اضافی
برای دستورالعملهای مربوط به کدنویسی امن و شیوههای توسعه نرمافزار، به موارد زیر مراجعه کنید:
- انجمن قابلیت اطمینان نرمافزار صنعت خودرو (MISRA)
- ابزارها و روشهای موسسه مهندسی نرمافزار (SEI) .
- موسسه ملی استانداردها و فناوری (NIST).
شیوههای توصیهشده برای محصول
گوگل استفاده از شیوههای توصیهشدهی زیر را تشویق میکند.
دستورالعملهای کلی راهاندازی
به طور کلی توصیه میشود که هر محصول متصل به شبکه با آخرین نسخه سیستم عامل عرضه شود و تولیدکننده باید قبل از عرضه محصول، سعی کند از جدیدترین نسخه سیستم عامل استفاده کند. در حالی که قفل کردن نسخه برای ایجاد ثبات قبل از آزمایش و اعتبارسنجی ضروری است، تولیدکننده باید ثبات محصول به دست آمده از نسخههای قدیمیتر سیستم عامل را با نسخههای جدیدتر سیستم عامل که آسیبپذیریهای امنیتی شناخته شده کمتر و محافظتهای امنیتی پیشرفتهتری دارند، متعادل کند.
دستورالعملهای توصیهشده عبارتند از:
- با توجه به زمان طولانی توسعه ذاتی فرآیند توسعه خودرو، تولیدکنندگان ممکن است نیاز داشته باشند که سیستم عامل را با نسخه n-2 یا قدیمیتر عرضه کنند.
- حفظ انطباق با سازگاری اندروید برای هر نسخه منتشر شده سیستم عامل اندروید با یک کمپین OTA (خارج از شبکه).
- پیادهسازی سیستم عامل اندروید از طریق هوا (FOTA) برای بهروزرسانیهای سریع و کاربرپسند. FOTA باید با استفاده از بهترین شیوههای امنیتی مانند امضای کد و اتصال TLS بین محصول و بخش فناوری اطلاعات انجام شود.
- آسیبپذیریهای امنیتی اندروید که بهطور مستقل شناسایی شدهاند را به تیم امنیت اندروید ارسال کنید .
توجه: گوگل در بولتنهای امنیتی اندروید، اعلانهای مربوط به نوع دستگاه یا صنعت خاص را در نظر گرفته است. با این حال، از آنجا که گوگل هسته، درایورها یا چیپستهای یک دستگاه خاص (خودرو، تلویزیون، پوشیدنی، تلفن و غیره) را نمیداند، گوگل روش قطعی برای برچسبگذاری هر مشکل امنیتی خاص با نوع دستگاه ندارد.
دستورالعملهای چرخه محصول
تولیدکننده باید تمام تلاش خود را بکند تا در طول بهبودهای چرخه محصول، از آخرین نسخه سیستم عامل یا بهروزرسانیهای امنیتی برای نسخه مورد استفاده استفاده کند. بهروزرسانیها میتوانند در طول بهروزرسانیهای دورهای محصول یا برای رفع مشکلات مربوط به کیفیت و/یا سایر موارد انجام شوند. رویههای توصیهشده عبارتند از:
- طرحی برای رسیدگی به بهروزرسانیهای درایور، هسته و پروتکل ایجاد کنید.
- از یک روش مناسب در صنعت برای ارائه بهروزرسانیها به خودروهای مستقر استفاده کنید.
سند تعریف سازگاری (CDD)
سند تعریف سازگاری (CDD) الزامات لازم برای سازگاری یک دستگاه با اندروید را شرح میدهد. CDD عمومی و در دسترس همه است؛ میتوانید نسخههای CDD را از اندروید ۱.۶ تا آخرین نسخه از source.android.com دانلود کنید.
برآورده کردن این الزامات برای یک محصول شامل مراحل اساسی زیر است:
- شریک، تعهدنامه سازگاری اندروید (ACC) را با گوگل امضا میکند. سپس یک مشاور راهحل فنی (TSC) به عنوان راهنما تعیین میشود.
- شریک، بررسی CDD را برای نسخه سیستم عامل اندروید محصول تکمیل میکند.
- شریک نتایج CTS (که در زیر شرح داده شده است) را اجرا و ارسال میکند تا زمانی که نتایج برای سازگاری با اندروید قابل قبول باشند.
مجموعه تست سازگاری (CTS)
ابزار تست مجموعه تست سازگاری (CTS) تأیید میکند که پیادهسازی محصول با اندروید سازگار است و آخرین وصلههای امنیتی در آن گنجانده شده است. CTS عمومی، متنباز و در دسترس همه است؛ میتوانید نسخههای CTS را از اندروید ۱.۶ تا آخرین نسخه از source.android.com دانلود کنید.
هر نسخه از نرمافزار اندروید که برای عموم منتشر میشود (ایمیجهای نصب کارخانهای و بهروزرسانی میدانی) باید سازگاری اندروید را از طریق نتایج CTS اثبات کند. به عنوان مثال، اگر دستگاه اندروید ۷.۱ را اجرا میکند، هنگام ایجاد و آزمایش ایمیج ساخت با هدف انتشار، باید به آخرین نسخه CDD 7.1 و CTS 7.1 مربوط به آن مراجعه شود. به تولیدکنندگان اکیداً توصیه میشود که از CTS به موقع و مکرر برای شناسایی و رفع مشکلات استفاده کنند.
گردش کار CTS
گردش کار CTS شامل راهاندازی محیط آزمایش، اجرای آزمایشها، تفسیر نتایج و درک کد منبع CTS است. دستورالعملهای زیر برای کمک به کاربران CTS (به عنوان مثال، توسعهدهندگان، تولیدکنندگان) در استفاده مؤثر و کارآمد از CTS در نظر گرفته شده است.
- تستها را مرتباً اجرا کنید . CTS به عنوان ابزاری خودکار طراحی شده است که در سیستم ساخت شما ادغام میشود. اجرای مکرر CTS میتواند به شما کمک کند تا هنگام بروز تخریب یا رگرسیون نرمافزار، نقصها را به سرعت و در مراحل اولیه پیدا کنید.
- کد منبع CTS را دانلود و بررسی کنید . کد منبع کامل CTS یک نرمافزار متنباز است که هر کسی میتواند آن را دانلود و استفاده کند (کد منبع دانلود شده کاملاً قابل ساخت و اجرا است). هنگامی که یک آزمایش روی دستگاه با شکست مواجه میشود، بررسی بخش مربوطه از کد منبع میتواند به شما در شناسایی دلیل آن کمک کند.
- جدیدترین CTS را دریافت کنید . نسخههای جدید اندروید میتوانند CTS را با رفع اشکالات، بهبودها و آزمایشهای جدید بهروزرسانی کنند. مرتباً دانلودهای CTS را بررسی کنید و در صورت لزوم برنامه CTS خود را بهروزرسانی کنید. سازنده و گوگل باید در مورد نسخه CTS برای عرضه محصول توافق کنند، زیرا محصول باید در مقطعی فریز شود در حالی که CTS همچنان بهروزرسانی میشود.
قبولی در آزمون CTS
برای یک محصول سازگار با اندروید، گوگل از CTS دستگاه و گزارشهای تأییدکننده CTS مبنی بر قابل قبول بودن نتایج آزمایش اطمینان حاصل میکند. در اصل، همه آزمایشها باید با موفقیت پشت سر گذاشته شوند. با این حال، آزمایشی که به دلایلی غیر از عدم تطابق دستگاه با الزامات سازگاری اندروید، با شکست مواجه شود، توسط گوگل بررسی خواهد شد. در طول این فرآیند:
- تولیدکننده، وصلههای پیشنهادی CTS، اعتبارسنجی وصلهها و توجیهات لازم برای اثبات این استدلال را در اختیار گوگل قرار میدهد.
- گوگل مطالب ارسالی را بررسی میکند و در صورت پذیرش، آزمونهای CTS مربوطه را بهروزرسانی میکند تا دستگاه در نسخه بعدی CTS با موفقیت پشت سر گذاشته شود.
اگر یک تست CTS پس از اعمال یک وصله امنیتی ناگهان با شکست مواجه شود، سازنده باید وصله را طوری اصلاح کند که سازگاری را از بین نبرد یا نشان دهد که آن تست اشتباه است و برای تست (همانطور که در بالا توضیح داده شد) راه حلی ارائه دهد.
CTS برای بررسی اصلاحات آزمایشی باز است. برای مثال، اندروید ۴.۴ همچنان اصلاحات را میپذیرد (به https://android-review.googlesource.com/c/platform/cts/+/273371 مراجعه کنید).
سوالات متداول (FAQ)
س: چه کسی مسئول اعمال بهروزرسانیهای امنیتی برای یک پیادهسازی خاص از اندروید است؟
الف) تولیدکنندهای که مستقیماً دستگاه را ارائه میدهد مسئول است. این نهاد گوگل نیست ، که بهروزرسانیهای امنیتی را در AOSP منتشر میکند و نه برای یک دستگاه خاص (مانند وسیله نقلیه).
س: گوگل چگونه مشکلات امنیتی در اندروید را مدیریت میکند؟
الف) گوگل به طور مداوم مشکلات را بررسی و اصلاحات بالقوه را توسعه میدهد، که گوگل آنها را به عنوان بخشی از فرآیند بهروزرسانی امنیتی منظم، در دسترس تمام سطوح API پشتیبانی شده قرار میدهد. از آگوست ۲۰۱۵، گوگل روند منظمی از انتشار بولتنها و لینکها به بهروزرسانیها در source.android.com را حفظ کرده است. گوگل همچنین بهروزرسانیهای امنیتی را به عنوان بخشی از انتشارهای اصلی سیستم عامل منتشر میکند. همچنین به سیاست پشتیبان امنیتی مراجعه کنید.
س: اگر تولیدکنندهای تمام وصلههای AOSP را از یک ASB ادغام کند اما وصلههای فروشنده BSP ذکر شده در همان بولتن را ادغام نکند، آیا باز هم میتواند سطح امنیتی را افزایش دهد (مثلاً وصله مربوطه را روی پلتفرم/ساخت اعمال کند) ؟
الف) برای اعلام سطح وصله امنیتی اندروید (SPL)، یک تولیدکننده باید تمام مسائل مورد نیاز منتشر شده در بولتن امنیتی اندروید ( از جمله بولتنهای قبلی ) و نگاشت شده به یک SPL خاص اندروید را برطرف کند. به عنوان مثال، تولیدکنندهای که از بولتن امنیتی مارس ۲۰۱۷ (۲۰۱۷-۰۳-۰۱ SPL) استفاده میکند، تمام مسائل مورد نیاز مستند شده در بولتن مارس ۲۰۱۷ برای آن SPL و تمام بهروزرسانیهای قبلی، از جمله بهروزرسانیهای خاص دستگاه برای همه بولتنهای امنیتی اندروید قبلی، از جمله بهروزرسانیهای خاص دستگاه مرتبط با SPL 2017-02-05 را برطرف کرده است.
س: چه اتفاقی میافتد وقتی سازنده با بهروزرسانیهای امنیتی ارائه شده توسط فروشنده BSP موافق نباشد یا بهروزرسانیهای امنیتی که توسط یک ASB الزامی شدهاند توسط فروشندگان ارائه نشوند؟
الف) یک ASB آسیبپذیریهای امنیتی (که توسط فهرستی از CVEها فهرست شدهاند) را توصیف میکند و اغلب تستهای امنیتی منطبق با آنها را ارائه میدهد. هدف این است که اطمینان حاصل شود که آسیبپذیریهای فهرستشده دیگر نمیتوانند روی یک دستگاه تکثیر شوند و دستگاه میتواند تستهای امنیتی مرتبط را با موفقیت پشت سر بگذارد. به این ترتیب، مسئله مربوط به دریافت بهروزرسانی امنیتی ارائه شده توسط گوگل یا یک فروشنده شخص ثالث نیست، بلکه مربوط به تأیید سازنده مبنی بر عدم آسیبپذیری دستگاه در برابر فهرست CVEهای موجود در ASB است. سازنده مختار است از بهروزرسانیهای امنیتی ارائه شده استفاده کند یا اگر تغییری دارد که برای دستگاهش مناسبتر است، از آن تغییر استفاده کند.
برای مثال، موردی را در نظر بگیرید که گوگل با استفاده از یک تغییر کد، یک آسیبپذیری امنیتی AOSP را برطرف میکند که به آن مؤلفه اجازه میدهد کاملاً کاربردی و مطابق با CDD باقی بماند. اگر سازنده تشخیص دهد که مؤلفه در دستگاه مورد نیاز نیست یا توسط CDD (یا آزمایش صدور گواهینامه مرتبط) اجباری نشده است، میتواند مؤلفه را حذف کند تا نیازهای سرویسدهی آینده و سطح حمله را کاهش دهد. اگرچه سازنده از بهروزرسانی امنیتی ارائه شده استفاده نکرده است، اما اطمینان حاصل کرده است که دستگاه در برابر CVE مستند شده در بولتن امنیتی آسیبپذیر نیست. با این حال، با انحراف از بهروزرسانی امنیتی توصیه شده، سازنده خطر رسیدگی نادرست به مشکل، ایجاد آسیبپذیریهای امنیتی جدید یا کاهش عملکرد نسخه نهایی را به جان میخرد.
در حالی که ما با تمام شرکای SoC همکاری میکنیم تا اطمینان حاصل کنیم که برای همه مشکلات موجود در ASB راهحلهایی وجود دارد، توصیه میکنیم تولیدکنندگان برای چرخه عمر یک دستگاه، یک قرارداد سرویس با فروشندگان SoC خود منعقد کنند. SoCها ممکن است سرویسدهی به یک چیپست را زودتر از موعد مقرر متوقف کنند، بنابراین ایجاد توافقنامه قبل از انتخاب چیپست دستگاه، بخش مهمی از فرآیند راهاندازی دستگاه است.
در نهایت، در مواردی که دستیابی مستقیم یا ایجاد مستقل یک اصلاحیه برای یک مشکل مستند شده در ASB غیرممکن است، یک سازنده میتواند SPL قبلی اندروید را حفظ کند و همچنان اصلاحات جدید موجود را به نسخه نهایی اضافه کند. با این حال، این عمل در نهایت منجر به مشکلاتی در صدور گواهینامه نسخه نهایی خواهد شد (زیرا اندروید تضمین میکند که آخرین سطح وصله امنیتی در دستگاههای دارای مجوز موجود است). گوگل توصیه میکند برای جلوگیری از این عمل، از قبل با SoC خود کار کنید.
س: اگر تولیدکننده تشخیص دهد که یک مورد ASB برای محصولش قابل استفاده نیست، آیا آن مورد همچنان نیاز به اعمال یا وصله شدن دارد تا سایر الزامات گوگل را برآورده کند یا CTS را پشت سر بگذارد؟
الف) ما برای اعلام سطح وصله امنیتی اندروید (SPL) نیازی به نصب وصلهها نداریم؛ ما الزام میکنیم که سازنده گواهی دهد که محصولش در برابر این مشکل آسیبپذیر نیست.
یک مثال زمانی است که قطعهای که قرار است وصله شود در سیستم سازنده وجود ندارد، یا قطعهای برای رفع یک مشکل از سیستم سازنده حذف میشود. در این صورت، سیستم ممکن است بدون نیاز به سازنده برای دریافت وصله، سازگار باشد.
این اساساً با این تفاوت دارد که یک تولیدکننده بخواهد، برای مثال، فقط وصلههای حیاتی را اصلاح کند، در حالی که سایر وصلههای قابل اجرا را که باعث شکست یک آزمایش امنیتی میشوند، دریافت نکند. در این حالت فرض بر این است که SPL رعایت نشده است.