🎯 Securing Access — تأمين الوصول إلى الموارد السحابية
تركز هذه الوحدة على مبادئ الأمان الأساسية في Amazon Web Services (AWS) وكيفية تأمين الوصول إلى مواردك السحابية. ستتعرف على نموذج المسؤولية المشتركة بين AWS والعملاء، ومبادئ التصميم الأمني في AWS Well-Architected Framework، وكيفية استخدام AWS Identity and Access Management (IAM) لإدارة المستخدمين والمجموعات والأدوار والسياسات لتأمين الوصول بدقة وفعالية.
1️⃣ AWS shared responsibility model — نموذج المسؤولية المشتركة
📖 ما هو نموذج المسؤولية المشتركة (AWS Shared Responsibility Model)؟
يقسم هذا النموذج مسؤوليات الأمان بين AWS والعملاء. AWS مسؤولة عن أمان السحابة نفسه (Security OF the Cloud)، بما في ذلك حماية البنية التحتية العالمية من المادية والمحاكاة إلى أنظمة التشغيل. العملاء مسؤولون عن الأمان داخل السحابة (Security IN the Cloud)، بما في ذلك بيانات العملاء والتطبيقات وإدارة الهوية والوصول وتكوين جدران الحماية والتشفير.
📋 تفصيل المسؤوليات:
يقسم هذا النموذج مسؤوليات الأمان بين AWS والعملاء. AWS مسؤولة عن أمان السحابة نفسه (Security OF the Cloud)، بما في ذلك حماية البنية التحتية العالمية من المادية والمحاكاة إلى أنظمة التشغيل. العملاء مسؤولون عن الأمان داخل السحابة (Security IN the Cloud)، بما في ذلك بيانات العملاء والتطبيقات وإدارة الهوية والوصول وتكوين جدران الحماية والتشفير.
- AWS: مسؤولة عن أمن المكونات بدءاً من نظام تشغيل المضيف (host OS) وطبقة المحاكاة (virtualization layer) إلى الأمن المادي للمرافق التي تديرها.
- العميل: مسؤول عن تشفير البيانات من جانب العميل (client-side encryption) والتشفير من جانب الخادم (server-side encryption) وحماية حركة الشبكة.
- العميل: مسؤول عن نظام التشغيل وجدار الحماية وتكوينات الشبكة وإدارة الهوية والوصول (IAM).
- العميل: مسؤول عن تكامل البيانات والمصادقة (data integrity and authentication).
مقهى أحمد و سارة يريد تخزين صور إبداعات الخبز في السحابة.
يتحمل AWS مسؤولية حماية مراكز البيانات والخوادم التي تخزن عليها الصور.
أما صوفيا التي تدير العمليات اليومية فهي مسؤولة عن ضبط صلاحيات الوصول إلى هذه الصور وتشفيرها قبل رفعها.
هكذا يتوزع الأمان بين الطرفين — كل طرف مسؤول عن جزء لا يتجزأ من الحل.
يتحمل AWS مسؤولية حماية مراكز البيانات والخوادم التي تخزن عليها الصور.
أما صوفيا التي تدير العمليات اليومية فهي مسؤولة عن ضبط صلاحيات الوصول إلى هذه الصور وتشفيرها قبل رفعها.
هكذا يتوزع الأمان بين الطرفين — كل طرف مسؤول عن جزء لا يتجزأ من الحل.
2️⃣ Security is a Well-Architected Framework pillar — الأمان كركيزة في إطار الهندسة المتقنة
📖 كيف يُصنف الأمان ضمن AWS Well-Architected Framework؟
الأمان هو إحدى الركائز الست في الإطار، إلى جانب التميز التشغيلي والموثوقية وكفاءة الأداء وتحسين التكلفة والاستدامة. يوفر الإطار أفضل الممارسات وإرشادات التصميم لكل ركيزة لمساعدتك على اتخاذ القرارات الصحيحة ومراجعة البنى القائمة. يمكنك استخدام AWS Well-Architected Tool لتقييم حمولات العمل ومقارنتها بأحدث أفضل الممارسات المعمارية.
الأمان هو إحدى الركائز الست في الإطار، إلى جانب التميز التشغيلي والموثوقية وكفاءة الأداء وتحسين التكلفة والاستدامة. يوفر الإطار أفضل الممارسات وإرشادات التصميم لكل ركيزة لمساعدتك على اتخاذ القرارات الصحيحة ومراجعة البنى القائمة. يمكنك استخدام AWS Well-Architected Tool لتقييم حمولات العمل ومقارنتها بأحدث أفضل الممارسات المعمارية.
🔑 نصيحة أساسية: استخدام AWS WA Tool يمنحك خطة عمل خطوة بخطوة لتحسين حمولات العمل في السحابة، مما يقلل أعطال النظام والتكاليف التشغيلية.
3️⃣ Design principles for the security pillar — مبادئ التصميم لركيزة الأمان
📖 ما هي المبادئ السبعة لتصميم الأمان في AWS؟
تتضمن ركيزة الأمان سبعة مبادئ تصميم: تنفيذ أساس هوية قوي (strong identity foundation)، حماية البيانات أثناء النقل وأثناء التخزين (protect data in transit and at rest)، تطبيق الأمان على جميع الطبقات (apply security at all layers)، إبعاد الأشخاص عن البيانات (keep people away from data)، الحفاظ على قابلية التتبع (maintain traceability)، الاستعداد للأحداث الأمنية (prepare for security events)، وأتمتة أفضل ممارسات الأمان (automate security best practices).
📋 المبادئ السبعة بالتفصيل:
تتضمن ركيزة الأمان سبعة مبادئ تصميم: تنفيذ أساس هوية قوي (strong identity foundation)، حماية البيانات أثناء النقل وأثناء التخزين (protect data in transit and at rest)، تطبيق الأمان على جميع الطبقات (apply security at all layers)، إبعاد الأشخاص عن البيانات (keep people away from data)، الحفاظ على قابلية التتبع (maintain traceability)، الاستعداد للأحداث الأمنية (prepare for security events)، وأتمتة أفضل ممارسات الأمان (automate security best practices).
- أساس هوية قوي: طبق مبدأ الامتياز الأدنى (least privilege) وفرض فصل المهام مع تفويض مناسب لكل تفاعل مع الموارد.
- حماية البيانات أثناء النقل والتخزين: صنف البيانات حسب مستويات الحساسية واستخدم آليات مثل التشفير (encryption) والترميز (tokenization) والتحكم في الوصول.
- تطبيق الأمان على جميع الطبقات: اعتمد نهج الدفاع في العمق (defense-in-depth) على جميع المستويات من حافة الشبكة إلى التطبيق والكود.
- إبعاد الأشخاص عن البيانات: استخدم آليات وأدوات لتقليل أو إلغاء الحاجة للوصول المباشر والمعالجة اليدوية للبيانات.
- الحفاظ على قابلية التتبع: راقب ونبه ودقق الإجراءات والتغييرات في بيئتك في الوقت الفعلي.
- الاستعداد للأحداث الأمنية: هيئ سياسات وعمليات لإدارة الحوادث تتوافق مع متطلبات مؤسستك.
- أتمتة أفضل ممارسات الأمان: استخدم الأتمتة لتطبيق ضوابط الأمان بشكل مستمر ومتسق عبر البنية.
مقهى فرانك ومارثا يستخدم تطبيق طلبات إلكترونية جديداً.
تطبق صوفيا مبدأ الامتياز الأدنى فتمنح الموظف الجديد نيكل صلاحية قراءة القوائم فقط دون تعديلها.
تشفّر جميع بيانات العملاء أثناء النقل باستخدام TLS وتخزّن تقارير المبيعات مشفرة في Amazon S3.
تفعّل AWS CloudTrail لتتبع كل إجراء في الحساب — هذه هي المبادئ السبعة مجتمعة في سيناريو واحد.
تطبق صوفيا مبدأ الامتياز الأدنى فتمنح الموظف الجديد نيكل صلاحية قراءة القوائم فقط دون تعديلها.
تشفّر جميع بيانات العملاء أثناء النقل باستخدام TLS وتخزّن تقارير المبيعات مشفرة في Amazon S3.
تفعّل AWS CloudTrail لتتبع كل إجراء في الحساب — هذه هي المبادئ السبعة مجتمعة في سيناريو واحد.
4️⃣ User permissions to access resources — أذونات المستخدمين للوصول إلى الموارد
📖 كيف تُدار أذونات الوصول إلى الموارد في AWS؟
جزء من تنفيذ أساس هوية قوي هو استخدام السياسات (policies) لمنح أو رفض الوصول إلى موارد AWS مثل مجالات Amazon S3. يمكن أن يكون للمستخدم صلاحيات مختلفة لكل مورد — مثلاً صلاحية القراءة والكتابة والحذف على مجال تخزين واحد، وصلاحية القراءة فقط على مجال آخر، ورفض صريح للوصول إلى جدول Amazon DynamoDB معين.
جزء من تنفيذ أساس هوية قوي هو استخدام السياسات (policies) لمنح أو رفض الوصول إلى موارد AWS مثل مجالات Amazon S3. يمكن أن يكون للمستخدم صلاحيات مختلفة لكل مورد — مثلاً صلاحية القراءة والكتابة والحذف على مجال تخزين واحد، وصلاحية القراءة فقط على مجال آخر، ورفض صريح للوصول إلى جدول Amazon DynamoDB معين.
جون مدير تقنية المعلومات في شركة صغيرة يمتلك صلاحية كاملة على مجلد صور المنتجات في S3.
لكنه يستطيع فقط عرض (وليس تعديل أو حذف) تقارير المالية المخزنة في مجال آخر.
كما أنه ممنوع صراحة من الوصول إلى قاعدة بيانات العملاء في DynamoDB.
كل هذه الأذونات محددة في سياسات IAM مرفقة بحسابه.
لكنه يستطيع فقط عرض (وليس تعديل أو حذف) تقارير المالية المخزنة في مجال آخر.
كما أنه ممنوع صراحة من الوصول إلى قاعدة بيانات العملاء في DynamoDB.
كل هذه الأذونات محددة في سياسات IAM مرفقة بحسابه.
5️⃣ Principle of least privilege — مبدأ الامتياز الأدنى
📖 ما هو مبدأ الامتياز الأدنى (Principle of Least Privilege)؟
يعني هذا المبدأ منح المستخدمين والمجموعات والأدوار أقل الصلاحيات اللازمة لأداء مهامهم فقط. من الأكثر أمناً البدء بمجموعة دنيا من الأذونات ثم إضافة المزيد عند الحاجة، بدلاً من البدء بأذونات واسعة جداً ثم محاولة تقييدها لاحقاً. يتطلب تحديد مجموعة الأذونات الصحيحة بحثاً دقيقاً في ما يحتاجه المستخدم تحديداً لإنجاز مهمته.
📋 أفضل الممارسات لتطبيق المبدأ:
يعني هذا المبدأ منح المستخدمين والمجموعات والأدوار أقل الصلاحيات اللازمة لأداء مهامهم فقط. من الأكثر أمناً البدء بمجموعة دنيا من الأذونات ثم إضافة المزيد عند الحاجة، بدلاً من البدء بأذونات واسعة جداً ثم محاولة تقييدها لاحقاً. يتطلب تحديد مجموعة الأذونات الصحيحة بحثاً دقيقاً في ما يحتاجه المستخدم تحديداً لإنجاز مهمته.
- امنح فقط الصلاحيات المطلوبة لأداء المهمة (grant only the permissions required).
- ابدأ بمجموعة دنيا من الأذونات ثم أضف المزيد تدريجياً عند الحاجة.
- ألغِ الصلاحيات غير الضرورية فور الاستغناء عنها.
- ابحث جيداً عن الوصول المطلوب قبل كتابة السياسة.
🔑 نصيحة أساسية: حدد ما يحتاجه المستخدمون فعلاً للقيام بمهامهم، ثم اصنع سياسات تسمح فقط بتلك المهام. مثلاً قد يُسمح للمطورين بإنشاء EC2 في بيئة الإنتاج ولكن لا يُسمح لهم بإيقاف أو إنهاء تلك الحالات.
في المقهى، نيكل الموظف الجديد يحتاج فقط إلى عرض قائمة المنتجات وتحديث حالة الطلبات.
تطبّق صوفيا مبدأ الامتياز الأدنى وتمنحه صلاحيات محدودة لا تشمل الوصول إلى التقارير المالية أو تعديل أسعار المنتجات.
لو احتاج نيكل لاحقاً صلاحية إضافة منتج جديد فإنها تُضاف عند الحاجة فقط وليس مسبقاً.
تطبّق صوفيا مبدأ الامتياز الأدنى وتمنحه صلاحيات محدودة لا تشمل الوصول إلى التقارير المالية أو تعديل أسعار المنتجات.
لو احتاج نيكل لاحقاً صلاحية إضافة منتج جديد فإنها تُضاف عند الحاجة فقط وليس مسبقاً.
6️⃣ Use encryption — استخدام التشفير
📖 كيف يحمي التشفير البيانات في AWS؟
بالإضافة إلى تحديد الصلاحيات، يمنع التشفير الوصول غير المصرح به إلى البيانات. البيانات أثناء النقل (data in transit) هي البيانات المنتقلة من مكان لآخر عبر الإنترنت أو شبكة خاصة. استخدام بروتوكولات مثل TLS (Transport Layer Security) يضمن خصوصية عملية النقل، مثل تشفير الصور أثناء تحميلها إلى خدمة سحابية دون الحاجة بالضرورة لتشفير الصور نفسها.
بالإضافة إلى تحديد الصلاحيات، يمنع التشفير الوصول غير المصرح به إلى البيانات. البيانات أثناء النقل (data in transit) هي البيانات المنتقلة من مكان لآخر عبر الإنترنت أو شبكة خاصة. استخدام بروتوكولات مثل TLS (Transport Layer Security) يضمن خصوصية عملية النقل، مثل تشفير الصور أثناء تحميلها إلى خدمة سحابية دون الحاجة بالضرورة لتشفير الصور نفسها.
صوفيا ترفع صور معجنات المقهى الجديدة إلى Amazon S3 من هاتفها المحمول أثناء تواجدها في المقهى.
بروتوكول TLS يؤمن عملية الرفع ويشفر البيانات أثناء انتقالها من الهاتف عبر شبكة الواي فاي العامة إلى AWS.
حتى لو اعترض أحدهم حركة الشبكة فلن يتمكن من قراءة الصور لأنها مشفرة أثناء النقل.
بروتوكول TLS يؤمن عملية الرفع ويشفر البيانات أثناء انتقالها من الهاتف عبر شبكة الواي فاي العامة إلى AWS.
حتى لو اعترض أحدهم حركة الشبكة فلن يتمكن من قراءة الصور لأنها مشفرة أثناء النقل.
7️⃣ Protecting data at rest with client-side encryption — حماية البيانات المخزنة بالتشفير من جانب العميل
📖 ما هو التشفير من جانب العميل (Client-Side Encryption)؟
حماية البيانات المخزنة (data at rest) تعني استخدام التشفير لحماية البيانات أينما خُزنت في الحل السحابي. التشفير من جانب العميل يوفر حماية شاملة من طرف إلى طرف للكائن (object) أثناء النقل وأثناء التخزين — من مصدره إلى وجهته في التخزين. يقوم العميل بتشفير البيانات قبل إرسالها، وعند الاسترجاع يحصل على البيانات المشفرة ويفك تشفيرها بنفسه.
حماية البيانات المخزنة (data at rest) تعني استخدام التشفير لحماية البيانات أينما خُزنت في الحل السحابي. التشفير من جانب العميل يوفر حماية شاملة من طرف إلى طرف للكائن (object) أثناء النقل وأثناء التخزين — من مصدره إلى وجهته في التخزين. يقوم العميل بتشفير البيانات قبل إرسالها، وعند الاسترجاع يحصل على البيانات المشفرة ويفك تشفيرها بنفسه.
نيكل يلتقط صوراً للمعجنات بهاتفه المحمول الذي قد يُفقد أو يُسرق بسهولة.
باستخدام تطبيق تشفير على الهاتف، تُشفر الصور قبل رفعها إلى السحابة.
حتى لو ضاع الهاتف أو سُرقت الصور من الخادم السحابي تبقى غير مفهومة لأي شخص لا يملك مفتاح فك التشفير.
التشفير من جانب العميل يضمن أن البيانات آمنة من المصدر إلى التخزين.
باستخدام تطبيق تشفير على الهاتف، تُشفر الصور قبل رفعها إلى السحابة.
حتى لو ضاع الهاتف أو سُرقت الصور من الخادم السحابي تبقى غير مفهومة لأي شخص لا يملك مفتاح فك التشفير.
التشفير من جانب العميل يضمن أن البيانات آمنة من المصدر إلى التخزين.
8️⃣ Protecting data at rest with server-side encryption — حماية البيانات المخزنة بالتشفير من جانب الخادم
📖 ما هو التشفير من جانب الخادم (Server-Side Encryption)؟
في هذا النموذج، تُشفر البيانات قبل تخزينها على الخادم. توفر Amazon S3 تشفيراً من جانب الخادم حيث تشفر الخدمة البيانات على مستوى الكائن (object level) عند كتابتها على الأقراص في مراكز بيانات AWS، وتفك تشفيرها عند طلبها. يتم التشفير تلقائياً باستخدام مفاتيح SSE-S3 (Server-Side Encryption with Amazon S3 Managed Keys) بشكل افتراضي لكل كائن يُرفع.
في هذا النموذج، تُشفر البيانات قبل تخزينها على الخادم. توفر Amazon S3 تشفيراً من جانب الخادم حيث تشفر الخدمة البيانات على مستوى الكائن (object level) عند كتابتها على الأقراص في مراكز بيانات AWS، وتفك تشفيرها عند طلبها. يتم التشفير تلقائياً باستخدام مفاتيح SSE-S3 (Server-Side Encryption with Amazon S3 Managed Keys) بشكل افتراضي لكل كائن يُرفع.
المقهى يخزن أرقام الهوية الضريبية للموظفين في قاعدة بيانات سحابية.
عند كتابة هذه البيانات الحساسة إلى Amazon S3 تقوم الخدمة تلقائياً بتشفيرها على الأقراص.
عند طلب هذه البيانات لاحقاً تُفك تشفيرها وتُعاد آمنة عبر اتصال TLS.
المستخدم لا يحتاج لفعل أي شيء — التشفير من جانب الخادم يعمل بصمت في الخلفية.
عند كتابة هذه البيانات الحساسة إلى Amazon S3 تقوم الخدمة تلقائياً بتشفيرها على الأقراص.
عند طلب هذه البيانات لاحقاً تُفك تشفيرها وتُعاد آمنة عبر اتصال TLS.
المستخدم لا يحتاج لفعل أي شيء — التشفير من جانب الخادم يعمل بصمت في الخلفية.
💡 مقارنة سريعة:
| وجه المقارنة | تشفير من جانب العميل | تشفير من جانب الخادم |
|---|---|---|
| المكان | يُشفر قبل الإرسال من جهاز العميل | يُشفر تلقائياً عند التخزين على الخادم |
| التحكم | العميل يدير المفاتيح بالكامل | AWS تدير المفاتيح (في SSE-S3) |
| النقل | مشفر طوال الرحلة من المصدر إلى التخزين | يُشفر فقط عند وصول الخادم |
مثلما تضع مستنداتك السرية في خزنة حديدية داخل بنك — البنك (AWS) مسؤول عن حماية الخزنة والمبنى، وأنت مسؤول عن إغلاق الخزنة واختيار الرقم السري (least privilege).
التشفير من جانب العميل مثل إرسال المستند مغلقاً ومقفلاً في ظرف، والتشفير من جانب الخادم مثل تسليم المستند للموظف ليضعه في الخزنة بدلاً منك.
التشفير من جانب العميل مثل إرسال المستند مغلقاً ومقفلاً في ظرف، والتشفير من جانب الخادم مثل تسليم المستند للموظف ليضعه في الخزنة بدلاً منك.
✅ خلاصة مبادئ الأمان:
- نموذج المسؤولية المشتركة: AWS مسؤولة عن أمن السحابة والعميل مسؤول عن الأمان داخل السحابة.
- الأمان ركيزة أساسية من ركائز AWS Well-Architected Framework الست.
- مبادئ التصميم السبعة تشمل أساس هوية قوي وحماية البيانات والتتبع والأتمتة والاستعداد للأحداث.
- مبدأ الامتياز الأدنى يعني منح أقل الصلاحيات اللازمة لأداء المهمة.
- تشفير البيانات أثناء النقل يحميها عبر TLS، وتشفيرها أثناء التخزين يحميها في مكانها.
- التشفير من جانب العميل يوفر حماية طرفية كاملة، ومن جانب الخادم يتم تلقائياً دون تدخل المستخدم.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| AWS Shared Responsibility Model | نموذج المسؤولية المشتركة | تقسيم مسؤوليات الأمان بين AWS (أمن السحابة) والعميل (الأمان داخل السحابة). |
| Principle of Least Privilege | مبدأ الامتياز الأدنى | منح أقل الصلاحيات اللازمة لأداء مهمة محددة فقط. |
| Data in Transit | البيانات أثناء النقل | البيانات المنتقلة عبر الشبكة والتي تُحمى باستخدام بروتوكولات مثل TLS. |
| Data at Rest | البيانات المخزنة | البيانات المخزنة على وسائط تخزين والتي تُحمى بالتشفير. |
| Client-Side Encryption | تشفير من جانب العميل | تشفير البيانات من المصدر قبل إرسالها إلى السحابة. |
| Server-Side Encryption | تشفير من جانب الخادم | تشفير تلقائي للبيانات عند تخزينها على الخادم في مراكز بيانات AWS. |
| Defense-in-Depth | الدفاع في العمق | نهج أمني متعدد الطبقات يطبق ضوابط على كل مستوى من البنية التحتية. |
1️⃣ Authentication and authorization — المصادقة والترخيص
📖 ما الفرق بين المصادقة (Authentication) والترخيص (Authorization)؟
المصادقة تجيب على سؤال "من يطلب الوصول؟" وتثبت هوية الطالب من خلال بيانات الاعتماد (credentials) مثل اسم المستخدم وكلمة المرور. الترخيص يجيب على "ما المسموح له فعله؟" بعد المصادقة، ويحدد ما إذا كان يُسمح أو يُرفض الطلب بناءً على الصلاحيات المخولة. يمكن أن يكون الطالب شخصاً أو تطبيقاً.
📋 الفرق بين المفهومين:
المصادقة تجيب على سؤال "من يطلب الوصول؟" وتثبت هوية الطالب من خلال بيانات الاعتماد (credentials) مثل اسم المستخدم وكلمة المرور. الترخيص يجيب على "ما المسموح له فعله؟" بعد المصادقة، ويحدد ما إذا كان يُسمح أو يُرفض الطلب بناءً على الصلاحيات المخولة. يمكن أن يكون الطالب شخصاً أو تطبيقاً.
- المصادقة (Authentication): تثبت هوية المستخدم — "من أنت؟" — عبر اسم المستخدم وكلمة المرور أو MFA.
- الترخيص (Authorization): يحدد الصلاحيات — "ماذا يسمح لك أن تفعل؟" — بعد التحقق من هويتك.
تخيل أن صوفيا تريد الدخول إلى حساب المقهى البنكي عبر الإنترنت لدفع فاتورة.
المصادقة: تدخل اسم المستخدم وكلمة المرور (+ رمز MFA من هاتفها). البنك يتحقق أن هذه صوفيا حقاً.
الترخيص: بعد الدخول، لا تستطيع استخدام أموال حساب آخر — البنك يرخص لها فقط الوصول إلى حساب المقهى الخاص بها.
نفس المبدأ ينطبق تماماً على AWS: أولاً تُوثق هويتك، ثم تُحدد صلاحياتك.
المصادقة: تدخل اسم المستخدم وكلمة المرور (+ رمز MFA من هاتفها). البنك يتحقق أن هذه صوفيا حقاً.
الترخيص: بعد الدخول، لا تستطيع استخدام أموال حساب آخر — البنك يرخص لها فقط الوصول إلى حساب المقهى الخاص بها.
نفس المبدأ ينطبق تماماً على AWS: أولاً تُوثق هويتك، ثم تُحدد صلاحياتك.
2️⃣ AWS Identity and Access Management (IAM) — هوية وإدارة الوصول
📖 ما هي خدمة AWS Identity and Access Management (IAM)؟
IAM هي خدمة تتيح لك التحكم الدقيق في الوصول إلى موارد AWS. يمكنك منح صلاحيات فريدة للمستخدمين والمجموعات، وتحديد أي واجهات برمجة وموارد يمكنهم الوصول إليها. IAM آمن افتراضياً — المستخدمون لا يملكون أي صلاحية حتى تمنحها لهم صراحة. تتكامل IAM مع معظم خدمات AWS وتدعم المصادقة متعددة العوامل (MFA) والهوية الموحدة (federated identity) من أنظمة مثل Microsoft Active Directory.
📋 ميزات IAM الرئيسية:
IAM هي خدمة تتيح لك التحكم الدقيق في الوصول إلى موارد AWS. يمكنك منح صلاحيات فريدة للمستخدمين والمجموعات، وتحديد أي واجهات برمجة وموارد يمكنهم الوصول إليها. IAM آمن افتراضياً — المستخدمون لا يملكون أي صلاحية حتى تمنحها لهم صراحة. تتكامل IAM مع معظم خدمات AWS وتدعم المصادقة متعددة العوامل (MFA) والهوية الموحدة (federated identity) من أنظمة مثل Microsoft Active Directory.
- يتحكم في الوصول الفردي والجماعي إلى موارد AWS.
- يتكامل مع معظم خدمات AWS الأخرى.
- يدير الهوية الموحدة (federated identity management) من أنظمة خارجية.
- يدعم المصادقة متعددة العوامل (MFA) عبر أجهزة مادية أو افتراضية مثل Google Authenticator.
- يسمح بصلاحيات دقيقة وحبيبية (granular permissions).
صوفيا تدير حسابات فريق المقهى على AWS باستخدام IAM.
تنشئ حساباً لكل موظف — نيكل لديه صلاحية قراءة القوائم فقط، وهي تملك صلاحية التعديل.
حساب MFA مفعل على حساب المستخدم الجذر لحمايته من الاختراق.
إذا أراد أحد استشاريي AWS مثل يوسف الوصول المؤقت تستخدم دور IAM بدلاً من إنشاء حساب دائم له.
تنشئ حساباً لكل موظف — نيكل لديه صلاحية قراءة القوائم فقط، وهي تملك صلاحية التعديل.
حساب MFA مفعل على حساب المستخدم الجذر لحمايته من الاختراق.
إذا أراد أحد استشاريي AWS مثل يوسف الوصول المؤقت تستخدم دور IAM بدلاً من إنشاء حساب دائم له.
3️⃣ IAM terminology — مصطلحات IAM
📖 ما هي المصطلحات الأساسية في IAM؟
توجد أربعة مصطلحات رئيسية: مورد IAM (IAM resource) هو كائن المستخدم أو المجموعة أو الدور أو السياسة المخزن في IAM. كيان IAM (IAM entity) هو كائن المورد المستخدم للمصادقة ويشمل المستخدمين والأدوار. هوية IAM (IAM identity) هي كائن المورد المستخدم للتعريف والتجميع ويمكن إرفاق سياسة به (يشمل المستخدمين والمجموعات والأدوار). الطالب (principal) هو الشخص أو التطبيق الذي يستخدم حساباً للمصادقة وتقديم الطلبات.
توجد أربعة مصطلحات رئيسية: مورد IAM (IAM resource) هو كائن المستخدم أو المجموعة أو الدور أو السياسة المخزن في IAM. كيان IAM (IAM entity) هو كائن المورد المستخدم للمصادقة ويشمل المستخدمين والأدوار. هوية IAM (IAM identity) هي كائن المورد المستخدم للتعريف والتجميع ويمكن إرفاق سياسة به (يشمل المستخدمين والمجموعات والأدوار). الطالب (principal) هو الشخص أو التطبيق الذي يستخدم حساباً للمصادقة وتقديم الطلبات.
في المقهى، صوفيا هي طالب (principal) لأنها الشخص الذي يسجل الدخول إلى AWS.
حسابها في IAM هو مورد (resource) وكيان (entity) وهوية (identity) في نفس الوقت.
عندما تسند صلاحية "قراءة القوائم" لمجموعة "الموظفين" ونيكل عضو فيها، ترث المجموعة صلاحية IAM المرتبطة بالسياسة المرفقة بالمجموعة.
حسابها في IAM هو مورد (resource) وكيان (entity) وهوية (identity) في نفس الوقت.
عندما تسند صلاحية "قراءة القوائم" لمجموعة "الموظفين" ونيكل عضو فيها، ترث المجموعة صلاحية IAM المرتبطة بالسياسة المرفقة بالمجموعة.
4️⃣ Using IAM to control access to AWS resources — استخدام IAM للتحكم في الوصول
📖 ما هي العناصر الأربعة للتحكم في الوصول عبر IAM؟
تتحكم IAM بالوصول عبر أربعة عناصر: مستخدم IAM (IAM user) يمثل شخصاً أو تطبيقاً وله بيانات اعتماد دائمة. مجموعة IAM (IAM group) تجمع المستخدمين وتمنحهم نفس الصلاحيات. دور IAM (IAM role) هو هوية مؤقتة بدون بيانات اعتماد طويلة الأمد توفر صلاحيات مؤقتة عند افتراضها. سياسة IAM (IAM policy) هي وثيقة تحدد الموارد المسموح الوصول إليها ومستوى الوصول.
تتحكم IAM بالوصول عبر أربعة عناصر: مستخدم IAM (IAM user) يمثل شخصاً أو تطبيقاً وله بيانات اعتماد دائمة. مجموعة IAM (IAM group) تجمع المستخدمين وتمنحهم نفس الصلاحيات. دور IAM (IAM role) هو هوية مؤقتة بدون بيانات اعتماد طويلة الأمد توفر صلاحيات مؤقتة عند افتراضها. سياسة IAM (IAM policy) هي وثيقة تحدد الموارد المسموح الوصول إليها ومستوى الوصول.
🔑 نصيحة أساسية: الدور في IAM لا يملك بيانات اعتماد طويلة الأمد (كلمة مرور أو مفاتيح وصول). بدلاً من ذلك، عند افتراض الدور تُمنح بيانات اعتماد أمنية مؤقتة (temporary security credentials) تنتهي بانتهاء جلسة الدور.
في المقهى، تنشئ صوفيا مجموعة IAM باسم Employees وتُرفق بها سياسة "قراءة القوائم".
تضيف نيكل وموظفاً آخر إلى هذه المجموعة فيرثان الصلاحية تلقائياً.
عندما يحتاج مستشار يوسف من شركة خارجية إلى الوصول المؤقت لفحص البنية، تُنشئ صوفيا دور IAM بدلاً من إنشاء حساب مستخدم دائم له.
تضيف نيكل وموظفاً آخر إلى هذه المجموعة فيرثان الصلاحية تلقائياً.
عندما يحتاج مستشار يوسف من شركة خارجية إلى الوصول المؤقت لفحص البنية، تُنشئ صوفيا دور IAM بدلاً من إنشاء حساب مستخدم دائم له.
5️⃣ IAM credentials for authentication — بيانات اعتماد IAM للمصادقة
📖 ما نوعا بيانات الاعتماد المستخدمة في AWS؟
نوعان رئيسيان من بيانات الاعتماد يُستخدمان حسب طريقة الوصول: للدخول إلى وحدة تحكم الإدارة (AWS Management Console) يُستخدم اسم المستخدم وكلمة المرور. للوصول عبر واجهة الأوامر (AWS CLI) أو حزم التطوير (SDKs) أو استدعاءات API مباشرة يُستخدم مفتاح وصول AWS (AWS access key) وهو مزيج من معرف مفتاح الوصول (access key ID) ومفتاح الوصول السري (secret access key).
نوعان رئيسيان من بيانات الاعتماد يُستخدمان حسب طريقة الوصول: للدخول إلى وحدة تحكم الإدارة (AWS Management Console) يُستخدم اسم المستخدم وكلمة المرور. للوصول عبر واجهة الأوامر (AWS CLI) أو حزم التطوير (SDKs) أو استدعاءات API مباشرة يُستخدم مفتاح وصول AWS (AWS access key) وهو مزيج من معرف مفتاح الوصول (access key ID) ومفتاح الوصول السري (secret access key).
صوفيا تدخل إلى AWS Management Console من حاسبها المحمول باستخدام اسم المستخدم وكلمة المرور.
عندما تريد بناء تطبيق آلي يُحدّث قائمة المنتجات عبر AWS CLI، تستخدم access key للمصادقة البرمجية.
لا يمكنها استخدام اسم المستخدم وكلمة المرور عبر AWS CLI — كل طريقة وصول تحتاج نوعها المناسب من بيانات الاعتماد.
عندما تريد بناء تطبيق آلي يُحدّث قائمة المنتجات عبر AWS CLI، تستخدم access key للمصادقة البرمجية.
لا يمكنها استخدام اسم المستخدم وكلمة المرور عبر AWS CLI — كل طريقة وصول تحتاج نوعها المناسب من بيانات الاعتماد.
6️⃣ Best practices to secure access — أفضل الممارسات لتأمين الوصول
📖 ما هي أفضل الممارسات التسع لتأمين الوصول في AWS؟
توفر AWS مجموعة من أفضل الممارسات لتأمين الوصول إلى الموارد تشمل تطبيق مبدأ الامتياز الأدنى، تفعيل المصادقة متعددة العوامل (MFA)، استخدام بيانات اعتماد مؤقتة للمستخدمين البشر، تدوير مفاتيح الوصول بانتظام، استخدام كلمات مرور قوية ومعقدة، تأمين بيانات الاعتماد المحلية، استخدام AWS Organizations لتوحيد الحسابات، تفعيل AWS CloudTrail لتسجيل الإجراءات، وحماية المستخدم الجذر (root user).
📋 أفضل الممارسات بالتفصيل:
توفر AWS مجموعة من أفضل الممارسات لتأمين الوصول إلى الموارد تشمل تطبيق مبدأ الامتياز الأدنى، تفعيل المصادقة متعددة العوامل (MFA)، استخدام بيانات اعتماد مؤقتة للمستخدمين البشر، تدوير مفاتيح الوصول بانتظام، استخدام كلمات مرور قوية ومعقدة، تأمين بيانات الاعتماد المحلية، استخدام AWS Organizations لتوحيد الحسابات، تفعيل AWS CloudTrail لتسجيل الإجراءات، وحماية المستخدم الجذر (root user).
- اتبع مبدأ الامتياز الأدنى — امنح أقل الصلاحيات اللازمة.
- فعّل MFA — يضيف طبقة حماية إضافية للمستخدم الجذر وجميع الحسابات.
- اطلب من المستخدمين استخدام بيانات اعتماد مؤقتة عبر IAM roles بدلاً من طويلة الأمد.
- دور مفاتيح الوصول (access keys) بانتظام باستخدام معلومات آخر استخدام.
- استخدم كلمات مرور قوية تتبع إرشادات سياسة كلمة المرور في AWS.
- خزّن المفاتيح وكلمات المرور وMFA tokens في مدير كلمات مرور آمن.
- استخدم AWS Organizations لتجميع الحسابات وإدارة الفواتير والصلاحيات مركزياً.
- فعّل AWS CloudTrail لتسجيل جميع الإجراءات في الحساب لتحديد الثغرات الأمنية.
- احمِ المستخدم الجذر — استخدمه فقط للمهام التي لا يمكن لأي مستخدم آخر تنفيذها.
فريق يوسف الهندسي يطبق جميع أفضل الممارسات على حساب المقهى:
فعّل MFA للمستخدم الجذر وصوفيا، وألغى مفاتيح الوصول غير المستخدمة، وفعّل CloudTrail لتتبع كل تغيير.
عندما يريد مهندس جديد العمل على حساب المقهى، لا ينشئون له حساباً دائماً بل يستخدمون دور IAM بصلاحيات مؤقتة تنتهي بانتهاء المشروع.
فعّل MFA للمستخدم الجذر وصوفيا، وألغى مفاتيح الوصول غير المستخدمة، وفعّل CloudTrail لتتبع كل تغيير.
عندما يريد مهندس جديد العمل على حساب المقهى، لا ينشئون له حساباً دائماً بل يستخدمون دور IAM بصلاحيات مؤقتة تنتهي بانتهاء المشروع.
7️⃣ Protecting the root user — حماية المستخدم الجذر
📖 كيف تحمي المستخدم الجذر (Root User) في AWS؟
المستخدم الجذر هو مالك الحساب ويمتلك صلاحية كاملة على جميع الموارد. يجب حماية بيانات اعتماد المستخدم الجذر كما تحمي رقم بطاقتك الائتمانية. بدلاً من استخدام المستخدم الجذر للمهام اليومية، أنشئ مستخدماً إدارياً عبر AWS IAM Identity Center بصلاحيات مؤقتة. استخدم المستخدم الجذر فقط للمهام التي لا يمكن تنفيذها بواسطة أي مستخدم آخر.
المستخدم الجذر هو مالك الحساب ويمتلك صلاحية كاملة على جميع الموارد. يجب حماية بيانات اعتماد المستخدم الجذر كما تحمي رقم بطاقتك الائتمانية. بدلاً من استخدام المستخدم الجذر للمهام اليومية، أنشئ مستخدماً إدارياً عبر AWS IAM Identity Center بصلاحيات مؤقتة. استخدم المستخدم الجذر فقط للمهام التي لا يمكن تنفيذها بواسطة أي مستخدم آخر.
🔑 نصيحة أساسية: لا تستخدم المستخدم الجذر (root user) في مهامك اليومية أبداً. أنشئ مستخدماً إدارياً (admin user) فوراً بعد إنشاء الحساب واستخدمه للعمل اليومي.
مارثا التي تدير الحساب المالي للمقهى على AWS تحتفظ ببيانات المستخدم الجذر في خزنة حديدية.
تنشئ حساباً إدارياً باسم صوفيا للاستخدام اليومي مع تفعيل MFA.
فقط إذا احتاجت لإغلاق الحساب أو تغيير نوع الدعم تستخدم المستخدم الجذر.
هذا يشبه امتلاك مفتاح رئيسي للمبنى — لا تحمله معك يومياً بل تضعه في مكان آمن وتستخدمه فقط عند الضرورة القصوى.
تنشئ حساباً إدارياً باسم صوفيا للاستخدام اليومي مع تفعيل MFA.
فقط إذا احتاجت لإغلاق الحساب أو تغيير نوع الدعم تستخدم المستخدم الجذر.
هذا يشبه امتلاك مفتاح رئيسي للمبنى — لا تحمله معك يومياً بل تضعه في مكان آمن وتستخدمه فقط عند الضرورة القصوى.
8️⃣ Steps to set up an admin user — خطوات إنشاء مستخدم إداري
📖 ما هي خطوات إنشاء مستخدم إداري في AWS؟
تتضمن العملية أربع خطوات بسيطة: أولاً سجل الدخول كـ root user وفعّل MFA عليه. ثانياً أنشئ مستخدماً إدارياً جديداً وأضف MFA له وحمّل مفاتيح الوصول البرمجية. ثالثاً سجل الخروج من المستخدم الجذر. رابعاً سجل الدخول كالمستخدم الإداري الجديد وابدأ بإنشاء حسابات المستخدمين — كل مستخدم بصلاحياته الخاصة الملائمة لدوره.
تتضمن العملية أربع خطوات بسيطة: أولاً سجل الدخول كـ root user وفعّل MFA عليه. ثانياً أنشئ مستخدماً إدارياً جديداً وأضف MFA له وحمّل مفاتيح الوصول البرمجية. ثالثاً سجل الخروج من المستخدم الجذر. رابعاً سجل الدخول كالمستخدم الإداري الجديد وابدأ بإنشاء حسابات المستخدمين — كل مستخدم بصلاحياته الخاصة الملائمة لدوره.
مارثا تتبع هذه الخطوات لتأمين حساب المقهى الجديد:
تسجل الدخول كجذر وتفعل MFA ← تنشئ حساب "صوفيا" الإداري مع مفاتيح وصول ← تسجل خروج من الجذر ← تسجل دخول كصوفيا ← تنشئ حسابات لنيكل والموظفين بصلاحيات محدودة لكل منهم.
تسجل الدخول كجذر وتفعل MFA ← تنشئ حساب "صوفيا" الإداري مع مفاتيح وصول ← تسجل خروج من الجذر ← تسجل دخول كصوفيا ← تنشئ حسابات لنيكل والموظفين بصلاحيات محدودة لكل منهم.
9️⃣ Best practices: IAM users and groups — أفضل الممارسات: مستخدمي IAM ومجموعاته
📖 كيف تُنظم المستخدمين والمجموعات في IAM؟
أفضل ممارسة لتكوين الوصول طويل الأمد هي إرفاق سياسات IAM بمجموعات IAM ثم تعيين المستخدمين لهذه المجموعات. المستخدم العضو في مجموعة يرث صلاحيات السياسات المرفقة بها. يمكنك أيضاً إرفاق سياسات مباشرة بالمستخدم لتخصيص إضافي للصلاحية الممنوحة عبر المجموعة.
أفضل ممارسة لتكوين الوصول طويل الأمد هي إرفاق سياسات IAM بمجموعات IAM ثم تعيين المستخدمين لهذه المجموعات. المستخدم العضو في مجموعة يرث صلاحيات السياسات المرفقة بها. يمكنك أيضاً إرفاق سياسات مباشرة بالمستخدم لتخصيص إضافي للصلاحية الممنوحة عبر المجموعة.
في المقهى، تُنشئ صوفيا مجموعتين: Employees بصلاحية قراءة القوائم، وManagers بصلاحية تعديل القوائم.
تضيف نيكل إلى مجموعة Employees فيرث الصلاحية تلقائياً.
تضيف نفسها إلى مجموعة Managers فترث صلاحية التعديل.
عند تعيين موظف جديد فقط تحتاج إضافته للمجموعة المناسبة — صلاحياته جاهزة فوراً!
تضيف نيكل إلى مجموعة Employees فيرث الصلاحية تلقائياً.
تضيف نفسها إلى مجموعة Managers فترث صلاحية التعديل.
عند تعيين موظف جديد فقط تحتاج إضافته للمجموعة المناسبة — صلاحياته جاهزة فوراً!
🔟 IAM roles — أدوار IAM
📖 ما هو دور IAM ومتى يُستخدم؟
دور IAM يعرّف مجموعة صلاحيات لمورد يحتاج المستخدم أو الخدمة الوصول إليه. الفرق الأساسي أن الصلاحيات لا تُرفق بالمستخدم أو المجموعة بل بالدور، وعند افتراضه تُنسى صلاحيات المستخدم السابقة مؤقتاً وتُمنح بيانات اعتماد مؤقتة. يُستخدم الدور في حالات متعددة: مستخدم في حساب AWS يحتاج وصولاً مؤقتاً لحساب آخر، مستخدمون موثّقون من نظام خارجي (federated users)، تطبيق جوال، أو تطبيق على EC2 يحتاج الوصول إلى خدمات AWS.
📋 حالات استخدام الأدوار الشائعة:
دور IAM يعرّف مجموعة صلاحيات لمورد يحتاج المستخدم أو الخدمة الوصول إليه. الفرق الأساسي أن الصلاحيات لا تُرفق بالمستخدم أو المجموعة بل بالدور، وعند افتراضه تُنسى صلاحيات المستخدم السابقة مؤقتاً وتُمنح بيانات اعتماد مؤقتة. يُستخدم الدور في حالات متعددة: مستخدم في حساب AWS يحتاج وصولاً مؤقتاً لحساب آخر، مستخدمون موثّقون من نظام خارجي (federated users)، تطبيق جوال، أو تطبيق على EC2 يحتاج الوصول إلى خدمات AWS.
- تطبيق يعمل على Amazon EC2 ويحتاج الوصول إلى موارد AWS أخرى.
- وصول عبر الحسابات (cross-account access) لمستخدم IAM في حساب آخر.
- تطبيقات الجوال التي تحتاج الوصول إلى الموارد دون تخزين بيانات الاعتماد فيها.
- المستخدمون الموحّدون (federated users) من أنظمة خارجية.
تطبيق المقهى الذي يعمل على Amazon EC2 يحتاج حفظ صور الطلبات في Amazon S3.
بدلاً من تخزين مفاتيح وصول طويلة الأمد في التطبيق، تنشئ صوفيا دور IAM بصلاحية الكتابة إلى S3.
تُرفق الدور بملف تعريف الحالة (instance profile) على خادم EC2.
التطبيق الآن يستطيع رفع الصور تلقائياً بصلاحية مؤقتة وآمنة — بدون أي مفاتيح مخزنة محلياً!
بدلاً من تخزين مفاتيح وصول طويلة الأمد في التطبيق، تنشئ صوفيا دور IAM بصلاحية الكتابة إلى S3.
تُرفق الدور بملف تعريف الحالة (instance profile) على خادم EC2.
التطبيق الآن يستطيع رفع الصور تلقائياً بصلاحية مؤقتة وآمنة — بدون أي مفاتيح مخزنة محلياً!
1️⃣1️⃣ Three examples of using an IAM role — ثلاثة أمثلة لاستخدام دور IAM
📖 ما هي السيناريوهات الثلاثة لاستخدام أدوار IAM؟
السيناريو الأول: مستخدم IAM في حساب 1 يحتاج وصولاً مؤقتاً إلى تطبيق على EC2 — يُنشأ دور بصلاحيات ويفترضه المستخدم. السيناريو الثاني: تطبيق على EC2 يحتاج الوصول إلى مجال S3 — يُنشأ دور ويُرفق بملف تعريف الحالة. السيناريو الثالث: مستخدم في حساب 2 يحتاج الوصول إلى مجال S3 في حساب 1 — يُنشأ دور عبر الحسابات (cross-account role) يحدد الحساب 2 ككيان موثوق.
السيناريو الأول: مستخدم IAM في حساب 1 يحتاج وصولاً مؤقتاً إلى تطبيق على EC2 — يُنشأ دور بصلاحيات ويفترضه المستخدم. السيناريو الثاني: تطبيق على EC2 يحتاج الوصول إلى مجال S3 — يُنشأ دور ويُرفق بملف تعريف الحالة. السيناريو الثالث: مستخدم في حساب 2 يحتاج الوصول إلى مجال S3 في حساب 1 — يُنشأ دور عبر الحسابات (cross-account role) يحدد الحساب 2 ككيان موثوق.
تواجه صوفيا ثلاثة احتياجات مختلفة في المقهى:
1. مستشار يوسف (حساب خارجي) يحتاج فحص تطبيق EC2 لمدة يوم — تستخدم دوراً بصلاحية مشاهدة.
2. تطبيق المقهى على EC2 يحتاج رفع صور إلى S3 — ترفق دوراً بملف تعريف الحالة.
3. شريك تجاري في حساب AWS آخر يحتاج تنزيل تقارير من مجال S3 خاص بالمقهى — تنشئ دور عبر الحسابات.
كل حالة تستخدم دوراً بدلاً من إنشاء مستخدم دائم أو تخزين مفاتيح حساسة.
1. مستشار يوسف (حساب خارجي) يحتاج فحص تطبيق EC2 لمدة يوم — تستخدم دوراً بصلاحية مشاهدة.
2. تطبيق المقهى على EC2 يحتاج رفع صور إلى S3 — ترفق دوراً بملف تعريف الحالة.
3. شريك تجاري في حساب AWS آخر يحتاج تنزيل تقارير من مجال S3 خاص بالمقهى — تنشئ دور عبر الحسابات.
كل حالة تستخدم دوراً بدلاً من إنشاء مستخدم دائم أو تخزين مفاتيح حساسة.
مثلما تستخدم بطاقة دخول مؤقتة للفندق بدلاً من مفتاح الغرفة الدائم — البطاقة تعمل فقط أثناء إقامتك وتنتهي صلاحيتها تلقائياً بمجرد المغادرة.
هذا هو مبدأ أدوار IAM: صلاحية مؤقتة لغرض محدد تنتهي بانتهاء الحاجة دون ترك أي مفاتيح دائمة في غير مكانها.
هذا هو مبدأ أدوار IAM: صلاحية مؤقتة لغرض محدد تنتهي بانتهاء الحاجة دون ترك أي مفاتيح دائمة في غير مكانها.
✅ خلاصة المصادقة وتأمين الوصول:
- المصادقة تُثبت هوية الطالب والترخيص يحدد الصلاحيات المسموح بها.
- IAM تتحكم في الوصول عبر المستخدمين والمجموعات والأدوار والسياسات.
- نوعا بيانات الاعتماد: اسم المستخدم وكلمة المرور لوحدة التحكم، ومفتاح الوصول للـ CLI وSDKs.
- أفضل الممارسات تشمل MFA والصلاحيات المؤقتة وتدوير المفاتيح وحماية المستخدم الجذر.
- الدور (role) يمنح صلاحيات مؤقتة بدون بيانات اعتماد دائمة — مثالي للوصول عبر الحسابات والتطبيقات على EC2.
- أفضل ممارسة لإدارة المستخدمين: إرفاق السياسات بالمجموعات ثم إضافة المستخدمين إليها.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Authentication | المصادقة | عملية التحقق من هوية المستخدم أو التطبيق عبر بيانات الاعتماد. |
| Authorization | الترخيص | عملية تحديد الصلاحيات المسموح للمستخدم الموثّق القيام بها. |
| IAM User | مستخدم IAM | كيان يمثل شخصاً أو تطبيقاً ببيانات اعتماد دائمة للتفاعل مع AWS. |
| IAM Group | مجموعة IAM | تجميع للمستخدمين لمنحهم نفس الصلاحيات عبر سياسة مشتركة. |
| IAM Role | دور IAM | هوية مؤقتة بصلاحيات محددة تُمنح عند افتراضها دون بيانات اعتماد دائمة. |
| IAM Policy | سياسة IAM | وثيقة تحدد الموارد المسموح أو الممنوع الوصول إليها ومستوى الوصول. |
| MFA | المصادقة متعددة العوامل | طبقة أمان إضافية تتطلب رمز تحقق إضافي مع كلمة المرور. |
| Root User | المستخدم الجذر | مالك الحساب بصلاحية كاملة — يُستخدم فقط للمهام الحرجة التي لا يقدر عليها غيره. |
1️⃣ IAM policies and permissions — سياسات IAM والأذونات
📖 ما هي سياسات IAM وأنواعها؟
السياسة (policy) هي كائن يُعرّف الصلاحيات للهوية أو المورد المرتبط به. نوعان: السياسات المبنية على الهوية (identity-based policies) تُرفق بمستخدم أو مجموعة أو دور وتحدد ما يمكن لتلك الهوية فعله. السياسات المبنية على المورد (resource-based policies) تُرفق بمورد AWS وتحدد من يمكنه الوصول إليه وكيف. تخزن السياسات بصيغة JSON ويُقيّم IAM هذه السياسات عند تقديم طلب.
السياسة (policy) هي كائن يُعرّف الصلاحيات للهوية أو المورد المرتبط به. نوعان: السياسات المبنية على الهوية (identity-based policies) تُرفق بمستخدم أو مجموعة أو دور وتحدد ما يمكن لتلك الهوية فعله. السياسات المبنية على المورد (resource-based policies) تُرفق بمورد AWS وتحدد من يمكنه الوصول إليه وكيف. تخزن السياسات بصيغة JSON ويُقيّم IAM هذه السياسات عند تقديم طلب.
🔑 نصيحة أساسية: الفرق الجوهري بين النوعين: السياسات المبنية على الهوية تجيب على "ما الذي يمكن لهذا المستخدم فعله؟"، والسياسات المبنية على المورد تجيب على "من يمكنه الوصول إلى هذا المورد؟".
في المقهى، صوفيا ترفق سياسة identity-based بحساب نيكل تسمح له بقراءة قائمة المنتجات فقط.
في المقابل، تضع سياسة resource-based على مجال S3 لتحديد أن الموظفين فقط يمكنهم رفع الصور، والمستشارين يمكنهم عرضها فقط.
كل نوع سياسة يُستخدم لسيناريوهات مختلفة ويكمل الآخر.
في المقابل، تضع سياسة resource-based على مجال S3 لتحديد أن الموظفين فقط يمكنهم رفع الصور، والمستشارين يمكنهم عرضها فقط.
كل نوع سياسة يُستخدم لسيناريوهات مختلفة ويكمل الآخر.
2️⃣ Determining permissions at the time of request — تحديد الأذونات عند الطلب
📖 كيف يقرر IAM السماح أو رفض الطلب؟
يتبع IAM منطق تقييم صارماً: أولاً يتحقق من وجود أي رفض صريح (explicit deny) — إن وُجد يُرفض الطلب فوراً. إن لم يوجد رفض صريح، يتحقق من وجود سماح صريح (explicit allow) — إن وُجد يُسمح بالطلب. إن لم يوجد أي منهما، يُطبق الرفض الضمني (implicit deny) الافتراضي ويُرفض الطلب. ترتيب التقييم لا يؤثر في النتيجة — جميع السياسات تُقيّم معاً والنتيجة نهائية.
يتبع IAM منطق تقييم صارماً: أولاً يتحقق من وجود أي رفض صريح (explicit deny) — إن وُجد يُرفض الطلب فوراً. إن لم يوجد رفض صريح، يتحقق من وجود سماح صريح (explicit allow) — إن وُجد يُسمح بالطلب. إن لم يوجد أي منهما، يُطبق الرفض الضمني (implicit deny) الافتراضي ويُرفض الطلب. ترتيب التقييم لا يؤثر في النتيجة — جميع السياسات تُقيّم معاً والنتيجة نهائية.
نيكل يطلب حذف منتج من القائمة — IAM يقيّم جميع السياسات المرفقة بحسابه.
لا يوجد رفض صريح لحذف المنتج ← يبحث عن سماح صريح ← لا يوجد أيضاً ← النتيجة: رفض ضمني.
هذا هو الإعداد الافتراضي: لا شيء مسموح حتى تمنحه صراحة.
لا يوجد رفض صريح لحذف المنتج ← يبحث عن سماح صريح ← لا يوجد أيضاً ← النتيجة: رفض ضمني.
هذا هو الإعداد الافتراضي: لا شيء مسموح حتى تمنحه صراحة.
3️⃣ Identity-based and resource-based policies — السياسات المبنية على الهوية والموارد
📖 كيف تُستخدم السياسات المبنية على الهوية مقابل المورد؟
السياسات المبنية على الهوية تُرفق بالمستخدم أو المجموعة أو الدور وتحدد الموارد التي يمكن لهذه الهوية الوصول إليها. السياسات المبنية على المورد تُرفق بالمورد نفسه وتحدد من يمكنه الوصول إليه وبأي صلاحية. مثال: سياسة S3 bucket policy هي سياسة مبنية على المورد تسمح أو تمنع وصول مستخدمين محددين إلى المجال.
السياسات المبنية على الهوية تُرفق بالمستخدم أو المجموعة أو الدور وتحدد الموارد التي يمكن لهذه الهوية الوصول إليها. السياسات المبنية على المورد تُرفق بالمورد نفسه وتحدد من يمكنه الوصول إليه وبأي صلاحية. مثال: سياسة S3 bucket policy هي سياسة مبنية على المورد تسمح أو تمنع وصول مستخدمين محددين إلى المجال.
لنفترض أن المستخدم "كارلوس" لديه سياسة identity-based تسمح له بقراءة وكتابة وسرد الملفات في المورد X.
في نفس الوقت، سياسة resource-based على المورد X تسمح بقراءة وسرد فقط.
عند تقييم الطلبين معاً، النتيجة هي القراءة والسرد فقط (الصلاحية الأكثر تقييداً تفوز في التعارض).
في نفس الوقت، سياسة resource-based على المورد X تسمح بقراءة وسرد فقط.
عند تقييم الطلبين معاً، النتيجة هي القراءة والسرد فقط (الصلاحية الأكثر تقييداً تفوز في التعارض).
4️⃣ Policies: Example 1 — مثال: سياسات (1)
📖 كيف تتفاعل السياسات المبنية على الهوية والمورد في المثال الأول؟
المستخدم "بوب" لديه سياسة identity-based تسمح له باستخدام GET وPUT وLIST على المجال X. لكن سياسة resource-based على المجال X تسمح بـ GET وLIST وترفض PUT. النتيجة: بوب لا يستطيع رفع كائنات (PUT) إلى المجال X لأن الرفض الصريح (explicit deny) في سياسة المورد يتجاوز السماح في سياسة الهوية.
المستخدم "بوب" لديه سياسة identity-based تسمح له باستخدام GET وPUT وLIST على المجال X. لكن سياسة resource-based على المجال X تسمح بـ GET وLIST وترفض PUT. النتيجة: بوب لا يستطيع رفع كائنات (PUT) إلى المجال X لأن الرفض الصريح (explicit deny) في سياسة المورد يتجاوز السماح في سياسة الهوية.
🔑 نصيحة أساسية: في IAM، الرفض الصريح (explicit deny) يتجاوز أي سماح صريح — حتى لو سمحت لك سياسة ما بفعل شيء، إذا منعتك سياسة أخرى صراحة فأنت ممنوع.
بوب موظف في شركة تصميم يملك صلاحية رفع الصور (PUT) إلى مجلد إعلانات المقهى.
لكن سياسة على المجلد نفسه تمنع بشكل صريح رفع الصور من خارج نطاق IP مقر الشركة.
عندما يحاول بوب الرفع من منزله، الرفض الصريح يمنعه — رغم أن سياسته الشخصية تسمح بذلك.
IAM دائماً يطبّق القاعدة الأكثر تقييداً.
لكن سياسة على المجلد نفسه تمنع بشكل صريح رفع الصور من خارج نطاق IP مقر الشركة.
عندما يحاول بوب الرفع من منزله، الرفض الصريح يمنعه — رغم أن سياسته الشخصية تسمح بذلك.
IAM دائماً يطبّق القاعدة الأكثر تقييداً.
5️⃣ Policies: Example 2 — مثال: سياسات (2)
📖 كيف تتفاعل السياسات في المثال الثاني؟
المستخدم "بوب" لديه سياسة identity-based تسمح LIST على المجال Y ولا تذكر GET أو PUT (لا سماح ولا رفض). سياسة resource-based على المجال Y تسمح GET وLIST. النتيجة: بوب يستطيع قراءة (GET) الكائنات من المجال Y لأن السماح الصريح في سياسة المورد يكمل ما ينقص سياسة الهوية.
المستخدم "بوب" لديه سياسة identity-based تسمح LIST على المجال Y ولا تذكر GET أو PUT (لا سماح ولا رفض). سياسة resource-based على المجال Y تسمح GET وLIST. النتيجة: بوب يستطيع قراءة (GET) الكائنات من المجال Y لأن السماح الصريح في سياسة المورد يكمل ما ينقص سياسة الهوية.
نيكل لا يملك صلاحية قراءة الملفات من مجال تقارير المقهى في سياسته الشخصية.
لكن سياسة مجال التقارير نفسها تسمح لجميع الموظفين بقراءة الملفات (GET).
لذا يستطيع نيكل قراءة التقارير — السماح من سياسة المورد يمنحه الصلاحية حتى لو لم تذكر في سياسته الشخصية.
العبرة: مجموع جميع السياسات هو ما يحدد الصلاحية النهائية!
لكن سياسة مجال التقارير نفسها تسمح لجميع الموظفين بقراءة الملفات (GET).
لذا يستطيع نيكل قراءة التقارير — السماح من سياسة المورد يمنحه الصلاحية حتى لو لم تذكر في سياسته الشخصية.
العبرة: مجموع جميع السياسات هو ما يحدد الصلاحية النهائية!
💡 مقارنة سريعة:
| وجه المقارنة | سياسة مبنية على الهوية | سياسة مبنية على المورد |
|---|---|---|
| مكان الإرفاق | تٌرفق بالمستخدم أو المجموعة أو الدور | تُرفق بالمورد نفسه (مثل مجال S3) |
| السؤال الذي تجيب عليه | ما الذي يمكن لهذا المستخدم فعله؟ | من يمكنه الوصول إلى هذا المورد؟ |
| المرونة | تحدد صلاحيات الهوية عبر جميع الموارد | تحدد من يمكنه الوصول إلى مورد معين فقط |
| مثال على الخدمة | سياسة IAM user policy | سياسة S3 bucket policy |
✅ خلاصة ترخيص المستخدمين:
- نوعان من السياسات: مبنية على الهوية (identity-based) ومبنية على المورد (resource-based).
- منطق التقييم: رفض صريح ← سماح صريح ← رفض ضمني (افتراضي).
- الرفض الصريح يتجاوز السماح الصريح مهما كان مصدره.
- السياسات المبنية على المورد تسمح بالتحكم الدقيق بالوصول إلى الموارد الفردية.
- تُجمع جميع السياسات معاً لتحديد الصلاحية النهائية — سياسة واحدة قد تمنح صلاحية منقوصة من أخرى.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Identity-Based Policy | سياسة مبنية على الهوية | سياسة تُرفق بمستخدم أو مجموعة أو دور لتحديد صلاحياته عبر الموارد. |
| Resource-Based Policy | سياسة مبنية على المورد | سياسة تُرفق بالمورد لتحديد من يمكنه الوصول إليه وبأي صلاحية. |
| Explicit Deny | رفض صريح | حكم رفض مذكور صراحة في السياسة يتجاوز أي سماح. |
| Explicit Allow | سماح صريح | حكم سماح مذكور صراحة في السياسة يتجاوز الرفض الافتراضي. |
| Implicit Deny | رفض ضمني | الرفض الافتراضي عندما لا يوجد سماح أو رفض صريح ينطبق على الطلب. |
| JSON Policy Document | وثيقة سياسة JSON | صيغة تخزين السياسات في AWS باستخدام تنسيق JSON. |
1️⃣ IAM policy document structure — هيكل وثيقة سياسة IAM
📖 ما هي عناصر وثيقة سياسة IAM؟
تخزّن سياسات IAM كمستندات JSON. كل بيان (statement) يحتوي معلومات عن صلاحية واحدة. العناصر الأساسية: الإصدار (Version) يحدد إصدار لغة السياسة. البيان (Statement) هو الحاوية الرئيسية ويحتوي: التأثير (Effect) — Allow أو Deny. الطالب (Principal) — للسياسات المبنية على المورد فقط. الإجراء (Action) — الإجراء المسموح أو الممنوع. المورد (Resource) — المورد أو الموارد التي ينطبق عليها الإجراء. الشرط (Condition) — اختياري، يحدد الظروف الواجب توفرها.
تخزّن سياسات IAM كمستندات JSON. كل بيان (statement) يحتوي معلومات عن صلاحية واحدة. العناصر الأساسية: الإصدار (Version) يحدد إصدار لغة السياسة. البيان (Statement) هو الحاوية الرئيسية ويحتوي: التأثير (Effect) — Allow أو Deny. الطالب (Principal) — للسياسات المبنية على المورد فقط. الإجراء (Action) — الإجراء المسموح أو الممنوع. المورد (Resource) — المورد أو الموارد التي ينطبق عليها الإجراء. الشرط (Condition) — اختياري، يحدد الظروف الواجب توفرها.
صوفيا تريد السماح لنيكل بقراءة الكائنات من مجال S3 فقط خلال ساعات العمل.
تكتب سياسة JSON فيها: Effect: Allow على إجراء s3:GetObject للمجال المحدد، مع شرط أن يكون وقت الطلب بين 8 صباحاً و5 مساءً.
هذه بنية السياسة متكاملة العناصر: إصدار + بيان + تأثير + إجراء + مورد + شرط.
تكتب سياسة JSON فيها: Effect: Allow على إجراء s3:GetObject للمجال المحدد، مع شرط أن يكون وقت الطلب بين 8 صباحاً و5 مساءً.
هذه بنية السياسة متكاملة العناصر: إصدار + بيان + تأثير + إجراء + مورد + شرط.
2️⃣ Example: resource-based policy — مثال: سياسة مبنية على المورد
📖 كيف تعمل سياسة مبنية على المورد مع عنصر NotResource؟
يجمع المثال بين السماح الصريح والرفض الصريح لتقييد الوصول داخل الحساب. السماح يسمح بأي إجراء DynamoDB أو S3 على موارد محددة (جدول course-notes ومجالَي S3). الرفض يستخدم عنصر NotResource لمنع أي إجراء على أي مورد آخر غير المذكور — حتى لو منحته سياسة أخرى السماح. هذا النمط يضمن حصر الوصول بدقة ضمن النطاق المسموح فقط.
يجمع المثال بين السماح الصريح والرفض الصريح لتقييد الوصول داخل الحساب. السماح يسمح بأي إجراء DynamoDB أو S3 على موارد محددة (جدول course-notes ومجالَي S3). الرفض يستخدم عنصر NotResource لمنع أي إجراء على أي مورد آخر غير المذكور — حتى لو منحته سياسة أخرى السماح. هذا النمط يضمن حصر الوصول بدقة ضمن النطاق المسموح فقط.
المقهى لديه ثلاثة موارد في AWS: جدول طلبات في DynamoDB ومجال صور في S3 ومجال تقارير في S3.
تكتب صوفيا سياسة تسمح الوصول إلى هذه الثلاثة فقط، وترفض صراحة أي وصول إلى أي مورد DynamoDB أو S3 آخر في الحساب.
هذا يضمن أنه حتى لو أضيفت صلاحية جديدة عن طريق الخطأ في سياسة أخرى، الرفض الصريح يمنع أي وصول غير مرغوب.
تكتب صوفيا سياسة تسمح الوصول إلى هذه الثلاثة فقط، وترفض صراحة أي وصول إلى أي مورد DynamoDB أو S3 آخر في الحساب.
هذا يضمن أنه حتى لو أضيفت صلاحية جديدة عن طريق الخطأ في سياسة أخرى، الرفض الصريح يمنع أي وصول غير مرغوب.
3️⃣ Example: Identity-based policy — مثال: سياسة مبنية على الهوية
📖 كيف تعمل سياسة مبنية على الهوية مع أسماء المستخدمين الديناميكية؟
يُظهر المثال سياسة تُرفق بمستخدم IAM تسمح له بإدارة بيانات اعتماده فقط — إنشاء وتعديل وحذف كلمة المرور (LoginProfile) ومفاتيح الوصول (AccessKey) ومفاتيح SSH (SSHPublicKey). تستخدم السياسة ${aws:username} في حقل Resource للحصول على اسم المستخدم الحالي ديناميكياً — مما يعني أن كل مستخدم يمكنه فقط إدارة بيانات اعتماده وليس بيانات غيره.
يُظهر المثال سياسة تُرفق بمستخدم IAM تسمح له بإدارة بيانات اعتماده فقط — إنشاء وتعديل وحذف كلمة المرور (LoginProfile) ومفاتيح الوصول (AccessKey) ومفاتيح SSH (SSHPublicKey). تستخدم السياسة ${aws:username} في حقل Resource للحصول على اسم المستخدم الحالي ديناميكياً — مما يعني أن كل مستخدم يمكنه فقط إدارة بيانات اعتماده وليس بيانات غيره.
صوفيا ترفق هذه السياسة بكل موظف في المقهى.
نيكل يستطيع تغيير كلمة مروره وإنشاء مفتاح وصول خاص به — لكن لا يمكنه تعديل كلمة مرور صوفيا أو أي موظف آخر.
المتغير ${aws:username} يجعل السياسة ذكية — تنطبق على كل مستخدم باسمه تلقائياً دون الحاجة لسياسة منفصلة لكل شخص.
نيكل يستطيع تغيير كلمة مروره وإنشاء مفتاح وصول خاص به — لكن لا يمكنه تعديل كلمة مرور صوفيا أو أي موظف آخر.
المتغير ${aws:username} يجعل السياسة ذكية — تنطبق على كل مستخدم باسمه تلقائياً دون الحاجة لسياسة منفصلة لكل شخص.
4️⃣ Example: Cross-account, resource-based policy — مثال: سياسة عبر الحسابات
📖 كيف تسمح سياسة مبنية على المورد بالوصول عبر حسابات AWS؟
في هذا السيناريو، الحساب A ينشئ سياسة resource-based على مجال S3 خاص به تسمح للحساب B (111122223333) بأي إجراء S3 (مشار إليه بـ *) على المجال. يجب على الحساب B بعد ذلك إنشاء سياسة identity-based تسمح لمستخدميه باستخدام هذه الصلاحية. هذا النمط يُستخدم لمنح الوصول بين الحسابات الموثوقة.
في هذا السيناريو، الحساب A ينشئ سياسة resource-based على مجال S3 خاص به تسمح للحساب B (111122223333) بأي إجراء S3 (مشار إليه بـ *) على المجال. يجب على الحساب B بعد ذلك إنشاء سياسة identity-based تسمح لمستخدميه باستخدام هذه الصلاحية. هذا النمط يُستخدم لمنح الوصول بين الحسابات الموثوقة.
شريك المقهى في مدينة أخرى لديه حساب AWS منفصل ويحتاج تحميل صور العروض الترويجية إلى مجال خاص بالمقهى.
تنشئ صوفيا سياسة على مجال المقهى تسمح لحساب الشريك (برقم الحساب) برفع الصور.
الشريك بدوره ينشئ سياسة داخل حسابه تسمح لفريقه باستخدام هذه الصلاحية.
الآن فريق الشريك يرفع الصور مباشرة إلى مجال المقهى دون الحاجة لحساب IAM دائم — وصول عابر للحسابات بسلاسة وأمان.
تنشئ صوفيا سياسة على مجال المقهى تسمح لحساب الشريك (برقم الحساب) برفع الصور.
الشريك بدوره ينشئ سياسة داخل حسابه تسمح لفريقه باستخدام هذه الصلاحية.
الآن فريق الشريك يرفع الصور مباشرة إلى مجال المقهى دون الحاجة لحساب IAM دائم — وصول عابر للحسابات بسلاسة وأمان.
مثلما تمنح جارك تصريحاً مؤقتاً لاستخدام مسبح منزلك — أنت تحدد المسبح (المورد) والجار (الطالب) والمدة (الشروط).
السياسات المبنية على المورد مثل لافتة على باب المسبح تقول "مسموح للجار فقط، من الساعة 4 إلى 6 مساءً".
وسياسات الهوية مثل المفتاح الذي تحمله — يحدد أي الأبواب يمكنك فتحها داخل العمارة.
السياسات المبنية على المورد مثل لافتة على باب المسبح تقول "مسموح للجار فقط، من الساعة 4 إلى 6 مساءً".
وسياسات الهوية مثل المفتاح الذي تحمله — يحدد أي الأبواب يمكنك فتحها داخل العمارة.
✅ خلاصة أجزاء سياسة IAM:
- عناصر السياسة الأساسية: الإصدار (Version) والبيان (Statement) والتأثير (Effect) والإجراء (Action) والمورد (Resource) والشرط (Condition).
- عنصر NotResource يُستخدم لرفض الوصول إلى كل الموارد ما عدا المحددة.
- المتغير ${aws:username} يسمح بسياسات ديناميكية تنطبق على كل مستخدم حسب اسمه.
- السياسات عبر الحسابات تتطلب تعاوناً بين حسابين: سياسة مورد من الحساب المالك وسياسة هوية من الحساب الضيف.
- كل بيان (statement) يعبر عن صلاحية واحدة — تدمج البيانات بعملية OR منطقية.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Policy Document | وثيقة السياسة | مستند JSON يحدد الصلاحيات ويتكون من بيان أو أكثر. |
| Effect | التأثير | يحدد ما إذا كانت السياسة تسمح (Allow) أو تمنع (Deny) الوصول. |
| Action | الإجراء | عملية محددة يُسمح أو يُمنع تنفيذها مثل s3:GetObject. |
| Resource | المورد | مورد AWS الذي ينطبق عليه الإجراء، يُحدد بصيغة ARN. |
| Principal | الطالب | الحساب أو المستخدم أو الدور الذي يُسمح أو يُمنع له الوصول (للسياسات المبنية على المورد). |
| Condition | الشرط | ظروف إضافية يجب توفرها لتفعيل قاعدة السياسة. |
| NotResource | غير المورد | عنصر يطبق القاعدة على جميع الموارد ما عدا المحددة. |
1. Under the AWS Shared Responsibility Model, who is responsible for patching the guest operating system of an Amazon EC2 instance?
✅ Correct! Under the Shared Responsibility Model, the customer is responsible for managing the guest operating system (including patching), security groups, and firewall configuration on EC2 instances. AWS manages the hypervisor and physical infrastructure.
⌠Incorrect. The correct answer is A) The customer. AWS is responsible for Security OF the Cloud (physical infrastructure, hypervisor), while the customer is responsible for Security IN the Cloud (guest OS, applications, data).
2. A security engineer needs to grant temporary, time-limited access to an S3 bucket for a contractor who works for a different AWS account. Which IAM entity should be used?
✅ Correct! An IAM role with cross-account trust is the correct approach for granting temporary access to users from another AWS account. Roles provide temporary security credentials that expire, eliminating the need to manage long-term credentials for external users.
⌠Incorrect. The correct answer is B) IAM role. IAM roles are designed for cross-account access and provide temporary credentials, making them the secure choice for granting access to external contractors.
3. According to AWS security design principles, which practice best implements the principle of least privilege?
✅ Correct! The principle of least privilege means starting with minimal permissions and granting additional permissions only as needed. It is more secure to begin with a baseline of no access and add specific permissions based on job requirements.
⌠Incorrect. The correct answer is B) Start with a minimum set of permissions and grant additional permissions only when necessary. This approach minimizes the risk of excessive permissions that could be exploited.
4. An application running on Amazon EC2 needs to access an S3 bucket. What is the MOST secure way to provide credentials to the EC2 instance?
✅ Correct! Attaching an IAM role to an EC2 instance profile is the most secure approach. The instance automatically retrieves temporary credentials from the instance metadata service, eliminating the need to store or manage long-term credentials on the instance.
⌠Incorrect. The correct answer is C) Attach an IAM role to the EC2 instance profile. This follows AWS best practices by using temporary credentials and avoiding hardcoded or stored secrets on the instance.
5. In IAM policy evaluation logic, what is the result when a request matches both an explicit allow and an explicit deny?
✅ Correct! In IAM policy evaluation, an explicit deny always overrides any allow. This is a fundamental security principle — if a request matches an explicit deny in any policy, it is immediately denied regardless of any allows that might also apply.
⌠Incorrect. The correct answer is B) The request is denied. IAM follows the rule: explicit deny > explicit allow > implicit deny. An explicit deny from any policy always overrides an explicit allow.
6. Which AWS service can be used to centrally manage permissions across multiple AWS accounts and enforce policies like restricting access to specific Regions?
✅ Correct! AWS Organizations with Service Control Policies (SCPs) provides centralized governance and control over accounts. SCPs allow you to set permission guardrails that apply to all IAM identities across member accounts in the organization.
⌠Incorrect. The correct answer is B) AWS Organizations with Service Control Policies (SCPs). SCPs establish centralized control over the maximum available permissions for all accounts in the organization.
7. A company wants to encrypt data at rest in Amazon S3. They need to use their own encryption keys and maintain control over key rotation and access policies. Which encryption option should they choose?
✅ Correct! SSE-KMS allows you to use AWS Key Management Service with customer managed keys, providing you with control over key rotation, access policies, and audit trails. It offers the most flexibility for organizations that need to manage their own encryption keys.
⌠Incorrect. The correct answer is A) Server-Side Encryption with AWS KMS (SSE-KMS). SSE-KMS provides separate permissions for key usage, automatic key rotation, and integration with AWS CloudTrail for auditing.
8. An administrator needs to track all API calls made in their AWS account for security auditing. Which service should they enable?
✅ Correct! AWS CloudTrail records all API calls made in the account, including the identity of the caller, the time of the call, the source IP address, and the request parameters. This is essential for security analysis, auditing, and compliance.
⌠Incorrect. The correct answer is C) AWS CloudTrail. CloudTrail provides a complete record of API activity in your account, enabling governance, compliance, and operational auditing.
9. What is the difference between authentication and authorization in AWS IAM?
✅ Correct! Authentication (AuthN) answers "Who are you?" by verifying credentials like username/password or MFA. Authorization (AuthZ) answers "What are you allowed to do?" by evaluating IAM policies to determine permitted actions.
⌠Incorrect. The correct answer is B) Authentication verifies the user's identity; authorization determines what actions the user can perform. Authentication must happen first, then authorization determines the scope of permitted actions.
10. A company wants to protect its AWS account root user. Which combination of actions is the MOST effective way to secure the root user?
✅ Correct! AWS best practices recommend enabling MFA on the root user, storing credentials securely, and avoiding its use for everyday tasks. Instead, create IAM admin users with appropriate permissions for daily operations. The root user should only be used for specific account-level tasks.
⌠Incorrect. The correct answer is B) Enable MFA on the root user, avoid using it for daily tasks, and create an IAM admin user instead. The root user has unrestricted access and should be protected with MFA and used only for tasks that require root privileges.
🚀 الخاتمة
في هذه الوحدة تعرفنا على المبادئ الأساسية لتأمين الوصول إلى الموارد في AWS Cloud، بدءاً من نموذج المسؤولية المشتركة الذي يحدد بدقة مسؤوليات كل من AWS والعميل، مروراً بمبادئ التصميم السبعة لركيزة الأمان في AWS Well-Architected Framework. استعرضنا خدمة AWS Identity and Access Management (IAM) بالتفصيل — من المستخدمين والمجموعات والأدوار إلى السياسات بأنواعها المبنية على الهوية والمورد. تعلمنا كيف يقيّم IAM الطلبات عبر منطق الرفض والسماح الصريح والضمني، وكيف نكتب سياسات JSON فعالة تتبع مبدأ الامتياز الأدنى. هذه المفاهيم تشكل أساساً متيناً لكل مهندس سحابة يسعى لبناء حلول آمنة وموثوقة على AWS.