تُرجمت هذه الصفحة وتم التحقق منها آليًا. النسخة الإنجليزية هي المرجع. بعض الأجزاء لا تزال بالإنجليزية ريثما يتم التحقق من ترجمتها. عرض بالإنجليزية · الإبلاغ عن خطأ في الترجمة

DeepDive › الأمن

انتشار الهوية عبر الأنظمة

أُلغي تزويده في Azure AD. ولا يزال نشطًا في نسخة Jira التي لم يُضفها أحد إلى الموصّل.

الأمن قراءة في 6 دقائق · 7 أغسطس 2026

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

ما مخاطر نشر الهوية عبر الأنظمة حقًا؟

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

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

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

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

لماذا يهم هذا

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

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

أين تخطئ معظم الفرق

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

  • اعتبار أتمتة IGA شاملة دون التحقق من قائمة الموصلات
  • لا مطابقة لقائمة التطبيقات مع قائمة موصلات IGA
  • نشر التطبيقات الجديدة لا يستدعي تسجيلها في IGA
  • عدم إجراء اكتشاف لتطبيقات الظل
  • التحقق من الوصول بعد المغادرة لا يشمل الأنظمة غير المُدارة عبر IGA

كيف تبدو الممارسة الجيدة

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

  • نشر التطبيقات الجديدة يستدعي تسجيلها في IGA: إجراء يشترط الإضافة إلى IGA قبل اكتمال نشر التطبيق
  • مطابقة دورية لقائمة الموصلات: مقارنة نطاق IGA بقائمة التطبيقات الحالية
  • اكتشاف تطبيقات الظل: فحص التطبيقات غير الواردة في قائمة موصلات IGA
  • التحقق من الوصول بعد المغادرة: تأكيد أن إلغاء الصلاحيات شمل جميع الأنظمة، بما فيها التطبيقات غير المُدارة عبر IGA
  • قائمة التطبيقات بوصفها أداة حوكمة: قائمة محدَّثة بجميع التطبيقات مع حالة اتصالها بـIGA

الأدوات

اكتشاف تطبيقات SaaS: Grip Security، وNudge Security، وBetterCloud

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

IGA مع اكتشاف التطبيقات: SailPoint، وSaviynt

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

تحديات الحوكمة

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

  • اشترط التسجيل في IGA قبل نشر أي تطبيق جديد: بوابة حوكمة في إجراء النشر
  • طبّق اكتشاف تطبيقات SaaS لرصد تطبيقات الظل
  • مطابقة دورية لقائمة الموصلات مع قائمة التطبيقات الحالية
  • التحقق من الوصول بعد المغادرة بما يشمل الأنظمة غير المُدارة عبر IGA
  • أدرج اكتمال النشر في تقييم حوكمة الوصول

إذا كنت فريقًا صغيرًا

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

  • اطلب من المورّدين عند كل مغادرة تأكيد أن إلغاء الصلاحيات شمل جميع الأنظمة، بما فيها التطبيقات غير المُدارة عبر IGA
  • اسأل عمّا إذا كان لدى المورّد إجراء لتحديد التطبيقات غير المشمولة في نطاق IGA لديه
  • اسأل كم مرة تُطابَق قائمة موصلات IGA مع قائمة التطبيقات الفعلية
  • اسأل عمّا إذا كان نشر تطبيق جديد يستدعي تسجيله في IGA

ما الذي ينبغي اشتراطه

اسأل مباشرةً:

«عندما تلغون صلاحيات موظف كان لديه حق الوصول إلى بيئتنا، هل يشمل ذلك جميع الأنظمة التي كان يصل إليها، بما فيها الأدوات الخاصة بالمشاريع ومنصات التعاون مع العملاء والتطبيقات التي نشرتها الفرق ولا تُدار عبر IGA المركزية لديكم؟»

«كم مرة تُطابَق قائمة موصلات IGA لديكم مع قائمة التطبيقات الفعلية لتحديد الأنظمة التي يملك فيها المستخدمون حسابات لا تُدار عبر إجراء دورة الحياة في IGA؟»

ما تتوقعه دليلًا

  • قائمة موصلات IGA مع تاريخ آخر مطابقة
  • قدرة أو إجراء لاكتشاف تطبيقات الظل
  • إجراء للتحقق من الوصول بعد المغادرة يشمل الأنظمة غير المُدارة عبر IGA
  • إجراء تسجيل التطبيقات الجديدة في IGA عند نشرها

ينبغي سؤال المورّد الذي يؤكد أتمتة إلغاء الصلاحيات عبر IGA تحديدًا عمّا إذا كانت تلك الأتمتة تشمل التطبيقات المنشورة لأغراض مشاريع محددة والتي قد لا تكون في قائمة موصلات IGA. فالأتمتة تغطي ما تعرفه IGA. والسؤال هو ما لا تعرفه IGA.

كيف تُثبت ذلك

  • سجلات مطابقة قائمة موصلات IGA
  • سجلات اكتشاف تطبيقات الظل
  • التحقق من الوصول بعد المغادرة بما يشمل الأنظمة غير المُدارة عبر IGA
  • إجراء تسجيل التطبيقات الجديدة في IGA عند نشرها

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

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

مكتبة التشريعات

جميع قوانين الخصوصية في الولايات الأمريكية على خريطة واحدة

لدى 24 ولاية قانون شامل للخصوصية في المكتبة، إلى جانب قوانين الاتحاد الأوروبي والمملكة المتحدة والقوانين الاتحادية الأمريكية والقوانين العالمية: 102 قانونًا إجمالًا، كل منها مشروح بلغة واضحة مع مصادره. اختر ولاية لمعرفة ما يسري فيها.

  • ساري
  • يدخل حيز التنفيذ
  • القوانين القطاعية
AK ME VT NH WA ID MT ND MN IL WI MI NY RI MA OR NV WY SD IA IN OH PA NJ CT CA UT CO NE MO KY WV VA MD DE AZ NM KS AR TN NC SC DC OK LA MS AL GA HI TX FL