أساسيات IAM عبر مزودي السحابة

إدارة الهوية والوصول (IAM) هي أهم مجال أمني في الحوسبة السحابية. بما أن الهوية هي المحيط في السحابة، فإن الخطأ في IAM يعني أن كل شيء آخر مكشوف.

لماذا IAM الأهم

الإحصائيات واضحة:

• أخطاء تكوين IAM هي السبب #1 لخروقات السحابة
• إدارة الهوية والوصول السحابية تقود بـ 34.8% حصة سوقية في برمجيات أمان السحابة (2024)
• خرق Capital One (100+ مليون سجل) نشأ من دور IAM ذي صلاحيات مفرطة

في الأمان التقليدي، يمكنك امتلاك مصادقة ضعيفة إذا كان لديك دفاع محيطي قوي. في السحابة، لا يوجد محيط—IAM هو دفاعك.

مفاهيم IAM الأساسية

كل مزود سحابة ينفذ هذه المفاهيم الأساسية بشكل مختلف:

المفهوم	AWS	Azure	GCP
خدمة الهوية	IAM	Microsoft Entra ID	Cloud IAM
هوية المستخدم	IAM User	User	Google Account
هوية الخدمة	IAM Role	Managed Identity	Service Account
تجميع الصلاحيات	IAM Policy	Role Definition	IAM Role
تعيين الصلاحيات	Role attachment	Role Assignment	IAM Binding
التحكم على مستوى المورد	Resource Policy	Scope	IAM Conditions

AWS IAM بالتفصيل

أنواع الهوية

┌─────────────────────────────────────────────────────────┐
│                    AWS Account (Root)                    │
├─────────────────────────────────────────────────────────┤
│  IAM Users          │  IAM Roles           │  Groups    │
│  • مستخدمين بشريين   │  • EC2 instances     │  • Admins  │
│  • حسابات خدمة      │  • Lambda functions  │  • Devs    │
│  • بكلمات مرور      │  • عبر الحسابات      │  • قراءة فقط│
│  • بمفاتيح وصول     │  • Federation        │            │
└─────────────────────────────────────────────────────────┘

هيكل السياسة

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadOnly",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "10.0.0.0/8"
        }
      }
    }
  ]
}

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

• Effect: السماح أو الرفض
• Action: عمليات API المسموحة
• Resource: ما ينطبق عليه الإجراء
• Condition: متى تنطبق السياسة

Azure IAM (Entra ID + RBAC)

Azure يفصل الهوية (Entra ID) عن التفويض (RBAC):

طبقة الهوية (Entra ID)

• Users: الهويات البشرية
• Service Principals: هويات التطبيقات
• Managed Identities: بيانات اعتماد تديرها Azure للخدمات

طبقة التفويض (RBAC)

┌──────────────────────────────────────────────────────────┐
│  Security Principal  →  Role Definition  →  Scope        │
│  (من)                   (ماذا)             (أين)          │
├──────────────────────────────────────────────────────────┤
│  User                   Owner               Subscription  │
│  Group                  Contributor         Resource Group│
│  Service Principal      Reader              Resource      │
│  Managed Identity       Custom Role                       │
└──────────────────────────────────────────────────────────┘

الأدوار المدمجة

الدور	الصلاحيات
Owner	وصول كامل بما في ذلك RBAC
Contributor	وصول كامل باستثناء RBAC
Reader	وصول للقراءة فقط
User Access Administrator	إدارة RBAC فقط

GCP IAM

GCP يستخدم نموذج التسلسل الهرمي للموارد:

Organization
    └── Folder (اختياري)
        └── Project
            └── Resource

مكونات IAM

• Member: الهوية (مستخدم، مجموعة، حساب خدمة، نطاق)
• Role: مجموعة من الصلاحيات
• Policy: يربط الأعضاء بالأدوار على مورد

ربط السياسة

bindings:
- role: roles/storage.objectViewer
  members:
  - user:developer@example.com
  - serviceAccount:app@project.iam.gserviceaccount.com
- role: roles/storage.admin
  members:
  - group:admins@example.com
  condition:
    expression: "request.time < timestamp('2026-01-01T00:00:00Z')"

ملخص أفضل ممارسات IAM

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

التالي، سنفحص أخطر أخطاء تكوين IAM وكيفية تحديدها. :::