مراجعة يدوية لكل تغيير سحابي… حتى وقعت الكارثة: كيف أنقذتني ‘السياسة كشيفرة’ (Policy as Code)

يا جماعة الخير، السلام عليكم ورحمة الله.

بتذكرها زي كأنها مبارح. كانت ليلة خميس، الساعة حوالي وحدة بعد نص الليل، والعيون صارت تزغلل من كثر التحديق في الشاشة. كان عنّا إطلاق ميزة جديدة ومهمة تاني يوم، والضغط كان “للركب”. وصلني طلب “Pull Request” من شب جديد في الفريق، فيه شوية تعديلات على البنية التحتية السحابية باستخدام Terraform.

بطبيعتي، وبحكم الخبرة، كنت أنا “فلتر الأمان” أو الـ “Gatekeeper” لكل تغيير بصير على السحابة. فتحت التقرير تبع Terraform plan، ومرقت عليه بعيوني المتعبة. عشرات الأسطر من الإضافات والتعديلات. شفت سطر بضيف قاعدة جديدة في مجموعة الأمان (Security Group) عشان يسمح بالوصول لمنفذ معين… “للضرورة القصوى وللتجربة فقط” زي ما كان مكتوب في التعليق. شفت المصدر `0.0.0.0/0`، واللي معناها “من أي مكان في العالم”. عقلي الباطن صرخ “خطر!”، بس عقلي الواعي، المرهق، قال “خلص يا أبو عمر، الشب حكى مؤقت وبدنا نخلص الشغل”. بلمسة زر، ضغطت “Approve” و “Merge”.

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

هذيك الليلة، حلفت يمين إنه هاي الطريقة لازم تتغير. مش معقول أظل ألحّق ورا كل واحد، وأكون أنا عنق الزجاجة اللي ممكن ينكسر في أي لحظة. لازم في طريقة أحسن، طريقة مؤتمتة ما بتتعب ولا بتنعس. ومن هنا، بدأت رحلتي الحقيقية مع مفهوم غيّر كل شيء: السياسة كشيفرة (Policy as Code).

لماذا فشلت المراجعة اليدوية؟ (أو ليش أبو عمر جاب العيد)

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

الخطأ البشري وارد… بل حتمي

مهما كنت خبيرًا أو “شنتير” في مجالك، أنت إنسان. بتتعب، بتنسى، بكون مزاجك مش رايق، أو بتكون تحت ضغط. أنا أبو عمر، وبكل خبرتي، غلطت. كيف عاد الشب الجديد اللي لسا بتعلم؟ الاعتماد على البشر بنسبة 100% في مهام متكررة ودقيقة مثل مراجعة قواعد الأمان هو مجازفة كبيرة.

انعدام التوحيد والاتساق (Inconsistency)

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

بطء العملية وعنق الزجاجة (The Bottleneck)

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

صعوبة التوسع (Scalability Issues)

بتقدر تراجع شغل 5 مطورين، يمكن 10 لو شديت حيلك. بس شو بصير لما الفريق يكبر ويصير 30 أو 50 مطور؟ أو لما عدد المشاريع يتضاعف؟ نموذج المراجعة اليدوية ينهار تمامًا. مستحيل تقدر تلاحق.

الحل السحري: السياسة كشيفرة (Policy as Code – PaC)

بعد ليلة الكارثة، غرقت في البحث والقراءة. كنت بدور على طريقة تخلي الكمبيوتر هو اللي يقوم بدور “شرطي المرور”، لكن بذكاء ودقة لا نهائية. وهنا تعرفت على الـ “Policy as Code” أو “PaC”.

شو يعني “السياسة كشيفرة”؟

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

• ممنوع فتح أي منفذ للعالم (`0.0.0.0/0`) إلا المنافذ 80 و 443.
• يجب أن تكون كل وحدات التخزين (Storage Buckets/Disks) مشفرة.
• يجب أن يحتوي كل مورد سحابي على وسوم (Tags) معينة مثل `owner` و `project`.
• ممنوع استخدام أنواع سيرفرات غالية جدًا (مثل `m5.24xlarge`) إلا بموافقة خاصة.

كل هذه القواعد وأكثر، بنحولها لشيفرة. هاي الشيفرة بتصير جزء من عملية التطوير والنشر التلقائية (CI/CD Pipeline). لما المطور يكتب كود البنية التحتية (Infrastructure as Code – IaC) تبعه، وقبل ما يتم تطبيق أي شيء على أرض الواقع، بتشتغل هاي “السياسات” وبتفحص الكود. إذا كان مخالف، بترفض التغيير فورًا وبتعطي المطور رسالة واضحة عن سبب الرفض وكيف يصلحه. ما في داعي تستنى أبو عمر يصحى من النوم!

كيف نطبقها عملياً؟ أدوات ومثال حي

الكلام النظري حلو، بس “الحكي ما عليه جمرك”. خلينا نشوف كيف ممكن نطبق هذا المفهوم عمليًا.

التعرف على Open Policy Agent (OPA)

واحدة من أشهر الأدوات في هذا المجال هي Open Policy Agent أو اختصارًا OPA (تُنطق “أوبا”). هي أداة مفتوحة المصدر من مؤسسة الحوسبة السحابية الأصلية (CNCF)، وهي عبارة عن محرك سياسات للأغراض العامة. أحلى ما فيها إنها مش مرتبطة بتقنية معينة. بتقدر تستخدمها مع Terraform, Kubernetes, Microservices, أو حتى تطبيقاتك الخاصة.

OPA بتستخدم لغة خاصة اسمها Rego. بصراحة، لغة Rego بالأول بتغلب شوي، زي القهوة السادة أول مرة بتشربها، بتحسها غريبة. بس لما تتعود عليها وتفهم منطقها، ما بتعرف تشتغل بدونها. هي لغة مصممة خصيصًا للتعبير عن السياسات فوق هياكل بيانات معقدة (مثل ملفات JSON).

مثال عملي: منع فتح منافذ خطرة في AWS

لنتخيل أننا نريد تطبيق القاعدة التي تسببت في الكارثة: “ممنوع فتح أي منفذ SSH (رقم 22) أو RDP (رقم 3389) للعالم الخارجي (`0.0.0.0/0`)”.

لو مطور كتب كود Terraform بهذا الشكل:

resource "aws_security_group_rule" "bad_ssh_rule" {
  type              = "ingress"
  from_port         = 22
  to_port           = 22
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"] // <-- هاي هي المصيبة!
  security_group_id = "sg-12345"
}

بدل ما أكتشفها أنا يدويًا، سنكتب سياسة بـ Rego لتمسكها تلقائيًا. سنستخدم أداة اسمها conftest التي تعمل مع OPA لفحص ملفات الإعدادات.

هذه هي السياسة بلغة Rego (احفظها في ملف مثلاً `security.rego`):

package terraform.aws.security

# Deny if a security group rule opens a sensitive port to the world
deny[msg] {
    # ابحث عن كل الموارد من نوع aws_security_group_rule
    resource := input.resource_changes[_]
    resource.type == "aws_security_group_rule"

    # تأكد أن القاعدة للاتصال الوارد (ingress)
    resource.change.after.type == "ingress"

    # تحقق إذا كان أحد الـ cidr_blocks هو 0.0.0.0/0
    contains(resource.change.after.cidr_blocks[_], "0.0.0.0/0")

    # تحقق إذا كان المنفذ من المنافذ الحساسة
    sensitive_ports := {22, 3389}
    sensitive_ports[resource.change.after.from_port]

    # إذا تحققت كل الشروط، ارفض التغيير وأعطِ هذه الرسالة
    msg := sprintf("يا حبيبنا، ممنوع فتح المنفذ %v للعالم كله! هاي ثغرة أمنية خطيرة. لو لازم، حدد الـ IP تبعك فقط.", [resource.change.after.from_port])
}

نصيحة من أبو عمر: لاحظ كيف الرسالة msg واضحة ومفيدة. لا تكتفِ بالقول “مرفوض”. اشرح للمطور لماذا رُفض طلبه وكيف يمكنه إصلاحه. هذا يحول الأداة من مجرد عائق إلى معلم يساعد الفريق على كتابة كود أفضل وأكثر أمانًا.

الآن، في الـ CI/CD pipeline، قبل تنفيذ terraform apply، نضيف خطوة بسيطة تقوم بتشغيل conftest على خطة Terraform (التي تكون بصيغة JSON). إذا اكتشفت السياسة أي مخالفة، ستفشل عملية البناء (Build) فورًا، ولن يتم تطبيق التغيير أبدًا. لقد أتمتّنا دور “أبو عمر” المرهق!

الفوائد اللي جنيتها (والنصائح الذهبية)

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

الفوائد الملموسة

• الأمان التلقائي (Automated Security): صرنا نصطاد عشرات المشاكل الأمنية المحتملة كل أسبوع، قبل أن تصل حتى إلى بيئة التطوير، ناهيك عن البيئة الحقيقية (Production).
• السرعة والرشاقة (Speed and Agility): المطورون صاروا يحصلون على تغذية راجعة فورية خلال دقائق بدلًا من ساعات أو أيام. لم أعد أنا عنق الزجاجة، وتفرغت للمهام الاستراتيجية الأكثر أهمية.
• التوحيد والاتساق (Standardization): نفس القواعد تطبق على الجميع، في كل مرة، بدون استثناءات. هذا خلق بيئة سحابية متجانسة وسهلة الإدارة.
• التدقيق والامتثال (Auditing and Compliance): عندما يأتي مدقق أمني أو مالي، بدلًا من البحث في سجلات التغييرات اليدوية، ببساطة نعرض له “السياسات كشيفرة”. الكود هو الدليل القاطع على أننا نطبق أفضل الممارسات.

نصائح من قلب الميدان

1. ابدأ صغيرًا ومتدرجًا: لا تحاول كتابة 100 سياسة في اليوم الأول. ابدأ بقاعدة أو قاعدتين من أهم القواعد وأكثرها خطورة (مثل الوصول العام، التشفير، أو الوسوم الإلزامية).
2. السياسات كود، عاملها ككود: ضع ملفات سياسات الـ Rego في نظام إدارة الإصدارات (Git)، واعمل لها مراجعة (Code Review) من قبل الفريق، واكتب لها اختبارات (Tests). عاملها بنفس احترافية كود التطبيق.
3. استخدم الوضع التحذيري أولاً (Warn Mode): معظم الأدوات تسمح لك بتشغيل السياسات في “وضع التحذير” بدلًا من “وضع الرفض”. هذا يسمح لك برؤية أثر السياسات الجديدة على الفريق دون تعطيل عملهم. بعد فترة، وعندما يتكيف الجميع، حولها إلى وضع الرفض (Deny).
4. شارك الفريق في كتابة السياسات: لا تجعل كتابة السياسات حكرًا على فريق الأمان أو كبار المطورين. عندما يشارك الجميع، يصبحون أكثر وعيًا بالأمان والتكاليف، وتصبح السياسات منطقية وعملية أكثر.

الخلاصة: من عنق الزجاجة إلى شريان الأتمتة 🚀

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

نصيحتي الأخيرة لك: لا تنتظر وقوع الكارثة حتى تتحرك. ابدأ اليوم، ولو بخطوة بسيطة، في استكشاف عالم الـ Policy as Code. ابدأ بتعريف سياسة واحدة بسيطة. صدقني، “أبو عمر” اللي جواتك، وكل فريقك، راح يدعيلك. فبدلًا من أن تكون حارسًا للبوابة، كن مهندسًا للطريق السريع والآمن.