ضبط أمان الشبكة

تتيح لك ميزة "إعداد أمان الشبكات" تخصيص إعدادات أمان الشبكة في تطبيقك في ملف إعدادات تعريفي وآمن بدون تعديل رمز التطبيق. يمكن ضبط هذه الإعدادات لنطاقات محدّدة ولتطبيق معيّن. في ما يلي الإمكانات الرئيسية لهذه الميزة:

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

إضافة ملف إعدادات أمان الشبكة

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

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:networkSecurityConfig="@xml/network_security_config"
                    ... >
        ...
    </application>
</manifest>

تخصيص موفِّري خدمات إصدار الشهادات الموثوق بهم

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

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

بشكلٍ تلقائي، تثق الاتصالات الآمنة (التي تستخدم بروتوكولات مثل بروتوكول أمان طبقة النقل (TLS) وHTTPS) من جميع التطبيقات في جهات إصدار الشهادات المُثبَّتة مسبقًا للنظام، وتثق التطبيقات التي تستهدف الإصدار 6.0 من نظام التشغيل Android (المستوى 23 من واجهة برمجة التطبيقات) والإصدارات الأقدم أيضًا في مخزن شهادات الاعتماد الذي أضافه المستخدم تلقائيًا. يمكنك تخصيص عمليات اتصال تطبيقك باستخدام base-config (لتخصيص على مستوى التطبيق) أو domain-config (لتخصيص على مستوى النطاق).

ضبط مرجع تصديق مخصّص

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

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <trust-anchors>
            <certificates src="@raw/my_ca"/>
        </trust-anchors>
    </domain-config>
</network-security-config>

أضِف شهادة هيئة إصدار الشهادات الذاتية التوقيع أو غير العامة بتنسيق PEM أو DER إلى res/raw/my_ca.

حصر مجموعة مصادر إصدار الشهادات الموثوقة

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

تشبه عملية ضبط قيود على مجموعة مراجع التصديق الموثوق بها عملية الثقة في مرجع تصديق مخصّص لنطاق معيّن، باستثناء أنّه يتم توفير مراجع تصديق متعددة في المرجع. يوضّح المقتطف التالي من الرمز البرمجي كيفية حصر مجموعة مراجع التصديق الموثوق بها في تطبيقك في res/xml/network_security_config.xml: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">secure.example.com</domain>
        <domain includeSubdomains="true">cdn.example.com</domain>
        <trust-anchors>
            <certificates src="@raw/trusted_roots"/>
        </trust-anchors>
    </domain-config>
</network-security-config>

أضِف موفِّري خدمات إصدار الشهادات الموثوق بهم بتنسيق PEM أو DER إلى res/raw/trusted_roots. يُرجى العلم أنّه في حال استخدام تنسيق PEM، يجب أن يحتوي الملف على بيانات PEM فقط وألّا يتضمّن أي نص إضافي. يمكنك أيضًا تقديم عناصر <certificates> متعددة بدلاً من عنصر واحد.

الوثوق بمصادر تصديق إضافية

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

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="@raw/extracas"/>
            <certificates src="system"/>
        </trust-anchors>
    </base-config>
</network-security-config>

ضبط خدمات إصدار الشهادات لتصحيح الأخطاء

عند تصحيح أخطاء تطبيق يتصل عبر بروتوكول HTTPS، قد تحتاج إلى الاتصال بخادم تطوير محلي لا يتضمّن شهادة بروتوكول SSL لخادم الإنتاج. لتمكين هذا الإجراء بدون أي تعديل على رمز تطبيقك، يمكنك تحديد جهات إصدار الشهادات المعنيّة بتصحيح الأخطاء فقط، والتي تكون موثوقًا بها فقط عندما تكون القيمة true لسمة android:debuggable ، وذلك باستخدام debug-overrides. عادةً ما تضبط حِزم تطوير البرامج (IDE) وأدوات الإنشاء هذا الإعداد تلقائيًا لعمليات الإنشاء غير العلنية.

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

يوضّح المقتطف أدناه كيفية تحديد مراجع تصديق مخصّصة لتصحيح الأخطاء فقط في res/xml/network_security_config.xml: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="@raw/debug_cas"/>
        </trust-anchors>
    </debug-overrides>
</network-security-config>

تفعيل ميزة "شفافية الشهادات"

شفافية الشهادات (CT، RFC 9162) هي معيار إنترنت مصمّم لتحسين أمان الشهادات الرقمية. ويتطلّب من مراجع التصديق إرسال جميع الشهادات التي تم إصدارها إلى سجلّ علني يسجّلها، ما يزيد من الشفافية والمساءلة في عملية إصدار الشهادات.

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

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

إيقاف الزيارات التي تستخدم نصًا عاديًا

ملاحظة: لا تنطبق الإرشادات الواردة في هذا القسم إلا على التطبيقات التي تستهدف الإصدار 8.1 من نظام التشغيل Android (المستوى 27 من واجهة برمجة التطبيقات) أو الإصدارات الأقدم. بدءًا من Android 9 (المستوى 28 من واجهة برمجة التطبيقات)، يتم إيقاف ميزة "النص الواضح" تلقائيًا.

إذا كنت تريد أن يتصل تطبيقك بالوجهات باستخدام اتصالات آمنة فقط، يمكنك إيقاف إتاحة النص الواضح (باستخدام بروتوكول HTTP غير المشفَّر بدلاً من HTTPS) مع هذه الوجهات. يساعد هذا الخيار في منع التراجعات العميقة غير المقصودة في التطبيقات بسبب التغييرات في عناوين URL المقدَّمة من مصادر خارجية، مثل خوادم الخلفية. يُرجى الاطّلاع على NetworkSecurityPolicy.isCleartextTrafficPermitted() لمزيد من التفاصيل.

على سبيل المثال، قد تريد أن يضمن تطبيقك أن تتم عمليات الاتصال بموقع secure.example.com دائمًا عبر بروتوكول HTTPS لحماية الزيارات المُهمّة من الشبكات المعادية.

يوضّح المقتطف أدناه كيفية إيقاف النص الواضح في res/xml/network_security_config.xml: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">secure.example.com</domain>
    </domain-config>
</network-security-config>

تثبيت الشهادات

يثق التطبيق عادةً بجميع جهات إصدار الشهادات المُثبَّتة مسبقًا. إذا أصدرت أيّ من هذه الجهات اعتمادًا fraudulent certificate، سيتعرّض التطبيق لهجوم من مهاجم على المسار. تختار بعض التطبيقات الحد من مجموعة الشهادات التي تقبلها، إما من خلال الحد من مجموعة شهادات CA التي تثق بها أو من خلال تثبيت الشهادة.

يتم تثبيت الشهادة من خلال تقديم مجموعة من الشهادات حسب تجزئة المفتاح العام (SubjectPublicKeyInfo من شهادة X.509). لا تكون سلسلة الشهادات صالحة إلا إذا كانت تحتوي على مفتاح عام واحد على الأقل من المفاتيح العامة المثبَّتة.

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

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

يوضّح المقتطف أدناه كيفية تثبيت الشهادات في res/xml/network_security_config.xml: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <pin-set expiration="2018-01-01">
            <pin digest="SHA-256">7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=</pin>
            <!-- backup pin -->
            <pin digest="SHA-256">fwza0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1oE=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

سلوك اكتساب الإعدادات

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

على سبيل المثال، يتمّ أخذ القيم غير المحدّدة في domain-config من العنصر الرئيسي domain-config، إذا كان مُدمجًا، أو من base-config، إذا لم يكن كذلك. إنّ القيم التي لم يتم ضبطها في base-config تستخدم القيم التلقائية للنظام الأساسي.

على سبيل المثال، لنفترض أنّه يجب أن تستخدم جميع عمليات الربط بالنطاقات الفرعية example.com مجموعة مخصّصة من موفّري خدمات إصدار الشهادات. بالإضافة إلى ذلك، يُسمح بالزيارات بتنسيق النص العادي إلى هذه النطاقات باستثناء الاتصال بـ secure.example.com. من خلال إدراج الإعدادات الخاصة بـ secure.example.com داخل الإعدادات الخاصة بـ example.com، ليس عليك تكرار trust-anchors.

يوضّح المقتطف أدناه شكل هذا التداخل في res/xml/network_security_config.xml: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">example.com</domain>
        <trust-anchors>
            <certificates src="@raw/my_ca"/>
        </trust-anchors>
        <domain-config cleartextTrafficPermitted="false">
            <domain includeSubdomains="true">secure.example.com</domain>
        </domain-config>
    </domain-config>
</network-security-config>

تنسيق ملف الإعداد

تستخدم ميزة "إعداد أمان الشبكات" تنسيق ملف XML. تظهر البنية العامة للملف في نموذج الرمز البرمجي التالي: 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="..."/>
            ...
        </trust-anchors>
    </base-config>

    <domain-config>
        <domain>android.com</domain>
        ...
        <trust-anchors>
            <certificates src="..."/>
            ...
        </trust-anchors>
        <pin-set>
            <pin digest="...">...</pin>
            ...
        </pin-set>
    </domain-config>
    ...
    <debug-overrides>
        <trust-anchors>
            <certificates src="..."/>
            ...
        </trust-anchors>
    </debug-overrides>
</network-security-config>

توضّح الأقسام التالية بنية ملف ملف وتفاصيل أخرى عنه.

<network-security-config>

يمكن أن تتضمّن ما يلي:
0 أو 1 من <base-config>
أي عدد من <domain-config>
0 أو 1 من <debug-overrides>

<base-config>

البنية: 
<base-config cleartextTrafficPermitted=["true" | "false"]>
    ...
</base-config>
يمكن أن تتضمّن ما يلي:
<trust-anchors> <certificateTransparency>
description:
الإعدادات التلقائية المستخدَمة من قِبل جميع عمليات الربط التي لا تقع وجهتها ضمن نطاق domain-config

وبالنسبة إلى أي قيم لم يتم ضبطها، يتم استخدام القيم التلقائية للمنصة.

في ما يلي الإعدادات التلقائية للتطبيقات التي تستهدف الإصدار 9 من نظام التشغيل Android (المستوى 28 من واجهة برمجة التطبيقات) والإصدارات الأحدث: 

<base-config cleartextTrafficPermitted="false">
    <trust-anchors>
        <certificates src="system" />
    </trust-anchors>
</base-config>

في ما يلي الإعدادات التلقائية للتطبيقات التي تستهدف الإصدار 7.0 من نظام التشغيل Android (المستوى 24 لواجهة برمجة التطبيقات) إلى الإصدار 8.1 (المستوى 27 لواجهة برمجة التطبيقات): 

<base-config cleartextTrafficPermitted="true">
    <trust-anchors>
        <certificates src="system" />
    </trust-anchors>
</base-config>

في ما يلي الإعدادات التلقائية للتطبيقات التي تستهدف الإصدار 6.0 من نظام التشغيل Android (المستوى 23 من واجهة برمجة التطبيقات) والإصدارات الأقدم: 

<base-config cleartextTrafficPermitted="true">
    <trust-anchors>
        <certificates src="system" />
        <certificates src="user" />
    </trust-anchors>
</base-config>

<domain-config>

البنية:
<domain-config cleartextTrafficPermitted=["true" | "false"]>
    ...
</domain-config>
يمكن أن تتضمّن ما يلي:
‫
1 أو أكثر <domain>
0 أو 1 <certificateTransparency>
0 أو 1 <trust-anchors>
0 أو 1 <pin-set>
أي عدد من <domain-config>
المُدمجة
description:
الإعداد المستخدَم للاتصال بوجهات محدّدة، كما هو محدّد من قِبل عناصر domain.

يُرجى العِلم أنّه إذا كانت هناك عناصر domain-config متعددة تغطي وجهة، يتم استخدام الإعداد الذي يتضمّن قاعدة النطاق المطابِقة الأكثر تحديدًا (الأكثر طولًا).

<domain>

البنية: 
<domain includeSubdomains=["true" | "false"]>example.com</domain>
السمات:
includeSubdomains
إذا كان "true"، تتطابق قاعدة النطاق هذه مع النطاق وجميع النطاقات الفرعية، بما في ذلك النطاقات الفرعية للنطاقات الفرعية. وبخلاف ذلك، تنطبق القاعدة فقط على المطابقات التامّة.

<certificateTransparency>

البنية:
<certificateTransparency enabled=["true" | "false"]/>
description:
في حال true، سيستخدم التطبيق سجلّات "شهادة الشفافية" للتحقّق من صحة الشهادات. عندما يستخدم التطبيق شهادته الخاصة (أو متجر المستخدم)، من المرجّح أن: الشهادة ليست عامة، وبالتالي لا يمكن التحقّق منها باستخدام شفافية الشهادات. يتم تلقائيًا إيقاف عملية إثبات الهوية في هذه الحالات. لا يزال من الممكن فرض عملية إثبات الملكية باستخدام <certificateTransparency enabled="true"/> في إعدادات النطاق. بالنسبة إلى كل <domain-config>، يتم إجراء التقييم وفقًا لهذا الترتيب:
  1. إذا كان الخيار certificateTransparency مفعّلاً، فعِّل ميزة تأكيد الحساب.
  2. إذا كان أي <trust-anchors> "user" أو مضمّنًا (أي "@raw/cert.pem")، أو أوقِف عملية إثبات الملكية.
  3. بخلاف ذلك، يمكنك الاعتماد على الإعدادات المُكتسَبة.

<debug-overrides>

البنية: 
<debug-overrides>
    ...
</debug-overrides>
يمكن أن تتضمّن ما يلي:
0 أو 1 <trust-anchors>
description:
عمليات الاستبدال التي سيتم تطبيقها عندما يكون android:debuggable هو "true"، وهو عادةً ما يكون الحال بالنسبة إلى عمليات الإنشاء غير العلنية التي يتم إنشاؤها بواسطة بيئات التطوير المتكاملة وأدوات الإنشاء. تتم إضافة مراسي الثقة المحدّدة في debug-overrides إلى جميع الإعدادات الأخرى، ولا يتم تثبيت الشهادة عندما تستخدم سلسلة شهادات الخادم أحد مراسي الثقة هذه المخصّصة فقط لتصحيح الأخطاء. إذا كان القيمة android:debuggable هي "false"، سيتم تجاهل هذا القسم بالكامل.

<trust-anchors>

البنية: 
<trust-anchors>
...
</trust-anchors>
يمكن أن تحتوي على ما يلي:
أي عدد من <certificates>
description:
مجموعة من نقاط الثقة للاتصالات الآمنة

<certificates>

البنية:
<certificates src=["system" | "user" | "raw resource"]
              overridePins=["true" | "false"] />
description:
مجموعة من شهادات X.509 لعناصر trust-anchors
السمات:
src
مصدر شهادات CA يمكن أن تكون كل شهادة واحدة مما يلي:
  • رقم تعريف مورد أولي يشير إلى ملف يحتوي على شهادات X.509 يجب ترميز الشهادات بتنسيق DER أو PEM. في حال استخدام شهادات PEM، يجب ألا يحتوي الملف على بيانات إضافية غير PEM، مثل التعليقات.
  • ‫"system" لشهادات CA المُثبَّتة مسبقًا للنظام
  • ‫"user" لشهادات CA التي يضيفها المستخدم
overridePins

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

القيمة التلقائية هي "false" ما لم يتم تحديدها في عنصر debug-overrides ، وفي هذه الحالة تكون القيمة التلقائية هي "true".

<pin-set>

البنية: 
<pin-set expiration="date">
...
</pin-set>
يمكن أن تتضمّن ما يلي:
أي عدد من <pin>
description:
مجموعة من دبابيس المفاتيح العامة لكي يكون الاتصال الآمن موثوقًا به، يجب أن يكون أحد المفاتيح العامة في سلسلة الثقة مضمّنًا في مجموعة العناصر المثبّتة. يُرجى الاطّلاع على <pin> لمعرفة تنسيق الدبابيس.
السمات:
expiration
التاريخ الذي تنتهي فيه صلاحية الدبابيس بتنسيق yyyy-MM-dd، ما يؤدي إلى إيقاف التثبيت في حال عدم ضبط السمة، لن تنتهي صلاحية أرقام التعريف الشخصي.

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

<pin>

البنية: 
<pin digest=["SHA-256"]>base64 encoded digest of X.509
    SubjectPublicKeyInfo (SPKI)</pin>
السمات:
digest
خوارزمية الملخّص المستخدَمة لإنشاء رقم التعريف الشخصي في الوقت الحالي، لا يُسمح إلا باستخدام "SHA-256".

مصادر إضافية

لمزيد من المعلومات عن إعداد أمان الشبكة، يُرجى الرجوع إلى المراجع التالية:

الدروس التطبيقية حول الترميز