تنفيذ إجراءات الأمان

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

يتلقّى فريق أمان Android طلبات للحصول على معلومات عن منع حدوث مشاكل أمان محتملة على أجهزة Android. نُجري أيضًا أحيانًا عمليات فحص سريعة للأجهزة ونُعلم المصنّعين والشركاء المتأثرين بالمشاكل المحتمَلة.

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

لتسهيل اعتماد أفضل الممارسات هذه، يدمج فريق أمن Android الاختبارات في مجموعة اختبار التوافق مع Android (CTS) وAndroid Lint كلما أمكن ذلك. ننصح مطوّري الأجهزة بالمساهمة في إجراء اختبارات يمكن أن تساعد مستخدمي Android الآخرين (يمكنك الاطّلاع على الاختبارات المتعلّقة بالأمان على root/cts/tests/tests/security/src/android/security/cts).

عملية التطوير

اتّبِع أفضل الممارسات التالية في عمليات التطوير و البيئة.

مراجعة رمز المصدر

يمكن أن ترصد مراجعة رمز المصدر مجموعة كبيرة من مشاكل الأمان، بما في ذلك المشاكل التي تم تحديدها في هذا المستند. ينصح فريق Android بشدة بإجراء مراجعة يدوية و آلية لرمز المصدر. أفضل الممارسات:

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

استخدام الاختبار الآلي

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

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

صور نظام التوقيع

إنّ توقيع صورة النظام مهم لتحديد سلامة الجهاز. أفضل الممارسات:

• يجب عدم توقيع الأجهزة باستخدام مفتاح معروف للجميع.
• يجب إدارة المفاتيح المستخدَمة لتوقيع الأجهزة بطريقة تتوافق مع الممارسات المتّبعة في المجال لمعالجة المفاتيح الحسّاسة، بما في ذلك وحدة أمان الأجهزة (HSM) التي توفّر إمكانية وصول محدودة يمكن مراجعتها.

توقيع التطبيقات (حِزم APK)

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

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

نشر التطبيقات

يمنح Google Play المصنّعين إمكانية تحديث التطبيقات بدون إجراء تحديث كامل للنظام. ويمكن أن يؤدي ذلك إلى تسريع الاستجابة لمشاكل الأمان وتقديم ميزات جديدة، بالإضافة إلى توفير طريقة لضمان أنّ تطبيقك يحتوي على اسم حِزمة فريد. أفضل الممارسات:

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

الردّ على الحوادث

يجب أن يكون بإمكان الجهات الخارجية التواصل مع الشركات المصنّعة للأجهزة بشأن المشاكل المتعلّقة بالأمان في الجهاز. ننصحك بإنشاء عنوان بريد إلكتروني يمكن للجميع الوصول إليه بهدف إدارة حوادث الأمان. أفضل الممارسات:

• أنشئ عنوانًا على النحو التالي: security@your-company.com أو عنوانًا مشابهًا وانشره.
• إذا رصدت مشكلة أمنية تؤثر في نظام التشغيل Android أو أجهزة Android من شركات تصنيع متعددة، عليك التواصل مع فريق أمان نظام التشغيل Android من خلال إرسال تقرير عن خلل أمني.

تنفيذ المنتجات

اتّبِع أفضل الممارسات التالية عند تنفيذ منتج.

عزل العمليات الأساسية

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

• يجب أن تعمل الأجهزة بأقل عدد من الرموز البرمجية اللازمة بصفتها الجذر. استخدِم عملية Android عادية بدلاً من عملية الجذر، إن أمكن. يحتوي هاتف Galaxy Nexus الذي يعمل بنظام التشغيل ICS على ست عمليات جذر فقط: vold وinetd وzygote وtf_daemon وueventd و init. إذا كان يجب تشغيل عملية بصلاحيات الجذر على جهاز، يجب توثيق العملية في طلب ميزة AOSP حتى يمكن مراجعتها بشكل علني.
• يجب عزل الرمز الجذر عن البيانات غير الموثوق بها، ويجب الوصول إليه من خلال واجهة برمجة التطبيقات. على سبيل المثال، يمكنك تقليل وظائف الجذر إلى خدمة صغيرة يمكن الوصول إليها من خلال Binder وعرض الخدمة التي تملك إذن التوقيع على تطبيق يملك امتيازات منخفضة أو لا يملك أي امتيازات للتعامل مع حركة بيانات الشبكة.
• يجب ألا تستمع عمليات الجذر إلى منفذ شبكة.
• يجب ألّا توفّر عمليات الجذر وقت تشغيل للأغراض العامة للتطبيقات (مثل آلة افتراضية Java).

عزل تطبيقات النظام

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

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

عزل العمليات

يضمن "وضع حماية التطبيقات" في Android عزل التطبيقات عن العمليات الأخرى على النظام، بما في ذلك عمليات الجذر وأدوات تصحيح الأخطاء. ولا يجوز لأي تطبيق مخالفة هذا التوقع ما لم يفعّل المستخدمDebugging في التطبيق على وجه التحديد. أفضل الممارسات:

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

تأمين ملفات SUID

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

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

يتضمّن مدقّق مجموعة أدوات اختبار التوافق (CTS) اختبارًا معلوماتيًا يسرد ملفات SUID، ولا يُسمح ببعض ملفات setuid وفقًا لاختبارات CTS.

مقابس الاستماع الآمنة

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

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

بيانات السجلّ

يؤدي تسجيل البيانات إلى زيادة خطر تعرُّض هذه البيانات ويقلل من أداء النظام. حدثت عدة حوادث أمنية عامة نتيجة تسجيل التطبيقات المثبَّتة تلقائيًا على أجهزة Android لبيانات المستخدمين الحسّاسة. أفضل الممارسات:

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

يتضمّن CTS اختبارات تتحقّق من توفّر معلومات قد تكون حسّاسة في سجلّات النظام.

تقييد الوصول إلى الدليل

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

في إطار أفضل الممارسات، يجب ألا تكون الأدلة التي أنشأها النظام أو مستخدمو الجذر قابلة للكتابة من قِبل جميع المستخدمين. تساعد اختبارات CTS في فرض هذه أفضل الممارسات من خلال اختبار الملفات الدليلية المعروفة.

ملفات الإعداد الآمنة

تعتمد العديد من برامج التشغيل والخدمات على ملفات الإعدادات والبيانات المخزَّنة في ملفاتك في ملف /system/etc و/data. إذا كانت هذه الملفات تتم معالجتها من خلال عملية مميّزة ويمكن للجميع تعديلها، يمكن للتطبيق استغلال ثغرة أمنية في العملية من خلال إنشاء محتوًى ضار في الملف الذي يمكن للجميع تعديله. أفضل الممارسات:

• يجب ألا تكون ملفات الإعدادات التي تستخدمها العمليات المميّزة قابلة للقراءة من قِبل جميع المستخدمين.
• يجب ألا تكون ملفات الضبط التي تستخدمها العمليات المميّزة قابلة للكتابة من قِبل جميع المستخدمين.

تخزين مكتبات الرموز البرمجية الأصلية

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

حصر إمكانية وصول برنامج تشغيل الجهاز

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

إيقاف ADB

‫Android Debug Bridge (adb) هي أداة مُهمّة لتطوير البرامج وتصحيح الأخطاء، ولكن تم تصميمها للاستخدام في البيئات الآمنة الخاضعة للرقابة، ويجب عدم تفعيلها للاستخدام العام. أفضل الممارسات:

• يجب أن يكون ADB غير مفعَّل تلقائيًا.
• يجب أن يطلب برنامج ADB من المستخدم تفعيله قبل قبول عمليات الربط.

فتح قفل برامج الإقلاع

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

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

• عندما يؤكّد المستخدم أمر فتح القفل، يجب أن يبدأ الجهاز محو البيانات على الفور. يجب عدم ضبط العلامة unlocked إلا بعد اكتمال عملية الحذف الآمن.
• إذا تعذّر إكمال عملية "الحذف الآمن"، يجب أن يظل الجهاز في حالة قفل.
• يجب استخدام ioctl(BLKSECDISCARD) أو ما يعادله إذا كان ذلك متوافقًا مع جهاز التخزين الأساسي. بالنسبة إلى أجهزة eMMC ، يعني ذلك استخدام الأمر Secure Erase (محو آمن) أو Secure Trim (القطع الآمن). بالنسبة إلى eMMC 4.5 والإصدارات الأحدث، يعني ذلك استخدام عملية محو أو اقتصاص عادية متبوعة بعملية Sanitize.
• إذا لم يكن BLKSECDISCARD متوافقًا مع برمجية التحكم في الوحدات الأساسية ، يجب استخدام ioctl(BLKDISCARD) بدلاً منه. في أجهزة eMMC ، هذا إجراء Trim عادي.
• إذا لم يكن BLKDISCARD متوافقًا، يُسمح بإعادة الكتابة على أجهزة التخزين المميّزة بوحدات أساسية باستخدام الأرقام صفر فقط.
• يجب أن يتوفّر للمستخدم النهائي خيار طلب محو بيانات المستخدم قبل فلاش أحد الأقسام. على سبيل المثال، على أجهزة Nexus، يتم ذلك من خلال الأمر fastboot oem lock.
• قد يسجِّل الجهاز، من خلال الصمامات الكهربائية القابلة للبرمجة أو آلية مماثلة، ما إذا كان قد تم فتح قفل الجهاز و/أو إعادة قفله.

تضمن هذه المتطلبات إتلاف جميع البيانات عند اكتمال عملية فتح القفل. ويُعدّ عدم تنفيذ إجراءات الحماية هذه تشكل هشاشة أمان بمستوى معتدل.

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