تُحدد إدارة الهوية والوصول (IAM) الهوية القادرة على المصادقة والإجراءات التي يمكن لتلك الهوية تنفيذها على مورد محدد. في بيئة السحابة المتعددة، يمكن لمزود هوية مؤسسي واحد إتاحة تسجيل الدخول للقوى العاملة، بينما تتخذ كل من AWS وAzure وGoogle Cloud قرارات التفويض الخاصة بها ضمن حدودها الإدارية المستقلة. ولا يعني نجاح تسجيل الدخول بحد ذاته منح تفويض لطلب واجهة برمجة تطبيقات (API) خاص بمورد ما. ففي AWS، عادةً ما يتم تكوين ميزة تسجيل الدخول الموحد (SSO) للقوى العاملة عبر “IAM Identity Center”، وتتولى أدوار IAM -بالتعاون مع خدمة رموز الأمان من AWS (STS)- إصدار بيانات الاعتماد المؤقتة الناتجة عن ذلك.
تكمن الحدود الفاصلة المهمة بين مزود الهوية، ومستوى التحكم (control plane) الخاص بكل سحابة، ومستوى البيانات (data plane) الخاص بكل سحابة. يتولى مستوى التحكم إدارة موارد السحابة وتكويناتها، بينما يعالج مستوى البيانات الطلبات الموجهة للموارد ذاتها؛ حيث تقوم كل سحابة بتقييم عناصر الطلب (الطرف الفاعل “Principal”، والإجراء، والمورد، والشروط ذات الصلة) ضمن نظام IAM الخاص بها عند تقديم مثل هذا الطلب. ورغم أن هذه المستويات قد تتشارك معلومات الهوية، إلا أنها لا تشترك في مجموعة موحدة وشاملة للأذونات.
يمكننا الآن تتبع حدود تسجيل الدخول دون أن يعني ذلك بالضرورة الوصول إلى الموارد.
غالبًا ما تبدأ حالات الفشل في إدارة الهوية والوصول (IAM) في بيئات السحابة المتعددة بمصطلحات مألوفة ولكنها ذات نطاقات مختلفة. يمثل حساب AWS حدودًا إدارية لموارد AWS. ويمثل “المستأجر” (Tenant) في Azure حدود دليل Microsoft Entra ID، بينما يتم عادةً تفويض الوصول إلى موارد Azure من خلال نظام التحكم في الوصول المستند إلى الأدوار (Azure RBAC) على مستوى مجموعة الإدارة، أو الاشتراك، أو مجموعة الموارد، أو نطاق المورد نفسه. وفي Google Cloud، توفر “المؤسسة” (Organization) و"المشروع" (Project) نطاقات منفصلة لربط سياسات Cloud IAM وتحديد ملكية الموارد.
[المصادر][/المصادر]
يُعد هذا التمييز مهمًا لأن عضوية الهوية لا تعادل إذن الوصول إلى المورد. ففي Azure، يمكن لـ Microsoft Entra ID مصادقة المستخدم والكشف عن عضويته في المجموعات، ولكن لا يزال يتعين على Azure RBAC منح دور مناسب لتفويض إجراء Azure المطلوب. وفي AWS، تساهم سياسات AWS IAM وبيانات اعتماد خدمة رموز الأمان (STS) في عملية التفويض داخل AWS. أما في Google Cloud، فيقوم نظام Cloud IAM بتقييم ارتباطات السياسات الخاصة به بناءً على التسلسل الهرمي للموارد المعنية. ولا تؤدي أسماء المجموعات المتشابهة بالضرورة إلى إنشاء صلاحيات وصول متكافئة عبر هذه الحدود المختلفة.
[المصادر][/المصادر]
تخضع الأدلة التشغيلية لقيود مماثلة؛ إذ يمكن لحدث تسجيل الدخول لدى موفر هوية المؤسسة أن يثبت حدوث المصادقة، لكنه لا يستطيع بمفرده إثبات أن AWS أو Azure أو Google Cloud قد سمحت بطلب لاحق لواجهة برمجة التطبيقات (API). وبالمثل، يمكن لسجل التدقيق السحابي إظهار محاولة وصول إلى مستوى التحكم (control-plane) أو واجهة برمجة تطبيقات الموارد في تلك السحابة، لكنه لا يثبت صحة بيانات دورة حياة الهوية لدى موفر هوية المؤسسة. نحن بحاجة إلى أدلة من المستوى (plane) الذي اتخذ القرار، تتضمن تفاصيل الهوية، والمورد، والإجراء، والإطار الزمني للعملية.
[المصادر][/المصادر]
قاعدة اتخاذ القرار قم بتشخيص الوصول لكل سحابة ولكل طلب على حدة. حدد أولاً الكيان (principal)، والمورد المستهدف، وإجراء واجهة برمجة التطبيقات (API)، ومستوى التفويض الذي قام بتقييم الطلب.
[المصادر][/المصادر]
سنستخدم عبء عمل واحدًا محدد النطاق بدلاً من معاملة جميع الهويات على قدم المساواة. تستمع خدمة orders-api إلى الطلبات عبر المنفذ 8080. وتمثل هوية القوى العاملة orders-workforce-user المشغّل الذي يحتاج إلى وصول تفاعلي عبر موفر هوية المؤسسة. وتمثل مجموعة app-operators الدور التشغيلي المقصود، بينما تم فصل مجموعة cloud-admins عمدًا لأن الوصول الإداري ينطوي على مخاطر مختلفة ويخضع لحدود موافقة مغايرة.
[المصادر][/المصادر]
أما الهوية المؤتمتة فهي orders-ci، والتي تمثل مهمة تكامل مستمر (CI) تقوم بنشر عبء العمل أو إدارته. ولا تُعد طلباتها جلسات متصفح خاصة بالقوى العاملة؛ فهي تتلقى بيانات اعتماد موحدة (federated credentials) قصيرة العمر لكل سحابة بدلاً من الاحتفاظ بمفاتيح وصول سحابية طويلة العمر. تتمثل حدود المزودين لدينا في حساب AWS المسمى dev ومستأجر Azure المسمى contoso ومشروع Google Cloud المسمى orders-prod؛ ويجب أن تُحدِّد أي عملية تحقق لاحقة من الصلاحيات أحد هذه الأهداف صراحةً.
يمكننا الآن فحص كيفية وصول مسارات الهوية الخاصة بالقوى العاملة (workforce) وعمليات التكامل المستمر (CI) إلى كل سحابة.