ملخص

  • ذكر تقرير الحادثة العام لـ CircleCI أن طرفًا ثالثًا غير مصرح له استخدم برمجيات خبيثة على حاسوب محمول لأحد مهندسي CircleCI لسرقة جلسة دخول موحدة (SSO) صالحة ومحمية بعامل مصادقة ثانٍ (2FA)، ثم تصعيد الوصول إلى جزء من أنظمة الإنتاج، وسرقة معلومات العملاء التي تضمنت متغيرات بيئية ورموزًا ومفاتيح.
  • من كان يمتلك السيطرة العملية على حفظ أسرار العملاء، ومقاومة اختراق أجهزة الموظفين، وإلغاء الرموز، والكشف عن متغيرات البيئة، وإشعار العملاء، وتوجيه التدوير، وإثبات أن حدود الثقة في CI أصبحت أكثر مرونة؟
  • تتمثل قضية المساءلة في أن منصات CI تحمل السلطة التشغيلية على بيانات اعتماد النشر حتى عندما يكون كود التطبيق الأساسي والحسابات السحابية وأنظمة الأعمال مملوكة للعملاء.
  • احتاج المطورون وفرق المنصات والمؤسسات والمستخدمون النهائيون وفرق الأمان والمدققون وأصحاب الموارد السحابية إلى دليل على أن تدوير أسرار العملاء قد اكتمل وأن التعرض المتكرر قد تم تقييده.
  • تتناول هذه المقالة تقرير حادثة CircleCI والتنبيه الأمني وإرشادات الدعم ووثائق المنتج باعتبارها السجل العام الأساسي. تُستخدم وثائق GitHub وAWS وGoogle Cloud وCISA وNIST وغيرها من الوثائق التقنية لتقييم تصميم الضوابط، وليس للادعاء بأن تلك المنظمات توصلت إلى استنتاجات محددة ضد CircleCI.

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

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

يبدأ السجل العام بالتنبيه الأمني لـ CircleCI علىhttps://circleci.com/blog/january-4-2023-security-alert/وتقرير الحادثة اللاحق علىhttps://circleci.com/blog/jan-4-2023-incident-report/. قالت CircleCI إنها نبهت العملاء في 4 يناير 2023، وأوصت بتدوير أي أسرار مخزنة في CircleCI. ذكر تقرير الحادثة أن المهاجم استغل برمجيات خبيثة نُشرت على حاسوب محمول لأحد مهندسي CircleCI، وسرق جلسة SSO صالحة مدعومة بـ 2FA، وانتحل شخصية الموظف، وصعّد الوصول إلى جزء من أنظمة الإنتاج، وسرق معلومات العملاء في 22 ديسمبر 2022. وشملت البيانات التي وصفتها CircleCI متغيرات بيئية للعملاء ورموزًا ومفاتيح لأنظمة طرف ثالث.

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

أجبر ذلك العملاء على تنفيذ عملية تصحيح كبيرة وموزعة.

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

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

حوّل الحادث أسرار العملاء إلى التزام إصلاح مشترك

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

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

تساعد وثائق CircleCI الخاصة في شرح السبب. دليل متغيرات البيئة علىhttps://circleci.com/docs/guides/security/env-vars/يصف متغيرات البيئة كوسيلة لتكوين الوظائف وحفظ الأسرار والمفاتيح الخاصة والسياقات. وثائق السياقات علىhttps://circleci.com/docs/guides/security/contexts/تصف متغيرات البيئة على مستوى المؤسسة التي يمكن حقنها في وقت التشغيل في الوظائف. مقال الدعم لحادثة 4 يناير علىhttps://support.circleci.com/hc/en-us/articles/11816211460891-Rotating-Secrets-for-January-4th-Incidentيسرد فئات التدوير العملية: رموز OAuth، ورموز API للمشروع، ومتغيرات بيئة المشروع، ومتغيرات السياق، ورموز API للمستخدم، ومفاتيح SSH للمشروع، ورموز العاملين. تلك القائمة تظهر الهدف الحقيقي للحوكمة. لم يكن على العميل أن يسأل عما إذا كانت كلمة مرور واحدة قد تعرضت؛ بل كان يحتاج إلى جرد الرسم البياني للثقة في CI.

كان للرسم البياني للثقة طبقات ملكية متعددة. يمكن لـ CircleCI إلغاء رموز API للمشروع والشخصية التي تم إنشاؤها قبل تاريخ قطع محدد. يمكنها العمل مع GitHub وAtlassian لتدوير رموز OAuth نيابة عن العملاء. يمكنها نشر الإرشادات والأدوات لتحديد الأسرار المخزنة. لكن مفتاح الوصول إلى AWS للعميل، أو كلمة مرور قاعدة البيانات، أو مفتاح التوقيع، أو رمز Kubernetes، أو مفتاح API لـ SaaS تابع لجهة خارجية كان يجب تدويره في النظام الذي يقبل ذلك المفتاح فعليًا. لم تستطع CircleCI رؤية كل الاستخدامات النهائية، ولم يستطع العملاء رؤية كل التحقيقات الداخلية لـ CircleCI.

لذلك كان الإصلاح مشتركًا: كان على CircleCI الإفصاح بالسرعة الكافية وتقديم تفاصيل كافية؛ وكان على العملاء القيام بالتدوير الخاص بهم ومراجعة السجلات.

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

جلسة SSO مسروقة مدعومة بـ 2FA غيرت درس الطرفية والهوية

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

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

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

البيئة المعيارية الأوسع تعزز الدرس. صحيفة حقائق CISA حول MFA المقاوم للتصيد علىhttps://www.cisa.gov/sites/default/files/2023-01/fact-sheet-implementing-phishing-resistant-mfa-508c.pdfتشرح لماذا تقاوم بعض طرق المصادقة التصيد وانتحال هوية المدقق بشكل أفضل من الرموز لمرة واحدة العادية. توجيه NIST للهوية الرقمية علىhttps://pages.nist.gov/800-63-4/sp800-63b.htmlيميز بين المصادقات الأقوى وضوابط الجلسة والافتراضات الأضعف حول الحيازة. مواد FIDO Alliance حول مفاتيح المرور و FIDO2 علىhttps://fidoalliance.org/passkeys/وhttps://fidoalliance.org/fido2/تشرح نموذج المفتاح العام وراء المصادقة المقاومة للتصيد. هذه الوثائق ليست استنتاجات ضد CircleCI. إنها مفردات التحكم لفهم لماذا يمكن لجلسة مدعومة بـ 2FA أن تظل بحاجة إلى ترقية تدريجية وضمانات مرتبطة بالجهاز.

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

كان يجب أن يكون التدوير قابلاً للاكتشاف ومختومًا بالوقت وقابلاً للتدقيق

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

أدركت استجابة CircleCI هذه المشكلة العملية. أشار التنبيه الأمني العملاء إلى أداة CircleCI-Env-Inspector علىhttps://github.com/CircleCI-Public/CircleCI-Env-Inspectorلاكتشاف الأسرار المخزنة. قالت CircleCI إنها أضافت حقلupdated_atإلى واجهة برمجة تطبيقات السياقات حتى يتمكن العملاء من التحقق من نجاح تدوير متغيرات السياق. أضافت دعم توقيع SHA-256 لمفاتيح الخروج. جعلت سجلات التدقيق متاحة للعملاء المجانيين والمدفوعين أثناء الاستجابة. توثق وثائق API الخاصة بها علىhttps://circleci.com/docs/api/v2/عمليات السياقات ومتغيرات البيئة ذات الصلة بالأتمتة. توثق وثائق سجل التدقيق علىhttps://circleci.com/docs/guides/security/audit-logs/كيف يمكن للمؤسسات استرداد بيانات التدقيق.

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

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

احتاج العملاء أيضًا إلى التدقيق خارج CircleCI. أدرج تقرير حادثة CircleCI عناوين IP وموفري VPN وملفات ضارة ومؤشرات سجل تدقيق GitHub مثلrepo.download_zip. يمكن أن تساعد هذه المعلومات العملاء في البحث في سجلات GitHub والسحابة والسجلات الداخلية. وثائق تطبيق OAuth من GitHub علىhttps://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-appsذات صلة لأن منح OAuth الواسعة يمكن أن تربط خدمة CI بالوصول إلى المستودع. وثائق سجل تدقيق المؤسسة من GitHub علىhttps://docs.github.com/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organizationتعطي مفردات لمراجعة أحداث المستودع. لذلك كان الإصلاح من جانب العميل يجب أن يكون عبر الأنظمة، وليس مجرد تمرين إعدادات في CircleCI.

منصات CI تركز سلطة النشر دون امتلاك النظام المنشور

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

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

لهذا السبب فإن توجيه OIDC من CircleCI علىhttps://circleci.com/docs/guides/permissions-authentication/openid-connect-tokens/مهم. يتيح OIDC للوظائف استقبال رموز هوية قصيرة الأجل يمكن لموفري السحابة المتوافقين استبدالها ببيانات اعتماد مؤقتة، مما يقلل الحاجة إلى تخزين أسرار سحابية طويلة الأجل في CircleCI. وثائق AWS IAM حول موفري هوية OIDC علىhttps://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.htmlووثائق اتحاد هوية العمل في Google Cloud علىhttps://cloud.google.com/iam/docs/workload-identity-federationتشرح جانب موفر السحابة لهذا النموذج. درس المساءلة ليس أن OIDC كان سيحل كل مسار في حادثة 2023. إنه أن الأسرار طويلة الأجل المخزنة في منصة CI تخلق نصف قطر انفجار دائم، بينما يمكن لبيانات الاعتماد الموحدة قصيرة الأجل أن تجعل التعرض المستقبلي أقل قيمة.

ضوابط CircleCI الأخرى تتوافق مع نفس المبدأ. نطاقات IP علىhttps://circleci.com/docs/guides/security/ip-ranges/يمكن أن تساعد العملاء في تقييد الوصول الوارد إلى نطاقات الخروج المعروفة لـ CircleCI. قيود السياق يمكن أن تقلل من أي الوظائف ترى أي الأسرار. وثائق العاملين المستضافين ذاتيًا، بما في ذلك توجيه رمز العامل علىhttps://circleci.com/docs/guides/execution-runner/runner-faqs/، تظهر أن رموز العاملين لها نموذج حفظ خاص بها. وثائق CircleCI حول استخدام تطبيق GitHub في مؤسسات OAuth علىhttps://circleci.com/docs/guides/integration/using-the-circleci-github-app-in-an-oauth-org/تشير إلى وصول أكثر دقة وقصير الأجل للتحكم بالإصدارات مقارنة برموز OAuth الواسعة. كل ضيق يضيق جزءًا مختلفًا من الرسم البياني للثقة.

الاحتكاك الاقتصادي حقيقي. اعتماد OIDC يتطلب عمل IAM سحابي، وسياسات الثقة، وتكوين الوظائف، وأحيانًا تغييرات في التطبيق. تقليل السياق يتطلب من الفرق الهندسية إعادة تنظيم الأسرار وقبول راحة أقل. نطاقات IP قد تكلف أرصدة وتناسب فقط بعض أنماط الشبكة. مراجعة سجل التدقيق تستهلك وقت الموظفين. هجرة تطبيق GitHub يمكن أن تغير تدفقات ترخيص المستخدم. لكن الحادث أظهر التكلفة البديلة: تدوير طارئ عبر العديد من الفرق خلال نافذة عدم يقين حية. يجب أن يقارن ملف المخاطر الناضج التكلفة الثابتة للتكوين الآمن افتراضيًا مع التكلفة التخريبية للتنظيف بعد التعرض.

كان الإفصاح بحاجة لمساعدة العملاء على التصرف دون المبالغة في اليقين

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

عالج التقرير بعض تلك الأسئلة بتصريحات صريحة. قالت CircleCI إن العملاء يمكنهم البناء بأمان بعد تصحيح المنصة. قالت إن أي شيء تم إدخاله في النظام بعد 5 يناير 2023 يمكن اعتباره آمنًا. قالت إن الوصول غير المصرح به من طرف ثالث شوهد في 19 ديسمبر 2022 وحدثت سرقة البيانات في 22 ديسمبر 2022. أوصت بالتحقيق في الفترة من تاريخ الاختراق في 16 ديسمبر حتى إكمال العميل للتدوير. قالت إن أقل من خمسة عملاء أبلغوا CircleCI عن وصول غير مصرح به إلى أنظمة طرف ثالث نتيجة للحادث وقت النشر.

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

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

يدعم التوجيه التنظيمي والعام هذا النهج القائم على الأدلة. برنامج CISA للتصميم الآمن علىhttps://www.cisa.gov/securebydesignيؤكد على تقليل مخاطر العميل من خلال التصميم والمساءلة. إطار عمل NIST للأمن السيبراني علىhttps://www.nist.gov/cyberframeworkيعطي دورة مفيدة من التحديد والحماية والكشف والاستجابة والتعافي. في حالة CircleCI، الدورة ملموسة: تحديد الأسرار المخزنة، حماية الوظائف المستقبلية من خلال أقل امتياز وبيانات اعتماد قصيرة الأجل، كشف الاستخدام النهائي المشبوه، الاستجابة بالتدوير والإلغاء، والتعافي بإثبات أن بيانات الاعتماد القديمة لم تعد تعمل.

السيطرة العملية كانت مشتركة، لكن ليست متساوية

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

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

تظهر GitHub وBitbucket وGitLab وAWS وGoogle Cloud في خريطة المساءلة لأن أسرار CI للعملاء غالبًا ما تشير إليهم. قال تقرير CircleCI إنها عملت مع GitHub وAtlassian على تدوير الرموز. تشرح وثائق GitHub سجلات التدقيق وضوابط OAuth. تشرح وثائق AWS وGoogle Cloud الهوية الموحدة. هذه المزودات لم يُزعم في السجل العام أنها تسببت في حادثة CircleCI. إنها جزء من نظام الإصلاح البيئي لأن العملاء اضطروا إلى استخدام ضوابطهم لتدوير أو إلغاء أو تدقيق أو إعادة تصميم بيانات الاعتماد.

يمكن لموردي الأمان والتقارير الخارجية مساعدة العملاء في تفسير الحدث، لكن يجب أن تظل ثانوية. تحليل Snyk علىhttps://snyk.io/blog/supply-chain-security-incident-circleci-secrets/ومناقشة AppOmni علىhttps://appomni.com/ao-labs/unpacking-preventing-circleci-data-breach/أمثلة مفيدة للإرشاد الخارجي حول تدوير الأسرار ومخاطر SaaS. لا ينبغي أن تحل محل تقرير حادثة CircleCI كمصدر للحقائق المؤكدة. أقوى سجل يجمع بين الإفصاح الأولي عن الحادث، ووثائق المنصة، ووثائق الهوية السحابية، وسجلات جانب العميل.

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

كيف يجب أن يبدو الإصلاح القابل للتحقق

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

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

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

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

الطبقة الخامسة هي قابلية التدقيق. يجب أن يحصل العملاء على سجلات تظهر نشاط المنصة ذي الصلة بمؤسستهم. يجب على المزودين توثيق الاحتفاظ، وتغطية الأحداث، وحدود التصدير، والقيود المستندة إلى الخطة. إدخال سجل التغييرات لـ CircleCI في نوفمبر 2023 علىhttps://circleci.com/changelog/audit-log-includes-context-accessed/الذي يظهرcontext.secrets.accessedكحدث في سجل التدقيق يوضح التفاصيل التي يحتاجها العملاء: ليس فقط أن وظيفة قد تشغلت، ولكن أن سياقًا حساسًا قد تم الوصول إليه. المزيد من تفاصيل السجل يمكن أن يخلق مقايضات بين الخصوصية والأمان، لكن بدون دليل الأحداث، لا يمكن للعملاء تقييم التعرض للأسرار بشكل مستقل.

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

حدود الأدلة والمجاهيل

يدعم الدليل العام عدة استنتاجات ثابتة. كشفت CircleCI عن حادث أمني في 4 يناير 2023. قال تقرير حادثتها إن برمجيات خبيثة على حاسوب مهندس محمول مكّنت من سرقة جلسة SSO صالحة مدعومة بـ 2FA. قال إن المهاجم وصل إلى جزء من أنظمة الإنتاج وسرق معلومات العملاء في 22 ديسمبر 2022، بما في ذلك متغيرات البيئة والرموز والمفاتيح. أخبرت العملاء الذين خزنوا أسرارًا خلال الفترة ذات الصلة بافتراض أن تلك الأسرار قد تم الوصول إليها. ألغت أو دورت عدة فئات من الرموز وعملت مع الشركاء. قدمت توجيه التحقيق والمؤشرات. ذكرت أن أقل من خمسة عملاء أبلغوا CircleCI عن وصول غير مصرح به إلى أنظمة طرف ثالث وقت التقرير.

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

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

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

لماذا لا يزال هذا مهمًا في عام 2026

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

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

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

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

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

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

سجل المصادر