ملفات تعريف المثيلات لأعباء EC2

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

ملف تعريف المثيل هو حاوية لدور IAM تُرفق بمثيل EC2. وعلى الرغم من أنك تعيّن دورًا من الناحية المفاهيمية، فإن EC2 يرفق فعليًا ملف تعريف المثيل الذي يغلّف ذلك الدور. وعند إنشاء دور لـ EC2 في وحدة التحكم، يُنشأ تلقائيًا ملف تعريف مثيل بالاسم نفسه؛ أما باستخدام CLI أو API، فقد تحتاج إلى إنشائه صراحةً.

بعد إرفاق ملف تعريف المثيل، يستطيع المثيل استرداد بيانات الاعتماد المؤقتة من Instance Metadata Service (IMDS)، وهو endpoint خاص بالرابط المحلي على العنوان 169.254.169.254. وتجلب AWS SDK وCLI بيانات الاعتماد هذه وتحدّثها بشفافية، لذا لا تتعامل شيفرة التطبيق مع المفاتيح إطلاقًا.

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

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

كان من الممكن إساءة استخدام خدمة بيانات التعريف الأصلية (IMDSv1) عبر هجمات SSRF (تزوير الطلبات من جانب الخادم) لسرقة بيانات اعتماد الدور. يتطلب IMDSv2 الحصول أولًا على رمز جلسة عبر طلب PUT، ما يحظر معظم عمليات استغلال SSRF. يتوقع الاختبار منك فرض استخدام IMDSv2، ومن الأفضل ضبط حد القفزات على 1 لمنع الحاويات من الوصول إليها.

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

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

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

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

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

تحقق من معرفتك بملفات تعريف المثيلات.

يغلّف ملف تعريف المثيل دور IAM ويرفقه بـ EC2، مقدمًا بيانات اعتماد مؤقتة يتم تدويرها تلقائيًا عبر خدمة بيانات تعريف المثيل. يؤدي ذلك إلى إزالة المفاتيح الثابتة بالكامل. افرض استخدام IMDSv2 وحد قفزات يساوي 1 لحظر سرقة بيانات الاعتماد عبر SSRF، وقيّد نطاق الدور وفق مبدأ أقل صلاحية، ودقّق جلساته في CloudTrail.