AWS بنى أداة أمان، ولكنها أدت إلى خطر أمان في هذه السلسلة من مقالات السياسة الأمنية، تم استكشاف أربع مفاهيم خاطئة خطيرة حول كيفية تأمين الوصول بين الحسابات في بيئات AWS. وفي هذا المقال الأخير، سنستعرض حالة حقيقية حيث ارتكبت AWS خطأً، حيث أدت أداة تقييم الحسابات الخاصة بـ AWS Organizations إلى تعريض الحسابات لمخاطر تصعيد الصلاحيات بسبب تعليمات نشر معيبة. كيف بدأت القصة أثناء التحقيق في خطر تصعيد صلاحيات حاسم يتعلق بدور في بيئة AWS لعميل، اكتشفنا دورًا موجودًا في كل من حسابات الإنتاج والإدارة الخاصة بهم، وكلها تثق في دورين في حساب التطوير: الدور الخطر: كان لديه صلاحيات لإجراء مكالمات API حساسة تتعلق بالهوية والوصول والبيانات، بما في ذلك الوصول إلى جميع الموارد (resource: "*")، مما يجعله خطرًا كبيرًا إذا تم اختراقه. حساب التطوير: كان لديه ضوابط أمان أضعف مقارنة بحسابات الإنتاج والإدارة، مما جعل هذا المسار ثقة محفوفًا بالمخاطر. إذا تمكن هacker من اختراق دور موثوق به في حساب التطوير، يمكنه الحصول على هذه الصلاحيات في حسابات الإنتاج والإدارة على الفور. أداة تقييم الحسابات لـ AWS Organizations عند البحث في تفاصيل الدور، وجدنا أن أسماء الأدوار كانت غريبة بعض الشيء، مما أشار إلى أنها جزء من نظام آلي. بحث سريع قادنا إلى أداة تقييم الحسابات لـ AWS Organizations، وهي أداة طورتها AWS ونشرتها في مكتبة حلول AWS. وفقًا للمستندات الرسمية، تساعد هذه الأداة المستخدمين على تقييم وإدارة الحسابات داخل منظماتهم بفعالية أكبر، وهي مفيدة في عمليات الاندماج والاستحواذ، ومراجعات الأمان، واستكشاف وإدارة السياسات المركزية. الأداة تتبع معمارية مركزية وفرعية (hub-and-spoke architecture)، حيث يسمح للدور المركزي (hub role) بالافتراض الدور الفرعي (spoke roles) عبر جميع الحسابات، مما يتيح جمع بيانات الأمان عبر المنظمة بأكملها. لماذا كانت هذه تعليمات خطيرة السبب الرئيسي للمشكلة هو تعليمات النشر الرسمية التي توصي بـ "تنصيب الحزمة المركزية - نشرها في أي حساب عضو في منظمتك في AWS باستثناء حساب إدارة المنظمة". هذه التعليمات، دون توضيح العواقب الأمنية، أدت إلى تعريض الحسابات لمخاطر كبيرة. بمجرد أن تمت توصية عدم نشر الدور المركزي في حساب الإدارة، اضطر العملاء إلى نشره في حساب أقل أمانًا، غالبًا حساب تطوير أو تجربة أو أي حساب آخر ذو حساسية منخفضة. هذا أدى إلى إنشاء مسار ثقة مباشر من حساب أقل أمانًا إلى حسابات أكثر حساسية مثل حسابات الإنتاج والبيئات الخاضعة لمعايير PCI-DSS وحتى حساب الإدارة نفسه. في الحالة التي تم التحقيق فيها، نشر العميل الدور المركزي في حساب التطوير، مما أدى إلى الآتي: - ضوابط أمان أضعف: كان حساب التطوير يتمتع بضوابط أمان أقل مقارنة بحسابات الإنتاج والإدارة. - الوصول الكامل: كان لديه الوصول الكامل لافتراض أدوار فرعية في جميع الحسابات، بما في ذلك الحسابات الحساسة مثل حسابات الإدارة والإنتاج. وهذا يعني أنه إذا تمكن هacker من اختراق حساب التطوير، يمكنه التحول إلى حساب الإدارة والتحكم في المنظمة بأكملها بسهولة أكبر. الآثار على المنظمات المتأثرة أي منظمة نشرت هذه الأداة وفقًا لتعليمات AWS (قبل تاريخ 28 يناير 2025) مع نشر الدور المركزي في حساب أقل أمانًا من حساب الإدارة، وتلك التي لم تقم بإزالة النشر بعد، تواجه خطرًا كبيرًا. يصبح الحساب الذي تم فيه نشر الدور المركزي هدفًا ذا قيمة عالية. إذا تمكن هacker من اختراق هذا الدور، سواء من خلال الوصول المباشر أو تصعيد الصلاحيات، يمكنه افتراض أدوار فرعية عبر جميع الحسابات المرتبطة، بما في ذلك البيئات الحساسة للغاية مثل حسابات الإدارة والإنتاج. بمجرد الاختراق، يمكن لهacker: - الوصول إلى البيانات الحساسة. - تغيير سياسات الأمان. - نشر أدوات خبيثة. - التلاعب بالموارد الحيوية. بالإضافة إلى ذلك، تجعل أسماء الأدوار المحددة مسبقًا من الأداة من السهل على الهackers استغلالها. إذا حصل الهacker على وصول إلى أي حساب AWS داخل المنظمة المتأثرة، يمكنه بسهولة تحديد ما إذا كانت الأداة مثبتة ومعرفة الأسماء الدقيقة للأدوار التي يمكن افتراضها من الحساب المركزي. الكشف عن المشكلة وإصلاحها هناك طريقتان لكشف ما إذا كانت منظمتك متأثرة: 1. فحص تاريخ النشر: تحقق من تاريخ نشر الأداة عن طريق فحص خاصية CreateDate للأدوار. إذا تم النشر قبل 28 يناير 2025، ننصحي بحزم النشر الحالي ما لم يكن الدور المركزي في حساب ذو أمان عالي (مثل حساب دعم البنية التحتية أو حساب DevOps). 2. حذف الأداة: قم بإزالتها عن طريق حذف مكدسات CloudFormation لكل من المكونات المركزية (Hub)، الفرعية (Spoke)، وإدارة المنظمة (Org-Management). يمكنك الرجوع إلى دليل الإزالة الرسمي لـ AWS للحصول على المزيد من التعليمات. إذا كنت ما زلت بحاجة إلى استخدام الأداة، يجب عليك إعادة نشر الدور المركزي في حساب ذو أمان يعادل أمان حساب الإدارة لمنع مخاطر تصعيد الصلاحيات. الإبلاغ وإصلاح المشكلة بعد تحديد المشكلة، أبلغنا فريق أمان AWS عن المخاطر الجدية التي خلقتها تعليمات نشر الأداة. قام فريق أمان AWS بمراجعة نتائجنا بشكل سريع، وأقر بالخطر الأمني، وعمل معنا على تحديد أفضل طريقة لتحديث الوثائق لمنع المخالفات المستقبلية. بناءً على هذا التعاون، قام AWS بتعديل الوثائق ليتم التوصية صراحة بنشر الدور المركزي في حساب ذو أمان يعادل أمان حساب الإدارة لضمان تقييم الحسابات بشكل آمن. الخاتمة خلال هذه السلسلة من المقالات، استكشفنا كيف يمكن أن تتسرب مخاطر السياسات الأمنية إلى بيئات AWS المدارة بشكل جيد، سواء من خلال تفاصيل تقنية مغفل عنها، مفاهيم خاطئة دقيقة، أو حتى أدوات رسمية. تأمين العلاقات الثقة يتطلب فهمًا أعمق لسلوك آليات الثقة في البيئات الحقيقية، وليس مجرد اتباع قائمة فحص. نأمل أن تكون هذه السلسلة قد أضاءت بعض التحديات الخفية حول سياسات الثقة. شكراً لقرائكم! تقييم الحدث من قبل المختصين فريق أمان AWS كان سريع الاستجابة ومفتوحًا للردود والاقتراحات، مما يعكس التزام الشركة بتحسين أمان عملائها. هذه الخطوة تعكس حسن النية والمسؤولية في التعامل مع القضايا الأمنية، وتؤكد على أهمية الشفافية في التواصل مع المطورين والمستخدمين. معلومات عن الشركة ذات الصلة Token Security هي منصة أمان تركز على الهوية والوصول الآلي، وتكتشف مخاطر السياسات الأمنية، بما في ذلك المخاطر المتعلقة بالثقة بين الحسابات، سواء كانت ناجمة عن أدوات AWS أو الأخطاء البشرية أو التكوينات المغفل عنها. إذا كنت ترغب في رؤية كيف تعمل، يمكنك حجز ديمو لترى كيف نساعد المنظمات في البقاء متقدمين على هذه المخاطر.