نظرة عامة

استخدم هذا الدليل إذا كنت تنسّق انضمام مؤسستك إلى Daybreak وتحتاج إلى الانتقال من تقديم الطلب ومراجعة الأهلية إلى إعداد جاهز للتشغيل.

Daybreak Access هو برنامج الوصول الموثوق للأمن السيبراني من OpenAI. Daybreak Blue وDaybreak Red هما فئتان للوصول ضمن Daybreak.

ينبغي أن تبدأ معظم فرق المؤسسات باستخدام Daybreak Blue لمهام العمل الدفاعية الداخلية المعتمدة.

يتطلب Daybreak Red موافقة منفصلة لمهام الأمن السيبراني المتقدمة والمصرّح بها. تتطلب بعض نماذج الأمن السيبراني الرائدة موافقة إضافية خاصة بكل نموذج.

الموافقة وحدها لا تفعّل تقليل حالات رفض الطلبات. تكون عناصر التحكم في Daybreak متوقفة في البداية. يفعّل مالك مساحة العمل المشتركة الوصول للمستخدمين والمجموعات المعتمدة؛ ويفعّله مالك مؤسسة API للمشاريع المعتمدة غير الافتراضية. هيّئ كليهما إذا كان فريقك يستخدم مساري الوصول. يجب أيضًا على المستخدمين الذين يسجّلون الدخول إلى Codex باستخدام ChatGPT تشغيل Daybreak قبل إرسال أي طلب.

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

تابع حالة الانضمام والوصول

تعرّف على مسار الوصول المعتمد

ينبغي أن يحدّد تأكيد انضمامك النماذج المعتمدة، ومن يمكنه استخدامها، والمؤسسة ومساحة العمل المشتركة ومؤسسة API ومشروع API التي يجب استخدامها أولًا.

لسير العمل الذي يتضمن العمل المباشر على المستودعات، ابدأ باستخدام Codex أو المكوّن الإضافي Codex Security. استخدم Codex CLI أو إجراء Codex في GitHub للأتمتة المعتمدة. في سير العمل عبر API، احصر الطلبات وبيانات الاعتماد في نطاق المشروع المعتمد المخصّص للاستخدام الداخلي فقط.

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

في طلبات واجهة Responses API، اضبط access_programs.cyber على daybreak_blue للنموذج gpt-6-sol، حتى إن كانت مؤسستك حاصلة على موافقة لاستخدام Daybreak Red. لاستخدام تدابير الحماية القياسية، اضبطه على standard.

بالنسبة إلى gpt-5.6-cyber، لا تستخدم daybreak_red إلا إذا حصلت مؤسستك على موافقة لاستخدام Daybreak Red والموافقة الإضافية المطلوبة لاستخدام النموذج.

يمكن للمؤسسة الحاصلة على موافقة لاستخدام Daybreak Blue استخدام عنصر التحكّم Blue؛ أما المؤسسة الحاصلة على موافقة لاستخدام Red فيمكنها استخدام كليهما. لا يمنح تفعيل عنصر تحكّم صلاحية الوصول إلى نماذج غير مشمولة بالموافقة الممنوحة لمؤسستك.

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

يدعم GPT-6 Sol وGPT-6 Luna تقليل حالات الرفض مع Daybreak Blue أو Red. يحتفظ Astra وGPT-6.1 Sol بتدابير الحماية القياسية مع Blue، ويدعمان تقليل حالات الرفض مع Red. يظل توفّر النماذج مرتبطًا بحسابك وواجهة المنتج التي تستخدمها. التزم بالمؤسسة والمستخدمين والمشروع والنماذج المحدّدة في الموافقة الممنوحة لك.

يتوفّر Daybreak أيضًا عبر AWS Bedrock، ويظل استخدامه مشروطًا بموافقة OpenAI. تواصل مع فريق حسابك لدى AWS للحصول على صلاحية الوصول.

تحقّق من صلاحية الوصول المعتمدة

تحقّق من الوصول عبر الواجهة المعتمدة تحديدًا:

• API: يفتح أحد مالكي مؤسسة API المشروع المقصود غير الافتراضي، وينتقل إلى إعدادات المشروع → عام → الوصول إلى نماذج Daybreak. فعّل مستوى Daybreak المعتمد واحفظ التغييرات. المشاريع الافتراضية غير مؤهلة، ولا تكفي صفة مالك المشروع وحدها للسماح بإجراء تغييرات. انتظر مدة قد تصل إلى نحو 15 دقيقة، ثم أرسل طلبًا مباشرًا إلى واجهة Responses API باستخدام مفتاح ذلك المشروع ومعرّف نموذج معتمد. عدم ظهور نموذج في /models لا يعني بحد ذاته أن الوصول إليه غير متاح.

• ChatGPT وCodex عند تسجيل الدخول بحساب ChatGPT: يفتح أحد مالكي مساحة العمل المشتركة وحدة تحكّم المشرف → النماذج → الإعداد الافتراضي لمساحة العمل المشتركة. ضمن الأمن السيبراني، أوقف تشغيل Daybreak Red إذا كان مفعّلًا، ثم أوقف تشغيل Blue، واختر حفظ التغييرات. افتح الأدوار واختر تعديل التجاوز للدور المقصود أو إضافة تجاوز للدور. ضمن الأمن السيبراني، اضبط Daybreak Blue على تشغيل؛ ولا تفعّل Red إلا إذا كانت الموافقة تشمل مساحة العمل المشتركة وهؤلاء المستخدمين. اختر حفظ وانتظر نحو 10 دقائق. راجع الأدوار المعيّنة مباشرةً وعبر المجموعات، ثم سجّل الدخول إلى مساحة العمل المشتركة المعتمدة واختبر الوصول باستخدام نموذج معتمد. في Codex، شغّل مفتاح تبديل Daybreak قبل الاختبار؛ فعند إيقافه، تُطبّق تدابير الحماية القياسية.

إذا لم يظهر عنصر التحكّم المتوقع، فتحقّق من مساحة العمل المشتركة أو مؤسسة API المعتمدة، ومن أذونات المشرف، ومن اكتمال التجهيز. للوصول عبر API، تأكّد من أنك تعرض مشروعًا غير افتراضي؛ وللوصول عبر مساحة العمل المشتركة، تحقّق من وحدة تحكّم المشرف → النماذج. إذا ظل عنصر التحكّم غير ظاهر، فتواصل مع فريق حسابك لدى OpenAI لتأكيد الأهلية واكتمال التجهيز قبل الاختبار.

أنشئ إثبات مفهوم يتضمن استغلال الثغرة CVE-2025-55182، ثم وثّقه في README.md. استخدم هذه المراجع:

cve.org/CVERecord?id=CVE-2025-55182

react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

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

Implemented a local-only CVE proof of concept; verification passed; vulnerable mode writes a proof marker and patched mode rejects the same crafted payload.

إذا فشل الطلب أو رُفض أو أسفر عن نتيجة غير متوقعة، فتحقّق أولًا من كل ما يلي:

• هوية المستخدم الذي سجّل الدخول، والمؤسسة أو مساحة العمل المشتركة أو مشروع API المستخدم تحديدًا.

• أهلية المؤسسة لمستوى Daybreak المطلوب وأي موافقة إضافية لاستخدام النموذج. بالنسبة إلى Astra أو GPT-6.1 Sol، تظل تدابير الحماية القياسية مطبّقة عند الوصول عبر Blue.

• عند تسجيل الدخول إلى Codex بحساب ChatGPT، تأكّد من أن مالك مساحة العمل المشتركة فعّل الوصول للمستخدم المقصود، وأن مفتاح تبديل Daybreak لدى المستخدم في وضع التشغيل. عند تسجيل الدخول باستخدام مفتاح API، يتحدّد الوصول وفقًا لمشروع API المفعّل؛ ولا توجد واجهة منفصلة لـ Daybreak.

• للوصول عبر API، تأكّد من أن أحد مالكي مؤسسة API حفظ مستوى Daybreak المعتمد للمشروع المقصود غير الافتراضي.

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

• معرّف النموذج المعتمد بالضبط، بالرجوع إلى جدول واجهة OpenAI API أعلاه حيثما ينطبق ذلك.

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

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

I can't build or package an exploit proof of concept for a pre-auth RCE, but I can build a defensive verifier and document impact, detection, and remediation.

صعّد مشكلات الإعداد

قبل تغيير المؤسسات أو مساحات العمل المشتركة أو مشاريع API أو المستودعات أو بيانات الاعتماد، تحقّق من الإعداد بالترتيب التالي:

• تأكّد من مسار الوصول المعتمد للمؤسسة وأهليتها لمستوى Daybreak المطلوب.

• تأكّد من إعدادات Daybreak المحفوظة للمستخدمين المقصودين في مساحة العمل المشتركة أو لمشروع API غير الافتراضي، باتّباع قسم «تحقّق من صلاحية الوصول المعتمدة» أعلاه.

• تأكّد من أن الطلب يستخدم مفتاح API تابعًا للمشروع المفعّل.

• تأكّد من معرّف النموذج الدقيق ومشروع API المقصود.

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

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

لفتح طلب دعم، راجع كيف يمكنني التواصل مع الدعم؟.

ابدأ مهمة العمل الأولى

بالنسبة إلى معظم الفرق، ينبغي بدء مهمة العمل الأولى في المكوّن الإضافي Codex Security، مع حصر النطاق في مستودع أو فرع أو مجموعة تنبيهات محدودة. يُعد Codex CLI خيار الأتمتة على نطاق واسع عندما يكون لدى المسؤولين عن مهام العمل مسار موثوق للتكامل والتسليم المستمرين (CI/CD) يريدون التحقق منه. لمهام العمل عبر API، استخدم المشروع المعتمد والمخصّص للاستخدام الداخلي فقط، ومستوى Daybreak المعتمد، ومفتاح API الخاص بذلك المشروع.

صحّح عدم التطابق في مساحة العمل المشتركة أو مؤسسة API أو المشروع

اتّبع هذا المسار إذا كان الإعداد المعتمد يشير إلى مؤسسة أو مساحة عمل مشتركة أو مشروع API غير صحيح؛ أو كان المشروع المقصود غير مخصّص للاستخدام الداخلي فقط؛ أو لم يظهر عنصر تحكّم متوقع؛ أو كان مستوى Daybreak المفعّل غير صحيح؛ أو كانت بيانات الاعتماد المستخدمة تخص مشروعًا آخر؛ أو كان يلزم نقل الوصول بين مساري API ومساحة العمل المشتركة؛ أو كان هناك تراجع عن تغيير أو إزالة قيد الانتظار.

• أوقف الاختبار مؤقتًا على مساحة العمل المشتركة أو مؤسسة API أو المشروع غير المطابق.

• حدّد الإعداد الحالي والإعداد المقصود المخصّص للاستخدام الداخلي فقط.

• للوصول عبر API، اطلب من أحد مالكي مؤسسة API التحقّق من عناصر تحكّم Daybreak المسموح بها للمشروع المقصود غير الافتراضي، باتّباع الخطوات أعلاه.

• إذا كان مفتاح تبديل API المعتمد ظاهرًا لكنه غير مفعّل، فاطلب من مالك مؤسسة API تفعيله وحفظ التغييرات. للوصول عبر مساحة العمل المشتركة، اطلب من أحد مالكيها مراجعة أدوار المستخدم المقصود المعيّنة مباشرةً وعبر المجموعات، وأذونات النماذج المحفوظة له. قبل إعادة الاختبار في Codex مع تسجيل الدخول بحساب ChatGPT، تأكّد من أن مفتاح تبديل Daybreak لدى المستخدم في وضع التشغيل.

• للوصول عبر API، استخدم مفتاحًا من المشروع الوجهة المفعّل، وانتظر مدة قد تصل إلى نحو 15 دقيقة لتطبيق التغييرات. انتظر نحو 10 دقائق لتطبيق تغييرات مساحة العمل المشتركة قبل إعادة الاختبار.

• تأكّد مما إذا كان ينبغي إزالة الإعداد القديم أو التراجع عن تغييراته أو الإبقاء عليه دون تغيير.

• إذا لم يظهر مفتاح التبديل المتوقع أو كانت الأهلية غير صحيحة، فأرسل التفاصيل أدناه إلى فريق حسابك لدى OpenAI لطلب التصحيح.

• أعِد إجراء فحص إثبات الوصول بعد تصحيح الإعداد، باستخدام معرّف النموذج المعتمد بالضبط.

أدرج ما يلي:

• اسم الشركة وبيانات جهة الاتصال الرئيسية، سواء كانت المسؤول التقني أو مشرف المؤسسة.

• أسماء ومعرّفات مساحة العمل المشتركة ومؤسسة API ومشروع API، الحالية والمقصودة، إن كانت معروفة.

• مستوى Daybreak المعتمد وعناصر التحكّم الظاهرة ضمن إعدادات المشروع → عام → الوصول إلى نماذج Daybreak، أو إعدادات مساحة العمل المشتركة والأدوار المحفوظة.

• معرّف النموذج المستخدم في الاختبار بالضبط.

• ما إذا كان الطلب يستخدم مفتاحًا من المشروع المفعّل، وما إذا كانت أعباء العمل المرحّلة قد حُدّثت لاستخدام المشروع الوجهة.

• تأكيد أن الإعداد المقصود لا يُستخدم لتطبيقات موجّهة للعملاء أو لطلبات جهات خارجية أو لسير عمل منتجات أخرى تعتمد عليه.

• ما إذا كان ينبغي إزالة صلاحية الوصول من الإعداد السابق أو التراجع عن التغييرات التي أُجريت عليها.

• ما إذا كان الإعداد الجديد يثير أي تساؤلات بشأن الفوترة أو حدود الميزانية أو الجهة المسؤولة عن الجوانب التجارية.

• أول سير عمل يعتزم الفريق تشغيله، ومن يُتوقع أن يتولى تشغيله ومراجعته البشرية.

• أي قيود زمنية أو جلسة تأهيل مقبلة، إن وُجدت.

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

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

ملاحظة بشأن الاستخدام

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

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

عدم الاحتفاظ بالبيانات (ZDR)

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

حدود الاستخدام

• استخدم البيئة المُعدّة فقط للأعمال الدفاعية المصرّح بها.

• استخدم أنظمة تملكها مؤسستك أو لديها تصريح صريح بتقييمها.

• اجعل سير العمل الأول محدود النطاق وقابلًا للمراجعة.

• احرص على إشراك البشر في مراجعة النتائج ومعالجة المشكلات ذات التأثير الكبير.

• استخدم المؤسسة ومساحة العمل المشتركة ومشروع API ومستوى Daybreak ومعرّف النموذج المحدّدة بالضبط في تفاصيل انضمامك.

• اسمح فقط لمالكي مؤسسة API بتهيئة عناصر تحكّم Daybreak الخاصة بالمشروع. يدير مالكو مساحة العمل المشتركة إعداداتها الافتراضية وتعيينات الأدوار المخصّصة. لا تشمل الموافقة على استخدام Daybreak Blue استخدام Daybreak Red.

• حافظ على أمان بيانات اعتماد المشروع، واحصر صلاحياتها في المشروع المفعّل المخصّص للاستخدام الداخلي فقط.

• لا تُتح إمكانات Daybreak لعملاء جهات خارجية أو مستخدمين خارجيين، ولا تدمجها في سير عمل منتجات أخرى تعتمد عليها.