سياسات الثقة ومن يمكنه تولّي الدور

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

يمكن لعنصر Principal في سياسة الثقة أن يشير إلى:

• AWS — حساب أو مستخدم أو ARN لدور (Amazon Resource Name).
• Service — خدمة AWS مثل lambda.amazonaws.com.
• Federated — موفّر SAML أو موفّر هوية الويب.

يُعد اختيار نوع principal الصحيح وتحديده بدقة أمرًا أساسيًا لتجنب منح ثقة أكبر من المقصودة.

يتطلب تولّي الدور بين الحسابات موافقة الطرفين. يجب أن تسمح سياسة الثقة للدور في الحساب المستهدف بالـprincipal المستدعي، ويجب أيضًا أن يملك ذلك الـprincipal سياسة هوية تسمح بإجراء sts:AssumeRole على ARN الدور. ويؤدي غياب أي من الجزأين إلى حظر الطلب. وتُعد هذه المصافحة ذات الاتجاهين من أسئلة الخداع الشائعة في الاختبار.

تسمح سياسة الثقة هذه لدور محدد في الحساب 111122223333 بتولّي الدور. ويُعد ذكر ARN دقيق بدلًا من الحساب بأكمله أكثر تقييدًا وأمانًا.

يؤدي تحديد principal بالشكل arn:aws:iam::ACCOUNT:root إلى الوثوق بـالحساب بأكمله: إذ يمكن لأي principal فيه يملك أيضًا صلاحية sts:AssumeRole تولّي الدور. وهذا واسع النطاق. وحيثما أمكن، اذكر ARN المستخدم أو الدور المحدد لتحقيق مبدأ أقل صلاحية وتقليص نطاق الثقة.

تدعم سياسات الثقة كتل Condition لتقييد من يمكنه التولّي وكيفية ذلك. ومن المفاتيح الشائعة sts:ExternalId (لمنع مشكلة الوكيل المربك)، وaws:MultiFactorAuthPresent (لفرض MFA)، وaws:SourceIp. وتتيح لك الشروط منح صلاحية التولّي في ظروف محددة وقابلة للتحقق فقط.

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

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

تكون الثقة بـprincipal داخلي (في الحساب نفسه) عمومًا أقل خطورة من الثقة بـحساب خارجي أو مورّد SaaS تابع لجهة خارجية. وبالنسبة إلى الثقة الخارجية، اجمع دائمًا بين principal محدد وشروط مثل ExternalId. وتعامل مع كل عبارة ثقة خارجية باعتبارها نقطة دخول يود المهاجم استغلالها.

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

لتصميم الثقة بأمان: سمِّ principal الأكثر تحديدًا الممكن، وأضف شروطًا مثل ExternalId وMFA عند الاقتضاء، وفضّل الأدوار على الثقة بجذر الحساب، وراجع الإعداد باستخدام Access Analyzer. تذكّر أن سياسة الثقة تجيب عن سؤال من، بينما تجيب سياسات الصلاحيات عن سؤال ما؛ ويجب أن يتوافق كلاهما حتى يعمل الوصول ويحافظ على مبدأ أقل صلاحية.

اختبر معرفتك بسياسات الثقة.

تحدد سياسة الثقة أي principals يمكنها تولّي دور، وهي حارس البوابة بغض النظر عن سياسات الصلاحيات. ويتطلب التولّي بين الحسابات مصافحة ذات اتجاهين: سياسة الثقة بالإضافة إلى صلاحية sts:AssumeRole لدى المستدعي. فضّل ARN لـprincipal محددًا على جذر الحساب، وأضف شروطًا مثل ExternalId وMFA، ودقّق باستخدام IAM Access Analyzer.