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

يرسم نموذج المسؤولية المشتركة حدًا واضحًا: تؤمّن AWS السحابة نفسها، وأنتم تؤمّنون ما تضعونه داخل السحابة. تعلّموا هذا قبل أي شيء آخر.

تتولى AWS أمان السحابة نفسها: مراكز البيانات والأجهزة والشبكات وطبقة المحاكاة الافتراضية. لن تضطروا أبدًا إلى تحديث برنامج hypervisor أو حراسة باب مبنى.

تتولون الأمان داخل السحابة: بياناتكم وهويتكم وقواعد الشبكة وأنظمة التشغيل وشيفرة التطبيقات. إذا تركتم حاوية متاحة للعامة، فهذه مسؤوليتكم أنتم، وليست مسؤولية AWS.

يتغير الحد الفاصل باختلاف الخدمة. في EC2 تديرون نظام التشغيل الضيف، بينما تتولى AWS المزيد من المسؤوليات مع الخدمات المُدارة أو عديمة الخوادم. لكن بياناتكم وعمليات الوصول إليها تظل دائمًا مسؤوليتكم.

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

بغض النظر عن الخدمة، تملكون بياناتكم دائمًا وتحددون من يمكنه الوصول إليها. ولا تحدد AWS سياسات الحاويات أو الأذونات أو التشفير نيابةً عنكم.

من الأسئلة الخادعة الشائعة في الاختبار: من يحدّث ماذا؟ في EC2 تحدّثون نظام التشغيل الضيف، بينما تحدّث AWS المضيف وhypervisor. أما الخدمات المُدارة فتنقل قدرًا أكبر من هذه المسؤولية إلى AWS.

أنتم تورثون بعض الضوابط من AWS — مثل الضوابط المادية والبيئية، المدعومة بإفادات مثل تقارير SOC. ثم تضيفون ضوابطكم الخاصة فوقها.

توفر AWS لبنات بناء آمنة، لكن الإعدادات الآمنة الافتراضية ليست مضمونة. قد يكون التشفير متاحًا دون أن يكون مفروضًا — وتفعيله مسؤوليتكم.

تسأل أسئلة كثيرة في SCS-C02 عن الطرف المسؤول. الأجهزة أو العمود الفقري العالمي؟ هذه مسؤولية AWS. أما الإذن أو المورد العام أو نظام التشغيل غير المحدّث؟ فهذه مسؤوليتكم.

فكروا في الأمر باعتباره شراكة ذات حد فاصل واضح: توفر AWS أساسًا آمنًا وتثبت ذلك، وأنتم تبنون فوقه بأمان باستخدام الهوية والتشفير والتحديثات.

طبّقوا نموذج المسؤولية المشتركة.

تؤمّن AWS السحابة (الأجهزة ومراكز البيانات وhypervisor)، وأنتم تؤمّنون ما هو داخل السحابة (البيانات والهوية والشبكة ونظام التشغيل الضيف). وتُحسم معظم سيناريوهات تحديد المسؤولية هنا.