المعرّف الخارجي والوكيل المربك

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

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

تخيلوا خدمة SaaS للمراقبة تفترض دورًا في حساب كل عميل. تستخدم خدمة SaaS هوية AWS واحدة للجميع. وإذا خمّن مهاجم هو أيضًا أحد العملاء معرّف ARN لدوركم، فقد يقنع خدمة SaaS بافتراض دوركم، لأن خدمة SaaS هي المبدأ الموثوق. ولا يكفي معرّف الحساب وحده لمنع ذلك.

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

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

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

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

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

ينطبق نمط الوكيل المربك أيضًا على خدمات AWS التي تعمل نيابةً عنكم. وغالبًا ما تستخدم الثقة بين الخدمات شروطًا مثل aws:SourceArn وaws:SourceAccount في سياسات الموارد للتأكد من أن الخدمة المستدعية تعمل لصالح موردكم، وهي الفكرة الدفاعية نفسها في سياق مختلف.

كلما وصف السؤال طرفًا ثالثًا أو خدمة SaaS تفترض دورًا عبر الحسابات، فغالبًا ما تتضمن الإجابة الآمنة معرّفًا خارجيًا في سياسة الثقة. وإذا كان السيناريو بين الخدمات، فابحثوا بدلًا من ذلك عن شرطي aws:SourceArn/aws:SourceAccount. ويساعدكم تمييز الإشارة في الوصول مباشرةً إلى الإجراء الصحيح.

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

اختبروا مفهوم الوكيل المربك.

تنشأ مشكلة الوكيل المربك عندما يُخدع طرف ثالث موثوق ليسيء استخدام وصوله عبر الحسابات. ويمنعها المعرّف الخارجي، الفريد لكل عميل والخاضع لتحكم المورّد، من خلال شرط في سياسة الثقة يستند إلى sts:ExternalId. وبالنسبة إلى الثقة بين خدمات AWS، استخدموا aws:SourceArn وaws:SourceAccount، مع الالتزام دائمًا بالحد الأدنى من الصلاحيات.