إدارة الهوية والوصول اللامركزية (Decentralized IAM) وأمن السحب المتعددة: بناء الثقة المعدومة على نطاق واسع

لقد انتهى عصر نموذج الأمان القائم على القلعة والخندق (castle-and-moat). عندما تمتد بنيتك التحتية عبر AWS و GCP و Azure والبيئات المحلية (on-premise)، فلن يكون هناك محيط أمني. في هذا الواقع، لا تعد إدارة الهوية والوصول اللامركزية (Decentralized IAM) وأمن السحب المتعددة مجرد نمط معمارى - بل هي الدفاع الوحيد القابل للتطبيق ضد التحركات الجانبية (lateral movement) وهجمات سلاسل التوريد المعقدة. إن هوية الطالب، سواء كان بشراً أو آلة، هي الحدود الجديدة.

تفشل معظم المؤسسات في هذا الأمر. حيث يحاولون حشر موفري الهوية المركزية التقليديين (IdPs) في عناقيد Kubernetes الديناميكية ومتعددة السحب، مما يؤدي إلى تكاملات هشّة، وأذونات مفرطة، ونقاط فشل فردية (single points of failure). في هذا المنشور، سنقوم بتشريح المشكلة، واقتراح بنية معمارية مدروسة، ونوضح لك بالضبط كيفية تنفيذها دون المساس بسرعة المطورين.

المشكلة: فخ الهوية المحوري والفرعي (Hub-and-Spoke Identity Trap)

عندما تتبنى الشركات استراتيجية السحب المتعددة لأول مرة، فإنها عادةً ما تقوم بتوجيه جميع عمليات المصادقة والتفويض عبر دليل مركزي واحد (مثل Active Directory أو مثيل Okta واحد). وهذا يخلق فخ الهوية المحوري والفرعي.

يجب على كل خدمة في AWS تحاول الوصول إلى قاعدة بيانات في GCP أن تتم مصادقتها مقابل المحور المركزي. يقدم هذا التصميم ثلاثة عيوب رئيسية:

1. زمن الانتقال (Latency): لا يمكن لبنية الخدمات المصغرة التي تجري مئات من استدعاءات API الداخلية في الثانية أن تتحمل زمن انتقال الرحلة الذهاب والعودة إلى موفر الهوية (IdP) المركزي.
2. التوفر (Availability): إذا تعطل موفر الهوية المركزي، فإن البنية التحتية لجميع السحب تتوقف بالكامل.
3. نطاق تأثير الانفجار (Blast Radius): يمنح الدليل المركزي المخترق المهاجم مفاتيح الوصول للمملكة بأكملها، عبر جميع السحب.

أنت بحاجة إلى التحقق من الهويات محلياً، ولكن مع إدارتها عالمياً.

لماذا تعد إدارة IAM اللامركزية وأمن السحب المتعددة أمراً صعباً

تعني لامركزية الهوية توزيع الثقة، ويتطلب توزيع الثقة إثباتات تشفيرية يتم التحقق منها باستمرار. عندما يكون لديك عبء عمل (workload) في AWS EKS يحتاج إلى قراءة كائن في حاوية Google Cloud Storage، كيف يعرف GCP أنه يمكنه الوثوق في حاوية (pod) AWS؟

النهج الساذج هو الاعتماد على بيانات اعتماد ثابتة طويلة الأجل (مثل مفاتيح وصول AWS أو ملفات JSON لحساب خدمة GCP) المخزنة في Vault أو كأسرار في Kubernetes. يعد هذا نمطاً مضاداً (anti-pattern) سيئاً. تتسرب بيانات الاعتماد الثابتة، ونادراً ما يتم تدويرها، وتكسر المبدأ الأساسي للثقة المعدومة (Zero Trust): الوصول قصير الأجل والمحدد النطاق.

التحدي هو تأسيس اتحاد لهويات أعباء العمل (workload identity federation) عبر نطاقات ثقة متباينة. يجب عليك تعيين هوية في النطاق A (موفر AWS OIDC) إلى دور في النطاق B (GCP IAM) دون تبادل أسرار طويلة الأجل.

البنية المعمارية الموصى بها: اتحاد هويات أعباء العمل (Workload Identity Federation)

نحن نؤيد بنية معمارية يعمل فيها كل تطبيق كـ موفر هوية (IdP) خاص به لأعباء العمل التي يستضيفها. ثم تقوم موفرات الهوية المحلية هذه بتفويض الثقة مع بيئات السحب الأخرى باستخدام OpenID Connect (OIDC).

تستخدم بنيتنا المعمارية المرجعية:

• Kubernetes (EKS v1.30): لاستضافة أعباء العمل.
• AWS IAM OIDC Provider: موفر الهوية المحلي لـ EKS.
• GCP Workload Identity Federation: للوثوق بموفر AWS OIDC.
• SPIFFE/SPIRE (v1.8.0): لبروتوكول mTLS الداخلي بين الخدمات وإصدار الهويات.

بدلاً من تمرير الأسرار، يطلب عبء العمل رمزاً مميزاً قصير الأجل من بيئته المحلية. ويتم توقيع هذا الرمز تشفيرياً بواسطة موفر الهوية (IdP) المحلي. وتتحقق البيئة المستهدفة (GCP) من التوقيع، وترسم مطالبة OIDC لدور IAM محلي، وتمنح وصولاً مؤقتاً.

التطبيق: من AWS EKS إلى GCP BigQuery

دعونا نلقي نظرة على تطبيق ملموس. لدينا خدمة إدخال بيانات تعمل في عنقود AWS EKS تحتاج إلى الكتابة إلى مجموعة بيانات GCP BigQuery.

1. تكوين موفر AWS EKS OIDC

أولاً، تأكد من أن عنقود EKS الخاص بك لديه موفر IAM OIDC مرتبط به. يتيح ذلك لحسابات خدمة Kubernetes افتراض أدوار IAM، ولكن الأهم من ذلك، أنه يمنحنا عنوان URL للمصدر يمكن لـ GCP الوثوق به.

# Terraform v1.8.0
# AWS Provider v5.40.0

data "tls_certificate" "eks" {
  url = aws_eks_cluster.main.identity[0].oidc[0].issuer
}

resource "aws_iam_openid_connect_provider" "eks" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = [data.tls_certificate.eks.certificates[0].sha1_fingerprint]
  url             = aws_eks_cluster.main.identity[0].oidc[0].issuer
}

2. إنشاء مجمع هويات أعباء العمل في GCP (GCP Workload Identity Pool)

في GCP، ننشئ مجمع هويات أعباء العمل (Workload Identity Pool) وموفراً لها (Provider). يشير الموفر إلى عنوان URL لمصدر AWS EKS OIDC. ونقوم بتعيين مطالبة sub (التي تحتوي على مساحة اسم Kubernetes واسم حساب الخدمة) إلى موضوع Google IAM.

# GCP Provider v5.20.0

resource "google_iam_workload_identity_pool" "aws_pool" {
  workload_identity_pool_id = "aws-eks-pool"
  display_name              = "AWS EKS Trust Pool"
  description               = "Identity pool for EKS workloads"
}

resource "google_iam_workload_identity_pool_provider" "aws_provider" {
  workload_identity_pool_id          = google_iam_workload_identity_pool.aws_pool.workload_identity_pool_id
  workload_identity_pool_provider_id = "aws-eks-provider"
  display_name                       = "AWS EKS OIDC Provider"
  
  attribute_mapping = {
    "google.subject" = "assertion.sub"
    "attribute.namespace" = "assertion['kubernetes.io']['namespace']"
  }
  
  oidc {
    issuer_uri = aws_eks_cluster.main.identity[0].oidc[0].issuer
  }
}

3. ربط حساب خدمة GCP

الآن نقوم بإنشاء حساب خدمة GCP يمتلك أذونات للكتابة في BigQuery، ونسمح لحساب خدمة Kubernetes المحدد (عبر مجمع الهوية) بانتحال شخصيته.

resource "google_service_account" "bq_writer" {
  account_id   = "bq-writer-sa"
  display_name = "BigQuery Writer Service Account"
}

resource "google_project_iam_member" "bq_data_editor" {
  project = var.project_id
  role    = "roles/bigquery.dataEditor"
  member  = "serviceAccount:${google_service_account.bq_writer.email}"
}

resource "google_service_account_iam_member" "workload_identity_user" {
  service_account_id = google_service_account.bq_writer.name
  role               = "roles/iam.workloadIdentityUser"
  
  # The member string matches the Google subject mapping from the provider
  # format: principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT
  member = "principal://iam.googleapis.com/${google_iam_workload_identity_pool.aws_pool.name}/subject/system:serviceaccount:data-ingest:bq-writer"
}

4. كود التطبيق

يستخدم التطبيق الذي يعمل في EKS حزمة برامج Google Cloud SDK. تكتشف حزمة SDK تلقائياً الرمز المميز لحساب الخدمة المعروض والمقدم من EKS، وتستخدمه للمصادقة ضد مجمع هويات أعباء عمل GCP، وتسترجع رمز وصول قصير الأجل لحساب الخدمة bq-writer-sa. ولا توجد حاجة إلى مفاتيح ثابتة.

# Kubernetes Service Account and Pod definition
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bq-writer
  namespace: data-ingest
  annotations:
    # Optional: If you also need AWS permissions
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/bq-writer-role

---
apiVersion: v1
kind: Pod
metadata:
  name: bq-writer-app
  namespace: data-ingest
spec:
  serviceAccountName: bq-writer
  containers:
  - name: app
    image: my-registry/bq-writer:v1.2.0
    env:
    # Tell Google SDK where to find the credential configuration
    - name: GOOGLE_APPLICATION_CREDENTIALS
      value: /var/run/secrets/google/credentials.json
    volumeMounts:
    - name: google-cloud-key
      mountPath: /var/run/secrets/google
    - name: k8s-token
      mountPath: /var/run/secrets/tokens
  volumes:
  - name: google-cloud-key
    configMap:
      name: workload-identity-config
  - name: k8s-token
    projected:
      sources:
      - serviceAccountToken:
          path: oidc-token
          expirationSeconds: 3600
          audience: sts.amazonaws.com # Or your GCP audience

فخاخ يجب تجنبها

إن تنفيذ هذه البنية المعمارية لا يخلو من المخاطر. إليك أوجه الفشل الشائعة التي نلاحظها عندما تتبنى الفرق إدارة IAM اللامركزية:

1. رسم المطالبات الواسع (Broad Claim Mapping)

عند تكوين تعيين سمات موفر هوية عبء العمل، لا تقم برسم مطالبات واسعة. إذا قمت برسم "google.subject" = "assertion.aud"، فإنك تسمح لأي عبء عمل في عنقود EKS بانتحال شخصية حساب خدمة GCP. قم دائماً بالتعيين وصولاً إلى sub (الموضوع) المحدد والذي يتضمن مساحة الاسم واسم حساب الخدمة (system:serviceaccount:namespace:sa-name).

2. تجاهل انتهاء صلاحية الرمز المميز (Ignoring Token Expiration)

تنتهي صلاحية الرموز المميزة لحسابات الخدمة المعروضة في Kubernetes. يجب أن يكون تطبيقك قادراً على إعادة تحميل بيانات الاعتماد ديناميكياً. تتعامل معظم حزم SDK الحديثة مع هذا تلقائياً، ولكن منطق المصادقة المخصص غالباً ما يخزن الرموز المميزة مؤقتاً لأجل غير مسمى، مما يؤدي إلى فشل يصعب تصحيحه عندما ينتهي الرمز المميز بعد ساعة.

3. إهمال سجلات التدقيق (Neglecting Audit Logs)

تحجب اللامركزية الرؤية الكاملة. يجب عليك تجميع سجلات التدقيق من AWS CloudTrail، و GCP Cloud Logging، وخادم Kubernetes API في نظام SIEM مركزي. فإذا تم اختراق هوية عبء العمل، فستحتاج إلى تتبع إجراءاتها عبر حدود السحب. وتأكد من ربط مطالبة sub من رمز OIDC المميز مع استدعاءات API الناتجة في البيئة المستهدفة.

النتيجة: الأمان كممكّن للتطوير

إن الانتقال إلى بنية IAM اتحادية ولامركزية يغير بشكل أساسي الموقف الأمني للمؤسسة الهندسية.

من خلال القضاء على بيانات الاعتماد الثابتة، فإنك تقضي على الناقل الرئيسي لهجمات سلاسل التوريد. وعندما يحتاج المطور إلى خدمة جديدة للوصول إلى مورد عبر السحب، فإنه لا يطلب مفتاحاً من فريق الأمان. بل يكتب وحدة Terraform لإنشاء علاقة الثقة وتحديد السياسة.

يصبح الأمان عبارة عن كود برمجى. وتصبح الثقة مؤقتة (ephemeral). وتصبح البنية التحتية مرنة. هذا هو المسار الوحيد للمضي قدماً للفرق الهندسية الجادة التي تعمل على نطاقات واسعة.