Okta جعلت ملفات الدعم حدود ثقة مع أطراف خارجية لعملاء الهوية

ملخص

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

خريطة الأدلة

أصبح الدعم جزءًا من محيط الهوية

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

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

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

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

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

لم تكن ملفات HAR مجرد لقطات شاشة بتفاصيل أفضل

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

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

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

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

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

لم تنقل الأدوات من طرف ثالث المساءلة بعيدًا عن Okta

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

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

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

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

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

أصبح العملاء أجهزة استشعار موزعة

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

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

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

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

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

غيرت بيانات الاتصال اقتصاديات الهجوم

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

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

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

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

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

ربط الجلسة وتعقيم القطع الأثرية مكملان

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

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

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

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

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

كان على الإفصاح عبور الحدود التنظيمية

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

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

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

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

المسؤولية تتبع سلطة القطعة الأثرية

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

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

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

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

حوّل الاحتفاظ تحميل الدعم إلى خطر اعتماد مستمر

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

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

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

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

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

كان تكافؤ API سؤالًا أمنيًا حقيقيًا

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

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

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

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

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

احتاج تسليم أدلة العميل إلى مسار أمني أسرع

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

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

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

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

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

عقد قطعة أثرية دعم أفضل

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

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

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

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

كان الحادث محدودًا، لكن درس التحكم واسع

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

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

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

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

اختبار المساءلة

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

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

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