لماذا تُشكّل حسابات «svc-» لديك قنبلة موقوتة؟

By Mirko Peters · 2026-08-11

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

Titelbild: Why Your 'svc-' Accounts Are a Ticking Time Bomb

مرحبًا بكم مجددًا في البودكاست، ومع متابعتنا المستمرة لتحليل معمّق لبنية أمان المؤسسات. إذا كانت مؤسستكم كمعظم المؤسسات، فسيكشف لكم نظرة سريعة على Active Directory أو دليل Microsoft Entra ID عن مقبرة واسعة من الحسابات التي تبدأ بـ"svc-" أو "app-" أو "admin-bot". تُبقي هذه الحسابات الأنظمة تعمل، والبيانات تتدفق، وعمليات الأتمتة قيد التشغيل. لكنها في الوقت نفسه أكبر نقطة عمياء في وضعيتكم الأمنية الحديثة. في منشور المدونة هذا، نتوسع في حديثنا الأخير لنشرح لماذا تُقوّض حسابات الخدمة التقليدية بنية Zero Trust لديكم بالكامل، ولماذا يُعد الانتقال إلى Microsoft Entra Workload Identities المسار الوحيد للمضي قدمًا.

للاستماع إلى شرح صوتي كامل لهذا الموضوع، تأكدوا من الاستماع إلى حلقة البودكاست المصاحبة، Replace Service Accounts with Entra Workload Identities. والآن، لنتعمّق في آليات مخاطر الهويات غير البشرية وكيفية القضاء عليها نهائيًا.

الخلاصة السريعة

تُعد حسابات الخدمة ذات الأسرار الثابتة والصلاحيات الواسعة أكبر ثغرة في الهوية لديكم. تمنح Workload Identities (في Microsoft Entra ID) كل جهة غير بشرية هوية خاضعة للحوكمة، تتضمن أقل قدر من الصلاحيات، ودورة حياة، وسياسات Conditional Access، والتدوير، وسجلات تدقيق كاملة، دون تعطيل عمليات الأتمتة لديكم.

لماذا تفشل حسابات الخدمة (ولماذا تُخلّ بمبادئ Zero Trust)

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

أسرار ثابتة وغياب MFA ← سهلة السرقة، وصعبة التدوير بأمان
صلاحيات زائدة افتراضيًا ← تتحول أذونات «اجعله يعمل» إلى أذونات دائمة
غياب دورة الحياة ← الحسابات اليتيمة أو المنسية تبقى بعد الترحيلات وإعادة الهيكلة
ضعف قابلية التدقيق ← السؤال «من استخدم هذا الحساب ولماذا؟» يتطلب تخمينًا ولقطات شاشة
ثقافة الاستثناءات ← استثناءات CA/MFA للروبوتات توسّع سطح الهجوم لديكم بهدوء

Managed Identities: خطوة جيدة، لكنها مرتبطة بـ Azure

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

✅ وصول بلا أسرار للموارد الأصلية في Azure (Functions وVMs وLogic Apps)
❌ فجوات مع الأهداف الهجينة أو التابعة لجهات خارجية، وضعف في ربط الملكية، وعروض حوكمة محدودة
❌ تغطية CA/الاستحقاقات غير موحدة عبر الأسطح الخارجة عن Azure

Workload Identities: ما الذي تحصل عليه فعليًا

هنا تدخل Microsoft Entra Workload Identities المشهد. فبدلًا من معاملة الجهات غير البشرية كمواطنين من الدرجة الثانية، أو إجباركم على قيود Azure فقط، ترفع Workload Identities التطبيقات والنصوص البرمجية والخدمات الآلية إلى مرتبة أصحاب الهويات الأمنية من الدرجة الأولى.

هويات غير بشرية من الدرجة الأولى (التطبيقات والنصوص البرمجية والموصلات وRPA والتكاملات)
أذونات محدودة النطاق (أدوار Graph والموارد، والمصادقة للتطبيق فقط) مع أقل قدر من الصلاحيات
دورة حياة (المالك، وإيقاع المراجعة، وتدفق الإيقاف) مرتبطة بالعملية التجارية
Conditional Access للأحمال (بوابات تراعي المخاطر والسياق، وضوابط الجلسات حيثما تُدعم)
نظافة بيانات الاعتماد (أسرار قصيرة الأجل، وشهادات، وسياسة تدوير المفاتيح)
رؤية موحدة (عمليات تسجيل الدخول، والرموز، والوصول إلى الموارد، وسجل التغييرات) ← جاهزة للتدقيق

مصفوفة المقارنة (نظرة سريعة)

القدرة	حساب الخدمة	Managed Identity	Workload Identity
الأسرار	كلمات مرور ثابتة	بدون أسرار (Azure)	بدون أسرار أو قصيرة الأجل + تدوير
النطاق	واسع / شبيه بالمستخدم	محصور في Azure	أي حمل عمل (تطبيقات ونصوص برمجية وموصلات)
CA / المخاطر	نادرًا ما يُطبَّق	محدود	قائم على السياسات حيثما تُدعم
دورة الحياة	عشوائية	أساسية	مالك + مراجعات + إيقاف
التدقيق	ضعيف	سجلات Azure	سجل مركزي لتسجيل الدخول والاستحقاقات

أنماط المعمارية (حالات الاستخدام الشائعة)

يتطلب تنفيذ هويات أحمال العمل ربطها بشكل صحيح بأنماط بنيتك المعمارية. فيما يلي كيفية تطبيقها على أكثر أحمال العمل شيوعاً في المؤسسات:

موصلات Power Platform / التدفقات السحابية -> عيّن هوية حمل عمل لكل تكامل؛ امنح فقط نطاقات Graph/Dataverse اللازمة.
تطبيقات الأعمال (واجهات برمجة التطبيقات على الويب، والعمليات الخلفية) -> تسجيل التطبيق + شهادة؛ استخدم أدوار التطبيق وGraph للتطبيق فقط؛ فعّل سياسات الوصول المشروط حيثما ينطبق ذلك.
نصوص الأتمتة (Azure Automation وGitHub Actions وDevOps) -> استخدم بيانات الاعتماد الموحدة (OIDC)، دون تخزين أسرار.
مهام عبر المستأجرين / B2B -> هوية حمل عمل مخصصة لكل حدود للمستأجر؛ اعزل الصلاحيات والتسجيل.

دليل الترحيل (90 يوماً، بأقل قدر من التعقيد)

قد يبدو التعامل مع مئات حسابات الخدمة القديمة أمراً مرهقاً. لهذا السبب تحتاج إلى دليل ترحيل منظم يمتد على مدى 90 يوماً ويركز على تقليل المخاطر.

المرحلة 1 — الاكتشاف والفرز (الأسابيع 0–3)

اجرد عمليات تسجيل الدخول والكائنات غير البشرية: svc-* وapp-* وصناديق البريد المشتركة وتسجيلات التطبيقات والأسرار التي تنتهي خلال أقل من 90 يوماً.
اربط كل عنصر بـالمالك والغرض التجاري والأهداف والأذونات والاعتماد على حساب الطوارئ.
رتّب المخاطر: كلمات المرور الثابتة، والأدوار العامة، والعناصر دون مالك، والعناصر التي لم تُدوَّر مؤخراً.

المرحلة 2 — تحويل الحالات عالية الخطورة أولاً (الأسابيع 4–8)

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

المرحلة 3 — الإيقاف والحوكمة (الأسابيع 9–12)

عطّل حسابات الخدمة القديمة، وراقبها لمدة 14 يوماً، ثم احذفها.
فرض معايير الإنشاء: التسمية، والمالك، وتصنيف البيانات، وإيقاع المراجعة.
أضف التنبيهات: عمليات تسجيل الدخول الشاذة، والهويات غير النشطة لأكثر من 30 و60 و90 يوماً، والأسرار قرب الانتهاء.
ادمج فحوصات الهوية في CI/CD (السياسة ككود).

الوصول المشروط والأذونات (ضوابط عملية)

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

سياسات منفصلة للهويات البشرية مقابل هويات أحمال العمل؛ وامنع تسجيل الدخول التفاعلي لأحمال العمل.
المواقع المسماة / قيود الشبكة للوصول للتطبيق فقط حيثما كان ذلك ممكناً.
استحقاقات محددة بالوقت (PIM لأدوار التطبيق حيثما يتوفر، ومراجعات وصول مجدولة).
النطاقات: فضّل أدوار التطبيق أو الأدوار الخاصة بالمورد بدلاً من الصلاحيات على مستوى الدليل بأكمله.

التسجيل والتدقيق (ما يجب عرضه على المدقق)

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

المالك لحمل العمل أو التطبيق، والغرض، وحساسية البيانات
سجلات تسجيل الدخول (عمليات تسجيل دخول كيان الخدمة)، والجمهور المستهدف للرمز المميز، وعنوان IP، وتطبيق العميل
تعيينات الأدوار (من وافق، ومتى تم اعتماد ذلك)
سجل بيانات الاعتماد (النوع، وآخر تدوير، وتاريخ الانتهاء)
دورة الحياة: الإنشاء والتعديل والتعطيل والحذف مع تحديد الجهة المنفذة للتغيير

لوحة مؤشرات الأداء (إثبات التحسن)

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

نسبة الهويات غير البشرية التي لها مالك ومعدل مراجعة (الهدف ≥ 95%)
حسابات الخدمة اليتيمة (الهدف <- 0)
أسرار أقدم من 90 يوماً (الهدف <- 0؛ يُفضَّل الشهادات/البيانات الموحدة)
اتساع أدوار التطبيق فقط (عدد "Directory.ReadWrite.All" ← في تناقص)
نتائج التدقيق لوصول الجهات غير البشرية (انخفاض ↓ ربع سنوي)

أنماط مضادة يجب القضاء عليها

أثناء تنظيف بيئتك، تأكد من أن فرقك لا تعود إلى العادات القديمة. اقضِ على هذه الأنماط المضادة فوراً:

إعادة استخدام حساب خدمة عام واحد عبر أنظمة متعددة
تضمين كلمات المرور في السكربتات أو web.config أو Key Vault دون وجود نهج تدوير
منح Global Admin / Owner “احتياطاً” للحفاظ على استمرار المهام
استثناءات “مؤقتة” من Conditional Access لا تنتهي صلاحيتها أبداً

مكاسب سريعة (هذا الأسبوع)

لا تحتاج إلى انتظار بدء مشروع كبير لتحسين وضعك الأمني. إليك أربع مكاسب سريعة يمكنك تنفيذها هذا الأسبوع:

ضع وسم Owner وSystem وData Class على كل هوية غير بشرية.
انقل مهمة عالية المخاطر إلى federated credentials (من GitHub OIDC ‏-> Entra).
استبدل حساب خدمة مشتركاً في Power Automate بـworkload identity.
أنشئ تقريراً بمبادئ الخدمة ذات الأسرار المنتهية أو القاربة على الانتهاء، وجدول تنبيهات لها.

الأسئلة المتداولة (إجابات سريعة)

هل تتسبب هويات أحمال العمل في تعطل المهام القديمة المحلية؟
لا، بل صِل بينهما عبر مصادقة app-only أو الشهادات أو خدمات الوساطة، وأوقف كلمات المرور تدريجياً.

هل يمكنني فرض Conditional Access على عمليات تسجيل الدخول غير البشرية؟
نعم، للتدفقات المدعومة (تسجيلات دخول مبادئ الخدمة). استخدم إشارات الشبكة والموقع والجهاز حيثما أمكن، وامنع التفاعل المباشر.

كيف أتجنب تشتت الهويات؟
هوية حمل عمل واحدة لكل تكامل (وليس لكل فريق). فرض التسمية والمالك والمراجعات عند الإنشاء، وأتمتة التنظيف للهويات غير النشطة.

ماذا عن Power Platform؟
استخدم Service Principals / Workload Identities للموصلات وDataverse، وتوقف عن استخدام حسابات المستخدمين المشتركة.

الخاتمة

لا يمكنك التخلص من مخاطر حسابات الخدمة بمجرد تدوير كلمات المرور. تُدخل Entra Workload Identities الوصول غير البشري ضمن نموذج Zero Trust ودورة الحياة والتدقيق نفسه الذي تطلبه اليوم للبشر، دون انقطاعات أو جهود بطولية. ابدأ بحسابات “svc-” الأكثر خطورة، وحوّلها إلى هويات أحمال عمل خاضعة للحوكمة، واجعل الاستثناءات استثناءً مرة أخرى.

إذا أعجبك هذا المقال، فلا تفوّت النقاش الكامل في حلقتنا البودكاست Replace Service Accounts with Entra Workload Identities. اشترك في البرنامج لمزيد من التعمق في استراتيجيات أمان Microsoft 365 وAzure للمؤسسات!