عندما تتغير البنية التحتية خارج خط أنابيبك: الانجراف والسياسات والحوكمة العملية

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

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

هذا هو انجراف البنية التحتية (Infrastructure Drift). يحدث في كل مؤسسة تدير أنظمة حقيقية. السؤال ليس ما إذا كان سيحدث، بل كيف تتعامل معه عندما يحدث.

لماذا لا ينجح منع التغييرات اليدوية

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

في الممارسة العملية، يفشل هذا النهج لثلاثة أسباب.

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

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

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

النهج الأفضل ليس منع التغييرات اليدوية، بل حوكمتها.

السياسات ككود: قواعد تفرض نفسها فعليًا

معظم المؤسسات لديها سياسات بشأن تغييرات البنية التحتية. عادة ما تكون مكتوبة في مستند ما: "يجب أن تمر جميع التغييرات على الإنتاج عبر عملية إدارة التغيير". لكن المستندات لا تفرض شيئًا. إنها مجرد ملفات.

السياسات ككود (Policy as Code) تغير هذا. أدوات مثل Open Policy Agent (OPA) أو HashiCorp Sentinel تسمح لك بكتابة قواعد في كود وإرفاقها بنقاط الإنفاذ. عندما يحاول شخص ما تعديل مورد من خلال وحدة التحكم السحابية، أو عندما يأتي طلب API مباشر، يقوم محرك السياسات بتقييم الطلب مقابل قواعدك قبل السماح به.

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

على سبيل المثال، إليك سياسة HashiCorp Sentinel التي تتطلب أن يكون لكل مورد علامة managed-by، مما يضمن إمكانية تتبع التغييرات خارج خط الأنابيب:

# Require all resources to have a "managed-by" tag
import "tfplan/v2" as tfplan

# Get all resources that will be created or updated
all_resources = tfplan.resource_changes.all

# Rule: every resource must have a "managed-by" tag
mandatory_tag = "managed-by"

main = rule {
  all all_resources as _, rc {
    rc.applied.tags[mandatory_tag] else null != null
  }
}

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

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

تصميم سياسات لا تنهار تحت الضغط

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

الحل هو تصميم السياسات مع مراعاة الواقع التشغيلي.

أحد الأنماط هو آلية كسر الزجاج (Break-Glass Mechanism). في حالات الطوارئ المحددة، يمكن للمهندس تجاوز السياسة. يتم تسجيل التجاوز مع سبب، وبعد الحادث، يراجع الفريق ما إذا كان يجب اعتماد التغيير في IaC أو التراجع عنه. يمنحك هذا الأمان دون شلل.

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

ربط السياسة باكتشاف الانجراف

تعمل السياسة واكتشاف الانجراف بشكل أفضل عندما يكونان متصلين. إليك كيف يبدو التدفق في الممارسة العملية.

يعمل ماسح الانجراف الخاص بك بانتظام ويجد الاختلافات بين تعريفات IaC الخاصة بك والبنية التحتية الفعلية. بدلاً من وضع علامة على كل اختلاف كمشكلة، يتحقق النظام من كل اختلاف مقابل سياساتك.

يوضح الرسم البياني التالي كيفية تفاعل إنفاذ السياسة واكتشاف الانجراف في حلقة حوكمة مستمرة.

flowchart TD A[IaC Pipeline] -->|Deploy| B[Infrastructure] C[Manual Change] -->|Emergency or direct action| B B -->|Drift Scanner| D{Drift Detected?} D -->|Yes| E[Policy Engine] D -->|No| F[No Action] E --> G{Policy Check} G -->|Approved Exception| H[Mark as Known & Allowed] G -->|Violation| I[Flag for Remediation] G -->|No Match| J[Queue for Manual Review] H --> K[Post-Incident Review] I --> K J --> K K -->|Adopt into IaC| A K -->|Roll back| B

إذا تم التغيير من خلال استثناء سياسة معتمد، يتم وضع علامة عليه كـ "معروف ومسموح به". إذا كان التغيير ينتهك سياسة، يتم وضع علامة عليه للمعالجة الفورية. إذا كان التغيير لا يتطابق مع أي قاعدة سياسة، فإنه يذهب إلى قائمة انتظار للمراجعة اليدوية.

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

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

قائمة مراجعة عملية للحوكمة القائمة على السياسات

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

  • حدد أنواع التغييرات الأكثر خطورة في بيئتك (مجموعات الأمان، تكوينات قاعدة البيانات، أدوار IAM)
  • اكتب سياسات تمنع تلك التغييرات خارج خط الأنابيب، مع مسارات استثناء واضحة
  • قم بتنفيذ آلية كسر الزجاج لحالات الطوارئ، مع مراجعة إلزامية بعد الحادث
  • اربط محرك السياسات الخاص بك بأدوات اكتشاف الانجراف
  • صنف التغييرات حسب مستوى المخاطر وطبق قواعد مختلفة وفقًا لذلك
  • قم بإعداد تسجيل تدقيق تلقائي لكل قرار سياسة
  • راجع استثناءات السياسة بانتظام واعتمدها في IaC أو تراجع عنها

الخلاصة

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

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