تنشأ مخاطر سلسلة توريد البنية التحتية بوصفها شفرة عندما تُستمد تعريفات البنية التحتية، كوحدات Terraform ومخططات Helm وأدوار Ansible ومشغّلات Kubernetes، من السجلات العامة أو المستودعات المجتمعية وتُدمج في أتمتة البنية التحتية للمؤسسة دون التدقيق الأمني ذاته الذي يُطبق على اعتماديات شفرة التطبيقات. فـTerraform Registry وHelm Hub وAnsible Galaxy والمستودعات المجتمعية المماثلة توفر ما يعادل npm أو PyPI في أتمتة البنية التحتية، أي مجموعات كبيرة من الوحدات التي يساهم بها المجتمع وكثيرًا ما تُستخدم كما هي، دون مراجعة انعكاساتها الأمنية أو حالة صيانتها.
مشكلة الثقة في الوحدات المصدرية هي الإخفاق المحدد في سلسلة توريد IaC. فعندما تستدعي شفرة البنية التحتية وحدة تابعة لطرف ثالث، مثل terraform-aws-modules/security-group، تُنفَّذ شفرة الوحدة ببيانات اعتماد أتمتة البنية التحتية وتحدد إعدادات البنية التحتية الناتجة. فالوحدة سيئة الإعداد أو المتقادمة تنتج بنية تحتية سيئة الإعداد. والوحدة الخبيثة، وهي ما يعادل في IaC الحزمة المنتحلة بأخطاء الكتابة، قد تنتج بنية تحتية مصممة خصيصًا لتكون قابلة للاستغلال أو لتسريب بيانات الإعدادات. ومهندس البنية التحتية الذي يراجع شفرة Terraform الخاصة به لا يراجع الوحدة المصدرية التي تستدعيها شفرته.
لماذا يهم هذا
تكتسب مخاطر سلسلة توريد IaC أهميتها بالنسبة إلى TPRM لأن الموردين الذين يستخدمون أتمتة البنية التحتية، وهو ما يتزايد ليصبح القاعدة في البيئات السحابية الأصيلة، يبنون بنيتهم التحتية على سلاسل اعتماديات تشمل وحدات من السجلات العامة. ولا يعتمد أمن تلك البنية التحتية على ممارسات المورد في مراجعة شفرة بنيته التحتية فحسب، بل على أمن الوحدات المصدرية التي تعتمد عليها أتمتته ومدى تحديثها. فالمورد الذي يملك عمليات صارمة لمراجعة IaC ويستخدم وحدات متقادمة تابعة لأطراف ثالثة يبني على أساس لم تفحصه مراجعته.
- تقييم أمن IaC دون مراجعة الوحدات المصدرية
- عدم تتبّع مدى تحديث وحدات الأطراف الثالثة: وحدات متقادمة بإعدادات قديمة
- عدم تقييم مصدر الوحدات والقائمين على صيانتها: استخدام الوحدات المجتمعية كما هي
- غياب الرؤية على سلسلة توريد IaC: التعامل مع الوحدات على أنها موثوقة دون تحقق
- سوء إعداد البنية التحتية بسبب وحدات خارج نطاق فحص أمن IaC
كيف تبدو الممارسة الجيدة
تُثبّت برامج سلسلة توريد IaC الناضجة إصدارات الوحدات، وتفحص وحدات الأطراف الثالثة بحثًا عن المشكلات الأمنية باستخدام أدوات فحص IaC، وتقيّم سلامة القائمين على صيانة الوحدات ومدى نشاطهم، وتطبق على وحدات البنية التحتية التدقيق ذاته في أمن سلسلة التوريد المطبق على اعتماديات التطبيقات.
- تثبيت إصدارات الوحدات: إصدارات محددة بدلًا من الإشارات العائمة
- فحص أمن IaC بما يشمل محتوى وحدات الأطراف الثالثة
- تقييم سلامة القائمين على صيانة الوحدات: مدى التحديث ونشاط الصيانة
- مراجعة شفرة الوحدات المعتمدة حديثًا
- سجل داخلي للوحدات: وحدات مدققة متاحة داخليًا بدلًا من الاستهلاك المباشر من السجلات العامة
الأدوات
أمن IaC: Checkov وtfsec وKICS لفحص أمن البنية التحتية بوصفها شفرة بما في ذلك وحدات الأطراف الثالثة
تحلل أدوات فحص أمن IaC ملفات Terraform وCloudFormation وبيانات Kubernetes وغيرها من صيغ IaC بحثًا عن أخطاء الإعداد الأمنية، بما في ذلك في وحدات الأطراف الثالثة المُدرجة بوصفها مصادر. ويستطيع Checkov وtfsec فحص محتوى الوحدات الموسّع لتحديد أخطاء الإعداد في شفرة الوحدات المصدرية. وبالنسبة لممارسي TPRM، فإن السؤال عمّا إذا كان الموردون يُجرون فحص أمن IaC على التعريف الكامل لبنيتهم التحتية بما في ذلك محتوى وحدات الأطراف الثالثة يطرح سؤالًا محددًا حول سلسلة توريد IaC.
تحديات الحوكمة
يتمثل تحدي الحوكمة في مخاطر سلسلة توريد IaC في تعقيد تحديث الوحدات. فكما هو الحال في اعتماديات التطبيقات، قد تؤدي تحديثات وحدات IaC إلى تعطيل البنية التحتية، إذ قد يتطلب تحديث وحدة يغيّر قواعد تسمية الموارد استبدال البنية التحتية بدلًا من تحديثها. ويكمن حل الحوكمة في تثبيت إصدارات الوحدات مع مراجعة أمنية دورية لكل إصدار مُثبَّت، بدلًا من الإشارات العائمة إلى الوحدات التي تلتقط التحديثات تلقائيًا.
- تثبيت إصدارات الوحدات في IaC: إشارات إلى إصدارات محددة
- تشغيل أدوات فحص IaC على التعريف الكامل للبنية التحتية بما في ذلك محتوى الوحدات
- تقييم مدى تحديث صيانة الوحدات لدى القائمين عليها لجميع الوحدات المستخدمة في بيئة الإنتاج
- الاحتفاظ بسجل داخلي للوحدات المعتمدة بعد التدقيق للبيئات عالية الأمان
- إدراج سلسلة توريد وحدات IaC في تقييم أمن البنية التحتية لدى المورد
إذا كنت فريقًا صغيرًا
شغّل Checkov أو tfsec على شفرة Terraform الخاصة بك أو بمورّدك مع تضمين المحتوى الكامل للوحدات. إذ تستطيع هذه الأدوات فحص شفرة الوحدات الموسّعة، لا مجرد غلاف Terraform الذي يستدعيها. والنتائج المستخلصة من محتوى الوحدات هي مخاطر سلسلة توريد IaC التي تفوتها مراجعة شفرة الغلاف وحدها. واسأل مورّدك عمّا إذا كان فحص IaC لديه يغطي المحتوى الكامل للوحدات أم شفرته الخاصة فقط.
- تشغيل Checkov أو tfsec مع التوسيع الكامل للوحدات على IaC
- مراجعة النتائج المستخلصة من محتوى وحدات الأطراف الثالثة
- سؤال المورد عمّا إذا كان فحص IaC يشمل محتوى الوحدات
- تقييم تثبيت إصدارات الوحدات ومدى نشاط القائمين على صيانتها
ما الذي ينبغي اشتراطه
اسأل مباشرةً:
«هل يغطي فحص أمن البنية التحتية بوصفها شفرة لديكم المحتوى الكامل لوحدات الأطراف الثالثة التي تستخدمها الأتمتة لديكم، لا شفرتكم الخاصة فحسب، وهل إشاراتكم إلى وحدات Terraform مثبتة على إصدارات محددة مع مراجعة أمنية دورية؟»
ما تتوقعه دليلًا
- تغطية فحص IaC بما يشمل محتوى الوحدات
- تطبيق تثبيت إصدارات الوحدات
- تقييم مدى نشاط القائمين على صيانة الوحدات
- سجل داخلي للوحدات المعتمدة بعد التدقيق أو ما يعادله
ينبغي سؤال المورد الذي يؤكد اتباع ممارسات أمن IaC عن تغطية سلسلة توريد الوحدات. ففحص أمن IaC لشفرته الخاصة يؤكد سلامة الغلاف فقط، أما الفحص الكامل لمحتوى الوحدات فيغطي سلسلة التوريد.
كيف تُثبت ذلك
- فحص IaC مع تغطية كاملة للوحدات
- سجلات تثبيت إصدارات الوحدات
- تقييم سلامة القائمين على صيانة الوحدات
- مخاطر سلسلة توريد وحدات IaC في تقييم الموردين
الخلاصة الرئيسية
IaC: تمت المراجعة. وحدة Terraform تابعة لطرف ثالث: متقادمة منذ 14 شهرًا، ومنافذ الإدارة مفتوحة على 0.0.0.0/0. مراجعة شفرة البنية التحتية: مكتملة. مراجعة شفرة الوحدة: لم تُجرَ. سلسلة توريد IaC لها نموذج التهديد ذاته الذي لسلسلة توريد اعتماديات التطبيقات، أي شفرة تابعة لطرف ثالث تُنفَّذ ببيانات اعتماد بمستوى بيئة الإنتاج وتُعِدّ البنية التحتية للإنتاج أو تنشرها. يتحكم تثبيت إصدارات الوحدات في الإصدار المستخدم، ويحدد فحص IaC مع التوسيع الكامل للوحدات ما يفعله ذلك الإصدار، ويحدد تقييم سلامة القائمين على الصيانة ما إذا كان من المرجح تحديث الإصدار إذا اكتُشفت ثغرة.