الخطر الخفي للحسابات الظلية في أتمتة Microsoft 365

By Mirko Peters · 2026-08-26

مرحبًا بعودتكم إلى تعمّق جديد في بنية منظومة Microsoft 365 وأمانها وواقعها الإداري. إذا كنتم تديرون البنية التحتية السحابية …

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

مرحبًا بعودتكم إلى تعمّق جديد في بنية منظومة Microsoft 365 وأمانها وواقعها الإداري. إذا كنتم تديرون البنية التحتية السحابية، أو تبنون سير العمل، أو تشرفون على تقنية المعلومات في المؤسسات، فعلينا أن نتحدث عن قنبلة موقوتة مختبئة أمام أعيننا. في حلقتنا الأخيرة، Service Principal Security: Stop Using Personal Accounts، كشفنا عن ممارسة شائعة إلى حد أن كل مؤسسة تقريبًا وقعت فيها: ربط أتمتة المؤسسة الحرجة مباشرةً بحسابات المستخدمين البشريين. يبدأ الأمر كاختصار بريء. يحتاج أحد المهندسين إلى تشغيل تدفق Power Automate، أو ربط Logic App، أو مزامنة البيانات عبر واجهة برمجية، أو ضبط تحديث بيانات Power BI. ولتوفير الوقت، يصادق على الاتصال باستخدام بيانات اعتماده الإدارية الشخصية. يعمل الأمر فورًا، ويُطلق المشروع دون عوائق، ويمضي الجميع في شؤونهم. لكن ماذا يحدث حين ينتقل هذا المهندس إلى فريق آخر، أو يعيد تعيين كلمة المرور الخاصة به، أو يُفعّل نهج وصول مشروطًا جديدًا، أو يغادر الشركة نهائيًا؟ تتوقف الأتمتة، ويعمّ الصمت بيئة الإنتاج، وتكتشف المؤسسة أنها كانت تشغّل منطق أعمالها الأساسي بهوية مستعارة. تتوسع هذه التدوينة في هذه المفاهيم، وتشرح لماذا تُقوّض الحسابات الظلية مرونة بنيتك التحتية، وكيف يمكنك تحديث نهجك قبل أن تفرض عليك تغييرات المنصة خياراتها.

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

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

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

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

وعلاوة على ذلك، يتحول إنهاء خدمة الموظفين إلى كابوس إداري. فعندما يغادر موظف المؤسسة، يُعطَّل حسابه أو يُحذف في نهاية المطاف. وإذا كان ذلك الحساب يشغّل سراً تكاملات SharePoint الحرجة، أو مسارات التقارير الآلية، أو سير عمل إشعارات العملاء، فإن تلك الأنظمة ستنهار. وغالباً ما تكتشف فرق تقنية المعلومات هذه الاعتماديات المعطلة فقط بعد أن تكون العمليات التجارية قد تعطلت بالفعل. إن التعامل مع الحسابات البشرية كهويات بنية تحتية نمطٌ معماري مضاد يُدخل مخاطر تشغيلية غير مقبولة.

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

تآكل الهوية والتكلفة الخفية للاعتماد على الحسابات البشرية

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

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

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

لماذا تفرض Microsoft الانتقال بعيداً عن سير العمل القائم على المستخدمين

إذا لم تكن المخاطر التشغيلية للحسابات الظلية كافيةً لإقناع المؤسسات بالتغيير، فإن خارطة طريق المنصة كفيلة بذلك. تُغلق Microsoft بحزم الباب أمام أنماط المصادقة القديمة والأتمتة القائمة على المستخدمين. ومع اتجاهنا نحو نموذج الهوية لعام 2026، يقترب عصر الأتمتة من دون مبدأ الهوية للخدمة (Service Principal) من نهايته. فسير عمل SharePoint 2013 القديم يُسحب من الخدمة، وAzure AD Graph يُوقف نهائياً، وأصبحت المصادقة الحديثة للتطبيقات فقط (app-only) متطلباً صارماً عبر المنظومة كلها.

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

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

معاملة الهوية كبنية تحتية باستخدام مبادئ الخدمة (Service Principals)

للقضاء على الحسابات الظلية، يجب على المؤسسات تبني عقلية جديدة: الهوية بنية تحتية. فكما نتعامل مع الأجهزة الافتراضية وحسابات التخزين ومكونات الشبكات بوصفها أصولاً منفصلة في البنية التحتية، يجب أن نعامل هويات التطبيقات وأعباء العمل بالدقة نفسها تماماً. وهنا يأتي دور مبادئ الخدمة (Service Principals).

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

إن معاملة الهوية بوصفها أصلاً من أصول النشر تعني أنه عند نشر Logic App أو Function App أو تكامل مؤسسي، يتم توفير Service Principal المرتبط به ومنحه الأذونات وإدارته بوصفه شيفرة (as code). ويحسّن هذا النهج الأصيل للبنية التحتية المرونة بشكل ملحوظ، ويضمن مسارات تدقيق نظيفة، ويلغي الاعتمادات البشرية الهشة التي تسبب الأعطال الصامتة.

الهويات المُدارة (Managed Identities) وقوة المصادقة بلا أسرار (Zero-Secret Authentication)

بينما تحلّ Service Principals مشكلة الاعتماد على العنصر البشري، فإنها أدخلت تاريخيًا تحديًا جديدًا يتمثل في إدارة الأسرار. فقد أدى تخزين الأسرار الخاصة بالعميل والشهادات وكلمات المرور داخل ملفات الإعدادات ومتغيرات البيئة أو Key Vaults إلى بقاء المؤسسات عرضةً لانتشار الأسرار وتسرّب بيانات الاعتماد. ولحسن الحظ، تجاوزت بنية السحابة الاعتماد على بيانات الاعتماد الثابتة بظهور Managed Identities.

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

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

إلغاء الأسرار الثابتة باستخدام Federated Credentials

بينما تُعد Managed Identities مثالية لأعباء العمل التي تعمل داخل Azure بشكل أصيل، تعتمد كثير من خطوط الأتمتة في المؤسسات على أنظمة CI/CD خارجية، أو بيئات متعددة السحب، أو أدوات المطورين مثل GitHub Actions. وفي هذه السيناريوهات، غالبًا ما تلجأ سير العمل التقليدية إلى إنشاء أسرار عميل طويلة الأجل وتخزينها في مستودعات خارجية، وهي ممارسة تُنشئ ثغرات أمنية كبيرة—

هنا يأتي دور Federated Credentials وOpenID Connect (OIDC). تتيح الهوية الموحّدة لأعباء العمل الخارجية إقامة علاقة مؤقتة قائمة على الثقة مع Microsoft Entra ID دون الحاجة إلى أي بيانات اعتماد مخزّنة بشكل دائم. فبدلًا من استخدام كلمة مرور دائمة، يطلب خط الأنابيب الخارجي رمزًا مباشرةً من مزوّده الأصلي، ثم يقدّم ذلك الرمز الموقّع تشفيريًا إلى Entra ID، ويتلقى في المقابل رمز وصول قصير الأجل.

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

الحدّ من أزمة توسّع الأذونات في بنية السحابة الحديثة

مع نجاح المؤسسات في الانتقال إلى Service Principals وManaged Identities وFederated Credentials، يبرز خطر معماري جديد هو توسّع الأذونات (Permission Creep). فالهوية المرنة والفعّالة التي تمتلك أذونات مفرطة تتحول إلى سلاح خطير إذا تعرّضت للاختراق. وغالبًا ما يمنح المهندسون نطاقات Graph API واسعة أكثر من اللازم، مثل `Application.ReadWrite.All` أو `Directory.ReadWrite.All`، ببساطة للتخلص من عوائق النشر وتجنّب استكشاف أخطاء الأذونات أثناء الإعداد الأولي.

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

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

الخاتمة

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

إذا كنت ترغب في التعمق أكثر في هذه المفاهيم، والاستماع إلى استراتيجيات واقعية لتأمين بيئات الأتمتة لديك، فتأكد من الاستماع إلى حلقتنا المخصصة بعنوان Service Principal Security: Stop Using Personal Accounts. تتضمن الحلقة رؤى عملية ستساعدك على تدقيق بنيتك الحالية، والقضاء على الحسابات الظلية، وتحصين مستأجر Microsoft 365 الخاص بك في مواجهة أزمة الهوية الوشيكة.