إدارة الهوية والوصول في السحابة

دليل التعلم: هندسة الـ prompts تحل "كيفية التعبير بوضوح"، إدارة صلاحيات حسابات السحابة تحل "من يمكنه فعل ماذا". يركز هذا الفصل على سؤال واحد: في عالم السحابة، كيف تفوض بسهولة دون تسليم المفاتيح لمن لا يستحقها؟

قبل البدء، يُنصح بمراجعة "لبنتين أساسيتين":

ما هو Token: يمكنك قراءة قسم "التجزئة وToken" في مقدمة في النماذج اللغوية الكبيرة.
ما هو Prompt: إذا لم تكن معتاداً على بنية System / User / Assistant، يمكنك الاطلاع على هندسة الـ prompts.

0. مقدمة: لماذا "نخطو في الألغام" بمجرد دخول السحابة؟

🔐IAM vs RAM ComparisonPermission services across cloud providers

AWS IAM

👤User management

👥User groups

🎭Role assumption

📋Permission policies

🔗Identity federation

🔑Access keys

User management

AWS IAM

IAM User supports programmatic and console access

Alibaba Cloud RAM

RAM user has similar capabilities and supports sub-account sign-in

Alibaba Cloud RAM

👤User management

👥User groups

🎭Role assumption

📋Permission policies

🔗Identity federation

🔑Access keys

💡Core idea:IAM and RAM share the same core concepts. Most differences are terminology and implementation details.

كثير من الناس يواجهون مواقف مشابهة عند بدء استخدام الخدمات السحابية:

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

حدسياً، قد نعتقد: "هؤلاء الموظفون لا يملكون وعياً أمنياً كافياً".

لكن في معظم الأحيان، المشكلة ليست في الأشخاص، بل في عدم وجود نظام صحيح لإدارة الصلاحيات.

Problem

Context is hard to keep consistent：As conversations grow, earlier and later meaning can drift apart.
Key facts are easy to lose：Information given early can be hard to reference accurately later.
Call cost keeps rising：Every round has to process a large amount of history again.

Likely causes

The model only sees the current call：It can only rely on the context provided in this round.
Information is not structured：Important facts and minor details are mixed together, making stable memory hard.
History is recomputed repeatedly：Large fixed prefixes are processed again and again across turns.

Impact

Answer quality becomes unstable：Longer conversations make consistency and traceability harder.
Cost is hard to estimate：Context size fluctuates heavily from turn to turn.
Production systems become hard to maintain：Without a clear context strategy, systems are hard to operate and extend.

أمام هذه التحديات، الاعتماد على "كن حذراً في العمليات" لم يعد مجدياً. نحتاج منهجية منهجية لإدارة الصلاحيات، وهذا بالضبط ما يحاول IAM (Identity and Access Management، إدارة الهوية والوصول) حله.

1. ما هو IAM/RAM؟ لنبدأ بـ "نظام التحكم في الوصول"

1.1 تشبيه: نظام التحكم الذكي للشركة

تخيل أن شركتك انتقلت إلى مبنى مكاتب جديد:

السيناريو	بدون IAM	مع IAM
موظف جديد	يعطونه مفتاحاً رئيسياً يفتح جميع الأبواب	يعطونه بطاقة تحكم تفتح فقط أبواب منطقته
موظف مغادر	المفتاح ضاع، لا يعرفون من يحمله	يلغون بطاقة التحكم فوراً، جميع الأبواب مغلقة
متعاقد خارجي	يقرضونه المفتاح لبضعة أيام	يصدرون بطاقة مؤقتة تنتهي صلاحيتها بعد 3 أيام
زائر	الاستقبال يعطيه مفتاحاً	يصدرون رمز زائر للاستخدام الواحد، للغرفة الاجتماعات فقط

IAM (Identity and Access Management، إدارة الهوية والوصول) يشبه هذا "نظام التحكم الذكي":

الهوية (Identity): مَن؟ موظفون، متعاقدون، زوار، تطبيقات
الوصول (Access): أي أبواب يمكنهم دخولها؟ ما العمليات التي يمكنهم تنفيذها؟
الإدارة (Management): كيف يُصدر المفتاح، كيف يُسترجع، كيف تُفحص السجلات

1.2 AWS IAM مقابل Alibaba Cloud RAM

🔐IAM vs RAM ComparisonPermission services across cloud providers

AWS IAM

👤User management

👥User groups

🎭Role assumption

📋Permission policies

🔗Identity federation

🔑Access keys

User management

AWS IAM

IAM User supports programmatic and console access

Alibaba Cloud RAM

RAM user has similar capabilities and supports sub-account sign-in

Alibaba Cloud RAM

👤User management

👥User groups

🎭Role assumption

📋Permission policies

🔗Identity federation

🔑Access keys

💡Core idea:IAM and RAM share the same core concepts. Most differences are terminology and implementation details.

مختلف مزودي الخدمات السحابية لديهم تطبيقات IAM الخاصة بهم:

مزود السحابة	اسم الخدمة	المفاهيم الأساسية
AWS	IAM (Identity and Access Management)	User, Group, Role, Policy
Alibaba Cloud	RAM (Resource Access Management)	用户、用户组、角色、策略
Tencent Cloud	CAM (Cloud Access Management)	用户、用户组、角色、策略
Huawei Cloud	IAM	用户、用户组、委托、策略
Azure	Azure AD + RBAC	User, Group, Role, RBAC

رغم اختلاف الأسماء، المفاهيم الأساسية متشابهة:

المستخدم (User): يمثل شخصاً أو تطبيقاً محدداً
المجموعة (Group): إدارة صلاحيات مجموعة من المستخدمين بشكل جماعي
الدور (Role): يحدد مجموعة صلاحيات يمكن "استلامها"
السياسة (Policy): قواعد الصلاحيات المحددة (السماح/الرفض لفعل ما)

2. المستخدمون والمجموعات والأدوار: أيها تستخدم؟

2.1 الفروق بين أنواع "الهوية" الثلاثة

🔐Identity Provider IntegrationEnterprise SSO login flow

1Open app

2Redirect to IdP

3User login

4Issue token

5Return to app

6Exchange credentials

7Access resources

User opens enterprise app

The user opens a business system in the browser, and the app detects that no valid session exists.

UserOpen →Enterprise app

💡Core idea:Enterprise IdP centralizes identity management and avoids creating separate accounts on every cloud platform.

باستخدام تشبيه مكتبي:

المفهوم	التشبيه	حالة الاستخدام	الخصائص
User (مستخدم)	موظف دائم، لديه مكتب وبطاقة تحكم	أعضاء فريق مستقرون على المدى الطويل	لديه بيانات اعتماد دائمة (كلمة مرور، AK/SK)
Group (مجموعة)	قسم، مثل "القسم التقني"، "المبيعات"	إدارة صلاحيات جماعية	لا يمكنه تسجيل الدخول، هو حاوية صلاحيات فقط
Role (دور)	بطاقة زائر مؤقتة، بطاقة متعاقد مؤقتة	تفويض مؤقت، وصول بين الحسابات	ليس لديه بيانات اعتماد دائمة، يحصل على بيانات مؤقتة عبر "استلام الدور"

2.2 حالة واقعية: تطور صلاحيات شركة ناشئة

المرحلة 1: الفريق المؤسس (2-3 أشخاص)

المشكلة: استخدام حساب root مباشرة، لأنه "أسهل"
الخطر: حساب root يملك جميع الصلاحيات، إذا تسرب الحساب كله يضيع

المرحلة 2: توسع الفريق (5-10 أشخاص)

التحسين: إنشاء IAM User لكل شخص، توزيع صلاحيات مختلفة
المشكلة:
- مشغل الشبكة وانغ غادر، أين AK/SK الخاص به على الخوادم؟
- مطور الواجهة الأمامية الجديد يحتاج صلاحيات قراءة S3 فقط، والخلفي يحتاج صلاحيات RDS، التكوين اليدوي واحد تلو الآخر مرهق

المرحلة 3: التوحيد (10-30 شخصاً)

التحسين:
1. إنشاء IAM Groups حسب الأدوار:
   - Developers: قراءة/كتابة S3, EC2, RDS
   - DevOps: صلاحيات كاملة ولكن يتطلب MFA
   - ReadOnly: عرض جميع الموارد، بدون تعديل
   - QAs: الوصول إلى موارد بيئة الاختبار

2. استخدام IAM Role:
   - مثيلات EC2 تستخدم Instance Profile، بدون AK/SK على الخادم
   - الوصول بين الحسابات باستخدام Role Assume، بدون مشاركة AK/SK
   - CI/CD يستخدم OIDC Federation، بدون بيانات اعتماد طويلة الأمد

المرحلة 4: متعدد الحسابات / مستوى المؤسسة (30+ شخصاً)

البنية:
- Master Account: فقط لإدارة الفواتير والهيكل التنظيمي
- Audit Account: جمع سجلات جميع الحسابات
- Dev Account: بيئة التطوير
- Staging Account: بيئة الاختبار
- Prod Account: بيئة الإنتاج، صلاحيات أكثر صرامة

تدفق الصلاحيات:
- المطورون افتراضياً لديهم صلاحيات قراءة فقط في Dev
- لتعديل الإنتاج، يقدمون طلب Assume إلى Role مؤقت في Prod
- جميع عمليات Assume مسجلة في CloudTrail، تدقيق دوري

3. الأدوار والسياسات: "روح" إدارة الصلاحيات

3.1 جوهر الدور: ثقة + صلاحيات

🎭Roles and PoliciesHow policies combine

🎭

CrossAccountS3AccessRoleCross-account access role

▶

📦S3ReadWritePolicy

Allows3:GetObject

Allows3:PutObject

📊CloudWatchLogsPolicy

🚫DenySensitiveData

💡Core idea:Policy composition means a role can attach multiple policies, and final permissions are the combined result. Deny has higher priority than Allow.

يتكون IAM Role من مكونين أساسيين:

سياسة الثقة (Trust Policy): مَن يمكنه استلام هذا الدور؟
سياسة الصلاحيات (Permission Policy): ماذا يمكنه الفعل بعد الاستلام؟

بتشبيه مسرحي:

المفهوم	التشبيه	الشرح
Role (دور)	"هاملت" في المسرحية	يحدد أي مسرحية يتم تمثيلها (الصلاحيات)
Trust Policy	المخرج يقول "مَن يمكنه تمثيل هاملت"	قد يكون "ممثلو هذه الفرقة" (مستخدمو الحساب)، "ممثلون مستعارون من فرقة أخرى" (بين الحسابات)، "ضيف شرف" (IdP خارجي)
Permission Policy	محتوى المسرحية	ماذا يمكن أن يفعل هاملت: إلقاء الحوار، المبارزة، الجنون (الصلاحيات المحددة)
Assume Role	الممثل يصعد إلى المسرح	شياو لي اختاره المخرج لتمثيل هاملت، على المسرح يملك جميع الصلاحيات المحددة في المسرحية
بيانات الاعتماد المؤقتة	بطاقة الأداء	شياو لي يحصل على "بطاقة أداء مؤقتة" تنتهي صلاحيتها عند انتهاء العرض

3.2 السياسة (Policy): "قواعد" الصلاحيات

🏛️Permission HierarchyScope differences across permission levels

👑

Root accountHighest account-wide privilege

👤

IAM adminFull IAM access

👥

Regular userLimited permissions

🎭

Temporary roleDefined by policy

🔑

Service accountAPI access

Root account

Scope:Highest account-wide privilege

Scenario:Account owner with all permissions

Full managementBilling managementClose account

💡Core idea:Least privilege means always granting only the minimum permissions required to complete the work.

IAM Policy هي مستند JSON يحدد "مَن يمكنه فعل أي عمليات على أي موارد".

مثال كامل لسياسة:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadWrite",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::my-app-bucket/*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "ap-northeast-1"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    },
    {
      "Sid": "DenySensitiveData",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::my-app-bucket/sensitive/*"
    }
  ]
}

شرح الحقول الرئيسية:

الحقل	المعنى	مثال
Version	إصدار بناء الجملة للسياسة	"2012-10-17"
Statement	مصفوفة تصريحات الصلاحيات، يمكن أن تحتوي قواعد متعددة	[...]
Sid	معرف التصريح، اختياري، لتحديد القاعدة	"AllowS3ReadWrite"
Effect	التأثير: Allow (سماح) أو Deny (رفض)	"Allow"
Action	العمليات المسموح/المرفوضة، تدعم أحرف البدل	"s3:GetObject", "s3:*"
Resource	المورد المتأثر، محدد بـ ARN	"arn:aws:s3:::bucket/*"
Condition	اختياري، يسري فقط عند تحقق شروط محددة	تقييد المنطقة، متطلبات MFA، إلخ

3.3 أولوية الصلاحيات: Deny > Allow > الرفض الافتراضي

منطق تقييم صلاحيات IAM يُلخص في جملة: الرفض الصريح يفوز دائماً، بدون Allow يعني رفض.

مسار التقييم:

1. أولاً التحقق من وجود سياسة Deny
   ├─ يوجد Deny → رفض (بغض النظر عن وجود Allow)
   └─ لا يوجد Deny → متابعة التحقق

2. ثم التحقق من وجود سياسة Allow
   ├─ يوجد Allow → سماح
   └─ لا يوجد Allow → رفض (مبدأ الرفض الافتراضي)

حالة عملية: حماية البيانات الحساسة

json

// السياسة 1: صلاحيات عادية للمطور
{
  "Effect": "Allow",
  "Action": ["s3:*"],
  "Resource": "arn:aws:s3:::company-data/*"
}

// السياسة 2: حماية الدليل الحساس (حتى لو كان المطور يملك s3:* لا يمكنه الوصول)
{
  "Effect": "Deny",
  "Action": ["s3:*"],
  "Resource": "arn:aws:s3:::company-data/sensitive/*"
}

النقاط الرئيسية:

رغم أن المطور يملك صلاحيات Allow لـ s3:*
الدليل الحساس لديه قاعدة Deny صريحة
Deny أولوية أعلى، لذا المطور لا يستطيع الوصول للبيانات الحساسة
حتى لو كان المطور مسؤولاً، Deny هذا يسري (ما عدا حساب root)

4. مفاتيح الوصول (AK/SK): "مفتاح" يجب الحرص على حفظه

4.1 ما هي AK/SK؟

🔑Access Key ManagementAK/SK lifecycle

ActiveCreated 45 days ago

Access Key:AKIAIOSF...

Secret Key:************************************

123456API calls

2 hours agoLast used

💡Core idea:Access key leaks are a common cause of cloud security incidents. Prefer IAM roles, and rotate keys regularly when keys are unavoidable.

Access Key هي بيانات اعتماد طويلة الأمد توفرها الخدمات السحابية للمكالمات البرمجية. تتكون من قسمين:

المكون	الاسم	الوظيفة	التشبيه
Access Key ID	معرف مفتاح الوصول	يحدد هويتك (مثل اسم المستخدم)	رقم البطاقة البنكية
Secret Access Key	مفتاح الوصول السري	يثبت أنك أنت (مثل كلمة المرور)	رقم PIN للبطاقة

4.2 لماذا AK/SK "عنصر عالي المخاطر"؟

حالة واقعية: درس من شركة ناشئة

شياو لي مهندس خلفية جديد في شركة ناشئة. مهمته في الأسبوع الأول كانت تصحيح وظيفة رفع الملفات.

python

# كود شياو لي (به مشاكل أمنية خطيرة!)
import boto3

# لتسهيل التصحيح، كتب AK/SK مباشرة في الكود
s3 = boto3.client(
    's3',
    aws_access_key_id='AKIAIOSFODNN7EXAMPLE',
    aws_secret_access_key='wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY',
    region_name='ap-northeast-1'
)

def upload_file(file_path, bucket_name, object_name):
    s3.upload_file(file_path, bucket_name, object_name)
    print(f"تم رفع الملف إلى s3://{bucket_name}/{object_name}")

# اختبار الرفع
upload_file('./test.jpg', 'my-company-bucket', 'uploads/test.jpg')

ما حدث بعد أسبوع:

شياو لي رفع الكود إلى GitHub (بما فيه AK/SK)
الكود على GitHub تم مسحه بواسطة crawler، AK/SK تم استخراجهما
المهاجم استخدم هذه البيانات لإنشاء العديد من مثيلات EC2 لتعدين العملات الرقمية
نهاية الشهر وصلت الفاتورة: مصاريف إضافية 12,000 دولار
التدقيق اكتشف تسريب AK/SK، تم استدعاء شياو لي للتحقيق...

ماذا نتعلم من هذه الحالة؟

الممارسة الخاطئة	الممارسة الصحيحة
تثبيت AK/SK في الكود	استخدام IAM Role، ترك البرنامج يحصل على بيانات اعتماد مؤقتة تلقائياً
رفع AK/SK إلى مستودع Git	استخدام `.gitignore` لتجاهل ملفات التكوين، استخدام خدمات إدارة الأسرار
عدم تدوير AK/SK لفترات طويلة	تدوير AK/SK دورياً، استخدام بيانات اعتماد مؤقتة بدلاً من طويلة الأمد
منح صلاحيات مفرطة لـ AK/SK	اتباع مبدأ الامتياز الأدنى، منح الصلاحيات اللازمة فقط

4.3 دليل الاستخدام الآمن لـ AK/SK

السيناريو 1: التطوير المحلي

bash

# الطريقة الصحيحة: استخدام AWS CLI لتكوين بيانات الاعتماد، بدون كتابتها في الكود
aws configure
# ثم اتبع التعليمات لإدخال Access Key ID وSecret Access Key
# هذه المعلومات تُحفظ في ~/.aws/credentials، بأذونات 600

# في الكود لا حاجة لأي تكوين بيانات اعتماد
import boto3
s3 = boto3.client('s3')  # يقرأ تلقائياً من ~/.aws/credentials

السيناريو 2: الخادم/EC2

python

# الطريقة الصحيحة: استخدام IAM Instance Profile
# 1. إنشاء IAM Role، إرفاق الصلاحيات المطلوبة (مثل S3ReadOnly)
# 2. إنشاء Instance Profile، ربط هذا Role
# 3. عند تشغيل EC2، اختيار هذا Instance Profile

# في الكود لا حاجة لبيانات اعتماد
import boto3
s3 = boto3.client('s3')  # يحصل على بيانات اعتماد مؤقتة تلقائياً من EC2 metadata service

# بيانات الاعتماد المؤقتة تتدوير تلقائياً، بدون قلق من الانتهاء

السيناريو 3: خط أنابيب CI/CD

yaml

# الطريقة الصحيحة: استخدام OIDC Federation (OpenID Connect)
# مثال مع GitHub Actions:

# 1. في AWS إنشاء OIDC Identity Provider، الوثوق بـ GitHub
# 2. إنشاء IAM Role مع سياسة ثقة تسمح لمستودع GitHub محدد بالاستلام
# 3. التكوين في GitHub Actions

name: Deploy
on: [push]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write # أساسي: السماح بطلب رمز OIDC
      contents: read
    steps:
      - uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
          aws-region: ap-northeast-1
          # ملاحظة: لا يوجد Access Key هنا! يستخدم بيانات اعتماد مؤقتة بالكامل

      - name: Deploy
        run: aws s3 sync ./build s3://my-bucket/

ملخص: مستويات أمان استخدام AK/SK

مستوى الأمان	النهج	السيناريو المناسب	مستوى المخاطر
الأعلى	استخدام IAM Role (بدون بيانات اعتماد طويلة الأمد)	EC2, Lambda, ECS, CI/CD	منخفض جداً
مرتفع	استخدام OIDC Federation	GitHub Actions, GitLab CI	منخفض
متوسط	استخدام خدمة إدارة الأسرار	التطوير المحلي، الفرق الصغيرة	متوسط
منخفض	استخدام متغيرات البيئة	النماذج الأولية السريعة، المشاريع الشخصية	مرتفع
منخفض جداً	التثبيت في الكود	غير موصى به في أي سيناريو	مرتفع جداً

5. المصادقة متعددة العوامل (MFA): إضافة "قفل" لحسابك

5.1 ما هي MFA؟

🔐Multi-Factor AuthenticationMFA two-factor authentication flow

🔐Password

→

📱MFA

→

✅Success

Enter password

💡Core idea:Enabling MFA can reduce account takeover risk by 99.9%. Even if the password leaks, an attacker cannot sign in without your MFA device.

MFA (Multi-Factor Authentication، المصادقة متعددة العوامل)، تُسمى أيضاً 2FA (Two-Factor Authentication)، هي آلية أمنية تتطلب من المستخدمين تقديم عاملَين أو أكثر من أنواع مختلفة من عوامل المصادقة عند تسجيل الدخول:

نوع العامل	ما هو	مثال
عامل المعرفة (ما تعرفه)	معلومات يعرفها المستخدم فقط	كلمة المرور، رمز PIN
عامل الحيازة (ما تملكه)	جهاز مادي يمتلكه المستخدم	الهاتف، مفتاح الأمان
عامل القياسات الحيوية (من أنت)	خصائص بيومترية للمستخدم	بصمة الإصبع، التعرف على الوجه

5.2 لماذا MFA مهمة جداً؟

البيانات الحقيقية تجيبك:

نوع الهجوم	معدل النجاح بدون MFA	معدل النجاح مع MFA
تخمين كلمة المرور / القوة الغاشمة	مرتفع	منخفض جداً (يحتاج العامل الثاني)
هجوم التصيد للحصول على كلمة المرور	مرتفع	منخفض جداً (صفحة التصيد لا تحصل على رمز MFA)
تسريب كلمات المرور (من مواقع أخرى)	مرتفع	منخفض جداً (لا يعرف العامل الثاني)

تقرير أمني من Microsoft (2020): تفعيل MFA يمكن أن يمنع 99.9% من الهجمات المؤتمتة.

5.3 تطبيق MFA: تفعيلها لحساب root في AWS

الخطوة 1: تسجيل الدخول إلى وحدة تحكم AWS

سجّل الدخول ببريد وكلمة مرور حساب root
في الزاوية العلوية اليمنى، انقر على اسم حسابك واختر "Security Credentials"

الخطوة 2: تفعيل MFA

ابحث عن قسم "Multi-factor authentication (MFA)"
انقر على "Assign MFA device"
اختر نوع جهاز MFA (موصى به "Authenticator app")

الخطوة 3: تكوين MFA الافتراضي

ثبّت Google Authenticator أو Microsoft Authenticator على هاتفك
امسح رمز QR أو أدخل المفتاح يدوياً
أدخل رمز التحقق من 6 أرقام المعروض في التطبيق (أدخل رمزين متتاليين لأن الرمز يتجدد كل 30 ثانية)

تم! حساب root الآن محمي بـ MFA.

6. الوصول بين الحسابات: كيف "تزور" بأمان؟

6.1 لماذا نحتاج الوصول بين الحسابات؟

🔗Cross-Account AccessAssumeRole mechanism

Account A (source)

IAM User

sts:AssumeRole

→

STS service

Verify identity

Issue temporary credentials

→

Account B (target)

CrossAccountRole

Access S3/EC2

Python example

sts = boto3.client('sts')
assumed = sts.assume_role(
    RoleArn='arn:aws:iam::123456789012:role/CrossAccountRole',
    RoleSessionName='MySession'
)
# Use temporary credentials to access target account resources

💡Core idea:Cross-account access works through role assumption. Temporary credentials expire automatically, making access safer and easier to manage.

مع نمو الأعمال، تستخدم العديد من الشركات بنية متعددة الحسابات لعزل البيئات المختلفة:

نوع الحساب	الغرض	متطلبات الصلاحيات
Master Account	الإدارة التنظيمية، تسوية الفواتير	يكاد لا يُستخدم
Security Audit	جمع مركزي لسجلات جميع الحسابات	قراءة فقط في الحسابات الأخرى
Shared Services	موارد مشتركة (مستودع صور، إلخ)	الحسابات الأخرى تقرأ فقط
Development	بيئة التطوير	صلاحيات كاملة للمطورين
Staging	بيئة الاختبار/ما قبل الإنتاج	صلاحيات للمختبرين
Production	بيئة الإنتاج	قيود صارمة، تتطلب موافقة

المشكلة: كيف تسمح لـ EC2 في Production بسحب صور من مستودع Shared Services؟

الحل A: كتابة AK/SK في بيانات المستخدم لـ Production (خطير! خطر تسريب AK/SK)
الحل B: استخدام Role Assume بين الحسابات (موصى به! بيانات اعتماد مؤقتة، تدوير تلقائي)

6.2 مبدأ Role Assume بين الحسابات

الحساب A (Production)                    الحساب B (Shared Services)
    |                                           |
    |  1. طلب Assume Role                      |
    |  "أريد استلام ECRReadRole من الحساب B"    |
    |------------------------------------------>|
    |                                           |
    |                    2. فحص سياسة الثقة     |
    |                    "هل يمكن للحساب A استلامي؟" |
    |                                           |
    |  3. إرجاع بيانات اعتماد مؤقتة             |
    |  AccessKeyId, SecretKey, SessionToken    |
    |<------------------------------------------|
    |                                           |
    |  4. استخدام بيانات الاعتماد المؤقتة للوصول إلى ECR |
    |  docker pull الحساب-B.dkr.ecr...          |
    ```

**النقاط الرئيسية**:

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

### 6.3 تطبيق: تكوين وصول ECR بين الحسابات

**السيناريو**: EC2 في حساب Production تحتاج لسحب صور Docker من حساب Shared Services.

**الخطوة 1: إنشاء IAM Role في حساب Shared Services**

1. سجّل الدخول إلى وحدة تحكم AWS لحساب Shared Services
2. اذهب إلى IAM -> Roles -> Create role
3. اختر "Another AWS account"
4. أدخل Account ID لـ Production
5. اختياري: حدد "Require external ID" وأدخل سلسلة عشوائية (زيادة الأمان)
6. أرفق الصلاحيات: AmazonEC2ContainerRegistryReadOnly
7. سمِّ Role: CrossAccountECRReadRole

**الخطوة 2: الحصول على ARN للدور**

بعد الإنشاء، انسخ ARN للدور:

arn:aws:iam::SHARED_SERVICES_ACCOUNT_ID:role/CrossAccountECRReadRole


**الخطوة 3: تكوين مثيل EC2 في حساب Production**

الطريقة A: استخدام Instance Profile (موصى بها)

1. إنشاء IAM Role في Production (لـ EC2)
2. سياسة الثقة: الثقة بخدمة EC2
3. سياسة الصلاحيات: السماح بـ Assume للدور بين الحسابات

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::SHARED_SERVICES_ACCOUNT_ID:role/CrossAccountECRReadRole"
    }
  ]
}

إنشاء Instance Profile، ربط هذا Role
عند تشغيل EC2، اختيار هذا Instance Profile

الطريقة B: Assume Role ديناميكي في بيانات المستخدم لـ EC2

bash

#!/bin/bash
# تثبيت AWS CLI
yum install -y aws-cli

# Assume Role بين الحسابات
CREDS=$(aws sts assume-role \
  --role-arn arn:aws:iam::SHARED_SERVICES_ACCOUNT_ID:role/CrossAccountECRReadRole \
  --role-session-name EC2PullSession)

# استخراج بيانات الاعتماد المؤقتة
export AWS_ACCESS_KEY_ID=$(echo $CREDS | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo $CREDS | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo $CREDS | jq -r '.Credentials.SessionToken')

# تسجيل الدخول إلى ECR
aws ecr get-login-password --region ap-northeast-1 | \
  docker login --username AWS --password-stdin SHARED_SERVICES_ACCOUNT_ID.dkr.ecr.ap-northeast-1.amazonaws.com

# سحب الصورة
docker pull SHARED_SERVICES_ACCOUNT_ID.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest

الخطوة 4: اختبار الوصول بين الحسابات

على EC2 في Production، نفّذ:

bash

# اختبار هل يمكن عمل Assume Role
aws sts get-caller-identity
# يجب أن يُظهر: arn:aws:sts::PRODUCTION_ACCOUNT_ID:assumed-role/CrossAccountECRReadRole/EC2PullSession

# اختبار هل يمكن سرد مستودعات ECR لـ Shared Services
aws ecr describe-repositories --registry-id SHARED_SERVICES_ACCOUNT_ID

تم! الآن EC2 في Production يمكنها سحب الصور من Shared Services بأمان، بدون مشاركة أي بيانات اعتماد طويلة الأمد.

7. تطبيق: بناء نظام صلاحيات آمن

7.1 بناء بنية الصلاحيات من الصفر

✅Permission Management Best PracticesApply security controls by priority

👑Protect the root accountP0

The root account owns the cloud service and needs the strongest protection.

✓ Enable MFA✓ Create an IAM admin user✓ Delete root access keys

👤Minimize user permissionsP0

🎭Prefer IAM rolesP1

🔑Manage access keys safelyP1

📊Monitoring and auditingP2

💡Core idea:Start from P0 and improve step by step. Each improvement significantly raises account security.

لنفترض أنك المسؤول التقني في شركة ناشئة من 10 أشخاص وتحتاج لتصميم بنية صلاحيات AWS من الصفر. الخطوات الموصى بها:

المرحلة 1: حماية حساب root (اليوم 1)

الهدف: حماية حساب root، أهم حساب

1. تفعيل MFA لحساب root (إلزامي)
   - موصى به MFA أجهزة (YubiKey) أو Google Authenticator

2. إنشاء حساب مسؤول IAM
   - اسم المستخدم: admin (أو اسمك)
   - الصلاحيات: AdministratorAccess (لكن سيتم تقليصها لاحقاً)
   - تفعيل MFA

3. حذف Access Key لحساب root (إذا تم إنشاؤها)
   - حساب root لا يجب أن يكون لديه AK/SK أبداً

4. تكوين تنبيهات استخدام حساب root
   - استخدام CloudWatch + SNS، إرسال بريد/رسالة عند تسجيل دخول root

المرحلة 2: تجميع صلاحيات الفريق (الأسبوع 1)

الهدف: تجميع أعضاء الفريق، إدارة الصلاحيات بشكل جماعي

1. تحليل أدوار الفريق:
   - الخلفية (2 شخص)
   - الواجهة الأمامية (1 شخص)
   - الموبايل (1 شخص)
   - مدير المنتج (1 شخص)
   - المصمم (1 شخص)
   - المؤسسون/المسؤولون (3 أشخاص)

2. إنشاء IAM Groups:

   Group: Developers
   ├── الأعضاء: جميع المطورين (الخلفية، الواجهة، الموبايل)
   ├── الصلاحيات:
   │   ├── EC2: تشغيل، إيقاف، عرض (لكن ليس حذف مثيلات الآخرين)
   │   ├── S3: قراءة/كتابة في buckets بيئة التطوير
   │   ├── RDS: قراءة فقط (لا يمكن تعديل قاعدة بيانات الإنتاج)
   │   └── CloudWatch: عرض السجلات
   └── القيود: العمل في منطقة ap-northeast-1 فقط

   Group: ProductTeam
   ├── الأعضاء: مدير المنتج، المصمم
   ├── الصلاحيات:
   │   ├── S3: قراءة فقط (عرض ملفات البيانات)
   │   ├── CloudWatch Dashboard: عرض لوحات المراقبة
   │   └── Cost Explorer: عرض الفواتير (لكن بدون تعديل)
   └── القيود: قراءة فقط، لا يمكن تعديل أي مورد

   Group: Administrators
   ├── الأعضاء: المؤسسون، المسؤول التقني
   ├── الصلاحيات: AdministratorAccess
   └── المتطلبات: يجب استخدام MFA للعمليات

3. إنشاء IAM User لكل شخص، إضافته إلى Group المناسب
   - عدم إرفاق صلاحيات مباشرة بالأفراد، الإدارة عبر Groups
   - تفعيل MFA (إلزامي)

المرحلة 3: تحسين صلاحيات مستوى التطبيق (الأسبوع 2-4)

الهدف: تمكين التطبيقات من الوصول بأمان إلى موارد AWS

1. مثيلات EC2 تستخدم Instance Profile
   - لم يعد يتم تكوين AK/SK على الخادم
   - إنشاء IAM Role، إرفاق الصلاحيات المطلوبة (مثل قراءة/كتابة S3)
   - إنشاء Instance Profile، ربط هذا Role
   - عند تشغيل EC2، اختيار هذا Instance Profile
   - في كود التطبيق استخدام boto3 مباشرة، بدون تكوين بيانات اعتماد

2. إذا كان يجب استخدام AK/SK (تكامل طرف ثالث)
   - استخدام AWS Secrets Manager لتخزين AK/SK
   - التطبيق يقرأ من Secrets Manager عند التشغيل
   - تكوين التدوير الدوري (90 يوماً)
   - مراقبة استخدام AK/SK

3. تكوين CloudTrail لتسجيل جميع مكالمات API
   - إنشاء S3 bucket منفصل لتخزين السجلات
   - تكوين التحقق من ملفات السجل (منع التلاعب)
   - تكوين إشعارات SNS للأحداث الحرجة (مثل استخدام root، تغييرات السياسات)

المرحلة 4: تعزيز الأمان (مستمر)

الهدف: بناء مراقبة وتحسين أمني مستمر

1. تفعيل AWS Config
   - مراقبة تغييرات تكوين الموارد
   - التحقق من الامتثال (مثل هل security groups تفتح 0.0.0.0/0)

2. تفعيل IAM Access Analyzer
   - تحليل مستمر لسياسات الموارد
   - تحديد الوصول الخارجي (مثل هل S3 bucket عام)

3. تدقيق دوري لتكوين IAM
   - فحص شهري للمستخدمين والأدوار غير المستخدمة
   - فحص استخدام Access Keys
   - التحقق من صحة تركيبة Groups

4. إنشاء عملية استجابة لحوادث الأمن
   - إذا اكتُشف تسريب AK/SK: حذف فوري، تدوير، تدقيق نطاق التأثير
   - إذا اكتُشفت مكالمات API مشبوهة: تحقيق فوري، تقييد الصلاحيات

8. الأخطاء الشائعة ودليل تجنبها

8.1 عشرة أنماط عكسية في IAM

#	النمط العكسي	لماذا هو سيء	الممارسة الصحيحة
1	استخدام حساب root للعمليات اليومية	حساب root يملك جميع الصلاحيات، لا يمكن تقييد الضرر عند التسريب	إنشاء حساب مسؤول IAM، استخدام root فقط عند الضرورة
2	منح الجميع AdministratorAccess	ينتهك مبدأ الامتياز الأدنى، يزيد مخاطر الأخطاء والتهديدات الداخلية	التجميع حسب الأدوار، منح الصلاحيات اللازمة فقط
3	تثبيت AK/SK في الكود	AK/SK يمكن تسريبها بسهولة عبر GitHub، وصعبة التدوير	استخدام IAM Role، متغيرات البيئة، أو خدمات إدارة الأسرار
4	عدم تدوير AK/SK لفترات طويلة	يزيد فترة التعرض إذا تسربت بيانات الاعتماد	تعيين سياسة تدوير كل 90 يوماً، أو الأفضل - استخدام بيانات اعتماد مؤقتة
5	تجاهل MFA	كلمة المرور المسربة تعني فقدان الحساب فوراً	تفعيل MFA لجميع مستخدمي IAM، خاصة ذوي الصلاحيات العالية
6	عدم استخدام CloudTrail	لا يمكن تدقيق مَن فعل ماذا، لا يمكن تتبع المصدر بعد الحادث	تفعيل CloudTrail، تخزين السجلات في حساب تدقيق مستقل
7	سياسة IAM متساهلة جداً	مثل `Resource: ""`، `Action: ""`، تزيد سطح الهجوم	تحديد ARN المورد وActions المحددة بوضوح
8	عدم تنظيف IAM Users للموظفين المغادرين	الحسابات الزومبي قد تصبح أبواباً خلفية	إنشاء عملية خروج، تعطيل وحذف IAM Users فوراً
9	عدم استخدام IAM Access Analyzer	لا يمكن اكتشاف سياسات الموارد المتساهلة (مثل S3 buckets عامة)	تفعيل IAM Access Analyzer، فحص الوصول الخارجي دورياً
10	عدم اختبار السياسات في بيئة الاختبار	تطبيق السياسات مباشرة في الإنتاج قد يسبب انقطاع الخدمة	استخدام IAM Policy Simulator للاختبار، التحقق في بيئة الاختبار أولاً

9. جدول المصطلحات

المصطلح بالإنجليزية	الترجمة العربية	الشرح
IAM (Identity and Access Management)	إدارة الهوية والوصول	خدمة إدارة هويات المستخدمين وصلاحيات الوصول في الخدمات السحابية
RAM (Resource Access Management)	إدارة الوصول إلى الموارد	اسم خدمة IAM في Alibaba Cloud
Root Account	حساب root	حساب المالك المنشأ عند تسجيل حساب السحابة، بأعلى الصلاحيات
IAM User	مستخدم IAM / حساب فرعي	هوية فرعية ينشئها حساب root، للعمليات اليومية
IAM Role	دور IAM	حامل صلاحيات مؤقت، بدون بيانات اعتماد طويلة الأمد، يحتاج "استلام"
IAM Policy	سياسة IAM	تعريف قواعد الصلاحيات بصيغة JSON
ARN	اسم مورد أمازون	معرف فريد عالمي للموارد
AK/SK	مفتاح الوصول / المفتاح السري	بيانات اعتماد للوصول البرمجي إلى APIs السحابية
STS	خدمة الرمز الأمني	خدمة توفر بيانات اعتماد أمنية مؤقتة
MFA	المصادقة متعددة العوامل	طريقة مصادقة تتطلب عاملين أو أكثر
SSO	تسجيل الدخول الموحد	طريقة مصادقة يكفي فيها تسجيل دخول واحد للوصول لأنظمة متعددة
ExternalId	معرف خارجي	معرف أمني يستخدم لمنع هجمات الوكيل المشوش
CloudTrail	خدمة التدقيق السحابي	خدمة سجلات تسجل جميع مكالمات API والعمليات في حساب السحابة

الخلاصة: المبادئ الأساسية لإدارة صلاحيات حسابات السحابة

إدارة صلاحيات حسابات السحابة ليست عملية تتم دفعة واحدة، بل يجب أن تتطور باستمرار وفقاً لحجم الفريق واحتياجات الأعمال:

مرحلة البداية (1-10 أشخاص):
- حماية حساب root (MFA + عدم استخدامه للعمليات اليومية)
- إنشاء حساب مسؤول IAM
- تجميع أساسي (Developers, Admins)
مرحلة النمو (10-50 شخصاً):
- تجميع صلاحيات مفصل (الواجهة، الخلفية، العمليات، المنتج، إلخ)
- استخدام IAM Role بدلاً من AK/SK
- تفعيل CloudTrail للتدقيق
- تدقيق دوري للصلاحيات
مرحلة النضج (50+ شخصاً / متعدد الحسابات):
- بنية متعددة الحسابات (Dev, Staging, Prod منفصلة)
- حساب مركزي لتدقيق السجلات
- تدقيق صلاحيات آلي وتنبيهات
- عملية كاملة لطلب وموافقة الصلاحيات

ثلاثة مبادئ أساسية تذكرها دائماً:

مبدأ الامتياز الأدنى: امنح فقط الصلاحيات اللازمة، لا تمنح AdministratorAccess
عدم استخدام بيانات اعتماد طويلة الأمد: أعطِ الأولوية لـ IAM Role وبيانات الاعتماد المؤقتة، تجنب تسريب AK/SK
تفعيل MFA: خاصة لحساب root والحسابات ذات الامتيازات العالية، هذا الإجراء الأمني الأكثر فعالية

قراءات إضافية:
توثيق AWS IAM الرسمي
توثيق Alibaba Cloud RAM الرسمي
AWS IAM Best Practices

إدارة الهوية والوصول في السحابة ​

0. مقدمة: لماذا "نخطو في الألغام" بمجرد دخول السحابة؟ ​

1. ما هو IAM/RAM؟ لنبدأ بـ "نظام التحكم في الوصول" ​

1.1 تشبيه: نظام التحكم الذكي للشركة ​

1.2 AWS IAM مقابل Alibaba Cloud RAM ​

2. المستخدمون والمجموعات والأدوار: أيها تستخدم؟ ​

2.1 الفروق بين أنواع "الهوية" الثلاثة ​

2.2 حالة واقعية: تطور صلاحيات شركة ناشئة ​

3. الأدوار والسياسات: "روح" إدارة الصلاحيات ​

3.1 جوهر الدور: ثقة + صلاحيات ​

3.2 السياسة (Policy): "قواعد" الصلاحيات ​

3.3 أولوية الصلاحيات: Deny > Allow > الرفض الافتراضي ​

4. مفاتيح الوصول (AK/SK): "مفتاح" يجب الحرص على حفظه ​

4.1 ما هي AK/SK؟ ​

4.2 لماذا AK/SK "عنصر عالي المخاطر"؟ ​

4.3 دليل الاستخدام الآمن لـ AK/SK ​

5. المصادقة متعددة العوامل (MFA): إضافة "قفل" لحسابك ​

5.1 ما هي MFA؟ ​

5.2 لماذا MFA مهمة جداً؟ ​

5.3 تطبيق MFA: تفعيلها لحساب root في AWS ​

6. الوصول بين الحسابات: كيف "تزور" بأمان؟ ​

6.1 لماذا نحتاج الوصول بين الحسابات؟ ​

6.2 مبدأ Role Assume بين الحسابات ​

7. تطبيق: بناء نظام صلاحيات آمن ​

7.1 بناء بنية الصلاحيات من الصفر ​

8. الأخطاء الشائعة ودليل تجنبها ​

8.1 عشرة أنماط عكسية في IAM ​

9. جدول المصطلحات ​

الخلاصة: المبادئ الأساسية لإدارة صلاحيات حسابات السحابة ​

إدارة الهوية والوصول في السحابة

0. مقدمة: لماذا "نخطو في الألغام" بمجرد دخول السحابة؟

1. ما هو IAM/RAM؟ لنبدأ بـ "نظام التحكم في الوصول"

1.1 تشبيه: نظام التحكم الذكي للشركة

1.2 AWS IAM مقابل Alibaba Cloud RAM

2. المستخدمون والمجموعات والأدوار: أيها تستخدم؟

2.1 الفروق بين أنواع "الهوية" الثلاثة

2.2 حالة واقعية: تطور صلاحيات شركة ناشئة

3. الأدوار والسياسات: "روح" إدارة الصلاحيات

3.1 جوهر الدور: ثقة + صلاحيات

3.2 السياسة (Policy): "قواعد" الصلاحيات

3.3 أولوية الصلاحيات: Deny > Allow > الرفض الافتراضي

4. مفاتيح الوصول (AK/SK): "مفتاح" يجب الحرص على حفظه

4.1 ما هي AK/SK؟

4.2 لماذا AK/SK "عنصر عالي المخاطر"؟

4.3 دليل الاستخدام الآمن لـ AK/SK

5. المصادقة متعددة العوامل (MFA): إضافة "قفل" لحسابك

5.1 ما هي MFA؟

5.2 لماذا MFA مهمة جداً؟

5.3 تطبيق MFA: تفعيلها لحساب root في AWS

6. الوصول بين الحسابات: كيف "تزور" بأمان؟

6.1 لماذا نحتاج الوصول بين الحسابات؟

6.2 مبدأ Role Assume بين الحسابات

7. تطبيق: بناء نظام صلاحيات آمن

7.1 بناء بنية الصلاحيات من الصفر

8. الأخطاء الشائعة ودليل تجنبها

8.1 عشرة أنماط عكسية في IAM

9. جدول المصطلحات

الخلاصة: المبادئ الأساسية لإدارة صلاحيات حسابات السحابة