السياسات المستندة إلى الهوية مقابل المستندة إلى المورد

تأتي الصلاحيات في AWS من سياسات مرفقة في موضعين: بكيان هوية (مستخدم أو مجموعة أو دور)، أو بمورد (مثل حاوية S3 أو مفتاح KMS). تُعد معرفة النوع المنطبق وكيفية تفاعلهما أمرًا أساسيًا للاختبار، لأن الوصول بين الحسابات يعتمد كليًا على هذا التمييز.

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

تُرفق السياسة المستندة إلى الموارد مباشرةً بمورد، وتتضمن عنصر Principal لتسمية الجهة المسموح لها بالوصول. ومن أمثلتها سياسات حاويات S3 ومفاتيح KMS وقوائم SQS الانتظارية ووظائف Lambda. وهي تحدد من (Principal) وما الإجراء (Action) على ذلك المورد الواحد.

تمنح سياسة حاوية S3 هذه حسابًا آخر صلاحية القراءة. ويحدد Principal الحساب الموثوق، وهو أمر لا يمكن أن تفعله إلا سياسة مستندة إلى الموارد.

ضمن الحساب الواحد، تتحد السياسات المستندة إلى الهوية والسياسات المستندة إلى الموارد في صورة اتحاد: يُسمح بالطلب إذا منحته أي منهما (ما لم يرفضه شيء). لذلك يمكن الوصول إلى كائن S3 إذا سمحت به سياسة المستخدم أو سياسة الحاوية. ويكفي أن يفتح أي من الجانبين الوصول.

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

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

لا تدعم كل الخدمات السياسات المستندة إلى الموارد. ومن أهم الخدمات التي تدعمها: S3 وKMS وSQS وSNS وLambda وSecrets Manager وECR. عندما تفتقر خدمة ما إلى سياسات الموارد، يجب منح الوصول بين الحسابات عبر افتراض دور بدلًا من ذلك. وقد يختبرك الاختبار في ما إذا كان النهج المختار ممكنًا أصلًا لخدمة معينة.

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

بما أن الوصول قد يأتي من أي من الجانبين، يتطلب التدقيق التحقق من كليهما. تفحص IAM Access Analyzer السياسات المستندة إلى الموارد للعثور على الموارد المشتركة خارجيًا أو المتاحة للعامة. وتساعد محاكاة السياسات وبيانات آخر وصول في فحص جانب الهوية. ولا تكتمل المراجعة بالنظر إلى نوع واحد فقط.

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

اختبر قدرتك على تحليل نوع السياسة.

تُرفق السياسات المستندة إلى الهوية بالكيانات الأصلية ولا تحتوي على عنصر Principal، بينما تُرفق السياسات المستندة إلى الموارد بالموارد وتسمّي Principal. ويكون الوصول داخل الحساب نفسه اتحادًا بين النوعين، أما الوصول بين الحسابات فيتطلب سماح كليهما. لا تدعم سياسات الموارد إلا بعض الخدمات (S3 وKMS وSQS وSNS وLambda وSecrets Manager وECR)، وإلا فاستخدم افتراض الدور.