شركة كابيتال ون تجعل بيانات السحابة الوصفية اختبارًا لعدم تطابق العقد والتحكم في المساءلة

ملخص

• أصبح اختراق شركة Capital One لعام 2019 حالة من عدم تطابق العقد والتحكم لأن لغة المسؤولية المشتركة للسحابة نصت على أن العملاء يتحكمون في التكوين والهوية، بينما كان على السجلات العامة إظهار من يمكنه عمليًا منع واكتشاف وإصلاح مسار الوصول المحدد للبيانات الوصفية.
• يوضح البيان الصحفي والأسئلة المتكررة المقدمان من Capital One إلى هيئة الأوراق المالية والبورصات (SEC)البيان الصحفي والأسئلة المتكررة، وصفحة معلومات الحادث الخاصة بالشركةصفحة معلومات الحادث، وصفحة الحادث الكنديةصفحة الحادث، إشعار الشركة والفئات السكانية المتأثرة وفئات البيانات وموقف الاستجابة.
• تدعم سجلات وزارة العدل، بما في ذلك صفحة القضيةصفحة القضية، ولائحة الاتهام البديلةلائحة الاتهام البديلة، وإعلان الإدانةإعلان الإدانة، وإعلان الحكمإعلان الحكم، سجل القضية الجنائية مع الحفاظ على التمييز بين الادعاءات والنتائج المقضية.
• تُظهر إجراءات مكتب مراقب العملة (OCC) والاحتياطي الفيدرالي، بما في ذلك إعلان العقوبة من OCCإعلان العقوبة، وأمر العقوبة المدنيةأمر العقوبة المدنية، وأمر الكف والامتناعأمر الكف والامتناع، وأمر الإنفاذ الصادر عن الاحتياطي الفيدراليأمر الإنفاذ، أن مساءلة الهيئات التنظيمية ركزت على إدارة مخاطر السحابة، وجرد الضوابط، والاختبار، والتدقيق، ورقابة مجلس الإدارة.
• سؤال الإصلاح ليس ما إذا كان موفر السحابة أو البنك يمكنه الاستشهاد بنموذج المسؤولية. بل هو ما إذا كانت التكوينات، والوصول إلى البيانات الوصفية، ونطاق IAM، والمراقبة، وتصريف التنبيهات، وإشعار العملاء، وأدلة مجلس الإدارة تتطابق مع مسار التحكم الفعلي الذي استخدمه المهاجمون.

المسؤولية المشتركة ليست سجلاً واقعياً

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

وصف البيان الصحفي والأسئلة المتكررة المقدم من Capital One إلى هيئة الأوراق المالية والبورصات في يوليو 2019البيان الصحفي والأسئلة المتكررةوصولاً غير مصرح به من قبل فرد خارجي استغل ثغرة في التكوين وحصل على معلومات شخصية معينة تتعلق بطلبات بطاقات الائتمان والعملاء. ذكرت الشركة أنه لم يتم اختراق أرقام حسابات بطاقات الائتمان أو بيانات تسجيل الدخول وأن أكثر من 99 بالمائة من أرقام الضمان الاجتماعي لم يتم اختراقها. قدمت صفحة الحادث المحفوظة لـ Capital Oneصفحة حادث Capital Oneوصفحة الحادث السيبراني الكندية لعام 2019صفحة الحادث السيبراني 2019لاحقاً معلومات محدثة خاصة بكل بلد.

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

يمكن أن تصبح المسؤولية المشتركة أحياناً شعاراً. يمكن استخدامها من قبل العملاء ليقولوا "الموفر آمن" أو من قبل الموفرين ليقولوا "تكوين العميل هو المشكلة". لا يكفي أي من الاختصارين. السؤال المفيد هو خاص بالتحكم: أي طرف كانت لديه القدرة العملية على منع مسار الطلب ذي الصلة، وتقييد استخدام بيانات اعتماد البيانات الوصفية، وتقليل الأذونات، وكشف السلوك غير الطبيعي، وإيقاف نسخ البيانات؟

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

مسار البيانات الوصفية حوّل تفاصيل البنية التحتية إلى تعرض للعميل

يشرح منشور AWS حولالدفاع في العمق باستخدام خدمة بيانات تعريف مثيل EC2 الإصدار 2خدمة بيانات تعريف المثيل، وبيانات اعتماد الدور، والوصول على مستوى الرابط، وتصميم رمز الجلسة، وطريقة PUT، والتفكير في الدفاع في العمق وراء IMDSv2. أعلنت AWS أيضاً عنتحديثات لخدمة بيانات تعريف مثيل Amazon EC2في نوفمبر 2019 ووصفت لاحقاًIMDSv2 بشكل افتراضيفي عام 2023. هذه السجلات من الموفر هي سياق تحكم بعد الاختراق، وليست اعترافات بشأن Capital One.

تعتبر قضية خدمة البيانات الوصفية مهمة لأن بيانات اعتماد الدور تهدف إلى السماح للتطبيقات بالوصول إلى موارد السحابة دون تضمين أسرار طويلة الأجل. هذا التصميم قوي ومفيد بشكل عام. لكن إذا سمح مسار التطبيق للمهاجم بالوصول إلى نقطة نهاية البيانات الوصفية واسترداد بيانات الاعتماد، يصبح نطاق الدور المرفق حاسماً. تشرح وثائق AWS حولتكوين خدمة بيانات تعريف المثيلوأدوار IAM لـ Amazon EC2نموذج التحكم الحالي.

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

تُؤكد أفضل ممارسات AWS IAMأفضل الممارساتعلى مبدأ الامتياز الأقل وانضباط بيانات الاعتماد في الإرشادات الحالية. مرة أخرى، الإرشادات الحالية ليست إعادة بناء لكل إعدادات عام 2019. إنها مفيدة لأنها تؤطر سؤال الإصلاح. بعد اختراق مسار البيانات الوصفية، يجب على المؤسسات أن تسأل ما إذا كانت أذونات الدور أضيق من حاجة التطبيق، وما إذا كان التخزين الحساس يتطلب شروطاً إضافية، وما إذا كان الوصول إلى البيانات الوصفية مقيداً، وما إذا كان استخدام بيانات الاعتماد غير الطبيعي سينبه بسرعة.

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

الحكم الجنائي والمساءلة المدنية هما سجلان مختلفان

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

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

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

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

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

ركزت الهيئات التنظيمية على حوكمة السحابة، وليس الشعارات

أعلن مكتب مراقب العملة عن عقوبة مدنية بقيمة 80 مليون دولار ضد Capital One فيNR 2020-101. يحتوي أمر العقوبة المدنية الموقع من OCCأمر العقوبة المدنيةعلى نتائج بشأن الانتقال إلى السحابة في عام 2015، وتقييم المخاطر، ونقاط الضعف في الضوابط، ومنع فقدان البيانات، وتصريف التنبيهات، والتدقيق الداخلي، ومساءلة مجلس الإدارة، والعقوبة، مع الحفاظ على أن Capital One لم تعترف أو تنكر نتائج المراقب. طلب أمر الكف والامتناع من OCCأمر الكف والامتناعإجراءات تصحيحية حول مخاطر السحابة، وجرد الضوابط، والاختبار، وإعداد التقارير، والتدقيق، ورقابة مجلس الإدارة.

تناول إعلان الإنفاذ الصادر عن الاحتياطي الفيدراليإعلان الإنفاذوأمر الكف والامتناع المرفقأمر الكف والامتناعإشراف الشركة القابضة وتخطيط الامتثال. أعلن OCC لاحقاً إنهاء أمر الكف والامتناع لعام 2020 في إصدار إنفاذ في أغسطس 2022إصدار إنفاذ. الإنهاء مهم، لكنه لا يمحو العقوبة التاريخية أو يعيد كتابة سجل 2020.

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

يوفر بيان FFIEC حولإدارة المخاطر لخدمات الحوسبة السحابيةالسياق الإشرافي الأوسع. يُؤكد أن المؤسسات المالية تظل مسؤولة عن إدارة المخاطر الفعالة عند استخدام الخدمات السحابية. البيان عام وليس نتيجة خاصة بـ Capital One. لكنه لا يزال يلتقط موقف الهيئة التنظيمية: لا تفترض أن ضوابط السحابة فعالة افتراضياً؛ افهم الهندسة والوصول والمراقبة والمرونة ومخاطر الطرف الثالث.

سجل الهيئة التنظيمية هو الإجابة الأوضح على عدم تطابق العقد والتحكم. يمكن لنموذج المسؤولية المشتركة تخصيص الفئات، لكن الهيئات التنظيمية تريد دليلاً. أي الضوابط كانت موجودة؟ هل تم اختبارها؟ هل تم التعامل مع التنبيهات بشكل صحيح؟ هل حدد التدقيق الثغرات؟ هل أشرف مجلس الإدارة على التصحيح؟ هل تم تقييم مخاطر الانتقال إلى السحابة قبل تشغيل النظام؟ هذه أسئلة أدلة.

ملاحظة حول الطباعة

حوّل إشعار العميل الهندسة المعمارية إلى مخاطر شخصية

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

أعلن مكتب مفوض الخصوصية في كندا أنه أطلق تحقيقاً في إشعار يوليو 2019،OPC يطلق تحقيقاً في Capital One، وأشار إلى ستة ملايين كندي متأثر وبعض أرقام التأمين الاجتماعي. إعلان الهيئة التنظيمية هذا ليس نتيجة نهائية، لكنه يظهر البعد العام العابر للحدود. يمكن أن يؤثر اختراق تطبيق سحابي على أشخاص في أكثر من ولاية قضائية حتى لو تم وصف المسار التقني في شروط خدمة موفر واحد.

إشعار العميل مهم لأن الأفراد لا يختبرون "الوصول إلى خدمة البيانات الوصفية". إنهم يختبرون عدم اليقين بشأن طلبات الائتمان، وبيانات الهوية، والتفاصيل المصرفية، والاحتيال، ومراقبة الائتمان، والوقت الذي يقضونه في الاستجابة. يصبح المسار التقني عبئاً شخصياً فقط عندما تترجمه المؤسسة إلى فئات بيانات وخطوات حماية. إذا كانت هذه الترجمة غامضة أو متأخرة، يتحمل العملاء عدم اليقين.

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

يُظهر سجل التسوية الذيل الطويل لمعالجة العملاء. وافق أمر الموافقة النهائيةأمر الموافقة النهائيةعلى صندوق تسوية وخدمات. موافقة التسوية لا تقرر كل ادعاء. لكنها تُظهر أن استجابة العملاء استمرت لسنوات بعد الإعلان الأولي عن الاختراق. أصبح فشل الهندسة برنامجاً قانونياً لمعالجة المستهلك.

كان على أدلة مجلس الإدارة أن تصبح تقنية بما يكفي

وصف النموذج 10-K لشركة Capital One لعام 2019النموذج 10-Kتكاليف الاستجابة للحادث، واستردادات التأمين، والإفصاحات عن المخاطر، والتقاضي، والمعالجة. وصف بيان التوكيل الخاص بالشركة لعام 2020بيان التوكيلإشعار مجلس الإدارة، واجتماعات اللجان، والخبراء الخارجيين، وحوكمة الأمن السيبراني المعززة، وإبلاغ مسؤول أمن المعلومات، ورقابة مجلس الإدارة. هذه إفصاحات من الشركة، وليست دليلاً مستقلاً على فعالية الضوابط، لكنها تُظهر كيف انتقل الحادث إلى الحوكمة.

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

تُشير أوامر OCC إلى هذه النقطة بشكل غير مباشر من خلال التركيز على تقييم المخاطر، وجرد الضوابط، والاختبار، والتدقيق، وإعداد التقارير لمجلس الإدارة. لا يمكن لمجلس الإدارة الإشراف على ما لا تستطيع الإدارة قياسه. إذا لم تتمكن المؤسسة من إظهار أي ضوابط سحابية تحمي أي بيانات حساسة، تصبح الرقابة ضماناً عاماً. بعد Capital One، لم يكن الضمان العام كافياً.

يجب أن تميز أدلة مجلس الإدارة أيضاً بين مخاطر الانتقال والمخاطر المستقرة. عُرفت Capital One بتبنيها العدواني للسحابة. يمكن أن يؤدي اعتماد السحابة إلى تحسين المرونة والأمان عند إدارته بشكل جيد. لكن الانتقال يخلق مخاطر انتقالية: قد لا تتطابق الضوابط القديمة بشكل نظيف، وقد تفترض الفرق أن ضوابط الموفر تغطي واجبات العميل، وقد تتأخر طرق التدقيق خلف الهندسة، وقد يتوسع نطاق الهوية بشكل أسرع من المراجعة. يجب أن يرى مجلس الإدارة مخاطر الانتقال تلك بشكل صريح.

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

الكشف هو تحكم، وليس فكرة لاحقة

وضع سجل الاختراق الكشف مباشرة داخل المساءلة. يناقش أمر العقوبة المدنية لـ OCC تصريف التنبيهات ومخاوف الضوابط. تضمن المسار التقني العام الوصول إلى البيانات ونسخها الذي كان يجب أن تحكمه المراقبة والاستجابة. يمكن للبيئة السحابية توليد سجلات وتنبيهات واسعة النطاق، لكنها مفيدة فقط إذا فهمت الفرق تلك التنبيهات وحددت أولوياتها وتصرفت بناءً عليها.

أتمتة الأمان مهمة هنا. يمكن لضوابط السحابة اكتشاف استدعاءات API غير عادية، والوصول غير الطبيعي إلى البيانات، واستخدام بيانات الاعتماد المشبوهة، ومسارات الشبكة غير المتوقعة. لكن الأتمتة يمكنها أيضًا إنشاء حجم تنبيهات وإيجابيات كاذبة وملكية غير واضحة. إذا تم إنشاء تنبيه ولم يتم التصرف بناءً عليه، فقد فشل التحكم تشغيلياً حتى لو كان موجوداً تقنياً. سؤال المساءلة ليس "هل كانت هناك أداة؟" بل "هل أنتجت الأداة إجراءً في الوقت المناسب؟"

يدعم مبدأ الامتياز الأقل والكشف بعضهما البعض. الأذونات الضيقة تقلل ما يمكن لبيانات اعتماد الدور المسروقة الوصول إليه. المراقبة القوية تكتشف الاستخدام غير الطبيعي لتلك البيانات. تقييدات البيانات الوصفية تجعل سرقة بيانات الاعتماد أصعب. ضوابط جدار حماية تطبيقات الويب وطبقة التطبيق تقلل من مسارات SSRF. ضوابط فقدان البيانات تراقب سلوك النسخ غير المعتاد. لا يكفي أي تحكم واحد؛ السلسلة هي الدفاع.

يعامل عملاء السحابة أحياناً ميزات الأمان الأصلية للموفر كقدرة متاحة بدلاً من ضوابط نشطة. يجب تكوين الميزة ومراقبتها وتزويدها بالموظفين واختبارها. يجب أن تتطابق السياسة مع مالك عمل. يجب أن يكون للتنبيه مسار تصعيد. يجب أن يُظهر تقرير مجلس الإدارة ما إذا كان التحكم قد عمل. وإلا يصبح أمان السحابة كتالوجاً من الحمايات المحتملة بدلاً من نظام تشغيل للحمايات الفعلية.

لذا فإن حادث Capital One هو درس في التحكم التشغيلي. يمكن للعقد أن يقول إن العميل يملك التكوين. يمكن للتوثيق وصف دفاعات خدمة البيانات الوصفية. يمكن للهيئات التنظيمية أن تطلب جرد ضوابط. لا شيء من ذلك مهم ما لم تتمكن المؤسسة من إثبات أن المسارات الخطرة مقيدة وأن النشاط المشبوه يتم التعامل معه قبل حدوث نسخ بيانات واسع النطاق.

تعلم الموفر أيضاً من المسار

تُظهر مواد IMDSv2 من AWS التعلم من جانب الموفر دون الفصل في قضية Capital One. شرح منشور أمان نوفمبر 2019 حولخدمة بيانات تعريف مثيل EC2 الإصدار 2نهجاً موجهًا للجلسة، وتغييرات في طريقة الطلب، ودفاعاً إضافياً في العمق ضد جدران الحماية المفتوحة والوكلاء العكسيين وثغرات SSRF. نقلت خارطة الطريق اللاحقةIMDSv2 بشكل افتراضيالوضع الافتراضي إلى أبعد من ذلك.

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

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

غالباً ما يُستشهد بقضية Capital One لتعليم "العميل يملك التكوين". هذا صحيح لكنه غير مكتمل. الدرس الناضج يسأل أيضاً كيف يمكن للموفرين تصميم الخدمات بحيث يصعب استغلال أنماط الأخطاء الشائعة. IMDSv2 مثال على هذا الاتجاه. لا يقرر الخطأ بأثر رجعي؛ إنه يُظهر قيمة التصميم الدفاعي بعد أن يصبح مسار الإساءة في العالم الحقيقي علنياً.

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

يظل العقد مقابل التحكم هو الدرس الدائم

الدرس الدائم هو أن عقد السحابة يمكن أن يحدد المسؤوليات، لكن الدليل فقط يمكنه إثبات التحكم. في حالة Capital One، يمتد سجل الأدلة ليشمل إشعار الشركة، ومقاضاة وزارة العدل، وأوامر OCC والاحتياطي الفيدرالي، وتوجيهات FFIEC، ووثائق AWS، وإفصاحات هيئة الأوراق المالية والبورصات، وإفصاحات مجلس الإدارة، وإشعار الهيئة التنظيمية الكندية، ووثائق التسوية المدنية. كل سجل يجيب على جزء من السؤال. لا يكفي أي منها بمفرده.

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

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

سؤال المساءلة النهائي ليس ما إذا كانت السحابة آمنة. بل هو ما إذا كانت المؤسسة التي تستخدم السحابة يمكنها إظهار أن عقودها وضوابطها وتنبيهاتها وأذوناتها ورقابة مجلس الإدارة تتطابق مع الطريقة التي تعمل بها السحابة فعلياً. جعلت Capital One هذا عدم التطابق علنياً. يجب أن يجعل سجل الإصلاح التطابق مرئياً.

يجب قياس المعالجة بتقليل الغموض

برنامج الإصلاح القوي بعد الحادث يقلل الغموض. قبل الحادث، قد تعتقد المؤسسة أن ضوابط السحابة وإعدادات جدار حماية تطبيقات الويب وأدوار IAM والمراقبة كافية. بعد الحادث، يجب أن تكون قادرة على إثبات أي الافتراضات تغيرت. أي الأدوار تم تضييقها؟ أي إعدادات البيانات الوصفية تغيرت؟ أي اختبار جدار حماية تطبيقات الويب تحسن؟ أي التنبيهات حصلت على مالكين؟ أي مخازن البيانات تلقت شروطاً أقوى؟ أي خطوات تدقيق أصبحت روتينية؟ أي مقاييس مجلس الإدارة تُظهر الإغلاق؟

توفر الأوامر التنظيمية لـ Capital One وإنهاء الأمر اللاحق معالم عامة، لكن القراء العامين لا يمكنهم رؤية كل اختبار تحكم داخلي. هذا طبيعي. ومع ذلك، يجب أن تكون فئات الإصلاح مرئية. ليس على البنك نشر مخططات معمارية حساسة لإظهار أنه عزز حوكمة السحابة. يمكنه الإفصاح عن هياكل الرقابة وبرامج التحكم وتغطية التدقيق وإغلاق الهيئة التنظيمية حيثما كان ذلك مناسباً.

الغموض مكلف بعد الاختراق. يتساءل العملاء ما الذي تعرض. تتساءل الهيئات التنظيمية ما إذا كانت ضوابط الانتقال كافية. يتساءل المستثمرون كم ستكلف المعالجة. يتساءل المهندسون أي الأنماط لا تزال مسموحة. يتساءل المدققون ما إذا كانت الأدلة كاملة. لذا فإن تقليل الغموض جزء من الإصلاح.

يعود عدم تطابق العقد والتحكم هنا. إذا قال العقد إن العميل يملك التكوين، لكن المؤسسة لا تستطيع تحديد أي التكوينات تحمي البيانات الحساسة، فإن العقد لم ينتج مساءلة تشغيلية. إذا قال مجلس الإدارة إنه يشرف على مخاطر الأمن السيبراني، لكنه لا يستطيع ربط دور سحابي بتعرض البيانات، فإن الرقابة مجردة للغاية. إذا قال الموفر إنه يقدم أساسيات آمنة، لكن الإعدادات الافتراضية تسمح ببقاء مسارات الأخطاء الشائعة سهلة، فإن مساءلة المنتج غير مكتملة.

يجب أن يكون المعيار بعد الحادث عملياً: كل مسار بيانات سحابية حساس يجب أن يكون له مالك مسمى، وسياسة بأقل امتياز، وتحكم تسجيل، ومالك تنبيه، وجدول اختبار، وحالة مرئية لمجلس الإدارة. هذا ما يحول المسؤولية المشتركة من رسم بياني إلى نظام تحكم عامل.

لا تزال القضية مهمة لأن استخدام السحابة أصبح عادياً الآن

لا يزال اختراق Capital One ذا صلة لأن استخدام السحابة أصبح الآن بنية تحتية مصرفية عادية. الجزء الاستثنائي ليس أن البنك استخدم السحابة. الجزء الاستثنائي هو أن السجل العام أجبر الجميع على فحص المسافة بين مخططات مسؤولية السحابة والتحكم التشغيلي الحقيقي. لا تزال تلك المسافة مهمة لكل مؤسسة مالية تستخدم الخدمات السحابية، أو التحليلات المُدارة، أو خدمات الهوية، أو بحيرات البيانات، أو منصات الحاويات، أو أعباء العمل بدون خادم.

غالباً ما تواجه المؤسسات المالية ضغوطاً للتحديث بسرعة. يمكن للسحابة تحسين السرعة والمرونة والقدرة الأمنية. يمكنها أيضاً خلق أنماط فشل جديدة إذا تأخرت الحوكمة. الهيئات التنظيمية لا تطلب من البنوك تجنب السحابة. إنها تطلب من البنوك فهم السحابة والتحكم فيها. الفرق حاسم. التجنب ليس الهدف؛ التشغيل القائم على الأدلة هو الهدف.

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

الدرس النهائي هو التواضع. يمكن أن تكون الهندسة السحابية قوية، لكن فقط إذا تعاملت المؤسسات مع التكوين والهوية والكشف والحوكمة كضوابط حية. المسؤولية المشتركة تحدد الواجبات. لا تؤديها. يُظهر السجل العام بعد Capital One ما يحدث عندما تصبح الفجوة بين الواجب المحدد والتحكم العملي مرئية للعملاء والهيئات التنظيمية والمحاكم والمستثمرين.

يجب اختبار تحكم الانتقال قبل النطاق الحساس

يجعل أمر العقوبة المدنية لـ OCCأمر العقوبة المدنيةوأمر الكف والامتناعأمر الكف والامتناعحوكمة الانتقال إلى السحابة محورياً في سجل Capital One. هذا مهم لأن مخاطر الانتقال تختلف عن المخاطر المستقرة. أثناء الانتقال، تترجم المؤسسات افتراضات التحكم القديمة إلى نموذج تشغيل جديد. تتغير جدران الحماية والهويات ومسارات التخزين والسجلات وروتينات التدقيق وخطط الاستجابة للحوادث جميعاً. إذا كانت ترجمة التحكم غير مكتملة، يمكن أن تصل البيانات الحساسة إلى نطاق سحابي قبل أن يلحق برنامج الأدلة به.

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

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

يجب أيضاً أن تكون أدلة الانتقال مُدارة بالإصدارات بمرور الوقت. قد لا يغطي التحكم الذي اجتاز الاختبار في وقت مبكر من البرنامج هندسة متغيرة أو خدمة جديدة أو دوراً موسعاً أو مخزن بيانات مختلف. تُظهر حالة Capital One لماذا تحتاج فرق مجلس الإدارة والتدقيق إلى رؤية مستمرة، وليس موافقة انتقال لمرة واحدة. اعتماد السحابة هو برنامج، وليس حفل توقيع.

الهدف ليس إبطاء التحديث بحد ذاته. الهدف هو منع التحديث من تجاوز الدليل. يمكن للسحابة أن تمنح البنك أدوات أفضل من البيئة القديمة، لكن فقط إذا تم تكوين تلك الأدوات واختبارها ومراقبتها وحوكمتها في الهندسة الفعلية التي تحتوي على بيانات العملاء.

يجب أن يُظهر مبدأ الامتياز الأقل ما لا يمكن أن يحدث

غالباً ما يوصف مبدأ الامتياز الأقل بإدراج ما يمكن للدور فعله. بعد اختراق مسار البيانات الوصفية، السؤال الأكثر أهمية هو ما لا يمكن للدور فعله. هل يمكن لدور مرتبط بتطبيق واحد إدراج تخزين غير ذي صلة؟ هل يمكنه قراءة بيانات الإنتاج عندما يجب عليه كتابة سجلات فقط؟ هل يمكنه عبور حدود الحساب؟ هل يمكنه الوصول إلى مخازن بيانات أقدم تم الاحتفاظ بها للتحليلات أو الامتثال؟ هل يمكنه تنفيذ إجراءات خارج ساعات العمل أو من مسارات غير متوقعة؟ يتم إثبات مبدأ الامتياز الأقل بالمساحة السلبية.

توفر وثائق AWS حولأدوار IAM لـ Amazon EC2وأفضل ممارسات IAMأفضل ممارسات IAMالخلفية التقنية الحالية للوصول القائم على الدور وانضباط الأذونات. لا يسمح السجل العام لـ Capital One للقراء الخارجيين بفحص سياسات الأدوار الدقيقة لعام 2019. لكنه يُظهر لماذا كان نطاق الأذونات مهماً. إذا تم الحصول على بيانات اعتماد مؤقتة من خلال مسار بيانات وصفية، تحدد الإجراءات المسموح بها للدور نصف قطر الانفجار.

يجب على برنامج السحابة الناضج اختبار الأدوار من منظور المهاجم. افترض أن دور التطبيق هذا قد سُرق. ما البيانات التي يمكنه قراءتها؟ ما الذي يمكنه إدراجه؟ ما الذي يمكنه نسخه؟ أي السجلات تُطلق؟ أي مفاتيح الشرط أو ضوابط الشبكة تحد من استخدامه؟ أي الحاويات الحساسة ترفضه؟ أي مالك تنبيه يرى الوصول غير الطبيعي؟ ما مدى سرعة تعطيل الدور؟ هذه الاختبارات تحول مبدأ الامتياز الأقل من عبارة سياسة إلى دليل تشغيلي.

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

هنا تصبح المسؤولية المشتركة ملموسة. يقدم موفر السحابة أدوات IAM وضوابط البيانات الوصفية. يصمم العميل ويختبر نطاق الدور. تطلب الهيئات التنظيمية دليلاً. إذا بقيت أي من هذه الطبقات مجردة، فإن مسار البيانات الوصفية التالي سيكشف مرة أخرى الفرق بين المسؤولية المحددة والتحكم العملي.

إغلاق التسوية وإغلاق التحكم هما نقطتا نهاية مختلفتان

تُظهر وثائق التسوية في أرشيف تسوية اختراق بيانات Capital Oneأرشيف التسوية، بما في ذلك أمر الموافقة النهائيةأمر الموافقة النهائية، شكلاً من أشكال الإغلاق العام لمطالبات المستهلكين. لا تُظهر كل إصلاح تحكم. يخدم الإغلاق القانوني وإغلاق التحكم وظائف مختلفة. يمكن للتسوية تعويض وتقديم خدمات وحل المطالبات. لا تثبت بحد ذاتها أنه تم إعادة تصميم كل مسار سحابي، أو تحسين كل عملية تنبيه، أو جعل كل مقياس لمجلس الإدارة دائمًا.

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

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

يُظهر النموذج 10-K لعام 2019 لـ Capital Oneالنموذج 10-Kوبيان التوكيل لعام 2020بيان التوكيلكيف دخلت الاستجابة للحادث والتكلفة والتأمين والتقاضي ورقابة مجلس الإدارة في الإفصاح المؤسسي. أقوى مساءلة مستمرة ستربط تلك الإفصاحات بمقاييس دائمة: إيقاع اختبار التحكم السحابي، ونتائج التدقيق، وتقليص نطاق الدور، ومقاييس الاستجابة للتنبيهات، وإغلاق الهيئة التنظيمية حيثما ينطبق.

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

كان تقليل البيانات سيغير سجل التأثير

عادة ما يُناقش حادث Capital One من خلال التكوين والبيانات الوصفية وIAM. يستحق تقليل البيانات اهتماماً متساوياً لأن الأذونات ومسارات البيانات الوصفية تصبح ضرراً للعميل فقط عندما تكون البيانات الحساسة قابلة للوصول. وصفت إشعارات Capital One المقدمة إلى هيئة الأوراق المالية والبورصاتالإشعار المقدموصفحة الحادث المحفوظةصفحة الحادثفئات البيانات المتعلقة بالتطبيقات والحسابات. تُظهر تلك الفئات أن السؤال لم يكن فقط كيف وصل المهاجم إلى التخزين، ولكن لماذا كانت كل فئة من البيانات موجودة وقابلة للوصول في البيئة المتأثرة.

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

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

سياق الإشعار الكندي من مكتب مفوض الخصوصية الكندي، الذي أعلن عن تحقيق في Capital Oneتحقيق Capital One، يُظهر أيضاً لماذا فئات البيانات مهمة عبر الولايات القضائية. قد يدير البنك برنامجاً سحابياً واحداً، لكن الأشخاص المتأثرين والهيئات التنظيمية يختبرون الحدث من خلال حقول بيانات محددة والإقامة وواجبات الإشعار. يقلل التخفيف عدد الأشخاص المسحوبين إلى ذلك السجل متعدد الولايات القضائية.

درس التحكم السحابي ليس فقط "منع إساءة استخدام البيانات الوصفية". بل هو "اجعل إساءة استخدام البيانات الوصفية أقل قيمة". الأدوار الضيقة، والوصول المشدد إلى البيانات الوصفية، وجدران الحماية المختبرة، والتنبيهات القوية ضرورية. وكذلك تقليل البيانات الحساسة المتاحة لأي مسار واحد. هكذا تلتقي الضوابط التقنية وحوكمة الخصوصية.

يجب أن تجعل حوكمة السحابة الملكية مرئية

الدرس التشغيلي النهائي هو الملكية. يمكن للبيئة السحابية أن تحتوي على العديد من الأجزاء التقنية الصحيحة مع ترك المسؤولية منتشرة. فريق يملك تطبيقاً، وآخر يملك أنماط IAM، وآخر يملك تصنيف البيانات، وآخر يملك قواعد جدار حماية تطبيقات الويب، وآخر يملك التسجيل، وآخر يملك استجابة التدقيق. عندما يعبر حادث تلك الحدود، يمكن أن تصبح "المسؤولية المشتركة" غموضاً مشتركاً ما لم تكن الملكية واضحة قبل الحدث.

يُظهر سجل Capital One لماذا تحتاج الملكية إلى أن تكون مرتبطة بمسارات البيانات، وليس فقط بالفرق. لكل عبء عمل حساس، يجب أن تعرف المؤسسة من يملك نقطة دخول التطبيق، ومن يوافق على أنماط الوصول إلى البيانات الوصفية، ومن يراجع أذونات الدور، ومن يراقب الوصول إلى التخزين، ومن يتحقق من صحة التنبيهات، ومن يقبل الاستثناءات، ومن يبلغ عن المخاطر غير المحلولة إلى منتديات الحوكمة. إذا كان مسار واحد يمكنه الوصول إلى بيانات المتقدم أو العميل، يجب أن يكون لهذا المسار مالك تحكم مسمى ومالك عمل مسمى.

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

لذا تعامل المؤسسة السحابية المسؤولة مع مخططات الهندسة كأدوات حوكمة. يجب أن تكون حديثة بما يكفي للمستجيبين، وواضحة بما يكفي للمدققين، ومحددة بما يكفي للمدراء التنفيذيين لفهم أين يمكن لمس البيانات عالية التأثير. مسؤولية السحابة حقيقية فقط عندما يكون الأشخاص الذين لديهم سلطة على كل جزء من المسار مرئيين.