ملخص

  • تكتسب حادثة تكامل 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 نشر تنبيهًا أمنيًا علىhttps://github.blog/news-insights/company-news/security-alert-stolen-oauth-user-tokens/يصف رموز OAuth الخاصة بالمستخدمين المسروقة والصادرة لـ Heroku وTravis CI. صفحة حالة الحادثة الخاصة بـ Heroku علىhttps://status.heroku.com/incidents/2413ومراجعة Heroku العامة لحادثة أبريل 2022 علىhttps://blog.heroku.com/april-2022-incident-reviewتؤطر الأمر من جانب المنصة. النشرة الأمنية لـ Travis CI علىhttps://www.travis-ci.com/blog/2022-04-15-security-bulletin/توفر مسار تكامل متأثر آخر. تحدد هذه المصادر الملامح العامة: رموز OAuth المرتبطة بسير عمل المطورين وإشعار العملاء وتحديثات التحقيق وسلسلة من الإجراءات الوقائية.

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

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

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

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

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

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

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

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

توثيق GitHub الحالي لـ OAuth علىhttps://docs.github.com/en/apps/oauth-appsودليل الحفاظ على تطبيق OAuth علىhttps://docs.github.com/en/apps/oauth-apps/maintaining-oauth-appsمفيد لأنه يظهر المفردات الرقابية حول تطبيقات OAuth وأسرار العميل وعناوين URL لرد الاتصال والملكية وإدارة التطبيق. دليل سجل تدقيق المؤسسة في GitHub علىhttps://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/about-the-audit-log-for-your-enterpriseيظهر لماذا تحتاج المؤسسات إلى أدلة النشاط بعد حدث تكامل مشتبه به. توثيق تكامل Heroku مع GitHub علىhttps://devcenter.heroku.com/articles/github-integrationيظهر سطح الميزة المرئي للعميل. لا يثبت أي من هذه المستندات بالضبط ما حدث في 2022. إنها تحدد السطح التشغيلي الذي كان على العملاء تأمينه.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

صفحات Heroku Dev Center مثلhttps://devcenter.heroku.com/articles/oauthوhttps://devcenter.heroku.com/articles/platform-api-referenceوhttps://devcenter.heroku.com/articles/heroku-cliوhttps://devcenter.heroku.com/articles/account-securityتظهر بيئة إدارة الوصول الأوسع حول استخدام منصة Heroku. صفحة المصادقة الثنائية لـ Heroku علىhttps://devcenter.heroku.com/articles/heroku-2faتوفر سياق تعزيز الحساب من جانب العميل. مرة أخرى، التوثيق الحالي ليس دليلاً على الحالة الداخلية لعام 2022. إنه يساعد القراء على فهم أنواع بيانات الاعتماد وإجراءات المستخدم التي يمكن أن تكون حول حساب Heroku.

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

أصعب طبقة هي التعرض لأسرار شفرة المصدر. إذا كان المهاجم قادرًا على قراءة المستودعات، فإن تدوير رمز OAuth فقط قد لا يكون كافيًا. قد يحتاج العملاء إلى البحث في المستودعات عن الأسرار الملتزمة وتدوير أي قيمة مكشوفة. توثيق فحص الأسرار من GitHub علىhttps://docs.github.com/en/code-security/secret-scanning/about-secret-scanningيوفر مفردات اليوم لتلك المراجعة من جانب العميل. إرشادات سلسلة توريد البرامج من CISA علىhttps://www.cisa.gov/resources-tools/resources/software-supply-chain-risk-management-sscrmومواد التصميم الآمن تساعد في شرح لماذا يمكن للأسرار في الكود أن تحول حدث المستودع إلى مخاطر تشغيلية أوسع.

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

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

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

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

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

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

ما الذي يجب أن يبدو عليه الإصلاح الدائم بعد حادثة وصاية OAuth

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

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

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

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

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

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