{"id":"l-aws-2-3","courseId":"aws-cloud-foundations","lang":"ar","kind":"lesson","summary":"امنح الأشخاص الوصول عبر IAM Identity Center، وامنح الكود الوصول عبر الـ roles في IAM، كي يعمل Lantern دون أي مفاتيح وصول طويلة الأمد على الحواسيب أو الخوادم أو في Git.","html":"

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

\n

الأشخاص: IAM Identity Center

\n

AWS IAM Identity Center هو المكان الذي يسجّل فيه فريق عملك الدخول. يحصل كل شخص على هوية واحدة، إما في الدليل المدمج في Identity Center أو مُزامَنة من مزوّد هوية مثل Microsoft Entra ID أو Okta أو Google Workspace. يسجّل الشخص الدخول مرة واحدة، مع MFA، عبر رابط بوابة وصول AWS (AWS access portal)، فيرى كل حساب مسموح له بدخوله.

\n

ما يستطيع فعله في كل حساب يأتي من حزم الصلاحيات (permission sets): حزمة مسمّاة من السياسات، مثل DeveloperAccess أو ReadOnly. عندما تُسند “المتطوّعة Rita، حزمة الصلاحيات DeveloperAccess، الحساب lantern-dev”، ينشئ Identity Center role مطابقًا في ذلك الحساب، وتتقمّصه جلسة Rita. لا أحد لديه مستخدم IAM؛ ولا أحد لديه مفتاح طويل الأمد.

\n

صُمِّم Identity Center ليعمل مع AWS Organizations، الذي يجمع حسابات Lantern تحت حساب إدارة واحد. انتبه إلى عقبة عملية واحدة: في خطة الحساب المجانية، يؤدّي الانضمام إلى مؤسسة (organisation) إلى ترقية الحساب إلى الخطة المدفوعة، لذا فهذه خطوة لوقت انتقال Lantern إلى الإنتاج.

\n

في الـ CLI، يكتب aws configure sso الـ profile، ويفتح aws sso login المتصفّح لتسجيل الدخول:

\n
~/.aws/config
[sso-session lantern]\nsso_start_url = https://lantern.awsapps.com/start\nsso_region = eu-west-1\nsso_registration_scopes = sso:account:access\n\n[profile lantern-dev]\nsso_session = lantern\nsso_account_id = 444455556666\nsso_role_name = DeveloperAccess\nregion = eu-west-1
\n
Terminal
aws sso login --sso-session lantern\naws sts get-caller-identity --profile lantern-dev
\n

الـ Arn الذي يعود الآن يُقرأ assumed-role/AWSReservedSSO_DeveloperAccess_…/rita: جلسة role، لا مستخدم.

\n

أحمال العمل: roles لا مفاتيح

\n

يحتاج الكود إلى بيانات اعتماد أيضًا، والجواب دائمًا role تتقمّصه المنصّة نيابة عنك:

\n\n

للـ role سياستان دائمًا. سياسة الثقة (trust policy) تحدّد من يحق له تقمّصه:

\n
trust-policy.json
{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Principal\": { \"Service\": \"lambda.amazonaws.com\" },\n      \"Action\": \"sts:AssumeRole\"\n    }\n  ]\n}
\n

وسياسة الصلاحيات (permissions policy) تحدّد ما يحق للـ role فعله بعد تقمّصه، وتُكتب تمامًا مثل سياسات الدرس السابق.

\n
\n تطلب خدمة Lambda من STS تقمّص الـ role المسمّى lantern-rsvp. يفحص STS سياسة الثقة ويعيد بيانات اعتماد مؤقتة. يستخدمها كود الدالة لاستدعاء DynamoDB، حيث يفحص IAM سياسة صلاحيات الـ role.\n \n Lambda\n دالة rsvp\n \n AWS STS\n يفحص سياسة الثقة\n \n DynamoDB\n يفحص الصلاحيات\n \n 1 AssumeRole\n \n 2 بيانات اعتماد مؤقتة\n \n 3 PutItem موقَّع\n
تتقمّص Lambda الـ execution role الخاص بها، ثم تستدعي DynamoDB ببيانات اعتماد مؤقتة
\n

عندئذٍ لا يحتوي الكود الخاص بك على أي بيانات اعتماد على الإطلاق. تستخدم حزم AWS SDK سلسلة بيانات اعتماد افتراضية (default credential chain) تعثر على بيانات اعتماد الـ role المؤقتة تلقائيًا:

\n
rsvp/index.mjs
import { DynamoDBClient } from \"@aws-sdk/client-dynamodb\";\n\n// No keys here: the SDK finds the execution role's temporary credentials.\nconst client = new DynamoDBClient({});\n// …handler code that calls client.send(…)
\n

الخطأ الذي ينتهي بفاتورة ضخمة

\n\n

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

\n

التخلّص من مفتاح موجود تسلسل دقيق، لأن حذف مفتاح ما زال شيء ما يستخدمه يعطّل الإنتاج. تحقّق من آخر مرة استُخدم فيها:

\n
Terminal
aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE
\n

بمجرد أن يثبت أن لا شيء استخدمه منذ تشغيل البديل، عطّله أولًا (وهذا قابل للتراجع)، وانتظر، ولا تحذفه إلا حين لا يشكو شيء. أما المفتاح الذي تشكّ في تسرّبه فأمره مختلف: عطّله فورًا، ثم حقّق في الأمر بعد ذلك.

\n\n

بهذا تكتمل الهوية. يضعها القسم الثالث موضع التطبيق وأنت تختار قطع الحوسبة والتخزين وقاعدة البيانات والشبكة لـ Lantern.

\n","toc":[{"id":"sec-1","text":"الأشخاص: IAM Identity Center","level":2},{"id":"sec-2","text":"أحمال العمل: roles لا مفاتيح","level":2},{"id":"sec-3","text":"الخطأ الذي ينتهي بفاتورة ضخمة","level":2}],"takeaways":["يمنح IAM Identity Center كل شخص تسجيل دخول واحدًا، مع MFA، إلى كل حساب يحتاجه، ويوزّع بيانات اعتماد قصيرة الأمد عبر حزم الصلاحيات (permission sets).","تحصل أحمال العمل على صلاحياتها من الـ roles، مثل الـ execution role في Lambda أو الـ instance profile في EC2، وتعثر حزم AWS SDK على بيانات الاعتماد المؤقتة هذه دون أي كود.","للـ role سياستان؛ سياسة الثقة تحدّد من يحق له تقمّصه، وسياسة الصلاحيات تحدّد ما يحق له فعله بعد ذلك.","مفاتيح الوصول طويلة الأمد في الكود أو ملفات الإعداد أو متغيّرات البيئة من أكثر الطرق شيوعًا لاختراق حسابات AWS.","عند التخلّص من مفتاح وصول قديم، تأكّد من أنه غير مستخدم عبر تاريخ آخر استخدام له، ثم عطّله، ولا تحذفه إلا بعد ذلك."],"further":[{"title":"What is IAM Identity Center?","url":"https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html"},{"title":"Configuring IAM Identity Center authentication with the AWS CLI","url":"https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html"},{"title":"Defining Lambda function permissions with an execution role","url":"https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html"},{"title":"Manage access keys for IAM users","url":"https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html"}],"quiz":[{"q":"

يجب أن تكتب دالة تأكيد الحضور في Lantern إلى DynamoDB. كيف يجب أن تحصل على بيانات الاعتماد؟

","options":[{"text":"خزّن مفتاح وصول لمستخدم IAM في متغيّرات البيئة الخاصة بالدالة.","why":"كل من يستطيع قراءة إعدادات الدالة يستطيع قراءة المفتاح، وهو لا تنتهي صلاحيته أبدًا. متغيّرات البيئة ليست مخزنًا للأسرار."},{"text":"امنح الدالة execution role بسياسة صلاحيات للجدول؛ وتلتقط الـ SDK بيانات اعتماده المؤقتة.","why":"صحيح. تتقمّص Lambda الـ role نيابة عنك وتسلّم كل بيئة تنفيذ بيانات اعتماد قصيرة الأمد، فلا يوجد ما يتسرّب أو يحتاج إلى تدوير."},{"text":"استخدم بيانات اعتماد مستخدم الجذر، لأن الدالة تحتاج إلى وصول موثوق.","why":"بيانات اعتماد الجذر غير مقيّدة ولا يجب أن توجد كمفاتيح وصول أصلًا، فضلًا عن وجودها داخل الكود."}],"answer":1},{"q":"

سياسة الصلاحيات الخاصة بـ role تسمح بـ dynamodb:PutItem على جدول تأكيدات الحضور، لكن الـ instances في EC2 تفشل في تقمّص الـ role. أيّ سياسة هي الخاطئة على الأرجح؟

","options":[{"text":"سياسة الثقة، التي يجب أن تسمّي ec2.amazonaws.com كـ principal مسموح له باستدعاء sts:AssumeRole.","why":"صحيح. من يحق له تقمّص الـ role تقرّره سياسة الثقة وحدها. أما سياسة الصلاحيات فلا تهمّ إلا بعد تقمّص الـ role."},{"text":"سياسة الصلاحيات، التي يجب أن تسمح أيضًا بـ sts:AssumeRole.","why":"لا يحتاج الـ role إلى صلاحية لتقمّص نفسه. هذه مهمة سياسة الثقة."},{"text":"سياسة جدول DynamoDB، التي يجب أن تسرد معرّف الـ instance في EC2.","why":"الـ instance ليست أبدًا الـ principal في استدعاءات DynamoDB؛ بل جلسة الـ role المتقمَّص. ثم إن التقمّص يفشل قبل أن تدخل DynamoDB في الصورة."}],"answer":0},{"q":"

لدى Lantern الآن حسابان منفصلان للتطوير والإنتاج وستة متطوّعين. ما أفضل طريقة لمنح المتطوّعين وصولًا إلى الـ console والـ CLI؟

","options":[{"text":"مستخدم IAM لكل متطوّع في كل حساب، لكلٍّ منهم كلمة مرور وMFA خاصان به.","why":"هذه اثنتا عشرة مجموعة من بيانات الاعتماد عليك إدارتها وإلغاؤها. الطريقة تعمل، لكنها لا تتوسّع جيدًا وتخلّف وراءها بيانات اعتماد طويلة الأمد."},{"text":"مستخدم IAM واحد مشترك لكل حساب بكلمة مرور قوية محفوظة في مدير كلمات مرور.","why":"المستخدمون المشتركون يقضون على المساءلة، ويجعلون إزالة شخص واحد مستحيلة دون تغيير وصول الجميع."},{"text":"مستخدمون في IAM Identity Center، مع حزم صلاحيات مسندة لكل حساب، يسجّلون الدخول عبر بوابة الوصول وaws sso login.","why":"صحيح. لكل شخص هوية واحدة وMFA، والوصول قصير الأمد، وإزالة أي شخص تغيير واحد."}],"answer":2}],"exercise":{"kind":"order","items":["write-policy","create-role","attach-profile","remove-keys","verify-identity","check-last-used","deactivate","delete"],"title":"تخلّص من مفتاح وصول المهمة الليلية","prompt":"

تعمل مهمة التصدير الليلية في Lantern على instance في EC2 وتقرأ مفتاح وصول من /etc/lantern/.env. المفتاح لم يتسرّب؛ وأنت تستبدله بـ role خلال أسبوع هادئ، دون تعطيل المهمة. رتّب الخطوات ترتيبًا آمنًا.

\n","hints":["يجب أن يوجد الـ role، بالصلاحيات الصحيحة، قبل أن يستطيع أي شيء استخدامه.","أثبت أن المهمة تعمل بالـ role قبل أن تلمس المفتاح القديم.","إزالة الوصول تتم على مرحلتين: واحدة قابلة للتراجع، وأخرى نهائية."],"explanation":"

تبني البديل أولًا: سياسة صلاحيات بأقل الصلاحيات، وrole تسمح سياسة الثقة الخاصة به بـ ec2.amazonaws.com، وinstance profile يضع الـ role على الـ instance. ثم تزيل المفتاح من الـ instance كي تنتقل الـ SDK إلى بيانات اعتماد الـ role، وتثبت ذلك بتشغيل aws sts get-caller-identity على الـ instance، ويجب أن يُظهر ARN من نوع assumed-role. عندها فقط تنظر في المفتاح القديم: يؤكّد get-access-key-last-used أن لا شيء استخدمه منذ التبديل. التعطيل قابل للتراجع إذا تعطّل شيء نسيته؛ أما الحذف فنهائي، لذا يأتي أخيرًا. لو كان المفتاح قد تسرّب، لعطّلته أولًا، فورًا، وتقبّلت التعطّل.

\n","checkLabels":{},"itemText":{"write-policy":"اكتب سياسة صلاحيات بأقل الصلاحيات لما تفعله مهمة التصدير بالضبط.","create-role":"أنشئ role بسياسة ثقة لـ ec2.amazonaws.com وأرفق به سياسة الصلاحيات.","attach-profile":"أرفق الـ role بالـ instance في EC2 عبر instance profile.","remove-keys":"أزل مفتاح الوصول من /etc/lantern/.env وأعد تشغيل المهمة.","verify-identity":"على الـ instance، شغّل aws sts get-caller-identity وتأكّد من أن الـ ARN جلسة من نوع assumed-role.","check-last-used":"شغّل aws iam get-access-key-last-used بعد التشغيل الليلي التالي لتتأكّد من أن المفتاح القديم خامل.","deactivate":"عطّل مفتاح الوصول القديم وراقب التشغيلات القليلة التالية.","delete":"احذف مفتاح الوصول القديم."}},"words":631,"readMinutes":4}