عندما تعيش قواعد الأمان في المستندات، يتم تجاهلها

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

هذه ليست قصة عن سوء النية. إنها قصة عن كيفية انهيار القواعد عندما تعيش خارج خط الأنابيب.

مشكلة القواعد كمستندات

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

النتيجة متوقعة. بعض الفرق تتبع القواعد. بعض الفرق تتبع نسخة مختلفة قليلاً. بعض الفرق تنسى تمامًا. ولا أحد يعرف أي موقف يحدث حتى يحدث خطأ ما.

الفرق بين هذين النهجين يصبح واضحًا عند رسم التدفق:

flowchart TD subgraph Document-Based [قائم على المستندات] A[فريق الأمان] -->|يكتب سياسة| B[Wiki/PDF] B -->|يقرأها بشري| C[فريق التطوير] C -->|يفسرها| D[إعدادات يدوية] D -->|يطبقها على| E[خط الأنابيب] E -->|قد يطبق أو لا| F[التنفيذ] end subgraph Policy as Code [السياسة ككود] G[فريق الأمان] -->|يكتب قاعدة| H[ملف سياسة في المستودع] H -->|مراجعة PR| I[التحكم بالإصدارات] I -->|CI يلتقطها| J[محرك السياسات] J -->|يقيم| K[خط الأنابيب] K -->|تلقائيًا| L[التنفيذ] end

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

كتابة القواعد ككود

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

الصيغة تختلف. بعض الفرق تستخدم Rego من Open Policy Agent. بعضها يستخدم YAML مع مخطط محدد. بعضها يستخدم أطر السياسات المدمجة من أدوات الفحص الحالية. اللغة أقل أهمية من المبدأ: القواعد تُكتب، وتُوضع في الإصدارات، وتُراجع، وتُنفذ تلقائيًا.

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

ما الذي يتغير عندما تصبح القواعد كودًا

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

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

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

لست بحاجة لكتابة كل شيء من الصفر

مفهوم خاطئ شائع هو أن سياسة ككود تعني كتابة كل قاعدة بنفسك. في الممارسة العملية، معظم القواعد تأتي من أطر عمل موجودة. أدوات الأمان تأتي مع سياسات لمعايير CIS والأطر التنظيمية وأنماط الأمان الشائعة. تقوم بتفعيل تلك التي تنطبق على مؤسستك وتعديل العتبات لتتناسب مع مستوى تحمل المخاطر لديك.

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

التحول العملي

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

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

قائمة مراجعة سريعة للبدء

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

ابدأ بقاعدة واحدة. أثبت أن سير العمل يعمل. ثم وسع.

الخلاصة

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