تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

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

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

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

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

يوضّح المقتطف أدناه كيفية تحديد مراجع التصديق المخصّصة لتصحيح الأخطاء فقط في 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>

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

ملاحظة: لا تتوفّر ميزة "شفافية الشهادات" إلا على الإصدار 16 من نظام التشغيل Android (المستوى 36 من واجهة برمجة التطبيقات).

‫Certificate Transparency (CT) هو معيار إنترنت (RFC 6962) مصمَّم لتعزيز أمان الشهادات الرقمية. ويشترط ذلك على مراجع التصديق إرسال جميع الشهادات الصادرة إلى سجلّ علني يتم فيه تسجيلها، ما يزيد من الشفافية والمساءلة في عملية إصدار الشهادات.

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

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

البيانات غير المشفّرة

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

يعتمد السلوك التلقائي لحركة بيانات النص العادي على مستوى واجهة برمجة التطبيقات:

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

إيقاف حركة المرور بنص عادي

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

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

على سبيل المثال، قد تريد أن يضمن تطبيقك إجراء عمليات الاتصال بـ secure.example.com دائمًا عبر HTTPS لحماية حركة البيانات الحساسة من الشبكات المعادية.

<?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>

الموافقة على حركة المرور بنص عادي

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

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

على سبيل المثال، قد تريد السماح لتطبيقك بإجراء اتصالات غير آمنة بـ insecure.example.com.

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

إذا كان تطبيقك بحاجة إلى تفعيل زيارات cleartext إلى أي نطاق، اضبط cleartextTrafficPermitted="true" في base-config. يُرجى العِلم أنّه يجب تجنُّب هذا الإعداد غير الآمن كلما أمكن ذلك.

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="true">
    </base-config>
</network-security-config>

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

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

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

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

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

يوضّح المقتطف أدناه كيفية تثبيت الشهادات في 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 يجب أن تستخدم مجموعة مخصّصة من شهادات المرجع المصدّق. بالإضافة إلى ذلك، يُسمح بزيارات cleartext إلى هذه النطاقات باستثناء حالات الاتصال بـ 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 من نظام التشغيل Android (المستوى 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>، يتم التقييم حسب الترتيب التالي:

في حال تفعيل certificateTransparency، فعِّل عملية تأكيد الحساب.
إذا كان أي <trust-anchors> "user" أو مضمّنًا (أي "@raw/cert.pem")، أوقِف عملية إثبات الهوية.
بخلاف ذلك، استخدِم الإعدادات الموروثة.

<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".

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

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

تخصيص جهات إصدار الشهادات الموثوقة

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

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

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

ضبط شهادات المرجع المصدّق لتصحيح الأخطاء

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

البيانات غير المشفّرة

إيقاف حركة المرور بنص عادي

الموافقة على حركة المرور بنص عادي

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

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

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

<network-security-config>

<base-config>

<domain-config>

<domain>

<certificateTransparency>

<debug-overrides>

<trust-anchors>

<certificates>

<pin-set>

<pin>

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