نموذج المسؤولية المشتركة

من المخطئ حين ينكشف الصندوق

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

الفريق هو المخطئ. ليس لأنه أخطأ في كتابة أمر، بل لأنه تعامل مع قرار كان دائماً قراره هو وكأن المزوّد اتخذه نيابة عنه. هذه الفجوة بين ما يؤمّنه المزوّد وما يضبطه العميل هي بالضبط ما يأتي نموذج المسؤولية المشتركة ليغلقه.

أمان السحابة، والأمان داخل السحابة

تسمي AWS نصفها من التقسيم "أمان السحابة": مراكز البيانات المادية، والخوادم داخلها، والمحاكي الافتراضي (hypervisor) الذي يقسّم خادماً مادياً واحداً إلى أجهزة افتراضية متعددة، والشبكة العالمية التي تربط مناطق AWS ببعضها. أنت لا ترى شيئاً من هذا، ولا ترقّع أياً منه أبداً. تصف Azure وGoogle Cloud التقسيم نفسه لمنصتيهما، بألفاظ مختلفة لكن بالشكل نفسه.

نصفك أنت هو "الأمان داخل السحابة": كل ما تبنيه وتضبطه وتخزّنه باستخدام الخدمات التي يمنحك إياها المزوّد. يشمل ذلك دائماً بياناتك وسياسات الوصول الخاصة بك. وحسب الخدمة التي اخترتها، قد يشمل أيضاً نظام التشغيل الضيف وكود التطبيق.

الحد يتحرك مع نموذج الخدمة

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

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

مثال محلول: نفس الميزة، نموذجا خدمة

يشغّل فريق واجهة برمجية بلغة Node.js على جهاز افتراضي بنظام Ubuntu. تتولى AWS الخادم المادي والمحاكي الافتراضي والشبكة بين مناطق التوافر. يتولى الفريق ترقيع Ubuntu حين تظهر ثغرة في النواة، وضبط مجموعة الأمان بحيث لا يُفتح سوى المنفذ 443، وتدوير مفتاح SSH المستخدم لتسجيل الدخول. هذه IaaS: ثقيلة على جانب العميل من الجدول.

يعيد الفريق نفسه بناء ميزة الرفع كصندوق S3 مع دالة Lambda تُصغّر الصور فور وصولها. تتولى AWS الآن ترقيع نظام التشغيل وبيئة التشغيل لبيئة تنفيذ Lambda بالكامل؛ لا يوجد خادم يرقّعه الفريق أصلاً. ما يبقى له: سياسة وصول صندوق S3، ودور IAM الذي تتخذه الدالة وما يُسمح له بلمسه، وما إذا كانت الملفات المخزّنة مشفّرة. الانتقال من IaaS إلى خدمة PaaS شبه بلا خادم أزال صفاً كاملاً من جانب العميل في الجدول. لم يُزل الصف الأول.

ما لا يعبر الخط أبداً

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

الالتباس: شهادة لم تكسبها

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

إشارات الامتحان: قراءة سؤال المسؤولية المشتركة

الفخ الذي عليك الانتباه إليه: سؤال يذكر خدمة مُدارة أو بلا خادم ويتوقع منك افتراض أن المزوّد يملك كل شيء الآن. يملك أكثر مما كان يملكه في IaaS، لكن البيانات والهوية لا تنتقلان أبداً.

إلى أين يقودك هذا

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