أفضل ممارسات أمن النظام

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

المصادقة البيومترية

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

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

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

لمزيد من إرشادات القياسات الحيوية، راجع إرشادات تطبيق Biometric 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 Protect عن طريق تحميل التطبيقات إلى Google Play لإجراء المسح الضوئي. يمكنك تحميل التطبيقات للمسح الضوئي دون النشر على Google Play.
  • لا تقم بتحميل الأدوات التي تركز على التشخيص أو الإصلاح مسبقًا في إصدارات الإصدار. قم بتثبيت هذه الأدوات فقط عند الطلب لحل مشكلات محددة. بالإضافة إلى ذلك، يجب ألا تعمل هذه الأدوات على أي بيانات خاصة بالحساب أو تقوم بتحميلها.

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

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

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

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

الكشف داخل التطبيق

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

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

غالبًا ما يكون لتضمين وظائف إضافية في AOSP سلوك وعواقب غير متوقعة؛ التقدم بحذر.

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

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

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

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

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

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

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

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

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

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

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

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

محمل الإقلاع غير القابل للفتح

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

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

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

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

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

اختراق الجهاز

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

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

استخدم أدوات اختبار الأمان التي توفرها AOSP. بخاصة

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