تطورت البيئة التقنية لدى مورّد لإدارة بيانات الرعاية الصحية على مدى ثلاث سنوات من نشر أحادي في المقر إلى بيئة هجينة تضم شبكة مؤسسية، وبيئة بنية تحتية على AWS، وخوادم Windows لأعباء العمل القديمة، ومجموعة Kubernetes يشغّلها مزود DevOps مُدار لتطبيق بوابة المرضى. وتطور الرصد الأمني لدى المورّد بالتوازي مع البنية التحتية: أمن نقاط النهاية على خوادم Windows، والرصد الأمني لـAWS في SIEM لديه، ورصد الشبكة على الشبكة المؤسسية. لكن مجموعة Kubernetes كانت منطقة رمادية. فقد تضمنت اتفاقية الخدمة مع مزود DevOps المُدار رصد سلامة المجموعة وأدائها. أما الرصد الأمني للمجموعة، وتحديدًا الأمن أثناء التشغيل وإنفاذ سياسات الشبكة وإدارة الثغرات في صور الحاويات، فقد نوقش أثناء التعاقد لكنه لم يُسند رسميًا إلى أي من الطرفين. واعتقد الفريق الأمني لدى المورّد أن رصد مزود DevOps يشمل الأمن إلى جانب الأداء. وفهم فريق مزود DevOps نطاقه على أنه رصد تشغيلي لا رصد أمني. وعندما استُغلت ثغرة هروب من الحاوية في إحدى حاويات تطبيق البوابة أثناء اختبار اختراق كلّف به المورّد، تمكن مختبِر الاختراق من الانتقال من حاوية مخترقة إلى عقدة Kubernetes الأساسية دون أن يولّد تنبيهًا أمنيًا في أي منصة رصد. فلم يكن SIEM لدى المورّد يغطي المجموعة. ولم يتضمن رصد مزود DevOps تنبيهات الأمن أثناء التشغيل. وكانت الفجوة قائمة منذ نشر المجموعة.
ما مشكلة الرؤية عبر المنصات حقًا؟
فجوات الرؤية عبر المنصات هي النقاط العمياء في الرصد الأمني التي توجد عند نقاط الالتقاء بين المنصات التقنية المختلفة والخدمات المُدارة والمشغّلين من الأطراف الثالثة، وتحديدًا الأنظمة والبيئات التي تكون فيها حدود مسؤولية الرصد بين طرفين غامضة، أو مفترضة لا مؤكدة، أو مستبعدة صراحةً من نطاق أحد الطرفين دون أن تُدرج صراحةً في نطاق الآخر. وليست هذه الفجوات إخفاقات تقنية في أي منصة رصد بعينها، بل هي إخفاقات حوكمة في تحديد الطرف المسؤول عن رصد كل نظام.
تمثل مشكلة افتراض المسؤولية الآلية التشغيلية للفجوة. ففي البيئات التقنية المعقدة التي يتعدد فيها مزودو الخدمات المُدارة والمشغّلون من الأطراف الثالثة، كثيرًا ما يُفترض نطاق الرصد بدلًا من تحديده تعاقديًا. فالمورّد يفترض أن مزود DevOps يرصد أمن المجموعة. ومزود DevOps يفترض أن الفريق الأمني لدى المورّد يرصد الجوانب الأمنية. والافتراض معقول من منظور كل طرف، إذ يعتقد كلٌّ منهما أن الآخر قد قبل المسؤولية. ولا يتحقق أي منهما من هذا الافتراض. فيبقى الرصد الأمني لمجموعة Kubernetes غير مُسند فعليًا إلى أحد.
تمثل مشكلة غموض نطاق الخدمة المُدارة إخفاق الحوكمة المحدد. فاتفاقيات الخدمات المُدارة كثيرًا ما تحدد نطاق الرصد بمصطلحات تشغيلية (سلامة المجموعة، والأداء، والتوافر) دون أن تتناول الرصد الأمني صراحةً. والانتقال من الرصد التشغيلي إلى الرصد الأمني تمييز جوهري في النطاق يتطلب معالجة صريحة في اتفاقية الخدمة. ودون تلك المعالجة الصريحة، يعود كل طرف إلى تفسيره الطبيعي: يفترض العميل أن الأمن مشمول بالرصد، ويفترض مزود الخدمة المُدارة أن الأمن من مسؤولية العميل.
- فجوة مسؤولية الرصد: كل طرف يفترض أن الطرف الآخر يغطي أمن مجموعة Kubernetes
- اتفاقية خدمة مُدارة تحدد الرصد التشغيلي دون أن تتناول الأمن صراحةً
- قائمة تغطية غير مكتملة: مجموعة Kubernetes غير مشمولة في النطاق الأمني المؤكد للمورّد أو لمزود DevOps
- الهروب من الحاوية والوصول إلى العقدة لا يولّدان أي تنبيه في أي منصة رصد
- افتراض نطاق الرصد بدلًا من تأكيده عند حدود الخدمة المُدارة
لماذا يهم هذا
تكتسب الرؤية عبر المنصات أهمية في TPRM لأن البيئات التقنية المعقدة لدى المورّدين، بما فيها من خدمات مُدارة متعددة ومشغّلين من أطراف ثالثة وبنية تحتية هجينة، تُنشئ فرصًا لفجوات الرصد عند كل نقطة التقاء بين الأطراف. فالمورّد الذي أكد رصده الأمني تغطية نقاط النهاية والسحابة والشبكة قد تكون لديه بوابة للمرضى على مجموعة Kubernetes لا يغطيها أي من برامج الرصد الثلاثة تلك، ولم يؤكد المورّد ولا مزود DevOps لديه مسؤوليته عن رصدها الأمني.
أين تخطئ معظم الفرق
الإخفاق الأكثر تكرارًا هو قبول تأكيدات الرصد حسب الفئات (أمن نقاط النهاية مؤكد، وأمن السحابة مؤكد، وأمن الشبكة مؤكد) دون السؤال عمّا إذا كانت هناك مكونات تقنية لا تشملها أي من تلك الفئات. وتوجد الفجوة عادةً في الخدمات المُدارة والمكونات التي تشغّلها أطراف ثالثة.
- تأكيد التغطية حسب الفئات دون قائمة بما هو مغطى وما هو غير مغطى
- عدم تقييم نطاق الرصد الأمني للخدمة المُدارة
- عدم تقييم أمن Kubernetes والحاويات تحديدًا
- عدم التحقق من رصد المكونات التي تشغّلها أطراف ثالثة
- تأكيد مسؤولية الرصد لكل مكوّن بدلًا من افتراضها
كيف تبدو الممارسة الجيدة
تحتفظ برامج الرؤية عبر المنصات الناضجة بقائمة كاملة بالمكونات التقنية مرتبطة بمسؤولية رصد مؤكدة، بما يضمن أن يكون لكل نظام وخدمة ومكوّن جهة رصد محددة، لا فجوة يملؤها الافتراض.
- قائمة المكونات التقنية: ربط جميع الأنظمة بجهة رصد مؤكدة
- تحديد نطاق الرصد الأمني للخدمة المُدارة صراحةً في الاتفاقيات
- الرصد الأمني للحاويات وKubernetes: الأمن أثناء التشغيل مؤكد، لا مفترض
- تأكيد مسؤولية الرصد: تأكيد الجهة المسؤولة عن كل مكوّن صراحةً، لا افتراضها
- مراجعة تحديد الفجوات: مراجعة سنوية تحدد المكونات التي لا يوجد تأكيد لرصدها
الأدوات
أمن الحاويات: Falco، وSysdig، وAqua Security لأمن Kubernetes أثناء التشغيل
ترصد منصات أمن Kubernetes أثناء التشغيل سلوك الحاويات وإنفاذ سياسات الشبكة والوصول على مستوى العُقد في الوقت الفعلي، وهو الرصد الأمني الذي لا توفره منصات رصد DevOps التشغيلية. وبالنسبة لممارسي TPRM، فإن السؤال عمّا إذا كانت بيئات Kubernetes لدى المورّد تخضع لرصد أمني أثناء التشغيل، وتحديدًا اكتشاف الهروب من الحاويات والوصول إلى العُقد، يمثل سؤالًا محددًا عن التغطية عبر المنصات.
تحديات الحوكمة
يتمثل تحدي الحوكمة في الرصد عبر المنصات في اشتراط الوضوح في عقود الخدمات المُدارة. إذ يجب تحديد نطاق الرصد صراحةً لكل مكوّن في اتفاقيات الخدمات المُدارة، فالرصد التشغيلي والرصد الأمني نطاقان منفصلان يتطلب كلٌّ منهما معالجة صريحة مستقلة. ويتمثل حل الحوكمة في اشتراط تحديد نطاق الرصد في جميع اتفاقيات الخدمات المُدارة، مع مراجعة لقائمة التغطية لتحديد الفجوات.
- اشترط تحديد نطاق الرصد الأمني صراحةً في جميع اتفاقيات الخدمات المُدارة
- احتفظ بقائمة رصد المكونات التقنية: جميع المكونات، مع جهة مسؤولة مؤكدة
- انشر أمن Kubernetes أثناء التشغيل لبيئات الحاويات
- مراجعة سنوية لفجوات التغطية: تحديد المكونات التي لا يوجد تأكيد لرصدها
- تأكد من النطاق الأمني للخدمة المُدارة، ولا تفترض أنه يطابق النطاق التشغيلي
إذا كنت فريقًا صغيرًا
بالنسبة للمورّد الأعلى مخاطرة لديك، اطلب قائمة رصد المكونات التقنية لديه، أي قائمة بمكوناته التقنية الرئيسية والجهة المؤكدة المسؤولة عن رصد كل منها. وإذا لم تكن لديه مثل هذه القائمة، فاسأله تحديدًا: هل تغطي رقابتكم الأمنية بيئات Kubernetes أو الحاويات لديكم، وإذا وقع هروب من حاوية في تلك البيئة، فهل سيصدر تنبيه في SIEM لديكم؟ يكشف هذان السؤالان ما إذا كانت فجوة الرؤية عبر المنصات قائمة في البيئة الأكثر عرضة لأن تكون غير مرصودة.
- اطلب قائمة رصد المكونات التقنية
- اسأل تحديدًا عمّا إذا كانت بيئات Kubernetes والحاويات تخضع لرصد أمني أثناء التشغيل
- اسأل عمّا إذا كان الهروب من الحاوية سيولّد تنبيهًا في SIEM
- اسأل عن نطاق الرصد الأمني للخدمات المُدارة في العقود
ما الذي ينبغي اشتراطه
اسأل مباشرةً:
«بالنسبة لبيئات Kubernetes والحاويات لديكم، هل لديكم رصد أمني أثناء التشغيل يكشف الهروب من الحاويات والوصول على مستوى العُقد، وهل أُسند هذا الرصد الأمني صراحةً في اتفاقية الخدمة إلى فريقكم أو إلى فريق مزود DevOps المُدار لديكم؟»
ما تتوقعه دليلًا
- تأكيد الرصد الأمني لـKubernetes أثناء التشغيل
- القدرة على اكتشاف الهروب من الحاويات
- نطاق الرصد الأمني للخدمة المُدارة في الاتفاقية
- قائمة رصد المكونات التقنية
ينبغي سؤال المورّد الذي يؤكد تغطية نقاط النهاية والسحابة والشبكة عن الرصد الأمني للحاويات وKubernetes تحديدًا. فالفئات المؤكدة تغطي المكونات المؤكدة. أما مجموعة Kubernetes التي تستضيف بيانات العملاء فتتطلب تأكيدًا خاصًا بها.
كيف تُثبت ذلك
- قائمة رصد المكونات التقنية
- سجلات الرصد الأمني لـKubernetes أثناء التشغيل
- توثيق نطاق الرصد الأمني للخدمة المُدارة
- سجلات مراجعة فجوات التغطية
الخلاصة الرئيسية
المورّد يرصد AWS. ومزود DevOps يرصد المجموعة تشغيليًا. ولا أحد منهما يرصد أمن المجموعة. وبوابة المرضى على المجموعة. ومن اكتشف الهروب من الحاوية؟ لا أحد. لم تنشأ الفجوة بسبب قيد تقني، بل لأن أحدًا لم يُسند مسؤولية الرصد صراحةً ولم يتأكد من هذا الإسناد. الافتراض ليس رصدًا. أما قائمة المكونات التقنية مع جهة رصد مؤكدة فهي الرصد. اشترط القائمة. وتأكد من المسؤولية. وحدد النطاق الأمني صراحةً في اتفاقيات الخدمات المُدارة. فالفجوة توجد في المساحة بين طرفين يعتقد كلٌّ منهما أن الآخر هو المسؤول.