نقاط العمى في تسجيل المصادقة في السحابة

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

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

لماذا تحتوي سجلات المصادقة على فجوات

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

يتولى Azure Active Directory (المعروف الآن باسم Entra ID) المصادقة لـ Microsoft 365 وموارد Azure والتطبيقات الخارجية عبر SAML/OIDC، والتطبيقات المحلية القديمة عبر App Proxy، وService Principals، والهويات المُدارة، وغيرها. لكل مسار من هذه المسارات خلفية خاصة به، وخط تسجيل خاص به، وحالات حدّية خاصة به. تُولَّد سجلات تسجيل الدخول بواسطة خدمة المصادقة، لكن بعض تدفقات المصادقة تتجاوز الخدمة القياسية أو تستخدم مسارات قديمة سبقت بنية التسجيل الحالية.

فجوات البروتوكولات القديمة

تحافظ Microsoft على التوافق الخلفي مع بروتوكولات مصادقة تعود إلى أوائل الألفينات، وهي بروتوكولات سبقت بنية التسجيل الحديثة لديها. تستخدم بعض مسارات المصادقة في SMTP وIMAP وPOP3 تدفقات 'Basic Auth' التي تتحقق من الهوية على طبقة نقل البريد، لا عبر نقطة نهاية الرموز القياسية في Azure AD. وقد لا تُنتج هذه المصادقات إدخالات سجل تسجيل دخول مماثلة لتلك التي تنتجها تدفقات OAuth/OIDC الحديثة.

أوقفت Microsoft Basic Auth تدريجيًا منذ سنوات، لكن الإيقاف بطيء في بيئات المؤسسات. فالمؤسسات التي لا تزال تستخدم عملاء بريد قدامى، أو ماسحات ضوئية ترسل المستندات عبر البريد، أو تطبيقات أعمال قديمة، قد تبقي Basic Auth مفعّلًا. وكل مسار قديم يمثل فجوة محتملة في التسجيل.

مصادقة Service Principal

تختلف الـ Service Principals، وهي هويات غير بشرية تستخدمها التطبيقات والأتمتة، في طريقة مصادقتها عن المستخدمين. تظهر أحداث تسجيل دخولها في سجل منفصل (تسجيلات service principal مقابل التفاعلية مقابل غير التفاعلية). فرق الأمن التي تراقب سجل تسجيل الدخول التفاعلي فقط تفوتها أنشطة service principal بالكامل.

وهذا مهم لأن الـ Service Principals المخترقة من أكثر نواقل الهجوم شيوعًا. فالمهاجم الذي يحصل على بيانات اعتماد أو شهادة service principal يستطيع المصادقة كذلك التطبيق والوصول إلى أي موارد يملك صلاحية عليها. وإذا كانت فرق الأمن تراقب تسجيلات المستخدمين فقط، فلن ترى ذلك أبدًا.

إعادة استخدام الرموز وتجديدها

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

مشكلة هندسة الكشف

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

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

Typical detection rule logic:
IF sign-in from unusual location
AND sign-in at unusual time
AND multiple failed attempts followed by success
THEN alert: possible credential compromise
What this misses:
- Authentication via legacy protocol → no sign-in log entry
- Stolen refresh token → appears as normal non-interactive sign-in
- Service principal abuse → in a different log stream entirely
- Authentication bypasses → sign-in doesn't appear at all
The rule is correct. The data it operates on is incomplete.

ما الذي يمكنك فعله فعلًا

لا يمكنك إصلاح فجوات تسجيل مزودي السحابة، فهذه مسؤولية Microsoft (أو AWS أو Google). لكن يمكنك بناء استراتيجيات كشف لا تعتمد وحدها على اكتمال سجلات المصادقة.

مراقبة مصادر السجلات المتعددة

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

-- Detection query: activity without recent authentication
-- (KQL-style for Azure Sentinel/Microsoft Sentinel)
let timeframe = 24h;
let activity_logs = AuditLogs
| where TimeGenerated > ago(timeframe)
| summarize Actions = count() by Identity, bin(TimeGenerated, 1h);
let signin_logs = SigninLogs
| where TimeGenerated > ago(timeframe)
| summarize LastSignIn = max(TimeGenerated) by UserPrincipalName;
activity_logs
| join kind=leftanti signin_logs
on $left.Identity == $right.UserPrincipalName
| where Actions > 5  // filter noise
// Results: identities with activity but no sign-in log entry
// These need investigation — either a logging gap or a bypass

تعطيل المصادقة القديمة

إذا كنت لا تستخدم البروتوكولات القديمة (Basic Auth لـ SMTP وIMAP وPOP3)، فعطّلها. هذا يقضي على فئات كاملة من فجوات التسجيل، لأن مسارات المصادقة التي تتجاوز التسجيل الحديث لن يعود بالإمكان استخدامها. ويمكن لسياسات Conditional Access في Azure حظر المصادقة القديمة لكل مستخدم، أو لكل مجموعة، أو على مستوى المستأجر بالكامل.

قبل التعطيل، راجع الاستخدام الحالي. ومن المفارقة أن سجلات تسجيل الدخول في Azure تُظهر بعض محاولات المصادقة القديمة، ويساعد دفتر Entra ID الخاص بالمصادقة القديمة في تحديد التطبيقات التي ما زالت تستخدم بروتوكولات قديمة. أصلح تلك التطبيقات أولًا، ثم احظر المصادقة القديمة.

مراقبة نشاط الرموز

فعّل Continuous Access Evaluation (CAE) إذا كانت بيئتك تدعمه. يتيح CAE لـ Azure AD سحب الرموز شبه فوريًا عند تغير الظروف (تعطيل المستخدم، أو اكتشاف تسجيل دخول عالي الخطورة، أو تغير موقع IP). ومن دون CAE، يظل رمز الوصول المسروق صالحًا حتى ينتهي، عادةً بعد ساعة، بغض النظر عما تفعله فرق الأمن.

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

اختبر تسجيلاتك بنفسك

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

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

الدرس الأوسع

ثغرات تجاوز تسجيل Azure ليست حكرًا على Microsoft. فكل مزود سحابي لديه مسارات مصادقة ذات تسجيل ناقص. فلدى AWS CloudTrail فجوات معروفة خاصة به، منها عمليات معينة على مستوى التحكم في بعض المناطق، وعمليات تولي أدوار service-linked معينة، وأنماط تسلسل أدوار عبر الحسابات قد تحجب الهوية الأصلية. ولسجلات التدقيق في Google Cloud حالات حدّية مماثلة.

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

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