AWS SAA 09 - Securing User and Application Access

🎯 Securing User, Application, and Data Access — تأمين وصول المستخدم والتطبيق والبيانات

مع تزايد تعقيد البيئات السحابية، تصبح الحاجة إلى حلول أمان متقدمة أكثر إلحاحاً. يغطي هذا المقال ميزات IAM المتقدمة مثل اتحاد الهوية (Identity Federation) و ABAC، بالإضافة إلى تشفير البيانات باستخدام KMS و CloudHSM، وخدمات الأمان مثل GuardDuty و Inspector و WAF.

1️⃣ AWS Organizations

📖 AWS Organizations هي خدمة مركزية لإدارة عدة حسابات AWS تحت مظلة واحدة مع سياسات حوكمة ودمج الفوترة.
بدلاً من إدارة 30 حساب AWS بشكل منفصل (مستخدمون، صلاحيات، فواتير)، تديرها كلها من حساب رئيسي واحد عبر هيكل شجري من الوحدات التنظيمية (OUs).
📋 المكونات الرئيسية لـ AWS Organizations
  • حساب الإدارة (Management Account): الحساب الرئيسي الذي تنشئ منه المؤسسة وتدير كل شيء — لا تضع فيه أحمال عمل، هو للإدارة فقط.
  • الحسابات الأعضاء (Member Accounts): حسابات AWS العادية التي تحتوي على مواردك الفعلية (إنتاج، تطوير، اختبار...).
  • الوحدات التنظيمية (Organizational Units - OUs): مجلدات لتجميع الحسابات حسب الوظيفة — مثلاً OU للإنتاج وOU للتطوير وOU للأمان.
  • سياسات التحكم في الخدمة (SCPs): تحدد الصلاحيات القصوى المسموحة في الحسابات — حتى لو أعطى IAM صلاحية، SCP يمكنه منعها.
  • الفوترة الموحدة (Consolidated Billing): فاتورة واحدة لكل الحسابات مع خصومات الحجم التراكمي.
شركة لديها 15 حساب AWS لفريق التطوير والإنتاج والتحليلات.
تنشئ مؤسسة في AWS Organizations بهيكل:.
Root → OU_Production (3 حسابات) | OU_Development (8 حسابات) | OU_Security (2 حسابات) | OU_Analytics (2 حسابات).
تطبق SCP على OU_Development: منع إنشاء موارد خارج regions محددة (للتحكم بالتكلفة).
تطبق SCP على الجميع: منع حذف سجلات CloudTrail (للأمان).
الفوترة الموحدة تجمع استهلاك كل الحسابات — خصم أكبر على Reserved Instances وSavings Plans لأن الحجم التراكمي أكبر.

2️⃣ سياسات التحكم في الخدمة (SCP)

📖 سياسة التحكم في الخدمة (Service Control Policy - SCP) هي الحد الأقصى للصلاحيات في الحساب — لا يمكن لأي كيان (مستخدم، دور) تجاوزها حتى لو منحته IAM الصلاحية.
SCP يشبه حارس البوابة للمؤسسة: يحدد ما هو مسموح به كحد أقصى لكل حساب، وسياسات IAM تحدد الصلاحيات الفعلية ضمن هذا الحد.
📋 كيف تعمل SCPs؟
  • SCP لا يمنح صلاحيات — هو فقط يحدد الحد الأعلى المسموح به (guardrail).
  • الصلاحية النهائية = (صلاحيات IAM) ∩ (ما يسمح به SCP).
  • إذا SCP يمنع EC2 تماماً، حتى لو أعطى IAM صلاحية AdministratorAccess — لا يمكنه استخدام EC2.
  • SCP يمكن تطبيقه على المؤسسة كاملة، على OU محدد، أو على حساب محدد (يرثها الأبناء).
  • سياسة FullAWSAccess الافتراضية تسمح بكل شيء — أضف SCPs مقيدة حسب الحاجة.
🔑 منطق تقييم SCP: ترتيب التقييم هو: Explicit Deny > Explicit Allow > Implicit Deny. SCP يُطبق كحد أعلى (سقف) على مستوى الحساب. الصلاحية النهائية = (سياسات IAM) ∩ (SCP). أي إجراء تُمنعه SCP لا يمكن لأي كيان في الحساب تنفيذه حتى لو منحته IAM صلاحية كاملة. تذكّر: SCP لا يمنح صلاحيات — هو فقط يُضيّق الحدود القصوى.
فريق DevOps في OU_Development يجب ألا يستطيع إنشاء مثيلات EC2 من عائلات GPU باهظة الثمن.
يُطبق SCP على OU_Development:.
{ "Effect": "Deny", "Action": "ec2:RunInstances", "Condition": { "StringLike": { "ec2:InstanceType": "*.8xlarge" } } }
حتى لو مهندس لديه صلاحية AdministratorAccess في حسابه، SCP يمنعه من إطلاق أي مثيل بحجم 8xlarge فأكثر.
يوفر على الشركة آلاف الدولارات من المثيلات الباهظة التي قد تُطلق بالخطأ.
خلاصة AWS Organizations:
  • إدارة مركزية للحسابات المتعددة عبر هيكل OUs شجري.
  • SCPs تحدد الحدود القصوى للصلاحيات — لا يمكن تجاوزها.
  • الفوترة الموحدة تجمع الاستهلاك للحصول على خصومات أفضل.
  • الحساب الإداري يجب ألا يحتوي على أحمال عمل — فقط للإدارة.

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

المصطلح (English)الترجمةالمفهوم
Management Accountحساب الإدارةالحساب الرئيسي الذي يدير المؤسسة — لا يحتوي على أحمال عمل.
Member Accountحساب عضوحساب AWS عادي ضمن المؤسسة يحتوي على الموارد الفعلية.
Organizational Unitوحدة تنظيميةمجلد لتجميع الحسابات حسب الوظيفة لتطبيق سياسات موحدة.
SCPسياسة التحكم في الخدمةتحدد الحد الأقصى للصلاحيات في الحساب — لا يمكن تجاوزها.
Consolidated Billingالفوترة الموحدةفاتورة واحدة لجميع الحسابات مع خصومات الحجم التراكمي.

1️⃣ Advanced IAM Policies — سياسات IAM المتقدمة

📖 سياسات IAM تتكون من عناصر متعددة: Effect وAction وResource وCondition — لكن العنصر الأقوى الذي يمنح تحكماً دقيقاً هو Condition.
شرط Condition يسمح لك بتقييد الصلاحية بناءً على السياق: الوقت، عنوان IP، طريقة المصادقة، العلامات (tags)، وغيرها.
📋 مفاتيح الشرط (Condition Keys) الشائعة
  • aws:SourceIp: تقييد الوصول من نطاق IP محدد — مثلاً السماح بالوصول لوحدة التحكم فقط من شبكة المكتب.
  • aws:RequestedRegion: تقييد الإجراءات على مناطق AWS محددة.
  • aws:MultiFactorAuthPresent: اشتراط تفعيل MFA لتنفيذ إجراءات معينة (مثل حذف S3 bucket).
  • aws:CurrentTime: تقييد الوصول بأوقات محددة من اليوم أو أيام الأسبوع.
  • ec2:ResourceTag: السماح بإجراءات فقط على موارد تحمل Tags محددة (مثلاً Environment=Dev).
  • aws:PrincipalTag: مطابقة Tags المستخدم مع Tags المورد — تحكم دقيق جداً.
سياسة IAM تمنح صلاحية إيقاف وتشغيل مثيلات EC2 لكن بشروط صارمة.
الشرط 1: فقط المثيلات التي تحمل tag "Environment=Dev" (يمنع العبث بالإنتاج).
الشرط 2: فقط من نطاق IP الخاص بشبكة المكتب (يمنع الوصول من خارج الشركة).
الشرط 3: فقط إذا كان MFA مفعّلاً (يمنع استخدام بيانات اعتماد مسروقة).
النتيجة: مهندس DevOps يمكنه إدارة بيئة التطوير من مكتبه فقط وبعد التحقق الثنائي — أمان متعدد الطبقات في سياسة واحدة.

2️⃣ حدود الأذونات (Permission Boundaries)

📖 حد الأذونات (Permission Boundary) هو سياسة IAM تُستخدم كسقف للصلاحيات القصوى التي يمكن لمستخدم أو دور الحصول عليها.
على عكس SCP الذي يُطبق على الحساب كاملاً، Permission Boundary يُطبق على مستخدم أو دور محدد — تحكم أدق.
📋 SCP مقابل Permission Boundary مقابل IAM Policy
  • SCP: حد أقصى على مستوى الحساب — يُطبق على كل الكيانات في الحساب. يُعرّف في AWS Organizations.
  • Permission Boundary: حد أقصى على مستوى المستخدم/الدور — يُطبق على كيان محدد فقط. يُعرّف في IAM.
  • IAM Policy: الصلاحيات الفعلية الممنوحة — يجب أن تكون ضمن حدود SCP وPermission Boundary معاً.
  • الصلاحية النهائية = IAM Policy ∩ Permission Boundary ∩ SCP.
شركة تسمح للمطورين بإنشاء أدوار IAM بأنفسهم (للتطبيقات) لكن تخشى أن يمنحوا أدواراً بصلاحيات مدير كامل.
تضع Permission Boundary على كل مطور: يسمح بإنشاء أدوار IAM لكن بشرط أن تحمل جميعها Permission Boundary محدداً يمنع IAM full access.
عندما يحاول مطور إنشاء دور جديد ويمنحه AdministratorAccess: يفشل — Permission Boundary يمنع إنشاء أي دور بدون ربطه بسياسة الحدود.
النتيجة: المطورون لديهم مرونة في إنشاء الأدوار لكن ضمن سقف أمان محدد.
🔑 تحديات RBAC عند التوسع: نموذج RBAC (التحكم بالوصول القائم على الأدوار) يصبح غير عملي عند نمو المؤسسة بسرعة. مع كل دور جديد يجب كتابة سياسة تسرد موارد محددة، ومع كل مورد جديد يجب تحديث كل سياسة. في مؤسسة تضم 100 دور و 1,000 مورد، تحتاج 100,000 تحديث سياسة — وهذا غير مستدام. الحل هو ABAC (التحكم بالوصول القائم على السمات) الذي يستخدم العلامات (Tags) لربط المستخدمين بالموارد تلقائياً دون تحديث السياسات.

3️⃣ Roles vs Users — الأدوار مقابل المستخدمين

🔑 قاعدة ذهبية:
استخدم أدوار IAM للتطبيقات والخدمات (مثيلات EC2، Lambda، ECS) — صلاحيات مؤقتة وآمنة.
استخدم مستخدمي IAM فقط للأشخاص الذين يحتاجون وصولاً طويل الأمد لوحدة التحكم أو CLI — ولا تنسَ تفعيل MFA.
لا تستخدم users للتطبيقات أبداً — إدارة المفاتيح الدائمة (access keys) خطر أمني كبير.
كلما قل عدد مستخدمي IAM وزاد عدد الأدوار، كان وضعك الأمني أفضل.
خلاصة IAM المتقدم:
  • مفاتيح الشرط (Condition Keys) تقيد الصلاحيات بناءً على السياق: IP، المنطقة، MFA، الوقت، والعلامات.
  • حد الأذونات (Permission Boundary) سقف إضافي على المستخدم أو الدور فوق IAM وتحت SCP.
  • استخدم أدوار IAM للتطبيقات والخدمات، ومستخدمي IAM فقط للأشخاص.
  • ABAC باستخدام العلامات (Tags) يحل مشكلة توسع RBAC في المؤسسات الكبيرة.

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

المصطلح (English)الترجمةالمفهوم
Condition Keyمفتاح الشرطعنصر في سياسة IAM يُقيد الصلاحية بناءً على السياق مثل IP أو الوقت أو MFA.
Permission Boundaryحد الأذوناتسياسة IAM تُحدد السقف الأعلى لصلاحيات مستخدم أو دور محدد.
SCPسياسة التحكم في الخدمةسياسة على مستوى الحساب تحدد الحد الأقصى للصلاحيات — لا يمكن تجاوزها.
IAM Roleدور IAMهوية بصلاحيات مؤقتة تُستخدم للتطبيقات والخدمات بدلاً من المستخدمين الدائمين.
IAM Policyسياسة IAMمستند JSON يحدد الصلاحيات الممنوحة ويجب أن تكون ضمن حدود SCP و Permission Boundary.

1️⃣ What is ABAC? — ما هو ABAC؟

📖 التحكم بالوصول القائم على السمات ABAC (Attribute-Based Access Control) هو استراتيجية تفويض تُعرّف الصلاحيات بناءً على السمات (Attributes) المرتبطة بالمستخدمين والموارد.
في AWS، السمات تُسمى العلامات Tags — أزواج مفتاح-قيمة (key-value) تُرفق بموارد IAM (مستخدمين/أدوار) وموارد AWS. السياسة تتحقق: هل سمة المستخدم تطابق سمة المورد الذي يريد الوصول إليه؟ بدون الحاجة لتحديد كل مورد بشكل منفصل في ملف السياسة.
📋 كيف يعمل ABAC؟
  • كل مستخدم IAM أو دور يُوسم بعلامات مثل Department=Finance أو Project=Alpha.
  • كل مورد AWS (مثل S3 bucket أو EC2 instance) يُوسم بنفس العلامات المطابقة.
  • سياسة IAM واحدة تستخدم مفتاح الشرط aws:PrincipalTag لمطابقة علامة المستخدم مع aws:ResourceTag للمورد.
  • عند وصول مستخدم لمورد، يتحقق النظام: هل علامة "Project" على المستخدم = علامة "Project" على المورد؟ إذا نعم → مسموح، إذا لا → ممنوع.
  • لا حاجة لتعديل السياسة عند إضافة مستخدمين جدد أو موارد جديدة — فقط أضف العلامة الصحيحة.
فريق تطوير يضم 3 مشاريع: Alpha وBeta وGamma، كل مشروع له موارده الخاصة في S3 وEC2 وDynamoDB.
بدلاً من كتابة 3 سياسات منفصلة لكل فريق (تسرد كل Bucket وكل Instance يدوياً)، تُنشأ سياسة ABAC واحدة:
"Condition": { "StringEquals": { "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}" } }
كل مطور يُوسم بـ Project=Alpha أو Beta أو Gamma — السياسة تسمح له تلقائياً بالوصول فقط للموارد التي تحمل نفس العلامة.
عند انضمام مطور جديد لمشروع Beta: فقط أضف علامة Project=Beta إلى مستخدم IAM الخاص به — صفر تعديل في السياسات.

2️⃣ العلامات (Tags) في AWS

📖 العلامات Tags هي بيانات وصفية (metadata) تُرفق بموارد AWS على شكل أزواج مفتاح-قيمة (Key-Value).
يمكن إرفاق حتى 50 علامة لكل مورد. العلامات ليست مجرد تسميات — إنها العمود الفقري للحوكمة والأتمتة والأمان في السحابة.
📋 استخدامات العلامات في AWS
  • تخصيص التكاليف (Cost Allocation): تصنيف الإنفاق حسب القسم أو المشروع أو البيئة — تقارير فواتير مفصلة حسب العلامات.
  • الأتمتة (Automation): تشغيل إجراءات تلقائية على موارد تحمل علامات محددة — مثلاً إيقاف كل مثيلات "Environment=Dev" في المساء لتوفير التكاليف.
  • التحكم بالوصول (Access Control): أساس ABAC — منح الصلاحيات بناءً على مطابقة العلامات بين المستخدم والمورد.
  • تنظيم الموارد (Resource Organization): تجميع وتصفية الموارد حسب العلامات في وحدة التحكم وأدوات الإدارة.
تخيل مكتبة ضخمة فيها 100,000 كتاب. بدلاً من كتابة قائمة بكل كتاب مسموح لكل قارئ (RBAC)، تُلصق على كل كتاب ملصقاً بلونه (أحمر، أزرق، أخضر) وتعطي كل قارئ بطاقة بنفس اللون (ABAC). القارئ ذو البطاقة الزرقاء يمكنه استعارة أي كتاب أزرق — لا حاجة لتحديث القائمة المركزية عند إضافة كتب زرقاء جديدة أو قرّاء جدد. علامة اللون تفعل كل شيء.

3️⃣ RBAC مقابل ABAC

📖 الفرق الجوهري بين RBAC وABAC هو: RBAC يمنح الصلاحيات بناءً على الدور الوظيفي (Role) للمستخدم، بينما ABAC يمنحها بناءً على السمات (Attributes) المشتركة بين المستخدم والمورد.
RBAC ممتاز للمؤسسات الصغيرة ذات الأدوار المحدودة. ABAC هو الحل الأمثل للمؤسسات الكبيرة ذات النمو السريع في المستخدمين والموارد.
📋 مقارنة تفصيلية
  • RBAC: كل دور له سياسة تسرد الموارد المسموحة تحديداً (مثلاً دور "مهندس Alpha" يصل إلى buckets A,B,C فقط). عند إضافة مورد جديد (bucket D)، يجب تحديث السياسة يدوياً.
  • ABAC: سياسة واحدة تنطبق ديناميكياً على أي مستخدم وأي مورد يحملان نفس العلامة. عند إضافة مورد جديد بعلامة Project=Alpha، كل مستخدمي Alpha يصلون إليه تلقائياً.
  • قابلية التوسع: RBAC يتطلب N×M من التحديثات (N مستخدمين × M موارد). ABAC يتطلب صفر تحديثات — العلامات تتكفل بالربط تلقائياً.
  • قابلية التدقيق: ABAC يسهل تتبع "من وصل إلى ماذا" لأن العلامات تظهر بوضوح في سجلات CloudTrail.
🔑 متى تختار ABAC؟
عندما يكون لديك عدد كبير من المستخدمين والموارد ينمون بسرعة.
عندما تحتاج تحكماً دقيقاً بدون انفجار في عدد السياسات.
عندما تريد أتمتة كاملة للتحكم بالوصول دون تدخل بشري.
استخدم RBAC للأدوار الثابتة المحدودة، وABAC لكل ما سينمو ويتوسع.
خلاصة ABAC:
  • ABAC يمنح الصلاحيات بناءً على مطابقة علامات (Tags) المستخدم مع المورد.
  • العلامات (Tags) هي العمود الفقري للحوكمة والأتمتة والتحكم بالوصول والفوترة.
  • ABAC يتفوق على RBAC في قابلية التوسع — صفر تحديثات في السياسات عند إضافة موارد جديدة.
  • استخدم ABAC للمؤسسات الكبيرة سريعة النمو، وRBAC للأدوار الثابتة.

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

المصطلح (English)الترجمةالمفهوم
ABACالتحكم بالوصول القائم على السماتاستراتيجية تفويض تمنح الصلاحيات بناءً على مطابقة سمات (علامات) المستخدم مع المورد.
RBACالتحكم بالوصول القائم على الأدواراستراتيجية تفويض تمنح الصلاحيات بناءً على الدور الوظيفي مع قائمة موارد ثابتة.
Tagعلامةبيانات وصفية (مفتاح-قيمة) تُرفق بموارد AWS ومستخدمي IAM — أساس ABAC.
PrincipalTagعلامة الكيانمفتاح شرط في سياسة IAM يشير إلى علامات المستخدم أو الدور.
ResourceTagعلامة الموردمفتاح شرط في سياسة IAM يشير إلى علامات مورد AWS المستهدف.

1️⃣ اتحاد الهوية (Identity Federation)

📖 الهوية الموحدة (Federation) تسمح للمستخدمين باستخدام بيانات اعتمادهم الموجودة (مثل Active Directory أو Google Workspace) للوصول إلى AWS دون إنشاء مستخدمي IAM منفصلين.
بدلاً من إدارة هويات منفصلة في كل مكان: هوية واحدة تديرها في مؤسستك، والمستخدمون يصلون إلى AWS من خلالها.
📋 نماذج الهوية الموحدة
  • SAML 2.0: بروتوكول قياسي لتبادل بيانات المصادقة والتفويض بين مزود الهوية (IdP) مثل Active Directory وAWS كمزود خدمة (SP).
  • OpenID Connect (OIDC): طبقة هوية فوق OAuth 2.0 — تستخدمها تطبيقات الويب والهاتف للمصادقة عبر مزودي الهوية الاجتماعية (Google, Facebook, Apple).
  • Custom Identity Broker: وسيط مخصص تبينه بنفسك عندما لا يدعم مزود هويتك SAML — وسيطك يتواصل مع AWS STS للحصول على بيانات اعتماد مؤقتة.
جامعة لديها 50,000 طالب وموظف يستخدمون Microsoft Active Directory.
بدلاً من إنشاء 50,000 مستخدم IAM (كابوس إداري!)، تربط Active Directory بـ AWS عبر SAML.
الطالب يسجل دخوله ببيانات اعتماد الجامعة على بوابة AWS، وSAML يمرر تأكيد الهوية إلى AWS.
AWS STS يصدر بيانات اعتماد مؤقتة (15 دقيقة إلى 12 ساعة) تخول الطالب الوصول لبيئة المعمل.
عندما يتخرج الطالب ويُحذف حسابه في Active Directory، يفقد تلقائياً وصوله إلى AWS — لا حاجة لتحديث IAM يدوياً.
🔑 تدفق وسيط الهوية (Identity Broker) — 4 خطوات: الخطوة 1: المستخدم يسجل دخوله إلى وسيط الهوية (مثلاً تطبيق ويب مخصص) ببيانات اعتماده المؤسسية. الخطوة 2: وسيط الهوية يتحقق من بيانات اعتماد المستخدم مع مزود الهوية (IdP) مثل Active Directory. الخطوة 3: بعد التحقق، وسيط الهوية يستدعي AWS STS للحصول على بيانات اعتماد AWS مؤقتة للمستخدم. الخطوة 4: وسيط الهوية يُرجع بيانات الاعتماد المؤقتة للمستخدم لاستخدامها في استدعاءات AWS API. هذا النموذج مثالي عندما لا يدعم مزود الهوية SAML مباشرة.

2️⃣ AWS IAM Identity Center

📖 AWS IAM Identity Center (سابقاً AWS SSO) هو خدمة مركزية لإدارة وصول المستخدمين إلى حسابات AWS المتعددة وتطبيقات السحابة عبر تسجيل دخول موحد (SSO).
المستخدم يسجل دخوله مرة واحدة وينتقل بين حسابات AWS وتطبيقاته السحابية دون إعادة المصادقة — كل شيء من بوابة واحدة.
📋 ميزات IAM Identity Center
  • يدمج مع مزود الهوية المدمج (Identity Center directory) أو خارجي مثل Active Directory وOkta وAzure AD.
  • مجموعات الأذونات (Permission Sets): قوالب صلاحيات مُعدة مسبقاً تُسند للمستخدمين عبر الحسابات — مثلاً "Database Admin" أو "ReadOnly".
  • تعيين المستخدمين والمجموعات إلى حسابات AWS محددة مع Permission Set مناسب — تحكم مركزي دقيق.
  • يدعم تسجيل الدخول الموحد لتطبيقات AWS (مثل SageMaker وQuickSight) وتطبيقات SAML 2.0 الخارجية.
شركة تضم 500 موظف و12 حساب AWS.
تستخدم IAM Identity Center مرتبطاً بـ Azure AD.
تعرّف Permission Set "NetworkAdmin" (يسمح بإدارة VPC فقط) و"DBAdmin" (يسمح بإدارة RDS وDynamoDB فقط).
عند انضمام مهندس شبكات جديد: يُضاف إلى مجموعة "NetworkEngineers" في Azure AD ← تلقائياً يحصل على وصول NetworkAdmin في حسابات الإنتاج والتطوير عبر Identity Center.
عند نقله إلى فريق قواعد البيانات: يُنقل إلى مجموعة "DBEngineers" ← صلاحياته تتغير تلقائياً دون لمس IAM مباشرة.
خلاصة الهوية الموحدة:
  • الهوية الموحدة تسمح باستخدام بيانات اعتماد موجودة (Active Directory, Google) للوصول إلى AWS.
  • SAML 2.0 للمؤسسات، OIDC للتطبيقات، ووسيط هوية مخصص للحالات الخاصة.
  • IAM Identity Center يوفر تسجيل دخول موحد (SSO) عبر حسابات AWS وتطبيقات السحابة.
  • Permission Sets تمنح صلاحيات محددة لكل مجموعة مستخدمين في كل حساب.

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

المصطلح (English)الترجمةالمفهوم
Federationالهوية الموحدةاستخدام مزود هوية خارجي للوصول إلى AWS.
SAML 2.0SAML 2.0بروتوكول تبادل بيانات المصادقة بين IdP وAWS.
Identity Centerمركز الهويةخدمة SSO لإدارة الوصول المركزي للحسابات والتطبيقات.
Permission Setمجموعة أذوناتقالب صلاحيات في Identity Center يُسند للمستخدمين عبر الحسابات.
Identity Provider (IdP)مزود الهويةنظام خارجي (مثل Active Directory أو Okta) يدير هويات المستخدمين.
AWS SSOالدخول الموحدخدمة تتيح تسجيل دخول واحد للوصول إلى حسابات وتطبيقات متعددة.

1️⃣ Amazon Cognito

📖 Amazon Cognito هو خدمة هوية مُدارة بالكامل لتطبيقات الويب والهاتف — تدير تسجيل المستخدمين وتسجيل الدخول والتحكم بالوصول دون بناء نظام هوية من الصفر.
مثالية للتطبيقات التي تواجه العملاء (B2C) حيث تحتاج ملايين المستخدمين للتسجيل والدخول بأمان.
📋 مكونا Cognito
  • User Pools: دليل مستخدمين كامل — تسجيل، تسجيل دخول، استعادة كلمة المرور، تحقق متعدد العوامل (MFA)، تكامل مع مزودي الهوية الاجتماعية (Google, Facebook, Apple, Amazon).
  • Identity Pools: منح المستخدمين بيانات اعتماد AWS مؤقتة للوصول إلى خدمات AWS مباشرة (مثل S3 أو DynamoDB) — تطبيقك يمنح مستخدميه صلاحيات محددة للوصول إلى موارد AWS.
  • User Pools = المصادقة (من أنت؟)، Identity Pools = التفويض (ماذا يحق لك في AWS؟).
  • يتكامل مع API Gateway وALB لمصادقة طلبات API — لا حاجة لكتابة كود مصادقة مخصص.
تطبيق لياقة بدنية يخدم مليون مستخدم نهائي.
يستخدم Cognito User Pool لإدارة حسابات المستخدمين: تسجيل ببريد إلكتروني أو Google أو Apple.
عند تسجيل الدخول، Cognito يصدر رموز JWT (JSON Web Tokens) — تطبيق الهاتف يمررها مع كل طلب API.
API Gateway يتحقق من صحة JWT عبر Cognito تلقائياً — لا حاجة لخادم مصادقة مخصص.
للصور الشخصية المخزنة في S3: يستخدم Identity Pool لمنح كل مستخدم بيانات اعتماد مؤقتة للوصول إلى مجلده الخاص فقط في S3.
النتيجة: نظام هوية كامل وآمن لمليون مستخدم بدون خادم واحد لإدارة المصادقة.
🔑 Cognito مقابل IAM — متى تستخدم ماذا؟
استخدم IAM للمستخدمين الداخليين: الموظفون، المطورون، المدراء — أشخاص يحتاجون الوصول لوحدة تحكم AWS وخدماتها.
استخدم Cognito للمستخدمين الخارجيين: عملاء تطبيقك — أشخاص يحتاجون فقط الوصول لتطبيقك وليس لوحدة تحكم AWS.
الخطأ الشائع: إنشاء مستخدمي IAM لعملاء التطبيق — هذا خطر أمني كبير ومخالف لأفضل الممارسات.
خلاصة Amazon Cognito:
  • User Pools: دليل مستخدمين كامل للتسجيل والدخول والمصادقة متعددة العوامل (MFA).
  • Identity Pools: منح المستخدمين بيانات اعتماد AWS مؤقتة للوصول إلى خدمات AWS.
  • يتكامل مع API Gateway وALB لمصادقة طلبات API بدون كود مخصص.
  • استخدم Cognito للمستخدمين الخارجيين (العملاء) وIAM للمستخدمين الداخليين (الموظفين).

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

المصطلح (English)الترجمةالمفهوم
User Poolمجمع المستخدميندليل مستخدمين كامل لإدارة التسجيل والدخول واستعادة كلمة المرور والتحقق المتعدد.
Identity Poolمجمع الهويةيمنح المستخدمين بيانات اعتماد AWS مؤقتة للوصول المباشر إلى خدمات AWS.
JWTرمز الويب JSONرمز آمن تصدره Cognito بعد المصادقة يُستخدم للتحقق من هوية المستخدم في طلبات API.
OIDCطبقة الهوية المفتوحةبروتوكول هوية فوق OAuth 2.0 للمصادقة عبر مزودي الهوية الاجتماعية.
Cognitoأمازون كوجنيتوخدمة هوية مُدارة لتطبيقات الويب والهاتف — تسجيل ودخول وتحكم بالوصول.

1️⃣ Why Encrypt Data at Rest? — لماذا نشفر البيانات في السكون؟

📖 تشفير البيانات في السكون يحمي سرية بياناتك حتى لو تمكن مهاجم من الوصول الفعلي إلى وسيط التخزين.
مبدأ CIA Triad (السرية - Confidentiality، السلامة - Integrity، التوفر - Availability) هو حجر الزاوية في أمن المعلومات، والتشفير يحقق ركيزة السرية حتى عند اختراق التخزين.
📋 ماذا يحمي التشفير في السكون؟
  • السرية (Confidentiality): حتى لو سُرق القرص الصلب أو اخترق S3 bucket، البيانات غير قابلة للقراءة بدون المفتاح.
  • السلامة (Integrity): آليات التشفير الحديثة تكتشف أي عبث بالبيانات — لا يمكن تعديل الملف المشفر وإعادة حفظه دون اكتشاف التغيير.
  • الامتثال (Compliance): معايير مثل PCI DSS وHIPAA وGDPR تفرض تشفير البيانات الحساسة في السكون كمتطلب إلزامي.
  • الدفاع متعدد الطبقات: جدران الحماية وIAM قد تُخترق — التشفير هو خط الدفاع الأخير حتى لو وصل المهاجم للبيانات.
🔑 تذكر: تشفير البيانات في السكون لا يحمي من هجمات التطبيق نفسه (SQL Injection مثلاً) — إنه يحمي البيانات المخزنة فقط. كل طبقة أمان لها دور مختلف.

2️⃣ التشفير المتماثل (Symmetric Encryption)

📖 في التشفير المتماثل، يُستخدم نفس المفتاح للتشفير وفك التشفير — سريع وفعّال للبيانات كبيرة الحجم.
مثل قفل البيت: نفس المفتاح يغلق الباب ويفتحه. الطرفان (المرسل والمستقبل) يجب أن يمتلكا نسخة من نفس المفتاح السري. الخوارزمية الأكثر استخداماً في AWS هي AES-256.
📋 خصائص التشفير المتماثل
  • السرعة: أسرع بكثير من التشفير غير المتماثل — مثالي لتشفير كميات كبيرة من البيانات.
  • التحدي الرئيسي: كيف تشارك المفتاح السري بأمان مع الطرف الآخر؟ هنا يأتي دور التشفير غير المتماثل.
  • أفضل الممارسات: تدوير المفاتيح بشكل متكرر — لا تستخدم نفس المفتاح لسنوات.

3️⃣ التشفير غير المتماثل (Asymmetric Encryption)

📖 التشفير غير المتماثل يستخدم زوجاً من المفاتيح: مفتاح عام (Public Key) للتشفير ومفتاح خاص (Private Key) لفك التشفير — لا يمكن اشتقاق أحدهما من الآخر.
مثل صندوق بريد: أي شخص يمكنه إسقاط رسالة (المفتاح العام)، لكن فقط من يملك المفتاح الفعلي يمكنه فتح الصندوق (المفتاح الخاص).
📋 خصائص التشفير غير المتماثل
  • أبطأ من المتماثل: العمليات الحسابية معقدة — غير مناسب للبيانات الكبيرة مباشرة.
  • عدم الإنكار (Non-Repudiation): المفتاح الخاص يثبت هوية الموقع الإلكتروني — لا يمكنه إنكار أنه أرسل البيانات.
  • الاستخدام في SSL/TLS Handshake: أثناء بدء اتصال HTTPS، يُستخدم لتبادل مفتاح متماثل مؤقت للجلسة بأمان.

4️⃣ تشفير المغلف (Envelope Encryption)

📖 تشفير المغلف يجمع بين التشفير المتماثل وغير المتماثل: سرعة المتماثل في تشفير البيانات + أمان غير المتماثل في حماية المفتاح.
هذه هي الاستراتيجية التي يستخدمها AWS KMS بالضبط لتشفير بياناتك.
📋 كيف يعمل تشفير المغلف — خطوة بخطوة
  • الخطوة 1: KMS يولّد مفتاح بيانات (Data Key) — مفتاح متماثل مؤقت.
  • الخطوة 2: تُشفر بياناتك الكبيرة بهذا المفتاح المتماثل (سريع).
  • الخطوة 3: مفتاح البيانات يُشفَر بدوره بالمفتاح الرئيسي (CMK) في KMS.
  • الخطوة 4: يُخزن مفتاح البيانات المشفر مع البيانات نفسها. المفتاح الرئيسي CMK لا يغادر KMS أبداً.
تدفق تشفير SSE-KMS بالتفصيل عند رفع كائن إلى S3:
① التطبيق يرسل الكائن إلى S3 مع طلب استخدام SSE-KMS.
② S3 يتصل بـ KMS: "أعطني مفتاح بيانات لهذا الكائن".
③ KMS يولّد مفتاح بيانات بنسختين: نسخة نصية (Plaintext) ونسخة مشفرة بـ CMK.
④ KMS يعيد النسختين إلى S3.
⑤ S3 يشفر الكائن بالنسخة النصية من مفتاح البيانات، ويخزن الكائن المشفر + مفتاح البيانات المشفر معاً.
⑥ S3 يمسح النسخة النصية من الذاكرة فوراً — لا تبقى أي نسخة غير مشفرة.
🔑 تشفير المغلف (Envelope Encryption) مع KMS: هذا هو نمط التشفير الأساسي في AWS. بدلاً من تشفير بياناتك الضخمة مباشرة بالمفتاح الرئيسي (CMK) — وهو بطيء ومحدود الحجم — KMS يولّد Data Key (مفتاح بيانات متماثل سريع) يُشفر بياناتك، ثم يُشفر مفتاح البيانات نفسه بالـ CMK ويُخزن مع البيانات. المفتاح الرئيسي لا يغادر KMS أبداً. هذا يجمع بين سرعة التشفير المتماثل وأمان التشفير غير المتماثل في آن واحد.

5️⃣ التشفير من جانب العميل مقابل التشفير من جانب الخادم (CSE vs SSE)

📖 CSE (Client-Side Encryption) و SSE (Server-Side Encryption) هما استراتيجيتان لتشفير البيانات قبل أو عند تخزينها في AWS — يمكن استخدامهما معاً لمزيد من الأمان.
CSE: أنت تشفر قبل الإرسال إلى AWS (أنت تدير المفاتيح). SSE: AWS تشفر بعد الاستلام (شفاف للمستخدم).
📋 مقارنة CSE مقابل SSE
  • CSE (التشفير من جانب العميل): البيانات تُشفر في جهازك قبل إرسالها إلى AWS. AWS لا ترى البيانات الأصلية أبداً. أنت مسؤول عن إدارة المفاتيح بالكامل. مثالية للبيانات فائقة الحساسية.
  • SSE (التشفير من جانب الخادم): AWS تستقبل البيانات غير مشفرة ثم تشفرها قبل تخزينها. العملية شفافة — لا تحتاج لتعديل تطبيقك. المفاتيح تُدار بواسطة AWS (SSE-S3) أو بواسطتك عبر KMS (SSE-KMS).
  • الاستخدام المشترك: يمكنك تشفير البيانات بـ CSE قبل الإرسال، ثم AWS تشفرها مرة أخرى بـ SSE — طبقتان من التشفير بمفاتيح مختلفة.
خلاصة نظرية التشفير:
  • التشفير في السكون يحقق السرية (CIA Triad) حتى لو اخترق التخزين.
  • التشفير المتماثل (AES-256) سريع للبيانات الكبيرة، وغير المتماثل يوفر عدم الإنكار لتبادل المفاتيح.
  • تشفير المغلف (Envelope Encryption) يجمع سرعة المتماثل وأمان غير المتماثل — تستخدمه KMS.
  • CSE تشفير من جانب العميل، SSE تشفير من جانب الخادم — يمكن استخدامهما معاً لمزيد من الأمان.

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

المصطلح (English)الترجمةالمفهوم
CIA Triadثالوث CIAالمبادئ الثلاثة لأمن المعلومات: السرية (Confidentiality)، السلامة (Integrity)، التوفر (Availability).
Symmetric Encryptionالتشفير المتماثلتشفير بنفس المفتاح للتشفير وفك التشفير — سريع ومناسب للبيانات الكبيرة.
Asymmetric Encryptionالتشفير غير المتماثلتشفير بمفتاح عام للتشفير ومفتاح خاص لفك التشفير — يوفر عدم الإنكار.
Envelope Encryptionتشفير المغلفتشفير البيانات بمفتاح متماثل (Data Key) يُشفَر بدوره بمفتاح رئيسي (CMK).
CMKالمفتاح الرئيسي للعميلالمفتاح الرئيسي في KMS الذي يُستخدم لتشفير/فك تشفير مفاتيح البيانات.
CSEالتشفير من جانب العميلتشفير البيانات قبل إرسالها إلى AWS — العميل يدير المفاتيح.
SSE-KMSالتشفير من جانب الخادم بـ KMSAWS تشفر البيانات بعد استلامها باستخدام مفاتيح KMS التي تتحكم بها.

1️⃣ خدمة إدارة المفاتيح AWS KMS (Key Management Service)

📖 AWS KMS هي خدمة مُدارة لإنشاء مفاتيح التشفير والتحكم فيها — تشفر بياناتك في معظم خدمات AWS بنقرة واحدة دون الحاجة لخبرة تشفير متقدمة.
المفاتيح تُنشأ وتُخزن في وحدات أمان عتادية (HSM) ولا تغادر AWS أبداً — لا يمكنك تصدير المفتاح، أنت تتحكم بمن يمكنه استخدامه فقط.
📋 مكونات KMS الأساسية
  • مفاتيح KMS (KMS Keys): المفاتيح الأساسية التي تنشئها — يمكن أن تكون مدارة من AWS (aws/service-key) أو مدارة من العميل (customer-managed). كل مفتاح له سياسة تحدد من يمكنه استخدامه ولأي غرض.
  • تشفير المغلف (Envelope Encryption): لا تشفر البيانات مباشرة بالمفتاح الأساسي — KMS يولّد مفتاح بيانات (data key)، تشفر به بياناتك، ثم تشفر مفتاح البيانات بالمفتاح الأساسي وتخزنه مع البيانات.
  • تدوير المفاتيح (Key Rotation): AWS تدير المفاتيح تلقائياً بتدوير سنوي — أو تدويره يدوياً حسب الحاجة.
  • يتكامل مع أكثر من 50 خدمة AWS: S3, EBS, RDS, DynamoDB, Lambda, SQS, SNS, CloudTrail, وغيرها.
تطبيق مالي يشفر بياناته الحساسة بتصميم متعدد الطبقات.
الطبقة 1: S3 تُهيأ لاستخدام تشفير SSE-KMS — كل ملف يُشفر تلقائياً عند رفعه بمفتاح KMS خاص بالتطبيق.
الطبقة 2: RDS تُهيأ بالتشفير عبر KMS — قاعدة البيانات كاملة مشفرة في السكون.
الطبقة 3: EBS لوحدات تخزين EC2 مشفرة بمفتاح KMS منفصل — حتى النسخ الاحتياطية واللقطات مشفرة تلقائياً.
كل طبقة تستخدم مفتاح KMS مستقل بسياسة وصول مختلفة — لو اختُرق مفتاح S3، لا يمكن استخدامه لفك تشفير RDS أو EBS. أمان متعدد الطبقات والمفاتيح.

2️⃣ AWS Secrets Manager

📖 AWS Secrets Manager هي خدمة مُدارة لتخزين الأسرار (كلمات المرور، مفاتيح API، بيانات اعتماد قواعد البيانات) وتدويرها تلقائياً.
بدلاً من تخزين كلمات المرور في ملفات الكود أو متغيرات البيئة (خطر أمني كبير)، تخزنها في Secrets Manager وتسترجعها وقت الحاجة فقط.
📋 ميزات Secrets Manager
  • التدوير التلقائي: يدور كلمات مرور RDS وDocumentDB وRedshift تلقائياً حسب جدول (يومي، أسبوعي، شهري) — بدون أي تعطيل للتطبيق.
  • التشفير في السكون: كل سر يُشفر بمفتاح KMS خاص — حتى موظفي AWS لا يمكنهم قراءته.
  • التحكم الدقيق بالوصول: سياسات IEM تحدد من يمكنه قراءة أي سر — تطبيقك يحصل على دوره الخاص الذي يسمح له بقراءة أسراره فقط.
  • التكامل مع AWS SDK: استرجع الأسرار بكود بسيط — SecretsManager.getSecretValue('prod/db/password').
تطبيق متعدد البيئات (تطوير، اختبار، إنتاج) يدير بيانات اعتماد قواعد البيانات بأمان.
كل بيئة لها سر منفصل في Secrets Manager: dev/db/credentials, test/db/credentials, prod/db/credentials.
لكل بيئة دور IAM خاص يسمح بقراءة سرها فقط — دور الإنتاج لا يمكنه رؤية أسرار التطوير والعكس.
كلمة مرور قاعدة الإنتاج تُدار تلقائياً كل 7 أيام — Secrets Manager ينشئ كلمة جديدة في RDS ويحدث السر ويخطر التطبيق.
لا كلمات مرور في الكود، لا ملفات .env، ولا خطر تسريب بيانات اعتماد الإنتاج.

3️⃣ AWS Systems Manager Parameter Store

📖 Parameter Store هي خدمة مجانية لتخزين قيم الإعدادات والأسرار البسيطة — مثالية لبيانات التهيئة غير الحساسة أو عندما لا تحتاج تدويراً تلقائياً.
استخدم Parameter Store للقيم العادية (مثل URLs الإعدادات) وSecrets Manager للأسرار الحساسة التي تحتاج تدويراً.
📋 Parameter Store مقابل Secrets Manager
  • Parameter Store: مجاني (حتى 10,000 بارامتر قياسي)، يدعم التشفير عبر KMS (للـ SecureString)، لا يدعم التدوير التلقائي. مثالي للإعدادات العامة.
  • Secrets Manager: مدفوع (~0.40$ لكل سر شهرياً + رسوم API)، تشفير إجباري، تدوير تلقائي، تكامل مع RDS. مثالي لكلمات المرور ومفاتيح API.
  • كلاهما يتكامل مع AWS SDK وCloudFormation.

4️⃣ AWS Certificate Manager (ACM)

📖 AWS Certificate Manager يوفر شهادات SSL/TLS مجانية لخدمات AWS مع تجديد تلقائي — لا حاجة لشراء أو تجديد أو تثبيت شهادات يدوياً.
الشهادات تصدرها AWS وتُجدد تلقائياً قبل انتهائها — لن تنسى تجديد شهادة ويتوقف موقعك مرة أخرى.
📋 خصائص ACM
  • شهادات مجانية بالكامل — تدفع فقط مقابل موارد AWS التي تستخدمها (ALB, CloudFront, API Gateway).
  • تجديد تلقائي قبل 60 يوماً من انتهاء الشهادة — بدون أي تدخل أو توقف.
  • يتكامل مع: Elastic Load Balancing (ALB/NLB)، CloudFront، API Gateway.
  • يدعم أسماء نطاقات فردية (*.example.com) أو wildcard أو متعددة.
  • لا يمكن تصدير المفاتيح الخاصة — الشهادة مربوطة بخدمات AWS فقط (للأمان).
موقع تجارة إلكترونية على CloudFront + ALB.
يطلب شهادة من ACM لنطاق *.myshop.com — مجانية بالكامل.
يربطها بـ CloudFront (للواجهة الأمامية) وALB (للـ API) — كل حركة HTTPS تُشفر تلقائياً.
بعد 13 شهراً، تنتهي الشهادة تلقائياً وتُستبدل بأخرى جديدة قبل أسبوعين من الانتهاء.
مدير الموقع لا يعرف حتى أن التجديد حدث — صفر توقف، صفر تكلفة، صفر جهد.
خلاصة إدارة المفاتيح والأسرار:
  • AWS KMS خدمة مُدارة لإنشاء مفاتيح التشفير والتحكم فيها — تتكامل مع 50+ خدمة AWS.
  • Secrets Manager تخزن وتدور كلمات المرور ومفاتيح API تلقائياً.
  • Parameter Store مجاني للإعدادات غير الحساسة، Secrets Manager للأسرار التي تحتاج تدويراً.
  • ACM يوفر شهادات SSL/TLS مجانية مع تجديد تلقائي لخدمات AWS.

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

المصطلح (English)الترجمةالمفهوم
KMS Keyمفتاح KMSمفتاح تشفير رئيسي يُدار في AWS KMS.
Envelope Encryptionتشفير المغلفتشفير البيانات بمفتاح بيانات يُشفَر بدوره بالمفتاح الرئيسي.
Secrets Managerمدير الأسرارتخزين وتدوير تلقائي لكلمات المرور ومفاتيح API.
ACMمدير الشهاداتإصدار شهادات SSL/TLS مجانية مع تجديد تلقائي.
CloudHSMوحدة أمان عتاديةجهاز HSM مخصص للتحكم الكامل في مفاتيح التشفير.

1️⃣ AWS CloudHSM

📖 AWS CloudHSM يوفر وحدات أمان عتادية (Hardware Security Modules) مخصصة لك فقط في السحابة — تحكم كامل في المفاتيح وامتثال لأعلى المعايير.
على عكس KMS (متعددة المستأجرين)، CloudHSM يمنحك HSM مخصصاً بالكامل — أنت الوحيد الذي يستخدمه، وأنت تتحكم في كل المفاتيح.
📋 KMS مقابل CloudHSM
  • KMS: مُدارة بالكامل، متعددة المستأجرين، سهلة الاستخدام، تتكامل مع معظم خدمات AWS. مثالية لمعظم حالات الاستخدام.
  • CloudHSM: HSM مخصص لك فقط، تحكم كامل (بما في ذلك تصدير المفاتيح إذا أردت)، معتمدة FIPS 140-2 Level 3. مثالية للمتطلبات التنظيمية الصارمة (PCI DSS, HIPAA, FedRAMP).
  • CloudHSM أغلى (~1.45$/ساعة للجهاز) ويتطلب خبرة في إدارة HSMs.
  • استخدم KMS إلا إذا كان لديك متطلب امتثال يفرض HSM مخصصاً.

2️⃣ Well-Architected on Security — تطبيق Well-Architected على الأمان

📖 ركيزة الأمان في Well-Architected تقدم سبعة مبادئ تصميم تضمن حماية بياناتك ومستخدميك وتطبيقاتك.
هذه المبادئ تشكل الأساس الذي تبنى عليه استراتيجية الأمان الشاملة.
📋 مبادئ التصميم السبعة لركيزة الأمان
  • الهوية أساس كل شيء: استخدم IAM وCognito وIdentity Center — الهوية هي المحور الذي تدور حوله كل قرارات الوصول.
  • إمكانية التتبع: فعّل CloudTrail في كل الحسابات، وسجّل كل حدث — لا ثقة عمياء، كل فعل يجب أن يكون قابلاً للتدقيق.
  • الأمان في كل الطبقات: لا تعتمد على طبقة واحدة — شبكة + هوية + تشفير + تدقيق = أمان متعدد الطبقات.
  • أتمتة الأمان: أتمتة تدوير الأسرار (Secrets Manager)، أتمتة اكتشاف البيانات الحساسة (Macie)، أتمتة الاستجابة للحوادث (Security Hub + Lambda).
  • حماية البيانات في السكون والنقل: تشفير كل شيء بـ KMS، TLS 1.2+ لكل الاتصالات، ACM للشهادات.
  • الابتعاد عن البيانات: استخدم أدوات مثل Macie لاكتشاف البيانات الحساسة وتقليل تخزينها — ما لا تخزنه لا يمكن سرقته.
  • الاستعداد للأحداث الأمنية: خطة استجابة للحوادث، محاكاة هجمات، نسخ احتياطي مشفر ومنفصل عن الحساب الأساسي.
مراجعة أمنية شاملة لتطبيق SaaS.
المكتشف 1: CloudTrail غير مفعل في 3 حسابات — يفعلها فوراً ويوجه السجلات إلى S3 مركزي (ركيزة التتبع).
المكتشف 2: كلمة مرور قاعدة البيانات في متغير بيئة داخل كود Lambda — ينقلها إلى Secrets Manager مع تدوير تلقائي (ركيزة أتمتة الأمان).
المكتشف 3: S3 bucket بدون تشفير افتراضي — يفعل SSE-KMS مع مفتاح مخصص (ركيزة حماية البيانات).
المكتشف 4: لا توجد خطة استجابة للحوادث — يوثق خطة تشمل عزل الحساب المخترق، استعادة البيانات من نسخة احتياطية، وتحليل السبب الجذري (ركيزة الاستعداد).
النتيجة: تحسين وضع الأمان من "مقبول" إلى "ممتاز" خلال أسبوعين.
خلاصة CloudHSM والامتثال:
  • CloudHSM يوفر HSM مخصص للتحكم الكامل في المفاتيح ومتطلبات الامتثال الصارمة (FIPS 140-2 Level 3).
  • استخدم KMS لمعظم الحالات، وCloudHSM للمتطلبات التنظيمية (PCI DSS, HIPAA).
  • ركيزة الأمان في Well-Architected تقدم 7 مبادئ تصميم لبناء استراتيجية أمان شاملة.
  • الأمان ليس منتجاً — إنه ممارسة مستمرة وثقافة تنظيمية تبدأ من التصميم.

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

المصطلح (English)الترجمةالمفهوم
AWS Organizationsمؤسسات AWSخدمة لإدارة حسابات AWS المتعددة مركزياً مع سياسات حوكمة وفوترة موحدة.
SCPسياسة التحكم في الخدمةسياسة تحدد الحد الأقصى للصلاحيات في حساب AWS — لا يمكن تجاوزها.
Permission Boundaryحد الأذوناتسياسة IAM تحدد السقف الأعلى لصلاحيات مستخدم أو دور محدد.
Federationالهوية الموحدةاستخدام مزود هوية خارجي (مثل Active Directory) للوصول إلى AWS.
SAML 2.0لغة ترميز تأكيد الأمانبروتوكول قياسي لتبادل بيانات المصادقة بين مزود الهوية ومزود الخدمة.
IAM Identity Centerمركز هوية IAMخدمة تسجيل دخول موحد (SSO) لإدارة الوصول إلى حسابات AWS وتطبيقات السحابة.
Amazon Cognitoأمازون كوجنيتوخدمة هوية مُدارة لتطبيقات الويب والهاتف — تسجيل ودخول وتحكم بالوصول.
AWS KMSخدمة إدارة المفاتيحخدمة مُدارة لإنشاء مفاتيح التشفير والتحكم فيها.
AWS Secrets Managerمدير الأسرارخدمة لتخزين الأسرار (كلمات مرور، مفاتيح API) وتدويرها تلقائياً.
ACMمدير الشهاداتخدمة لإصدار شهادات SSL/TLS مجانية مع تجديد تلقائي.
CloudHSMوحدة الأمان العتادية السحابيةجهاز HSM مخصص لك في السحابة لتحكم كامل في مفاتيح التشفير.

1️⃣ الكشف والاستجابة (Detection & Response)

📖 AWS تقدم ثلاث خدمات متكاملة لاكتشاف التهديدات الأمنية وتحليلها والاستجابة لها — من التحقيق العميق إلى التقييم الآلي ثم لوحة القيادة المركزية.
كل خدمة تؤدي دوراً مختلفاً في دورة حياة الأمان: Detective للتحقيق، Inspector للتقييم، Security Hub للتجميع والإدارة.
📋 خدمات الكشف والاستجابة
  • Amazon Detective: يحلل ويصور بيانات الأمان للتحقيق في المشكلات الأمنية. يستخدم التعلم الآلي والتحليل الإحصائي ونظرية الرسوم البيانية (Graph Theory) لبناء نموذج موحد لسلوك الموارد. مثالي عند اكتشاف حادثة أمنية وتحتاج فهم "ماذا حدث بالضبط؟".
  • Amazon Inspector: خدمة تقييم أمني آلي تفحص أحمال العمل بحثاً عن ثغرات برمجية وانكشاف غير مقصود للشبكة. يراقب باستمرار (Continuous Monitoring) ويكتشف الثغرات في الحزم (packages) ويثبتها مع درجة خطورتها.
  • AWS Security Hub: لوحة قيادة مركزية للتنبيهات الأمنية وحالة الامتثال. يجمع النتائج من خدمات متعددة (GuardDuty, Inspector, Macie, Firewall Manager) في عرض موحد. يوفر فحوصات امتثال آلية ضد معايير مثل CIS AWS Foundations وPCI DSS.
بنك يستخدم خدمات الكشف والاستجابة معاً.
GuardDuty يكتشف اتصالاً مريباً من مثيل EC2 إلى عنوان IP معروف بالهجمات ← ينشئ finding تلقائياً.
Security Hub يستلم الـ finding ويعرضه في لوحة القيادة مع درجة الخطورة (Critical).
فريق الأمان يفتح Detective للتحقيق: من أي مستخدم IAM أُطلقت الجلسة؟ ما هي الموارد التي لمسها؟ الرسم البياني للسلوك يظهر التسلسل الزمني كاملاً.
في نفس الوقت، Inspector يراقب باستمرار نفس المثيل — اكتشف أن حزمة OpenSSL قديمة ومعرضة للثغرات ويوصي بالترقية.

2️⃣ حماية الشبكة والتطبيقات (Network & Application Protection)

📖 حماية تطبيقات الويب من الهجمات الشائعة والتصدي لهجمات الحرمان من الخدمة (DDoS) هما خط الدفاع الأول عن تطبيقاتك.
AWS Shield يحمي من هجمات الحجم الكبير، وAWS WAF يحمي من الهجمات الذكية على مستوى التطبيق.
📋 خدمات حماية الشبكة والتطبيقات
  • AWS WAF (Web Application Firewall): جدار حماية لتطبيقات الويب يحمي من هجمات SQL Injection وCross-Site Scripting (XSS). يمكنك تعريف قواعد أمان ويب مخصصة. يتكامل مع CloudFront وALB وAPI Gateway. يمكنك حظر IPs محددة، أو تقييد الطلبات حسب الدولة، أو فلترة أنماط معينة.
  • AWS Shield: خدمة حماية مُدارة ضد هجمات DDoS. Shield Standard مجاني وتلقائي لكل عملاء AWS. Shield Advanced حماية معززة مع حماية التكاليف (Cost Protection) ودعم 24/7.
متجر إلكتروني أثناء تخفيضات الجمعة البيضاء.
WAF مهيأ بقاعدة تحد من الطلبات من نفس الـ IP إلى 100 طلب في 5 دقائق — يمنع محاولات تخمين كلمات المرور.
WAF مهيأ بقاعدة Managed Rule من AWS: يحظر أنماط SQL Injection وXSS تلقائياً.
أثناء التخفيضات، تبدأ هجمة DDoS — Shield Advanced يكتشف الهجمة ويبدأ في تصفية الحركة الضارة. التكلفة الحقيقية للهجمة على CloudFront مغطاة بالكامل من Shield Advanced.

3️⃣ حماية البيانات (Data Protection)

📖 حماية البيانات لا تقتصر على التشفير فقط — بل أيضاً على اكتشاف البيانات الحساسة وتصنيفها ومراقبتها.
قد تخزن بيانات حساسة في S3 دون أن تدري — Amazon Macie يكتشفها لك وينبهك قبل أن تصبح ثغرة امتثال.
📋 خدمة Amazon Macie
  • Amazon Macie: يستخدم التعلم الآلي لاكتشاف وتصنيف وحماية البيانات الحساسة في S3. يتعرف على PII (معلومات التعريف الشخصية)، PHI (المعلومات الصحية المحمية)، والبيانات المالية. يكتشف Buckets ذات الأذونات العامة (Public). يساعد في الامتثال لـ GDPR وHIPAA وPCI DSS.
شركة تأمين صحي تستخدم S3 لتخزين ملايين الملفات.
بعد تشغيل Macie، يكتشف أن 23 bucket تحتوي على أرقام تأمين صحي (PHI) — بعضها مفتوح للأقسام الداخلية بدون حاجة.
Macie يُصنف الـ buckets حسب مستوى الخطورة. يكتشف أيضاً أن 3 buckets عامة (Public Read) بالخطأ — يغلقها فوراً.
التقرير الأسبوعي من Macie يُرسل لفريق الامتثال: انخفضت البيانات الحساسة المكشوفة من 450GB إلى 80GB خلال شهر.

4️⃣ الامتثال والحوكمة (Compliance & Governance)

📖 AWS تقدم أدوات متكاملة للامتثال والتدقيق والحوكمة — من تقارير الامتثال الجاهزة إلى التدقيق المستمر، وحتى إعداد بيئة متعددة الحسابات مؤمنة تلقائياً.
الحوكمة ليست مجرد فحص سنوي — إنها مراقبة مستمرة وإعداد بيئة سليمة من البداية.
📋 خدمات الامتثال والحوكمة
  • AWS Artifact: وصول فوري إلى تقارير امتثال AWS واتفاقيات الأمان. حمّل تقارير SOC 1/2/3، PCI DSS، ISO 27001 مباشرة من وحدة التحكم. مثالي للمدققين الخارجيين.
  • AWS Audit Manager: يدقق حسابات AWS باستمرار لتبسيط تقييم المخاطر والامتثال. يجمع الأدلة تلقائياً ويبني تقارير جاهزة للمدققين.
  • AWS Control Tower: يسهّل إعداد وحوكمة بيئة AWS متعددة الحسابات وآمنة. ينشئ تلقائياً Landing Zone جيدة التصميم بناءً على أفضل الممارسات. يفرض حواجز حماية (Guardrails) للأمان والعمليات والامتثال — Guardrails وقائية (تمنع المخالفة) أو كشفية (تنبه عند المخالفة).
تخيل أنك تبني حياً سكنياً كاملاً (بيئة AWS متعددة الحسابات). Control Tower هو المخطط العمراني الذي يجهز البنية التحتية (شوارع، صرف، كهرباء) وفق أفضل المعايير قبل بناء أول منزل. Audit Manager هو المفتش البلدي الذي يتأكد أن كل منزل ملتزم بقوانين البناء بشكل مستمر. Artifact هو ملف شهادات الامتثال الجاهزة التي تقدمها للجهات الرقابية عند الطلب.
خلاصة خدمات الأمان المتقدمة:
  • Amazon Detective يحقق في الحوادث الأمنية، Inspector يفحص الثغرات، وSecurity Hub يوحد التنبيهات.
  • AWS WAF يحمي تطبيقات الويب من SQL Injection وXSS، وShield يحمي من DDoS.
  • Amazon Macie يكتشف ويصنف البيانات الحساسة في S3 باستخدام التعلم الآلي.
  • Artifact للامتثال، Audit Manager للتدقيق المستمر، Control Tower لإعداد بيئة متعددة الحسابات بحوكمة كاملة.

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

المصطلح (English)الترجمةالمفهوم
Amazon Detectiveأمازون ديتكتفخدمة تحليل وتحقيق أمني باستخدام التعلم الآلي ونظرية الرسوم البيانية.
Amazon Inspectorأمازون إنسبكتورخدمة تقييم أمني آلي تفحص أحمال العمل بحثاً عن ثغرات برمجية وانكشاف شبكي.
AWS Security Hubمركز الأمانلوحة قيادة مركزية للتجميع والتنبيهات الأمنية وفحوصات الامتثال الآلية.
AWS WAFجدار حماية تطبيقات الويبيحمي تطبيقات الويب من SQL Injection وXSS والهجمات الشائعة بقواعد قابلة للتخصيص.
AWS Shieldدرع AWSحماية مُدارة ضد هجمات DDoS — Standard مجاني، Advanced بتكلفة وحماية معززة.
Amazon Macieأمازون ميسييكتشف ويصنف البيانات الحساسة (PII, PHI) في S3 باستخدام التعلم الآلي.
AWS Control Towerبرج التحكمإعداد وحوكمة بيئة AWS متعددة الحسابات بآلية Landing Zone وحواجز Guardrails.

🚀 الخاتمة

في هذه الوحدة تعلمنا أن الأمان ليس مجرد طبقة إضافية — إنه النسيج الذي يجب أن يحيط بكل مكونات بنيتك السحابية.
استكشفنا AWS Organizations لإدارة الحسابات المتعددة مركزياً مع سياسات SCP التي تفرض حدوداً عليا للصلاحيات لا يمكن تجاوزها.
تعمقنا في IAM المتقدم: شروط Condition للتحكم الدقيق بالسياق (IP، وقت، MFA، Tags)، وحدود الأذونات Permission Boundaries كسقف إضافي للصلاحيات، والفرق الحاسم بين الأدوار (للتطبيقات) والمستخدمين (للأشخاص فقط).
تعلمنا الهوية الموحدة Federation عبر SAML 2.0 لتجنب إنشاء مستخدمي IAM لكل موظف، وIAM Identity Center لإدارة مركزية للوصول عبر الحسابات، وAmazon Cognito لإدارة هوية ملايين العملاء النهائيين.
تعمقنا في التشفير وإدارة المفاتيح: AWS KMS لتشفير كل مواردك بنقرة واحدة، وSecrets Manager لتخزين وتدوير الأسرار تلقائياً، وACM للشهادات المجانية، وCloudHSM للمتطلبات التنظيمية الصارمة.
وأخيراً، طبقنا مبادئ ركيزة الأمان السبعة من Well-Architected: الهوية أساس كل شيء، التتبع الدائم، الأمان متعدد الطبقات، أتمتة الأمان، حماية البيانات، تقليل البيانات، والاستعداد للحوادث.
تذكر: الأمان ليس منتجاً تشتريه — إنه ممارسة مستمرة وثقافة تنظيمية تبدأ من التصميم ولا تنتهي أبداً.

تعليقات



حجم الخط
+
16
-
تباعد السطور
+
2
-