Okta Shared Signals Framework

إشارات انكشاف بيانات متحقق منها لاتخاذ قرارات بشأن مخاطر الهوية

يمكن لـ LeakData إرسال حدث user-risk-change موقّع عند اكتشاف خرق بيانات جديد متحقق منه وعالي الخطورة يؤثر على عنوان بريد إلكتروني محدد تم التحقق من ملكيته في حسابك أو ينتمي إلى أحد نطاقاتك المتحقق منها.

الحالة
مدرج في Okta Integration Network باسم LeakData Shared Signals.
الوصول إلى LeakData
خطة Enterprise مع إمكانية الوصول إلى تكامل SIEM.
المزوّد
مسؤول Okta ودعم استقبال SSF وميزات سياسات المخاطر المطلوبة.
الإعداد في LeakDataاقرأ دليل الإعداد

مدرج في Okta Integration Network

النطاق وحدود البيانات

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

ما يُرسل

  • عنوان البريد الإلكتروني المحدد المعني بالإشارة، الذي تم التحقق من ملكيته أو ينتمي إلى أحد نطاقاتك المتحقق منها
  • مستوى عالٍ لحدث user-risk-change
  • وقت الحدث والجهة المصدرة والجهة المستهدفة ومعرّف فريد للرمز
  • سبب عام مع عدد النتائج الأمنية المستوفية للشروط

ما لا يُرسل

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

كيف تنتقل الإشارة

  1. 01

    عنصر مراقبة متحقق منه

    لا يتأهل إلا عنصر مراقبة بريد إلكتروني شخصي نشط، وفقط إذا تم التحقق من ملكية عنوانه أو كان ينتمي إلى أحد نطاقاتك المتحقق منها (بما فيها النطاقات الفرعية).

  2. 02

    نتيجة أمنية مستوفية للشروط

    يجب أن يكون المصدر موسومًا بأنه متحقق منه وأن يستوفي حد الخطورة المحدد، سواء كان عاليًا أو حرجًا.

  3. 03

    SET موقّع

    يوقّع LeakData رمز Security Event Token بأقل قدر من البيانات باستخدام RS256 ويرسله إلى مؤسسة العميل في Okta.

  4. 04

    سياسة العميل

    تسجل Okta حدث المزوّد وتطبّق فقط سياسات Identity Threat Protection التي أعدّها العميل.

إعداد LeakData Shared Signals

استخدم هذا الدليل لتثبيت تكامل خدمة API الخاص بـ LeakData في OIN وربطه والتحقق منه وصيانته. يمكنك قراءة جميع الخطوات دون تسجيل الدخول.

قبل البدء

  • صلاحيات مالك حساب LeakData مع إمكانية الوصول إلى تكامل SIEM ضمن اشتراك Enterprise. لا يمكن لحسابات المستخدمين ضمن مقاعد الاشتراك إعداد الاتصال.
  • مسؤول Okta لديه صلاحية تثبيت تكاملات خدمة API وتفويضها، ومؤسسة تدعم استقبال Shared Signals. يلزم توفر Identity Threat Protection لاستخدام ميزات سياسات المخاطر ذات الصلة.
  • عنوان بريد إلكتروني شخصي تتم مراقبته بشكل نشط، وقد تم التحقق من ملكيته أو ينتمي إلى أحد نطاقاتك التي تم التحقق منها. لاختبار إشارة موقّعة، استخدم حساب مستخدم تجريبي تتحكم فيه وله عنوان البريد الإلكتروني نفسه في مؤسسة Okta مخصصة للاختبار.

1. التثبيت والتفويض في Okta

الإدراج في الكتالوج العام قيد الانتظار. إذا لم يكن LeakData متاحًا في الكتالوج لديك، فتواصل مع الدعم لمعرفة مسار الإعداد الحالي قبل المتابعة.

  1. افتح التطبيقات والموارد > تكاملات خدمة API في وحدة تحكم إدارة Okta، وثبّت LeakData Shared Signals عندما يتوفر في الكتالوج لديك.
  2. فوّض okta.securityEventsProviders.manage فقط. انسخ سر العميل الذي يُعرض مرة واحدة فورًا، ثم سجّل معرّف العميل ونطاق Okta من المثيل نفسه.
  3. استخدم عنوان الأصل غير المخصص للمؤسسة، مثل https://integrator-1234567.okta.com. أزل -admin والمسارات وسلاسل الاستعلام وأرقام المنافذ.
لمراجعي OIN فقط

أثناء مراجعة OIN، افتح تكاملات OIN الخاصة بك > LeakData Shared Signals > اختبار التكامل > إنشاء مثيل للإصدار الحالي المقدّم للمراجعة. اختر «التثبيت والتفويض».

تأتي بيانات الاعتماد هذه من تكامل خدمة API مثبّت من OIN. لا يوفّر رمز API أو تطبيق خدمة OAuth عام أُنشئ عبر «إنشاء تكامل تطبيق» إعداد معرّف العميل وسر العميل نفسه الخاص بـ OIN.

2. الربط في LeakData

  1. سجّل الدخول بصفتك مالك الحساب، وافتح لوحة التحكم > التكاملات > Okta Shared Signals.
  2. أدخل عنوان URL للمؤسسة ومعرّف العميل وسر العميل من المثيل المفوّض نفسه. اختر «عالية وحرجة» أو «حرجة فقط».
  3. اطّلع على قيد الاقتصار على العناوين التي تم التحقق منها وعلى تأثير سياسات المخاطر لديك في Okta، وأكّد إقرارك بهما، ثم اختر «ربط Okta». يتحقق LeakData من بيانات الاعتماد وينشئ مزوّد أحداث الأمان الخاص به أو يعيد استخدامه.
  4. بعد الإعداد، يكون المزوّد نشطًا. يشفّر LeakData السر ولا يعرضه مجددًا.
فتح لوحة اتصال Okta

3. التحقق من الاتصال

  1. اختر «التحقق من الاتصال» للتحقق من بيانات الاعتماد وحالة المزوّد دون إرسال إشارة مخاطر. تأكد من أن المزوّد نشط وأن معرّف المزوّد موجود في «تفاصيل الاتصال».
  2. راجع عناوين البريد الإلكتروني المؤهلة التي تتم مراقبتها. لا تتأهل إلا عناوين البريد الإلكتروني المحددة التي تم التحقق من ملكيتها أو التي تنتمي إلى أحد نطاقاتك التي تم التحقق منها؛ ولا يُرسل النطاق الخاضع للمراقبة نفسه مطلقًا.
  3. في حساب مخصص للاختبار وضمان الجودة ومؤسسة Okta Integrator خاضعة للتحكم، راجع البريد الإلكتروني التجريبي والإقرار بالسياسات قبل استخدام «اختبار إشارة موقّعة». قد يؤدي هذا الاختبار إلى تفعيل سياسات المخاطر التي تم إعدادها.
  4. يؤكد HTTP 202 القبول فقط. راجع سجل نظام Okta بحثًا عن security.events.provider.receive_event وuser.risk.detect للمستخدم التجريبي. قد يتم تجاهل عنوان بريد إلكتروني غير معروف دون إشعار.

4. استبدال بيانات الاعتماد أو تغيير المؤسسة

  1. للمؤسسة نفسها، اختر «استبدال بيانات الاعتماد» وأدخل زوجًا جديدًا من معرّف العميل وسر العميل من مثيل مفوّض لخدمة API الخاصة بـ LeakData في تلك المؤسسة. يؤدي الحفظ إلى التحقق من الاتصال وتفعيله.
  2. يُبقي «إيقاف التسليم مؤقتًا» الارتباط بالمؤسسة وبيانات الاعتماد المحفوظة. ولا يهيئ الحساب للربط بمؤسسة أخرى.
  3. لاستئناف التسليم إلى المؤسسة نفسها، اختر «بدء التسليم»، ثم «التحقق من الاتصال»، وتأكد من أن المزوّد نشط.
  4. لاستخدام مؤسسة مختلفة، راجع «إزالة الاتصال» أولًا. يؤدي تأكيد الإزالة إلى حذف المزوّد وبيانات الاعتماد المشفّرة وسجل التسليم المحلي. ثم أعدّ المؤسسة الجديدة. إذا فشلت الإزالة، فتواصل مع الدعم؛ ولا تفترض أن المزوّد القديم قد أُزيل.

استكشاف الأخطاء وإصلاحها

تم رفض بيانات الاعتماد
تأكد من أن القيم الثلاث جميعها مأخوذة من مثيل خدمة API نفسه المثبّت والمفوّض من OIN. أثناء المراجعة، استخدم مثيلًا للإصدار الحالي المقدّم للمراجعة. لا يمكن استخدام رموز API وبيانات اعتماد تطبيقات خدمة OAuth العامة بدلًا من بيانات الاعتماد الخاصة بهذا الإعداد.
تم رفض الصلاحية أو الوصول إلى المستقبِل
تأكد من تفويض okta.securityEventsProviders.manage ومن أن مؤسستك في Okta تدعم مستقبِل SSF. راجع صلاحيات المسؤول وسياسات المؤسسة.
متصل بمؤسسة أخرى بالفعل
استبدل بيانات الاعتماد للمؤسسة المعروضة فقط. لا يؤدي الإيقاف المؤقت إلى إزالة الاتصال. راجع خطوات الإزالة أعلاه قبل تغيير المؤسسة.
لا توجد إشارة أو حدث مخاطر للمستخدم
تأكد من أن العنوان قد تم التحقق من ملكيته أو ينتمي إلى نطاق تم التحقق منه، وأن مراقبة البريد الإلكتروني الشخصي نشطة، وأن النتيجة الأمنية متحقق منها وذات خطورة عالية أو حرجة، وراجع حد الخطورة المحدد. قبول المستقبِل وحده لا يثبت مطابقة المستخدم أو تنفيذ إجراء بموجب السياسات.

هل تحتاج إلى مساعدة؟

تواصل مع دعم LeakData مع ذكر العملية التي فشلت ورمز الخطأ. لا تُضمّن كلمات مرور أو أسرار العميل أو رموز الوصول.

التواصل مع الدعممرجع تكامل خدمة API في Okta

تحقق من النتيجة في Okta

تؤكد استجابة القبول HTTP 202 قبول الجهة المستقبلة، ولا تؤكد مطابقة مستخدم في Okta أو تنفيذ إجراء معين بموجب سياسة. ينبغي للمسؤولين التحقق من أحداث System Log وسلوك السياسات في مؤسسة الاختبار الخاصة بهم.