كيف يعمل Kerberos؟ شرح بروتوكول المصادقة خطوة بخطوة

يُعد Kerberos واحداً من أهم بروتوكولات المصادقة في بيئات الشركات الحديثة، خصوصاً داخل أنظمة Windows وبيئات Active Directory. وتكمن أهميته في أنه يتيح التحقق من هوية المستخدم والخدمة بطريقة آمنة، من دون إرسال كلمة المرور عبر الشبكة بشكل مباشر.

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

ما هو Kerberos؟

Kerberos هو بروتوكول مصادقة صُمم لتأمين التحقق من الهوية بين العميل والخادم عبر شبكة غير موثوقة. الفكرة الأساسية فيه بسيطة: بدلاً من تمرير بيانات الاعتماد الحساسة بين الأجهزة في كل مرة، يعتمد البروتوكول على نظام تذاكر Tickets يثبت هوية المستخدم بشكل آمن ومؤقت.

طُوّر البروتوكول في معهد MIT خلال ثمانينيات القرن الماضي، ثم جرى تحسينه واعتماده على نطاق واسع، خاصة في أنظمة Microsoft ليكون بديلاً أكثر أماناً من NTLM.

وإذا أردنا تلخيص الفرق بسرعة بين Kerberos وNTLM، فيمكن القول إن NTLM يعتمد على تبادل بيانات تحقق بين الطرفين، بينما يتجنب Kerberos إرسال بيانات الاعتماد نفسها عبر الشبكة.

لماذا يُستخدم Kerberos في بيئات المؤسسات؟

عندما يسجل الموظف الدخول مرة واحدة ثم يتمكن من الوصول إلى البريد الإلكتروني، وخوادم الملفات، وبعض التطبيقات الداخلية دون إعادة إدخال كلمة المرور في كل مرة، فغالباً هناك نظام Single Sign-On يعمل في الخلفية، ويكون Kerberos جزءاً رئيسياً منه.

هذا البروتوكول مناسب جداً للشبكات المؤسسية لأنه يحقق توازناً مهماً بين الأمان، وسهولة الاستخدام، وقابلية الإدارة المركزية.

المكونات الأساسية في بنية Kerberos

يعتمد Kerberos على مركز توزيع مفاتيح يُعرف باسم Key Distribution Center أو KDC. وفي بيئات Active Directory يكون هذا الدور موجوداً غالباً على وحدات التحكم بالمجال Domain Controllers.

ويتكون KDC عادة من العناصر التالية:

• Authentication Service (AS): يتولى التحقق من المستخدم عند بدء طلب الوصول.
• Ticket Granting Service (TGS): يصدر تذاكر الوصول إلى الخدمات المطلوبة بعد نجاح التحقق الأولي.
• قاعدة بيانات Kerberos: تضم معلومات الحسابات، مثل المعرّفات وكلمات المرور أو القيم المرتبطة بها، وغالباً تكون ضمن LDAP أو قواعد SAM داخل بيئة Active Directory.

كيف يعمل Kerberos؟

لفهم آلية العمل، من الأفضل تقسيم العملية إلى مراحل واضحة تبدأ من إدخال المستخدم لبياناته وتنتهي بحصوله على الخدمة المطلوبة.

1. طلب المصادقة الأولي

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

• معرّف الأمان SID.
• اسم الخدمة المطلوبة.
• عنوان IP الخاص بالمستخدم.
• العمر المطلوب لتذكرة منح التذاكر TGT.

من المهم ملاحظة أن كلمة المرور لا تُرسل كما هي عبر الشبكة، بل تُستخدم محلياً لاشتقاق سر مشترك يساعد على إثبات الهوية.

2. إصدار تذكرة منح التذاكر TGT

إذا كان المستخدم موجوداً في قاعدة البيانات ونجحت عملية التحقق، تصدر خدمة AS تذكرة تُسمى Ticket Granting Ticket أو TGT. هذه التذكرة لا تمنح الوصول إلى الخدمة مباشرة، لكنها تسمح للمستخدم لاحقاً بطلب تذاكر خدمات أخرى دون إعادة إدخال كلمة المرور.

تتضمن هذه المرحلة عادة معلومات مثل:

• SID الخاص بالمستخدم.
• هوية TGS.
• طابعاً زمنياً Timestamp.
• عنوان IP.
• مدة صلاحية TGT.
• مفتاح جلسة Session Key.

3. طلب الوصول إلى خدمة محددة عبر TGS

بعد حصول المستخدم على TGT، يرسلها إلى خدمة منح التذاكر TGS مع اسم الخدمة التي يريد الوصول إليها. كما يرسل ما يُعرف باسم Authenticator، وهو جزء يحتوي غالباً على هوية المستخدم وطابع زمني، ويكون مشفراً باستخدام مفتاح الجلسة.

هذه الخطوة تسمح لـ TGS بالتحقق من أن الطلب صادر فعلاً من المستخدم المصرح له، وليس من طرف يعيد استخدام تذكرة قديمة.

4. إصدار تذكرة الخدمة

إذا تحققت TGS من البيانات بنجاح، فإنها ترسل للمستخدم رسالتين:

• الأولى تحتوي على Service Ticket موجهة إلى الخادم الذي يقدم الخدمة، وتكون مشفرة بمفتاح الخدمة السري.
• الثانية تحتوي على مفتاح جلسة الخدمة، وتكون مشفرة بمفتاح جلسة المستخدم.

وتضم تذكرة الخدمة عادة:

• هوية المستخدم.
• عنوان IP.
• مدة الصلاحية.
• مفتاح جلسة الخدمة.

5. الوصول إلى الخادم المطلوب

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

إذا تطابقت البيانات وكانت التذكرة صالحة، فإن الخادم يرد برسالة تؤكد هويته للمستخدم. بهذه الطريقة تتم المصادقة المتبادلة بين الطرفين، وليس فقط التحقق من المستخدم وحده.

كيف تتم عملية التشفير في Kerberos؟

عند إنشاء حساب جديد داخل Active Directory، يحصل المستخدم على اسم مستخدم وكلمة مرور. بعد ذلك يستخدم عميل Kerberos قيمة إضافية تسمى salt، وهي سلسلة فريدة تُستخدم لزيادة العشوائية وتقوية اشتقاق السر.

في كثير من البيئات، تكون قيمة salt مرتبطة باسم المستخدم. ثم تُمرر هذه البيانات إلى دالة مثل string2Key لاشتقاق السر المشترك Shared Secret.

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

أهم مزايا بروتوكول Kerberos

• عدم إرسال كلمات المرور النصية الصريحة عبر الشبكة.
• تقليل الحاجة إلى التحقق المتكرر طوال مدة صلاحية التذكرة.
• دعم تسجيل الدخول الموحد Single Sign-On.
• إمكانية دعم المصادقة متعددة العوامل MFA.
• المصادقة المتبادلة بين العميل والخادم.
• سهولة التتبع والمراجعة من خلال السجلات المركزية.

هذه الخصائص تجعل Kerberos خياراً قوياً خصوصاً في البيئات التي تحتوي على عدد كبير من المستخدمين والخدمات.

نقاط الضعف والمخاطر الأمنية في Kerberos

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

هجوم Golden Ticket

في هذا الهجوم ينشئ المهاجم تذكرة Kerberos مزورة تمنحه صلاحيات واسعة داخل المجال. ويحتاج ذلك عادة إلى وصول إداري مرتفع داخل Active Directory. خطورة هذا الهجوم تكمن في أن التذكرة قد تظل صالحة لفترة طويلة جداً إذا لم تُعالج البنية بشكل صحيح.

المعالجة المعتادة تتطلب إعادة تعيين حساب krbtgt مرتين، مع انتظار المدة المناسبة بين العمليتين حتى تنتهي صلاحية التذاكر القديمة.

هجوم Silver Ticket

يشبه Silver Ticket الهجوم السابق، لكنه يستهدف خدمة محددة بدلاً من السيطرة الواسعة على المجال كله. يحدث عادة بعد اختراق حساب خدمة أو استخراج بيانات مرتبطة به. ومن أسباب خطورته أنه قد لا يحتاج إلى تواصل مباشر مع Domain Controller أثناء التزوير.

هجوم Skeleton Key

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

هجوم Pass the Hash

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

هجوم Pass the Ticket

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

هجوم Overpass the Hash

يجمع هذا الأسلوب بين Pass the Hash وPass the Ticket، حيث يُستخدم الهاش المخترق للحصول على تذكرة Kerberos يمكن استغلالها للوصول إلى الموارد.

هجوم Kerberoasting

يُعد Kerberoasting من أشهر الهجمات ضد حسابات الخدمات. عندما تكون خدمة ما مرتبطة باسم رئيسي للخدمة SPN، يمكن للمستخدم صاحب TGT صالح أن يطلب TGS لتلك الخدمة. بعدها يحاول المهاجم كسر الهاش المرتبط بحساب الخدمة خارجياً Offline.

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

هجوم إعادة التشغيل Replay Attack

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

كيف تحمي بيئة Kerberos من الهجمات؟

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

1. تفعيل السجلات والمراقبة المستمرة

يجب مراجعة سجلات Domain Controller باستمرار، خاصة الأحداث المرتبطة بطلبات التذاكر مثل الحدث 4769. ويمكن أن تساعد الأنماط غير الطبيعية، مثل أسماء حسابات غير موجودة أو استخدام أنواع تشفير قديمة، في اكتشاف محاولات تزوير أو استغلال مبكر.

2. تطبيق التحديثات الأمنية دون تأخير

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

3. تقييد تفويض الحسابات الحساسة

يُفضّل تعيين الحسابات الإدارية وحسابات الخدمات الحساسة على أنها Sensitive and cannot be delegated. هذه الخطوة تحد من قدرة المهاجم على استخدام الحسابات المخترقة في الحركة الجانبية داخل الشبكة.

4. عدم إضافة حسابات الأجهزة إلى مجموعات إدارية

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

5. تشغيل LSASS في الوضع المحمي

تُعد عملية LSASS هدفاً مباشراً للبرمجيات التي تحاول سرقة التذاكر أو الهاشات من الذاكرة. وعند تشغيلها كوحدة محمية، يصبح الوصول إليها أكثر صعوبة بالنسبة للأدوات غير الموثوقة.

يمكن ضبط ذلك عبر السجل بإضافة القيمة RunAsPPL داخل المسار التالي:

HKLM\SYSTEM\CurrentControlSet\Control\LSA

وتعيينها إلى القيمة 1 ثم إعادة تشغيل النظام.

6. فرض التحقق من PAC

تحتوي شهادة السمات المميزة Privileged Attribute Certificate أو PAC على معلومات صلاحيات المستخدم. وعند تفعيل التحقق منها، يصبح من الأصعب تمرير امتيازات مزورة إلى TGS.

يمكن ضبط ذلك من خلال تعيين المفتاح التالي:

HKLM\System\CurrentControlSet\Control\LSA\Kerberos\Parameters

إلى القيمة 1.

7. تطبيق مبدأ أقل صلاحية

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

8. استخدام كلمات مرور قوية وفريدة

يجب أن تكون كلمات مرور الحسابات الإدارية وحسابات الخدمات طويلة ومعقدة وفريدة. وتكتسب هذه النقطة أهمية مضاعفة مع الحسابات المرتبطة بـ SPN، لأنها هدف مباشر لهجمات Kerberoasting.

9. تفعيل Windows Defender Credential Guard

يساعد Credential Guard على حماية بيانات الاعتماد الحساسة، مثل NTLM Hashes وTGTs، من خلال عزلها داخل بيئة محمية تعتمد على تقنيات افتراضية. وهذا يقلل فرص نجاح هجمات مثل Pass the Hash وPass the Ticket.

10. تعطيل تشفير RC4 وتفعيل AES

يُعد RC4-HMAC خياراً قديماً وضعيفاً نسبياً من الناحية الأمنية. لذلك يُستحسن تعطيله متى كان ذلك ممكناً، مع تفعيل دعم AES، خاصة في علاقات الثقة بين المجالات وحسابات الدخول الموحد.

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

مقارنة سريعة بين Kerberos وNTLM

أفضل الممارسات لإدارة Kerberos بكفاءة

1. راجع سجلات المجال بشكل دوري.
2. احمِ حساب krbtgt والحسابات الإدارية بعناية قصوى.
3. استخدم كلمات مرور طويلة جداً لحسابات الخدمات.
4. عطّل أساليب التشفير القديمة ما أمكن.
5. قلل الاعتماد على الحسابات ذات الصلاحيات الواسعة.
6. اعزل الأنظمة الحساسة وطبّق ضوابط وصول دقيقة.
7. اختبر إعدادات المصادقة بعد كل تغيير على مستوى البنية.

الخلاصة التقنية

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