لماذا يجب ألا يكون كلمة مرور قاعدة البيانات الخاصة بك في ملف إعدادات أبدًا
أنت تبني تطبيقًا جديدًا. في البداية، تضع كل البيانات المتغيرة في ملف واحد: اسم قاعدة البيانات، عنوان الخادم، روابط API. يذهب الملف إلى Git، ويُدفع إلى المستودع، ويُنشر على الخادم. كل شيء في مكان واحد، ويبدو الأمر عمليًا. ثم تضيف كلمة مرور قاعدة البيانات إلى نفس الملف. ثم رمز API. ثم مفتاح تشفير. فجأة، يصبح ملف الإعدادات الواحد خطرًا أمنيًا يمكن أن يسقط نظامك بالكامل.
هذه هي اللحظة التي تدرك فيها أن بيانات الإعدادات ليست كلها متساوية. بعض البيانات، إذا تم كشفها، تعطي شخصًا آخر مفاتيح مملكتك. هذه البيانات تُسمى "سرًا". ومعاملة الأسرار مثل الإعدادات العادية هي واحدة من أكثر الأخطاء شيوعًا وخطورة التي ترتكبها الفرق.
الفرق بين الإعدادات والسر
بيانات الإعدادات العادية تشمل أشياء مثل أسماء الخوادم، منافذ التطبيق، أو أعلام الميزات. إذا علم شخص خارج فريقك أن تطبيقك يعمل على المنفذ 8080، فهذه ليست كارثة. لا يمكنهم تسجيل الدخول إلى قاعدة بياناتك فقط لأنهم يعرفون رقم المنفذ.
الأسرار مختلفة. كلمة مرور قاعدة البيانات، رمز API، أو مفتاح التشفير يمكن استخدامها من قبل مهاجم لانتحال شخصية نظامك، الوصول إلى بياناتك، أو تدمير بنيتك التحتية. تأثير تسرب سر فوري وشديد.
ومع ذلك، لا تزال العديد من الفرق تتعامل مع الأسرار كما لو كانت إعدادات عادية. يضعون كلمات المرور في ملفات .env ويدفعونها إلى Git. يخزنون رموز API في ملفات إعدادات التطبيق ويدفعونها إلى المستودع. يحتفظون بمفاتيح SSH داخل مجلدات المشروع ويقومون بنسخ احتياطي لكل شيء إلى السحابة. هذا ليس لأن الفريق مهمل. عادةً لأنهم لم يواجهوا العواقب بعد.
ماذا يحدث عندما يتسرب سر
في عام 2022، وقعت عدة حوادث بارزة تضمنت رموز AWS متروكة في مستودعات عامة. استخدم المهاجمون تلك الرموز لتشغيل حالات تعدين العملات المشفرة. وصلت الفواتير إلى عشرات الآلاف من الدولارات في ساعات. في حالات أخرى، أدى تسرب كلمات مرور قاعدة البيانات إلى تنزيل بيانات العملاء وبيعها في الويب المظلم.
هذه الحوادث لم تبدأ بهجوم متطور. بدأت بخطأ بسيط: معاملة سر مثل ملف إعدادات. كان السر موجودًا، مرئيًا لأي شخص يمكنه الوصول إلى المستودع. بمجرد أن أصبح المستودع عامًا، أصبح السر عامًا أيضًا.
تاريخ Git يجعل هذا أسوأ. حتى إذا حذفت ملفًا يحتوي على سر، يبقى السر في تاريخ الالتزامات. أي شخص يستنسخ المستودع يمكنه تشغيل git log والعثور على كلمة المرور التي اعتقدت أنك أزلتها. لا توجد طريقة سهلة لمسح تاريخ Git تمامًا، خاصة إذا تم مشاركة المستودع أو تفريعه.
كيف تختلف الإعدادات والأسرار عمليًا
الاختلافات بين الإعدادات والأسرار تؤثر على كيفية التعامل معها في عملك اليومي وفي خط أنابيب CI/CD الخاص بك.
من يمكنه رؤيتها: يمكن أن تكون الإعدادات مرئية لجميع المطورين في الفريق. يجب أن تكون الأسرار مرئية فقط للأشخاص أو الأنظمة التي تحتاجها بشدة. ليس كل مطور يحتاج إلى معرفة كلمة مرور قاعدة بيانات الإنتاج.
أين يتم تخزينها: يمكن أن تعيش الإعدادات في Git. يجب ألا تُخزن الأسرار في Git أبدًا. إنها تنتمي إلى نظام تخزين أسرار مخصص يقوم بتشفيرها في حالة السكون وأثناء النقل.
كيف يتم تدويرها: نادرًا ما تحتاج الإعدادات إلى التدوير. تغير اسم خادم عندما تهاجر البنية التحتية، وهذا كل شيء. تحتاج الأسرار إلى تدوير منتظم. يجب تدوير كلمات مرور قاعدة البيانات كل بضعة أشهر، وتدويرها فورًا إذا كان هناك أي مؤشر على تسرب.
كيف تتعامل معها خطوط الأنابيب: في خط أنابيب CI/CD، يمكن قراءة الإعدادات مباشرة من ملف في المستودع. يأخذ خط الأنابيب الملف ويستخدمه. تتطلب الأسرار نهجًا مختلفًا. يجب على خط الأنابيب جلبها من نظام تخزين آمن، وحقنها في عملية البناء أو النشر، وضمان عدم ظهورها أبدًا في السجلات أو القطع الأثرية أو الملفات المنشورة.
العواقب العملية للخلط بينهما
عندما تتعامل مع الأسرار مثل الإعدادات، فإنك تخلق سلسلة من المشاكل التي يصعب التراجع عنها.
أولاً، تفقد السيطرة على من لديه حق الوصول. إذا كان السر في Git، فإن أي شخص لديه حق الوصول إلى المستودع لديه السر. يشمل ذلك المقاولين والموظفين السابقين الذين لا يزال لديهم حق الوصول، وربما المهاجمين إذا كان المستودع عامًا.
ثانيًا، تجعل التدوير صعبًا. إذا كان السر منتشرًا عبر ملفات إعدادات متعددة وفروع وبيئات نشر، فإن تدويره يعني العثور على كل نسخة وتحديثها. ستفوتك واحدة حتمًا، وستظل كلمة المرور القديمة صالحة في مكان ما.
ثالثًا، تكسر مسار التدقيق الخاص بك. إذا تسرب سر، تحتاج إلى معرفة من كان لديه حق الوصول ومتى. إذا كان السر في Git، فإن الإجابة هي "كل من كان لديه حق الوصول إلى المستودع على الإطلاق." هذا ليس مسار تدقيق مفيدًا.
طريقة بسيطة لمعرفة الفرق
قبل أن تضع أي بيانات في ملف إعدادات، اسأل نفسك سؤالًا واحدًا: "إذا رأى شخص خارج فريقي هذا، هل يمكنه استخدامه للوصول إلى نظامي؟"
إذا كانت الإجابة لا، فهي على الأرجح إعدادات. أسماء الخوادم وأرقام المنافذ وأعلام الميزات ومستويات السجل هي إعدادات.
إذا كانت الإجابة نعم، فهي سر. كلمات مرور قاعدة البيانات ورموز API ومفاتيح SSH ومفاتيح التشفير وبيانات اعتماد حسابات الخدمة هي أسرار.
هذا الاختبار البسيط سيمنع معظم الأخطاء الشائعة التي ترتكبها الفرق.
قائمة تحقق عملية للتعامل مع الأسرار
عند إعداد مشروعك التالي أو مراجعة مشروعك الحالي، اتبع قائمة التحقق هذه:
- هل جميع الأسرار مخزنة خارج Git؟ استخدم مدير أسرار مخصص أو خزنة.
- هل يتم حقن الأسرار في وقت التشغيل، وليس خبزها في الصور أو القطع الأثرية؟
- هل تجلب خطوط أنابيب CI/CD الخاصة بك الأسرار من مصدر آمن، وليس من ملفات المستودع؟
- هل الأسرار مستبعدة من السجلات ورسائل الأخطاء ومخرجات التصحيح؟
- هل لديك جدول تدوير لكل نوع من الأسرار؟
- هل هناك عملية لتدوير الأسرار فورًا عند الاشتباه في تسرب؟
- هل يمكنك إلغاء الوصول إلى الأسرار لأشخاص أو أنظمة معينة دون التأثير على الآخرين؟
الخلاصة
إذا كان جزء من البيانات يمكن استخدامه من قبل شخص آخر لانتحال شخصيتك أو نظامك، فهو ليس إعدادات. إنه سر. تعامل معه بشكل مختلف. خزنه بشكل منفصل. دورة بانتظام. ولا تدفعه إلى Git أبدًا. تكلفة تعلم هذا الدرس بالطريقة الصعبة أعلى بكثير من الجهد المبذول للقيام به بشكل صحيح من البداية.