طبقات الثقة في الويب

طبقات الثقة في الويب.. لماذا لا يكفي رمز القفل وحده؟

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

أشهر هذه الطبقات وأكثرها وضوحًا للمُستخدِم هو البروتوكول الآمن لنقل النص التشعبي (HTTPS)، حيث يظهر رمز القفل في المُتصفِّر ليؤكِّد أنّ الاتصال مشفَّر وآمن. لكن هذا البروتوكول ليس وحيدًا في هذه السلسلة؛ هناك طبقة أخرى أقل شهرة، لكنها بالغة الأهمية، وتسمى نظام أسماء النطاقات (DNS). هذا هو النظام الذي يُترجِم أسماء المواقع مثل example.com إلى العناوين الرقمية (IP) التي تفهمها الشبكة. المشكلة في هذا النظام أنّ درجة الحماية فيه ليست كافية في شكله التقليدي، ما يجعله عرضة للتزوير أو الاختراق.

وهنا يبرز السؤال، إذا كان هذا النظام هو الخطوة الأولى للوصول إلى أي موقع على الإنترنت، فلماذا يَندُر الحديث عن حمايته باستخدام امتدادات تحسين أمان نظام أسماء النطاقات (DNSSEC)، بينما نرى تركيزًا كبيرًا على بروتوكول نقل النص التشعبي (HTTP)؟

الطبقة الأولى: البروتوكول الآمن لنقل النص التشعبي وبُنية التشفير

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

أنّه لا يمكن لأحد أن يقرأ أو يعدِّل البيانات التي ترسلها أو تستقبلها أثناء انتقالها.
أن الموقع الذي تزوره هو بالفعل الجهة الحقيقية، لا نسخة مزوّرة تنتحل هويتها.

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

في السنوات الأخيرة، أصبح البروتوكول الآمن لنقل النص التشعبي المعيار التلقائي لمعظم المواقع. أحد الأسباب الرئيسية لهذا الانتشار هو مبادرات مثل «فلنشفِّر» (Let's Encrypt)، التي قدَّمت شهادات أمان مجانية وسهلة التفعيل. سهَّل هذا الأمر على أي صاحب موقع، صغيرًا كان أو كبيرًا، أن يضيف رمز القفل إلى موقعه من دون تكلفة أو تعقيد.

الطبقة الثانية: دور نظام أسماء النطاقات (DNS)

بعد أن عرفنا كيف يحمي البروتوكول الآمن لنقل النص التشعبي الاتصال، يظهر سؤال جديد، كيف يعرف المُتصفِّر عنوان الموقع الذي نريد الوصول إليه؟ هنا يأتي دور نظام أسماء النطاقات (DNS). يمكننا أن نتخيله كدفتر ضخم يحتوي كل عناوين الإنترنت؛ بدلًا من أن تتذكر أرقام العناوين الطويلة، يكفي أن تكتب اسم الموقع مثل example.com، فيترجمه هذا النظام إلى العنوان الرقمي الصحيح.

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

انتحال أسماء النطاقات (DNS Spoofing): عندما يُرسِل المهاجم ردودًا مزيفة، فيوجِّهك إلى موقع خاطئ.
تسميم الذاكرة المؤقتة (Cache Poisoning): عندما تُخرِّب الذاكرة المؤقتة لخادم نظام أسماء النطاقات، ليخزِّن عناوين مضلِّلة لفترة طويلة.

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

الطبقة الثالثة: امتدادات تحسين أمان نظام أسماء النطاقات (DNSSEC): الخاتم الرقمي للعناوين

لحل مشكلة ضعف نظام أسماء النطاقات، ظهرت امتدادات تحسين أمان نظام أسماء النطاقات (Domain Name System Security Extensions). الفكرة الأساسية بسيطة، إضافة توقيعات رقمية إلى ردود نظام أسماء النطاقات، بحيث يمكن التحقُّق من أنّ المعلومات أصلية ولم يتلاعب بها أحد أثناء انتقالها.

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

تعتمد هذه الامتدادات على ما يسمى سلسلة الثقة (Chain of Trust):

تبدأ من الجذر (Root Zone).
تمر عبر النطاقات العليا (مثل org. أو com.).
تصل في النهاية إلى النطاق الذي تبحث عنه (مثل mynews.org).

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

البروتوكول الآمن لنقل النص التشعبي يحمي المحتوى بعد أن يصل إلى الموقع.
امتدادات تحسين أمان نظام أسماء النطاقات تحمي العنوان الذي يقودك إلى الموقع.

معًا، يشكلان نظامًا أقوى للثقة على الإنترنت.

"تحمي امتدادات تحسين أمان نظام أسماء النطاقات الطريق الذي يسلكه المستخدم للوصول إلى الموقع، بينما يحمي البروتوكول الآمن لنقل النص التشعبي البيانات بعد أن يصل المستخدم هناك."
المصدر: Cloud Flare Learning Center

لماذا يتجاهل الناس امتدادات تحسين أمان نظام أسماء النطاقات رغم أهميتها؟

مع أن هذه الامتدادات توفِّر طبقة أساسية من الحماية، إلّا أن اعتمادها عالميًا ما زال محدودًا جدًا. وهناك عدة أسباب لذلك:

التعقيد في التفعيل: على عكس البروتوكول الآمن لنقل النص التشعبي الذي يمكن أن يُفعَّل بضغطة زر تقريبًا بفضل خدمات مثل «فلنُشفِّر» (Let's Encrypt)، فإنّ تفعيل هذه الامتدادات يتطلب تعاون عدة أطراف: مسجِّل النطاق (Registrar)، ومزوِّد خدمة الاستضافة، وخوادم نظام أسماء النطاقات. أي خلل في هذه السلسلة قد يوقف الموقع عن العمل كليًّا.
قلّة الوعي عند المستخدمين: يعرف المعظم رمز القفل للبروتوكول الآمن لنقل النص التشعبي، بينما لا يوجد مؤشِّر واضح أو مباشر يدلّ على أنّ الامتدادات مفعّلة. وبذلك لا تجد المؤسسات نفسها تحت ضغط من المستخدمين لتطبيقه.
المخاطر التشغيلية: في بعض الحالات قد يؤدي أي خلل في إعداد الامتدادات إلى توقُّف الموقع تمامًا، مما يدفع بعض المسؤولين للتردُّد في تفعيله خشية الوقوع في أخطاء.
غياب الدافع الاقتصادي: بالنسبة لمعظم الشركات الصغيرة، لا يُظهِر تفعيل الامتدادات لها أي فائدة ملموسة أو قيمة تسويقية، على عكس البروتوكول الآمن لنقل النص التشعبي الذي أصبح معيارًا أساسيًا لكسب ثقة المُستخدِمين.

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

مثال عمليّ: ماذا يحدث بدون الامتدادات وماذا لو كانت مُفعَّلة؟

السيناريو الأول — بدون الامتدادات: التوجيه إلى نسخة مزوَّرة

تخيل أنك تكتب في المُتصفِّر: www.mynews.org للوصول إلى موقعك الإخباري الموثوق. أول خطوة يجريها المُتصفِّر هي سؤال نظام أسماء النطاقات عن عنوان بروتوكول الإنترنت المقابل لاسم النطاق، أي أنّ نظام اسم النطاقات هو دفتر عناوين الإنترنت الذي يربط الاسم بالعنوان الرقمي.

إذا كان أحد خوادم نظام أسماء النطاقات أو مسار التحقُّق عرضة للاختراق، أو لهجمات مثل تسميم الذاكرة المؤقتة (Cache Poisoning) أو تزوير الردود، فقد يتمكن المهاجم من إرسال ردّ مُزيَّف يوجِّه مُتصفِّحك إلى خادمه بدلًا من الموقع الحقيقي. ما يحدث ليس مجرد افتراض؛ فقد كشف هجوم كامنسكي عام ٢٠٠٨ عن قدرة المهاجمين على حقن ردود مزوَّرة على نطاق واسع، ولا تزال الأبحاث العملية تُبيّن احتمال عودة هذه التقنيات بصيغ جديدة.

ظهرت في السنوات الماضية نُسَخ مُحدَّثة ومحسَّنة من هجمات تسميم الذاكرة، من أبرزها ما عُرف باسم الهجوم الجانبي (SAD DNS) الذي كشفه وناقشه الباحثون عام ٢٠٢٠، والذي عاد ليُبيِّن أن ثغرات جديدة أو جوانب تنفيذية في أنظمة التشغيل قد تُعيد تمكين هجمات التزوير من جديد إذا لم تُطبّق التصحيحات والمعالجات اللازمة.

كما أنّ السنوات الماضية شهدت حملات عملية من نوع اختطاف نظام أسماء النطاقات (DNS Hijacking)، استهدفت سجلات النطاقات والبنى التحتية لنظام أسماء النطاقات عبر اختراق بيانات الاعتماد أو استغلال ثغرات تشغيلية، وهو ما أدى إلى إعادة توجيه حركة المرور نحو مواقع خبيثة (تبعًا لتقرير تحذيري عن حملة واسعة نشرته وكالة الأمن السيبراني وأمن البنية التحتية (CISA) عام ٢٠١٩).

إضافة إلى ذلك، ظهرت في السنوات الأخيرة دراسات وأوراق علمية حديثة في مؤتمرات يوزنِكس (USENIX) وجمعيّة آلات الحَوسَبة (ACM) وغيرها خلال الفترة بين ٢٠٢٠ و٢٠٢٣، عرَّفت أساليب جديدة لاستهداف مزوِّدي خدمة نظام أسماء النطاقات، مثل استغلال ثغرات في الموجِّهات (Forwarders) أو في التعامل مع سجلات الأسماء المعياري (CNAMEs). وقد بيَّنت هذه الأعمال أن بعض آليات منع التخمين التقليدية لم تعد كافية وحدها من دون طبقات حماية إضافية مثل امتدادات تحسين أمان نظام أسماء النطاقات (DNSSEC) أو تحديثات الأنظمة.

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

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

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

السيناريو الثاني — مع امتدادات تحسين الأمان: محاولة التزوير تُكشَف وتُمنَع

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

حتى مع تطوَّر الهجمات الجانبية (SAD DNS) التي أعادت إحياء أساليب تسميم الذاكرة المؤقتة، تظل آلية التوقيع في امتدادات تحسين أمان نظام أسماء النطاقات (DNSSEC) وسلسلة الثقة وسيلة مباشرة للتحقُّق من أصالة الردود، وتشكل حاجزًا تقنيًا قويًا أمام المهاجمين الذين يحاولون تمرير ردود مزوَّرة. وبطبيعة الحال، يبقى الإعداد الصحيح والتوافق بين جميع الأطراف —من مسجِّل النطاق (Registrar) ونظام أسماء النطاقات (DNS) إلى المُقرِّرات (Resolvers)— شرطًا أساسيًا لنجاح الحماية.

خلاصة المثال (لماذا هذا مهم)

بدون حماية على مستوى نظام أسماء النطاقات، يمكن للمهاجمين أن يوجهوا الجمهور إلى نُسَخ مزيفة حتى لو كان الموقع نفسه يستخدم بروتوكول الآمن لنقل النص التشعبي؛ لأن هذا البروتوكول يضمن أمان الاتصال بعد الوصول للعنوان، لكن لا يمنع التلاعب بالعناوين نفسها.
تفعيل امتدادات تحسين أمان نظام أسماء النطاقات لا يضمن الأمان المطلق، لكنه يُقلِّص بكفاءة فرصة نجاح هجمات التزوير/التوجيه على مستوى نظام أسماء النطاقات، خصوصًا إذا ترافقت مع ممارسات أُخرى (تحديث الخوادم، مراقبة السجلات، واستخدام DNS-over-HTTPS/TLS للخصوصية).

حين تكتمل طبقات الثقة

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

قبل عشر سنوات، لم يكن البروتوكول الآمن لنقل النص التشعبي (HTTPS) منتشرًا كما هو اليوم، وكانت المواقع تتردَّد في استخدامه بسبب التكلفة أو التعقيد. ثم جاءت مبادرات مثل «فلنُشفِّر» Let's Encrypt، ومعها تحوَّل هذا البروتوكول إلى معيار بديهي.

تقف اليوم امتدادات تحسين أمان نظام أسماء النطاقات في نفس المرحلة تقريبًا، فهي تقنية يعرفها المتخصِّصون، لكن حضورها محدود عند أصحاب المواقع والمستخدمين.

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

وقد يشهد المستقبل تحولًا مشابهًا لما حدث مع البروتوكول الآمن لنقل النص التشعبي (HTTPS)، حين تصبح امتدادات تحسين أمان نظام أسماء النطاقات (DNSSEC) جزءًا طبيعيًا من البنية التحتية للويب.

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