AWS SAA 03 - Securing Access

🎯 Securing Access — تأمين الوصول

يُعد الأمان أولوية قصوى في أي بنية سحابية، وفهم مبادئ تأمين الوصول هو الخطوة الأولى نحو بناء بيئة آمنة. يستعرض هذا المقال مبادئ الأمان الأساسية في AWS، بما في ذلك إدارة الهوية والوصول (IAM) والسياسات والمصادقة والتفويض، لضمان حماية مواردك السحابية من الوصول غير المصرح به.

1️⃣ Security Principles — مبادئ الأمان (Security Principles)

📖 ما هي مبادئ الأمان في AWS؟
هي الأساس الذي تبنى عليه كل استراتيجيات الحماية في السحابة، وتتضمن ثلاثة مبادئ مترابطة تشكل حجر الزاوية لأي بنية آمنة.

📋 المبادئ الثلاثة الرئيسية:

• فهم نموذج المسؤولية المشتركة (Shared Responsibility Model) لمعرفة من المسؤول عن ماذا.
• استخدام ركيزة الأمان (Security Pillar) من إطار العمارة الجيدة (Well-Architected Framework).
• تطبيق مبدأ الامتياز الأقل (Least Privilege) عند تأمين موارد AWS.

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

2️⃣ AWS Shared Responsibility Model — نموذج المسؤولية المشتركة (AWS Shared Responsibility Model)

📖 ما هو نموذج المسؤولية المشتركة؟
هو الإطار الذي يوضح تقسيم مهام الأمان بين AWS والعميل: AWS مسؤولة عن أمان السحابة، والعميل مسؤول عن الأمان داخل السحابة.

📋 تقسيم المسؤوليات:

• أمان السحابة (Security OF the Cloud): مسؤولية AWS عن البنية التحتية الأساسية — مراكز البيانات، الشبكات، الأجهزة، الخوادم الفيزيائية، وطبقة المراقب الافتراضي (hypervisor).
• الأمان داخل السحابة (Security IN the Cloud): مسؤولية العميل عن بيانات العملاء، التطبيقات، أنظمة التشغيل، إعدادات الشبكة والجدار الناري، التشفير، وإدارة الهوية والوصول.
• AWS تؤمن الأساس وأنت تبني عليه — كل طرف له دوره المحدد بوضوح.

شركة تستخدم EC2 لاستضافة تطبيقها. AWS مسؤولة عن أمان الخادم الفيزيائي ومركز البيانات.
الشركة مسؤولة عن: تحديث نظام التشغيل على EC2، تكوين مجموعات الأمان (Security Groups)، تشفير البيانات، وإدارة IAM.
لو حدث اختراق بسبب عدم تحديث نظام التشغيل، فالشركة هي المسؤولة وليس AWS.

3️⃣ Security Pillar — ركيزة الأمان في إطار العمارة الجيدة (Security Pillar)

📖 ما هي ركيزة الأمان في إطار العمارة الجيدة؟
هي إحدى الركائز الست للإطار الذي يوفر أفضل الممارسات لمساعدتك في تصميم بنية آمنة ومستدامة على AWS.

📋 الركائز الست لإطار العمارة الجيدة:

• الأمان (Security) إلى جانب التميز التشغيلي (Operational Excellence)، والموثوقية (Reliability)، وكفاءة الأداء (Performance Efficiency).
• تحسين التكلفة (Cost Optimization) والاستدامة (Sustainability).
• أداة AWS Well-Architected Tool هي خدمة مجانية تقيم بنيتك بناءً على الركائز الست وتقدم خطة عمل للتحسين.

شركة استشارات تجري مراجعة العمارة الجيدة (Well-Architected Review) لعملائها كل ستة أشهر.
لكل عميل، يحدد الفريق الأحمال في الأداة ويجيب على 60 سؤالاً.
الأداة تُولّد تقريراً بالمخاطر العالية والمتوسطة، ويقدم الفريق خطة عمل.
هذه العملية تحسّن بنية العميل بشكل مستمر.

4️⃣ Design Principles — مبادئ التصميم لركيزة الأمان (Design Principles)

📖 ما هي مبادئ التصميم السبعة لركيزة الأمان؟
هي المبادئ التي يجب تطبيقها لتحقيق أعلى مستوى من الحماية في بيئتك السحابية عبر طبقات أمان متعددة.

📋 مبادئ التصميم السبعة:

• تطبيق أساس هوية قوي: تطبيق مبدأ الامتياز الأقل وفصل المهام.
• حماية البيانات أثناء النقل وأثناء التخزين: تصنيف البيانات حسب الحساسية وتطبيق التشفير.
• تطبيق الأمان على كل الطبقات: استخدام الدفاع في العمق (defense in depth) مع ضوابط متعددة.
• إبعاد الناس عن البيانات: تقليل الوصول اليدوي للبيانات.
• الحفاظ على إمكانية التتبع: مراقبة كل التغييرات في الوقت الفعلي.
• التحضير للأحداث الأمنية: الاستعداد للحوادث عبر سياسات الاستجابة للحوادث (incident response).
• أتمتة أفضل ممارسات الأمان: استخدام البنية التحتية كرمز (Infrastructure as Code) لأتمتة الأمان.

شركة تطبق كل المبادئ السبعة.
الهوية: IAM مع المصادقة متعددة العوامل (MFA) إجباري.
التشفير: خدمة إدارة المفاتيح (KMS) لكل البيانات.
الطبقات: WAF + مجموعات الأمان + NACLs.
إبعاد الناس: لا وصول مباشر لقواعد البيانات.
التتبع: CloudTrail + CloudWatch.
الأحداث: فريق الاستجابة للحوادث يجتمع شهرياً.
الأتمتة: Security Hub يفحص البنية آلياً.

5️⃣ User Permissions — صلاحيات المستخدم للوصول للموارد (User Permissions to Access Resources)

📖 كيف نتحكم بصلاحيات المستخدم للوصول إلى الموارد؟
عبر استخدام السياسات لمنح أو رفض الوصول إلى موارد AWS مثل حاويات S3 وجداول DynamoDB بناءً على الصلاحيات المطلوبة لكل دور.

📋 آلية عمل الصلاحيات:

• يمكن تحديد صلاحيات مختلفة لمستخدم واحد على موارد مختلفة: قراءة وكتابة وحذف على حاوية أولى، قراءة فقط على حاوية ثانية.
• الصلاحيات تُعرّف عبر سياسات IAM بصيغة JSON.
• كل صلاحية مرتبطة بمورد محدد عبر اسم مورد أمازون (ARN).

تطبيق تجارة إلكترونية يحتاج ثلاث صلاحيات: موظفو التسويق (قراءة ملفات الوسائط فقط)، موظفو التطوير (قراءة وكتابة على حاوية التطوير)، ومديرو النظام (صلاحيات كاملة).
مهندس السحابة ينشئ ثلاث سياسات IAM، كل واحدة تخدم مجموعة.
كل موظف يرى فقط ما يحتاجه.

6️⃣ Least Privilege — مبدأ الامتياز الأقل (Principle of Least Privilege)

📖 ما هو مبدأ الامتياز الأقل؟
هو أحد أهم ممارسات الأمان في AWS الذي يطلب منح المستخدم فقط الصلاحيات المطلوبة لأداء مهمته، لا أكثر ولا أقل.

📋 قواعد تطبيق المبدأ:

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

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

🔑 نصيحة أساسية: مبدأ least privilege يعني منح المستخدمين والخدمات فقط الصلاحيات التي يحتاجونها لأداء عملهم — لا أكثر ولا أقل. استخدم IAM Access Analyzer لمراجعة الصلاحيات وتحديد أي صلاحيات زائدة. الأداة تحلل السياسات وتُظهر الموارد المُشاركة خارجياً والتي قد تكون مكشوفة عن غير قصد.

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

7️⃣ Encryption — استخدام التشفير (Use Encryption)

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

📋 حماية البيانات أثناء النقل:

• البيانات أثناء النقل (Data in transit) هي البيانات المنتقلة من مكان إلى آخر عبر الإنترنت أو شبكة خاصة.
• لحمايتها نستخدم طبقة النقل الآمنة (TLS) التي تضمن عدم إمكانية قراءة البيانات حتى لو اعترضها مهاجم.
• في AWS، كل الخدمات تستخدم TLS افتراضياً.

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

8️⃣ Client-side Encryption — حماية البيانات المخزنة بتشفير من جانب العميل (Protecting Data at Rest with Client-Side Encryption)

📖 ما هو التشفير من جانب العميل؟
أسلوب يقوم فيه العميل بتشفير البيانات قبل إرسالها إلى AWS، مما يعني أن AWS لا ترى البيانات الأصلية أبداً، ويوفر أعلى مستوى من الحماية الشاملة.

📋 خصائص التشفير من جانب العميل:

• العميل يشفر البيانات قبل إرسالها إلى AWS ويفك تشفيرها عند استرجاعها.
• AWS لا ترى البيانات الأصلية أبداً — حماية شاملة (end-to-end).
• الميزة: أعلى مستوى من الحماية.
• العيب: العميل يتحمل مسؤولية إدارة المفاتيح.

موظف يخزن ملفات الشركة على قرص خارجي.
يشفر القرص بأداة BitLocker وهي تشفير من جانب العميل.
لو فُقد القرص أو سُرق، لا يستطيع أحد قراءة الملفات بدون كلمة المرور.
البيانات مشفرة سواء في حالة التخزين أو النقل.

9️⃣ Server-side Encryption — حماية البيانات المخزنة بتشفير من جانب الخادم (Protecting Data at Rest with Server-Side Encryption)

📖 ما هو التشفير من جانب الخادم؟
أسلوب تشفر فيه AWS البيانات تلقائياً على مستوى الكائن عند كتابتها على الأقراص، وتفك تشفيرها عند الوصول إليها دون أي إجراء يدوي من المطور.

📋 خصائص التشفير من جانب الخادم:

• Amazon S3 يوفر تشفيراً من جانب الخادم (SSE-S3) افتراضياً.
• الخدمة تشفر بياناتك على مستوى الكائن عند كتابتها وتفك تشفيرها تلقائياً عند وصولك إليها.
• لا يحتاج المطور لأي إجراء يدوي — أبسط من تشفير جانب العميل.
• العيب: AWS تستطيع رؤية البيانات الأصلية.

مستشفى يخزن سجلات المرضى في S3. S3 يشفر البيانات تلقائياً بخدمة SSE-S3. عندما يقرأ الطبيب سجل مريض، يفك S3 التشفير تلقائياً.
الطبيب لا يحتاج للتعامل مع التشفير.
المستشفى تستفيد من حماية التشفير دون أي تعقيد إضافي.

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

✅ خلاصة مبادئ الأمان في AWS:

• الأمان مسؤولية مشتركة: AWS تؤمن البنية التحتية والعميل يؤمن بياناته وتطبيقاته.
• ركيزة الأمان في إطار Well-Architected توفر سبعة مبادئ تصميم لأعلى مستوى حماية.
• مبدأ الامتياز الأقل هو القاعدة الذهبية: امنح فقط الصلاحيات الضرورية.
• التشفير يحمي البيانات أثناء النقل (TLS) وأثناء التخزين (Server-side أو Client-side).

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Shared Responsibility Model	نموذج المسؤولية المشتركة	تقسيم مسؤوليات الأمان بين AWS (أمان السحابة) والعميل (الأمان داخل السحابة).
Security OF the Cloud	أمان السحابة	مسؤولية AWS عن البنية التحتية الفيزيائية ومراكز البيانات والشبكات.
Security IN the Cloud	الأمان داخل السحابة	مسؤولية العميل عن البيانات والتطبيقات وأنظمة التشغيل و IAM.
Least Privilege	الامتياز الأقل	منح الحد الأدنى من الصلاحيات اللازمة لأداء المهمة فقط.
Data in Transit	البيانات أثناء النقل	البيانات المنتقلة عبر الشبكة، تُحمى باستخدام TLS.
Data at Rest	البيانات المخزنة	البيانات المخزنة على أقراص، تُحمى باستخدام التشفير.
Client-side Encryption	تشفير من جانب العميل	يشفر العميل البيانات قبل إرسالها، AWS لا ترى البيانات الأصلية.
Server-side Encryption	تشفير من جانب الخادم	تشفر AWS البيانات تلقائياً عند التخزين، وتفكها عند الطلب.

1️⃣ Authentication vs Authorization — المصادقة والتفويض (Authentication and Authorization)

📖 ما الفرق بين المصادقة والتفويض؟
المصادقة (Authentication) تثبت هوية الطالب (من أنت؟)، والتفويض (Authorization) يحدد الصلاحيات المسموح بها (ماذا تستطيع أن تفعل؟).

📋 الفرق بين المفهومين:

• المصادقة: تجيب على السؤال "من يطلب الوصول؟" عبر بيانات الاعتماد (اسم مستخدم، كلمة مرور، MFA).
• التفويض: يجيب على السؤال "ما الذي يُسمح له بفعله؟" عبر السياسات والصلاحيات.
• المصادقة تسبق التفويض دائماً — لا يمكن تفويض من لم تثبت هويته.

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

2️⃣ AWS IAM — خدمة AWS IAM (Identity and Access Management)

📖 ما هي خدمة IAM؟
هي الخدمة المركزية التي تتحكم في وصول الأفراد والمجموعات إلى موارد AWS بتكوين تحكم دقيق (fine-grained access control) يتبع أفضل ممارسات الأمان.

📋 مميزات IAM:

• تتيح تحكماً دقيقاً في الوصول إلى موارد AWS.
• آمنة افتراضياً: المستخدمون لا يملكون صلاحية الوصول حتى تُمنح لهم صراحةً.
• متكاملة مع معظم خدمات AWS.
• تدعم الهوية الموحدة (federated identity) مثل Active Directory والمصادقة متعددة العوامل.

شركة تدمج 200 موظف مع AWS عبر IAM Identity Center و Active Directory.
الموظفون يستخدمون نفس بيانات اعتماد الشركة.
عند دخولهم إلى AWS Console، يحصلون تلقائياً على الصلاحيات المناسبة لدورهم.
لا حاجة لإدارة 200 حساب IAM منفصل.

3️⃣ IAM Terminology — مصطلحات IAM (IAM Terminology)

📖 ما أهم مصطلحات IAM؟
هناك مفاهيم أساسية في IAM لكل منها دور محدد في إدارة الهوية والوصول، وفهمها ضروري للتعامل الصحيح مع الخدمة.

📋 المصطلحات الأساسية:

• مورد IAM (IAM resource): كائن مخزن في IAM (مستخدم، مجموعة، دور، سياسة، أو موفر هوية).
• كيان IAM (IAM entity): كائن IAM تستخدمه AWS للمصادقة (المستخدمون والأدوار فقط).
• هوية IAM (IAM identity): كائن IAM يمكن تفويضه في السياسات (مستخدم، مجموعة، أو دور).
• الموجه (Principal): الشخص أو التطبيق الذي يسجل الدخول ويقدم طلبات إلى AWS.

شركة تستخدم اتحاد SAML مع Okta.
الموظف Ahmed (موجه) يدخل إلى Okta (موفر الهوية).
يحصل على بيانات اعتماد مؤقتة ويفترض دور IAM (هوية IAM).
الدور يحدد الصلاحيات عبر سياسات (مورد).
كل مصطلح يخدم غرضاً محدداً في هذه السلسلة.

4️⃣ IAM Access Control — التحكم في الوصول عبر IAM (Using IAM to Control Access)

📖 ما الطرق الرئيسية للتحكم في الوصول عبر IAM؟
توفر IAM ثلاث طرق: مستخدم IAM ببيانات اعتماد دائمة، مجموعة IAM بصلاحيات موحدة، ودور IAM بصلاحيات مؤقتة.

📋 طرق التحكم الثلاث:

• مستخدم IAM (IAM user): شخص أو تطبيق يمكنه المصادقة باستخدام حساب AWS، يحصل على بيانات اعتماد دائمة.
• مجموعة IAM (IAM group): مجموعة من المستخدمين يُمنحون صلاحية موحدة لتسهيل الإدارة.
• دور IAM (IAM role): هوية تُستخدم لمنح مجموعة مؤقتة من الصلاحيات، لا يملك بيانات اعتماد دائمة.

شركة تريد تشغيل تطبيق على EC2 يحتاج للوصول إلى S3. لا تفضل الشركة إنشاء مفاتيح وصول للمثيل (غير آمنة).
تنشئ دور IAM بسياسة تسمح بقراءة S3. تربط الدور بمثيل EC2 عبر ملف تعريف المثيل (instance profile).
التطبيق يحصل على الصلاحيات تلقائياً دون مفاتيح وصول.

5️⃣ IAM Credentials — بيانات اعتماد IAM (IAM Credentials)

📖 ما أنواع بيانات الاعتماد في AWS؟
هناك نوعان رئيسيان: اسم المستخدم وكلمة المرور لواجهة الويب، ومفاتيح الوصول (access keys) للمصادقة البرمجية عبر CLI وSDKs.

📋 أنواع بيانات الاعتماد:

• اسم المستخدم وكلمة المرور: للدخول إلى AWS Management Console عبر الويب.
• مفتاح الوصول: مزيج من Access Key ID و Secret Access Key — يُستخدم لـ AWS CLI و AWS SDKs واستدعاءات API المباشرة.
• لا يمكن استخدام اسم المستخدم وكلمة المرور للمصادقة البرمجية.
• يجب تدوير مفاتيح الوصول بانتظام لأنها بيانات اعتماد طويلة الأجل.

مطور يعمل على سكريبت ينشر التطبيق تلقائياً.
يستخدم AWS CLI مع مفاتيح وصول مخزنة في ملف ~/.aws/credentials.
السكريبت ينفذ أوامر مثل aws s3 cp.
لا يحتاج لاسم مستخدم وكلمة مرور في هذه الحالة.
لتدوير المفاتيح، ينشئ مفتاحاً جديداً ويحذف القديم كل 90 يوماً.

6️⃣ Best Practices — أفضل ممارسات تأمين الوصول (Best Practices to Secure Access)

📖 ما أفضل ممارسات تأمين الوصول إلى AWS؟
مجموعة من المبادئ والإجراءات التي تضمن حماية حساباتك ومواردك من الوصول غير المصرح به وتقليل سطح الهجوم.

📋 أفضل الممارسات:

• اتبع مبدأ الامتياز الأقل.
• فعّل المصادقة متعددة العوامل (MFA).
• استخدم بيانات اعتماد مؤقتة عبر الدخول الموحد (SSO) أو Identity Center.
• درّور مفاتيح الوصول بانتظام واستخدم كلمات مرور قوية.
• استخدم AWS Organizations وفعّل CloudTrail لتتبع النشاط.
• لا تستخدم المستخدم الجذر (Root User) للمهام اليومية.

شركة تطبق كل هذه الممارسات.
المستخدم الجذر محمي بجهاز MFA مادي ويستخدم فقط لإنشاء الحساب.
جميع الموظفين يستخدمون IAM Identity Center مع SSO.
مفاتيح الوصول لا تُستخدم للتطبيقات بل تستخدم أدوار IAM بدلاً منها.
النتيجة: سطح هجوم ضيق جداً.

7️⃣ Root User — حماية المستخدم الجذر (Protecting the Root User)

📖 لماذا يجب حماية المستخدم الجذر؟
لأنه مالك حساب AWS بصلاحية كاملة غير محدودة لجميع الموارد، لذا يجب حماية بيانات اعتماده بأقصى درجة واستخدامه فقط للحالات الحرجة.

📋 قواعد التعامل مع المستخدم الجذر:

• يملك صلاحية كاملة غير محدودة لجميع الموارد — احمِ بيانات اعتماده كما تحمي رقم بطاقتك الائتمانية.
• للمهام اليومية استخدم مستخدماً إدارياً في IAM Identity Center مع بيانات اعتماد مؤقتة.
• استخدمه فقط للمهام التي لا يمكن لأي مستخدم آخر القيام بها: تغيير خطة الحساب، إغلاق الحساب، استعادة الوصول، تفعيل IAM للوصول للفواتير.

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

🔑 نصيحة أساسية: فعّل MFA (المصادقة متعددة العوامل) فوراً للمستخدم الجذر (Root User) ولكل مستخدمي IAM دون استثناء. كلمة المرور وحدها لم تعد كافية — أي اختراق لكلمة المرور بدون MFA يعني وصولاً كاملاً للمخترق. استخدم جهاز MFA مادي (U2F security key) للحسابات الحرجة، أو تطبيق Virtual MFA للمستخدمين العاديين. هذا الإجراء البسيط يمنع 99% من هجمات سرقة بيانات الاعتماد.

8️⃣ Admin Setup — خطوات إعداد مستخدم إداري (Steps to Set Up an Admin User)

📖 كيف نعد مستخدماً إدارياً بدلاً من المستخدم الجذر؟
باتباع خمس خطوات تبدأ بتسجيل الدخول كمستخدم جذر وتفعيل MFA، وتنتهي بإنشاء حسابات المستخدمين الآخرين بسياسات منفصلة.

📋 الخطوات الخمس:

• الخطوة ١: سجل الدخول كمستخدم جذر وقم بإعداد MFA على هذا الحساب.
• الخطوة ٢: أنشئ مستخدماً إدارياً جديداً (مثل John)، أضف MFA للمستخدم الجديد، وحمّل المفاتيح البرمجية.
• الخطوة ٣: سجل الخروج كمستخدم جذر.
• الخطوة ٤: سجل الدخول كمستخدم John.
• الخطوة ٥: أنشئ حسابات المستخدمين الآخرين مع سياسات منفصلة لكل واحد.

شركة جديدة تنشئ حساب AWS.
المستخدم الجذر ينشئ مستخدم IAM اسمه admin-jane مع صلاحيات AdministratorAccess. Jane تفعّل MFA على حسابها.
المستخدم الجذر يخرج ولا يُستخدم بعد ذلك. Jane تنشئ حسابات لكل فريق: مطور، تسويق، عمليات.
كل فريق يحصل على الصلاحيات التي يحتاجها فقط.

9️⃣ IAM Users and Groups — مستخدمي IAM والمجموعات (Best Practices: IAM Users and Groups)

📖 كيف نستخدم المجموعات لإدارة الصلاحيات بكفاءة؟
بإرفاق سياسات IAM بمجموعات IAM ثم تعيين المستخدمين إلى هذه المجموعات، يرث المستخدم العضو تلقائياً كل الصلاحيات المرفقة بالمجموعة.

📋 فوائد استخدام المجموعات:

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

شركة كبيرة تنشئ ثلاث مجموعات: المطورين (Developers)، والتسويق (Marketing)، والمديرين (Admins).
كل مجموعة لها سياستها.
عند انضمام موظف جديد للتسويق، يضاف إلى مجموعة Marketing فقط.
عند تغيير صلاحيات التسويق، تُعدّل السياسة في مجموعة Marketing وتنعكس على كل الأعضاء تلقائياً.

🔟 IAM Roles — أدوار IAM (IAM Roles)

📖 ما هو دور IAM وما أهميته؟
يوفر بيانات اعتماد أمان مؤقتة ولا يرتبط بشخص واحد — يُفترض من قبل شخص أو تطبيق أو خدمة عند الحاجة، وهو أكثر أماناً من مفاتيح الوصول الدائمة.

📋 خصائص واستخدامات أدوار IAM:

• بيانات اعتماد مؤقتة لا ترتبط بشخص واحد — عند افتراض الدور تُلغى صلاحيات المستخدم السابقة مؤقتاً.
• حالات الاستخدام الشائعة: تطبيق على EC2 يحتاج للوصول لـ S3.
• وصول عبر الحسابات لمستخدم IAM، وتطبيقات الجوال التي تحتاج لاستدعاء خدمات AWS.
• خدمات AWS التي تحتاج للوصول لبعضها البعض.

تطبيق على EC2 يحتاج لتحميل ملفات إلى S3. بدلاً من تخزين مفاتيح الوصول على الخادم (غير آمن)، ينشئ مهندس السحابة دور IAM بسياسة s3:PutObject، ويربطه بملف تعريف مثيل EC2. التطبيق يحصل على الصلاحية تلقائياً عبر metadata دون أي مفاتيح مخزنة.

1️⃣1️⃣ Role Examples — أمثلة على استخدام دور IAM (IAM Role Examples)

📖 ما أبرز ثلاثة أمثلة لاستخدام أدوار IAM؟
استخدام الدور للوصول عبر الحسابات، منح تطبيقات EC2 صلاحية الوصول لـ S3، ومنح خدمات AWS مثل Lambda صلاحية الوصول لـ DynamoDB.

📋 الأمثلة الثلاثة:

• المثال الأول: مستخدم IAM في حساب 1 يحتاج وصولاً مؤقتاً لمورد في حساب آخر — ينشئ دوراً ويرفق به سياسة ويفترضه المستخدم.
• المثال الثاني: تطبيق على EC2 يحتاج الوصول لـ S3 — ينشئ دوراً بسياسة S3 ويربطه بملف تعريف المثيل.
• المثال الثالث: خدمة Lambda تحتاج الوصول لـ DynamoDB — ينشئ دوراً بسياسة DynamoDB ويربطه بدالة Lambda.

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

1️⃣2️⃣ Café Considerations — تطبيق: اعتبارات المقهى (Café)

📖 كيف يطبق مقهى Frank و Martha مبادئ IAM في بنيته السحابية؟
مع نمو مقهى القرية، أصبح Frank و Martha بحاجة إلى نظام آمن لإدارة وصول الموظفين إلى الموارد السحابية. ساعدهم المستشارون في تصميم بنية IAM تناسب حجم عملهم.

📋 سيناريوهات IAM في المقهى:

• الدور الإداري: Frank و Martha يحتاجان صلاحية كاملة لإدارة تطبيق المقهى — ينشئان دور Admin مع سياسة AdministratorAccess تستخدم فقط من قبلهم.
• دور الموظفين: Nikhil (الموظف الجزئي) يحتاج صلاحية لعرض الطلبات فقط — ينشئ له دور Staff مع صلاحية قراءة DynamoDB فقط.
• دور المطور: Sofía تخطط لتطوير التطبيق — تحتاج صلاحية أوسع مثل إنشاء وتعديل موارد التطوير.
• دور المستشارين: Olivia و Faythe و Mateo يحتاجون صلاحية مؤقتة للمساعدة في البنية — يفترضون دور Consultant مع صلاحيات محدودة زمنياً.

🔑 تطبيق عملي: المقهى يستخدم مبدأ الامتياز الأقل — كل شخص يحصل فقط على الصلاحيات التي يحتاجها. Frank لا يعطي Nikhil صلاحية حذف قاعدة البيانات، وSofía لا تملك صلاحية تغيير فواتير الدفع. هذا يمنع الأخطاء البشرية ويحمي البنية.

عندما قرر المقهى ترقية تطبيق الطلبات، احتاجت Sofía صلاحية إنشاء Lambda جديدة وتعديل DynamoDB. بدلاً من إعطائها صلاحية Admin كاملة، أنشأت Martha دور "Developer" مع صلاحيات محددة لخدمات التطوير فقط (Lambda، DynamoDB، S3). بعد انتهاء الترقية، استُرجعت الصلاحية المؤقتة — تطبيق لمبدأ الامتياز الأقل في المقهى.

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

✅ خلاصة المصادقة وتأمين الوصول (IAM):

• المصادقة تثبت الهوية والتفويض يحدد الصلاحيات — مفهومان متكاملان.
• IAM هي الخدمة المركزية لإدارة الهوية والوصول بتحكم دقيق.
• ثلاث طرق للتحكم: مستخدم (بيانات دائمة)، مجموعة (صلاحيات موحدة)، دور (صلاحيات مؤقتة).
• أفضل الممارسات: الامتياز الأقل، MFA، عدم استخدام المستخدم الجذر يومياً، استخدام أدوار IAM بدل مفاتيح الوصول الدائمة.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Authentication	المصادقة	التحقق من هوية الطالب عبر بيانات الاعتماد (اسم مستخدم، كلمة مرور، MFA).
Authorization	التفويض	تحديد ما يُسمح للطالب فعله بعد المصادقة الناجحة.
IAM User	مستخدم IAM	هوية دائمة لشخص أو تطبيق، ببيانات اعتماد ثابتة.
IAM Group	مجموعة IAM	مجموعة من المستخدمين بصلاحيات موحدة لتسهيل الإدارة.
IAM Role	دور IAM	هوية مؤقتة يُفترض من قبل مستخدم أو خدمة، بدون بيانات اعتماد دائمة.
Root User	المستخدم الجذر	مالك الحساب بصلاحيات كاملة، يُستخدم فقط للحالات الحرجة.
MFA	المصادقة متعددة العوامل	طبقة أمان إضافية تتطلب رمزاً مؤقتاً من جهاز خارجي.
Access Key	مفتاح الوصول	مزيج من Access Key ID و Secret Key للمصادقة البرمجية.
IAM Identity Center	مركز هوية IAM	خدمة SSO لإدارة الهويات الموحدة عبر حسابات AWS.
Instance Profile	ملف تعريف المثيل	حاوية لـ IAM role تُربط بـ EC2 instance لمنحه صلاحيات.

1️⃣ IAM Policies — سياسات وصلاحيات IAM (IAM Policies)

📖 ما هي سياسة IAM؟
هي كائن بصيغة JSON يحدد الصلاحيات للهوية أو المورد المرتبط بها، وتنقسم إلى نوعين: سياسات قائمة على الهوية وسياسات قائمة على المورد.

📋 نوعا السياسات:

• السياسات القائمة على الهوية (Identity-based policies): تُرفق بمستخدم أو مجموعة أو دور IAM وتحدد ما يُسمح للهوية بفعله.
• السياسات القائمة على المورد (Resource-based policies): تُرفق بمورد AWS (مثل حاوية S3) وتحدد من يمكنه الوصول إليها.
• يتم تعريف الصلاحيات في مستندات سياسة IAM بصيغة JSON.

مطور ينشئ تطبيقاً يحتاج للوصول لـ DynamoDB.
ينشئ سياسة قائمة على الهوية تسمح بقراءة وكتابة جدول Orders فقط.
يربط السياسة بدور IAM يُفترض من Lambda.
التطبيق يصل لـ Orders دون الوصول لجداول أخرى.

2️⃣ Permission Evaluation — تحديد الصلاحيات عند الطلب (Determining Permissions at the Time of Request)

📖 كيف تقيّم AWS صلاحيات الطلب؟
تتبع AWS منطق تقييم محدد: تتحقق من المنع الصريح أولاً، ثم السماح الصريح، وإلا تعود إلى المنع الضمني الذي يرفض الطلب.

📋 منطق تقييم الصلاحيات:

• أولاً — المنع الصريح (Explicit Deny): إذا وُجدت أي سياسة تمنع الإجراء صراحةً، يُرفض الطلب فوراً — وهذا أقوى أنواع القرارات.
• ثانياً — السماح الصريح (Explicit Allow): إذا لم يوجد منع صريح ووُجدت سياسة تسمح بالإجراء، يُسمح.
• ثالثاً — المنع الضمني (Implicit Deny): إذا لم توجد أي سياسة منع أو سماح، يُرفض الطلب افتراضياً.

⚠️ تذكر: القاعدة الأساسية — بشكل افتراضي كل الطلبات مرفوضة.
والمنع الصريح يتجاوز أي سماح صريح، لذلك هو أقوى أداة أمان في السياسات.

🔑 نصيحة أساسية: تذكر تسلسل تقييم الصلاحيات: Explicit Deny دائماً يتجاوز Explicit Allow. حتى لو منحت سياسة ما صلاحية كاملة (Allow *)، مجرد وجود سياسة واحدة فيها Deny على نفس الإجراء يرفض الطلب فوراً. استخدم هذا المبدأ لبناء حواجز أمان قوية: امنح صلاحيات واسعة للمستخدمين ولكن امنع صراحةً الإجراءات الخطرة مثل حذف S3 buckets أو CloudTrail.

موظف في مجموعة التسويق يحاول حذف ملف في S3 الحساس.
سياسة الحاوية (S3 bucket policy) تحتوي على Deny صريح لـ s3:Delete*.
حتى لو كان لدى الموظف صلاحية s3:DeleteObject من سياسة IAM، فإن المنع الصريح في S3 يتغلب عليها ويُرفض الحذف.

3️⃣ Policy Types — السياسات القائمة على الهوية والقائمة على المورد (Identity-Based and Resource-Based Policies)

📖 ما الفرق بين نوعي السياسات؟
سياسات الهوية تجيب على سؤال "ما الذي تملك صلاحية الوصول إليه؟"، بينما سياسات المورد تجيب على سؤال "من يمكنه الوصول إلى هذا المورد؟".

📋 الفرق بين النوعين:

• سياسات الهوية (Identity-based): تُرفق بمستخدم أو مجموعة أو دور IAM — تحدد ما يمكن للهوية فعله.
• سياسات المورد (Resource-based): تُرفق بالمورد نفسه — تحدد من يمكنه الوصول إليه.
• الفرق الرئيسي: الأولى تركز على الهوية، والثانية تركز على المورد.

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

4️⃣ Example 1 — مثال 1 على السياسات (Policies: Example 1)

📖 كيف تطبق سياسة محددة على مستخدم؟
عبر منح المستخدم صلاحية إجراءات محددة (Get, Put, List) على حاوية معينة فقط، بينما تبقى الحاويات الأخرى ممنوعة تلقائياً بالمنع الضمني.

📋 مكونات المثال:

• المستخدم Bob لديه صلاحية Get و Put و List على حاوية X فقط.
• الحاوية Y غير محددة في السياسة مما يعني عدم وجود وصول (منع ضمني).
• يتم تحديد الإجراء (Action) والمورد (Resource) بدقة عبر ARN.

تطبيق اختباري (staging) يحتاج للوصول لـ S3 في حاوية الاختبار فقط.
السياسة تسمح بـ s3:GetObject و s3:PutObject على arn:aws:s3:::staging-bucket/*.
المطور يصل لبيئة الاختبار دون رؤية بيانات الإنتاج.
لو حدث خطأ في الكود وأراد حذف ملف إنتاجي، يُمنع تلقائياً.

5️⃣ Example 2 — مثال 2 على السياسات (Policies: Example 2)

📖 كيف يعمل المنع الضمني؟
كل مورد لم يُذكر صراحةً في السياسة يبقى ممنوعاً تلقائياً، مما يحقق نهج "القائمة البيضاء" الآمن الذي يحدد بوضوح ما هو مسموح به فقط.

📋 نهج القائمة البيضاء:

• Bob لديه صلاحيات على حاوية X فقط — حاوية Y ممنوعة بالمنع الضمني.
• نهج الأمان الأفضل: حدد بوضوح ما هو مسموح به، وكل ما لم يُذكر فهو ممنوع تلقائياً.
• لا تستخدم "Resource": "*" التي تمنح وصولاً واسعاً — حدد كل مورد بدقة عبر ARN.

شركة مالية (fintech) تنشئ سياسات IAM صارمة.
كل سياسة تذكر الموارد بدقة عبر ARN.
لا توجد سياسات بـ "Resource": "*" التي تمنح وصولاً واسعاً.
النتيجة: كل موظف يرى فقط الموارد التي يحتاجها.
حتى لو حدث اختراق، الضرر محدود.

تخيل أنك في مكتبة محكمة الإغلاق: لديك تصريح دخول (هوية IAM).
بعض الكتب في أقسام مفتوحة يمكنك تصفحها (السماح الصريح).
القسم المحظور عليه لافتة "ممنوع الدخول" (المنع الصريح) — حتى لو كان تصريحك عاماً، لا تستطيع دخوله.
أما الكتب في المخزن التي لم تُذكر في تصريحك فهي ممنوعة تلقائياً (المنع الضمني).

✅ خلاصة تفويض المستخدمين (Authorization):

• السياسات تُكتب بصيغة JSON وتحدد الصلاحيات بدقة للهوية أو المورد.
• نوعان: سياسات هوية (مرتبطة بالمستخدم) وسياسات مورد (مرتبطة بالمورد نفسه).
• منطق التقييم: المنع الصريح > السماح الصريح > المنع الضمني.
• الأفضل اتباع نهج "القائمة البيضاء": حدد المسموح واترك الباقي ممنوعاً.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Policy	السياسة	مستند JSON يحدد الصلاحيات لهوية أو مورد.
Identity-based Policy	سياسة قائمة على الهوية	سياسة تُرفق بمستخدم أو مجموعة أو دور IAM.
Resource-based Policy	سياسة قائمة على المورد	سياسة تُرفق بمورد AWS مثل حاوية S3.
Explicit Allow	سماح صريح	تجاوز المنع الافتراضي ويسمح بالإجراء.
Explicit Deny	منع صريح	يتجاوز أي سماح ويرفض الإجراء نهائياً.
Implicit Deny	منع ضمني	المنع الافتراضي عند عدم وجود سماح صريح.
ARN	اسم مورد أمازون	معرف فريد لكل مورد في AWS، يستخدم في السياسات.
JSON	تنسيق JSON	لغة منظمة لكتابة سياسات IAM بشكل قابل للقراءة.

1️⃣ Policy Structure — بنية مستند سياسة IAM (Policy Document Structure)

📖 ما هي عناصر مستند سياسة IAM؟
يتكون من إصدار (Version) وبيان (Statement) يحتوي على التأثير والموجه والإجراء والمورد والشرط — وكل عنصر اختياري ما عدا التأثير.

📋 العناصر الرئيسية:

• الإصدار (Version): إصدار لغة السياسة، عادةً "2012-10-17".
• البيان (Statement): العنصر الرئيسي الذي يحدد ما هو مسموح أو ممنوع.
• التأثير (Effect): Allow أو Deny — العنصر الوحيد الإجباري.
• الموجه (Principal): لسياسات المورد فقط، يحدد الحساب أو المستخدم.
• الإجراء (Action): يسرد إجراءات API المسموحة أو الممنوعة، يدعم الرموز البديلة مثل s3:*.
• المورد (Resource): يحدد موارد AWS عبر ARN.
• الشرط (Condition): ظروف إضافية مثل عنوان IP أو الوقت أو MFA مطلوب.

سياسة IAM نموذجية: { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::my-bucket/*" }] }.
هذه السياسة تسمح بقراءة الكائنات من my-bucket.
كل عنصر يخدم غرضاً: الإصدار يحدد الصيغة، التأثير يسمح، الإجراء يحدد العملية، المورد يحدد الهدف.

2️⃣ Resource-based Policy — سياسة قائمة على المورد (Example: Resource-Based Policy)

📖 كيف تبدو سياسة قائمة على المورد عملياً؟
تسمح صراحةً بإجراءات على DynamoDB أو S3 وتُرفق بالمورد نفسه مع تحديد الموجه (Principal) الذي يملك حق الوصول.

📋 خصائص السياسة القائمة على المورد:

• السياسة تُرفق بالمورد نفسه (جدول DynamoDB أو حاوية S3).
• تحدد من يمكنه الوصول إلى المورد عبر عنصر Principal.
• وجود الموجه (Principal) في السياسة هو علامة أنها سياسة قائمة على المورد.

شركة تريد أن يصل موظفوها لـ DynamoDB الحساس.
تضيف سياسة قائمة على المورد على الجدول تسمح بدور DynamoDB-Reader فقط.
لا يحتاج كل موظف إلى سياسة هوية خاصة، فقط يحصل على الدور.
هذا يريح المدير من إدارة السياسات على كل مستخدم.

3️⃣ Identity-based Policy — سياسة قائمة على الهوية (Example: Identity-Based Policy)

📖 كيف تبدو سياسة قائمة على الهوية؟
تسمح للمستخدم بإجراءات على نفسه فقط عبر المتغير ${aws:username} مما يطبق مبدأ الامتياز الأقل بدقة — المستخدم يدير بيانات اعتماده فقط.

📋 خصائص السياسة القائمة على الهوية:

• تسمح بإجراءات مثل إنشاء ملف تعريف تسجيل الدخول (iam:CreateLoginProfile) وإنشاء مفاتيح الوصول (iam:CreateAccessKey).
• المورد محدد كـ ${aws:username} مما يعني أن السياسة تنطبق فقط على المستخدم نفسه.
• لا تحتوي على عنصر Principal لأنها مُرفقة بالفعل بالمستخدم.
• تطبق مبدأ الامتياز الأقل: المستخدم يدير بيانات اعتماده فقط وليس بيانات الآخرين.

شركة تريد أن يستطيع كل موظف إدارة بياناته الشخصية (تغيير كلمة المرور، إنشاء مفتاح وصول).
تطبق سياسة قائمة على الهوية على كل مستخدم IAM تسمح بهذه الإجراءات على نفسه فقط عبر ${aws:username}.
النتيجة: الموظف مستقل، والمدير مرتاح.

4️⃣ Cross-account Policy — سياسة قائمة على المورد عبر الحسابات (Example: Cross-Account Resource-Based Policy)

📖 كيف نشارك الموارد بين حسابات AWS المختلفة؟
عبر سياسة عبر الحسابات (Cross-account policy) تُرفق بالمورد وتسمح لحساب AWS آخر بالوصول، دون مشاركة كلمات مرور أو إنشاء مستخدمين جدد.

📋 خصائص السياسات عبر الحسابات:

• الحساب A ينشئ سياسة على حاوية S3 تسمح للحساب B (برقم الحساب المحدد) بالوصول الكامل.
• يستخدم عنصر Principal لتحديد رقم الحساب الآخر.
• لا حاجة لإنشاء مستخدمين جدد في حساب A — ويمكن حذف السياسة فوراً لإنهاء الوصول.

شركة A (المالك) وشركة B (الشريك) يتعاونان على مشروع.
شركة A تشارك حاوية S3 مع شركة B عبر سياسة عبر الحسابات.
شركة B تصل للحاوية دون أي حساب في شركة A.
لو انتهى التعاون، تحذف شركة A السياسة فوراً.
لا توجد كلمات مرور مشتركة.

تخيل أن لديك مستند إداري رسمي: أعلى المستند مكتوب رقم الإصدار (Version)، ثم فقرة رئيسية (Statement) تقول "يُسمح (Allow) للموظف رقم ١٢٣ (Principal) بدخول الغرفة رقم ٥ (Resource) للقراءة فقط (Action) خلال ساعات العمل (Condition)".
لو المستند معلق على باب الغرفة فهو سياسة قائمة على المورد، ولو مع الموظف فهو سياسة قائمة على الهوية.

✅ خلاصة بنية سياسات IAM:

• مستند السياسة يتكون من Version و Statement ويحتوي البيان على Effect و Action و Resource.
• السياسات القائمة على المورد تحتوي على Principal، بينما سياسات الهوية لا تحتويه.
• المتغيرات مثل ${aws:username} تساعد في تطبيق الامتياز الأقل بدقة.
• السياسات عبر الحسابات تتيح مشاركة الموارد بين حسابات AWS دون مشاركة كلمات مرور.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Version	إصدار لغة السياسة	إصدار صيغة JSON للسياسة، عادةً "2012-10-17".
Statement	البيان	الكتلة الرئيسية في السياسة التي تحدد Effect و Action و Resource.
Effect	التأثير	يحدد ما إذا كان الإجراء مسموحاً (Allow) أو ممنوعاً (Deny).
Action	الإجراء	يسرد عمليات AWS API المسموحة أو الممنوعة، يدعم wildcards.
Resource	المورد	يحدد موارد AWS عبر ARN مثل arn:aws:s3:::my-bucket/*.
Principal	الموجه	الحساب أو المستخدم أو الدور، يظهر في resource-based policies فقط.
Condition	الشرط	ظروف إضافية مثل IP أو الوقت أو MFA مطلوب.
Cross-account	عبر الحسابات	السماح بالوصول لمورد في حساب AWS مختلف.

1️⃣ Activity 1: IAM Policy Analysis — النشاط الأول: تحليل سياسة IAM

📖 سياسة IAM التالية تسمح بإجراءات iam:Get* و iam:List*:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["iam:Get*","iam:List*"],
    "Resource": "*"
  }]
}

📋 أسئلة التحليل:

• ما الخدمة المستهدفة في هذه السياسة؟ — خدمة IAM.
• ما الإجراءات المسموحة؟ — جميع إجراءات GET و LIST في IAM.
• هل تسمح السياسة بإنشاء مستخدمين جدد؟ — لا، لأن iam:CreateUser ليس ضمن الإجراءات المسموحة.
• هل تسمح بحذف المستخدمين؟ — لا، لأن iam:DeleteUser ليس ضمن الإجراءات.
• ما المبدأ الذي تطبقه هذه السياسة؟ — مبدأ الامتياز الأقل — تسمح فقط بالقراءة دون كتابة أو حذف.

مدير أمان يريد منح فريق التدقيق صلاحية مراجعة إعدادات IAM دون القدرة على تعديلها. هذه السياسة مثالية — الفريق يقرأ قائمة المستخدمين والسياسات (List) ويتفاصيلها (Get) لكنه لا يستطيع إنشاء أو تعديل أو حذف أي شيء.

2️⃣ Activity 2: EC2 with IP Condition — النشاط الثاني: تحليل سياسة EC2 مع شرط IP

📖 سياسة IAM التالية تسمح بإنهاء مثيلات EC2 مع شرط عنوان IP:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "ec2:TerminateInstances",
    "Resource": "*",
    "Condition": {
      "NotIpAddress": {
        "aws:SourceIp": ["10.0.0.0/8","192.168.0.0/16"]
      }
    }
  }]
}

📋 أسئلة التحليل:

• ما الإجراء المسموح؟ — ec2:TerminateInstances (إنهاء مثيلات EC2).
• ما الشرط المطبق؟ — NotIpAddress — يسمح فقط إذا كان عنوان IP المصدر ليس من النطاقات 10.0.0.0/8 أو 192.168.0.0/16.
• متى يمكن تنفيذ هذا الإجراء؟ — فقط عندما يأتي الطلب من خارج نطاقي العناوين الخاصة المحددين.
• ما الهدف من هذا الشرط؟ — منع إنهاء المثيلات من الشبكة الداخلية للشركة، والسماح به فقط من شبكات خارجية مثل VPN أو مكاتب فرعية.

🔑 ملاحظة أمنية مهمة: استخدام NotIpAddress مع نطاقات خاصة يعني أن أي طلب قادم من خارج هذه النطاقات يُسمح له بإنهاء المثيلات. هذا قد يكون خطراً إذا كان التطبيق متاحاً للعامة. أفضل ممارسة: استخدم IpAddress بدلاً من NotIpAddress لحصر الإجراءات الحساسة بعناوين IP محددة وموثوقة.

فريق عمليات يعمل من مكاتب خارجية متعددة. المدير يريد أن يتمكن الفريق من إنهاء مثيلات EC2 المتعطلة فقط عندما يكونون خارج الشبكة الداخلية (عبر VPN). استخدام NotIpAddress مع النطاقات الداخلية يحقق هذا الهدف — الفريق في المكتب لا يمكنه إنهاء المثيلات، لكن الفريق على الطريق (عبر VPN بعنوان IP خارجي) يمكنه ذلك.

3️⃣ Activity 3: Deny with Instance Type — النشاط الثالث: تحليل سياسة Deny مع شرط نوع المثيل

📖 سياسة IAM التالية تمنع تشغيل مثيلات EC2 من أنواع محددة:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "ec2:InstanceType": ["t2.micro","t2.small"]
      }
    }
  }]
}

📋 أسئلة التحليل:

• ما التأثير (Effect) في هذه السياسة؟ — Deny (منع).
• ما الإجراء الممنوع؟ — ec2:RunInstances (تشغيل مثيلات جديدة).
• ما الشرط المطبق؟ — StringNotEquals — يُمنع الإجراء إذا كان نوع المثيل لا يساوي t2.micro أو t2.small.
• ما أنواع المثيلات المسموح بها؟ — فقط t2.micro و t2.small.
• لماذا نستخدم Deny هنا بدلاً من Allow؟ — لأن Deny صريح يتجاوز أي Allow آخر. هذا يضمن أنه حتى لو منحت سياسة أخرى صلاحية EC2 كاملة، فإن تشغيل مثيلات كبيرة الحجم ما زال ممنوعاً.

⚠️ تذكر: المنع الصريح (Explicit Deny) هو أقوى أداة في سياسات IAM. استخدام Deny مع StringNotEquals يعني: "إذا كان نوع المثيل ليس t2.micro ولا t2.small، امنع الإجراء". هذا يسمح فقط بالمثيلات الصغيرة ويمنع كل الأنواع الأخرى — حتى لو حاول مستخدم بصلاحيات واسعة تشغيل مثيل كبير.

شركة ناشئة تريد التحكم في تكاليف EC2. تنشئ سياسة Deny تمنع تشغيل أي مثيل ليس من النوع t2.micro أو t2.small. حتى المطورين بصلاحيات AdministratorAccess لا يمكنهم تشغيل مثيلات كبيرة — Deny يتجاوز كل Allow. الفواتير الشهرية تبقى تحت السيطرة.

✅ خلاصة نشاط تحليل سياسات IAM:

• النشاط الأول: سياسة iam:Get*/List* تسمح بقراءة IAM فقط — مناسبة للتدقيق والمراجعة.
• النشاط الثاني: سياسة ec2:TerminateInstances مع NotIpAddress — تقيد إنهاء المثيلات بعناوين IP محددة.
• النشاط الثالث: سياسة Deny مع StringNotEquals — تمنع تشغيل مثيلات ليست من النوعين المسموحين فقط t2.micro و t2.small.
• المنع الصريح (Explicit Deny) أقوى من السماح الصريح — استخدمه للتحكم الصارم في التكاليف والأمان.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
NotIpAddress	ليس عنوان IP	شرط ينطبق عندما لا يكون عنوان IP المصدر مطابقاً للنطاق المحدد.
StringNotEquals	لا يساوي نصياً	شرط ينطبق عندما لا يساوي النص القيمة المحددة.
ec2:RunInstances	تشغيل مثيلات EC2	إجراء API لإنشاء وتشغيل مثيل EC2 جديد.
ec2:TerminateInstances	إنهاء مثيلات EC2	إجراء API لإنهاء وحذف مثيلات EC2.
Explicit Deny	المنع الصريح	يمنع الإجراء بصراحة ويتجاوز أي Allow — الأقوى في التقييم.

1️⃣ Lab Overview — نظرة عامة على المعمل

📖 المعمل العملي "Exploring IAM" يتيح لك تجربة عملية لفهم كيفية عمل AWS Identity and Access Management (IAM) من خلال مهام تطبيقية.
سيتيح لك هذا المعمل فرصة تطبيق المفاهيم التي تعلمتها في هذه الوحدة في بيئة AWS حقيقية — من إنشاء المستخدمين إلى إدارة الصلاحيات.

2️⃣ Lab Tasks — مهام المعمل

📖 يقسم المعمل إلى أربع مهام رئيسية:

📋 مهام المعمل العملي:

• المهمة 1: استكشاف المستخدمين والمجموعات: سجّل الدخول إلى AWS Management Console وتصفح مستخدمي IAM والمجموعات والسياسات الموجودة. تعرف على واجهة IAM Dashboard.
• المهمة 2: إضافة مستخدمين إلى مجموعات IAM: أنشئ مستخدمي IAM جدد وأضفهم إلى مجموعات مختلفة — لاحظ كيف يرث المستخدمون الصلاحيات تلقائياً من المجموعة.
• المهمة 3: اختبار صلاحيات المستخدمين: سجّل الدخول كمستخدم مختلف باستخدام IAM sign-in URL. اختبر الصلاحيات الممنوحة — حاول الوصول إلى خدمات غير مصرح بها لترى رفض الوصول.
• المهمة 4: تحديث السياسات وملاحظة التغيير: عدّل سياسة مجموعة IAM وأضف صلاحية جديدة. سجّل الدخول مرة أخرى كمستخدم ولاحظ أن الصلاحية الجديدة متاحة فوراً.

في المعمل، ستنشئ مستخدماً جديداً اسمه "TestUser" وتضيفه إلى مجموعة "S3-ReadOnly-Users" التي تملك صلاحية قراءة S3 فقط. بعد تسجيل الدخول كمستخدم TestUser، حاول إنشاء مثيل EC2 جديد — سترى رسالة رفض الوصول (AccessDenied) لأن المجموعة لا تمنح صلاحية EC2.

3️⃣ IAM Sign-in URL — الوصول إلى IAM Sign-in URL

📖 رابط تسجيل الدخول الخاص بحساب IAM (IAM sign-in URL) يسمح للمستخدمين بالدخول إلى AWS Console باستخدام اسم المستخدم وكلمة المرور — دون الحاجة لاستخدام الحساب الجذر.
يمكنك العثور على الرابط في IAM Dashboard تحت "Sign-in URL for IAM users in this account". يمكن تخصيصه لاستخدام اسم نطاق الشركة.

4️⃣ Debrief — أسئلة التفكير (Debrief)

📖 بعد إتمام المعمل، يجب أن تفكر في الأسئلة التالية لتعميق فهمك:

📋 أسئلة التفكير بعد المعمل:

• أين يمكن الوصول إلى خدمة IAM في AWS Management Console؟ — عبر البحث عن "IAM" في شريط الخدمات أو عبر قائمة Services > Security, Identity, & Compliance > IAM.
• ماذا يحدث عندما تحدّث سياسة مدارة (Managed Policy) مرتبطة بمجموعة؟ — يتم تطبيق التغيير فوراً على كل أعضاء المجموعة. إذا أضفت صلاحية جديدة للسياسة، تصبح متاحة لجميع المستخدمين في المجموعة فوراً دون حاجة لإعادة تسجيل الدخول.
• لماذا نستخدم المجموعات بدلاً من إرفاق السياسات مباشرة بالمستخدمين؟ — لتسهيل الإدارة: تغيير واحد ينطبق على كل الأعضاء، ويمكن إضافة وإزالة المستخدمين بسهولة.

🔑 نصيحة أساسية: السياسات المدارة (AWS Managed Policies) تُنشأ وتُدار من AWS وتُحدّث تلقائياً. السياسات المدارة من العميل (Customer Managed Policies) تنشئها أنت وتتحكم بتحديثاتها. استخدم السياسات المدارة من AWS للحالات القياسية (مثل ReadOnlyAccess، AdministratorAccess)، والسياسات المدارة من العميل للصلاحيات المخصصة.

✅ خلاصة المعمل العملي Exploring IAM:

• المعمل يتيح تجربة عملية لإدارة المستخدمين والمجموعات والسياسات في IAM.
• المهام تشمل إنشاء المستخدمين وإضافتهم للمجموعات واختبار الصلاحيات وتحديث السياسات.
• IAM sign-in URL هو الرابط المخصص لمستخدمي IAM لتسجيل الدخول إلى AWS Console.
• تحديث السياسات المدارة ينطبق فوراً على كل المستخدمين المرتبطين بها.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
IAM sign-in URL	رابط تسجيل دخول IAM	رابط مخصص لمستخدمي IAM لتسجيل الدخول إلى AWS Console.
Managed Policy	سياسة مدارة	سياسة IAM تُنشأ وتُدار من AWS أو العميل بشكل مركزي.
AWS Managed Policy	سياسة AWS مدارة	سياسة منشأة من AWS تُحدّث تلقائياً — مثل ReadOnlyAccess.
Customer Managed Policy	سياسة عميل مدارة	سياسة تنشئها أنت وتتحكم بتحديثاتها حسب احتياجك.
Debrief	أسئلة التفكير	أسئلة تأملية بعد المعمل لتعميق فهم المفاهيم.

1️⃣ SAA-C03 Exam Question — سؤال امتحان SAA-C03

📖 السؤال:
شركة تريد أن تسمح لتطبيق يعمل على Amazon EC2 بالوصول إلى Amazon DynamoDB لقراءة وكتابة البيانات. ما هو الحل الأكثر أماناً لتحقيق ذلك؟

📋 اختر الإجابة الصحيحة:

• A: تخزين اسم المستخدم وكلمة المرور لحساب AWS في ملف تكوين التطبيق على EC2.
• B: إنشاء مستخدم IAM بصلاحيات DynamoDB الكاملة وتخزين مفاتيح الوصول (Access Keys) في متغيرات البيئة.
• C: إنشاء دور IAM مع سياسة تسمح بإجراءات DynamoDB المطلوبة، وربط الدور بملف تعريف المثيل (Instance Profile) الخاص بمثيل EC2.
• D: فتح DynamoDB للعامة (Public access) والاعتماد على عنوان IP الخاص بمثيل EC2 للتحكم في الوصول.

2️⃣ Correct Answer — الإجابة الصحيحة

✅ الإجابة الصحيحة: C

📖 شرح الإجابة الصحيحة (C):
استخدام دور IAM هو الحل الأكثر أماناً ومن أفضل الممارسات في AWS. بدلاً من تخزين مفاتيح وصول دائمة على الخادم (غير آمنة)، يُنشأ دور IAM بسياسة تسمح بإجراءات DynamoDB المطلوبة فقط. يُربط الدور بمثيل EC2 عبر Instance Profile. يحصل التطبيق تلقائياً على بيانات اعتماد مؤقتة من AWS Metadata Service — تُجدّد تلقائياً ولا تحتاج لإدارة يدوية.

📋 لماذا الخيارات الأخرى خاطئة:

• A خطأ: تخزين بيانات اعتماد حساب AWS (الجذر) في التطبيق مخالف لأفضل ممارسات الأمان. المستخدم الجذر يملك صلاحيات كاملة غير محدودة — أي اختراق للملف يعرض كل موارد AWS للخطر.
• B خطأ: على الرغم من أنه أفضل من A، إلا أن تخزين مفاتيح الوصول — حتى في متغيرات البيئة — ليس الطريقة المثلى. المفاتيح ثابتة ودائمة، تحتاج تدويراً يدوياً، ويمكن تسريبها بسهولة من السكريبت أو الصور الثنائية للحاوية.
• D خطأ: فتح DynamoDB للعامة يعرض قاعدة البيانات لهجمات خارجية. استخدام عنوان IP فقط للتحكم (بدون مصادقة) ليس آمناً — عناوين IP يمكن تزويرها.

هذا السؤال يختبر فهمك لأفضل ممارسات IAM: استخدام أدوار IAM بدلاً من مفاتيح الوصول الدائمة. في امتحان SAA-C03، الأسئلة غالباً ما تختبر قدرتك على اختيار الحل الأكثر أماناً — وليس فقط الحل الذي يعمل. دور IAM مع Instance Profile هو الحل المعتمد من AWS لمنح صلاحيات لتطبيقات EC2.

✅ خلاصة سؤال الامتحان النموذجي:

• أفضل ممارسة لمنح صلاحيات لتطبيق على EC2: استخدام دور IAM مع Instance Profile.
• لا تخزّن أبداً مفاتيح وصول أو كلمات مرور على الخوادم أو في الكود.
• استخدم بيانات الاعتماد المؤقتة (Temporary credentials) عبر أدوار IAM كلما أمكن.
• امتحان SAA-C03 يركز على اختيار الحل الأكثر أماناً وفعالية — وليس فقط الحل الأسرع.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Instance Profile	ملف تعريف المثيل	حاوية لدور IAM تُربط بمثيل EC2 لمنحه صلاحيات تلقائياً.
Temporary credentials	بيانات اعتماد مؤقتة	صلاحيات محددة زمنياً تُجدّد تلقائياً — أكثر أماناً من المفاتيح الدائمة.
EC2 Metadata Service	خدمة البيانات الوصفية	خدمة داخلية في EC2 توفر بيانات التهيئة وبيانات الاعتماد المؤقتة للتطبيقات.
SAA-C03	امتحان مهندس الحلول	شهادة AWS Certified Solutions Architect – Associate.
AWS CloudTrail	سجل تدقيق AWS	خدمة تسجل جميع API calls في حسابك لأغراض التدقيق والمراقبة.
AWS Config	خدمة التهيئة	خدمة تقيّم موارد AWS وتتحقق من امتثالها للسياسات والقواعد المحددة.

🚀 الخاتمة

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

تعديل المقال