حظرنا توصيل USB وحظرنا الحفظ على القرص المحلّيّ. فلماذا ما زال يمكن إخراج الملفّات؟

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

كانت الخدمة B مقيَّدة بـ«تسجيل الدخول فقط من عنوان IP العموميّ لشركة M». لماذا لا يوقف ذلك الوصول من الشبكة اللاسلكيّة للزوّار؟

لأنّ حركة الشبكة اللاسلكيّة للزوّار تمرّ أيضاً عبر NAT لجدار الحماية نفسه وتُترجَم إلى عنوان IP العموميّ نفسه قبل الخروج إلى الإنترنت. من منظور الخدمة B، الوصول من حاسوب أعمال داخل المكتب والوصول من حاسوب شخصيّ موصول بالشبكة اللاسلكيّة للزوّار في قاعة الاجتماعات يبدوان عنوان مصدر واحداً. لا يمكن التمييز. قيداً قائماً على عنوان IP المصدر ينبغي فهمه بأنّه يسمح لا بـ«هذا الجهاز فقط» بل بـ«كلّ من يشارك نقطة الخروج هذه». Wi-Fi الضيوف، وشبكات VPN بين المواقع، وبوّابات تجميع العمل عن بُعد — أيّ شيء يخرج عبر عنوان IP العموميّ نفسه — يقع داخل النطاق المسموح.

كانت الشبكة اللاسلكيّة للموظّفين فيها ترشيح عنوان MAC. ألا يُعدّ ذلك علاجاً؟

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

حتّى مع نقطة وصول مزيّفة وموقع مزيّف معدَّين، لماذا يمكن القول إنّ الموظّف لن يُخدَع؟

لأنّه ما دام الاتّصال عبر HTTPS، لا يستطيع موقع مزيّف اجتياز تحقّق شهادة الخادم. يعدّد الشكل 2 في السؤال أربعة بنود يمكن أن تظهر كتفاصيل الخطأ الناتج: غير صادرة عن مرجع تصديق موثوق؛ اسم الخادم على الشهادة يختلف عن اسم الخادم المتَّصَل به؛ ملغاة؛ ومنتهية الأجل. لا يستطيع المهاجم الحصول على شهادة شرعيّة لاسم نطاق الخدمة B، فشهادة موقعة ذاتيّاً تسقط في النقطة الأولى، وشهادة مُحصَّل عليها شرعيّاً لنطاق المهاجم تسقط في الثانية. وفق تعليق التصحيح لدى IPA، كان معدّل الإجابة الصحيحة للسؤال عن محتوى هذا التحقّق منخفضاً. لاحظوا أنّ هذه البنود الأربعة ليست متساوية الوزن. ما يوقف الهجوم فعلاً هما الأوّلان (المُصدِر والاسم) مع تاريخ الانتهاء — تتحقّق المتصفّحات من هذه دائماً. أمّا تأكيد الإلغاء فيتوقّف على التنفيذ والإعداد. Chrome مثلاً لا ينفّذ عادةً تأكيد OCSP أو CRL عبر الإنترنت؛ يستخدم بدلاً منه قائمة محدودة تُسمّى CRLSet غايتها الرئيسة الحظر الطارئ. لا تفترضوا أنّ إلغاء شهادة مضمون أن يحظرها. وإن وُزِّعت على حاسوب الأعمال شهادة جذر لمرجع تصديق داخليّ، وضُبط مفتاح ذلك المرجع الخاصّ أو إجراء الإصدار بيد مهاجم، يمرّ الفحص الأوّل أيضاً.

ماذا يحدث إن أخطأ أحدهم وكتب عنوان URL كـ «http://»؟ ماذا يفعل HSTS فعلاً؟

يعيد المتصفّح كتابة HTTP إلى HTTPS قبل الاتّصال، فتكون النتيجة مرّة أخرى خطأ شهادة خادم. HSTS آليّة يتذكّر بها المتصفّح محتوى ترويسة تلقّاها آخر مرّة اتّصل بذلك الموقع عبر HTTPS. يطلب RFC 6797 أن يستبدل وكيل المستخدم المخطّط http بـ https عندما يتضمّن عنوان URL للمضيف المستهدف مخطّط http، ويحوّل المنفذ 80 إلى 443 إن صُرِّح به. أي أنّ طلب HTTP الصريح لا يخرج من الجهاز أصلاً. والأهمّ: إن فشل تحقّق الشهادة أثناء الاتّصال بمضيف HSTS نشط، تشترط المواصفة إنهاء الاتّصال بغضّ النظر عمّا إذا كان الخطأ تحذيراً أم قاتلاً. تنصّ صراحة على عدم تقديم خيار للمستخدم مثل «هذا الاتّصال غير آمن، أأتابع؟». غير أنّ HSTS يفترض أنّ المتصفّح بلغ الموقع الحقيقيّ مرّة عبر HTTPS وتلقّى الترويسة. لا حماية إن صادف أوّل وصول من جهاز جديد تماماً موقعاً مزيّفاً. قائمة التحميل المسبق المضمَّنة في المتصفّح هي ما تملأ فجوة المرّة الأولى تلك.

ماذا يتغيّر عندما يُحفَظ المفتاح الخاصّ لشهادة العميل في TPM؟

لا يعود المفتاح الخاصّ قابلاً للإخراج من حاسوب الأعمال ذلك. مفتاح خاصّ محفوظ كملفّ على الجهاز يمكن نسخه ببساطة إلى حاسوب شخصيّ مملوك، فيمرّ ذلك الحاسوب بالمصادقة كأنّه حاسوب الأعمال. إن وُلِّد المفتاح داخل TPM وضُبط ألا يُصدَّر أبداً، تجري عمليّات مثل التوقيع كلّها داخل TPM، ولا يبلغ المفتاح نفسه نظام التشغيل ولا أيّ برمجيّة خبيثة. النتيجة أنّ حواسيب الأعمال التي منحتها الشركة وحدها تستطيع إكمال مصادقة EAP-TLS. لهذا استطاع السيّد S أن يقول «طريقة الحفظ تلك لا بأس بها». تنفيذ هذا على Windows يعني تعيين Microsoft Platform Crypto Provider كمزوّد تخزين مفاتيح لقالب الشهادة، مع عدم السماح بتصدير المفتاح الخاصّ. لاحظوا أنّ TPM يحمي فقط من نسخ المفتاح إلى جهاز آخر — ولا يفعل شيئاً لوقف من يملك ذلك الجهاز فيزيائيّاً عن استخدامه. فقدان الجهاز أو سرقته ما زال يحتاج تغطية منفصلة بتشفير المحرّك وإلغاء الشهادة.

ماذا ينبغي أن نعيد إلى ممارستنا من هذا السؤال؟

أربعة أمور. الأوّل، فكّروا في علاجات الإخراج بمسارات لا بوسائل. حظر USB ومرفقات البريد والبريد عبر الويب واحداً واحداً لا يعني شيئاً إن بقي جهاز يصل إلى الملفّات. الثاني، اكتبوا ما يسمح به قيد عنوان IP المصدر فعلاً. إن شارك Wi-Fi الضيوف أو VPN نقطة الخروج نفسها، فذلك داخل النطاق المسموح أيضاً. الثالث، اجعلوا مصادقة الشبكة اللاسلكيّة اعتماداً لكلّ جهاز. المفتاح المشترك مسبقاً سرّ مشترك يحمله الجميع متماثلاً، فإن سرّبه واحد سُرِّب اعتماد الجميع. الانتقال إلى EAP-TLS بشهادات عميل، وإبقاء المفتاح الخاصّ لا يخرج من TPM، يربط الاعتماد بالجهاز. الرابع، احذفوا تكويناً لم تعد تستخدمونه. السؤال الفرعيّ الأخير في هذه المسألة يطلب من المرشّح تعداد كلّ إعداد واجهة VLAN وقاعدة ترشيح جدار الحماية المتبقّية بعد تقاعد الشبكة اللاسلكيّة للزوّار — ووفق تعليق التصحيح لدى IPA كان معدّل الإجابة الصحيحة مرتفعاً، لكن قلّة من المنظّمات تنفّذ هذا فعلاً في الممارسة.

شرح اختبار اختصاصي ضمان أمن معالجة المعلومات خريف ريوا 5 سؤال بعد الظهر 2 ── ملفات تخرج عبر Wi-Fi الزوّار

1 Aug، 2026 03:00 · غو كومورا · اختصاصي ضمان أمن معالجة المعلومات, اختبار اختصاصي الأمن المسجَّل, شبكة لاسلكيّة, شهادات خادم, HSTS, EAP-TLS, RADIUS, TPM, أمن المعلومات, منع تسرّب البيانات, IPA, مراجعة تصميم

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

ومع ذلك، يمكن إخراج ملفّات الأعمال.

سؤال بعد الظهر 2 في اختبار اختصاصي ضمان أمن معالجة المعلومات خريف السنة الماليّة 5 من ريوا، يضع شركة ملابس M نفّذت كلّ ما سبق مسرحاً، ويطلب من المرشّحين إيجاد الثقوب المتبقّية¹. هذا المقال الثاني في سلسلة تتبع شرح السؤال 1 (XSS المخزَّن)، والنطاق الذي يغطّيه ينتقل من تطبيق الويب إلى الشبكة الداخليّة ومصادقة الأجهزة.

حيث سأل السؤال 1 «أين اُجتُيزت العلاجات المصفوفة أمام تطبيق الويب»، يسأل السؤال 2 «أيّ نطاق قصد تصميم العلاجات حمايته فعلاً». لا علاج من علاجات M خاطئ. لكن افحصوا الحدّ الذي قُصد أن يغطّيه كلّ واحد، واحداً واحداً، والمساحة خارجها مباشرة متروكة مفتوحة.

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

1. الخلاصة أوّلاً

الثغرة كانت قاعة الاجتماعات. حظرت شركة M إدخال الحواسيب الشخصيّة المملوكة، لكنّ المحظور كان منطقة المكاتب فقط، وقاعة الاجتماعات مستثناة. في قاعة الاجتماعات تطير الشبكة اللاسلكيّة للموظّفين والشبكة اللاسلكيّة للزوّار كلتاهما
مسارا إخراج الموظّف اثنان. طريقة انتحال عنوان MAC والاتّصال بالشبكة اللاسلكيّة للموظّفين، وطريقة الاتّصال بالشبكة اللاسلكيّة للزوّار فحسب. الثانية أسهل بكثير، وما يلزم هو المفتاح المشترك مسبقاً الموزَّع على الزوّار فقط
كانت الخدمة السحابيّة للتخزين (الخدمة B) مقيَّدة بـ«تسجيل الدخول فقط من عنوان IP العموميّ لشركة M». لكن حركة الشبكة اللاسلكيّة للزوّار تُترجَم أيضاً عبر NAT نفسه إلى عنوان IP العموميّ نفسه، فيمرّ هذا القيد. قيد عنوان IP المصدر إعداد يسمح لا بالجهاز بل بـكلّ من يشارك نقطة الخروج
نقطة وصول مزيّفة + موقع مزيّف من مهاجم خارجيّ يتوقّفان بـتحقّق شهادة الخادم. ما يعمل هما «هل أصدرها مرجع تصديق موثوق» و«هل اسم الخادم على الشهادة يطابق جهة الاتّصال». وفق تعليق التصحيح لدى IPA، كان معدّل الإجابة الصحيحة للسؤال الذي يطلب هاتين النقطتين منخفضاً
حتّى إن كُتب خطأ http://، يستبدل HSTS بـ HTTPS ثمّ يتّصل، فيكون خطأ شهادة أيضاً. وفوق ذلك، على مضيف HSTS نشط لا يجوز تقديم خيار للمستخدم بتجاهل التحذير والمتابعة
وظيفة مشاركة الملفّات الشرعيّة نفسها تصير مسار إخراج. يكفي تعيين عنوان بريد خاصّ بالموظّف كعنوان المشارك الخارجيّ. كانت موافقة الرئيس موجودة، لكن كان ثمّة رئيس لا يؤكّد الوجهة
أعمدة العلاج ثلاثة. اجعلوا الشبكة اللاسلكيّة للموظّفين EAP-TLS وصادِقوا بشهادة عميل لكلّ جهاز، وضعوا المفتاح الخاصّ في TPM بحيث لا يُخرَج من حاسوب الأعمال. افصلوا الشبكة اللاسلكيّة للزوّار عن شبكة شركة M (أو فرّقوا عنوان IP العموميّ لنقطة الخروج). ثمّ احذفوا VLAN وقواعد الترشيح وSSID التي لم تعد تُستخدم

خريطة المعرفة لهذه المقالة

هذا المقال شرح يتّخذ سؤال بعد الظهر 2 في اختبار اختصاصي ضمان أمن معالجة المعلومات خريف السنة الماليّة 5 من ريوا مادّة، ويرتّب مراجعة تصميم حول الشبكة اللاسلكيّة وشهادة الخادم. WPA2-PSK الذي يشترك فيه الجميع في المفتاح نفسه يملك ضعف أنّ من يعرف المفتاح يستطيع إقامة نقطة وصول مزيّفة (evil twin) لا تُميَّز عن الحقيقيّة، لكن بتحقّق شهادة الخادم وHSTS لا ينعقد تسجيل الدخول إلى موقع مزيّف. في إخراج الموظّف، علاج انتحال عنوان MAC هو EAP-TLS الذي يصادق بشهادة عميل وRADIUS، وعلاج اجتياز قيد عنوان IP المصدر عبر نقطة خروج NAT مشتركة بين عدّة شبكات هو فصل شبكة الزوّار. حفظ المفتاح الخاصّ في TPM بحيث لا يُخرَج هو المفتاح الذي يجعل المصادقة بالشهادة تعمل فعلاً.

flowchart LR
    accTitle: خريطة معرفة اختبار اختصاصي ضمان أمن معالجة المعلومات خريف ريوا 5 سؤال بعد الظهر 2 (الشبكة اللاسلكيّة وشهادة الخادم)
    accDescr: مخطّط يبيّن كيف يجرّ ضعف المفتاح المشترك في WPA2-PSK انتحال عنوان MAC وهجوم evil twin، وكيف يمنع تحقّق شهادة الخادم وHSTS تسجيل الدخول إلى موقع مزيّف، وكيف تحقّق EAP-TLS مع RADIUS ومفتاح خاصّ محفوظ في TPM مصادقة لكلّ جهاز، وحدود قيد عنوان IP المصدر المشترك عبر NAT وعلاجه.
    wpa2_psk["WPA2-PSK"]
    eap_tls["EAP-TLS"]
    evil_twin["هجوم evil twin (التوأم الشيطانيّ)"]
    phishing["تصيّد (phishing)"]
    mac_address_filtering["ترشيح عنوان MAC"]
    mac_address_spoofing["انتحال عنوان MAC"]
    server_certificate_validation["تحقّق شهادة الخادم"]
    certificate_chain["سلسلة الشهادات"]
    root_ca["شهادة مرجع التصديق الجذريّ"]
    certificate_revocation_check["تأكيد إلغاء الشهادة"]
    trust_anchor_risk["خطر إساءة استخدام نقطة انطلاق الثقة"]
    hsts["HSTS (HTTP Strict Transport Security)"]
    hsts_preload_list["قائمة التحميل المسبق لـ HSTS"]
    client_certificate["شهادة العميل"]
    radius["RADIUS"]
    ieee_802_1x["IEEE 802.1X (EAP over LAN)"]
    network_policy_server["خادم سياسة الشبكة (NPS)"]
    private_key["المفتاح الخاصّ"]
    tpm["TPM"]
    key_exfiltration_risk["خطر إخراج المفتاح الخاصّ"]
    shared_egress_ip_bypass["تجاوز قيد IP المصدر بعنوان خروج مشترك"]
    nat["NAT (ترجمة عنوان الشبكة)"]
    guest_network_isolation["فصل شبكة الزوّار"]
    unused_config_cleanup["حذف إعداد لم يعد يُستخدم"]
    source_ip_restriction["قيد عنوان IP المصدر"]
    wpa2_psk -->|"قد يسبّب"| evil_twin
    evil_twin -.->|"قد يسبّب"| phishing
    mac_address_filtering -->|"غير موصى به لـ"| mac_address_spoofing
    eap_tls -->|"موصى به لـ"| mac_address_spoofing
    server_certificate_validation -.->|"يمنع"| phishing
    server_certificate_validation -->|"يستخدم"| certificate_chain
    server_certificate_validation -->|"يستخدم"| root_ca
    server_certificate_validation -.->|"يستخدم"| certificate_revocation_check
    root_ca -.->|"قد يسبّب"| trust_anchor_risk
    hsts -.->|"يمنع"| phishing
    hsts -->|"يشترط"| server_certificate_validation
    hsts_preload_list -.->|"يخفّف"| evil_twin
    eap_tls -->|"يستخدم"| client_certificate
    eap_tls -.->|"يستخدم"| radius
    eap_tls -.->|"يستخدم"| ieee_802_1x
    network_policy_server -->|"ينفّذ"| radius
    client_certificate -->|"يشترط"| private_key
    private_key -.->|"يُحفظ في"| tpm
    tpm -.->|"يمنع"| key_exfiltration_risk
    shared_egress_ip_bypass -.->|"يشترط"| wpa2_psk
    nat -->|"قد يسبّب"| shared_egress_ip_bypass
    guest_network_isolation -->|"يمنع"| shared_egress_ip_bypass
    guest_network_isolation -->|"ينبغي أن يسبق"| unused_config_cleanup
    source_ip_restriction -.->|"لا يتوافق مع"| nat

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 24، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. عن المادّة ── المصدر ومعاملتها في هذا المقال

المسألة المتناوَلة هي التالية.

المصدر: اختبار اختصاصي ضمان أمن معالجة المعلومات خريف السنة الماليّة 5 من ريوا، بعد الظهر، السؤال 2

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

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

تقابل الأسئلة الفرعية وهذا المقال

يجوز البدء من السؤال الفرعيّ الذي تريدون حلّه.

السؤال الفرعيّ	ما يُسأل عنه (عدد الأحرف)	قسم المقال المقابل
1(1)	ما يلزم لتسجيل الدخول إلى الخدمة B (الفراغان a وb)	الفصل 4
1(2)	تفاصيل خطأ شهادة الخادم المعروض (الفراغان c وd، كلّ منهما في 40 حرفاً أو أقلّ)	الفصل 4 «ماذا ينظر إليه تحقّق الشهادة»
1(3)	حركة متصفّح الويب حتّى ما قبل عرض الخطأ عند تفعيل HSTS (60 حرفاً أو أقلّ)	الفصل 5
2(1)	طريقة إساءة استخدام وظيفة مشاركة الملفّات (40 حرفاً أو أقلّ)	الفصل 6
2(2)	ما يُغيَّر في الطريقة 1 (الفراغ e)	الفصل 7 «الطريقة 1»
3(1)	البروتوكول فوق UDP الذي يستخدمه خادم المصادقة في EAP	الفصل 8
3(2)	ما يقابل شهادة العميل (الفراغ f)	الفصل 8 «إجابة خاطئة أشار إليها تعليق التصحيح»
3(3)	غرض الحفظ في TPM (الفراغ g، 20 حرفاً أو أقلّ)	الفصل 8 «ماذا يتغيّر بالوضع في TPM»
3(4)	سبب أنّ طريقة الحفظ تلك لا بأس بها (40 حرفاً أو أقلّ)	الفصل 8 «لماذا يمكن القول «لا بأس»»
3(5)	محتوى تغيير إعداد NAT لجدار الحماية (70 حرفاً أو أقلّ)	الفصل 9
3(6)	خادم وجهة الاتّصال الذي يصير غير لازم (الفراغ h)	الفصل 10
3(7)	أرقام البنود التي ينبغي حذفها من الجدولين 3 و4	الفصل 10

وصف كتيّب المسألة ومعاملته في هذا المقال

لكي يمكن مقابلة الأصل، نلخّص أين عولج ماذا وكيف.

وصف كتيّب المسألة	المعاملة في هذا المقال	موضع النشر
الشكل 1 (تكوين شبكة شركة M)	لم يُعد نشره كما هو؛ كتبنا رسماً مبسَّطاً مقصوراً على النطاق اللازم للشرح	الفصل 3
الجدول 1 (لمحة عناصر التكوين) والجدول 2 (قواعد الأمن)	ملخَّص وفق وصف الأصل	الفصل 3
الجدول 3 (إعداد واجهة VLAN لجدار الحماية) والجدول 4 (إعداد ترشيح جدار الحماية) والجدول 5 (إعداد AP-5)	لم يُعد نشره كما هو؛ لخّصنا في النصّ والجداول البنود اللازمة لشرح السؤال فقط. لم نورد سلسلة المفتاح المشترك مسبقاً	الفصول 7 و9 و10
الشكل 2 (تفاصيل رسالة الخطأ)	اقتباس البنود الأربعة بشكل ملأ الفراغات وفق مثال الإجابة	الفصل 4
حوار السيّدة Y والسيّد S في النصّ	ملخّص يحفظ الجوهر	الفصول 4–9
نصّ كلّ سؤال فرعيّ	ملخّص يحفظ الجوهر (شروط مثل حدّ الأحرف بقيم الأصل)	صدر كلّ فصل
مثال الإجابة	مثال الإجابة الذي نشرته IPA³	كلّ فصل
تعليق التصحيح	المواضع ذات الصلة من تعليق التصحيح الذي نشرته IPA⁴	الفصول 4 و8 و10

3. مسرح المسألة ── ما كانت شركة M «قد فعلته أصلاً»

شركة M شركة تابعة لشركة L، تعمل في صناعة الملابس، وعدد موظّفيها 100. مبنى المكتب يطلّ على شارع كبير في طوكيو كثير المرور. هذه الجملة تفعل لاحقاً.

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

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

الحادث السابق كان مساراً «خادم ملفّات داخليّ» → «USB»، فسُدّ طرفا ذلك المسار. المنطق مستقيم.

تكوين الشبكة

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

برسم النطاق اللازم للشرح فقط، الشكل التالي.

flowchart LR
accTitle: تكوين شبكة شركة M
accDescr: تُترجَم الشبكة اللاسلكيّة للزوّار وللموظّفين وشبكة الخوادم عبر NAT جدار الحماية نفسه إلى عنوان IP عموميّ واحد ثم تخرج إلى الخدمة B
    subgraph M["الشبكة الداخليّة لشركة M"]
        direction TB
        G["شبكة لاسلكيّة للزوّار<br/>192.168.10.0/24<br/>(نقطة وصول قاعة الاجتماعات فقط)"]
        E["شبكة لاسلكيّة للموظّفين<br/>192.168.20.0/24<br/>(منطقة المكاتب وقاعة الاجتماعات)"]
        S["شبكة الخوادم<br/>192.168.30.0/24<br/>DHCP وDNS والدليل"]
        FW["جدار الحماية<br/>NAT يترجم المصدر<br/>إلى عنوان IP<br/>عموميّ واحد"]
        G --> FW
        E --> FW
        S --> FW
    end
    FW --> B["الخدمة B<br/>(تخزين سحابيّ)"]
    FW --> I["الإنترنت"]

الشكل 1: شبكات الزوّار والموظّفين والخوادم الثلاث تخرج إلى الإنترنت عبر NAT جدار حماية واحد بعنوان IP عموميّ واحد.

المواصفات التي ينبغي تثبيتها كالتالي.

عنصر التكوين	من المواصفات ما يفعل في السؤال
نقاط وصول الشبكة اللاسلكيّة	أسلوب المصادقة مشترك لكلّ نقاط الوصول وهو WPA2-PSK (المفتاح المشترك مسبقاً مختلف بين الزوّار والموظّفين). نقطة وصول قاعة الاجتماعات وحدها تحمل SSID الزوّار وSSID الموظّفين كليهما. شبكة الزوّار تبثّ SSID، لكن شبكة الموظّفين عطّلت بثّ SSID. وفوق ذلك ترشيح عنوان MAC مضبوط على الشبكة اللاسلكيّة للموظّفين فقط، فلا يتّصل إلا حواسيب الأعمال التي سجّلها قسم نظم المعلومات مسبقاً
الخدمة B	الوصول عبر HTTPS، وHSTS مفعَّل. تسجيل الدخول بهويّة مستخدم وكلمة مرور لكلّ موظّف. بهويّة مستخدم مخصَّصة لموظّفي شركة M، تسجيل الدخول ممكن من عنوان IP عموميّ واحد لشركة M فقط. ثمّة وظيفة مشاركة ملفّات: يُحدَّد الملفّ المراد مشاركته وعنوان بريد المشارك الخارجيّ ويُقدَّم طلب موافقة الرئيس، وعند الموافقة تُصدَر وصلة مشاركة خارجيّة وتُرسَل تلقائيّاً بالبريد إلى المشارك الخارجيّ. وصلة المشاركة الخارجيّة لا تُعلَم لصاحبها ولا للرئيس. يستطيع المشارك الخارجيّ التنزيل دون تسجيل دخول. تتضمّن الوصلة سلسلة عشوائيّة صعبة التخمين، وأجلها يوم واحد
حاسوب الأعمال	يُستخدم للعمل اليوميّ، والوصول إلى الخدمة B، وتصفّح الإنترنت، وإرسال واستقبال البريد الإلكترونيّ. يحمل TPM 2.0
خادم الدليل	إلى جانب وظيفة الدليل، يملك وظيفة تثبيت برمجيّات وشهادات عميل على حواسيب الأعمال
جدار الحماية	نوع تفتيش حزم ذو حالة. وظيفة NAT مفعَّلة، وحركة الخروج إلى الإنترنت من كلّ شبكة داخليّة تُترجَم إلى عنوان IP عموميّ واحد

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

هل لاحظتم أنّ القاعدة الثانية مكتوب فيها «إلى منطقة المكاتب»؟ قاعة الاجتماعات غير مكتوبة.

كيف تتقدّم هذه المسألة

تؤكّد السيّدة Y من قسم نظم المعلومات، بدعم السيّد S وهو اختصاصي ضمان أمن معالجة المعلومات (اختصاصي أمن مسجَّل) في الشركة الأمّ L، ما إذا كانت التدابير كافية ضدّ إخراج الملفّات من الخدمة B. يقسم الاثنان النظر إلى إخراج مهاجم خارجيّ وإخراج موظّف. السؤال 1 للأوّل، والسؤال 2 للثاني، والسؤال 3 لوضع العلاجات.

4. Wi-Fi مزيّف وموقع مزيّف ── السؤالان 1(1) و1(2)

أوّل ما تطرحه السيّدة Y سيناريو يتّصل فيه زائر سبق أن استخدم الشبكة اللاسلكيّة للزوّار، كمهاجم، بالشبكة اللاسلكيّة للزوّار من قرب شركة M، ويصل إلى الخدمة B.

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

جواب السيّد S هنا واضح. لتسجيل الدخول إلى الخدمة B يلزم [a] هويّة مستخدم و[b] كلمة مرور. هذا مثال إجابة السؤال 1(1) (بأيّ ترتيب). الاتّصال بالشبكة اللاسلكيّة نفسه لا يعني تسجيل الدخول إلى الخدمة B.

نقطة وصول مزيّفة وموقع مزيّف

عندئذٍ تطرح السيّدة Y سيناريو أعمق بدرجة. ماذا عن إعداد نقطة وصول مزيّفة بالإعداد نفسه لنقطة وصول الشبكة اللاسلكيّة للزوّار، وموقع مزيّف بعنوان URL الخدمة B نفسه، والتلاعب بإعداد DNS لسرقة هويّة المستخدم وكلمة المرور. إن وُضعت نقطة الوصول المزيّفة قرب شركة M، قد يتّصل موظّف شركة M خطأ بنقطة الوصول المزيّفة بحاسوب الأعمال، ويحاول الوصول إلى الخدمة B فيصل إلى الموقع المزيّف ويسجّل الدخول.

ما يُسمّى evil twin (التوأم الشيطانيّ). إن أقمتم نقطة وصول بـ SSID نفسه والمفتاح المشترك مسبقاً نفسه للشبكة اللاسلكيّة للزوّار، لا يمكن تمييزها من الجهاز عن نقطة الوصول الشرعيّة. ما يستطيع الجهاز التحقّق منه عن نقطة الوصول في WPA2-PSK هو «معرفة المفتاح المشترك مسبقاً نفسه» فقط. نقطة وصول لا تعرف المفتاح لا تستطيع إكمال إجراء الاتّصال، لكن بالمقابل، من يعرف المفتاح يصير «نقطة وصول حقيقيّة» أيّاً كان. ما دام مفتاحاً يُوزَّع على الزوّار، ينبغي افتراض أنّه موزَّع على المهاجم أيضاً.

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

شهادة الخادم هذه ليست شهادة خادم صادرة عن مرجع تصديق موثوق (الفراغ c)

اسم الخادم المكتوب على شهادة الخادم هذه يختلف عن اسم خادم جهة الاتّصال (الفراغ d)

شهادة الخادم هذه ملغاة

شهادة الخادم هذه منتهية الأجل

الأسفلان مكتوبان أصلاً في كتيّب المسألة، والإجابة عن الأعلىين (الفراغان c وd، كلّ منهما في 40 حرفاً أو أقلّ، بأيّ ترتيب) هي السؤال 1(2).

sequenceDiagram
accTitle: نقطة الوصول المزيّفة والموقع المزيّف يتوقّفان بتحقّق الشهادة
accDescr: عندما يتّصل الموظّف عبر HTTPS عبر نقطة وصول مزيّفة يظهر خطأ لأنّها ليست صادرة عن مرجع تصديق موثوق أو لأنّ اسم الخادم لا يطابق، فلا تُعرض شاشة تسجيل الدخول
    autonumber
    participant U as حاسوب أعمال الموظّف
    participant F as نقطة وصول وموقع مزيّفان<br/>(المهاجم)
    participant B as الخدمة B (شرعيّة)

    Note over F: إقامة نقطة وصول بـ SSID نفسه<br/>والمفتاح المشترك مسبقاً نفسه لشبكة الزوّار
    U->>F: اتّصال خطأ بنقطة الوصول المزيّفة
    Note over F: التلاعب بـ DNS وتوجيه اسم نطاق<br/>الخدمة B إلى الموقع المزيّف
    U->>F: اتّصال بعنوان URL الخدمة B عبر HTTPS
    F-->>U: شهادة خادم الموقع المزيّف
    Note over U: رسوب في التحقّق<br/>· ليست صادرة عن مرجع تصديق موثوق<br/>· اسم الخادم على الشهادة يختلف عن جهة الاتّصال
    Note over U: عرض خطأ بأنّ الاتّصال غير آمن<br/>شاشة تسجيل الدخول لا تُعرض
    Note over U,B: مع الخدمة B الشرعيّة<br/>لا اتّصال أصلاً

الشكل 2: الوصول عبر HTTPS عبر نقطة وصول مزيّفة يرسب في تحقّق شهادة الخادم؛ فلا تُعرض شاشة تسجيل الدخول.

ماذا ينظر إليه تحقّق الشهادة

يكتب تعليق التصحيح عن هذا السؤال كالتالي.

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

أي أنّ قلّة استطاعت تفكيك ما يُؤكَّد فيُرسب إلى أربعة بنود، وإن عرفوا أنّ «خطأ شهادة يظهر». بترتيب بنود الشكل 2 من منظور «تأكيد أيّ غرض» يصير التالي.

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

من منظور المهاجم، الأعلىان جدار لا يُتجاوز. صنع شهادة موقعة ذاتيّاً يسقط في الأوّل، وتحصيل شهادة مجّانيّة شرعيّاً لنطاقه (مثلاً b-service.example.net) يسقط في الثاني لأنّ جهة الاتّصال نطاق الخدمة B. شهادة لاسم نطاق الخدمة B لا تُحصَّل ما لم تُدار نطاق الخدمة B. يمكن القول إنّ جمع هاتين النقطتين هو جوهر آليّة الشهادة.

إجراء تحقّق مسار الشهادة يحدّده RFC 5280⁵، وإجراء مطابقة الاسم المكتوب على الشهادة مع اسم جهة الاتّصال يحدّده RFC 6125⁶.

البنود الأربعة لا تعمل بالقوّة نفسها

هنا نفصل جواب الاختبار عن سلوك المتصفّح الفعليّ. البنود الأربعة أعلاه يعدّدها الشكل 2 في المسألة كـ«تفاصيل خطأ قد تُعرض»، فلا تُقرأ بأنّ كلّ متصفّح يفحص الأربعة باليقين نفسه.

المُصدِر واسم الخادم والأجل الثلاثة تُحكَم بمعلومات في اليد لحظة تلقّي الشهادة، فتُتحقَّق حتماً. وما يوقف هجوم هذه المسألة أيضاً هذه الثلاثة.

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

Chrome لا ينفّذ عادةً تأكيد OCSP أو CRL عبر الإنترنت. بدلاً من ذلك يوزّع قائمة محدودة تُسمّى CRLSet غايتها الرئيسة حظر الشهادات بسرعة في الطوارئ، وما يُجلَب من قوائم إلغاء مراجع التصديق جزء منها فقط⁷
حتّى في تنفيذ يستعلم OCSP، يُستخدم على نطاق واسع تكوين يمرّر الاتّصال عندما لا تُحصَّل إجابة (soft-fail)

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

مطبّ في الممارسة ── من يقرّر «مرجع التصديق الموثوق»

ما يلي خارج نصّ المسألة. الأوّل في الجدول أعلاه يتوقّف على بما يثق ذلك الجهاز. قائمة الثقة يحملها المتصفّح أو نظام التشغيل، وعلى Windows مخزن الشهادات «مراجع التصديق الجذريّة الموثوقة» هو ذلك.

أي أنّ الفحص الأوّل يمرّ في أوضاع مثل التالية.

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

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

للفحص الثاني (تطابق اسم الخادم) نقطة انتباه منفصلة في الممارسة. الشهادة عاجزة أمام هجوم يخطئ فيه المستخدم قراءة اسم النطاق. إن حصّل مهاجم نطاقاً ملتبساً مثل b-serv1ce.example.com، وحصّل شهادة شرعيّة لذلك النطاق، لا يُخرج المتصفّح خطأ. ما تضمنه الشهادة هو «تطابق اسم خادم جهة الاتّصال مع اسم الخادم على الشهادة»، لا «أنّ اسم الخادم ذلك هو الطرف الذي قصده المستخدم». الآليّة التي لا تعتمد الخطوة الأخيرة تلك على عين المستخدم هي أسلوب يتحقّق فيه الأصل على جانب أداة المصادقة مثل مفاتيح المرور (WebAuthn). التفاصيل في لماذا مفاتيح المرور آمنة.

5. سبب التوقّف حتّى إن كُتب `http://` ── السؤال 1(3)

تصرّ السيّدة Y. إن اتّصل الموظّف بنقطة الوصول المزيّفة وأدخل عنوان URL الخدمة B في متصفّح الويب مخطئاً بـ http://، ألا تُعرض رسالة الخطأ، تقول.

شكّ معقول. إن اتّصل بـ HTTP، لا تظهر شهادة الخادم أصلاً. يبدو أنّ الموقع المزيّف يستطيع عرض شاشة تسجيل الدخول بلا أيّ خطأ.

جواب السيّد S «لا بأس. HSTS مفعَّل، فتُعرض في تلك الحالة أيضاً رسالة الخطأ نفسها آنفاً». يسأل السؤال 1(3) عن حركة متصفّح الويب حتّى ما قبل عرض رسالة الخطأ هذه في 60 حرفاً أو أقلّ.

مثال الإجابة «يستبدل وصول HTTP بوصول HTTPS ثمّ يصل. بعد ذلك يتلقّى شهادة خادم من الموقع المزيّف».

ماذا يحدث داخل المتصفّح

HSTS (HTTP Strict Transport Security) آليّة يعلن بها الموقع بترويسة Strict-Transport-Security «من الآن فصاعداً إلى هذا المضيف دائماً عبر HTTPS»، ويتذكّرها المتصفّح. يحدّدها RFC 6797⁸.

عندما يحاول الوصول إلى مضيف يتذكّره بـ http://، يتحرّك المتصفّح كالتالي.

يستبدل مخطّط العنوان من http إلى https. إن صُرِّح بالمنفذ 80 يحوّله إلى 443 (RFC 6797 القسم 8.3)
نتيجة لذلك يتّصل عبر HTTPS. عندئذٍ DNS مُتلاعَب به فجهة الاتّصال الموقع المزيّف
يتلقّى شهادة خادم من الموقع المزيّف
يفشل التحقّق، ويكون الخطأ نفسه كما في الفصل 4

المهمّ أنّ استبدال 1 يكتمل قبل الخروج إلى الشبكة. طلب HTTP الصريح لا يُرسَل أصلاً. لذا لا تحدث حالة «اتّصلنا بـ HTTP فلم تظهر شهادة».

لا يمكن الضغط على «تجاهل وتابع»

خاصّيّة أخرى لـ HSTS كبيرة جدّاً عمليّاً. يطلب القسم 8.4 من RFC 6797، عند وقوع خطأ أثناء إقامة قناة اتّصال آمنة مع مضيف HSTS نشط، إنهاء الاتّصال سواء كان تحذيراً أم قاتلاً. والقسم 12.1 يصف ذلك السلوك بـ “No User Recourse” (عدم إعطاء المستخدم وسيلة تجنّب)، ويقول إنّه لا يجوز تقديم خيار مثل «هذا الاتّصال غير آمن لكن هل تتابع».

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

مقدّمة HSTS ── المرّة الأولى وحدها لا تُحمى

غير أنّ لـ HSTS مقدّمة. كما يحدّد القسم 8.1 من RFC 6797، يصير مضيف «مضيف HSTS معروفاً» عندما يتلقّى وكيل المستخدم حقل ترويسة Strict-Transport-Security فوق قناة اتّصال آمنة. أي يلزم أن يكون ذلك المتصفّح قد بلغ الموقع الشرعيّ مرّة عبر HTTPS.

لذا لا حماية في الحالات التالية.

على حاسوب أعمال وُزِّع للتوّ، كان أوّل وصول فجأة تحت نقطة وصول مزيّفة
أُعيد إنشاء ملفّ تعريف المتصفّح، أو مُحيت بيانات التصفّح فمُحي سجلّ HSTS أيضاً
انتهى أجل السجلّ (max-age)

ما يملأ مشكلة المرّة الأولى هذه هو قائمة التحميل المسبق لـ HSTS. إن وُجد في قائمة نطاقات مضمَّنة مسبقاً في المتصفّح، يُفرَض HTTPS حتّى بلا وصول سابق.

غير أنّه إن نظرتم في تسجيل موقعكم، أكّدوا الشروط أوّلاً. متطلّبات التسجيل كالتالي⁹.

تقديم شهادة صالحة
إن كان الاستماع على المنفذ 80، إعادة التوجيه من HTTP إلى HTTPS على المضيف نفسه
تقديم كلّ النطاقات الفرعيّة عبر HTTPS (بما فيه www إن وُجد سجلّ DNS)
إعادة ترويسة Strict-Transport-Security على النطاق الأساس بـ max-age 31536000 ثانية (سنة) فأكثر، مع includeSubDomains وpreload

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

والإلغاء ليس سهلاً. طلب الحذف يُقبل عموماً، لكن وصول التغيير إلى متصفّحات المستخدمين يستغرق أشهراً، ولا ضمان لمتصفّحات غير Chrome⁹. أسلم أن تُقبلوا على التحميل المسبق باعتباره إعداداً ليس «إن أخطأنا نعيده».

بالمقابل كطرف يستخدم، ما إذا كانت خدمة سحابيّة تُستخدم في العمل تدعم HSTS نقطة تأكيد جائزة عند الاختيار.

6. في اللحظة التي تصير فيها الموافقة شكليّة، تصير وظيفة المشاركة مسار إخراج ── السؤال 2(1)

من هنا ننتقل إلى النظر في إخراج الموظّف.

يؤكّد السيّد S أوّلاً تشغيل وظيفة مشاركة الملفّات. هل يؤكّد الرئيس عنوان بريد الوجهة والملفّ حقّاً قبل الموافقة. جواب السيّدة Y «يبدو أنّ ثمّة رؤساء لا يستطيعون التأكيد».

عندئذٍ ما يشير إليه السيّد S هو السؤال 2(1). يجيبون تحديداً في 40 حرفاً أو أقلّ عن طريقة إساءة استخدام وظيفة مشاركة الملفّات لجعل تنزيل الملفّ ممكناً من خارج شركة M.

مثال الإجابة «تعيين عنوان بريد إلكترونيّ خاصّ بالموظّف نفسه كعنوان بريد المشارك الخارجيّ».

التصميم صحيح، والتشغيل فيه ثغرة

وظيفة مشاركة الملفّات في الخدمة B مصنوعة بتفكير جيّد.

المشاركة تحتاج موافقة الرئيس
وصلة المشاركة الخارجيّة لا تُعلَم لصاحبها ولا للرئيس. لا يستطيع صاحب المشاركة نفسه إعادة توجيه الوصلة لإخراجها
تتضمّن الوصلة سلسلة عشوائيّة صعبة التخمين، وأجلها يوم واحد

الثاني خصوصاً تصميم واعٍ بالإخراج من الداخل. ومع ذلك يُكسَر. إن جعلتم الوجهة أنفسكم، تصل الوصلة «غير المُعلَمة لصاحبها» إلى يد صاحبها.

وشرط انفتاح هذه الثغرة واحد فقط: «أن لا يؤكّد الرئيس الوجهة». سير عمل الموافقة مصمَّم بافتراض أنّ الموافق ينظر إلى المحتوى. إن لم ينظر، فهو مسار تسليم مؤتمت فحسب.

شروط تحوّل الموافقة إلى شكل ثابتة

عندما تصير الموافقة شكليّة في الممارسة، السبب عادة أحد التالي.

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

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

الصورة الكلّيّة من أين تبدأ المنشآت الصغيرة والمتوسّطة مُعالَجة في كيفيّة قراءة الإصدار 4.0 من «الدليل الإرشادي لتدابير أمن المعلومات للشركات الصغيرة والمتوسطة» الصادر عن IPA.

7. الثغرة المسمّاة قاعة الاجتماعات ── السؤال 2(2)

سؤال السيّد S التالي «هل يمكن إدخال حاسوب شخصيّ مملوك إلى قاعة الاجتماعات». جواب السيّدة Y «إدخال قاعة الاجتماعات غير محظور، فيمكن إدخاله».

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

الطريقة 1 ── انتحال عنوان MAC

الطريقة 1 هي تغيير [e] عنوان MAC لواجهة الشبكة اللاسلكيّة لحاسوب شخصيّ مملوك إلى عنوان MAC لواجهة الشبكة اللاسلكيّة لحاسوب أعمال، ثمّ وصل الحاسوب الشخصيّ المملوك بالشبكة اللاسلكيّة للموظّفين. الإجابة عن الفراغ e هي السؤال 2(2).

ما كان يحمي مدخل الشبكة اللاسلكيّة للموظّفين هما المفتاح المشترك مسبقاً لـ WPA2-PSK وترشيح عنوان MAC. كلاهما يتجاوزهما الموظّف.

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

ترشيح عنوان MAC وإخفاء SSID لهما معنى كترتيب يقلّل الاتّصالات الخاطئة. لكنّهما ليسا آليّة مصادقة توقف من يقصد الدخول. أكّدوا في تكوينكم أيضاً ما إذا كنتم تعدّون هذين ضمن «عدد العلاجات».

الطريقة 2 ── مجرّد الاتّصال بالشبكة اللاسلكيّة للزوّار

الطريقة 2 أبسط. وصل الحاسوب الشخصيّ المملوك بالشبكة اللاسلكيّة للزوّار، وتنزيل ملفّات من الخدمة B، والخروج بالحاسوب الشخصيّ المملوك. ذلك فقط.

لا حاجة لانتحال عنوان MAC. ما يلزم هو المفتاح المشترك مسبقاً للشبكة اللاسلكيّة للزوّار فقط، وهذا ما يُوزَّع على الزوّار. لا يُتصوَّر أن لا يعرفه الموظّف.

هنا يبرز الشكّ التالي طبعاً. ألم تكن الخدمة B مقيَّدة بـ«بهويّة مستخدم مخصَّصة لموظّفي شركة M، تسجيل الدخول ممكن من عنوان IP العموميّ لشركة M فقط»؟

ماذا يسمح قيد عنوان IP المصدر

بقراءة إعداد جدار الحماية في نصّ المسألة يخرج الجواب. حركة الخروج إلى الإنترنت من الشبكة اللاسلكيّة للزوّار وحركة الشبكة اللاسلكيّة للموظّفين تُترجَمان عبر NAT نفسه إلى عنوان IP عموميّ واحد.

مصدر الاتّصال	نقطة الخروج إلى الإنترنت	المصدر كما تراه الخدمة B
حاسوب أعمال على الشبكة اللاسلكيّة للموظّفين	NAT جدار الحماية	عنوان IP العموميّ لشركة M
حاسوب شخصيّ مملوك على الشبكة اللاسلكيّة للزوّار	NAT نفسه لجدار الحماية نفسه	عنوان IP العموميّ نفسه لشركة M
شبكة الخوادم	NAT نفسه لجدار الحماية نفسه	عنوان IP العموميّ نفسه لشركة M

من منظور الخدمة B لا يمكن تمييز هذه الثلاثة. قيد عنوان IP يمرّ.

هذا التركيب يظهر مراراً خارج الاختبار أيضاً. قيد عنوان IP المصدر لا يعني «من هذا الجهاز فقط». يعني «من كلّ من يخرج بعنوان IP العموميّ هذا». أمثلة نموذجيّة ينزاح فيها النطاق الذي قصدتم السماح به عن النطاق المسموح به فعلاً.

«قصدنا السماح»	النطاق المسموح به فعلاً
حواسيب الأعمال الداخليّة فقط	Wi-Fi الضيوف المارّ بنقطة الخروج نفسها، وأجهزة قاعة الاجتماعات، وأجهزة الزوّار
شبكة المقرّ فقط	كلّ المواقع الخارجة عبر المقرّ بـ VPN بين المواقع
الأجهزة الممنوحة من الشركة فقط	حتّى جهاز شخصيّ، إن وُصل بـ Wi-Fi الداخليّ أو VPN فنقطة الخروج نفسها
شركة واحدة معيَّنة فقط	شركات أخرى تستخدم عنوان IP عموميّاً مشتركاً لنفس مزوّد الخدمة (في حالة CGNAT)

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

8. ربط الجهاز بشهادة ── الأسئلة 3(1)–(4)

كعلاج للطريقة 1، اختارت شركة M EAP-TLS أسلوب مصادقة للشبكة اللاسلكيّة للموظّفين، وقرّرت إعداد خادم مصادقة.

السؤال 3(1) ── RADIUS

يسأل السؤال 3(1) عن البروتوكول فوق UDP الذي يستخدمه خادم المصادقة في EAP. مثال الإجابة RADIUS.

بترتيب التركيب، الشخصيّات ثلاث.

الدور	في هذه المسألة	ما يفعله
الطالب (supplicant)	حاسوب الأعمال	يتلقّى المصادقة بشهادة عميله
المصادق (authenticator)	نقطة وصول الشبكة اللاسلكيّة	لا تمرّر حركة ذلك المنفذ حتّى تمرّ المصادقة
خادم المصادقة	خادم المصادقة الذي سيُنشَأ	يتحقّق من الشهادة ويبلّغ نقطة الوصول بالجواز

بين حاسوب الأعمال ونقطة الوصول IEEE 802.1X (EAP over LAN)، وبين نقطة الوصول وخادم المصادقة RADIUS. يعمل RADIUS فوق UDP¹⁰. إجراء EAP-TLS نفسه يحدّده RFC 5216¹¹. عند البناء على Windows Server، من يتولّى دور خادم المصادقة هو خادم سياسة الشبكة (NPS)¹².

لنثبّت ماذا يتغيّر بالانتقال من WPA2-PSK إلى EAP-TLS.

	WPA2-PSK	EAP-TLS
الاعتماد	مفتاح مشترك مسبقاً للجميع	شهادة عميل لكلّ جهاز
أثر تسرّب جهاز واحد	يلزم تغيير مفتاح الجميع	يكفي إلغاء تلك الواحدة
إيقاف جهاز معيَّن فقط	غير ممكن	ممكن
هل يستطيع العميل تأكيد جهة الاتّصال	لا (كلّ نقطة وصول تعرف المفتاح تبدو حقيقيّة)	نعم (يتحقّق من شهادة خادم المصادقة)

السطر الأخير يحتاج تكملة. الطرف الذي يتحقّق العميل من شهادته في EAP-TLS هو خادم المصادقة لا نقطة الوصول. نقطة الوصول مجرّد مصادق يرحّل تبادل EAP، والعميل لا يؤكّد هويّة نقطة الوصول نفسها.

ومع ذلك يصير استعداداً لـ evil twin في الفصل 4 لأنّ مادّة المفتاح التي تُولَّد عند نجاح المصادقة فقط لا تُسلَّم إلا لنقطة وصول شرعيّة تحمل السرّ المشترك لـ RADIUS. نقطة وصول أقامها مهاجم وحده لا تستطيع إكمال هذا الإجراء حتّى النهاية ما لم تحمل خادم مصادقة شرعيّاً وراءها. ما يتحقّق منه العميل مباشرة هو خادم المصادقة، وشرعيّة نقطة الوصول تُشتَقّ من هناك غير مباشرة.

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

السؤال 3(2) ── إجابة خاطئة أشار إليها تعليق التصحيح

يتواصل شرح السيّدة Y كالتالي. تُصدَر شهادات العميل بإنشاء خادم مرجع تصديق جديد، ولا يثبّتها الموظّف بنفسه على حاسوب أعماله، بل تُحفَظ على حاسوب الأعمال بوظيفة خادم الدليل. ثمّ [f] المقابل لشهادة العميل يُحفَظ في TPM لحاسوب الأعمال ويُحمى من أجل [g].

يسأل السؤال 3(2) عن الفراغ f. مثال الإجابة المفتاح الخاصّ.

يكتب تعليق التصحيح كالتالي.

كان معدّل الإجابة الصحيحة للسؤال 3(2) مرتفعاً نسبيّاً، لكن ظهرت في بعض الإجابات «مفتاح عامّ» أو «شهادة خادم». PKI تقنيّة مهمّة أساس تقنيّات أمن متنوّعة، فينبغي فهم في أيّ موضع وكيف تُستخدم جيّداً.

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

ماذا يتغيّر بالوضع في TPM ── السؤال 3(3)

يسأل السؤال 3(3) عن الفراغ g في 20 حرفاً أو أقلّ. مثال الإجابة «بحيث لا يمكن إخراجه من حاسوب الأعمال».

إن وُضع المفتاح الخاصّ كملفّ على الجهاز، فهو بيانات يمكن نسخها. إن نُسخ إلى حاسوب شخصيّ مملوك، يمرّ ذلك الحاسوب الشخصيّ المملوك بالمصادقة كحاسوب أعمال. ما ظننتم أنّكم سددتم به الطريقة 1 (انتحال عنوان MAC) يُستبدل فحسب بـ«انتحال شهادة».

يستطيع TPM توليد المفتاح داخله والاحتفاظ به بحالة لا تُخرَج. تجري عمليّات مثل التوقيع داخل TPM، ولا يبلغ المفتاح نفسه نظام التشغيل ولا التطبيق ولا البرمجيّة الخبيثة. نتيجة لذلك يُثبَّت ذلك المفتاح الخاصّ في قطعة فيزيائيّة لذلك الجهاز الواحد.

عند التنفيذ على Windows، عيّنوا Microsoft Platform Crypto Provider كمزوّد تخزين مفاتيح (KSP) لقالب الشهادة. هذا المزوّد يحمي المفتاح باستخدام TPM، ولا يمكن اختياره إن كان «السماح بتصدير المفتاح الخاصّ» معلَّماً على جانب قالب الشهادة¹³. قيد بديهيّ: إن أمكن التصدير فلا معنى للحماية.

دور القطعة المسمّاة TPM نفسه مُعالَج في سياق تشفير المحرّك في الدليل العمليّ لـ BitLocker. فكرة «عدم إخراج المفتاح الخاصّ خارج الجهاز» التفكير نفسه لتصميم أداة المصادقة المشروح في لماذا مفاتيح المرور آمنة.

لماذا يمكن القول «لا بأس» ── السؤال 3(4)

بعد سماع شرح السيّدة Y يردّ السيّد S «أعتقد أنّ طريقة الحفظ تلك لا بأس بها». يسأل السؤال 3(4) عن ذلك السبب في 40 حرفاً أو أقلّ.

مثال الإجابة «لأنّ معلومات المصادقة اللازمة لـ EAP-TLS لا يمكن حفظها إلا في حاسوب الأعمال».

بتتبّع التدفّق يصير كالتالي.

شهادة العميل لا يثبّتها الموظّف بنفسه، بل تُوزَّع على حاسوب الأعمال بوظيفة خادم الدليل. لا تمرّ بيد الموظّف
المفتاح الخاصّ داخل TPM، ولا يُخرَج من حاسوب الأعمال
إذن من يستطيع الاتّصال بالشبكة اللاسلكيّة للموظّفين بـ EAP-TLS هو حاسوب الأعمال الذي منحته الشركة فقط
الحاسوب الشخصيّ المملوك، حتّى بانتحال عنوان MAC، لا يمرّ بالمصادقة. تُسدّ الطريقة 1

انتبهوا إلى القول المشروط «إن كانت طريقة الحفظ تلك». لو وُضع المفتاح الخاصّ كملفّ على حاسوب الأعمال، لما قال السيّد S لا بأس. حتّى «المصادقة بشهادة عميل» نفسها، نطاق ما يُحمى يتغيّر بموضع المفتاح الخاصّ.

ما لا يحميه TPM

بالمقابل، ليس الحديث أنّ الوضع في TPM يطمئن. ما يضمنه TPM هو «أن لا يُنسَخ ذلك المفتاح إلى جهاز آخر» فقط. التالي لا يحميه.

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

9. تفريق عنوان IP لنقطة الخروج ── السؤال 3(5)

كعلاج للطريقة 2 (مجرّد الاتّصال بالشبكة اللاسلكيّة للزوّار)، تنظر شركة M في مقترحين. مقترح تغيير إعداد NAT لجدار الحماية، ومقترح استخدام خدمة شبكة لاسلكيّة (الخدمة D).

يسأل السؤال 3(5) عن محتوى التغيير للأوّل في 70 حرفاً أو أقلّ. مثال الإجابة بمعنى «جعل عنوان IP المصدر عند وصول الشبكة اللاسلكيّة للزوّار إلى الإنترنت عنوان IP مختلفاً عن عنوان IP العموميّ المستخدم حالياً» (في نصّ المسألة يُرمَز عنوان IP العموميّ ذلك بـ a1.b1.c1.d1).

كما في الفصل 7، انعقدت الطريقة 2 لأنّ حركة الشبكة اللاسلكيّة للزوّار تخرج بعنوان IP العموميّ نفسه للموظّفين. إذن يكفي ترجمة الشبكة اللاسلكيّة للزوّار وحدها إلى عنوان IP عموميّ آخر. قيد عنوان IP على جانب الخدمة B لا يُغيَّر، ويخرج وصول الشبكة اللاسلكيّة للزوّار منه وحده.

ينعقد هذا لأنّ عدّة عناوين IP عموميّة مخصَّصة لجانب WAN لشركة M. بقراءة إعداد واجهة جدار الحماية في نصّ المسألة، قناع الشبكة الفرعية لجانب WAN 255.255.255.248، أي /29، فيتّضح أنّ العناوين المتاحة ليست واحداً. خيط خلفية متواضع لكن موثوق يجعلكم تقرؤون جدول المسألة بدقّة.

ما إذا استطعتم فعل اليد نفسها لديكم يتوقّف على إمكان استخدام عدّة عناوين IP عموميّة على الخطّ المتعاقَد عليه. إن لم يكن إلا واحد، لا يُؤخَذ هذا المقترح. عندئذٍ يصير مقترح الفصل التالي للفصل.

10. العلاج لا يكتمل إلا بحذف إعداد لم يعد يُستخدم ── السؤالان 3(6) و3(7)

نتيجة النظر، قرّرت شركة M استخدام الخدمة D.

وضع موجّه شبكة لاسلكيّة منحته الخدمة D (موجّه D) في قاعة الاجتماعات
على موجّه D، تفعيل وظيفة خادم DHCP ووظيفة خادم ذاكرة DNS المؤقّتة
أجهزة الزوّار المُدخَلة تتّصل بالإنترنت دون المرور بشبكة شركة M، باستخدام شريحة SIM محمولة على موجّه D
جهاز العرض لا يستخدم الشبكة اللاسلكيّة للزوّار، ويُغيَّر الأسلوب إلى التوصيل بكابل HDMI

flowchart LR
accTitle: بعد العلاج تُفصَل شبكة الزوّار
accDescr: شبكة الموظّفين EAP-TLS وTPM، وأجهزة الزوّار المُدخَلة تخرج إلى الإنترنت بشريحة SIM على موجّه D دون المرور بشبكة شركة M
    subgraph M["الشبكة الداخليّة لشركة M (بعد العلاج)"]
        direction TB
        E["شبكة لاسلكيّة للموظّفين<br/>EAP-TLS + RADIUS<br/>المفتاح الخاصّ داخل TPM"]
        S["شبكة الخوادم"]
        FW["جدار الحماية"]
        E --> FW
        S --> FW
    end
    subgraph K["قاعة الاجتماعات"]
        T["جهاز زائر مُدخَل"]
        D["موجّه D<br/>إلى الإنترنت مباشرة بشريحة SIM"]
        T --> D
    end
    FW --> B["الخدمة B"]
    D --> I["الإنترنت"]

الشكل 3: شبكة الزوّار مفصولة فيزيائيّاً ومنطقيّاً عن شبكة شركة M؛ ولم تعد تخرج بعنوان IP العموميّ نفسه.

فُصلت شبكة الزوّار فيزيائيّاً ومنطقيّاً عن شبكة شركة M. ولا تخرج بعنوان IP العموميّ نفسه أيضاً.

السؤال 3(6) ── اتّصال يصير غير لازم

عندما تكفّ أجهزة الزوّار المُدخَلة عن استخدام شبكة شركة M، يصير الاتّصال بخادم DHCP وخادم [h] الذي كان لازماً حتّى الآن غير لازم. مثال إجابة الفراغ h هو DNS.

يملك موجّه D نفسه وظيفة خادم DHCP ووظيفة خادم ذاكرة DNS المؤقّتة، فلا تحتاج أجهزة الزوّار المُدخَلة استخدام خادم DHCP وخادم DNS في شبكة خوادم شركة M. بإعادة قراءة شرح نصّ المسألة، مكتوب كما هو.

السؤال 3(7) ── تعداد كلّ إعداد ينبغي حذفه

يجعل السؤال 3(7) يجيبون عن كلّ أرقام البنود التي ينبغي حذفها من إعداد واجهة VLAN لجدار الحماية وإعداد الترشيح، كلّ على حدة، المصاحبة لهذا التغيير.

الإجابة، من إعداد واجهة VLAN VLAN الشبكة اللاسلكيّة للزوّار (البند 1)، ومن إعداد الترشيح قاعدتان: قاعدة السماح بـ HTTP/HTTPS من الشبكة اللاسلكيّة للزوّار إلى الإنترنت (البند 1) وقاعدة السماح بالوصول من الشبكة اللاسلكيّة للزوّار إلى DNS في شبكة الخوادم (البند 4). ومع ذلك، يُحذف إعداد SSID الزوّار من إعداد نقطة الوصول.

يكتب تعليق التصحيح كالتالي.

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

سؤال معدّل إجابته الصحيحة مرتفع، لكن قلّة من المنظّمات تنفّذ هذا الحدّ في الممارسة. عمل إدخال آليّة جديدة تلحقه ميزانيّة وأجل، وعمل حذف إعداد قديم لا يلحقه. ونسيان الحذف يظهر بالأشكال التالية.

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

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

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

أسلوب التقييم	مثال	إن بقيت قاعدة سماح قديمة
أوّل تطابق من الأعلى (first match)	كثير من جدران حماية الشبكة. جدار هذه المسألة أيضاً هذا	كلّما علا قوي. سماح بقي فوق قاعدة رفض يمرّ
الحظر يتقدّم على السماح (block overrides allow)	جدار حماية Windows Defender	يُحسَم بالنوع لا بالترتيب. حتّى إن بقي سماح، إن وُجد حظر مطابق لا يمرّ
سماح فقط بلا ترتيب	مجموعات أمن سحابيّة وغيرها	يكفي تطابق واحد ليمرّ. «أهو في الأعلى» لا علاقة له، والبقاء نفسه ثقب

بأيّ أسلوب، خطر إبقاء سماح غير مستخدم نفسه لا يتغيّر. ما يتغيّر هو «لماذا خطر» و«كيف يُصلَح». أكّدوا أيّ أسلوب لجهازكم، ثمّ أدخلوا في موضوع الجرد الدوريّ منظور «هل المصدر والوجهة ما زالا موجودين».

حديث جدار الحماية على جانب المضيف، كيف تُدار القواعد الواردة اللازمة على جانب تطبيق الأعمال، مُعالَج في جدار حماية Windows وتطبيقات الأعمال.

11. علاجات لم تعمل، وعلاجات عملت

بتلخيص هذه المسألة في ورقة واحدة يصير الجدول التالي. تقابل علاجات كانت لدى شركة M وأين اُجتُيزت.

علاج كانت لدى شركة M	التهديد المتصوَّر	المسار الذي اُجتُيز به فعلاً
حظر توصيل وسائط تخزين خارجيّة مثل USB	إخراج بالنسخ إلى وسيط	عدم استخدام حاسوب الأعمال. الخروج بالحاسوب الشخصيّ المملوك نفسه
حظر حفظ الملفّات على القرص المحلّيّ	بقاء ملفّات على حاسوب الأعمال	التنزيل مباشرة إلى الحاسوب الشخصيّ المملوك
قطع الاتّصال بالبريد عبر الويب والتخزين السحابيّ غير المأذون	النقل إلى خدمة أخرى	استخدام وظيفة المشاركة في الخدمة B المأذون بها نفسها
حظر إرفاق ملفّات عند إرسال البريد الإلكترونيّ	الإرسال بمرفق	وصلة المشاركة تُرسَل تلقائيّاً من الخدمة B إلى الوجهة
إلغاء خادم الملفّات الداخليّ	النسخ بالجملة من الخادم	موضع الملفّات وُحِّد في الخدمة B فحسب
حظر إخراج حاسوب الأعمال خارج الشركة	إخراج لكلّ جهاز	ما يُخرَج هو الحاسوب الشخصيّ المملوك
حظر إدخال حاسوب شخصيّ مملوك	اتّصال جهاز غير مُدار داخليّاً	المحظور منطقة المكاتب فقط. قاعة الاجتماعات مستثناة
ترشيح عنوان MAC للشبكة اللاسلكيّة للموظّفين	اتّصال جهاز غير مسجَّل	انتحال عنوان MAC (الطريقة 1)
قيد عنوان IP المصدر للخدمة B	تسجيل دخول من خارج الشركة	الشبكة اللاسلكيّة للزوّار تخرج أيضاً بعنوان IP العموميّ نفسه (الطريقة 2)
موافقة الرئيس على مشاركة الملفّات	مشاركة مع طرف غير مناسب	جعل الوجهة عنواناً خاصّاً بالموظّف. الرئيس لا يؤكّد
HTTPS + HSTS للخدمة B	التوجيه إلى موقع مزيّف	لم يُجتَز. هنا عمل

السطر الأخير وحده «عمل». وبصفّ ما وُضع كعلاج يصير التالي.

العلاج الموضوع	ماذا يوقف
جعل الشبكة اللاسلكيّة للموظّفين EAP-TLS	مشاركة المفتاح المشترك مسبقاً وانتحال عنوان MAC. يصير الاعتماد لكلّ جهاز
توزيع شهادة العميل من خادم الدليل	نسخ الشهادة المارّ بيد الموظّف
حفظ المفتاح الخاصّ في TPM بحيث لا يُخرَج	نقل الشهادة مع المفتاح إلى حاسوب شخصيّ مملوك
فصل الشبكة اللاسلكيّة للزوّار إلى الخدمة D (أو تفريق IP الخروج بـ NAT)	اجتياز قيد عنوان IP المصدر من شبكة الزوّار
حذف VLAN وقواعد الترشيح وSSID التي صارت غير لازمة	بقاء مسار أُلغي كإعداد

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

12. نقاط تأكيد للممارسة

نعدّد بنود تأكيد عند إسقاط هذه المسألة على تكوينكم.

هل يمكن كتابة علاجات الإخراج بمسارات لا بوسائل. لا قائمة وسائل USB ومرفقات البريد والبريد عبر الويب، بل اصنعوا «قائمة أجهزة وشبكات تصل إلى ملفّات الأعمال». إن وُجد مسار واحد يصل إليه جهاز خارج الإدارة، يُتجاوز حظر الوسائل
هل قواعد الإدخال والإخراج لا تقيّد المكان. «حظر الإدخال إلى منطقة المكاتب» يسمح بقاعة الاجتماعات والاستقبال والمساحات المشتركة. أكّدوا تطابق التقسيم الفيزيائيّ مع تقسيم الشبكة
هل يمكن قول النطاق الذي يسمح به قيد عنوان IP المصدر فعلاً. عدّوا كلّ ما يخرج بعنوان IP العموميّ ذلك. Wi-Fi الضيوف، وشبكة الزوّار، وVPN بين المواقع، وبوّابة تجميع العمل عن بُعد، وبيئة التحقّق
هل اعتماد الشبكة اللاسلكيّة صار لكلّ جهاز. المفتاح المشترك مسبقاً سرّ مشترك يحمله الجميع متماثلاً، فإن سرّبه واحد سُرِّب اعتماد الجميع، ولا يمكن إيقاف جهاز واحد معيَّن
هل لا تعدّون ترشيح عنوان MAC وإخفاء SSID ضمن عدد العلاجات. كلاهما ترتيب يقلّل الاتّصال الخاطئ، لا مصادقة
هل المفتاح الخاصّ لشهادة العميل بحالة لا تُخرَج من الجهاز. مفتاح خاصّ موضوع كملفّ يمكن نسخه. عيّنوا مزوّد تخزين مفاتيح يستخدم TPM، ولا تسمحوا بالتصدير
هل يتحقّق عميل أُدخل فيه EAP-TLS من شهادة خادم المصادقة. تعطيل هذا يفقد مقاومة خادم مصادقة مزيّف
هل ليس خطأ شهادة الخادم بحالة يستطيع المستخدم تجاوزها بـ«متابعة». اضبطوا HSTS على موقعكم. لا تتركوا خطأ شهادة نظام داخليّ فيتعلّم المستخدم أنّ «الخطأ شيء يُضغط للمتابعة»
هل تجردون محتوى مخزن مراجع التصديق الجذريّة الموثوقة. ما دخله هو الطرف الذي يعلن ذلك الجهاز «شهادة أصدرها مرجع التصديق هذا تُعدّ حقيقيّة»
هل تصل مادّة الحكم إلى الموافق في سير عمل الموافقة. وهل تنظرون إلى نتيجة الموافقة لاحقاً. أكّدوا دوريّاً بقائمة المشاركات الموجَّهة إلى نطاق خارجيّ أو بريد حرّ
هل تحذفون إعداد مسار أُلغي. واجهة VLAN، وقواعد الترشيح، وSSID، وقيود قائمة السماح. عاملوا عمل الحذف بالأجل نفسه لعمل «الإدخال الجديد»

خاتمة ── علاج لا يكتب «نطاقاً» لا يحمي

إن كان السؤال 1 يسأل «أيّ هجوم، وأيّ مرحلة، يوقف ذلك العلاج»، فما يسأله السؤال 2 هو «أيّ نطاق يحمي ذلك العلاج».

لكلّ علاج لدى شركة M نطاق ضمنيّ. نطاق برمجيّة منع تسرّب المعلومات إلى حاسوب الأعمال. نطاق حظر الإدخال إلى منطقة المكاتب. نطاق ترشيح عنوان MAC إلى «طرف لا ينتحل». نطاق قيد عنوان IP المصدر إلى «كلّ من يخرج بعنوان IP العموميّ ذلك». كلّ نطاق كان يعمل صحيحاً، غير أنّ الوصلة مع الجار كانت مفتوحة.

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

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

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع مراجعة تصميم تفترض شبكة وتكوين أجهزة قائمين، وتنفيذ توزيع الشهادات وحماية المفاتيح في بيئة Windows.

روابط مرجعيّة

IPA الوكالة المستقلّة لتعزيز تقانة المعلومات، كتيّب المسألة ونسبة توزيع الدرجات ومثال الإجابة وتعليق التصحيح (السنة الماليّة 2023، السنة 5 من ريوا) ضمن «اختبار اختصاصي ضمان أمن معالجة المعلومات خريف السنة الماليّة 5 من ريوا، بعد الظهر، المسألة». حول لمحة شركة M (شركة تابعة لـ L، صناعة ملابس، 100 موظّف، مبنى المكتب يطلّ على شارع كبير في طوكيو كثير المرور)، وحادث إخراج ملفّ تصميم منتج بـ USB في السنة السابقة، وإعادة النظر الثلاثة المنفَّذة أصلاً (إدخال برمجيّة منع تسرّب المعلومات على حاسوب الأعمال وإعداداتها الخمسة، وتجميع ملفّات الأعمال في الخدمة B، وإلغاء خادم الملفّات الداخليّ)، وتكوين الشبكة اللاسلكيّة لمنطقة المكاتب وقاعة الاجتماعات، وتكوين الشبكة ولمحة عناصر التكوين (WPA2-PSK، وترشيح عنوان MAC على الشبكة اللاسلكيّة للموظّفين فقط، وHTTPS وHSTS للخدمة B، وتسجيل الدخول بهويّة مستخدم وكلمة مرور، والقيد بتسجيل الدخول من عنوان IP عموميّ واحد فقط، ومواصفات وظيفة مشاركة الملفّات، وحمل TPM 2.0 على حاسوب الأعمال، ووظيفة تثبيت شهادة العميل عبر خادم الدليل)، وبنود قواعد الأمن الثلاثة، وإعداد واجهة VLAN لجدار الحماية وإعداد الترشيح وإعداد AP-5، وحوار السيّدة Y والسيّد S (نقطة وصول مزيّفة وموقع مزيّف، وتفاصيل رسالة خطأ شهادة الخادم، وHSTS، وإساءة استخدام وظيفة مشاركة الملفّات، والطريقة 1 والطريقة 2، وEAP-TLS وخادم المصادقة، وشهادة العميل وTPM، وتغيير إعداد NAT لجدار الحماية، وشروط استخدام الخدمة D). نصوص الأسئلة من 1 إلى 3 أيضاً وفق هذا الكتيّب. ↩ ↩²
IPA الوكالة المستقلّة لتعزيز تقانة المعلومات، أسئلة شائعة حول الاختبار. حول عدم الحاجة إلى إذن أو رسوم استخدام لمسائل الاختبار السابقة التي تنشرها هذه الوكالة إلا حيث ينصّ القانون على خلاف ذلك، وعدم التنازل عن حقّ المؤلّف، ولزوم ذكر المصدر بصيغة «السنة الماليّة، الفترة، فئة الاختبار، تقسيم الوقت، رقم السؤال، إلخ»، ولزوم ذكر أنّ جزءاً من المسألة عُدِّل إن كان ذلك كذلك. ↩
IPA الوكالة المستقلّة لتعزيز تقانة المعلومات، مثال إجابة اختبار اختصاصي ضمان أمن معالجة المعلومات خريف السنة الماليّة 5 من ريوا. حول غرض السؤال 2 (انتشار الشبكة اللاسلكيّة على نطاق واسع في شبكات الشركات، وإمكان وجود شبكة لاسلكيّة للزوّار، وأهمّيّة اتّخاذ تدابير أمن كي لا يتّصل طرف ثالث في بيئة كهذه، وكون هذا السؤال يتّخذ إعادة النظر في تدابير الأمن في صناعة الملابس مادّة ويسأل عن القدرة على تصوّر تهديدات في بيئة تستخدم شبكة لاسلكيّة من زوايا متنوّعة والقدرة على وضع تدابير أمن)، وأمثلة الإجابة لكلّ سؤال فرعيّ (الفراغان a وb في 1(1) «هويّة مستخدم» و«كلمة مرور» بأيّ ترتيب، والفراغان c وd في 1(2) «شهادة الخادم هذه ليست شهادة خادم صادرة عن مرجع تصديق موثوق» و«اسم الخادم المكتوب على شهادة الخادم هذه يختلف عن اسم خادم جهة الاتّصال» بأيّ ترتيب، و1(3) «يستبدل وصول HTTP بوصول HTTPS ثمّ يصل. بعد ذلك يتلقّى شهادة خادم من الموقع المزيّف.»، و2(1) «تعيين عنوان بريد إلكترونيّ خاصّ بالموظّف نفسه كعنوان بريد المشارك الخارجيّ.»، والفراغ e في 2(2) «عنوان MAC»، و3(1) «RADIUS»، والفراغ f في 3(2) «المفتاح الخاصّ»، والفراغ g في 3(3) «بحيث لا يمكن إخراجه من حاسوب الأعمال»، و3(4) «لأنّ معلومات المصادقة اللازمة لـ EAP-TLS لا يمكن حفظها إلا في حاسوب الأعمال»، و3(5) «جعل عنوان IP المصدر عند وصول الشبكة اللاسلكيّة للزوّار إلى الإنترنت عنوان IP مختلفاً عن a1.b1.c1.d1.»، والفراغ h في 3(6) «DNS»، و3(7) الجدول 3 البند 1 والجدول 4 البندان 1 و4). ↩ ↩²
IPA الوكالة المستقلّة لتعزيز تقانة المعلومات، تعليق تصحيح اختبار اختصاصي ضمان أمن معالجة المعلومات خريف السنة الماليّة 5 من ريوا. حول كون السؤال 2 اتّخذ إعادة النظر في تدابير الأمن في صناعة الملابس مادّة وطرح تحقّق شهادة الخادم وإدارة المفتاح الخاصّ ومراجعة بيئة الشبكة اللاسلكيّة وكان معدّل الإجابة الصحيحة إجماليّاً متوسّطاً، وانخفاض معدّل الإجابة الصحيحة للسؤال 1(2) والإشارة إلى أنّ «حتّى إن أعدّ مهاجم موقعاً مزيّفاً، فإنّ الوصول عبر HTTPS يفشل في تحقّق شهادة الخادم» وأنّ «تحقّق شهادة الخادم معرفة أساسيّة لتأمين سلامة الاتّصال فينبغي فهم ما يُتحقَّق منه تحديداً حتّى ذلك الحدّ»، وكون معدّل الإجابة الصحيحة للسؤال 3(2) مرتفعاً نسبيّاً لكن ظهرت في بعض الإجابات «مفتاح عامّ» أو «شهادة خادم»، وارتفاع معدّل الإجابة الصحيحة للسؤال 3(7) وفهم أثر مراجعة بيئة الشبكة اللاسلكيّة وكلّ إعدادات ترشيح جدار الحماية كما ينبغي. ↩ ↩²
IETF, RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Section 6 “Certification Path Validation”. حول تعريف تحقّق مسار الشهادة كإجراء ينفّذ بالترتيب فحص تحقّق التوقيع وتأكيد فترة الصلاحيّة وتأكيد الإلغاء وقيود الأسماء وغيرها على السلسلة من الجذر الموثوق (مرساة الثقة) إلى الشهادة المقصودة. ↩
IETF, RFC 6125: Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS). حول تحديد إجراء مطابقة اسم تعريف الخدمة (اسم النطاق) التي يحاول العميل الاتّصال بها مع معلومات التعريف المتضمَّنة في الشهادة التي عرضها الخادم. ↩
The Chromium Projects, CRLSets. حول كون CRLSet الوسيلة الرئيسة لحظر الشهادات بسرعة في الطوارئ في Chrome، وتضمّن إلغاء غير طارئ أيضاً لشهادات وسيطة ونهائيّة مجلوب من قوائم إلغاء مراجع التصديق لكن ما يُدرَج في كلّ إصدار يبقى جزءاً من الإلغاء المحدَّد، وعدم تنفيذ التأكيد عبر الإنترنت (OCSP وCRL) عادةً في Chrome (يمكن لمديري المؤسّسات تفعيل تأكيد OCSP عبر الإنترنت بالسياسة). ↩
IETF, RFC 6797: HTTP Strict Transport Security (HSTS). حول تحديد القسم 8.1 أنّ وكيل المستخدم يتذكّر ذلك المضيف كمضيف HSTS معروف عندما يتلقّى حقل ترويسة Strict-Transport-Security فوق قناة اتّصال آمنة. وطلب القسم 8.3 أن يستبدل وكيل المستخدم المخطّط http بـ https عندما يتضمّن URI لمضيف HSTS معروف مخطّط http، ويحوّل المنفذ 80 إلى 443 إن صُرِّح به. وطلب القسم 8.4 إنهاء الاتّصال بغضّ النظر عمّا إذا كان الخطأ تحذيراً أم قاتلاً عند خطأ أثناء إقامة قناة اتّصال آمنة مع مضيف HSTS معروف. وشرح القسم 12.1 ذلك السلوك كـ “No User Recourse” ووجوب عدم تقديم خيار للمستخدم بتجاوز التحذير والمتابعة. ↩
Google Chrome, HSTS Preload List Submission. حول تعداد متطلّبات التسجيل في قائمة التحميل المسبق: تقديم شهادة صالحة، وإعادة التوجيه من HTTP إلى HTTPS على المضيف نفسه إن كان الاستماع على المنفذ 80، وتقديم كلّ النطاقات الفرعيّة بما فيه www الذي له سجلّ DNS عبر HTTPS، وإعادة ترويسة Strict-Transport-Security على النطاق الأساس بـ max-age 31536000 ثانية (سنة) فأكثر مع includeSubDomains وpreload. ومع ذلك أنّ التسجيل في قائمة التحميل المسبق لا يُلغى بسهولة، وطلب الحذف يُقبل عموماً لكن وصول التغيير إلى المستخدمين عبر تحديث Chrome يستغرق أشهراً، ولا ضمان لمتصفّحات أخرى. ↩ ↩²
IETF, RFC 2865: Remote Authentication Dial In User Service (RADIUS). حول كون RADIUS بروتوكولاً يعمل فوق UDP، واستخدامه لاستعلام خادم وصول الشبكة (نقطة الوصول في هذه المسألة) خادم المصادقة عن مصادقة المستخدم وتفويضه. ↩
IETF, RFC 5216: The EAP-TLS Authentication Protocol. حول كون EAP-TLS أسلوب EAP ينفّذ مصادقة متبادلة باستخدام TLS، وعرض العميل والخادم شهادة كلّ منهما على الآخر والتحقّق منها. ↩
Microsoft Learn, Network Policy Server (NPS) overview. حول كون NPS تنفيذ Microsoft لمعيار RADIUS المحدَّد في RFC 2865 وRFC 2866 لدى IETF، وقيامه كخادم RADIUS بمصادقة وتفويض ومحاسبة مركزيّة لأنواع وصول شبكة متنوّعة مثل اللاسلكيّ ومبدّلات المصادقة والاتّصال الهاتفيّ وVPN، وتكوين خوادم وصول الشبكة مثل نقاط وصول الشبكة اللاسلكيّة كعملاء RADIUS، وتوفير معالج تكوين خادم RADIUS لاتّصالات 802.1X اللاسلكيّة / السلكيّة. ↩
Microsoft, Setting up TPM protected certificates using a Microsoft Certificate Authority - Part 1: Microsoft Platform Crypto Provider. حول كون Microsoft Platform Crypto Provider مزوّد تخزين مفاتيح (KSP) يستخدم TPM، وتعذّر اختيار هذا المزوّد إن كان «السماح بتصدير المفتاح الخاصّ» مفعَّلاً في قالب الشهادة، وإجراء الضبط باختيار فئة المزوّد كمزوّد تخزين مفاتيح في قالب الشهادة وتعيين Microsoft Platform Crypto Provider كمزوّد. ↩

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

شرح سؤال بعد الظهر 1 من امتحان أخصائي أمن المعلومات المسجَّل ربيع 2024 (رييوا 6) ── JWT alg=none وتفويض API والتخفيف المؤقّت بـ WAF

انطلاقاً من سؤال بعد الظهر 1 في امتحان أخصائي أمن المعلومات المسجَّل لربيع 2024 (رييوا 6)، يشرح هذا المقال alg=none في JWT، وتفويض واجهات...

قراءة المقالة

أكبر 10 تهديدات لأمن المعلومات لعام 2026 ── كيفيّة قراءة الترتيب، وما ينبغي للشركات الصغيرة والمتوسّطة أن تتصدّى له فعليّاً

في «أكبر 10 تهديدات لأمن المعلومات 2026» الصادرة عن IPA، احتلّت هجمات الفدية المرتبة الأولى للسنة الحادية عشرة على التوالي، وجاءت هجمات س...

قراءة المقالة

ما ينبغي أن يعرفه الجانب الطالب أيضاً عند طلب موقع ويب ── استخدام «كيفية إنشاء موقع ويب آمن» الصادر عن IPA كقائمة تحقق

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

قراءة المقالة

من أين تبدأ الشركات الصغيرة والمتوسطة في تدابير الأمان؟ ── كيفيّة قراءة الإصدار 4.0 من «الدليل الإرشادي لتدابير أمن المعلومات للشركات الصغيرة والمتوسطة» الصادر عن IPA

من أين ينبغي أن تبدأ الشركات الصغيرة والمتوسطة في تدابير الأمان؟ استناداً إلى الإصدار 4.0 من «الدليل الإرشادي لتدابير أمن المعلومات للشرك...

قراءة المقالة

لكي لا تنسى تحديد «كم ثانية يجب أن يستغرق التشغيل حتى يكون مُرضياً» ── تنظيم المتطلبات غير الوظيفية باستخدام «درجة المتطلبات غير الوظيفية» الصادرة عن IPA

كثير من أسباب الخلاف حول «السرعة بطيئة» أو «التعامل مع الأعطال لم يكن متوقَّعاً» يعود إلى نسيان تحديد المتطلبات غير الوظيفية. نشرح للجانب...

قراءة المقالة

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الاستشارات التقنية ومراجعة التصميم

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

عرض الخدمة تواصل معنا

تطوير تطبيقات ويندوز عالية الصعوبة

حفظ المفتاح الخاصّ لشهادة العميل في TPM، وتوزيع الشهادات إلى حواسيب الأعمال، كلاهما يحتاج معالجة كجزء من بناء بيئة Windows.

عرض الخدمة تواصل معنا

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

حظرنا توصيل USB وحظرنا الحفظ على القرص المحلّيّ. فلماذا ما زال يمكن إخراج الملفّات؟: لأنّ ما حُظر وظيفة حاسوب الأعمال الذي منحته الشركة، لا مسار الوصول إلى موضع الملفّات. في هذا السؤال يستخدم الموظّف حاسوبه الشخصيّ المملوك له. دون لمس حاسوب الأعمال أصلاً، يصل حاسوبه الشخصيّ بالشبكة اللاسلكيّة في قاعة الاجتماعات، يسجّل الدخول إلى التخزين السحابيّ (الخدمة B) بهويّة مستخدمه، ينزّل الملفّات، ويخرج بالحاسوب الشخصيّ نفسه. إعداد برمجيّة منع تسرّب المعلومات على حاسوب الأعمال لا يؤثّر في الحاسوب الشخصيّ المملوك البتّة. كانت شركة M قد حظرت إدخال الحواسيب الشخصيّة إلى المقرّ — لكن إلى منطقة المكاتب فقط؛ قاعة الاجتماعات مستثناة. حتّى إن سددتم الوسائل واحداً واحداً (USB، مرفقات البريد، البريد عبر الويب)، ينجح الإخراج ما بقي مسار يصل إلى الملفّات.
كانت الخدمة B مقيَّدة بـ«تسجيل الدخول فقط من عنوان IP العموميّ لشركة M». لماذا لا يوقف ذلك الوصول من الشبكة اللاسلكيّة للزوّار؟: لأنّ حركة الشبكة اللاسلكيّة للزوّار تمرّ أيضاً عبر NAT لجدار الحماية نفسه وتُترجَم إلى عنوان IP العموميّ نفسه قبل الخروج إلى الإنترنت. من منظور الخدمة B، الوصول من حاسوب أعمال داخل المكتب والوصول من حاسوب شخصيّ موصول بالشبكة اللاسلكيّة للزوّار في قاعة الاجتماعات يبدوان عنوان مصدر واحداً. لا يمكن التمييز. قيداً قائماً على عنوان IP المصدر ينبغي فهمه بأنّه يسمح لا بـ«هذا الجهاز فقط» بل بـ«كلّ من يشارك نقطة الخروج هذه». Wi-Fi الضيوف، وشبكات VPN بين المواقع، وبوّابات تجميع العمل عن بُعد — أيّ شيء يخرج عبر عنوان IP العموميّ نفسه — يقع داخل النطاق المسموح.
كانت الشبكة اللاسلكيّة للموظّفين فيها ترشيح عنوان MAC. ألا يُعدّ ذلك علاجاً؟: لا. عنوان MAC يمكن إعادة كتابته بحرّيّة على جانب الجهاز. الطريقة 1 في هذا السؤال كانت تغيير عنوان MAC لمحوّل لاسلكيّ لحاسوب شخصيّ ليطابق عنوان MAC لحاسوب أعمال مسجَّل، ثمّ الاتّصال. لأنّ عناوين MAC في إطارات الشبكة اللاسلكيّة تسير غير مشفَّرة، يستطيع مهاجم يستقبل الإشارة في الجوار معرفة عنوان MAC مسجَّل أيضاً. الأمر نفسه لإخفاء SSID. حتّى مع تعطيل بثّ SSID، يظهر SSID من التبادل عند اتّصال جهاز. ترشيح عنوان MAC وSSID المخفيّ يقلّلان الاتّصالات الخاطئة العرضيّة، لكنّهما ليسا آليّة مصادقة توقف من يتّصل عن قصد.
حتّى مع نقطة وصول مزيّفة وموقع مزيّف معدَّين، لماذا يمكن القول إنّ الموظّف لن يُخدَع؟: لأنّه ما دام الاتّصال عبر HTTPS، لا يستطيع موقع مزيّف اجتياز تحقّق شهادة الخادم. يعدّد الشكل 2 في السؤال أربعة بنود يمكن أن تظهر كتفاصيل الخطأ الناتج: غير صادرة عن مرجع تصديق موثوق؛ اسم الخادم على الشهادة يختلف عن اسم الخادم المتَّصَل به؛ ملغاة؛ ومنتهية الأجل. لا يستطيع المهاجم الحصول على شهادة شرعيّة لاسم نطاق الخدمة B، فشهادة موقعة ذاتيّاً تسقط في النقطة الأولى، وشهادة مُحصَّل عليها شرعيّاً لنطاق المهاجم تسقط في الثانية. وفق تعليق التصحيح لدى IPA، كان معدّل الإجابة الصحيحة للسؤال عن محتوى هذا التحقّق منخفضاً. لاحظوا أنّ هذه البنود الأربعة ليست متساوية الوزن. ما يوقف الهجوم فعلاً هما الأوّلان (المُصدِر والاسم) مع تاريخ الانتهاء — تتحقّق المتصفّحات من هذه دائماً. أمّا تأكيد الإلغاء فيتوقّف على التنفيذ والإعداد. Chrome مثلاً لا ينفّذ عادةً تأكيد OCSP أو CRL عبر الإنترنت؛ يستخدم بدلاً منه قائمة محدودة تُسمّى CRLSet غايتها الرئيسة الحظر الطارئ. لا تفترضوا أنّ إلغاء شهادة مضمون أن يحظرها. وإن وُزِّعت على حاسوب الأعمال شهادة جذر لمرجع تصديق داخليّ، وضُبط مفتاح ذلك المرجع الخاصّ أو إجراء الإصدار بيد مهاجم، يمرّ الفحص الأوّل أيضاً.
ماذا يحدث إن أخطأ أحدهم وكتب عنوان URL كـ «http://»؟ ماذا يفعل HSTS فعلاً؟: يعيد المتصفّح كتابة HTTP إلى HTTPS قبل الاتّصال، فتكون النتيجة مرّة أخرى خطأ شهادة خادم. HSTS آليّة يتذكّر بها المتصفّح محتوى ترويسة تلقّاها آخر مرّة اتّصل بذلك الموقع عبر HTTPS. يطلب RFC 6797 أن يستبدل وكيل المستخدم المخطّط http بـ https عندما يتضمّن عنوان URL للمضيف المستهدف مخطّط http، ويحوّل المنفذ 80 إلى 443 إن صُرِّح به. أي أنّ طلب HTTP الصريح لا يخرج من الجهاز أصلاً. والأهمّ: إن فشل تحقّق الشهادة أثناء الاتّصال بمضيف HSTS نشط، تشترط المواصفة إنهاء الاتّصال بغضّ النظر عمّا إذا كان الخطأ تحذيراً أم قاتلاً. تنصّ صراحة على عدم تقديم خيار للمستخدم مثل «هذا الاتّصال غير آمن، أأتابع؟». غير أنّ HSTS يفترض أنّ المتصفّح بلغ الموقع الحقيقيّ مرّة عبر HTTPS وتلقّى الترويسة. لا حماية إن صادف أوّل وصول من جهاز جديد تماماً موقعاً مزيّفاً. قائمة التحميل المسبق المضمَّنة في المتصفّح هي ما تملأ فجوة المرّة الأولى تلك.
ماذا يتغيّر عندما يُحفَظ المفتاح الخاصّ لشهادة العميل في TPM؟: لا يعود المفتاح الخاصّ قابلاً للإخراج من حاسوب الأعمال ذلك. مفتاح خاصّ محفوظ كملفّ على الجهاز يمكن نسخه ببساطة إلى حاسوب شخصيّ مملوك، فيمرّ ذلك الحاسوب بالمصادقة كأنّه حاسوب الأعمال. إن وُلِّد المفتاح داخل TPM وضُبط ألا يُصدَّر أبداً، تجري عمليّات مثل التوقيع كلّها داخل TPM، ولا يبلغ المفتاح نفسه نظام التشغيل ولا أيّ برمجيّة خبيثة. النتيجة أنّ حواسيب الأعمال التي منحتها الشركة وحدها تستطيع إكمال مصادقة EAP-TLS. لهذا استطاع السيّد S أن يقول «طريقة الحفظ تلك لا بأس بها». تنفيذ هذا على Windows يعني تعيين Microsoft Platform Crypto Provider كمزوّد تخزين مفاتيح لقالب الشهادة، مع عدم السماح بتصدير المفتاح الخاصّ. لاحظوا أنّ TPM يحمي فقط من نسخ المفتاح إلى جهاز آخر — ولا يفعل شيئاً لوقف من يملك ذلك الجهاز فيزيائيّاً عن استخدامه. فقدان الجهاز أو سرقته ما زال يحتاج تغطية منفصلة بتشفير المحرّك وإلغاء الشهادة.
ماذا ينبغي أن نعيد إلى ممارستنا من هذا السؤال؟: أربعة أمور. الأوّل، فكّروا في علاجات الإخراج بمسارات لا بوسائل. حظر USB ومرفقات البريد والبريد عبر الويب واحداً واحداً لا يعني شيئاً إن بقي جهاز يصل إلى الملفّات. الثاني، اكتبوا ما يسمح به قيد عنوان IP المصدر فعلاً. إن شارك Wi-Fi الضيوف أو VPN نقطة الخروج نفسها، فذلك داخل النطاق المسموح أيضاً. الثالث، اجعلوا مصادقة الشبكة اللاسلكيّة اعتماداً لكلّ جهاز. المفتاح المشترك مسبقاً سرّ مشترك يحمله الجميع متماثلاً، فإن سرّبه واحد سُرِّب اعتماد الجميع. الانتقال إلى EAP-TLS بشهادات عميل، وإبقاء المفتاح الخاصّ لا يخرج من TPM، يربط الاعتماد بالجهاز. الرابع، احذفوا تكويناً لم تعد تستخدمونه. السؤال الفرعيّ الأخير في هذه المسألة يطلب من المرشّح تعداد كلّ إعداد واجهة VLAN وقاعدة ترشيح جدار الحماية المتبقّية بعد تقاعد الشبكة اللاسلكيّة للزوّار — ووفق تعليق التصحيح لدى IPA كان معدّل الإجابة الصحيحة مرتفعاً، لكن قلّة من المنظّمات تنفّذ هذا فعلاً في الممارسة.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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

عرض الملف تواصل معنا

روابط عامة

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

العودة إلى المدونة

1. الخلاصة أوّلاً

خريطة المعرفة لهذه المقالة

2. عن المادّة ── المصدر ومعاملتها في هذا المقال

تقابل الأسئلة الفرعية وهذا المقال

وصف كتيّب المسألة ومعاملته في هذا المقال

3. مسرح المسألة ── ما كانت شركة M «قد فعلته أصلاً»

تكوين الشبكة

كيف تتقدّم هذه المسألة

4. Wi-Fi مزيّف وموقع مزيّف ── السؤالان 1(1) و1(2)

نقطة وصول مزيّفة وموقع مزيّف

ماذا ينظر إليه تحقّق الشهادة

البنود الأربعة لا تعمل بالقوّة نفسها

مطبّ في الممارسة ── من يقرّر «مرجع التصديق الموثوق»

5. سبب التوقّف حتّى إن كُتب http:// ── السؤال 1(3)

ماذا يحدث داخل المتصفّح

لا يمكن الضغط على «تجاهل وتابع»

مقدّمة HSTS ── المرّة الأولى وحدها لا تُحمى

6. في اللحظة التي تصير فيها الموافقة شكليّة، تصير وظيفة المشاركة مسار إخراج ── السؤال 2(1)

التصميم صحيح، والتشغيل فيه ثغرة

شروط تحوّل الموافقة إلى شكل ثابتة

7. الثغرة المسمّاة قاعة الاجتماعات ── السؤال 2(2)

الطريقة 1 ── انتحال عنوان MAC

الطريقة 2 ── مجرّد الاتّصال بالشبكة اللاسلكيّة للزوّار

ماذا يسمح قيد عنوان IP المصدر

8. ربط الجهاز بشهادة ── الأسئلة 3(1)–(4)

السؤال 3(1) ── RADIUS

السؤال 3(2) ── إجابة خاطئة أشار إليها تعليق التصحيح

ماذا يتغيّر بالوضع في TPM ── السؤال 3(3)

لماذا يمكن القول «لا بأس» ── السؤال 3(4)

ما لا يحميه TPM

9. تفريق عنوان IP لنقطة الخروج ── السؤال 3(5)

10. العلاج لا يكتمل إلا بحذف إعداد لم يعد يُستخدم ── السؤالان 3(6) و3(7)

السؤال 3(6) ── اتّصال يصير غير لازم

السؤال 3(7) ── تعداد كلّ إعداد ينبغي حذفه

11. علاجات لم تعمل، وعلاجات عملت

12. نقاط تأكيد للممارسة

خاتمة ── علاج لا يكتب «نطاقاً» لا يحمي

مجالات الاستشارة ذات الصلة

روابط مرجعيّة

مقالات ذات صلة

شرح سؤال بعد الظهر 1 من امتحان أخصائي أمن المعلومات المسجَّل ربيع 2024 (رييوا 6) ── JWT alg=none وتفويض API والتخفيف المؤقّت بـ WAF

أكبر 10 تهديدات لأمن المعلومات لعام 2026 ── كيفيّة قراءة الترتيب، وما ينبغي للشركات الصغيرة والمتوسّطة أن تتصدّى له فعليّاً

ما ينبغي أن يعرفه الجانب الطالب أيضاً عند طلب موقع ويب ── استخدام «كيفية إنشاء موقع ويب آمن» الصادر عن IPA كقائمة تحقق

لكي لا تنسى تحديد «كم ثانية يجب أن يستغرق التشغيل حتى يكون مُرضياً» ── تنظيم المتطلبات غير الوظيفية باستخدام «درجة المتطلبات غير الوظيفية» الصادرة عن IPA

أين يتصل هذا الموضوع

الاستشارات التقنية ومراجعة التصميم

تطوير تطبيقات ويندوز عالية الصعوبة

الأسئلة الشائعة

الملف الشخصي للمؤلف

غو كومورا

5. سبب التوقّف حتّى إن كُتب `http://` ── السؤال 1(3)