اختبار مساءلة حفظ رمز OAuth في Heroku

ملخص

حادثة تكامل Heroku مع GitHub في 2022 مهمة لأن رموز OAuth ليست كلمات مرور عادية؛ فهي تفويض سلطة يمكنه ربط مستودعات المصدر وخطوط الأنابيب النشر وأنظمة البناء وتطبيقات العملاء ومستخدمي البرامج النهائيين.
حذرت GitHub علنًا من أن مهاجمًا استخدم رموز OAuth المسروقة الصادرة لـ Heroku و Travis CI، بينما تطلبت اتصالات Heroku حول الحادثة من العملاء اتباع إرشادات التدوير مع تطور التحقيق والإبطال وإعادة تعيين بيانات الاعتماد.
سؤال المساءلة ليس فقط ما إذا قامت Heroku في النهاية بتدوير المفاتيح أو استعادة التكاملات. بل هو من الذي تحكم في حفظ الرمز وإشعار العملاء وسلوك تطبيق GitHub وأدلة الوصول إلى كود المصدر وحدود الثقة في CI/CD والدليل بعد الحادثة.
تتعامل هذه المقالة مع مصادر Heroku و GitHub و Travis CI و Salesforce و IETF و NIST و CISA و MITRE كمسارات أدلة منفصلة؛ لا يتم التعامل مع أي مصدر عام كسجل جنائي داخلي كامل.
الدرس الدائم هو أن راحة منصة المطورين يجب أن تحمل سجل حفظ: أي رمز تكامل موجود، ولماذا يوجد، وما نطاقه، وأين يتم تخزينه، ومن يمكنه إبطاله، وما الأدلة التي يتلقاها العملاء عندما يصبح الرمز مشبوهًا.

لماذا تنتمي هذه القضية إلى ملف الخطر والمساءلة

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

كان المحفز العام في 2022 مرئيًا لأن GitHub نشر تنبيهًا أمنيًا على source: github.blog يصف رموز OAuth المسروقة الصادرة لـ Heroku و Travis CI. وتؤطر صفحة حالة Heroku الخاصة بالحادثة على source: status.heroku.com ومراجعة Heroku العامة للحمادثة في أبريل 2022 على source: blog.heroku.com المسألة من جانب المنصة. وتوفر نشرة Travis CI الأمنية على source: travis-ci.com مسارًا آخر للتكامل المتأثر. تحدد هذه المصادر الملامح العامة: رموز OAuth المتصلة بسير عمل المطورين وإشعار العملاء وتحديثات التحقيق وسلسلة من الإجراءات الوقائية.

القضية مهمة لأن OAuth يغير شكل المساءلة. غالبًا ما يمكن تفسير كلمة المرور المسروقة من خلال حساب مستخدم واحد. لكن رمز OAuth المسروق قد يمثل سلطة مفوضة استمرت بعد اللحظة التي فكر فيها المستخدم آخر مرة في الموافقة. قد يحمل صلاحية الوصول إلى المستودعات وصلاحية سير العمل المؤتمت ونطاق API وصلاحية الوصول إلى البيانات الوصفية وتضمينات العضوية في المؤسسة أو صلاحية النشر. وثائق IETF الخاصة بـ OAuth 2.0 على source: datatracker.ietf.org وسجل أفضل الممارسات الأمنية الحالية على source: datatracker.ietf.org ليست تقارير حادثة عن Heroku، لكنها تساعد في تحديد سبب أهمية إصدار الرمز ونطاقه وتخزينه وتدويره وإبطاله ومقاومة إعادة التشغيل وثقة العميل.

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

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

يظهر السجل العام أيضًا سبب انتماء حوادث أدوات المطورين إلى مساءلة سلسلة توريد البرامج، وليس فقط مساءلة أمان الحساب. الوصول إلى كود المصدر يسبق أمان التطبيق والأسرار ووظائف CI/CD وأعمال البناء وبيانات اعتماد النشر وإصدارات المنتج. تعتبر تقنية رمز الوصول للتطبيق من MITRE ATT&CK على source: attack.mitre.org وتقنية بيانات الاعتماد البديلة على source: attack.mitre.org مفردات مفيدة لأنها تميز سوء استخدام الرمز عن التخمين العادي لبيانات الاعتماد. تساعد مواد CISA للتصميم الآمن على source: cisa.gov وإطار تطوير البرامج الآمن من NIST على source: csrc.nist.gov في شرح سبب وجوب معاملة حفظ كود المصدر وثقة نظام البناء كضوابط إنتاجية.

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

موافقة OAuth تصبح حفظًا بعد النقرة الأولى

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

وثائق GitHub الحالية لـ OAuth على source: docs.github.com وإرشادات صيانة تطبيق OAuth على source: docs.github.com مفيدة لأنها تظهر مفردات التحكم حول تطبيقات OAuth وأسرار العميل وعناوين URL لرد الاتصال والملكية وإدارة التطبيقات. إرشادات سجل تدقيق GitHub للمؤسسات على source: docs.github.com تظهر لماذا تحتاج المؤسسات إلى أدلة نشاط بعد حدث تكامل مشتبه به. وثائق تكامل Heroku مع GitHub على source: devcenter.heroku.com تظهر سطح الميزة المرئي للعميل. لا تثبت أي من هذه المستندات بالضبط ما حدث في 2022. إنها تحدد سطح التشغيل الذي كان على العملاء تأمينه.

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

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

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

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

الوصول إلى كود المصدر ليس مثل اختراق الإنتاج، لكنه ليس غير ضار

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

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

NIST SP 800-218 على source: csrc.nist.gov مفيد لأنه يعامل تطوير البرامج الآمن كدورة حياة، وليس فقط كتابة الكود. NIST SP 800-204D على source: csrc.nist.gov يساعد في تأطير أسئلة أمان التطبيقات السحابية الأصلية وهوية الخدمة. NIST SP 800-53 Rev. 5 على source: csrc.nist.gov يعطي مفردات تحكم للتحكم في الوصول والتدقيق والتكوين والاستجابة للحوادث ونظام النزاهة. هذه المواد ليست نتائج خاصة بـ Heroku. إنها معايير لتقرير ما إذا كان يجب مراجعة حادثة منصة مطورين كحدث في سلسلة توريد البرامج.

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

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

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

توقيت الإشعار هو جزء من سطح التحكم

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

صفحة حادثة Heroku على source: status.heroku.com مفيدة لأن تحديثات الحالة تظهر تسلسلًا بدلاً من بيان نهائي واحد. يوفر تنبيه GitHub الأمني مسارًا زمنيًا آخر. نشرة Travis CI توفر ثالثًا. لا يجب على القارئ الدقيق طي هذه الخطوط الزمنية في تسلسل زمني مثالي واحد ما لم تدعم المصادر ذلك. السؤال المفيد هو كيف غير إشعار كل فاعل إجراء العميل. هل احتاج العملاء إلى إبطال تفويض التطبيق؟ هل احتاجوا إلى تدوير مفاتيح Heroku API؟ هل احتاجوا إلى تدوير كلمات مرور Heroku؟ هل احتاجوا إلى فحص مستودعات GitHub؟ هل احتاجوا إلى التحقق من متغيرات بيئة CI؟ هل احتاجوا إلى إعادة بناء خطافات النشر؟

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

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

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

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

التدوير الإجباري هو علاج فقط إذا عرف العملاء ما تغير

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

صفحات Heroku Dev Center مثل source: devcenter.heroku.com و source: devcenter.heroku.com و source: devcenter.heroku.com و source: devcenter.heroku.com تظهر بيئة إدارة الوصول الأوسع حول استخدام منصة Heroku. صفحة المصادقة الثنائية في Heroku على source: devcenter.heroku.com توفر سياقًا لتقوية الحساب من جانب العميل. مرة أخرى، الوثائق الحالية ليست دليلاً على الحالة الداخلية لعام 2022. إنها تساعد القراء على فهم أنواع بيانات الاعتماد والإجراءات التي يمكن أن تحيط بحساب Heroku.

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

أصعب طبقة هي كشف سر كود المصدر. إذا كان المهاجم يستطيع قراءة المستودعات، فإن تدوير رمز OAuth فقط قد لا يكون كافيًا. قد يحتاج العملاء إلى البحث في المستودعات عن أسرار ملتزمة وتدوير أي قيمة مكشوفة. وثائق فحص الأسرار في GitHub على source: docs.github.com تعطي مفردات حالية لتلك المراجعة من جانب العميل. إرشادات CISA لسلسلة توريد البرامج على source: cisa.gov ومواد التصميم الآمن تساعد في شرح لماذا يمكن للأسرار في الكود تحويل حدث المستودع إلى مخاطر تشغيلية أوسع.

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

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

GitHub و Heroku و Travis CI و Salesforce والعملاء، كل منهم يمتلك أدلة مختلفة

خريطة مساءلة الحادثة متعددة الأطراف. يمتلك GitHub أدلة المضيف المصدر ورؤية تطبيق OAuth والتنبيه الأمني الذي نشره. تمتلك Heroku تكامل منصتها واتصالات العملاء وحفظ الرمز وبرنامج الإجبار على بيانات الاعتماد. يمتلك Travis CI قناة تكامل CI/CD المتأثرة وتوجيهاته للعملاء. تمتلك Salesforce حوكمة Heroku وتخصيص الموارد وتصعيد المخاطر وواجب جعل إصلاح المنصة موثوقًا. يمتلك العملاء نظافة المستودع وتدوير الأسرار وموافقات OAuth التنظيمية ومراجعة النشر. لا يلغي أي من هذه الأدوار الآخرين.

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

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

تشكل مصادر IETF و NIST و MITRE و CISA و GitHub و Heroku و Travis CI معًا ملفًا عامًا محددًا. لا تكشف كل حقيقة خاصة، لكنها تسمح بنموذج مساءلة واضح. يجب أن تكون رموز OAuth محددة النطاق بدقة، ومخزنة بشكل قابل للدفاع، وقابلة للإبطال بسرعة، ومراقبة باستمرار، ومعينة بالغرض التجاري الحالي. يجب على منصات المطورين التواصل حول الحوادث بدقة كافية للسماح للعملاء بالتصرف. يجب على العملاء مراجعة التكاملات بشكل دوري بدلاً من معاملة التفويض كأمر دائم. يجب على مضيفي المصدر جعل أدلة التدقيق متاحة بما يكفي للعملاء لتمييز التعرض المحتمل عن الوصول المؤكد.

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

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

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

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

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

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

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

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

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

المشتريات والحوكمة يجب أن تعامل التكاملات كوصول دائم

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

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

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

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

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

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

ما يجب أن يبدو عليه الإصلاح الدائم بعد حادثة حفظ رمز OAuth

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

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

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

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

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

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