كيف تقضي الهويات المُدارة على كلمات المرور المضمّنة في الكود داخل Azure

By Mirko Peters · 2026-08-13

أهلاً بعودتكم إلى المدونة المرافقة لبودكاستنا! إذا كنتم تبنون التطبيقات منذ فترة، فمن المرجح أنكم واجهتم المشكلة الأزلية المتمثلة في ال…

Automatically translated with AI from the original post. Read the English original

أهلاً بكم مجدداً في المدونة المصاحبة لبودكاستنا! إذا كنتم تبنون تطبيقات منذ فترة، فمن المرجّح أنكم واجهتم المشكلة القديمة المتمثلة في كيفية ربط الشيفرة بقاعدة بيانات أو واجهة برمجية أو حساب تخزين سحابي. تقليدياً، كان المطورون يحلّون هذه المشكلة بوضع سلسلة اتصال أو كلمة مرور لقاعدة البيانات أو سرّ عميل مباشرة داخل ملف إعدادات أو متغير بيئة، أو حتى الأسوأ من ذلك، بتضمينه مباشرة في مستودع الشيفرة المصدرية. وطالما استطاع التطبيق قراءة هذا السر، كان بإمكانه المصادقة وأداء مهمته. لكن ماذا يحدث عندما تُرفع هذه الشيفرة عن طريق الخطأ إلى مستودع عام على GitHub؟ وماذا يحدث عندما يغادر موظف ساخط المؤسسة، أو يحصل مهاجم على صلاحية قراءة إعدادات تطبيقك؟ في لحظات، تصبح بنيتك التحتية بالكامل معرّضة للخطر. وفي بنية السحابة الحديثة، يُعدّ هذا خطراً غير مقبول. اليوم، نتعمق في كيفية قضاء الهويات المُدارة في Microsoft Azure تماماً على الحاجة إلى كلمات المرور المضمّنة في الكود، واستبدال الأسرار الثابتة برموز وصول ديناميكية قصيرة العمر.

مقدمة في أمن السحابة والأسرار المضمّنة في الكود

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

لقد حطّمت الحوسبة السحابية هذا الحد تماماً. فأعباؤنا الآن تمتد عبر بيئات متعددة السحابات، ومراكز بيانات محلية، ومنصات SaaS، ووظائف بلا خادم موزّعة. وفي هذا العالم الجديد، يجب أن يتبع الأمان هوية أعباء العمل نفسها. فالأسرار المضمّنة في الكود قنابل موقوتة؛ فهي لا تُدوَّر تلقائياً، ومن الصعب تدقيقها بشكل كبير، ولا تترك أي هامش للخطأ إذا تعرّضت للكشف. ولتحقيق أمان Zero Trust حقيقي، يجب أن نفصل بيانات الاعتماد عن الشيفرة المصدرية بالكامل. نحتاج إلى آلية مصادقة تستطيع فيها التطبيقات إثبات هويتها دون الحاجة إلى معرفة كلمة مرور أو تخزينها.

فهم هويات المستخدمين مقابل هويات أعباء العمل في Entra ID

لفهم كيفية تطوّر أمان السحابة، نحتاج أولاً إلى النظر في كيفية إدارة Microsoft Entra ID للكيانات التي تصل إلى أنظمتنا. بشكل عام، تصنّف Microsoft Entra ID الهويات إلى فئتين رئيسيتين: هويات المستخدمين وهويات أعباء العمل.

تمثّل هويات المستخدمين بشراً: موظفين وشركاء ومتعاقدين وعملاء. يتفاعل البشر مع الأنظمة بشكل ديناميكي، ويصادقون باستخدام طرق مصممة خصيصاً للأشخاص، مثل كلمات المرور، وWindows Hello for Business، ومفاتيح الأمان FIDO2، والمصادقة متعددة العوامل. والبشر ينسون كلمات المرور، ويقعون ضحية لهجمات التصيّد، ويحتاجون إلى إعادة تعيين كلمات المرور من قبل المسؤول.

أما هويات أعباء العمل فتمثّل البرمجيات. وتشمل التطبيقات، والخدمات الخلفية، وسكربتات الأتمتة، وAzure Functions، وLogic Apps، وخطوط نشر DevOps، ووكلاء الذكاء الاصطناعي. فأعباء العمل لا تشرب القهوة، ولا تنقر على رسائل التصيّد الاحتيالي، ولا يمكنها إكمال مطالبة مصادقة متعددة العوامل تفاعلية على الهاتف الذكي. فهي تحتاج إلى المصادقة بشكل غير تفاعلي وبرمجي ومستمر. ومعاملة هوية عبء العمل كهوية مستخدم عبر تعيين كلمة مرور ثابتة لها تُعدّ من أكثر الأخطاء شيوعاً في بنية السحابة. تحتاج هويات أعباء العمل إلى نماذج حوكمة متخصصة، وإدارة لدورة حياتها، وتدفقات مصادقة آلية خاصة بها.

فك الغموض عن تسجيلات التطبيقات، ومبادئ الخدمة، والهويات المُدارة

إذا قضيت أي وقت في إعداد التطبيقات داخل Microsoft Entra ID، فلا شك أنك صادفت ثلاثة مصطلحات كثيراً ما تسبب الالتباس: تسجيلات التطبيقات (Application Registrations)، ومبادئ الخدمة (Service Principals)، والهويات المُدارة (Managed Identities). دعونا نفصّلها ببساطة.

يُعدّ تسجيل التطبيق (Application Registration) التعريف العام أو المخطط الأساسي لتطبيقك. عند تسجيل تطبيق في Microsoft Entra ID، فأنت تنشئ هويته العامة عبر منظومة المستأجرين المتعددين بالكامل. وهنا تحدد الأذونات التي قد يحتاجها التطبيق، ونقاط نهاية المصادقة التي يستخدمها، والمعرّفات URI المرتبطة به. فكّر في تسجيل التطبيق على أنه نموذج جواز السفر.

يُعدّ مبدأ الخدمة (Service Principal) النسخة المحلية من هذا التطبيق داخل مستأجر بعينه. إذا كان التطبيق متعدد المستأجرين، فسيكون له تسجيل تطبيق واحد في مستأجر الناشر، لكن له مبدأ خدمة منفصل في كل مستأجر عميل نُشر فيه التطبيق ومنحه الموافقة. ومبدأ الخدمة هو المكان الذي يعيّن فيه المسؤولون الأذونات فعليًا، ويطبّقون نهج الوصول المشروط، ويتحكمون في من يستطيع الوصول إلى التطبيق محليًا. فكّر في مبدأ الخدمة على أنه جواز السفر الموثّق بالختم الذي يُستخدم للدخول إلى دولة بعينها.

تأخذ الهوية المُدارة (Managed Identity) هذا المفهوم خطوة أبعد، وتحديدًا للموارد التي تعمل داخل Microsoft Azure. فبدلًا من أن يضطر المطوّر إلى إنشاء تسجيل تطبيق يدويًا، وتوليد سرّ عميل (client secret)، وتخزين هذا السرّ في متغير بيئة، وكتابة شيفرة لإدارة دورة حياة المصادقة، يتولى Azure العملية كاملة في الخلفية. إذ ينشئ Azure بيانات الاعتماد الأساسية ويديرها ويدوّرها تلقائيًا نيابةً عنك. ويكفي أن يخبر المطوّر مورد Azure بأن يستخدم الهوية المُدارة الخاصة به، وسيتكفّل Azure بالباقي.

كيف تُلغي الهويات المُدارة كلمات المرور وبيانات الاعتماد المكتوبة داخل الشيفرة

يكمن سرّ الهويات المُدارة في الطريقة التي تغيّر بها جوهر عملية المصادقة. فعند استخدام هوية مُدارة لمورد Azure، مثل Azure App Service أو جهاز افتراضي أو Azure Function، لا توجد فعليًا أي كلمة مرور أو سرّ أو شهادة مخزّنة في شيفرتك أو في إعدادات التهيئة.

عندما يحتاج تطبيقك إلى الوصول إلى مورد محمي، مثل قاعدة بيانات أو واجهة برمجية، فإنه لا يبحث عن كلمة مرور مخزّنة. بل يجري استدعاءً محليًا إلى نقطة النهاية الخاصة بخدمة بيانات المثيل الوصفية في Azure (IMDS)، وهي متاحة بأمان فقط من داخل مورد Azure المحدد. ثم تطلب المنصة الأساسية لمورد Azure رمز ويب JSON (JWT) قصير العمر مباشرةً من Microsoft Entra ID نيابةً عن التطبيق.

يتحقق Microsoft Entra ID من هوية مورد Azure، ويُصدر رمز وصول موقّعًا تشفيريًا بعمر قصير جدًا (يبلغ عادةً نحو ساعة واحدة)، ويعيده إلى التطبيق. ثم يستخدم التطبيق هذا الرمز للمصادقة أمام الخدمة المستهدفة. ولأن الرمز ينتهي بسرعة، فحتى إن تمكّن مهاجم من اعتراضه، تكون نافذة الثغرة ضيقة للغاية. وعلاوةً على ذلك، لأنه لا توجد كلمة مرور ثابتة مكتوبة في الشيفرة، فلا يوجد ما قد يسرّبه المطوّر عن طريق الخطأ إلى مستودع عام.

دمج Azure Key Vault ورموز الوصول قصيرة العمر

إذا كانت الهويات المُدارة تُلغي الحاجة إلى كلمات مرور للتطبيقات، فقد تتساءل عن كيفية تعامل التطبيقات مع الأسرار الخارجية فعليًا، مثل مفاتيح واجهات البرمجة الخاصة بخدمات الجهات الخارجية التي لا تدعم المصادقة عبر Microsoft Entra. وهنا يأتي دور Azure Key Vault، الذي يعمل جنبًا إلى جنب مع الهويات المُدارة.

بدلًا من ترميز مفتاح واجهة برمجية لجهة خارجية داخل الشيفرة المصدرية، تخزّن هذا السرّ بأمان داخل Azure Key Vault. ثم تمنح الهوية المُدارة لمورد Azure الخاص بك إذنًا بقراءة الأسرار من هذا Key Vault باستخدام التحكم في الوصول المستند إلى الأدوار (Azure RBAC) أو نهج الوصول الخاصة بـ Key Vault.

عند بدء تشغيل تطبيقك، يستخدم هوية الُمدارة الخاصة به للمصادقة أمام Azure Key Vault، ويسترجع مفتاح واجهة البرمجة الخارجي المطلوب ديناميكيًا في الذاكرة، ثم يستخدمه. ولا تُكشف بيانات الاعتماد في أي لحظة داخل الشيفرة المصدرية. فالتطبيق يستخدم آلية آمنة قائمة على الهوية لجلب السرّ، بدلًا من الاعتماد على سلسلة نصية ثابتة مضمّنة في ملف إعدادات.

تأمين هويات أحمال العمل بمبدأ أقل الصلاحيات والحوكمة

يُعدّ إلغاء كلمات المرور المكتوبة داخل الشيفرة مكسبًا كبيرًا للأمان، لكن نشر الهويات المُدارة ليس نموذجًا تشغيليًا من نوع "اضبطه ثم انسَه". فهويات أحمال العمل تحتاج إلى حوكمة صارمة تمامًا كما تحتاجها حسابات المستخدمين البشرية.

قبل كل شيء، يجب الالتزام الصارم بمبدأ الحد الأدنى من الصلاحيات. لا تمنح هوية عبء العمل أدوار المساهم الواسعة أو أذونات Microsoft Graph المفرطة فقط لتسريع تشغيل الأمور. إذا كان سكربت أتمتة في الخلفية يحتاج فقط إلى قراءة عناصر من حاوية Azure Storage محددة، فامنحه صلاحية Storage Blob Data Reader على تلك الحاوية بالذات، ولا شيء أكثر من ذلك. وإذا تعرّضت هوية عبء العمل للاختراق يومًا، فإن نطاق الضرر سيبقى محدودًا للغاية.

ثانيًا، يجب عليك مراقبة هويات أعباء العمل وتدقيقها بشكل مستمر. كثيرًا ما تُنشئ المؤسسات مبادئ الخدمة والهويات المُدارة لمشاريع الإثبات التجريبي وسكربتات الأتمتة والتكاملات المؤقتة، ثم تتركها تعمل إلى أجل غير مسمى بصلاحيات عالية. نفّذ مراجعات أمنية دورية لتحديد مبادئ الخدمة اليتيمة، وحسابات الأتمتة غير المستخدمة، وبيانات الاعتماد القديمة. كما أن الاستفادة من ميزات مثل Microsoft Entra ID Protection وإعداد تسجيل قوي عبر Azure Monitor يمنحك رؤية كاملة لتوقيت وكيفية وصول هويات أعباء العمل إلى بيئتك.

اختيار استراتيجية الهوية المناسبة لكل عبء عمل سحابي

مع الكثير من الخيارات المتاحة في منظومة الهوية لدى Microsoft، كيف تختار استراتيجية المصادقة المناسبة لعبء العمل الخاص بك؟ يعتمد القرار عادةً على مكان تشغيل التطبيق وطريقة تصميمه.

إذا كان الكود يعمل داخل Microsoft Azure، سواء على Azure App Services أو Azure Functions أو Virtual Machines أو Container Instances أو Azure Kubernetes Service، فيجب أن يكون خيارك الأول دائمًا Managed Identity. يمكنك الاختيار بين System-Assigned Managed Identity (وهي هوية ترتبط دورة حياتها بمورد Azure بعلاقة 1:1) أو User-Assigned Managed Identity (وهي هوية يمكن إنشاؤها بشكل مستقل وتعيينها لعدة موارد Azure لتسهيل الإدارة).

أما إذا كان التطبيق يعمل خارج Azure، مثل الخوادم المحلية أو AWS أو كجزء من خط أنابيب CI/CD في GitHub Actions، فلا تتوفر الهويات المُدارة المستضافة مباشرةً في بنية Azure التحتية كخيار. في هذه الحالات، ينبغي لك الاستفادة من Workload Identity Federation. يتيح ذلك للمنصات الخارجية تبادل الرموز مباشرةً مع Microsoft Entra ID باستخدام ثقة OpenID Connect (OIDC)، مما يلغي تمامًا الحاجة إلى إدارة أسرار العميل طويلة الأمد أو تدويرها أو تخزينها.

وأخيرًا، بالنسبة للتطبيقات المؤسسية المخصصة التقليدية التي تتطلب مصادقة العميل حيث لا تكون الهويات المُدارة ولا الاتحاد خيارين ممكنين، ينبغي دائمًا تفضيل الشهادات المُدارة بعناية على أسرار العميل طويلة الأمد. وبالجمع بين Microsoft Entra Workload Identities وAzure Key Vault ومبادئ Zero Trust والوصول بمبدأ الحد الأدنى من الصلاحيات، يمكن لمؤسستك القضاء تمامًا على كلمات المرور المُضمَّنة في الكود وبناء بنية سحابية مرنة إلى حد كبير.

الخلاصة والخطوات التالية لأمان الحوسبة السحابية الحديثة

تُعدّ كلمات المرور المُضمَّنة في الكود وسلاسل الاتصال الثابتة من بقايا حقبة قديمة في أمن تقنية المعلومات. وباعتماد Microsoft Entra Workload Identities وAzure Managed Identities، يمكننا القضاء تمامًا على المخاطر المرتبطة ببيانات الاعتماد المضمّنة، وحماية مستودعات الكود المصدري من التسريب العرضي، وفرض الوصول الصارم بمبدأ الحد الأدنى من الصلاحيات عبر جميع تطبيقاتنا السحابية الأصلية. كما تضمن رموز الوصول قصيرة الأمد أنه حتى لو اعترض أحدهم رمزًا، فإن عمره أقصر من أن يسبب ضررًا دائمًا، مما يُحوّل وضعنا الأمني جذريًا من الدفاع التفاعلي إلى الحماية الاستباقية.

للتعمق أكثر في هذا الموضوع والاستماع إلى نصائح تطبيقية من الميدان، لا تفوّت الحلقة البودكاست ذات الصلة: Entra Workload Identities - Simply Explained. استمع إلينا ونحن نشرح هذه المفاهيم بمزيد من التفصيل لمساعدتك على تأمين بيئاتك في Azure وMicrosoft 365 كمحترف!