ما المقصود بانحراف التكوينات؟

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

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

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

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

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

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

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

تُعَد الإصلاحات اليدوية لمرة واحدة السبب الرئيسي لانحراف التكوينات.

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

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

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

دون اختبار وإشراف مناسبين، يمكن للتحديثات والعمليات المؤتمتة أن تتسبب في انحراف موارد الشبكة المهمة عن تكويناتها المستهدفة.

تكون الأتمتة جيدة فقط بقدر جودة مصدر الحقيقة الخاص بها. على سبيل المثال، إذا اعتمدت أداة البنية التحتية ككود (IaC) على ملفات إعدادات قديمة لإنشاء خوادم جديدة، فقد يؤدي ذلك إلى تعطيل البيئة. قد تؤدي التحديثات البرمجية المؤتمتة للتطبيقات وأنظمة التشغيل مثل Microsoft Windows إلى تطبيق التحديثات في أوقات مختلفة عبر الخوادم، ما قد يسبب تباينًا ضارًا. وقد لا تتوافق هذه التحديثات مع البنية الشبكية الخاصة بالمؤسسة، ما يسبِّب مشكلات إضافية.

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

على مستوى المؤسسة، يمكن أن تؤدي المشكلات في مسار التكامل المستمر والتسليم المستمر (CI/CD) وممارسات عمليات التطوير إلى مشكلات في التكوينات.

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

ويمكن أن يؤدي غياب ممارسات واضحة ومحددة لتوثيق وإجراء التغييرات إلى سجلات تغييرات غير متسقة، وتغييرات غير مصرَّح بها، وعدم تطبيق آليات الموافقة. في النهاية، قد يتجاوز المسؤولون والمطورون والمهندسون عملية إدارة التغيير بالكامل.

يشكِّل انحراف التكوينات مخاطر كبيرة على أمان النظام والأداء وحالة الامتثال.

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

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

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

إلى جانب الأمن الإلكتروني، يُعَد أداء الشبكة من أكبر -وأكثر- المخاطر تكلفةً الناتجة عن انحراف التكوينات.

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

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

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

لنأخذ على سبيل المثال قانون إخضاع التأمين الصحي لقابلية النقل والمساءلة (HIPAA). يفرض HIPAA على المؤسسات استخدام أساليب تشفير محددة لحماية البيانات الحساسة في أثناء النقل والتخزين.

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

يتطلب اكتشاف الانحراف -أي تتبُّع التغييرات على الشبكة وتحديد الاختلافات عن حالتها المستهدفة- مزيجًا من الأدوات، بما في ذلك البنية التحتية ككود، وGitOps، والبنية التحتية غير القابلة للتغيير، وأدوات قابلية الملاحظة.

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

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

فعلى سبيل المثال، في Terraform، عند إجراء تغيير، تعمل أداة البنية التحتية ككود على مقارنة ملف الحالة (وهو أحدث عرض للشبكة على المنصة) مع ملفات التكوين المُعلنة - أي الملفات التي تحدد ما "يجب" أن تكون عليه الشبكة. ثم يعمل Terraform على معالجة الاختلافات بين ملف الحالة والتكوين المعلن من خلال تحديث البنية التحتية لتتوافق مع ملف التكوين، ما يؤدي إلى تقليل فرص تسلل الانحراف.

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

تُعَد GitOps ممارسة ضمن عمليات التطوير تستخدم مستودع Git مفتوح المصدر كمصدر الحقيقة الوحيد لملفات التكوين. وتساعد GitOps العديد من المؤسسات على نشر البنية التحتية ككود بأقصى قدر من الكفاءة والأمان.

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

تَحُدّ البنية التحتية غير القابلة للتغيير من انحراف التكوينات من خلال تقليل عدد فرص تغيير تكوين الشبكة بشكل كبير.

البنية التحتية الثابتة هي ممارسة استبدال الخوادم وموارد تكنولوجيا المعلومات الأخرى وليس تعديلها عند الحاجة إلى إجراء تغييرات.

فعلى سبيل المثال، لنفترض أن أحد الخوادم يحتاج إلى تحديث أمني. بدلًا من تطبيق التحديث على الخادم الحالي، يقوم المسؤولون بإيقاف تشغيل الخادم واستبداله بآخر جديد ومحدَّث.

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

ترتبط ممارسات البنية التحتية ككود وGitOps والبنية التحتية غير القابلة للتغيير ارتباطًا وثيقًا ببعضها. تحدد أدوات البنية التحتية ككود صور عناصر الشبكة، بينما تسهِّل GitOps عمليات النشر، وتبني سجلًا شاملًا للشبكة، وتمنع حدوث التباينات.

كما أن الركائز الثلاث لقابلية الملاحظة -السجلات والمقاييس والتتبُّعات- تؤدي دورًا في منع انحراف التكوينات.

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

يُعَد اكتشاف الانحراف ممارسة مقارنة الحالة الفعلية للشبكة بالحالة المستهدفة لاكتشاف الاختلافات. ورغم أنه يمكن نظريًا تنفيذ هذه العملية يدويًا، فإن العديد من مزوِّدي الخدمات السحابية وأدوات البنية التحتية ككود يوفرون أدوات تتضمن إمكانات لاكتشاف الانحراف، ما يساعد على أتمتة هذه العملية وتبسيطها بدلًا من كونها مشروعًا يستغرق وقتًا طويلًا.

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

ويعمل Terraform Enterprise على مقارنة الحالة الفعلية بملف الحالة، أو تحديث ملف الحالة ليعكس الوضع الفعلي، ما يؤدي إلى الكشف عن التغييرات. كما يمكن أيضًا استخدام أدوات إدارة التكوين مثل Ansible وPuppet لاكتشاف الانحراف.