لماذا يجب كتابة قواعد البنية التحتية ككود

فريقك لديه سياسة: لا ينبغي لأي مجموعة أمان أن تفتح منفذ SSH (المنفذ 22) للإنترنت بالكامل. الجميع يوافق على ذلك. إنه موجود في التوثيق. حتى أن أحدهم قام بطباعته ولصقه على الحائط.

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

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

مشكلة السياسات القائمة على المستندات

تبدأ معظم الفرق بسياسات مخزنة في مستندات. مستند Google، أو صفحة Confluence، أو ملف PDF يعيش في محرك أقراص مشترك. تصف هذه المستندات ما يجب وما لا يجب أن يحدث: "يجب تشفير جميع دلائل S3"، "يمكن استخدام صور AMI المعتمدة فقط"، "يجب أن يحتوي كل مورد على علامة مركز التكلفة".

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

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

ماذا يعني كتابة السياسة ككود

سياسة ككود تعني أخذ تلك القواعد وكتابتها بتنسيق يمكن للآلات قراءته وتنفيذه. بدلاً من مستند يقول "لا تفتح SSH للعالم"، تكتب قاعدة تتحقق من كل تغيير في البنية التحتية مقابل هذا القيد تلقائيًا.

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

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

مثال ملموس مع Open Policy Agent

دعنا نجعل هذا ملموسًا. Open Policy Agent (OPA) هي أداة شائعة لكتابة السياسة ككود. تستخدم لغة تسمى Rego. إليك ما تبدو عليه سياسة بسيطة تمنع الوصول إلى SSH من أي مكان:

deny if {
    input.resource.type == "aws_security_group_rule"
    "0.0.0.0/0" in input.resource.cidr_blocks
    input.resource.port == 22
}

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

يمكنك أيضًا كتابة العكس: قاعدة تسمح فقط بنطاقات CIDR محددة للوصول إلى SSH:

allow if {
    input.resource.type == "aws_security_group_rule"
    input.resource.cidr_blocks[_] != "0.0.0.0/0"
}

تعتمد الصيغة الدقيقة على أداتك ولغة السياسة، لكن النمط هو نفسه: القواعد هي كود، والكود يعمل تلقائيًا.

نهج آخر: Sentinel لمستخدمي Terraform

إذا كان فريقك يستخدم Terraform بشكل مكثف، فإن Sentinel من HashiCorp يقدم تكاملًا أكثر إحكامًا. تتم كتابة سياسات Sentinel خصيصًا لسياق تنفيذ Terraform. إليك نفس تقييد SSH في Sentinel:

import "tfplan"

allowed_cidrs = ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]

main = rule {
    all tfplan.resource_changes as _, change {
        change.type is "aws_security_group_rule" implies
        change.change.after.cidr_blocks all allowed_cidrs
    }
}

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

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

أين تخزن ملفات السياسة الخاصة بك

لديك خياران رئيسيان لمكان الاحتفاظ بملفات السياسة:

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

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

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

قائمة تحقق عملية للبدء

قبل الغوص في كتابة السياسات، راجع قائمة التحقق السريعة هذه:

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

القيمة الحقيقية تكمن في سير العمل

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

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