اختراق نظام الدعم في Okta يكشف الاعتماد الخفي وراء الهوية السحابية

ملخص

• أكدت Okta أن مهاجماً استخدم حساب خدمة مخترق لنظام الدعم للوصول إلى ملفات مرتبطة بـ 134 عميلاً وأعاد استخدام آثار الجلسة لاختراق خمس جلسات عملاء؛ وكشف مراجعة لاحقة بشكل منفصل أن المهاجم قام بتنزيل تقرير يحتوي على أسماء وعناوين البريد الإلكتروني لجميع مستخدمي نظام دعم Okta المتأثر.
• كان السبب المباشر هو بيانات اعتماد مسروقة، لكن المساءلة العملية تمتد إلى عناصر التحكم التي جعلت بيانات الاعتماد مفيدة: وصول دعم متميز، آثار تشخيصية غير منقحة، تفسير سجلات غير مكتمل، جلسات إدارية قابلة للنقل، تأخير في التصعيد عبر العملاء وعملية إخطار تعتمد على العملاء لمساعدة مزود الهوية على اكتشاف اختراقه الخاص.

التفاصيل الأكثر أهمية في اختراق نظام دعم Okta لعام 2023 ليست أن مكتب المساعدة تم اختراقه. بل أن مكتب المساعدة كان قريباً بما يكفي من عمليات الهوية المتميزة بحيث يمكن لملف استكشاف أخطاء المتصفح أن يعمل كبيانات اعتماد لحامل لجلسة مدير عميل.

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

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

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

تعرضان، ليس رقماً واحداً متزايداً

غالباً ما تضغط الحسابات العامة الحادث في ادعاء أن Okta قالت أولاً إن 1٪ من العملاء تأثروا ثم اعترفت لاحقاً أن جميع العملاء تأثروا. هذا الاختصار يحجب مجموعتي بيانات مختلفتين ونوعين مختلفين من المخاطر.

في 20 أكتوبر، قال الإعلان العام الأولي لـ Okta إن جهة تهديد استخدمت بيانات اعتماد مسروقة للوصول إلى نظام إدارة حالات الدعم وعرض الملفات التي تم تحميلها من قبل عملاء معينين. حذر من أن ملفات أرشيف HTTP، أو HAR، يمكن أن تحتوي على ملفات تعريف الارتباط ورموز الجلسة التي تسمح بالانتحال. قال الإعلان إن العملاء المتأثرين تم إخطارهم، وأن نظام الدعم منفصل عن خدمة Okta الإنتاجية، وأن نظام إدارة حالات Auth0/CIC لم يتأثر.

في 3 نوفمبر، حساب السبب الجذري والمعالجة لـ Okta قاد كمية التعرض للوصول إلى الملفات. من 28 سبتمبر حتى 17 أكتوبر، حصل المهاجم على وصول غير مصرح به إلى ملفات مرتبطة بـ 134 عميلاً من عملاء Okta، أي أقل من 1٪ من عملائها. كان بعضها ملفات HAR تحتوي على رموز جلسة. قال Okta إن المهاجم استخدم تلك الرموز لاختراق جلسات شرعية لخمسة عملاء. نشر ثلاثة من الخمسة حساباتهم الخاصة: 1Password و BeyondTrust و Cloudflare.

في 29 نوفمبر، بعد إعادة إنشاء التقارير التي قام بتشغيلها المهاجم، كشفت Okta عن تعرض ثانٍ في إشعار الحادث المحدث. قام المهاجم بتنزيل تقرير يحتوي على أسماء وعناوين البريد الإلكتروني لجميع مستخدمي نظام دعم العملاء المتأثر. غطت الفئة المتأثرة عملاء Workforce Identity Cloud و Customer Identity Solution، باستثناء العملاء في بيئات FedRAMP High و Department of Defense Impact Level 4 الذين يستخدمون نظام دعم منفصل. تم استبعاد نظام حالات دعم Auth0/CIC مرة أخرى. بالنسبة لـ 99.6٪ من المستخدمين في التقرير، قال Okta إن معلومات الاتصال الوحيدة المسجلة كانت الاسم الكامل وعنوان البريد الإلكتروني. كان لقالب التقرير حقول أخرى، لكن معظمها كان فارغاً؛

قال Okta إنه لا يحتوي على بيانات اعتماد المستخدم أو بيانات شخصية حساسة.

تدعم هذه الحقائق أربعة بيانات دقيقة:

1. تم الوصول إلى ملفات مرتبطة بـ 134 عميلاً.
2. تم استخدام آثار الجلسة من بعض الملفات التي تم الوصول إليها لاختراق خمس جلسات عملاء.
3. تم تنزيل تقرير أوسع بكثير يحتوي على أسماء وعناوين بريد إلكتروني لمستخدمي الدعم.
4. إدخال التقرير لا يعني أنه تم الوصول إلى مستأجر الشخص أو جلسة المسؤول الخاصة به.

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

قدمت Okta تحديث نوفمبر كمعرض لـ نموذج 8-K المقدم إلى لجنة الأوراق المالية والبورصات الأمريكية. هذا يجعل الإفصاح جزءاً من سجل المستثمرين العام للشركة. لا يحول حساب الشركة إلى نتيجة من هيئة الأوراق المالية والبورصات، ونص 8-K نفسه على أن المعلومات تم تقديمها بدلاً من اعتبارها مودعة لأغراض مسؤولية معينة. هذا التمييز مهم لأن السرد الواقعي العام الأكثر تفصيلاً لا يزال يأتي من Okta والعملاء المتأثرين، وليس من حكم منظم منشور.

الأثر الداعم الذي يمكنه انتحال شخصية المسؤول

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

يصف دليل إنشاء HAR الخاص بـ Okta التنسيق كطريقة لتكرار أخطاء المستخدم النهائي أو المسؤول ويحذر المستخدمين من إزالة أو إخفاء المعلومات السرية والشخصية قبل إرسال الملف. توثيق Chrome DevTools الحالي يجعل المخاطرة ملموسة بشكل غير عادي: التصدير المنقح الافتراضي يستبعد رؤوسCookieوSet-CookieوAuthorization، بينما يجب تمكين التصدير مع البيانات الحساسة بشكل منفصل. لا ينبغي إسقاط هذا السلوك الحالي للمتصفح إلى الوراء كدليل على الواجهة الدقيقة التي رآها العميل في سبتمبر 2023. لكنه يظهر، مع ذلك، أنه يمكن نقل تنقية HAR من تحذير في مقال دعم إلى السلوك الافتراضي لأداة الجمع.

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

يصف OWASP Session Management Cheat Sheet لماذا هذا خطير جداً: بعد المصادقة، يكون معرف الجلسة مكافئاً مؤقتاً لأقوى طريقة مستخدمة لمصادقة المستخدم. يمكن لمفتاح FIDO2 أن يجعل من الصعب جداً إجراء تسجيل دخول تصيد جديد، لكن جلسة حامل قابلة للنقل قد تسمح للمهاجم بالوصول بعد هذا الفحص. هذا لا يجعل المصادقة المقاومة للتصيد عديمة الفائدة. يعني أن قوة المصادقة وقوة الجلسة هما سؤالان تحكم منفصلان.

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

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

كان العملاء أول أجهزة استشعار موزعة

حسابات العملاء العامة هي أكثر من مجرد حكايات مؤكدة. تكشف عن عناصر التحكم التي عملت عندما لم تكن تليمترية الدعم المورد قد أنتجت بعد نتيجة عبر العملاء.

1Password: حدث إداري غير متوقع

يقول الجدول الزمني لـ Okta إن 1Password أبلغ عن نشاط مشبوه في 29 سبتمبر وأن الشركتين اجتمعتا مراراً حتى 2 أكتوبر. تقرير حادثة 1Password المعاصر وصف نشاطاً إدارياً غير متوقع في بيئة Okta الخاصة به وأضاف لاحقاً أن المجموعة الأولى من سجلات الوصول إلى الملفات من Okta لم تظهر وصولاً غير مصرح به إلى ملف HAR ذي الصلة. بعد أن أكدت Okta اختراق نظام الدعم، أظهرت سجلات إضافية أن حساب خدمة مخترق قد وصل إليه. وفقاً لملحق 1Password، كان الملف موجوداً تحت معرفين كائنيين متميزين في نظام بائع الدعم، بينما غطى التحليل الأول واحداً فقط.

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

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

BeyondTrust: رفض السياسة، تحول API، وتصعيد مستمر

كتابة حادثة BeyondTrust توفر أوضح وصف دقيقة بدقيقة لمسار ملف الدعم. في 2 أكتوبر، بناءً على طلب دعم Okta، قام مسؤول BeyondTrust بإنشاء وتحميل ملف HAR لمشكلة دعم غير أمنية. احتوى الملف على طلب API وملف تعريف ارتباط جلسة. في غضون 30 دقيقة، حاول مهاجم استخدام جلسة المسؤول من عنوان IP في ماليزيا مرتبط بخدمات إخفاء الهوية.

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

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

أصبحت BeyondTrust أيضاً جهاز استشعار خارجي لـ Okta. اتصلت بـ Okta في 2 أكتوبر، وطلبت التصعيد في 3 أكتوبر، واجتمعت مع موظفي الدعم والأمن، وطلبت سجلات أكثر اكتمالاً، واستمرت في الجدال بأن الأدلة تشير إلى اختراق داخل مؤسسة دعم Okta. في 13 أكتوبر قدمت عنوان IP المشبوه الذي قال Okta لاحقاً إنه مكّن البحث الحاسم. كان هذا عملاً استقصائياً مكلفاً قام به عميل لأن العميل يمكنه رؤية التأثير في مستأجره بينما يمكن لـ Okta رؤية السبب المشترك في بيئة الدعم الخاصة به.

Cloudflare: احتواء سريع، ثم تدوير غير مكتمل

حساب حادثة أكتوبر الأول لـ Cloudflare قال إنه اكتشف نشاطاً في 18 أكتوبر يتضمن رمز جلسة إدارية مأخوذ من تذكرة دعم Okta. اخترق المهاجم حسابي موظفين في Cloudflare ضمن منصة Okta. قالت Cloudflare إنها اكتشفت النشاط قبل أكثر من 24 ساعة من إخطار Okta لها واحتوت الحدث قبل أن يتمكن المهاجم من تأسيس الثبات أو الوصول إلى بيانات العميل أو أنظمة العميل أو شبكة الإنتاج.

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

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

توضح حالة Cloudflare أيضاً أن الاحتواء السريع الأولي ليس هو نفسه القضاء التام. في فبراير 2024، كشفت Cloudflare عن حادثة عيد الشكر منفصلة استخدم فيها مهاجم رمز وصول واحد وثلاثة بيانات اعتماد حساب خدمة مأخوذة خلال اختراق أكتوبر لـ Okta. اعترفت Cloudflare بأنها فشلت في تدوير بيانات الاعتماد الأربعة هذه. من 14 نوفمبر، وصل المهاجم إلى بيئة Atlassian المستضافة ذاتياً، وعرض الوثائق الداخلية وكمية محدودة من الكود المصدري، وحاول دون نجاح الوصول إلى خادم وحدة تحكم في مركز بيانات غير إنتاجي بعد. قالت Cloudflare إنه لم يتأثر أي بيانات عميل أو أنظمة عميل أو تكوين شبكة عالمي.

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

تسلسل الكشف والإخطار

التسلسل أساسي لأن المهاجم احتفظ بالوصول بينما كان العملاء يبلغون بالفعل عن الأعراض.

يقول الجدول الزمني لـ Okta في 3 نوفمبر إن الوصول غير المصرح به لجهة التهديد استمر من 28 سبتمبر إلى 17 أكتوبر. أبلغت 1Password عن نشاط مشبوه في 29 سبتمبر. بدأت Okta التحقيق في ذلك اليوم لكنها اشتبهت في البداية في برمجيات خبيثة أو تصيد في 1Password. أبلغت BeyondTrust عن نشاط مشبوه في 2 أكتوبر. أبلغ عميل ثالث في 12 أكتوبر. قدمت BeyondTrust عنوان IP المشبوه في 13 أكتوبر. في 16 أكتوبر، استخدمت Okta هذا المؤشر لتحديد حساب خدمة مرتبط بأحداث سجل نظام الدعم غير الملاحظة سابقاً. في 17 أكتوبر، عطلت Okta حساب الخدمة، وأنهت جلساته، وفحصت الملفات التي تم الوصول إليها، وألغت الرموز المضمنة في ملفات HAR التي حددتها.

قالت Okta إن فجوة في السجلات ثم عقدت النطاق. في 18 أكتوبر اكتشفت أن سجلات نظام الدعم كانت تفتقد الساعات الأخيرة من وصول المهاجم. أعاد استعلام متكرر سجلاً أكثر اكتمالاً. في 19 أكتوبر وجدت ملفات إضافية تم تنزيلها، وألغت الرموز المضمنة المحددة حديثاً، وحددت Cloudflare كخامس عميل مستهدف، وأبلغت جهات الاتصال الأمنية المسجلة عبر قاعدة عملائها حول ما إذا كانت مؤسساتهم متأثرة بالحادث المعروف آنذاك. تبع الإعلان العام في 20 أكتوبر. ذهب معلومات السبب الجذري والمعالجة إلى جهات الاتصال الأمنية المسجلة في 2 نوفمبر ونشرت في 3 نوفمبر.

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

يحدد التسلسل الزمني أربعة تأخيرات على الأقل بأسباب مختلفة:

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

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

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

المحفز والسبب الجذري والظروف التمكينية

المحفز المؤكد كان استخدام بيانات اعتماد حساب خدمة مخترق. قال Okta إن حساب الخدمة كان مخزناً في نظام الدعم وكان لديه إذن لعرض وتحديث حالات دعم العملاء. أثناء التحقيق، وجدت Okta أن موظفاً سجل الدخول إلى ملف شخصي شخصي لـ Google في Chrome على كمبيوتر محمول مدار من Okta وأن اسم المستخدم وكلمة المرور لحساب الخدمة تم حفظهما في حساب Google الشخصي للموظف.

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

كشف بيانات الاعتماد يشرح كيف بدأ الوصول، لكنه لا يشرح بالكامل مدة الحادث أو تأثيره. عدة ظروف تمكينية حولت بيانات اعتماد واحدة إلى حدث هوية متعدد العملاء:

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

ملف تعريف متصفح شخصي يمكنه الاحتفاظ ببيانات اعتماد خدمة عمل.سياسة Okta اللاحقة حظرت الملفات الشخصية الشخصية لـ Google في Chrome على أجهزة الكمبيوتر المحمولة المدارة. حقيقة أن هذا كان علاجاً يشير إلى أن التكوين السابق سمح لحدود المزامنة الشخصية بالتقاطع مع جهاز عمل مدار.

آثار العملاء الحساسة دخلت مستودع الدعم.حذرت Okta العملاء من تنقية ملفات HAR، لكن الملفات التي تحتوي على مواد جلسة حية كانت موجودة. تحذير يترك التنفيذ للمسؤول تحت ضغط لحل مشكلة. لم يضمن تدفق الدعم بشكل موثوق إزالة الحقول الخطرة قبل التحميل.

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

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

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

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

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

من كانت لديه القدرة على منع أو اكتشاف أو الحد أو تقصير الضرر

تصبح المساءلة أكثر وضوحاً عندما ترتبط بقدرة السيطرة.

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

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

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

سيطر العملاء على مستوى الامتياز للحساب المستخدم لالتقاط التشخيصات، سواء لتنقية ملف، وسياسات مستأجر Okta الخاصة بهم، والسجلات والاكتشافات المستقلة، وعمر الجلسة، ومراقبة سلوك المسؤول، والتقسيم النهائي، وتدوير بيانات الاعتماد بعد الإخطار. أظهرت BeyondTrust أن سياسة الجهاز غير الافتراضية وتحليلات السلوك يمكن أن تحد من جلسة معاد تشغيلها. أظهرت Cloudflare أن تقسيم الشبكة يمكن أن يحمي الإنتاج، ثم أظهرت أن جرد الأسرار غير المكتمل يمكن أن يترك مساراً متأخراً مفتوحاً. أظهرت 1Password قيمة التنبيهات للتقارير الإدارية غير المتوقعة والمراجعة السريعة للتكوين.

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

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

اعتماد مزود الهوية يشمل الاسترداد والدعم

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

كشف اختراق 2023 عن ثلاثة أشكال من الاعتماد.

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

ثانياً، اعتمد العملاء على Okta للحصول على أدلة حول مستودع الدعم. يمكن للعميل رؤية إجراء إداري مستحيل ولكن ليس من قام بتنزيل مرفقه من نظام حالات المزود. احتاج 1Password و BeyondTrust إلى سجلات من Okta لربط حدث المستأجر بملف الدعم. اعتمد المزود، بدوره، على تليمترية العميل لاكتشاف أي أحداث دعم كانت ضارة. تم تقسيم الأدلة عبر الحدود التنظيمية.

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

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

اقتصاديات قناة التصعيد

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

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

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

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

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

تصميم تصعيد فعال للمزود سيجعل خمس قدرات قابلة للملاحظة:

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

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

المعالجة: ما تغير وما بقي صعب التحقق

حساب Okta في 3 نوفمبر أدرج أربع خطوات مكتملة. عطلت حساب الخدمة المخترق. استخدمت تكوين Chrome للمؤسسات لمنع الموظفين من تسجيل الدخول إلى الملفات الشخصية الشخصية لـ Google على أجهزة الكمبيوتر المحمولة المدارة من Okta. أضافت قواعد مراقبة وكشف لنظام الدعم. أصدرت ميزة وصول مبكر تربط رموز جلسة المسؤول بموقع الشبكة، وتتطلب إعادة المصادقة بعد اكتشاف تغيير في الشبكة.

تحديث 29 نوفمبر أضاف ضوابط مواجهة للعميل. أوصت Okta بمصادقات مقاومة للتصيد للمسؤولين، وربط جلسة المسؤول بناءً على تغيير في النظام المستقل، ووقت خروج لوحة تحكم المشرف أكثر تشدداً. أعلنت عن حد أقصى افتراضي للجلسة يبلغ 12 ساعة ووقت خمول يبلغ 15 دقيقة، مع النشر حتى يناير 2024. حثت أيضاً العملاء على مراجعة التحقق من مكتب المساعدة قبل إعادة تعيين كلمة المرور أو العامل. تعالج هذه الإجراءات مدة إعادة التشغيل ومخاطر الهندسة الاجتماعية، على الرغم من أن تغيير ASN هو إشارة خطر بدلاً من ربط جهاز تشفيري. يمكن للمستخدمين المحمولين الشرعيين أو البعيدين تغيير الشبكات، بينما قد يجد المهاجم بنية تحتية في نفس سياق الشبكة.

في 8 فبراير 2024، نشرت Okta إشعار إغلاق التحقيق. قالت إن Stroz Friedberg أكمل تحقيقاً مستقلاً ولم يجد دليلاً على نشاط ضار يتجاوز استنتاجات Okta السابقة. قالت Okta إنها أخطبت الجهات التنظيمية ووكالات إنفاذ القانون، وأعطت تقارير تأثير مخصصة للعملاء المتأثرين، وراجعت أمان مركز المساعدة، وغيرت توفير المسؤولين والاحتفاظ بالبيانات. أشارت أيضاً إلى عدم وجود امتيازات دائمة للمسؤولين، ومصادقة متعددة العوامل معززة لإجراءات وحدة تحكم المشرف المحمية، وحظر أدوات إخفاء الهوية من خلال المناطق الديناميكية، وربط IP أوسع وقيود منطقة الشبكة للوصول إلى API.

تغطي هذه المعالجات عدة طبقات:

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

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

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

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

معيار تحكم لحالات دعم الهوية

يقترح الحادث معياراً عملياً يمكن لمزودي الهوية وعملائهم مشاركته.

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

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

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

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

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

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

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

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

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

المساءلة بعد انتهاء الجلسة

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

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

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

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