يُعدّ تأمين الوصول إلى الموارد السحابية أحد أهم الأولويات في أي بنية تحتية تعتمد على AWS. في هذه الوحدة، سنستعرض مبادئ الأمان الأساسية، ونشرح AWS Shared Responsibility Model، وركيزة الأمان في إطار Well-Architected، ومبادئ التصميم السبعة للأمان. سنتعمق في خدمة AWS Identity and Access Management (IAM) بأنواعها المختلفة: المستخدمين (Users)، المجموعات (Groups)، الأدوار (Roles)، والسياسات (Policies). وأخيراً، سنفهم بنية مستندات IAM بصيغة JSON، وكيف نطبق مبدأ Least Privilege لحماية بيئتنا. تماماً كما يحمي القلعة بأسوار خارجية وبحراس داخليين وبخزائن للأسرار، تحمي AWS مواردك بطبقات متعددة من الأمان.
1️⃣ Security principles
مبادئ الأمان في AWS تشكل الأساس الذي تبنى عليه جميع استراتيجيات الحماية في السحابة. هناك ثلاثة مبادئ رئيسية يجب مراعاتها عند تصميم بنية آمنة. أولاً: فهم AWS Shared Responsibility Model لتحديد من المسؤول عن أي جزء من الأمان. ثانياً: استخدام Security Pillar من إطار Well-Architected لتحديد مبادئ التصميم المناسبة. ثالثاً: تطبيق Principle of Least Privilege عند تأمين موارد AWS. هذه المبادئ الثلاثة مترابطة: بدون فهم تقسيم المسؤوليات، لا يمكنك تحديد أين يبدأ دورك وأين ينتهي دور AWS. تماماً كما يحتاج مالك المبنى لشريك يفهم من المسؤول عن السور الخارجي (مالك المبنى) ومن المسؤول عن الأبواب الداخلية (المستأجر)، يحتاج cloud architect لفهم توزيع المسؤوليات في السحابة.
2️⃣ AWS shared responsibility model
AWS Shared Responsibility Model يوضح تقسيم مهام الأمان بين AWS والعميل. AWS مسؤولة عن أمان السحابة (Security OF the Cloud)، أي البنية التحتية الأساسية: مراكز البيانات، الشبكات، الأجهزة، الخوادم الفيزيائية، طبقة hypervisor. العميل مسؤول عن الأمان داخل السحابة (Security IN the Cloud)، أي: بيانات العملاء، التطبيقات، أنظمة التشغيل، إعدادات الشبكة والجدار الناري، التشفير، إدارة الهوية والوصول. هذا التقسيم يعني أن AWS تؤمن الأساس وأنت تبني عليه. تماماً كما يبني مالك المبنى السور الخارجي والأبواب الرئيسية، بينما المستأجر مسؤول عن أقفال شقته وتأمين ممتلكاته الخاصة.
3️⃣ Security is a Well-Architected Framework pillar
الأمان هو أحد الركائز الست لإطار Well-Architected، إلى جانب Operational Excellence، Reliability، Performance Efficiency، Cost Optimization، وSustainability. يوفر الإطار أفضل الممارسات والنصائح التصميمية لمساعدتك في اتخاذ القرارات الصحيحة ومراجعة البنى التحتية الحالية. يمكنك استخدام AWS Well-Architected Tool، وهي خدمة ذاتية توفر الوصول عند الطلب إلى أحدث أفضل ممارسات AWS. تجيب الأداة على أسئلة محددة وتقيم بنيتك بناءً على الركائز الست، ثم تقدم خطة عمل للتحسين. تماماً كما يزور الطبيب المستشفى دورياً لتقييم أداء الأقسام، يستخدم cloud architect WA Tool لتقييم بنيته دورياً.
4️⃣ Design principles for the security pillar
ركيزة الأمان في إطار Well-Architected تتضمن سبعة مبادئ تصميم رئيسية. Implement a strong identity foundation: تطبيق مبدأ Least Privilege وفصل المهام. Protect data in transit and at rest: تصنيف البيانات حسب الحساسية وتطبيق التشفير. Apply security at all layers: نهج defense in depth مع ضوابط متعددة على كل المستويات. Keep people away from data: تقليل الوصول اليدوي للبيانات. Maintain traceability: مراقبة وتنبيه كل التغييرات في الوقت الفعلي. Prepare for security events: التحضير للحوادث عبر سياسات incident response. Automate security best practices: أتمتة الأمان عبر Infrastructure as Code. هذه المبادئ السبعة مترابطة وتغطي دورة حياة الأمان الكاملة. تماماً كما يحمي المبنى الذكي بسبع طبقات (أساسات، جدران، أبواب، أقفال، كاميرات، إنذارات، حراسة)، تحمي AWS بنيتك بسبع طبقات.
5️⃣ User permissions to access resources
جزء من تنفيذ أساس هوية قوي هو استخدام السياسات لمنح أو رفض الوصول إلى موارد AWS مثل حاويات Amazon S3 وجداول Amazon DynamoDB. في المثال: المستخدم John يمكنه قراءة وكتابة وحذف الكائنات في حاوية S3 الأولى، لكنه يستطيع فقط قراءة الكائنات في الحاوية الثانية، وهو ممنوع صراحةً من الوصول إلى جدول DynamoDB محدد. هذه الصلاحيات تُعرَّف عبر سياسات IAM بصيغة JSON. يجب أن تكون كل صلاحية مرتبطة بمورد محدد عبر ARN (Amazon Resource Name). تماماً كما يحصل موظف على بطاقة دخول تتيح له دخول بعض الأبواب وتمنعه من أخرى، يحصل IAM user على صلاحيات تتيح له الوصول لبعض الموارد وتمنعه من أخرى.
6️⃣ Principle of least privilege
مبدأ Least Privilege (الامتياز الأقل) هو أحد أهم ممارسات الأمان في AWS. يطلب منك: منح فقط الصلاحيات المطلوبة لأداء المهمة، البدء بمجموعة دنيا من الصلاحيات، منح صلاحيات إضافية حسب الحاجة، وإلغاء الصلاحيات غير الضرورية. هذا النهج يقلل من سطح الهجوم (attack surface) بشكل كبير. لو حصل مهاجم على بيانات اعتماد أحد المستخدمين، فإن الضرر يكون محدوداً بالصلاحيات الممنوحة له فقط. في المثال: John (مستخدم إداري) يحصل على صلاحيات كاملة لـ S3، بينما Mary (مستخدم تسويق) تحصل على قراءة فقط لحاوية واحدة وتمنع من حاوية أخرى. تماماً كما لا يحتاج موظف الاستقبال لمفتاح غرفة الخوادم، لا يحتاج المطور للوصول لموارد الإنتاج الحساسة.
7️⃣ Use encryption
بالإضافة إلى تحديد من لديه صلاحية الوصول إلى البيانات، يجب عليك حماية البيانات نفسها عبر Encryption (التشفير). هذا يتعلق بمبدأ تصميم Protect data in transit and at rest. Data in transit هي البيانات المنتقلة من مكان إلى آخر عبر الإنترنت أو شبكة خاصة. لحماية البيانات أثناء النقل، يمكنك استخدام TLS (Transport Layer Security) لتأمين البيانات أثناء انتقالها. TLS يضمن أن البيانات لا يمكن قراءتها حتى لو اعترضها مهاجم. في AWS، كل الخدمات تستخدم TLS افتراضياً. تماماً كما تضع رسالتك في ظرف مغلق بدلاً من بطاقة بريدية مكشوفة، يحمي TLS بياناتك من القراءة أثناء النقل.
8️⃣ Protecting data at rest with client-side encryption
حماية Data at Rest (البيانات المخزنة) تعني استخدام التشفير لحماية البيانات المخزنة في أي مكان في الحل السحابي. Client-side Encryption يوفر حماية شاملة (end-to-end) للكائن من المصدر إلى التخزين. في هذا الأسلوب: يقوم العميل بتشفير البيانات قبل إرسالها إلى AWS، وعند استرجاعها يقوم العميل بفك التشفير. هذا يعني أن AWS لا ترى البيانات الأصلية أبداً. الميزة: أعلى مستوى من الحماية. العيب: العميل يتحمل مسؤولية إدارة المفاتيح. تماماً كما تشفر وثائقك السرية قبل إرسالها بالبريد، يضمن Client-side Encryption أن البيانات لا يمكن قراءتها حتى لو وصلت ليد غير مصرح بها.
9️⃣ Protecting data at rest with server-side encryption
مع Server-side Encryption، يتم تشفير البيانات قبل تخزينها على الخادم. Amazon S3 يوفر server-side encryption افتراضياً، حيث تقوم الخدمة بتشفير بياناتك على مستوى الكائن عند كتابتها على الأقراص في مراكز بيانات AWS، وفك تشفيرها تلقائياً عند وصولك إليها. لا يحتاج المطور لأي إجراء يدوي. هذا الخيار أبسط من client-side لكن AWS تكون قادرة على رؤية البيانات الأصلية. تماماً كما يضع البنك أموالك في خزنة مقفلة (البنك يعرف ما بداخلها، لكن اللص لا يستطيع الوصول)، يضع S3 بياناتك في تخزين مشفر.
📖 قاموس مصطلحات المحور الأول
| المصطلح (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 and authorization
Authentication (المصادقة) وAuthorization (التفويض) هما مفهومان أساسيان في أمن المعلومات. Authentication تجيب على السؤال: من يطلب الوصول إلى حساب AWS وموارده؟ من المهم تحديد هوية الطالب من خلال بيانات الاعتماد. الطالب يمكن أن يكون شخصاً أو تطبيقاً. Authorization تجيب على السؤال: بعد مصادقة الطالب، ما الذي يُسمح له بفعله؟ تحدد ما إذا كان سيتم السماح أو رفض الطلب. المصادقة تثبت الهوية، والتفويض يحدد الصلاحيات. تماماً كما تحتاج لبطاقة هوية لدخول البنك (مصادقة)، ثم الموظف يتحقق من رصيدك ليسمح لك بالسحب (تفويض).
2️⃣ AWS Identity and Access Management (IAM)
AWS Identity and Access Management (IAM) هي الخدمة التي تتحكم في وصول الأفراد والمجموعات إلى موارد AWS. تتيح لك IAM تكوين تحكم دقيق (fine-grained access control) في الوصول إلى موارد AWS. يمكنك استخدام IAM لاتباع أفضل ممارسات الأمان من خلال منح بيانات اعتماد أمان فريدة لكل مستخدم ومجموعة. IAM آمنة افتراضياً: المستخدمون لا يملكون صلاحية الوصول إلى موارد AWS حتى تُمنح لهم الصلاحيات صراحةً. IAM متكاملة مع معظم خدمات AWS، وتدعم federated identity (مثل Active Directory) وMFA (المصادقة متعددة العوامل). تماماً كما يدير الفندق بطاقات الدخول للموظفين، تدير IAM هويات الوصول لـ AWS.
3️⃣ IAM terminology
هناك مصطلحات مهمة خاصة بـ IAM. الـIAM resource: كائن مخزن في IAM (مستخدم، مجموعة، دور، سياسة، أو موفر هوية). الـIAM entity: كائن IAM تستخدمه AWS للمصادقة (المستخدمون والأدوار فقط). الـIAM identity: كائن IAM يمكن تفويضه في السياسات (مستخدم، مجموعة، أو دور). الـPrincipal: الشخص أو التطبيق الذي يسجل الدخول ويقدم طلبات إلى AWS. الـPrincipal يشمل root user وIAM users والأدوار المفترضة والمستخدمين الموحدين (federated users). تماماً كما يميز البنك بين العميل (Principal) وبطاقته (Identity) وحسابه (Resource) وصلاحياته (Policy)، تميز IAM بين هذه العناصر.
4️⃣ Using IAM to control access to AWS resources
IAM يوفر ثلاث طرق رئيسية للتحكم في الوصول. IAM user (مستخدم IAM): شخص أو تطبيق يمكنه المصادقة باستخدام حساب AWS. يحصل على بيانات اعتماد دائمة. IAM group (مجموعة IAM): مجموعة من المستخدمين يُمنحون صلاحية موحدة. تسهل الإدارة. IAM role (دور IAM): هوية تُستخدم لمنح مجموعة مؤقتة من الصلاحيات. لا يملك بيانات اعتماد دائمة. IAM role يُفترض من قبل شخص أو خدمة عند الحاجة. تماماً كما يميز المسرح بين الممثل الدائم (مستخدم)، وفرقة المسرح (مجموعة)، وزائر يرتدي زياً خاصاً (دور)، تميز IAM بين هذه الأنواع الثلاثة.
5️⃣ IAM credentials for authentication
عند التفاعل مع AWS، يجب تقديم بيانات اعتماد. هناك نوعان رئيسيان حسب طريقة الوصول. Username and password: لـ AWS Management Console (واجهة الويب). AWS access key: مزيج من Access Key ID وSecret Access Key. يُستخدم لـ AWS CLI، AWS SDKs، واستدعاءات API المباشرة. لا يمكن استخدام اسم المستخدم وكلمة المرور للمصادقة البرمجية. access keys هي بيانات اعتماد طويلة الأجل، لذا يجب تدويرها بانتظام. تماماً كما تحتاج لبطاقة صراف للجهاز (access key) ولبطاقة هوية للإنترنت (username/password)، تختلف بيانات الاعتماد حسب طريقة الوصول.
aws s3 cp. لا يحتاج لـ username/password في هذه الحالة. لتدوير المفاتيح، ينشئ مفتاحاً جديداً ويحذف القديم كل 90 يوماً.6️⃣ Best practices to secure access
أفضل ممارسات تأمين الوصول إلى AWS تشمل: اتبع Least Privilege، فعّل MFA، اطلب من المستخدمين البشريين استخدام بيانات اعتماد مؤقتة (عبر SSO أو Identity Center)، قم بتدوير access keys للحالات التي تتطلب بيانات اعتماد طويلة الأجل، استخدم كلمات مرور قوية، احمِ بيانات الاعتماد المحلية، استخدم AWS Organizations، فعّل AWS CloudTrail لتتبع النشاط، واحمِ Root User. الأهم: لا تستخدم Root User للمهام اليومية. تماماً كما لا تستخدم مفتاح المنزل الرئيسي لفتحه يومياً (تحتفظ به للطوارئ)، يجب أن يكون Root User للطوارئ فقط.
7️⃣ Protecting the root user
Root User هو مالك حساب AWS وله صلاحية كاملة غير محدودة لجميع الموارد. لهذا، يجب حماية بيانات اعتماده بأقصى درجة. احمِ بيانات اعتماد Root User كما تحمي رقم بطاقتك الائتمانية. للمهام اليومية، استخدم مستخدماً إدارياً في AWS IAM Identity Center مع بيانات اعتماد مؤقتة. استخدم Root User فقط للمهام التي لا يمكن لأي مستخدم آخر القيام بها: تغيير خطة الحساب، إغلاق الحساب، استعادة الوصول، تفعيل IAM access to billing. تماماً كما لا تشارك مفتاح خزنة البنك مع أي موظف، لا تستخدم Root User إلا في الحالات القصوى.
8️⃣ Steps to set up an admin user
لإعداد مستخدم إداري بدلاً من Root User، اتبع هذه الخطوات. أولاً: سجل الدخول كـ Root User وقم بإعداد MFA على هذا الحساب. ثانياً: أنشئ مستخدماً إدارياً جديداً (John مثلاً)، أضف MFA للمستخدم الجديد، وحمّل المفاتيح البرمجية. ثالثاً: سجل الخروج كـ Root User. رابعاً: سجل الدخول كـ John. خامساً: أنشئ حسابات المستخدمين الآخرين مع سياسات منفصلة لكل واحد. هذه الخطوات الخمس هي أفضل ممارسة لإنشاء بيئة آمنة منذ البداية. تماماً كما تشتري منزلاً جديداً، أول ما تفعله هو تغيير أقفال الباب (إعداد MFA) قبل الانتقال إليه.
9️⃣ Best practices: IAM users and groups
أفضل ممارسة في IAM هي إرفاق سياسات IAM بمجموعات IAM، ثم تعيين المستخدمين إلى هذه المجموعات. المستخدم الذي هو عضو في مجموعة يرث الصلاحيات المرفقة بتلك المجموعة. يمكنك أيضاً إرفاق سياسات IAM مباشرة بمستخدم لتخصيص الوصول الممنوح عبر المجموعة. هذا الأسلوب يسهل الإدارة بشكل كبير: بدلاً من تحديث 50 مستخدماً عند تغيير السياسة، تحدث المجموعة مرة واحدة ويعمم التغيير على كل الأعضاء. في المثال: السياسة 1 مرفقة بمجموعة المبيعات والسياسة 2 مرفقة بمجموعة تقنية المعلومات. تماماً كما يصدر المدير قراراً واحداً لكل قسم بدلاً من إصدار قرار لكل موظف، تُدار الصلاحيات عبر المجموعات.
🔟 IAM roles
IAM Role (دور IAM) يوفر بيانات اعتماد أمان مؤقتة ولا يرتبط بشخص واحد بشكل فريد. يمكن افتراض الدور من قبل شخص أو تطبيق أو خدمة. يُستخدم IAM Role غالباً لتفويض الوصول. حالات الاستخدام الشائعة: تطبيق يعمل على EC2 يحتاج للوصول إلى S3، وصول عبر الحسابات لمستخدم IAM، تطبيقات الجوال التي تحتاج لاستدعاء خدمات AWS، خدمات AWS التي تحتاج للوصول لبعضها. عند افتراض دور، تُلغى صلاحيات المستخدم السابقة مؤقتاً وتُستبدل بصلاحيات الدور. تماماً كما يرتدي عامل المستشفى زياً خاصاً لدخول غرفة العمليات، يفترض التطبيق دوراً خاصاً للوصول لمورد معين.
1️⃣1️⃣ Three examples of using an IAM role
ثلاثة أمثلة شائعة لاستخدام IAM roles. المثال الأول: مستخدم IAM في حساب 1 يحتاج وصولاً مؤقتاً لمورد في حساب آخر. الحل: تنشئ سياسة IAM بالصلاحيات، تنشئ IAM role وتُرفق السياسة به، والمستخدم يفترض الدور. المثال الثاني: تطبيق على EC2 يحتاج الوصول لـ S3. تنشئ IAM role بسياسة S3، تضيف الدور إلى instance profile، تربطها بالمثيل. المثال الثالث: خدمة AWS مثل Lambda تحتاج للوصول لـ DynamoDB. تنشئ IAM role بسياسة DynamoDB، تربطه بدالة Lambda. تماماً كما يستخدم ساعي البريد بطاقة هوية موحدة لدخول عدة مبانٍ، تستخدم IAM role للوصول لعدة موارد.
📖 قاموس مصطلحات المحور الثاني
| المصطلح (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 and permissions
السياسة (Policy) هي كائن JSON يحدد الصلاحيات للهوية أو المورد المرتبط بها. باستخدام السياسات، يمكنك ضبط الصلاحيات الممنوحة للموجهين (principals) مثل مستخدمي IAM وأدوار IAM وخدمات AWS. هناك نوعان من السياسات. Identity-based policies (قائمة على الهوية): تُرفق بمستخدم أو مجموعة أو دور IAM وتحدد ما يُسمح للهوية بفعله. Resource-based policies (قائمة على المورد): تُرفق بمورد AWS (مثل حاوية S3) وتحدد من يمكنه الوصول إليها. يتم تعريف الصلاحيات في مستندات سياسة IAM بصيغة JSON. تماماً كما يضع النادي لائحة داخلية (identity-based) تحدد ما يمكن للأعضاء فعله، ولائحة للزوار (resource-based) تحدد من يدخل، تعمل IAM بسياسات من نوعين.
2️⃣ Determining permissions at the time of request
عندما يحدد IAM ما إذا كان الإجراء مسموحاً، تتبع AWS منطق تقييم محدد. أولاً: تتحقق من وجود أي سياسة منع صريح (explicit deny). إذا وُجد منع صريح، يُرفض الطلب فوراً. ثانياً: إذا لم يوجد منع صريح، تتحقق من وجود أي سياسة سماح صريح (explicit allow). إذا وُجد سماح، يُسمح. ثالثاً: إذا لم توجد سياسة منع أو سماح صريحة، تعود IAM إلى المنع الضمني (implicit deny) وترفض الوصول. القاعدة الأساسية: بشكل افتراضي، كل الطلبات مرفوضة. Explicit Deny يتجاوز أي Explicit Allow. تماماً كما لا يستطيع أي شخص دخول القصر ما لم يُسمح له صراحةً (implicit deny)، ولا يستطيع الدخول حتى بوجود إذن إذا كان مدرجاً في قائمة المنع (explicit deny).
3️⃣ Identity-based and resource-based policies
السياسات القائمة على الهوية (Identity-based) تُرفق بمستخدم أو مجموعة أو دور IAM وتجيب على السؤال: ما الذي تملك صلاحية الوصول إليه هوية معينة؟ على سبيل المثال، Carlos لديه صلاحية قراءة وكتابة وقائمة على المورد X، بينما Richard ليس لديه أي صلاحية. السياسات القائمة على المورد (Resource-based) تُرفق بالمورد نفسه (مثل حاوية S3) وتحدد من يمكنه الوصول إليه. الفرق الرئيسي هو مكان التطبيق: identity-based تحدد ما يمكن للهوية فعله، وresource-based تحدد من يصل للمورد. تماماً كما يحصل موظف على بطاقة هوية تحدد ما يمكنه فعله (identity-based)، وتضع الشركة لافتة على باب غرفة تقول "هذه الغرفة لموظفي قسم X فقط" (resource-based).
4️⃣ Policies: Example 1
المثال الأول لسياسة قائمة على الهوية: المستخدم Bob لديه سياسة تسمح له بعمليات Get وPut وList على حاوية X. بالنسبة للحاوية Y، الصلاحية غير محددة (N/A) مما يعني عدم وجود وصول. هذه السياسة تمنح Bob صلاحية التعامل مع حاوية S3 محددة فقط. هذا مفيد عندما تريد منح مطور صلاحية الوصول إلى حاوية تطوير محدد دون منحه صلاحية الوصول إلى حاويات الإنتاج الحساسة. تتم كتابة السياسة بصيغة JSON مع تحديد Action وResource بدقة. تماماً كما يحصل موظف على مفتاح يفتح غرفة محددة فقط، يحصل Bob على صلاحية تتيح الوصول لحاوية محددة فقط.
s3:GetObject وs3:PutObject على arn:aws:s3:::staging-bucket/*. المطور يصل لبيئة staging دون رؤية بيانات الإنتاج. لو حدث خطأ في الكود وأراد حذف ملف إنتاجي، يُمنع تلقائياً.5️⃣ Policies: Example 2
المثال الثاني: Bob لا يزال لديه صلاحيات Get وPut وList على الحاوية X. الصلاحية على الحاوية Y غير محددة (N/A)، لذلك حتى لو كان هناك سماح صريح للحاوية X، فإن الحاوية Y تبقى ممنوعة (implicit deny). هذا يوضح أهمية تحديد الموارد بدقة في السياسات. نهج الأمان الأفضل هو "القائمة البيضاء": حدد بوضوح ما هو مسموح به، وكل ما لم يُذكر فهو ممنوع تلقائياً. تماماً كما لا يستطيع موظف دخول أي غرفة ما لم يُذكر اسمها صراحةً في بطاقة دخوله، لا يستطيع Bob الوصول لأي حاوية ما لم تُذكر في سياسته.
"Resource": "*" التي تمنح وصولاً واسعاً. النتيجة: كل موظف يرى فقط الموارد التي يحتاجها. حتى لو حدث اختراق، الضرر محدود.📖 قاموس مصطلحات المحور الثالث
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Policy | السياسة | مستند JSON يحدد الصلاحيات لهوية أو مورد. |
| Identity-based Policy | سياسة قائمة على الهوية | سياسة تُرفق بمستخدم أو مجموعة أو دور IAM. |
| Resource-based Policy | سياسة قائمة على المورد | سياسة تُرفق بمورد AWS مثل حاوية S3. |
| Explicit Allow | سماح صريح | تجاوز المنع الافتراضي ويسمح بالإجراء. |
| Explicit Deny | منع صريح | يتجاوز أي سماح ويرفض الإجراء نهائياً. |
| Implicit Deny | منع ضمني | المنع الافتراضي عند عدم وجود سماح صريح. |
| ARN | اسم مورد أمازون | معرف فريد لكل مورد في AWS، يستخدم في السياسات. |
| JSON | تنسيق JSON | لغة منظمة لكتابة سياسات IAM بشكل قابل للقراءة. |
1️⃣ IAM policy document structure
مستند سياسة IAM يتكون من عدة عناصر رئيسية. Version: إصدار لغة السياسة (عادةً "2012-10-17"). Statement: العنصر الرئيسي الذي يحدد ما هو مسموح أو ممنوع. داخل Statement توجد: Effect (Allow أو Deny)، Principal (لسياسات المورد فقط، يحدد الحساب أو المستخدم)، Action (يسرد إجراءات AWS API المسموحة أو الممنوعة، يدعم wildcards مثل s3:*)، Resource (يحدد موارد AWS عبر ARN)، وCondition (ظروف إضافية مثل IP أو الوقت). كل عنصر اختياري ما عدا Effect. تماماً كما تتكون الوصفة من اسم الطبق، المكونات، الكميات، والظروف (فرن، حرارة، وقت)، تتكون السياسة من هذه العناصر الخمسة.
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::my-bucket/*" }] }. هذه السياسة تسمح بقراءة الكائنات من my-bucket. كل عنصر يخدم غرضاً: Version يحدد الصيغة، Effect يسمح، Action يحدد الإجراء، Resource يحدد الهدف.2️⃣ Example: resource-based policy
مثال على سياسة قائمة على المورد: تسمح السياسة صراحةً بأي إجراء (*) على DynamoDB أو S3 على جدول DynamoDB المسمى course-notes، وحاوية S3 المسماة course-notes-web، وكائنات حاوية course-notes-mp3. هذه سياسة resource-based لأنها تُرفق بالمورد نفسه (جدول DynamoDB أو حاوية S3) وتحدد من يمكنه الوصول إليه. لاحظ وجود Principal في السياسة (لأنه resource-based). تماماً كما يضع المتحف لوحة على الباب تقول "الطلاب المسجلون في دورة X يمكنهم مشاهدة هذا المعرض"، تحدد resource-based policy من يصل للمورد.
3️⃣ Example: Identity-based policy
مثال على سياسة قائمة على الهوية: تسمح السياسة للمستخدم بإجراء عمليات إدارة ملف تعريف تسجيل الدخول (iam:CreateLoginProfile)، ومفاتيح الوصول (iam:CreateAccessKey)، والمفاتيح العامة SSH (iam:UploadSSHPublicKey). لكن لاحظ أن المورد محدد كـ ${aws:username}، مما يعني أن السياسة تنطبق فقط على المستخدم نفسه. هذا يطبق Least Privilege بدقة: المستخدم يمكنه إدارة بيانات الاعتماد الخاصة به فقط، وليس بيانات اعتماد الآخرين. لاحظ عدم وجود Principal في السياسة (لأنها identity-based ومُرفقة بالفعل بالمستخدم). تماماً كما يستطيع كل موظف تغيير كلمة المرور الخاصة بمكتبه فقط، يستطيع IAM user إدارة بياناته الشخصية فقط.
${aws:username}. النتيجة: الموظف مستقل، admin مرتاح.4️⃣ Example: Cross-account, resource-based policy
مثال على سياسة عبر الحسابات (Cross-account): الحساب A ينشئ سياسة على حاوية S3 تسمح للحساب B (رقم الحساب 111122223333) بالوصول الكامل (*) إلى جميع عمليات S3 على الحاوية. هذا النوع من السياسات resource-based يسمح بمشاركة الموارد عبر حسابات AWS مختلفة دون مشاركة كلمات المرور أو إنشاء مستخدمين جدد. يستخدم Principal لتحديد الحساب الآخر. تماماً كما تشارك شركتان مشروعاً: تمتلك إحداهما المستودع وتضع الأخرى في قائمة الوصول المسموح، تستخدم cross-account policy لمشاركة آمنة بين الحسابات.
📖 قاموس مصطلحات المحور الرابع
| المصطلح (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 مختلف. |
🚀 الخاتمة
في هذه الوحدة استعرضنا أساسيات تأمين الوصول في AWS. تعلمنا أن الأمان مسؤولية مشتركة بين AWS (أمان السحابة) والعميل (الأمان داخل السحابة)، وأن ركيزة الأمان في Well-Architected تتضمن سبعة مبادئ تصميم تشمل Least Privilege وحماية البيانات والتشفير. تعرفنا على خدمة AWS IAM بأنواعها المختلفة (User, Group, Role)، وكيف يفرق بين Authentication وAuthorization عبر بيانات اعتماد مؤقتة ودائمة. فهمنا بنية السياسات (Identity-based, Resource-based)، ومنطق التقييم (Explicit Deny, Explicit Allow, Implicit Deny). وأخيراً، تعرفنا على بنية مستند JSON للسياسة وعناصره الخمسة (Version, Statement, Effect, Action, Resource, Condition). تذكر دائماً: الأمان ليس وجهة بل رحلة مستمرة من التعلم والتحسين، تماماً كما السيف يحتاج للصقل المستمر ليبقى حاداً.