مشكلة انتشار الأسرار

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

يحدث الانتشار عندما تنتهي هذه الأسرار مبعثرةً في أماكن لا ينبغي أن توجد فيها أبدًا:

• الشيفرة المصدرية وملفات الإعدادات
• مسارات CI/CD ومتغيرات البيئة
• صور الحاويات والبنية التحتية ككود
• رسائل الدردشة ومواقع الويكي وأنظمة التذاكر

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

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

إليك شكل كلمة مرور قاعدة بيانات مضمَّنة مباشرةً في شيفرة التطبيق:

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

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

يمكنك استعادة سرّ مسرَّب من السجل في أي وقت:

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

عندما يُدفَع مستودع يحتوي على أسرار مضمَّنة مباشرةً في الشيفرة إلى مضيف عام مثل GitHub، تعمل الروبوتات الآلية على جمع محتواه خلال ثوانٍ إلى دقائق.

تشمل العواقب الواقعية ما يلي:

• فواتير سحابية كارثية، إذ استُخدمت مفاتيح AWS مسرَّبة لتشغيل أساطيل من أجهزة تعدين العملات المشفَّرة، ما أدى إلى تكبّد رسوم بعشرات الآلاف من الدولارات خلال ليلة واحدة.
• اختراقات البيانات، إذ أدت بيانات اعتماد قواعد البيانات المكشوفة إلى استخراج البيانات بالكامل.
• الحركة الجانبية، إذ استُخدم رمز مميز مسرَّب واحد للانتقال إلى مستويات أعمق من البنية التحتية.

تشغّل موفّرو الخدمات السحابية وGitHub الآن فحص الأسرار لاكتشاف المفاتيح المسرَّبة تلقائيًا، بل وإبطالها أحيانًا تلقائيًا، لكن لا يمكنكم الاعتماد على ذلك كشبكة أمان.

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

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

يمكن لأي شخص يسحب الصورة استخراج تلك الطبقة وقراءة المفتاح. استخدموا أسرار البناء أو الحقن أثناء التشغيل بدلًا من ذلك.

يُعد نقل الأسرار من الشيفرة إلى متغيرات البيئة تحسّنًا، لكنه ليس حلًا كاملًا. فمتغيرات البيئة تعالج مشكلة تضمين الأسرار مباشرةً في الشيفرة، لكنها تفتح مسارات جديدة للتعرّض:

• تتسرّب في تفريغات الأعطال وتتبع مكدسات الأخطاء
• تكون مرئية للعمليات الأخرى عبر /proc/<pid>/environ على Linux
• تسجّلها أدوات تصحيح الأخطاء التي تطبع البيئة كاملةً
• تُخزَّن في ملفات .env نصية عادية، وقد تُودَع في المستودع بالخطأ

تُعد متغيرات البيئة مقبولة للإعدادات منخفضة الحساسية، أما الأسرار عالية القيمة فمكانها مدير أسرار مخصص يوفّر التحكم في الوصول والتدقيق.

يجعل انتشار الأسرار الاستجابة للحوادث شبه مستحيلة. فعندما يكون السر موجودًا في كل مكان، يصبح السؤالان التاليان بلا إجابة:

• أين يوجد؟ لا يمكنكم تدوير ما لا تستطيعون العثور عليه.
• من استخدمه؟ من دون سجلات وصول مركزية، لا يمكنكم تحديد نطاق الاختراق.

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

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

تشمل الأدوات الشائعة مفتوحة المصدر gitleaks وtrufflehog وdetect-secrets. ويُشغَّل خطاف pre-commit نموذجي محليًا:

اجمعوا ذلك مع الفحص من جهة الخادم ضمن CI، حتى يُكتشف المطوّر الذي يتجاوز الخطاف المحلي.

إذا وصل سرّ إلى مكان لا ينبغي أن يكون فيه، فاتبعوا هذا الترتيب. يأتي التدوير أولًا، أما تنظيف السجل فثانوي لأن نسخًا من السر قد تكون موجودة بالفعل.

• 1. التدوير أبطِلوا السر المسرَّب وأصدروا سرًا جديدًا فورًا.
• 2. التدقيق راجعوا سجلات الوصول بحثًا عن أي استخدام غير مصرَّح به خلال فترة التعرّض.
• 3. التطهير أزيلوا السر من السجل، مثلًا باستخدام git filter-repo، ثم أجروا force-push.
• 4. الوقاية أضيفوا الفحص وانقلوا السر إلى مدير أسرار حتى لا يتكرر الأمر.

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

يزداد انتشار الأسرار سوءًا عندما تكون الأسرار مفرطة الصلاحيات ومُشارَكة على نطاق واسع. ويساعد تطبيق مبدأ أقلّ قدر من الامتيازات على الحد من الضرر عند حدوث تسرّب:

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

تحوّل هذه الممارسات الاختراق الكارثي إلى حادثة محدودة يمكن التعافي منها.

الأدوات وحدها لا تحل مشكلة الانتشار؛ بل تحلها الثقافة. تتعامل المؤسسة الناضجة مع إدارة الأسرار باعتبارها ممارسة مستمرة:

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

الهدف هو إنشاء نظام يصعب فيه تسرّب السر، ويسهل التعافي من تسرّبه.

اختبروا فهمكم لسبب عدم كفاية حذف السر المسرَّب.

تعلّمتم لماذا تُعد الأسرار المبعثرة والمضمَّنة مباشرةً في الشيفرة واحدةً من أكثر نقاط الضعف الأمنية شيوعًا وإضرارًا.

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

بعد ذلك، سنوحّد تخزين الأسرار بطريقة صحيحة باستخدام الخزنات ومخازن الأسرار.