ملخص
- أصبح اختراق مفتاح AWS لـ OneLogin في 2017 اختبارًا للمساءلة في مزود الهوية لأن البيانات الرسمية لـ OneLogin في ذلك الوقت أفادت باكتشاف وصول غير مصرح به في منطقة البيانات الأمريكية، ووصفت لاحقًا مهاجمًا استخدم مفاتيح AWS للوصول إلى واجهة برمجة تطبيقات AWS، ونصحت العملاء باتخاذ إجراءات تصحيحية واسعة عبر المفاتيح والشهادات والرموز والأسرار وكلمات المرور.
- من كان لديه السيطرة العملية على تخزين مفاتيح AWS، وتشفير بيانات العملاء، وعزل مزود الهوية، وإبطال الرموز، وتوجيه العملاء بشأن التصحيح، وتوقيت الإفصاح، وإثبات أن اختراق SSO لم يترك تعرضًا دائمًا للحسابات؟
- قضية المساءلة هي أن مزود الهوية يركز مخاطر وصول العملاء، لذا يصبح اختراق المفاتيح السحابية اختبارًا للحوكمة للتقسيم والتشفير وأدلة إصلاح العملاء.
- احتاج العملاء من المؤسسات والموظفون والمسؤولون ومزودو SaaS اللاحقون وفرق الأمن والمدققون والجهات التنظيمية إلى دليل على أنه يمكن إعادة تعيين سلسلة ثقة الهوية والتحقق منها بدلاً من الإعلان عن استعادتها فقط.
- تتناول هذه المقالة التقارير المعاصرة التي نقلت عن إشعار الأمان لـ OneLogin وتوجيهات العملاء كدليل على سجل الحادث لعام 2017، ومواد OneLogin وOne Identity كدليل على سياق المنتج والإقامة الإقليمية، ومواد AWS والمعايير كمفردات تحكم، وتحليلات الطرف الثالث فقط كدعم لدروس الاستجابة للحوادث والمفاتيح السحابية.
لماذا تنتمي هذه القضية إلى ملف المخاطر والمساءلة
تنتمي OneLogin إلى ملف المخاطر والمساءلة لأن الخدمة لم تكن تطبيقًا عاديًا يحتوي على مجموعة بيانات ضيقة واحدة. لقد كانت مزود هوية. استخدمتها المؤسسات للتوسط في الوصول إلى العديد من التطبيقات الأخرى، وإصدار تأكيدات SAML، ودعم تدفقات OAuth وOpenID Connect، وأتمتة التزويد وإلغاء التزويد، ومركزية سياسة المصادقة. عندما يتعرض مزود هوية لحادث مفتاح بنية تحتية، يكون سؤال الضرر أكبر مما إذا كانت قاعدة بيانات واحدة قد تم لمسها. يصبح السؤال العملي هو ما إذا كان يمكن إعادة تعيين سلسلة الثقة التي يستخدمها العملاء للوصول إلى خدمات سحابية أخرى قبل أن يتمكن المهاجم من تحويل التعرض من جانب المزود إلى وصول دائم لاحق.
يبدأ السجل العام بإفصاح OneLogin في 31 مايو 2017 كما ورد في Krebs on Security على source: krebsonsecurity.com وSecurityWeek على source: securityweek.com. نقلت تلك الحسابات عن OneLogin قولها إنها اكتشفت وصولًا غير مصرح به إلى بيانات OneLogin في منطقة البيانات الأمريكية، وأوقفت الوصول، وأبلغت السلطات، وعملت مع شركة أمن مستقلة. قال تحديث لاحق من OneLogin نقله نفس السجل العام إن المهاجم حصل على مفاتيح AWS، واستخدمها للوصول إلى واجهة برمجة تطبيقات AWS من مزود وسيط في الولايات المتحدة، وأنشأ مثيلات للاستطلاع، ووصل إلى جداول قاعدة بيانات تحتوي على معلومات حول المستخدمين والتطبيقات وأنواع المفاتيح.
كما ذكر السجل أن OneLogin لم تستبعد احتمال أن المهاجم حصل على القدرة على فك تشفير البيانات.
هذا المزيج جعل القضية اختبارًا للمساءلة. مفاتيح AWS ليست مجرد كلمات مرور. في بيئة البنية التحتية كخدمة، يمكنها إنشاء مثيلات وقراءة البيانات الوصفية والتنقل عبر الخدمات والوصول إلى قواعد البيانات اعتمادًا على الأذونات. يجعل نموذج المسؤولية المشتركة لـ AWS على source: aws.amazon.com الخط واضحًا: AWS تؤمن البنية التحتية السحابية الأساسية، بينما يظل العميل الذي يستخدم AWS مسؤولاً عن الهوية والوصول وتكوين البيانات وضوابط التطبيق. في هذه الحالة، كانت OneLogin هي عميل AWS، وكان عملاء OneLogin من المؤسسات أطرافًا معتمدة. لذلك عبرت سلسلة المساءلة ثلاثة مستويات: مزود السحابة، مزود الهوية، ومستأجر العميل.
السؤال عملي: من كان لديه السيطرة العملية على تخزين مفاتيح AWS، وتشفير بيانات العملاء، وعزل مزود الهوية، وإبطال الرموز، وتوجيه العملاء بشأن التصحيح، وتوقيت الإفصاح، وإثبات أن اختراق SSO لم يترك تعرضًا دائمًا للحسابات؟ لا يمكن للإجابة أن تتوقف عند "تدوير المفاتيح". التدوير ضروري، لكنه جزء واحد فقط من إصلاح الهوية. كان العملاء بحاجة إلى معرفة أي كائنات ثقة تأثرت، وأيها قد تكون تأثرت، وأيها يجب استبداله فورًا، وأيها يمكن مراقبته، وأي دليل يظهر الإغلاق.
يؤكد الوضع الحالي لمنتج OneLogin على source: onelogin.com على إدارة الهوية المركزية للقوى العاملة والعملاء والشركاء، وآلاف تكاملات التطبيقات، والمصادقة التكيفية، وإدارة دورة الحياة الآلية. هذا الوضع يفسر مخاطر حدث 2017. المزود الذي يركز الوصول يقلل التجزئة عندما يعمل. عندما يتم اختراق مستوى التحكم الخاص به، يمكنه أيضًا تركيز عدم اليقين. يجب أن يظهر ملف الإصلاح المسؤول أن المركزية لا تصبح نصف قطر انفجار غير محدود.
حوادث مزود الهوية ليست اختراقات بيانات عادية
تحلل العديد من تحليلات الاختراقات عدد السجلات. تتطلب حوادث مزود الهوية قياسًا مختلفًا. يخزن مزود الهوية أو يتوسط هويات المستخدمين، وتعيينات التطبيقات، وإعدادات الاتحاد، وشهادات التوقيع، وبيانات اعتماد API، وتكاملات MFA، وموصلات التطبيقات، وضوابط الجلسة، والسياسة الإدارية. بعض هذه الكائنات هي بيانات. البعض هو سلطة. البعض هو خرائط لمكان قبول السلطة. إذا رأى المهاجم الخريطة وقد يرى الكائنات التي تثبت السلطة، يجب على العملاء اللاحقين افتراض أن الحادث يمكن أن يتجاوز حدود حساب المزود الخاص.
تظهر وثائق مطوري OneLogin السبب. تقول نظرة عامة على API على source: developers.onelogin.com إن API مؤمن بواسطة OAuth 2.0 ويستخدم النطاق الفرعي لـ OneLogin الخاص بالعميل كنطاق API. تشرح صفحة بيانات اعتماد API على source: developers.onelogin.com أن استدعاءات API تتطلب رمز حامل OAuth يتم الحصول عليه بزوج من بيانات الاعتماد. تصف صفحة إنشاء الرموز على source: developers.onelogin.com إنشاء رموز الوصول والتحديث لـ APIs الموارد. هذه المستندات هي وثائق منتج حالية، وليست أدلة جنائية لحادث 2017. توضح الحقيقة العامة لمزود الهوية: الرموز والعملاء والأسرار والمجالات والأدوار هي سلطة تشغيلية، وليست بيانات وصفية سلبية.
نفس الشيء ينطبق على الاتحاد. توفر نظرة عامة SAML من OneLogin على source: developers.onelogin.com تصف OneLogin كأداة لتمكين SSO مع SAML. توفر نظرة عامة OpenID Connect على source: developers.onelogin.com تصف OpenID Connect كطبقة هوية فوق OAuth 2.0. تصف صفحة API تسجيل الخروج على source: developers.onelogin.com إنهاء جلسة OneLogin وإبطال الرموز الصادرة تحت جلسة SSO تلك. مرة أخرى، هذه مستندات منتج وليست حقائق حادث، لكنها تشرح لماذا يمكن أن يكون عبء تصحيح العملاء بعد حدث مزود الهوية كبيرًا. يتم قبول ثقة الاتحاد من قبل موفري الخدمات لأن الشهادات والرموز ونقاط النهاية والبيانات الوصفية تقول إن مزود الهوية موثوق.
عكس تحليل استجابة العميل المعاصر لـ Ryan McGeehan على source: magoo.medium.com هذا العبء العملي. المقال وجه القراء صراحة إلى مقال دعم OneLogin كمصدر للحقيقة ثم ناقش إجراءات العملاء مثل تدوير شهادات SAML، وأسرار تكامل MFA، ومحتويات Secure Notes، وكلمات مرور غير SAML، وبيانات اعتماد API، وكائنات الثقة ذات الصلة. هذا المقال ليس تقرير ما بعد الحادث من OneLogin، لكنه قيم لأنه يظهر ما فهمه الممارسون أن نصف قطر الانفجار يتطلب: إعادة تعيين هوية منسقة، وليس مجرد تغيير كلمة مرور ضيق.
لذلك فإن المعيار المسؤول لهذا النوع من الحوادث أعلى من "تم الوصول إلى بيانات العميل". يجب أن يحدد السجل العام المفيد أي مواد الهوية تم تأكيد الوصول إليها، وأيها قد تكون مكشوفة لأن حدود التشفير لا يمكن إثباتها، وأيها يجب تدويرها كاحتياط، وكيف يمكن للعملاء التحقق من الاكتمال، وما الذي غيرته OneLogin بحيث يكون تعرض مماثل لمفاتيح البنية التحتية أقل احتمالاً للوصول إلى كائنات ثقة العملاء.
جعلت مفاتيح AWS مستوى التحكم السحابي جزءًا من الحادث
الحادث هو حالة اعتماد على الخدمات السحابية لأن المحفز الموصوف في السجل العام كان الوصول إلى مفاتيح AWS. يمكن تحديد نطاق مفاتيح AWS بشكل ضيق أو واسع. يمكن أن تكون طويلة العمر أو تُستبدل ببيانات اعتماد مؤقتة. يمكن مراقبتها وتقييدها وتدويرها ومنعها بواسطة السياسة. يمكن أن تصبح خطيرة أيضًا عندما تكون مفرطة في الصلاحيات، أو مخزنة حيث يمكن للاختراق التطبيقي أو التشغيلي الوصول إليها، أو إعادة استخدامها عبر خدمات يجب أن يكون لها حدود فشل منفصلة.
توفر أفضل ممارسات IAM من AWS على source: docs.aws.amazon.com ووثائق بيانات الاعتماد المؤقتة على source: docs.aws.amazon.com مفردات التحكم الحديثة: الامتياز الأقل، بيانات الاعتماد المؤقتة، الأدوار، MFA للوصول المميز، مراجعة الوصول، والتعامل الدقيق مع مفاتيح الوصول. لا تخبر هذه المستندات الجمهور بالضبط كيف قامت OneLogin بتكوين ممتلكاتها على AWS في 2017. لكنها تحدد فئات التحكم التي يجب أن يسأل عنها ملف المساءلة: هل كانت المفاتيح طويلة العمر؟ هل كانت مرتبطة بمستخدمين أو أدوار؟ هل يمكن لمفتاح مخترق إنشاء مثيلات؟ هل يمكنه الوصول إلى قواعد بيانات الإنتاج؟ هل تم فصل الأذونات حسب منطقة البيانات والوظيفة والبيئة؟
هل كانت تنبيهات الشذوذ مرتبطة بالاحتواء الآلي؟
استخدمت مناقشة Nordcloud المعاصرة لأمن السحابة على source: nordcloud.com قضية OneLogin للدفاع عن الوصول القائم على الأدوار، وتبديل الأدوار المفروض بـ MFA، وتجنب مفاتيح API الثابتة حيثما أمكن. اعتمد المقال على نفس تحديث OneLogin المشار إليه في مكان آخر، لذلك فهو ليس سلطة جنائية منفصلة. قيمته في تأطير درس التحكم السحابي: يجب على المزود تصميم وصول API إلى AWS بحيث لا يمكن لبيانات اعتماد مكشوفة واحدة إنشاء بنية تحتية بحرية، أو استكشاف البيئة، أو الوصول إلى مخازن البيانات دون حدود إضافية.
تكون قضية مستوى التحكم السحابي مهمة لأن مزودي الهوية هم أنفسهم مستأجرون سحابيون. قد يشتري عميل مؤسسة OneLogin لتقليل عدد أنظمة المصادقة التي يجب أن يديرها، لكنه لا يستطيع فحص سياسات IAM في AWS الخاصة بـ OneLogin، أو تصميم تخزين المفاتيح، أو تنبيهات الحوادث، أو تجزئة قاعدة البيانات، أو حراسة مفاتيح التشفير. لذلك يجب على المزود تحويل الضوابط الخفية إلى دليل يمكن للعملاء الوثوق به. تساعد صفحات الشهادات والامتثال، لكنها لا تحل محل الأدلة الخاصة بالحادث عند حدوث تعرض للمفاتيح.
تظهر صفحة امتثال OneLogin على source: onelogin.com وصفحة GDPR على source: onelogin.com نوع بيانات الحوكمة التي يراجعها العملاء عادة: الخصوصية، والشهادات، ومعالجة البيانات، ولغة الإخطار بالاختراق، وتدفقات البيانات، ودعم الامتثال. هذه الصفحات ليست تقريرًا عن السبب الجذري بعد الحادث. توضح وعد الشراء. اختبر اختراق 2017 ما إذا كان الوعد يمكن أن يتحمل اختراقًا فعليًا لمفاتيح البنية التحتية وما إذا كان لدى العملاء أدلة كافية لاتخاذ إجراء دقيق.
لذلك تتعلق المساءلة بحراسة المفاتيح وتصميم نصف قطر الانفجار. إذا كان يمكن للمفتاح إنشاء مثيلات استطلاع، يجب على المزود إظهار كيف تم تحديد نطاق ذلك المفتاح وكيف تم اكتشافه. إذا كان يمكن للمفتاح الوصول إلى قواعد البيانات، يجب على المزود إظهار ما إذا كانت مفاتيح تشفير قاعدة البيانات قابلة للفصل عن بيانات اعتماد التطبيق أو البنية التحتية. إذا تم إبطال المفتاح بعد الكشف، يجب على المزود إظهار ما إذا كانت أي جلسات مشتقة، أو مثيلات منشأة، أو لقطات، أو بيانات اعتماد مؤقتة، أو نسخ بيانات قد بقيت. لا يتم إغلاق حادث مفتاح سحابي حتى يتم تتبع أو إبطال كل مسار سلطة أنشأه المفتاح.
كان تصحيح العميل هو إصلاح الهوية الحقيقي
كان عمل إصلاح العميل محوريًا في حادث OneLogin. ذكر Krebs أن رسالة العميل وجهت المؤسسات إلى إنشاء مفاتيح API جديدة ورموز OAuth، وإنشاء شهادات أمان وبيانات اعتماد جديدة، وإعادة تدوير الأسرار المخزنة في Secure Notes، وجعل المستخدمين النهائيين تحديث كلمات المرور. تعاملت النظرة الاستعادية للممارس على Medium مع شهادات SAML ورموز تكامل MFA وكلمات مرور غير SAML وSecure Notes وبيانات اعتماد API ككائنات استجابة عملية. وصف حساب لاحق من CSO على source: csoonline.com أيضًا الحدث كمشكلة ثقة العملاء تتطلب استجابة سريعة وشفافية.
قائمة التصحيح هذه مهمة لأنها تظهر الفرق بين احتواء المزود وإصلاح العميل. احتواء المزود يمنع الوصول غير المصرح به، ويلغي مفاتيح AWS المخترقة، ويغلق البنية التحتية المتأثرة، ويحقق، ويصدر التوجيه. إصلاح العميل يغير مواد الثقة التي تستخدمها التطبيقات اللاحقة لقبول تأكيدات OneLogin واستدعاءات API وبيانات الاعتماد المخزنة. إذا لم يكمل العملاء هذه الخطوة الثانية، فقد يكون المزود قد استعاد تقنيًا بينما تظل بيئات العملاء مكشوفة.
تدوير شهادة SAML هو مثال مفيد بشكل خاص. يشرح دليل شهادات توقيع SAML من OneLogin على source: onelogin.com ودليل تكوين SAML على source: onelogin.com أن الشهادات والبصمات ونقاط النهاية وإعدادات SSO هي جزء من إدارة تكامل SAML. إذا كان من الممكن أن تكون شهادة التوقيع قد اخترقت، فقد يحتاج كل مزود خدمة يثق بتلك الشهادة إلى شهادة وبيانات وصفية محدثة. هذا ليس إصلاحًا بنقرة واحدة لمؤسسة معقدة. يمكن أن يشمل مئات أو آلاف التطبيقات وأصحاب الأعمال وبوابات البائعين ونوافذ الاختبار ومخاطر التوقف والتحقق من أي تطبيق يثق الآن في مادة الهوية الجديدة.
تدوير رمز OAuth وAPI له شكل تشغيلي مختلف. قد تكون بيانات اعتماد API مضمنة في الأتمتة والنصوص البرمجية ومهام التزويد وموصلات التقارير والبرمجيات الوسيطة للتكامل. إذا كان التدوير غير كامل، يمكن أن يستمر رمز قديم أو سر في العمل في سير عمل منسي. إذا تم التدوير على عجل دون جرد، يمكن أن تتعطل العمليات التجارية. لهذا السبب تعتبر أتمتة الأمان موضوعًا في هذه القضية. كان العملاء بحاجة إلى جرد قابل للقراءة آليًا للتطبيقات والشهادات والرموز والأسرار المخزنة والموصلات المميزة. كانوا بحاجة إلى سجلات تظهر ما إذا كانت المواد القديمة لا تزال مستخدمة. كانوا بحاجة إلى طريقة لإثبات أن إعادة تعيين الهوية قد وصلت بالفعل إلى كل نظام يقبلها.
يجب أن يدعم المزود المسؤول هذا العمل. يجب أن يكون توجيه التصحيح محددًا ومرتبًا بالأولويات ومختومًا بالوقت وقابلًا للاختبار. يجب أن يميز بين "يجب التدوير فورًا" و"التدوير كاحتياط" و"مراقبة الاستخدام المشبوه". يجب أن يتضمن استعلامات كشف حيثما أمكن، وتقارير إدارية، وجرد تطبيقات قابل للتصدير، وحالة انتهاء صلاحية الشهادة واستبدالها، وسجلات إصدار الرمز وإبطاله، ودعم العملاء لتصحيح التكاملات عالية المخاطر. بدون هذه القطع الأثرية، يصبح التصحيح تدافعًا يدويًا، والتدافع اليدوي يترك فجوات دائمة.
لذلك ينتمي الحادث إلى ملف المساءلة لأن عمل الإصلاح كان موزعًا. سيطرت OneLogin على الملكية السحابية المخترقة وتوجيه المنتج. سيطر العملاء على تكاملات تطبيقاتهم ومراسي الثقة اللاحقة. سيطر مزودو SaaS اللاحقون على مدى سرعة استبدال شهادة SAML أو عميل OAuth. يجب أن تتبع المساءلة هذه السلسلة بدلاً من التظاهر بأن طرفًا واحدًا يمكنه إكمال إعادة التعيين بمفرده.
تتطلب ادعاءات التشفير دليلاً على فصل المفاتيح
قال التحديث المقتبس من OneLogin إن الشركة قامت بتشفير بعض البيانات الحساسة أثناء التخزين لكنها لم تستبعد احتمال أن المهاجم حصل على القدرة على فك تشفير البيانات. هذه هي الجملة الأكثر أهمية في السجل العام. لا تثبت أن جميع البيانات المشفرة تم فك تشفيرها. تظهر أن التشفير أثناء التخزين لم يكن، بحد ذاته، ضمانًا عامًا كافيًا بعد تعرض مفتاح AWS. كان العملاء بحاجة إلى معرفة ما إذا كانت مفاتيح التشفير، ومفاتيح تشفير المفاتيح، وأسرار التطبيق، وجداول قاعدة البيانات، ومسارات الوصول منفصلة بقوة كافية بحيث لا يصبح الوصول إلى قاعدة البيانات تعرضًا للنص العادي.
هذه فجوة مساءلة شائعة. غالبًا ما يوصف التشفير كتحكم ثنائي، لكن الاستجابة للحوادث تحوله إلى سلسلة حراسة. البيانات المشفرة أثناء التخزين محمية فقط إذا لم يتمكن المهاجم أيضًا من الحصول على المادة أو سلطة الخدمة اللازمة لفك تشفيرها. إذا كانت نفس البيئة التشغيلية تحتوي على كل من النص المشفر والمفاتيح أو أذونات الوصول إلى المفاتيح، يمكن للاختراق البنيوي عبور الحدود. إذا تم الاحتفاظ بالمفاتيح في خدمة منفصلة بأذونات صارمة ومسارات تدقيق وتشفير مغلف، يمكن أن يكون نصف قطر الانفجار أصغر. لم يقدم السجل العام تفاصيل كافية لإثبات أي تصميم تم تطبيقه في 2017.
يظهر موضوع سيادة البيانات والمحلية هنا أيضًا. تقول صفحة الحالة الحالية لـ OneLogin على source: onelogin.com إنها توفر خيار إقامة بيانات أوروبية مستضافة في مراكز بيانات موزعة جغرافيًا في المنطقة الاقتصادية الأوروبية. سجل الحادث، على النقيض، يتعلق بمنطقة البيانات الأمريكية. سؤال المساءلة ليس ما إذا كان كل عميل عالمي موجودًا في نفس قاعدة البيانات. إنه ما إذا كان بإمكان العملاء تحديد المنطقة التي تخدمهم، وما هي البيانات ومواد الثقة الموجودة في تلك المنطقة، وما هي المسارات عبر المناطق أو الدعم الموجودة، وكيف تتوافق إشعارات الحادث مع التعرض الإقليمي.
يتم تسويق إقامة البيانات أحيانًا كموقع. في الحادث، يجب أن تصبح دليلاً. يحتاج العملاء إلى معرفة ما إذا كانت بيانات المصادقة، والبيانات الوصفية للتطبيق، والأسرار، والسجلات، والنسخ الاحتياطية، وصادرات الدعم، والتحليلات، والوصول الإداري مقيدة بالمنطقة أم منسوخة في مكان آخر. يحتاجون إلى معرفة ما إذا كان حادث منطقة البيانات الأمريكية يؤثر فقط على المستأجرين المستضافين في الولايات المتحدة أم أيضًا على أنظمة الإدارة العالمية. يحتاجون إلى معرفة ما إذا كانت المفاتيح أو السجلات في منطقة واحدة يمكنها فتح بيانات في منطقة أخرى. أعطى السجل العام لـ OneLogin لعام 2017 مرساة إقليمية لكنه لم يقدم خريطة تدفق بيانات كاملة.
اللائحة العامة لحماية البيانات (GDPR)، المتاحة على source: eur-lex.europa.eu، تجعل مساءلة حماية البيانات أوسع من الموقع. تناقش صفحة GDPR الخاصة بـ OneLogin تدفقات البيانات ومسؤوليات الإخطار بالاختراق والخصوصية حسب التصميم. بالنسبة لمزود هوية، يجب أن تتضمن الخصوصية حسب التصميم تقليل الأسرار المخزنة، وفصل سلطة فك التشفير، ووصول الدعم الواعي بالمنطقة، والتسجيل الذي يبقى بعد الاستجابة للحوادث، ودليل مواجه للعميل على أن البيانات لم يتم نسخها خارج الحدود الموعودة. كان السؤال المسؤول بعد الاختراق هو ما إذا كانت هذه المبادئ أصبحت ضوابط قابلة للقياس.
الدرس ليس أن التشفير فشل لأن OneLogin لم تستبعد فك التشفير. الدرس هو أن ادعاءات التشفير يجب أن تكون مدعومة بأدلة فصل المفاتيح. إذا كان بإمكان المزود إثبات أن بيانات اعتماد البنية التحتية المسروقة لا يمكنها الوصول إلى مواد المفاتيح، يمكن للعملاء تضييق نطاق التصحيح. إذا لم يستطع المزود إثبات ذلك، يجب على العملاء التدوير على نطاق واسع، وافتراض أن بيانات الاعتماد المخزنة قد تكون مكشوفة، ومعاملة الحادث كإعادة تعيين لسلسلة الثقة.
توقيت الإفصاح وحدود الأدلة مهمة
تظهر الأدلة العامة أن OneLogin اكتشفت وصولًا غير مصرح به في 31 مايو 2017، وأوقفته، وأبلغت السلطات، وعملت مع شركة أمن مستقلة. قالت التفاصيل اللاحقة إن الهجوم بدأ حوالي الساعة 2 صباحًا بتوقيت المحيط الهادئ وتم تنبيه الموظفين حوالي الساعة 9 صباحًا، مع إغلاق المثيلات المتأثرة ومفاتيح AWS في غضون دقائق من الكشف. جاءت هذه الحقائق من خلال بيانات OneLogin التي نقلتها التقارير المعاصرة، بما في ذلك Krebs وSecurityWeek والنظرة الاستعادية للممارس. نظرًا لأن صفحة الحادث الأصلية لـ OneLogin لم تعد مصدرًا ثابتًا حاليًا وتعيد التوجيه داخل ممتلكات One Identity على الويب، يجب التعامل مع السجل العام بحذر.
هذا القيد الأدلى هو بحد ذاته جزء من المساءلة. يجب أن تظل إشعارات الحوادث متاحة أو مؤرشفة في مكان ثابت لأن العملاء والمدققين والجهات التنظيمية والباحثين وفرق الشراء يحتاجون إلى تقييم سلوك المزود السابق. لا يمكن لصفحة امتثال حالية أن تحل محل إشعار حادث قديم. مقال طرف ثالث ينقل الإشعار مفيد، لكنه أضعف من أرشيف مزود دائم مع الإشعار الأصلي وتاريخ التحديث وتوجيهات العملاء والدروس المستفادة النهائية.
لذلك يفصل المقال بين الحقائق المؤكدة والاستنتاجات المدعومة والمجهولات. تشمل الحقائق العامة المؤكدة الوصول غير المصرح به المبلغ عنه إلى بيانات OneLogin في المنطقة الأمريكية، ومسار مفتاح AWS المقتبس، وإنشاء مثيلات الاستطلاع، والوصول إلى جداول قاعدة البيانات التي تحتوي على المستخدمين والتطبيقات وأنواع المفاتيح، وعدم القدرة على استبعاد قدرة فك التشفير، وتوصيات تصحيح العملاء. يشمل الاستنتاج المدعوم أن نطاق IAM في AWS، وفصل مفاتيح التشفير، ورسم خرائط منطقة البيانات، وتدوير شهادة SAML، وإبطال رمز OAuth، وجرد جانب العميل كانت كائنات تحكم مركزية.
تشمل المجهولات أذونات المفاتيح الدقيقة، ومحتويات قاعدة البيانات الكاملة التي تم الوصول إليها، وهندسة إدارة المفاتيح الكاملة، وجميع اتصالات العملاء، وجميع نتائج الطب الشرعي، وحالة الإكمال النهائية لكل تدوير عميل.
هذا الانضباط مهم لأن اختراقات مزود الهوية تدعو إلى التكهن. سيكون من السهل الادعاء بأن كل حساب SaaS لاحق قد اخترق. السجل العام لا يثبت ذلك. سيكون من السهل أيضًا التقليل من شأن الحادث لأن OneLogin أوقفت الوصول بعد الكشف. السجل العام لا يدعم ذلك أيضًا. القراءة المسؤولة الصحيحة هي أن اختراق مفتاح AWS من جانب المزود خلق نصف قطر انفجار هوية ذا مصداقية كافية بحيث طُلب من العملاء تدوير مواد ثقة واسعة.
لتوقيت الإفصاح غرض ثانٍ: يسمح للعملاء بالبحث في السجلات. إذا بدأ الحادث حوالي الساعة 2 صباحًا بتوقيت المحيط الهادئ وتم الكشف حوالي الساعة 9 صباحًا، يمكن للعملاء فحص سجلات تطبيقاتهم اللاحقة، وسجلات نشاط OneLogin، واستخدام API، وقبول تأكيد SAML، وأحداث مزود MFA، والتغييرات الإدارية خلال وبعد تلك النافذة. الأدلة المحددة بالوقت تكون قيمة فقط إذا أعطى المزود طوابع زمنية كافية وفئات قطع أثرية. الإفصاح الغامض يحرم العملاء من القدرة على البحث عن الضرر الخاص بهم.
لذلك يجب أن يتضمن سجل الإصلاح المسؤول جدولًا زمنيًا محفوظًا، وقائمة بفئات التحكم المتأثرة، ومصفوفة تصحيح العملاء، وقسم "ما زلنا لا نعرفه" واضح. لا يحتاج الجمهور إلى كل قطعة أثرية طب شرعي خاصة، لكن العملاء يحتاجون إلى تفاصيل كافية لأداء دورهم في إعادة التعيين.
يجب أن تسد أتمتة الأمان الفجوة بين التنبيه ونصف قطر الانفجار
يقترح الجدول الزمني المقتبس لـ OneLogin فجوة كشف لعدة ساعات بين بداية نشاط API على AWS وتنبيه الموظفين. لا يظهر السجل العام بنية المراقبة الكاملة، لذا فإن النقطة ليست الحكم على تنبيه واحد بمعزل. قضية المساءلة هي ما يجب أن تفعله أتمتة الأمان عندما تبدأ بيانات اعتماد مستوى التحكم السحابي سلوكًا غير معتاد في بيئة مزود هوية عالية الثقة.
يجب أن تسأل الاستجابة الحديثة للحوادث السحابية عما إذا كانت استدعاءات API غير معتادة على AWS تؤدي إلى احتواء فوري، وما إذا كان استخدام المفتاح مقيدًا بالمصدر والحساب والدور والخدمة وسير العمل المتوقع، وما إذا كان إنشاء المثيلات خارج أنظمة النشر محظورًا أو يتم تنبيهه بشدة، وما إذا كانت حالات شذوذ الوصول إلى قاعدة البيانات مرتبطة بتسجيل مخاطر الهوية، وما إذا كانت أسرار الإنتاج يمكن الوصول إليها بنفس بيانات الاعتماد التي تدير الحوسبة. توفر مواد AWS وCISA وNIST اللغة. تركز إرشادات التصميم الآمن من CISA على source: cisa.gov على تصميم المنتجات بحيث لا يُجبر العملاء على امتصاص المخاطر القابلة للوقاية.
يعطي إطار الأمن السيبراني من NIST على source: nist.gov هيكل التحديد والحماية والكشف والاستجابة والتعافي.
بالنسبة لمزود هوية، يجب أن تدعم الأتمتة أيضًا العملاء. تتحدث مواد المنتج الحالية لـ OneLogin عن المصادقة التكيفية، ونتائج المخاطر، وبث أحداث تسجيل الدخول إلى SIEM وأدوات الاتصال السحابي. تقول الصفحة الرئيسية الحالية على source: onelogin.com إن المنصة يمكنها اكتشاف السلوك المشبوه وفرض المصادقة التكيفية. تناقش مقالة مطوري التهديدات السحابية على source: developers.onelogin.com ميزات الكشف والاستجابة حول إساءة استخدام الحسابات الصالحة والمؤشرات المشبوهة والإشعارات الآلية. لا تثبت مواد المنتج اللاحقة هذه ما كان موجودًا في 2017، لكنها تحدد نوع الأتمتة التي يتوقعها العملاء من شركة هوية.
بعد اختراق المزود، يجب أن تساعد الأتمتة المواجهة للعميل في الإجابة على أربعة أسئلة بسرعة. أي التطبيقات تثق في مزود الهوية هذا؟ أي الشهادات وعملاء OAuth نشطة؟ أي المستخدمين لديهم بيانات اعتماد مخزنة أو Secure Notes قد تحتاج إلى تدوير؟ أي التطبيقات اللاحقة قبلت تأكيدات أو استدعاءات API خلال النافذة المشبوهة؟ بدون هذه الإجابات، يجب على فرق الاستجابة بناء جداول بيانات تحت الضغط. جداول البيانات لا تتوسع بشكل جيد عندما يكون المزود المتأثر مركزيًا للوصول.
تحتاج أتمتة الأمان أيضًا إلى دلالات انتهاء الصلاحية والإبطال. يجب أن يتوقف الرمز الملغي عن العمل. يجب أن تحل شهادة SAML المدورة محل مرساة الثقة القديمة. يجب أن تبطل إعادة تعيين كلمة المرور الجلسات القديمة حيثما أمكن. يجب أن يكون سر تكامل MFA قابلاً للاستبدال دون التخلي عن المستخدمين أو تعطيل الوصول الطارئ. يجب أن يظهر المنتج للعميل أي المواد القديمة لا تزال مقبولة. إذا لم يتمكن مزود الهوية من إظهار ذلك، فإنه لم يقم بتشغيل الإصلاح بالكامل.
الدرس المتعلق بالمساءلة هو أن سرعة الكشف وأدوات التصحيح مرتبطة. قد يكتشف المزود حادثًا ويصدر توجيهًا بسرعة، لكن إذا لم يتمكن العملاء من تنفيذ التوجيه بأمان وكامل، يستمر نصف قطر الانفجار. لذلك يجب قياس أتمتة الأمان ليس فقط بتوليد التنبيهات ولكن بمدى سرعة تمكن المزود والعملاء من إلغاء واستبدال والتحقق من ثقة الهوية.
تغير المحلية عبء الاتصال بالعميل
تم وصف حادث OneLogin بأنه أثر على منطقة البيانات الأمريكية، بينما تصف صفحة الثقة الحالية لـ OneLogin خيار إقامة بيانات أوروبية. الفرق مهم لأن مزودي الهوية يخدمون عملاء عالميين بتوقعات تنظيمية وتعاقدية وتشغيلية مختلفة. يجب أن يخبر إشعار التعرض الإقليمي العملاء ما إذا كانوا في المنطقة، وما هي فئات البيانات المقيدة بالمنطقة، وما إذا كانت بيانات الدعم أو النسخ الاحتياطي تعبر المناطق، وما إذا كانت كائنات ثقة الهوية محلية أم عالمية.
المحلية ليست مجرد قضية خصوصية. إنها أيضًا قضية استجابة للحوادث. إذا علم العميل أن مستأجره يُخدم من منطقة محددة، يمكنه رسم خريطة لواجبات الإخطار التنظيمي، وعمليات البحث في الاحتفاظ بالسجلات، وأولويات التصحيح اللاحقة. إذا كان مستوى التحكم للمزود يستخدم خدمات عالمية مشتركة، قد تكون التصنيفات الإقليمية غير كافية. لم يقدم السجل العام حول حدث 2017 وصفًا معماريًا كاملاً. هذا مفهوم لأسباب أمنية، لكن العملاء ما زالوا بحاجة إلى نطاق قابل للتنفيذ.
تناقش صفحة GDPR على source: onelogin.com رسم خرائط البيانات واتفاقيات معالجة البيانات والإخطار بالاختراق وأدوات العميل للوصول وإمكانية النقل وإلغاء التزويد والتدقيق. تتقاطع هذه الموضوعات مباشرة مع حوادث مزود الهوية. إذا كان المستأجر يحتوي على مستخدمين من الاتحاد الأوروبي لكنه يُخدم من منطقة أمريكية، قد يحتاج العميل إلى تقييم أسئلة النقل عبر الحدود والإخطار. إذا كان المستأجر يُخدم من منطقة المنطقة الاقتصادية الأوروبية، ما زال العميل بحاجة إلى معرفة ما إذا كانت سجلات الدعم والتحليلات والمفاتيح والنسخ الاحتياطية تأثرت في مكان آخر. الإقامة دون رسم خرائط التبعية غير مكتملة.
بالنسبة للعملاء، عبء الاتصال بعد حادث هوية له طبقتان. أولاً، كان على OneLogin إخبار عملائها بما يكفي لحماية بيئاتهم الخاصة. ثانيًا، كان على أولئك العملاء أن يقرروا ما إذا كانوا سيخبرون موظفيهم وشركائهم ومدققيهم والجهات التنظيمية وأصحاب الخدمات اللاحقة وكيف. تعليمات "تدوير كل شيء" الواسعة تقلل من مخاطر نقص الاستجابة لكنها تزيد من اضطراب الأعمال. التعليمات الضيقة تقلل من الاضطراب لكنها قد تفوت التعرض غير المعروف. أفضل دليل يسمح للعملاء بالاختيار بشكل متناسب.
المحلية تؤثر أيضًا على مساءلة الشراء. تشتري المؤسسات مزودي الهوية بناءً جزئيًا على المنطقة وموقف الامتثال ووقت التشغيل والدعم واتساع التكامل. تصبح صفحة الحالة على source: onelogin.com وصفحة الامتثال جزءًا من سجل الشراء. عند وقوع حادث، يجب أن يكون المزود قادرًا على التوفيق بين وعود الشراء وخريطة التعرض الفعلية. أي منطقة تأثرت؟ أي العملاء كانوا فيها؟ أي القطع الأثرية كانت مخزنة هناك؟ أي الضوابط أبقت المناطق أو الأنظمة الأخرى خارج نصف قطر الانفجار؟ أي دليل يدعم هذا الاستنتاج؟
لذلك تظل قضية 2017 ذات صلة لأن الهوية السحابية أصبحت أكثر إقليمية وتنظيمًا الآن. يحتاج العملاء إلى مزودين يعاملون المحلية كسطح تحكم، وليس كمجال تسويق. يجب أن يأتي تصنيف المنطقة مع أدلة استجابة، وخرائط تدفق البيانات، وجرد كائنات الثقة التي يمكن أن تبقى بعد الحادث.
احتاج جانب العميل إلى ملف المساءلة الخاص به
سيطرت OneLogin على بيئة المزود، لكن العملاء سيطروا على العديد من العواقب اللاحقة. العميل الذي استخدم OneLogin لمئات تكاملات SaaS كان بحاجة إلى معرفة أي التطبيقات تعتمد على SAML، وأيها استخدم OIDC، وأيها خزن كلمات مرور، وأيها خزن بيانات اعتماد API، وأيها استخدم تكاملات مزود MFA، وأي المسؤولين لديهم صلاحيات، وأي المستخدمين لديهم أسرار مخزنة. إذا كان العميل يفتقر إلى هذا الجرد، كشف حادث المزود عن ضعف في حوكمة العميل بالإضافة إلى حادث بائع.
هذه هي الحقيقة غير المريحة للمركزية في الهوية. شراء مزود هوية لا يزيل واجب العميل في فهم تبعيات الهوية. إنه يغير شكل ذلك الواجب. يجب على العملاء الحفاظ على جرد تطبيقات، وجرد كائنات ثقة، وعملية تدوير شهادات، وإجراءات اتحاد طارئة، وتصميم وصول طارئ، وسياسة بيانات اعتماد غير SAML، وسياسة Secure Notes، وسير عمل إبطال الرموز، وعملية بحث في السجلات بعد الحادث. يمكن لـ OneLogin تقديم التوجيه والأدوات، لكن كل عميل كان عليه التنفيذ داخل بيئته الخاصة.
يمكن أن تكون تكاملات SAML وOIDC صعبة بشكل خاص في التدوير لأن أصحاب الأعمال قد لا يعرفون المالك التقني لكل تطبيق. قد يقبل مزود الخدمة الشهادات القديمة والجديدة أثناء الانتقال، أو قد يتطلب توقفًا مجدولًا. قد يكون بعض مسؤولي SaaS قد رحلوا. قد تكون بعض بيانات التطبيق قديمة. قد تكون بعض التكاملات قد أنشئت لمشروع ولم يتم توثيقها أبدًا. اختراق مزود الهوية يحول هذا الدين الإداري إلى مخاطر فورية.
تضمنت قائمة التصحيح التي ذكرها Krebs أيضًا الأسرار المخزنة في Secure Notes وكلمات مرور غير SAML. هذا يكشف سؤال سياسة. إذا كانت منصة الهوية تسمح للمستخدمين أو المسؤولين بتخزين الأسرار، يحتاج العملاء إلى قواعد حول ما يمكن تخزينه، ومن يمكنه تصديره، وكيف يتم تشفيره، وما إذا كان الاستخدام قابلًا للتقرير، ومدى سرعة تحديد جميع الأسرار المتأثرة. إذا لم يستطع العميل سرد من استخدم الميزة، يصبح الاستجابة تخمينًا. يمكن أن تكون ميزة المزود ملائمة في العمليات العادية وخطيرة في استجابة الاختراق إذا كانت تفتقر إلى جرد وضوابط دورة الحياة.
احتاج العملاء أيضًا إلى فحص التطبيقات اللاحقة بحثًا عن وصول غير معتاد. خطر اختراق شهادة SAML ليس مجرد مشكلة شهادة. إنها مشكلة وصول. هل قبل أي مزود خدمة تأكيدات غير معتادة؟ هل تغيرت أي أدوار إدارية؟ هل استمرت أي جلسات مستخدم؟ هل قام أي عميل API باستدعاءات غير متوقعة؟ هل رأى أي مزود MFA استخدام رمز يجب التحقيق فيه؟ تتطلب هذه الأسئلة سجلات محفوظة عبر عدة بائعين. تتطلب أيضًا ساعات ومعرفات ارتباط وخطوط أنابيب SIEM تم إعدادها قبل الحادث.
لذلك يجب أن يتضمن ملف المساءلة لعميل OneLogin كلاً من أدلة البائع وأدلة العميل. أدلة البائع: ما حدث، ما تأثر، ما يجب تدويره، ما تغير، ما لا يزال غير معروف. أدلة العميل: ما تم تدويره، ومتى، ومن، وأي التطبيقات تم التحقق منها، وأي السجلات تم البحث فيها، وأي الاستثناءات بقيت، وأي السياسات تغيرت لتقليل نصف قطر الانفجار في المستقبل.
يجب على الشراء تقييم الأدلة، وليس فقط قوائم الميزات
كان يجب أن يغير حادث OneLogin كيفية تقييم العملاء لمزودي الهوية. قوائم الميزات مهمة، لكن يجب على الشراء أيضًا أن يسأل عن ممارسات أدلة الحوادث. هل يحتفظ المزود بإشعارات الحوادث القديمة؟ هل ينشر دروس ما بعد الحادث حيثما أمكن؟ هل يوفر أدوات تصدير للعميل لجرد التطبيقات والشهادات وبيانات اعتماد API وتكاملات MFA والأسرار المخزنة والسجلات والإجراءات الإدارية؟ هل يوثق حدود منطقة البيانات؟ هل يدعم التدوير الطارئ للثقة على نطاق واسع؟ هل يوفر لغة إخطار بالاختراق تطابق الواجبات الفعلية للعميل؟
صفحات الامتثال والحالة الحالية لـ OneLogin هي مدخلات شراء مفيدة، وسياق استحواذ One Identity ربما غير الحوكمة وهندسة المنتج منذ 2017. لكن مراجعة المساءلة الدائمة تنظر إلى السلوك تحت الضغط. ما مدى سرعة إفصاح المزود؟ ما مدى تحديد التوجيه؟ هل فهم العملاء نصف قطر الانفجار المحتمل؟ هل ذكر المزود ما لا يمكنه استبعاده؟ هل حول المزود الحادث إلى تغيير معماري؟ هل أظهرت المواد اللاحقة أتمتة أقوى، وخيارات منطقة، وضوابط مخاطر هوية؟
يمكن أن يساعد تحليل الطرف الثالث، لكن لا ينبغي أن يصبح السجل الأساسي. حساب CSO الاستعادي، وتقارير Krebs وSecurityWeek، ومناقشة Nordcloud لمفاتيح AWS، ومقال الممارس على Medium تقدم لمحات مفيدة عما عرفه الجمهور ومجتمع الاستجابة. لا يمكنها استبدال تقرير ما بعد الحادث الذي يحتفظ به المزود بالكامل. المزود الذي يحمل سلطة الهوية يجب أن يعامل أرشيف حوادثه كجزء من ثقة العملاء.
يجب أن يختبر الشراء أيضًا الخروج والتراجع. إذا كان مزود الهوية متدهورًا أو يجب عدم الثقة به مؤقتًا، هل يمكن الوصول إلى التطبيقات الحرجة من خلال حسابات طارئة؟ هل تلك الحسابات مراقبة ومحمية؟ هل يمكن للعملاء تعطيل SSO بأمان للوصول الطارئ دون فتح ثغرات جديدة؟ هل يمكنهم إعادة بناء الثقة بشهادات ورموز جديدة في تسلسل متحكم به؟ هل يمكنهم إثبات أن مواد الثقة القديمة لم تعد مقبولة؟ هذه ليست أسئلة مجردة. إنها المهام العملية التي واجهها العملاء في 2017.
الحافز الاقتصادي واضح. مزودو الهوية يقللون الاحتكاك التشغيلي عندما يعمل كل شيء. تظهر التكلفة عندما يجب استبدال مواد الثقة عبر المؤسسة. لذلك يجب على العملاء أن يسعروا ليس فقط تكلفة الاشتراك وسهولة تسجيل الدخول، ولكن أيضًا تكلفة التدوير الطارئ ومراجعة الأدلة والتوقف إذا أصبح مزود الهوية نفسه موضع شك. المزود الذي يسهل التدوير الطارئ يقلل من مخاطر العميل. المزود الذي يترك العملاء للجرد اليدوي ينقل تكلفة خفية إليهم.
معيار الشراء المسؤول ليس "لا يوجد حادث أبدًا". إنه "أثبت أن الحادث يمكن حده والإفصاح عنه ومعالجته والتعلم منه". يظل اختراق OneLogin لعام 2017 مفيدًا لأنه أظهر مقدار ثقة مزود الهوية التي تعتمد على أدلة لا يمكن للعملاء توليدها بمفردهم.
يجب أن تفصل الأدلة بين الحقائق المؤكدة والاستنتاجات المدعومة والمجهولات
الحقائق العامة المؤكدة محدودة لكنها مهمة. أفصحت OneLogin عن وصول غير مصرح به في منطقة البيانات الأمريكية. نقلت التقارير العامة تحديث OneLogin اللاحق الذي يصف مهاجمًا حصل على مفاتيح AWS، واستخدم API AWS، وأنشأ مثيلات للاستطلاع، ووصل إلى جداول قاعدة بيانات تحتوي على المستخدمين والتطبيقات وأنواع المفاتيح. قال نفس السجل العام إن OneLogin لم تستبعد أن المهاجم حصل على القدرة على فك تشفير البيانات. تضمن توجيه العميل المبلغ عنه تدويرًا واسعًا لمفاتيح API ورموز OAuth والشهادات وبيانات الاعتماد والأسرار وكلمات مرور المستخدمين النهائيين.
الاستنتاجات المدعومة مهمة أيضًا. من المعقول استنتاج أن نطاق IAM في AWS، وتخزين المفاتيح، وتجزئة قاعدة البيانات، وفصل مفاتيح التشفير، وحراسة شهادات SAML، وإبطال رمز OAuth، وأسرار تكامل MFA، وحوكمة Secure Notes، وجرد العملاء كانت كائنات مساءلة مركزية. من المعقول استنتاج أن نطاق منطقة البيانات كان مهمًا لأن الحادث وُصف بأنه أثر على منطقة البيانات الأمريكية وتقوم OneLogin بتسويق خيارات الإقامة الإقليمية. من المعقول استنتاج أن احتواء جانب المزود وحده لم يكن كافيًا لأن العملاء اضطروا إلى تدوير مواد الثقة اللاحقة.
المجهولات لا تزال قائمة ويجب تسميتها. لا يكشف السجل العام عن سياسات IAM الدقيقة في AWS، أو موقع ودورة حياة المفاتيح المكشوفة، أو مخطط قاعدة البيانات الكامل الذي تم الوصول إليه، أو هندسة مفاتيح التشفير المحددة، أو القائمة الكاملة لفئات بيانات العملاء، أو تقرير الطب الشرعي المستقل الكامل، أو جميع تعليمات تصحيح العملاء، أو جميع التغييرات المعمارية بعد الحادث، أو حالة الاكتمال لكل تدوير عميل. كما لا يسمح لمراقب خارجي بإثبات ما إذا كان أي حساب SaaS لاحق قد أسء استخدامه بالفعل نتيجة للحادث.
هذه المجهولات لا تجعل المساءلة مستحيلة. إنها تحدد حدود الأدلة. ملف المخاطر الجاد لا يحتاج إلى سجلات خاصة لتحديد مشكلة الحوكمة. المشكلة هي أن مزود هوية مركزي عانى من حادث مفتاح سحابي واضطر العملاء إلى معاملة كائنات الثقة التي يديرها المزود على أنها قد تكون مخترقة. هذا كافٍ لجعل القضية حدث اعتماد على هوية عالي التأثير.
حدود الأدلة تحمي أيضًا من الادعاءات غير العادلة. سيكون من الخطأ الادعاء، دون دليل، أن OneLogin حجب الحقائق عن عمد، أو أن جميع بيانات اعتماد العميل تم فك تشفيرها، أو أن جميع التطبيقات اللاحقة تم الوصول إليها. سيكون من الخطأ أيضًا الادعاء بأن الحادث كان منخفض التأثير لمجرد أن الوصول غير المصرح به تم إيقافه. يظهر عبء تصحيح العميل أن المخاطر كانت واسعة حتى لو بقي سوء الاستخدام النهائي المثبت غير واضح.
السؤال المسؤول لمزودي المستقبل هو ما إذا كان بإمكانهم تضييق تلك المجهولات. التسجيل الأفضل يضيق الجداول الزمنية. فصل المفاتيح الأفضل يضيق مخاطر فك التشفير. جرد التطبيقات الأفضل يضيق تدوير الشهادات. خرائط المناطق الأفضل تضيق التعرض للمحلية. أرشيفات الحوادث الأفضل تضيق عدم اليقين العام. تظهر قضية OneLogin ما يحدث عندما تلتقي ثقة الهوية والبنية التحتية السحابية تحت الضغط: تصبح قدرة المزود على إثبات الحدود بنفس أهمية قدرة المزود على استعادة الأنظمة.
معيار الإصلاح هو إعادة تعيين الثقة القابلة للتحقق
الاختبار النهائي للمساءلة ليس ما إذا كانت OneLogin أوقفت الوصول غير المصرح به. لقد فعلت، وفقًا للسجل العام. الاختبار هو ما إذا كانت سلسلة ثقة الهوية قد أعيد تعيينها بطريقة قابلة للتحقق. بالنسبة للمزود، يعني ذلك إلغاء مفاتيح AWS المخترقة، وتدمير أو إعادة بناء البنية التحتية المتأثرة، وتتبع مسارات الوصول المشتقة، وتحليل الوصول إلى قاعدة البيانات، وتقييم تعرض مفاتيح التشفير، وتعزيز ضوابط المنتج، والاحتفاظ بتوجيه العملاء.
بالنسبة للعميل، يعني ذلك تدوير شهادات SAML، واستبدال رموز OAuth، وإعادة إنشاء بيانات اعتماد API، ومراجعة الأسرار المخزنة، وتغيير كلمات المرور حيثما دعت الحاجة، وتجديد أسرار تكامل MFA، والتحقق من السجلات اللاحقة، وتتبع الاستثناءات إلى الإغلاق.
إعادة تعيين الثقة القابلة للتحقق يجب أن تكون قابلة للقياس. يجب أن يكون المزود قادرًا على إظهار أعداد المستأجرين المتأثرين، والإشعارات المرسلة، وتحديثات التوجيه، وحالات الدعم، وتغييرات المنتج، وفئات المواد المدورة. يجب أن يكون العميل قادرًا على إظهار أعداد التطبيقات التي تمت مراجعتها، والشهادات التي تم تغييرها، والرموز التي ألغيت، والمستخدمين الذين تم إخطارهم، والأسرار التي تم تدويرها، والسجلات التي تم البحث فيها. لا يحتاج أي من الجانبين إلى نشر تفاصيل حساسة على نطاق واسع، لكن كلاهما يحتاج إلى ملف أدلة للمدققين ومجالس الإدارة والجهات التنظيمية وقادة الأمن الداخلي.
تدعو القضية أيضًا إلى هندسة تجعل إعادة التعيين المستقبلية أصغر. يجب تقليل المفاتيح الثابتة طويلة العمر. يجب تفضيل الأدوار السحابية وبيانات الاعتماد المؤقتة حيثما أمكن. يجب ألا تثق قواعد بيانات الإنتاج بنفس بيانات الاعتماد التي تدير الحوسبة. يجب فصل سلطة فك التشفير عن سلطة قراءة قاعدة البيانات. يجب تقليل أسرار العملاء وجعلها قابلة للاكتشاف وإدارة دورة حياتها. يجب أن تدعم ثقة الاتحاد التبديل الطارئ للشهادات. يجب أن تكون السجلات متاحة للعملاء بسرعة. يجب أن تتوافق وعود منطقة البيانات مع حدود التحكم الفعلية.
لهذا السبب يظل الحادث ذا صلة بعد فترة طويلة من 2017. المؤسسات الحديثة أكثر اعتمادًا على مزودي الهوية، وليس أقل. المزيد من التطبيقات تستخدم SSO. المزيد من APIs تستخدم الرموز. المزيد من الأتمتة تستخدم هويات غير بشرية. المزيد من الأنظمة التنظيمية تسأل أين تتم معالجة البيانات ومن يتحكم فيها. لذلك يخلق اختراق المزود مشكلة مساءلة مركبة: اعتماد على الخدمات السحابية، ومحلية البيانات، وأتمتة الأمان، كلها تتصادم.
يجب تذكر اختراق OneLogin لعام 2017 كقضية نصف قطر انفجار مزود هوية، وليس فقط قضية مفتاح AWS. المفتاح المسروق أو المكشوف كان المسار الموصوف في السجل العام. الاختبار الحقيقي كان ما إذا كان المزود والعملاء يمكنهم إعادة تعيين السلطة التي جعلت آلاف عمليات تسجيل الدخول اللاحقة ممكنة. تبدأ المساءلة عندما يتم توثيق إعادة التعيين، ويتم تسمية المجهولات، ويتم تغيير الهندسة بحيث يكون لتعرض المفتاح التالي من جانب المزود نصف قطر انفجار أصغر وأوضح وأسرع احتواءً.