كسر سلاسل هجوم المهاجمين في AWS: أدوار IAM

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

في عمليات النشر السحابية لدينا أربع فئات رئيسية من الهجمات، ولكل منها سلاسل هجوم مختلفة:

1. الهجمات على المنصة السحابية نفسها. وبصرف النظر عن اختراق جوهري لمزوّد الخدمة السحابية (وهو أمر خارج عن سيطرة العميل)، تركّز هذه الهجمات عادةً على أخطاء تهيئة الخدمات السحابية. فإذا تركت حاوية S3 عامة، أو أغفلت إضافة أداة تفويض إلى API Gateway، أو كشفت بيانات اعتمادك لـ AWS على GitHub، فذلك يندرج ضمن هذه الفئة.
2. الهجمات على الموارد والتطبيقات التي ينشرها العميل في السحابة. لا تختلف هذه الهجمات التقليدية عن تلك التي تُشن على مركز بياناتك. ومن الأمثلة الشائعة حقن SQL في تطبيق ويب، والخوادم المعرّضة للثغرات التي تُركت منافذها الخاطئة مفتوحة على الإنترنت. وتميل هذه الهجمات إلى أن تكون أكثر محدودية مما لو استهدفت مركز بيانات، بافتراض استخدامك للحسابات/الاشتراكات/المشاريع وشبكات VPC أو الشبكات الافتراضية للحد من نطاق الضرر.
3. الهجمات على مسؤولي السحابة والمطورين لديك. في المرة القادمة التي تُجري فيها اختبار اختراق، احرص على السماح للمهاجمين بمحاولة التصيّد الاحتيالي لمطوريك ومسؤوليك. فهذه إحدى أفضل الطرق للانتقال إلى السحابة، إذ غالبًا ما يكون الوصول إلى جهاز أحد المطورين أسهل بكثير على المهاجم من اختراق التطبيق السحابي نفسه. سنتناول هذا الموضوع مستقبلًا، لكن لنبدأ بالقول إن «المصادقة متعددة العوامل صديقتي».
4. الهجمات المختلطة. هذه هي الفئة التي سنركّز عليها اليوم. ففي هذه الهجمات يخترق المهاجم شيئًا منشورًا في السحابة ثم يستخدمه للانتقال إلى مستوى إدارة السحابة. (يعتبر البعض أن الهجمات على المطورين مختلطة أيضًا، لكنني أفضّل فصلها على حدة.)

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

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

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

الهجوم المختلط على AWS: استخراج بيانات اعتماد أدوار IAM

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

1. الاختراق المباشر لمثيل أو حاوية. على سبيل المثال، إذا تركت المنفذ 22 مفتوحًا وتمكن المهاجم من الاختراق أو الحصول على وصول إلى الغلاف بطريقة أخرى.
2. تزوير الطلبات من جانب الخادم (SSRF). يستغل المهاجم (عادةً) ثغرة في خادم أو خدمة ويب ويمكنه تنفيذ أوامر دون الحصول على وصول إلى الغلاف.
3. اختراق دالة Lambda. رغم أنه لا يمكنك الحصول على غلاف في Lambda، فإنها تظل عرضة لثغرات تنفيذ التعليمات البرمجية، بل وحتى التنفيذ العشوائي للتعليمات البرمجية إذا احتوت على خلل تطبيقي. وقد تشبه التبعات الدقيقة هجمات SSRF.

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

يفهم معظم الناس بيانات الاعتماد الثابتة؛ وهي في AWS مفتاح وصول ومفتاح سري. وهي أشبه باسم مستخدم وكلمة مرور لكنها تُستخدم لاستدعاءات واجهة برمجة تطبيقات AWS. ويستخدم الإصدار الحالي عملية تشفير تُعرف باسم Signature 4 لتوقيع طلبات HTTP عند إجراء تلك الاستدعاءات. ويمكنك، بل ينبغي لك، التعامل معها تمامًا كاسم مستخدم وكلمة مرور — وينبغي ألا تخزّنها مطلقًا داخل موارد سحابية مثل المثيلات ودوال Lambda.

أدوار IAM أكثر تعقيدًا عند بدء استخدام AWS، فهي رائعة ومخيفة في آن واحد. إن دور IAM في AWS هو في الواقع حاوية للصلاحيات تستخدمها لجلسة معينة. وأدوار IAM ممتازة لأنها ليست بيانات اعتماد بحد ذاتها… فعندما تتولى الدور توفّر AWS مجموعة من بيانات الاعتماد لجلسة محدودة المدة. والأدوار شيء «داخل AWS فقط». يمكنك تعيينها لموارد داخل AWS (مثل مثيل أو دالة Lambda) ويصبح بإمكان ذلك المورد إجراء استدعاءات واجهة برمجة التطبيقات دون بيانات اعتماد ثابتة ومخزّنة! نستخدم الأدوار لاتصالات الهوية الموحّدة، والمثيلات، ودوال Lambda، وكل خدمة أخرى داخل AWS. أما مفاتيح الوصول فتُستخدم فعليًا فقط عند إنشاء مستخدم في حساب AWS، ونستخدم الأدوار لكل ما عدا ذلك.

ترتبط بالأدوار أربعة أنواع من الصلاحيات:

1. ما يمكن للدور فعله داخل AWS. وهذه هي سياسات الصلاحيات المباشرة التي ترفقها بالدور.
2. من أو ما الذي يمكنه استخدام الدور (سياسة الثقة). فإنشاء دور لا يعني أن أي شيء أو أي شخص يمكنه استخدامه، إذ تقيّد هذه السياسة الوصول ليقتصر مثلًا على مثيلات AWS أو دالة Lambda محددة.
3. حد الصلاحيات الذي يقيّد نطاق الدور. وهذا أمر أكثر تعقيدًا قليلًا ولا صلة له بنقاشنا اليوم، لذا سنتناوله لاحقًا.
4. عند تولّي دور لجلسة معينة، يمكنك أيضًا تحديد مجموعة فرعية من صلاحياتك الحالية لاستخدامها في تلك الجلسة. وهذه ميزة ممتازة لتحقيق مبدأ الحد الأدنى من الصلاحيات، لكنها أيضًا ليست وثيقة الصلة بنقاشنا اليوم.

ربما يكون شرح آلية العمل أسهل بعرضها خطوة بخطوة. لنفترض أن لديّ تطبيقًا يحتاج إلى الوصول إلى حاوية S3 أو قاعدة بيانات Dynamo. أنشئ دور IAM للمثيل وأضبط سياسة الثقة بحيث تتمكن خدمة EC2 من استخدام الدور. ثم أُطلق مثيلًا وأعيّن له الدور. تشغّل AWS المثيل وتجعله يتولى الدور. وتولّي الدور يفتح جلسة ويخصّص مفتاح وصول ومفتاحًا سريًا ورمز جلسة. ثم تدوّر AWS بيانات الاعتماد هذه كل 1-6 ساعات، ويصبح بإمكان المثيل إجراء استدعاءات واجهة برمجة التطبيقات المصرّح بها بموجب سياسات الصلاحيات.

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

وهنا يأتي دور الهجوم.

خدمة البيانات الوصفية هي ببساطة عنوان URL يمكنك الوصول إليه فيعيد المعلومات المطلوبة. فالأمر curl 169.254.169.254/latest/meta-data/ سيوفّر جميع المعلومات الأساسية، ويمكنك استخدام المسار curl 169.254.169.254/latest/meta-data/iam-security-credentials/ للحصول على مفتاح الوصول والمفتاح السري والرمز. (وفي حالة الهجوم القائم على Lambda يبدو الأمر مختلفًا تمامًا وتستخدم تعليمات SDK بدلًا من curl، لكن المبادئ نفسها تنطبق.)

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

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

كسر سلسلة الهجوم الخاصة باستخراج أدوار IAM

لنرسم خريطة سلسلة الهجوم. يحتاج المهاجم إلى ما يلي:

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

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

6 أساليب تساعد على كسر حلقات مختلفة من سلسلة الهجوم

1. إدارة الثغرات
2. سياسات أذونات IAM بأقل امتياز مع قيود على الموارد
3. استخدام قيود شرطية على عنوان IP أو VPC أو غيرها من مصادر الطلب في سياسات الأذونات
4. استخدام نقاط نهاية الخدمة مع السياسات + سياسات الموارد
5. إضافة وكلاء بيانات وصفية مع مرشّحات وكيل مستخدم HTTP (حماية خدمة البيانات الوصفية)
6. الحماية من الاستخدام المزدوج للدور

إدارة الثغرات

• التعقيد: متوسط
• الفعالية: منخفضة
• قابلية التوسع: صعبة
• النوع: كشفي ووقائي

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

سياسات أذونات IAM بأقل امتياز مع قيود على الموارد

• التعقيد: متوسط
• الفعالية: عالية
• قابلية التوسع: متوسطة إلى صعبة
• النوع: وقائي

سياسات IAM في AWS هي رفض افتراضي وتتضمن عبارات سماح ورفض صريحة. على سبيل المثال، يمكنكم كتابة سياسة تسمح فقط بقراءة حاوية S3. كما تتضمن قيودًا على الموارد، فحيث تُصرّح عبارة السماح للدور باستدعاء واجهة برمجة تطبيقات القراءة، يسمح قيد الموارد للدور بقراءة حاويات أو كائنات محددة فقط. ينبغي أن تبدأوا دفاعاتكم من هنا دائمًا وأبدًا. عندما أُجري عمليات تقييم أجد، في كل مشروع تقريبًا، سياسات IAM تمنح امتيازات كثيرة جدًا (استدعاءات API) وقيود موارد قليلة جدًا. نعم، قد تحتاج تلك الخدمة إلى الوصول إلى قاعدة بيانات Dynamo، لكن هل تحتاج إلى الوصول إلى كل جدول؟ تطبيق هذا الضابط تحديدًا ليس صعبًا على نطاق صغير، لكن كلما كبرتم وزاد عدد الأشخاص الذين يتخذون قرارات السياسات هذه، صعُب الحفاظ على الاتساق على نطاق واسع. ومن المهم أيضًا إضافة عبارات رفض صريحة تحسبًا لقيام أحدهم بإضافة سياسة جديدة بأذونات جديدة إلى الدور. فالأذونات تراكمية، لكن أي عبارة رفض تتجاوز عبارات السماح.

استخدام قيود شرطية على عنوان IP أو VPC أو غيرها من مصادر الطلب في سياسات الأذونات

• التعقيد: عالية
• الفعالية: متوسطة إلى عالية
• قابلية التوسع: صعبة
• النوع: وقائي

تدعم سياسات IAM العبارات الشرطية التي تدعم مجموعة من الخيارات منها عنوان IP أو شبكة VPC المصدر. إذا كنتم تعلمون أن دورًا معينًا لا ينبغي له أبدًا إجراء استدعاءات API إلا من مورد محدد في حزمة تطبيقاتكم، فيمكنكم قصر التصريح على عنوان IP أو الشبكة الفرعية بالتحديد. وإذا سرق المهاجم بيانات الاعتماد وحاول تشغيلها في مكان آخر فستفشل استدعاءات API. هذه مطرقة ثقيلة موجّهة بدقة – سهلة في المفهوم وصعبة في التنفيذ لأنكم قد تجدون تعقيدات أخرى تعترض التطبيق السليم. على سبيل المثال، استدعاءات API إلى خدمات AWS إما أن تصل إلى الإنترنت مباشرةً، أو تمر عبر بوابة NAT، أو تُوجَّه داخليًا عبر نقطة نهاية خدمة (وهو ما سنناقشه بعد قليل). وسيعتمد عنوان IP المكتشف على مسار استدعاء API إلى الإنترنت. كل ذلك قابل للإدارة والكشف (والأتمتة) لكن ينبغي لكم الاطلاع أولًا للتأكد من فهمكم لمختلف الحالات.

اطّلعوا على الجزء الأول من هذه التدوينة من Netflix للحصول على بعض الأمثلة.

ما لم تشغّلوا دالة Lambda على شبكة VPC، فلن يكون هذا خيارًا متاحًا لحماية دالة مخترقة.

استخدام نقاط نهاية الخدمة مع السياسات + سياسات الموارد

• التعقيد: متوسط
• الفعالية: متوسطة إلى عالية
• قابلية التوسع: متوسط
• النوع: وقائي

في AWS، تُعد نقطة نهاية الخدمة بمثابة مأخذ على الشبكة يلتقط حركة البيانات التي تنتقل عادةً عبر الإنترنت إلى إحدى خدمات AWS ويعيد توجيهها داخليًا. وقد أُنشئت في الأصل للسماح للشبكات الفرعية الخاصة بالكامل في AWS، أي تلك التي لا تملك أي وسيلة للوصول إلى الإنترنت، بالوصول مع ذلك إلى خدمات AWS معينة. وتدعم نقاط النهاية سياسات يمكنكم استخدامها لتقييد الوصول والإجراءات بطرق مشابهة جدًا لسياسات IAM. وفي هذه الحالة تضيفون قيودًا إلى سياسة نقطة النهاية للسماح فقط بالوصول إلى موارد محددة خلف تلك النقطة (S3 هو المثال الأكثر شيوعًا). أنتم تحددون الحاويات المسموح بها، ولا يحصل أي مورد آخر في تلك الشبكة الفرعية على وصول إلى تلك الخدمة. اعتبروا هذا خط دفاع احتياطيًا لسياسة IAM - فمع نقطة نهاية خدمة تستخدم سياسة مقيِّدة، حتى لو منح أحدهم الدور عن غير قصد (أو عمدًا) وصولًا أوسع مما ينبغي، فسيظل غير قادر على الوصول إلى أي شيء غير مسموح به في سياسة نقطة نهاية الخدمة. وهذا يعني أن لدينا الآن ثلاث طبقات من السياسات، ويجب أن تسمح جميعها بالوصول إلى المورد:

• سياسة أذونات IAM التي تمنح الدور وصولًا إلى المورد.
• سياسة نقطة نهاية الخدمة التي تسمح بالوصول إلى الموارد عندما تأتي الطلبات عبر نقطة النهاية، بصرف النظر عن أذونات الدور المستخدم.
• سياسة الحاوية أو المورد (ويعتمد ذلك على نوع المورد) التي يمكنها قصر الوصول على عناوين IP المعتمدة فقط.

ما لم تشغّلوا دالة Lambda على شبكة VPC، فلن يكون هذا، مرة أخرى، خيارًا متاحًا لحماية دالة مخترقة.

إضافة وكلاء بيانات وصفية مع مرشّحات وكيل مستخدم HTTP (حماية خدمة البيانات الوصفية)

• التعقيد: عالية
• الفعالية: متوسط
• قابلية التوسع: صعبة
• النوع: وقائي

تفترض كل هذه الضوابط أن بإمكان المهاجم سرقة بيانات اعتماد الدور، ولكن ماذا لو كانت لدينا وسيلة للحد من قدرته على الحصول على تلك البيانات حتى لو اخترق المثيل أو الحاوية المصرَّح لها؟ (لن ينجح هذا الأسلوب مع دوال Lambda). من الخيارات الناشئة تقييد الوصول إلى خدمة البيانات الوصفية من الأساس. ورغم وجود بعض المحاولات للقيام بذلك باستخدام IPTables، فقد يؤدي ذلك أيضًا إلى تعطيل وظائف مطلوبة للشيفرة التي تُشغّلونها على المثيل. في نوفمبر 2018 تعاونت AWS مع Netflix وبدأتا بإضافة بيانات المستخدم لاستدعاءات API الصادرة من حِزم AWS SDK إلى ترويسات HTTP. وهذا دفاع ضد هجمات SSRF لأن معظمها يعتمد على خداع التطبيق ليُصدر طلبات HTTP نيابةً عن المهاجم، لكن تلك الطلبات تأتي عادةً من أداة سطر أوامر مثل curl أو من عملية أخرى وستفتقر إلى ترويسة بيانات المستخدم التي تأتي من حِزم AWS SDK. ولتحقيق ذلك تحتاجون إلى إدراج وكيل لتلك الطلبات. وهناك بعض الخيارات مفتوحة المصدر للمثيلات والحاويات، بما في ذلك وكلاء يعملون على المثيل نفسه بدلًا من إلزامكم بتوجيه حركة البيانات إلى جهاز افتراضي أو وكيل squid.

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

يمكنكم الاطلاع على كل التفاصيل في هذه التدوينة من Netflix.

الحماية من الاستخدام المزدوج للدور

• التعقيد: عالية
• الفعالية: عالية
• قابلية التوسع: عالية
• النوع: كشفي

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

الخلاصة

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

• اكتشاف واستغلال ثغرة في مثيل أو حاوية أو دالة Lambda تتيح له الوصول إلى بيانات اعتماد الدور. وهذا يكون دائمًا تقريبًا خطأً من جانب العميل… مثل إهمال التصحيح، أو فتح المنافذ الخاطئة، أو نشر شيفرة بها ثغرات.
  • إدارة الثغرات (بما في ذلك أدوات مثل SASST وDAST للتطبيقات) وتقييم تهيئة السحابة لديكم (باستخدام أدوات مثل DisruptOps أو أدوات مفتوحة المصدر مثل Prowler وCloudMapper) هما خط دفاعكم الأول.
• استخراج بيانات اعتماد الدور الحالية.
  • حماية خدمة البيانات الوصفية وإدارة الثغرات
• تشغيل استدعاءات API المسموح بها بنجاح في بيئة تحت سيطرته.
  • اكتشاف الاستخدام المزدوج للدور، استخدام قيود شرطية على عنوان IP أو VPC أو غيرها من مصادر الطلب في سياسات الأذونات، استخدام نقاط نهاية الخدمة مع السياسات + سياسات الموارد
• القيام بعمل ضار ضمن نطاق سياسة الأذونات الخاصة بدور IAM المسموح به. أعني، ضار على الأرجح، فليس من المعتاد أن يقوم معظم المهاجمين بتصحيح شيفرتكم نيابةً عنكم.
  • سياسات أذونات IAM بأقل امتياز مع قيود على الموارد

نأمل أن يمنحكم ذلك صورة أوضح عن كيفية الحد من نجاح هذا النوع من الهجمات.