مأساة الأمن تُحسم في بوتقة DevOps

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

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

مأساة الأمن انعكاس لـمأساة المشاعات. من ويكيبيديا:

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

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

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

وقد ورد مثال ممتاز على ذلك في محادثة مع Chris Farris. وبإعادة صياغة كلامه،

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

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

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

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

هناك حلان محتملان.

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

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

الأمر يتعلق بالوقت وبتركيز الموارد المحدودة. وبصراحة، أيهما أكثر قيمة… اختبار اختراق جيد أم تدقيق امتثال؟ والآن انظروا كم تنفقون على اختبار الاختراق وكم تدفعون مقابل التدقيق.