أفضل الممارسات المتعلقة بأمان النظام

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

يحتوي هذا القسم على اقتراحات لضمان أمان نظام التشغيل Android الأساسي والأجهزة.

مصادقة المقاييس الحيوية

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

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

يجب أن تتيح الأجهزة التي تتضمّن ميزات المقاييس الحيوية استخدام BiometricPrompt API، وهي واجهة برمجة تطبيقات مشتركة ومتسقة تتيح لمطوّري التطبيقات الاستفادة من المصادقة المستندة إلى المقاييس الحيوية في تطبيقاتهم. لا يمكن دمج سوى المقاييس الحيوية القوية مع BiometricPrompt، ويجب أن تلتزم عمليات الدمج بإرشادات مستند تعريف ملف تعريف التوافق مع Android (CDD).

لمزيد من الإرشادات المتعلّقة بالسمات الحيوية، اطّلِع على إرشادات تنفيذ HAL البيومتري.

SELinux

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

• تنفيذ سياسة الحد الأدنى من الأذونات المميّزة
• تجنَّب منح أذونات CAP_DAC_OVERRIDE وCAP_SYS_ADMIN وCAP_NET_ADMIN.
• لا تسجِّل بيانات النظام في بطاقة SD.
• استخدِم الأنواع المقدَّمة للوصول إلى بيانات السائق، مثل gpu_device audio_device وما إلى ذلك.
• استخدِم أسماء ذات معنى للعمليات والملفات وأنواع SELinux.
  • تأكَّد من عدم استخدام التصنيفات التلقائية وعدم منح إذن الوصول إليها.
• يجب أن تشكّل السياسة الخاصة بالجهاز نسبة تتراوح بين %5 و%10 من السياسة العامة التي يتم تطبيقها على الجهاز. من المؤكد تقريبًا أنّ عمليات التخصيص التي تزيد نسبتها عن%20 تحتوي على نطاقات تتمتع بامتيازات زائدة وسياسة غير سارية. تؤدي السياسة الكبيرة بشكل غير ضروري إلى إهدار الذاكرة ومساحة القرص من خلال الحاجة إلى صورة تمهيد أكبر، وتؤثّر سلبًا في أوقات البحث عن سياسة وقت التشغيل.

التحميل الديناميكي لسياسة SELinux

لا تحمِّل سياسة SELinux ديناميكيًا على أجهزة Android. وقد يؤدي ذلك إلى حدوث مشاكل، مثل:

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

الأبواب الخلفية

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

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

أدوات التطوير

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

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

في ما يلي بعض الاقتراحات الإضافية التي يمكنك الرجوع إليها عند تنفيذ بيان الإفصاح عن التعامل مع البيانات والموافقة:

بيان الإفصاح داخل التطبيق

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

طلب الموافقة

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

الوظائف المضمّنة في AOSP

يمكن أن يؤدي تضمين وظائف إضافية في AOSP غالبًا إلى سلوك ونتائج غير متوقّعة، لذا يُرجى المتابعة بحذر.

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

تحديثات الأمان

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

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

تحديثات النواة الديناميكية

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

إدارة المفاتيح

يجب الحفاظ على سياسات وممارسات إدارة مفاتيح التشفير الجيدة لضمان أمان مفاتيح التوقيع.

• لا تشارك مفاتيح التوقيع مع جهات خارجية.
• إذا تم اختراق مفتاح توقيع، أنشئ مفتاحًا جديدًا واوقِّع كل التطبيقات مرتين من الآن فصاعدًا.
• تخزين جميع المفاتيح في وحدات أجهزة أو خدمات عالية الأمان تتطلّب عوامل متعددة للوصول إليها

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

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

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

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

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

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

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

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

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

اختبار اختراق الأجهزة

يجب أن يراجع أحد خبراء اختبار الاختراق الأجهزة قبل شحنها. يجب أن يُثبت اختبار الاختراق أنّ الجهاز اتّبع إرشادات الأمان المقدَّمة هنا بالإضافة إلى إرشادات الأمان الداخلية لمصنعي المعدّات الأصلية.

اختبار الأمان

استخدِم أدوات اختبار الأمان التي يوفّرها إطار عمل AOSP. على وجه الخصوص

• استخدِم أدوات أمان الذاكرة أثناء التطوير: استخدِم MTE حيثما كان ذلك متاحًا (ARMv9 والإصدارات الأحدث)، HWASan حيثما لم يكن متاحًا. أجرِ أكبر عدد ممكن من الاختبارات مع تفعيل هذه الأدوات.
• استخدِم GWP-ASan وKFENCE في مرحلة الإنتاج للكشف بشكلٍ احتمالي عن مشاكل أمان الذاكرة.