في عام 2023، سمحت ثغرة في منصة سحابية واسعة الاستخدام لنقل الملفات للمهاجمين بالتنقل أفقيًا عبر بيئات العملاء، لا باختراق كل مستأجر على حدة، بل باستغلال مواطن ضعف في بنية المنصة التي تربط بينهم. وتأثرت آلاف المؤسسات. ولم يكن يجمع بينها شيء سوى أنها جميعًا وثقت بالمورّد نفسه. ولم تقيّم أي منها ما إذا كانت البنية متعددة المستأجرين لدى ذلك المورّد توفر عزلًا كافيًا بين العملاء. ولم تسأل أي منها عمّا إذا كان اختراق يصيب عميلًا آخر على المنصة نفسها قد يصل إلى بياناتها. فالسؤال لم يُطرح قط، لأن معظم المؤسسات لا تفكر في المستأجرين الآخرين الذين يتشاركون البنية التحتية لمورّدها. إلى أن تُضطر إلى ذلك.
ما مخاطر الوصول العابر للمستأجرين حقًا؟
مخاطر الوصول العابر للمستأجرين هي احتمال أن تتعرض بيانات عميل أو أعباء عمله أو بيئته داخل منصة سحابية متعددة المستأجرين للوصول أو التأثر أو الاختراق نتيجة وجود عميل آخر على المنصة نفسها، أو نتيجة مواطن ضعف في المكونات المشتركة للمنصة التي تخدم جميع المستأجرين في آن واحد. وهي فئة من المخاطر غير مرئية بنيويًا في معظم تقييمات المورّدين لأنها لا تنشأ من علاقة المورّد بك تحديدًا، بل تنشأ من بنية المورّد ومن كونك تتشارك تلك البنية مع كل من يخدمهم.
تعدد المستأجرين هو النموذج الاقتصادي الأساسي للبرمجيات السحابية. فمورّد SaaS لا يبني نسخة منفصلة من منصته لكل عميل، بل يبني منصة واحدة ويقسّمها بحيث لا يرى كل عميل سوى بياناته وتهيئته. ويمكن تنفيذ هذا التقسيم على مستويات عدة: فصل منطقي داخل قاعدة بيانات مشتركة، أو مخططات قواعد بيانات منفصلة لكل مستأجر، أو قواعد بيانات منفصلة على بنية تحتية مشتركة، أو بنية تحتية معزولة بالكامل لكل مستأجر. وتختلف الآثار الأمنية لكل نهج اختلافًا كبيرًا، ومعظم العملاء لا يعرفون أي نموذج يستخدمه مورّدوهم.
المخاطر ليست نظرية. فالفصل المنطقي، وهو النموذج الأكثر شيوعًا واقتصادًا، يعتمد كليًا على ضوابط الوصول في طبقة التطبيق لمنع أي مستأجر من رؤية بيانات مستأجر آخر. وإذا احتوت تلك الضوابط على خلل برمجي أو خطأ في التهيئة أو عيب في التصميم، يُخفق الفصل. فباحث يستعلم عن معرّف العميل الخطأ في نقطة نهاية API ضعيفة التحقق، أو أداة دعم تجمع البيانات من مستأجرين متعددين دون تحديد نطاق كافٍ، أو مهمة خلفية تعالج السجلات دون إنفاذ حدود المستأجرين: أي من ذلك قد يؤدي إلى كشف بيانات عابر للمستأجرين دون تدخل أي مهاجم. وعندما يتدخل مهاجم فعلي ويبحث عمدًا عن مواطن الضعف هذه، يصبح اكتشاف هذا الكشف واستغلاله أرجح بكثير.
تظهر المخاطر العابرة للمستأجرين عبر أنماط متمايزة عدة من الهجمات والإخفاقات:
- المراجع المباشرة غير الآمنة للكائنات: واجهات برمجة تطبيقات تقبل معرّفات المستأجرين أو الموارد دون التحقق من أن المستخدم مقدم الطلب ينتمي إلى ذلك المستأجر، مما يتيح لعميل الاستعلام عن بيانات عميل آخر
- ثغرات البنية التحتية المشتركة: عيوب في مكونات مشتركة بين جميع المستأجرين (خدمات المصادقة، وخطوط معالجة السجلات، والمعالجات الخلفية) تؤثر في كل عميل في آن واحد عند استغلالها
- تصعيد الصلاحيات عبر المستأجرين: اختراق حساب منخفض الصلاحيات على المنصة واستخدام موطئ القدم هذا لتصعيد الوصول إلى مستأجرين آخرين عبر واجهات إدارية مشتركة أو أدوات الدعم
- آثار الجار المزعج: نشاط أحد المستأجرين يستهلك الموارد المشتركة بطرق تُضعف التوافر أو تُنشئ قنوات جانبية قائمة على التوقيت بالنسبة للمستأجرين الآخرين
- الوصول لأغراض الدعم والإدارة: موظفو المورّد القادرون على الوصول إلى بيئة أي مستأجر لأغراض الدعم، مما يُنشئ طبقة وصول مشتركة تتجاوز الضوابط الأمنية لكل مستأجر
لماذا يهم هذا
تُعد المخاطر العابرة للمستأجرين من أقل أبعاد مخاطر السحابة لدى الأطراف الثالثة تقييمًا، تحديدًا لأنها غير مرئية في نموذج التقييم المعتاد. فاستبيان المورّد يسأل عن الممارسات الأمنية للمورّد: التشفير، وضوابط الوصول، وقدرات الاستجابة للحوادث. لكنه لا يسأل عن العملاء الآخرين الذين يتشاركون البنية التحتية للمورّد، ولا عن الكيفية التي قد يفتح بها اختراق أحد هؤلاء العملاء مسارًا إلى بياناتك. ومع ذلك، ففي البنية متعددة المستأجرين، يُعد كل عميل آخر على المنصة جزءًا غير مباشر من نموذج التهديدات الخاص بك.
يختلف حساب نطاق الضرر في حادث عابر للمستأجرين اختلافًا جوهريًا عن خرق موجَّه لمورّد. فعندما يُخترق مورّد عبر ثغرة في منصته المشتركة، يُحتمل أن يتأثر كل عميل على تلك المنصة في آن واحد، بغض النظر عن وضعه الأمني الفردي، أو العناية الواجبة التي بذلها عند التعاقد، أو الضوابط التي طبقها من جانبه. ولا يستطيع العميل فعل أي شيء داخل مستأجره لمنع استغلال ثغرة عابرة للمستأجرين. فالحماية تكمن بالكامل في بنية المورّد وتنفيذه، ولا يملك العميل أي سيطرة مباشرة عليهما.
يُنشئ ذلك التزامًا محددًا بالعناية الواجبة يتجاوز التقييم المعتاد للمورّدين: تقييم البنية متعددة المستأجرين لدى المورّد وآليات العزل فيها بوصفها عامل مخاطر قائمًا بذاته. فالمورّد الذي يعالج بيانات مؤسسات مستهدفة بدرجة عالية (مؤسسات مالية، ومقدمي رعاية صحية، ومتعاقدين حكوميين) إلى جانب عملاء أقل اهتمامًا بالأمن يمثل مخاطر مختلفة عن مورّد ذي قاعدة عملاء أكثر تجانسًا. فقد يؤثر تطور المهاجمين الذين يستهدفون عميلًا واحدًا على المنصة في كل عميل آخر إذا كان العزل غير كافٍ.
أين تخطئ معظم الفرق
الإخفاق الأكثر شيوعًا هو المساواة بين الفصل على مستوى الحساب والعزل الأمني. فمعظم العملاء يدركون أن لهم حسابهم الخاص وبيانات دخولهم الخاصة ومساحة بياناتهم الخاصة داخل منصة المورّد. ويفسرون ذلك بأن بياناتهم معزولة عن العملاء الآخرين. لكن ما تأكدوا منه فعليًا هو أن واجهة المستخدم في التطبيق لا تعرض لهم سوى بياناتهم في التشغيل الاعتيادي، لا أن البنية الأساسية تمنع الوصول العابر للمستأجرين في ظروف الهجوم. وهذان ادعاءان مختلفان اختلافًا جوهريًا، ومعظم المؤسسات لم تطلب قط من أي مورّد إثبات الادعاء الثاني.
الإخفاق الثاني هو عدم احتساب وصول فريق الدعم لدى المورّد عاملًا من عوامل المخاطر العابرة للمستأجرين. فكل مورّد SaaS تقريبًا يحتفظ بقدرة موظفي الدعم على الوصول إلى مستأجري العملاء، للتحقيق في المشكلات أو الرد على تذاكر الدعم أو تنفيذ عمليات إدارية. وطبقة وصول الدعم هذه قدرة مشتركة قائمة عبر جميع المستأجرين في آن واحد. وإذا كانت ضوابط الوصول الداخلية لدى المورّد لأدوات الدعم هذه غير كافية، أو إذا اختُرق حساب أحد موظفي الدعم، فلا يقتصر التعرض على مستأجر واحد، بل قد يمتد إلى قاعدة العملاء بأكملها.
- قبول عبارة «بيانات عملائنا مفصولة منطقيًا» دليلًا على عزل كافٍ دون فهم ما تعنيه من الناحية المعمارية
- عدم تقييم نموذج عزل المستأجرين لدى المورّد (منطقي، أو على مستوى المخطط، أو على مستوى قاعدة البيانات، أو على مستوى البنية التحتية) والآثار الأمنية لكل منها
- عدم السؤال عن وصول فريق الدعم لدى المورّد إلى مستأجرك تحديدًا: من يمكنه الوصول إليه، وبأي شروط، ومع أي تسجيل
- عدم اعتبار تركيبة عملاء منصة المورّد عاملًا من عوامل المخاطر: فالمنصة التي تخدم عملاء مستهدفين بدرجة عالية تحمل مخاطر عابرة للمستأجرين تختلف عن منصة تخدم شركات صغيرة ومتوسطة منخفضة المخاطر
- اعتبار المخاطر العابرة للمستأجرين شأنًا يخص مزود الخدمات السحابية لا شأنًا يخص بنية المورّد
كيف تبدو الممارسة الجيدة
تتعامل المؤسسات ذات التقييم الناضج للمخاطر العابرة للمستأجرين مع عزل المستأجرين بوصفه سؤالًا أساسيًا في العناية الواجبة تجاه المورّدين، لا أمرًا ثانويًا. فهي تدرك أن بنية المورّد لا تقل أهمية لوضعها الأمني عن سياساته، وتطرح أسئلة مصممة لكشف كيفية تنفيذ العزل فعليًا، لا مجرد ما إذا كان موجودًا.
- توثيق نموذج عزل المستأجرين في سجلات تقييم المورّد: فصل منطقي، أو على مستوى المخطط، أو على مستوى قاعدة البيانات، أو بنية تحتية مخصصة، مع فهم ما يترتب على كل منها
- تقييم ضوابط وصول فريق الدعم لدى المورّد: من لدى المورّد يمكنه الوصول إلى مستأجرك، ووفق أي إجراء تفويض، وما الذي يُسجَّل عند وصوله
- مراجعة سجل الحوادث العابرة للمستأجرين: هل تعرّض المورّد يومًا لكشف بيانات عابر للمستأجرين، وإن حدث ذلك، فكيف استجاب وما التغييرات المعمارية التي تلت ذلك
- تأكيد نطاق اختبار الاختراق: هل يشمل الاختبار الأمني لدى المورّد سيناريوهات هجوم عابرة للمستأجرين، وهل نتائجه متاحة للعملاء
- تحديد موطن البيانات وعزلها تعاقديًا: يحدد العقد كيفية تنفيذ عزل المستأجرين وسبل الانتصاف المتاحة في حال إخفاقه
الأدوات
تقييم المخاطر العابرة للمستأجرين هو في المقام الأول تقييم للبنية والحوكمة، لا مشكلة أدوات. ومع ذلك، تدعم أدوات عدة التزامات العناية الواجبة والرصد التي يفرضها على العميل.
إدارة الوضع الأمني لتطبيقات SaaS: AppOmni، وObsidian Security، وValence Security
توفر أدوات SSPM رؤية لكيفية تهيئة منصات SaaS واستخدامها داخل مستأجر العميل. وهي تكشف التكاملات ذات الصلاحيات المفرطة، ومنح الوصول المفرط إلى البيانات، وأنماط الاستخدام غير الاعتيادية التي قد تشير إلى تعرض عابر للمستأجرين. وبالنسبة لممارسي TPRM، توفر هذه الأدوات أيضًا دليلًا على الرصد الفعّال للطبقة التي يملكها العميل داخل منصات SaaS، بما يثبت أن المؤسسة لا تثق بادعاءات المورّد بشأن العزل ثقةً سلبية.
وسطاء أمن الوصول إلى السحابة: Netskope، وMicrosoft Defender for Cloud Apps، وZscaler
يوفر وسطاء أمن الوصول إلى السحابة رؤية وتحكمًا في البيانات المنتقلة من منصات SaaS وإليها، بما في ذلك اكتشاف الحالات الشاذة في أنماط الوصول إلى البيانات. وفي حادث عابر للمستأجرين، قد يكتشف CASB أحجامًا أو أنماطًا غير اعتيادية للوصول إلى البيانات قبل أن يحدد المورّد المشكلة، فيوفر إنذارًا مبكرًا وأدلة للاستجابة للحادث.
منصات تقييم أمن المورّدين: OneTrust، وProcessUnity، وVanta
تدعم هذه المنصات تقييمات منظمة لمخاطر المورّدين يمكن تهيئتها لتتضمن أسئلة خاصة بالمخاطر العابرة للمستأجرين. والأهم هو ضمان أن يتجاوز نموذج التقييم المحتوى المعتاد لاستبيانات الأمن ليشمل أسئلة خاصة بالبنية حول عزل المستأجرين وضوابط وصول فريق الدعم وسجل الحوادث العابرة للمستأجرين.
برامج مكافآت اكتشاف الثغرات والإفصاح عنها: HackerOne، وBugcrowd
المورّد الذي لديه برنامج فعّال لمكافآت اكتشاف الثغرات يشمل نطاقه سيناريوهات الهجوم العابرة للمستأجرين قد قطع التزامًا علنيًا جادًا بتحديد هذه الثغرات. ووجود مثل هذا البرنامج، وسجل المورّد في الاستجابة للملاحظات العابرة للمستأجرين ومعالجتها، مؤشر ملموس على نضج أمن البنية يتجاوز الإقرار بالسياسات.
تحديات الحوكمة
يتمثل تحدي الحوكمة في المخاطر العابرة للمستأجرين في أنها تقع خارج النموذج المعتاد لتقييم مخاطر المورّدين. فمعظم برامج TPRM تقيّم الضوابط الأمنية للمورّد كما تنطبق على بيانات العميل وعلاقته. أما المخاطر العابرة للمستأجرين فتتطلب تقييم بنية المورّد كما تنطبق على مجموع عملائه، وهو تقييم أوسع وأقل ألفة لم تُصمم معظم أطر التقييم لإجرائه.
تتمثل الإجابة العملية في إدراج تقييم المخاطر العابرة للمستأجرين في تصنيف المورّدين والعناية الواجبة بوصفه بُعدًا محددًا من أبعاد المخاطر، يُرجَّح وفق حساسية البيانات التي تجري معالجتها والتركيبة المرجحة لقاعدة عملاء المورّد. فالمورّد الذي يعالج بيانات خاضعة للتنظيم بالغة الحساسية إلى جانب عملاء كثيرين آخرين يستدعي عناية واجبة أعمق على مستوى البنية مقارنةً بمورّد يتعامل مع بيانات تشغيلية منخفضة الحساسية في نشر مخصص.
- أضف عزل المستأجرين إلى استبيان المورّدين المعتاد لديك بوصفه قسمًا إلزاميًا لأي مورّد سحابي يعالج بيانات حساسة
- اطلب تقارير اختبار الاختراق لدى المورّد مع التركيز تحديدًا على ما إذا كانت سيناريوهات الهجوم العابرة للمستأجرين مدرجة في النطاق
- راجع إفصاحات المورّد السابقة عن الحوادث بحثًا عن أي حالات كشف بيانات عابرة للمستأجرين: فكثيرًا ما يُقلَّل من شأنها في ردود الاستبيانات
- اشترط تعاقديًا الإخطار خلال إطار زمني محدد إذا علم المورّد بأي ثغرة أو حادث عابر للمستأجرين قد يكون أثّر في بياناتك
- فكّر في الاستئجار المخصص لعلاقاتك الأعلى مخاطرة مع المورّدين: فبعض المورّدين يقدمون مقابل تكلفة إضافية عزلًا على مستوى البنية التحتية يلغي مخاطر المكونات المشتركة كليًا
إذا كنت فريقًا صغيرًا
ابدأ بتحديد مورّدي SaaS الذين يعالجون بياناتك الأكثر حساسية في بيئة مشتركة متعددة المستأجرين. وبالنسبة لهؤلاء المورّدين، أضف ثلاثة أسئلة إلى محادثة التقييم القادمة: كيف يُنفَّذ عزل المستأجرين على مستوى البنية، ومن لدى المورّد يمكنه الوصول إلى مستأجرك تحديدًا وبأي شروط، وهل تعرّض المورّد يومًا لكشف بيانات عابر للمستأجرين. وستخبرك الإجابات ما إذا كانت المخاطر تُدار فعلًا أم يُفترض ببساطة أنها غير موجودة.
- راجع عقود المورّدين لديك بحثًا عن صياغة عزل البيانات: فالإشارات المبهمة إلى «الفصل المنطقي» دون تفاصيل معمارية فجوة جديرة بالمعالجة
- اسأل مورّدي SaaS الذين يتعاملون مع بياناتك الأعلى حساسية عمّا إذا كان الاستئجار المخصص متاحًا وبأي تكلفة: فهو جدير بالتقييم لعلاقاتك الأكثر أهمية
- فعّل كل ما توفره منصات SaaS لديك من سجلات تدقيق لمستأجرك: فهي لن تمنع الحوادث العابرة للمستأجرين، لكنها ستساعدك على اكتشافها والاستجابة لها
- تحقق مما إذا كانت لدى مورّدي SaaS الحرجين لديك برامج فعّالة لمكافآت اكتشاف الثغرات، وما إذا كانت الثغرات العابرة للمستأجرين ضمن نطاقها
ما الذي ينبغي اشتراطه
اسأل مباشرةً:
«كيف يُنفَّذ عزل المستأجرين في بنية منصتكم: هل هو فصل منطقي داخل قاعدة بيانات مشتركة، أم فصل على مستوى المخطط، أم قواعد بيانات منفصلة، أم بنية تحتية مخصصة لكل عميل؟»
«بأي شروط يمكن لموظفي الدعم أو الهندسة لديكم الوصول إلى مستأجرنا تحديدًا، وما التفويض المطلوب، وما الذي يُسجَّل عند وصولهم؟»
«هل تعرّضت منصتكم يومًا لكشف بيانات أو ثغرة عابرة للمستأجرين؟ وإن حدث ذلك، فما الأثر، وكيف استجبتم، وما التغييرات المعمارية التي أجريتموها؟»
ما تتوقعه دليلًا
- وصف معماري واضح لعزل المستأجرين: لا عبارة تسويقية، بل شرح تقني
- توثيق ضوابط وصول فريق الدعم، بما في ذلك متطلبات التفويض وسجلات التدقيق
- تقارير اختبار الاختراق أو ملخصاتها التنفيذية التي تؤكد اختبار السيناريوهات العابرة للمستأجرين
- التزامات تعاقدية بعزل البيانات مع سبل انتصاف محددة في حال إخفاق العزل
المورّد الذي يجيب عن سؤال العزل بعبارة «بياناتك آمنة تمامًا في حسابك» قد وصف تجربة المستخدم، لا البنية. أصرّ على الإجابة التقنية.
كيف تُثبت ذلك
تحظى المخاطر العابرة للمستأجرين باعتراف متزايد في الأطر التنظيمية بوصفها بُعدًا من أبعاد العناية الواجبة تجاه مورّدي الخدمات السحابية. وإثبات أن مؤسستك قيّمت هذه المخاطر، لا أنها قبلت تأكيدات المورّد فحسب، يتطلب أدلة موثقة على تقييم البنية، لا مجرد استكمال استبيان.
- سجلات تقييم المورّدين التي توثق نموذج عزل المستأجرين لكل منصة SaaS تعالج بيانات حساسة
- أدلة على مراجعة سجل الحوادث العابرة للمستأجرين ضمن العناية الواجبة تجاه المورّد
- بنود تعاقدية تحدد التزامات عزل المستأجرين والتزامات الإخطار بالخرق
- سجلات مراجعة نطاق اختبار الاختراق التي تؤكد إدراج السيناريوهات العابرة للمستأجرين
- توثيق القرارات في أي حالة جرى فيها تقييم الاستئجار المخصص ثم اعتماده أو رفضه مع مبررات موثقة
الخلاصة الرئيسية
كل مورّد تستخدمه في بيئة سحابية متعددة المستأجرين يربطك، بصورة غير مباشرة لكنها مؤثرة، بكل عميل آخر على تلك المنصة. ولا قيمة لوضعك الأمني داخل مستأجرك إذا كانت البنية التي تفصلك عن المستأجرين الآخرين غير كافية. فلا يمكنك سد ثغرة عابرة للمستأجرين بالتحديثات، ولا الالتفاف عليها بالتهيئة، ولا بلوغ الأمان بالتقييم دون أن تسأل تحديدًا عن كيفية عمل العزل وما إذا كان قد أخفق من قبل. والمخاطر العابرة للمستأجرين ليست أمرًا غريبًا، بل هي سمة بنيوية في كل منصة متعددة المستأجرين تعتمد عليها. والسؤال الوحيد هو ما إذا كنت قد قيّمتها.