تطبيق الأمن

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

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

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

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

استخدم أفضل الممارسات التالية في عمليات التطوير والبيئة الخاصة بك.

مراجعة كود المصدر

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

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

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

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

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

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

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

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

تطبيقات التوقيع (APKs)

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

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

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

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

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

الاستجابة للحوادث

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

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

تنفيذ المنتج

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

عزل العمليات الجذرية

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

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

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

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

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

عمليات العزل

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

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

تأمين ملفات SUID

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

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

يشتمل برنامج التحقق من CTS على اختبار معلوماتي يسرد ملفات SUID؛ بعض ملفات setuid غير مسموح بها في اختبارات CTS.

تأمين مآخذ الاستماع

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

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

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

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

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

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

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

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

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

تأمين ملفات التكوين

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

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

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

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

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

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

تعطيل بنك التنمية الآسيوي

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

• يجب تعطيل ADB بشكل افتراضي.
• يجب أن يطلب ADB من المستخدم تشغيله قبل قبول الاتصالات.

فتح محمل الإقلاع

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

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

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

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

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