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

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

احراز هویت بیومتریک

داده های بیومتریک را برای احراز هویت کاربر به دقت دریافت، ذخیره و پردازش کنید. تو باید:

• قبل از استفاده از هر شکل دیگری از احراز هویت (از جمله بیومتریک) روش احراز هویت اولیه را اجباری کنید.
• هنگام استفاده از روش‌های بیومتریک غیرفعال، مانند تشخیص چهره، برای تراکنش‌هایی (مثلاً پرداخت‌ها) که شامل کلیدهای مرتبط با احراز هویت است، به تأیید صریح نیاز دارید تا نشان دهد قصد دارید.
• هر 72 ساعت به روش احراز هویت اولیه نیاز دارید.
• از یک خط لوله کاملاً ایمن برای همه داده‌های بیومتریک و مدیریت استفاده کنید.
• هرگز داده های بیومتریک (از جمله اندازه گیری حسگر خام و ویژگی های مشتق شده) را خارج از دستگاه ارسال نکنید. در صورت امکان، این داده ها را در یک محیط ایزوله ایمن مانند محیط اجرای مورد اعتماد (TEE) یا Secure Element نگهداری کنید.

دستگاه‌های دارای مشخصات بیومتریک باید از BiometricPrompt API پشتیبانی کنند، که یک رابط مشترک و ثابت برای توسعه‌دهندگان برنامه‌ها ارائه می‌کند تا از احراز هویت مبتنی بر بیومتریک در برنامه‌های خود استفاده کنند. فقط بیومتریک قوی می‌تواند با BiometricPrompt ادغام شود و ادغام‌ها باید از دستورالعمل‌های سند تعریف سازگاری Android (CDD) پیروی کنند.

برای دستورالعمل‌های بیومتریک بیشتر، دستورالعمل‌های اجرای بیومتریک HAL را ببینید.

SELinux

SELinux تعریف و اجرای بسیاری از مدل های امنیتی اندروید را ارائه می دهد. استفاده صحیح از SELinux برای امنیت دستگاه های اندرویدی بسیار مهم است و می تواند به کاهش تأثیر آسیب پذیری های امنیتی کمک کند. به همین دلیل همه دستگاه های اندرویدی باید یک خط مشی قوی SELinux را اجرا کنند.

• سیاست کمترین امتیاز را اجرا کنید.
• از دادن مجوزهای CAP_DAC_OVERRIDE ، CAP_SYS_ADMIN ، و CAP_NET_ADMIN خودداری کنید.
• داده های سیستم را به کارت SD وارد نکنید.
• از انواع ارائه شده برای دسترسی به درایور استفاده کنید، مانند gpu_device ، audio_device و غیره.
• از نام های معنی دار برای پردازش ها، فایل ها و انواع SELinux استفاده کنید.
  • اطمینان حاصل کنید که از برچسب های پیش فرض استفاده نمی شود و دسترسی به آنها اعطا نمی شود.
• خط‌مشی خاص دستگاه باید 5 تا 10 درصد از خط‌مشی کلی اجرا شده روی دستگاه را تشکیل دهد. سفارشی‌سازی‌ها در محدوده 20%+ تقریباً مطمئناً حاوی دامنه‌های دارای امتیاز بیش از حد و خط‌مشی مرده هستند. سیاست بزرگ غیرضروری حافظه را هدر می دهد، فضای دیسک را با نیاز به تصویر بوت بزرگتر هدر می دهد و بر زمان جستجوی خط مشی زمان اجرا تأثیر منفی می گذارد.

بارگذاری پویا سیاست SELinux

خط مشی SELinux را به صورت پویا در دستگاه های Android بارگیری نکنید. انجام این کار می تواند منجر به مشکلاتی مانند:

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

درهای پشتی

برنامه‌های اندروید نباید هیچ درب پشتی یا راه‌هایی برای دسترسی به سیستم یا داده‌هایی داشته باشند که مکانیسم‌های امنیتی عادی را دور بزنند. این شامل عیب‌یابی، اشکال‌زدایی، توسعه یا تعمیر ضمانت‌نامه دسترسی ویژه است که توسط اسرار شناخته شده برای توسعه‌دهنده بسته شده است. برای جلوگیری از درهای پشتی:

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

ابزار توسعه

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

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

در اینجا چند پیشنهاد اضافی وجود دارد که باید هنگام اجرای افشا و رضایت به آنها اشاره کرد:

افشای درون برنامه ای

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

درخواست رضایت

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

قابلیت تعبیه شده در AOSP

تعبیه عملکرد اضافی در AOSP اغلب می تواند رفتار و پیامدهای غیرمنتظره ای داشته باشد. با توجه ادامه بدهید.

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

به روز رسانی های امنیتی

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

• با شرکای سخت افزاری مانند فروشندگان SoC خود کار کنید تا توافق نامه های پشتیبانی مناسب را برای همه اجزای دستگاه Android خود تنظیم کنید.
• اطمینان حاصل کنید که به‌روزرسانی‌های امنیتی را می‌توان با حداقل تعامل کاربر نصب کرد تا احتمال پذیرش و نصب به‌روزرسانی‌ها در دستگاه اندرویدی توسط کاربران افزایش یابد. اجرای به‌روزرسانی‌های سیستم بدون درز یا یک ویژگی امنیتی معادل اکیداً توصیه می‌شود.
• اطمینان حاصل کنید که الزامات تجمعی وصله امنیتی Android (SPL) را همانطور که در بولتن امنیتی Android اعلام شده است، درک می کنید. به عنوان مثال، دستگاه‌هایی که از سطح وصله امنیتی 01-02-2018 استفاده می‌کنند، باید تمام مشکلات مرتبط با آن سطح وصله امنیتی و همچنین رفع تمام مشکلات گزارش‌شده در همه بولتن‌های امنیتی قبلی را شامل شوند.

به روز رسانی هسته پویا

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

مدیریت کلیدی

سیاست ها و شیوه های مدیریت کلید را برای اطمینان از امنیت کلیدهای امضاء حفظ کنید.

• کلیدهای امضا را با طرف های خارجی به اشتراک نگذارید.
• اگر یک کلید امضا به خطر افتاده است، یک کلید جدید ایجاد کنید و همه برنامه‌ها را دوبار امضا کنید.
• همه کلیدها را در سخت‌افزار یا سرویس‌های ماژول با امنیت بالا که برای دسترسی به عوامل متعددی نیاز دارند، ذخیره کنید.

امضای تصویر سیستم

امضای تصویر سیستم برای تعیین یکپارچگی دستگاه بسیار مهم است.

• دستگاه ها را با یک کلید شناخته شده برای عموم امضا نکنید.
• کلیدهای امضای دستگاه را به روشی مطابق با شیوه‌های استاندارد صنعتی برای مدیریت کلیدهای حساس مدیریت کنید، از جمله یک ماژول امنیتی سخت‌افزار (HSM) که دسترسی محدود و قابل بازرسی را فراهم می‌کند.

بوت لودرهای قابل باز شدن

بسیاری از دستگاه‌های اندرویدی از باز کردن قفل پشتیبانی می‌کنند، که به مالک دستگاه امکان می‌دهد پارتیشن سیستم را تغییر دهد یا یک سیستم عامل سفارشی نصب کند. موارد استفاده رایج شامل نصب تصویر سیستم شخص ثالث و انجام توسعه در سطح سیستم بر روی دستگاه است. به عنوان مثال، برای باز کردن قفل تصویر سیستم در Google Nexus یا Pixel، کاربر می‌تواند fastboot oem unlock اجرا کند که این پیام را نشان می‌دهد:

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

• پس از تأیید فرمان باز کردن قفل توسط کاربر، دستگاه باید فوراً پاک کردن اطلاعات را شروع کند. پرچم unlocked نباید تا زمانی که حذف ایمن کامل شود تنظیم شود.
• اگر حذف ایمن نمی تواند تکمیل شود، دستگاه باید در حالت قفل بماند.
• اگر توسط دستگاه بلوک زیرین پشتیبانی می شود، باید ioctl(BLKSECDISCARD) یا معادل آن استفاده شود. برای دستگاه‌های کارت چند رسانه‌ای (eMMC) تعبیه‌شده، این به معنای استفاده از فرمان پاک کردن امن یا برش امن است. برای eMMC 4.5 و جدیدتر، این به معنای استفاده از یک Erase یا Trim معمولی و به دنبال آن یک عملیات Sanitize است.
• اگر BLKSECDISCARD توسط دستگاه بلوک زیرین پشتیبانی نمی شود، باید به جای آن ioctl(BLKDISCARD) استفاده شود. در دستگاه‌های eMMC، این یک عملیات Trim معمولی است.
• اگر BLKDISCARD پشتیبانی نمی‌شود، بازنویسی دستگاه‌های بلوک با تمام صفرها قابل قبول است.
• یک کاربر باید این گزینه را داشته باشد که قبل از فلش کردن پارتیشن، اطلاعات کاربر را پاک کند. برای مثال، دستگاه‌های Nexus از فرمان fastboot oem lock برای پاک کردن اطلاعات کاربر استفاده می‌کنند.
• یک دستگاه ممکن است از طریق eFuse یا مکانیزم مشابه، قفل و/یا قفل مجدد دستگاه را ضبط کند. با این حال، ما قویاً توصیه می کنیم که قفل مجدد بوت لودر با بازنشانی کارخانه ای بعدی باید عملکرد کامل دستگاه را بازیابی کند.

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

دستگاهی که قفل آن باز است ممکن است متعاقباً با استفاده از فرمان fastboot oem lock قفل مجدد شود. قفل کردن بوت لودر همان حفاظتی را از اطلاعات کاربر با سیستم عامل سفارشی جدید فراهم می کند که در سیستم عامل اصلی سازنده دستگاه موجود بود (به عنوان مثال اگر دستگاه دوباره آنلاک شود، داده های کاربر پاک خواهند شد).

دستگاه در حال آزمایش

دستگاه ها باید قبل از حمل و نقل توسط یک پنتستر ذیصلاح بررسی شوند. Pentesting باید مشخص کند که دستگاه از دستورالعمل‌های امنیتی ارائه‌شده در اینجا و همچنین دستورالعمل‌های امنیتی OEM داخلی پیروی می‌کند.

تست امنیت

از ابزارهای تست امنیتی ارائه شده توسط AOSP استفاده کنید. به خصوص

• از ابزارهای ایمنی حافظه در طول توسعه استفاده کنید: از MTE در جایی که پشتیبانی می شود (ARMv9 و بالاتر) و از HWASan در جایی که پشتیبانی نمی شود استفاده کنید. با فعال بودن این ابزار تا حد امکان تست ها را اجرا کنید.
• از GWP-ASan و KFENCE در تولید، برای تشخیص احتمالی مسائل ایمنی حافظه استفاده کنید.