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

ملخص

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

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

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

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

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

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

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

في 20 أكتوبر،أول إعلان عام من Oktaذكر أن جهة ضارة استخدمت بيانات اعتماد مسروقة للوصول إلى نظام إدارة حالات الدعم واطلعت على ملفات تم تحميلها من قبل بعض العملاء. وحذرت من أن ملفات 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 و DoD 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 حول إدارة الجلسةلماذا هذا خطير جدًا: بعد المصادقة، يكون معرف الجلسة مكافئًا مؤقتًا لأقوى طريقة مستخدمة لمصادقة المستخدم. يمكن أن يجعل مفتاح 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 معرف إنتاج وتحليل طبي شرعي عميق. المسؤولية تتبع السيطرة في كل خطوة، وليس تسمية واحدة مرتبطة بالاختراق الأولي.

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

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

يشير خط زمني 3 نوفمبر من Okta إلى أن الوصول غير المصرح به للجهة الضارة استمر من 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 يدويًا. يمكن لبوابة دعم رفض أنماط معرفات معروفة، أو إظهار معاينة على مستوى الحقل، أو وضع التحميلات غير المنقاة في الحجر الصحي، أو قبول أثر غير كامل عن قصد. هذه الضوابط غير كاملة لأن الرموز قد تظهر في رؤوس أو URLs أو أجسام غير عادية، وقد يزيل التنظيف الحقيقة الضرورية لتصحيح الأخطاء. لكن أداة آمنة افتراضيًا تغير الاقتصاديات: الخيار الاستثنائي يجب أن يكون الاحتفاظ بالسلطة، وليس إزالتها.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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