تسريبات الأسرار: خطوة واحدة نحو الحلsaster

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

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

يا إلهي! لقد دفعت مفاتيح الوصول إلى السحابة الخاصة بي إلى مستودع عام

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

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

على سبيل المثال، (في) الشهيرة هجوم كوديكوف كان الأمر ممكنًا في أبريل 2021 لأن صورة Codecov Docker تحتوي على بيانات اعتماد git التي سمحت للمهاجم بالوصول إلى مستودعات git الخاصة بـ Codecov وإضافة سطر واحد في البرنامج النصي للتحميل bash الخاص بـ Codecov لمتغيرات بيئة المجموعة وعناوين URL لمستودع git.

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

والمشكلة هي أن الأسرار المشفرة هي مكان شائع. في مارس 2022، تم تطوير Lapsus$ APT تسربت 189GB من كود مصدر سامسونج والملفات الحساسة الأخرى. وكشف التحليل أنه يحتوي على بعض 6,600 سرًا مشفرًا: 90% للأنظمة الداخلية، و10% للخدمات والأدوات الخارجية مثل GitHub أو AWS أو Google. وتضمنت هذه الأسرار مفاتيح AWS / Twilio / Google API وسلاسل اتصال قاعدة البيانات وغيرها من المعلومات الحساسة. هذا هو أحدث ما توصلت إليه معظم قواعد التعليمات البرمجية.

تسريبات الأسرار هي أسهل طريق لهجمات سلسلة التوريد

تعد تبعيات الحزمة هي الأكثر شيوعًا حاليًا، وإن لم تكن الهدف الفريد لهجمات سلسلة التوريد. يمكن للأشرار إنشاء حزمة جديدة تنتهي بتثبيتها في برامج الضحايا (باستخدام typosquatting وغيرها من التقنيات)، ولكنهم يحاولون عادةً إصابة حزمة موجودة إما عن طريق إضافة تعديلات على الكود المصدر في مستودعات البرامج (SCM) مثل GitHub أو GitLab أو BitBucket، أو عن طريق إضافة إصدارات ضارة إلى السجلات العامة مثل NPM وPyPI وRubyGems وMaven Central.

لكن إدخال تعليمات برمجية ضارة أو تبعية ضارة مخفية في رسم بياني معقد للتبعيات يتطلب ذلك login بيانات الاعتماد مثل اسم المستخدم/كلمة المرور أو الرموز المميزة أو مفاتيح الوصول (دعنا نسميها "مفاتيح"باختصار)، لمستودع المصدر المستهدف أو السجل العام، على التوالي. 

أحيانًا يحصل الأشرار على المفاتيح عبر هندسة اجتماعية. الهجوم على event-stream توفر حزمة NPM الشهيرة مثالاً رائعًا. ولكن البحث عن تسربت login تعد بيانات الاعتماد أو مفاتيح الوصول هي تقنية الهجوم الأكثر شيوعًا لهجمات سلسلة توريد البرامج.

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

التوصيات المعتادة

لا نقول شيئًا جديدًا هنا، أنتم تعلمون ذلك. لكن تصرّفوا! تذكّروا أن الروبوتات تفحص بانتظام جميع البيانات العامة. SCM المستودعات. بعض التوصيات، بدون ترتيب معين.

• إذا كان لديك مسؤولية عن إدارة أمن تكنولوجيا المعلومات، تحديد كيفية التعامل مع الأسرار في السياسة الأمنية. لكن السياسات تكون جيدة بقدر التنفيذ: تأكد من تطبيق إرشادات التعامل مع الأسرار في مؤسستك - بما في ذلك ليس فقط فرق DevOps الخاصة بك ولكن أيضًا موردي البرامج لديك، وأن خطة الاستجابة للحوادث في مؤسستك تحتوي على أحكام لحوادث تسرب الأسرار.
• تنفيذ وإنفاذ المصادقة متعددة العوامل (MFA، 2FA أو أي اختصار). ولا توجد تخفيضات في الأمان: مفتاح أمان USB يستحق الدولارات القليلة التي يكلفها. عليك أن تدفع أيًا من آلاف بيانات الاعتماد الخاصة بك (سهلة) ثم تسكر وتترك مفاتيحك في حانة تحتوي على شيء مرتبط بك (الاحتمالات أقل قليلاً، خاصة إذا كنت ممتنعًا عن تناول الكحول).
• استخدم مدير كلمات المرور بكلمة مرور قوية وغير محفوظة. للتعامل مع الأسرار في استخدام الأنظمة خزائن سرية. CI/CD الأنظمة ومقدمي الخدمات السحابية، SCMتوفر أدوات DevOps وأدوات s الأخرى هذه الخدمة، ولكن يمكنك اختيار حل Secret Vault العام.
• تفضل قصير الأمد الرموز المميزة لمفاتيح الوصول طويلة العمر. ومن الأسهل إبطالها وكشف نافذة محدودة للشر.
• الحد من إعادة استخدام بيانات الاعتماد: سيعيد المهاجمون استخدام بيانات الاعتماد التي تم جمعها لهدف ما في أنظمة أخرى، وهي نقطة أخرى لاستخدام مدير كلمات المرور. يجب على مديري كلمات المرور والخزائن السرية جعل إعادة استخدام بيانات الاعتماد شيئًا من الماضي.
• الحد من الاستخدام ومراقبته مشرف كلمات المرور. إنهم أقوياء بما يكفي ليستحقوا متابعة خاصة.
• تطبيق تجزئة وتشفير قوي. العودة إلى مفاتيح USB (التشفير)، والإجراءات الصارمة لنقل بيانات الاعتماد مع الشركاء وزملاء العمل، وما إلى ذلك.
• إستخدم الماسح الضوئي للأسرار، على سبيل المثال تشغيل في pre-commit صنارة صيد لتجنب التسريبات في أنظمة التحكم في الإصدار، كبوابة أمنية. قبل الشيء من المهم هنا. بدلاً من ذلك، استخدم عمليات المسح اللاحقة للكشف عن الأسرار المسربة على سبيل المثال كفحص قبل pull request ملاحظة: تتضمن منصة Xygeni الخاصة بنا ماسحًا للأسرار يسمح بكلا وضعي التشغيل. 
• البديل اليدوي للاستخدام مراجعات التعليمات البرمجية إن البحث عن الأسرار المشفرة له تكاليف أعلى ويعمل بعد ذلك.commit (ولكن نأمل على الأقل قبل أن يصبح السر متاحًا للغرباء). لكن المراجعات قد تكتشف أسرارًا غير تقليدية قد تتهرب من أجهزة فحص الأسرار.       
• تجنب عن طريق الخطأ commitربط الملفات الشائعة بأسرار التحكم في الإصدار بالطريقة المناسبة استبعاد الأنماط (مثل قالب "gitignore")، مع الأخذ في الاعتبار ملفات مثل .env, .npmrc, .pypircالملفات المؤقتة... طبقة إضافية في البصلة الأمنية بالفعل.
• والأخير في هذه القائمة الطويلة: السماح لموفري الخدمات السحابية بإجراء عمليات فحص بحثًا عن تسرب مفاتيحهم، عندما يكون ذلك متاحًا. على الأقل هذا قد نعلمك بشأن التسرب عند حدوثه، ولكن الأمان أمر لا بد منه لموفري الخدمات السحابية. هذا بعد خاصة لا يتمتع المسح السري بالشفافية فيما يتعلق بمكان إجراء الفحص وعدد المرات، وغالبًا ما يحتاج إلى إعداد واضح، ولكنه بالتأكيد المورد الأخير عندما يفشل كل شيء آخر.

يا إلهي! لقد دفعت مفاتيح الوصول إلى السحابة الخاصة بي إلى مستودع عام، خذ رقم 2

يمكن أن يحدث ذلك لأفضلنا. شمروا عن سواعدكم !

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

اتبع الخطوات الموصى بها من قبل المزود عندما تكون متاحة، مثل AWS في هذا المثال.

تحديد سبب التسرب. إن معرفة كيفية حدوث ذلك أمر ضروري للإفصاح والتحليل والاحتواء وأنشطة الدروس المستفادة.

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

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

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

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