نظرة عامة

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

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

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

يتطلب Daybreak Red موافقة منفصلة لمهام سير العمل المتقدمة والمصرّح بها في مجال الأمن السيبراني. جميع مؤسسات Daybreak Red مؤهلة لاستخدام GPT-5.6 Cyber. يتطلب GPT-6 Cyber موافقة منفصلة لاستخدام هذا النموذج. فعّل تسجيل الدخول الموحد (SSO) واجعله إلزاميًا في كل مؤسسة أو مساحة عمل مشتركة تستخدم فيها Daybreak Red. يتطلب الوصول إلى GPT-6 Cyber عبر API افتراضيًا إدراج عناوين IP في قائمة السماح. تتطلب مشاريع API التي تستخدم إعداد عدم الاحتفاظ بالبيانات عادةً معالجة السلامة الخاصة أيضًا.

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

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

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

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

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

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

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

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

لكلا نموذجَي Cyber، استخدم daybreak_red في Responses API.

يمكن للمؤسسة المعتمدة لاستخدام 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 للحصول على إمكانية الوصول.

تحقّق من عمل GPT-6.1 Terra مع Daybreak

لاستخدام GPT-6.1 Terra، تأكّد من الحصول على موافقة Daybreak Red وفعّل Daybreak صراحةً للطلب. لا يكفي Daybreak Blue وحده لتفعيل تقليل حالات الرفض المتعلقة بالأمن السيبراني في Terra. في Responses API، استخدم مفتاح المشروع غير الافتراضي المفعّل، واضبط access_programs.cyber صراحةً؛ فإغفاله يؤدي إلى تطبيق ضوابط الحماية القياسية. لا تدعم واجهة Chat Completions هذا المسار لتقليل حالات الرفض.

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

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

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

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

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

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

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

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 المطلوبة، وحصولها على موافقة لاستخدام GPT-6 Cyber إذا كان هو النموذج المطلوب. عند استخدام 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 اللذين تستخدمهما. بالنسبة إلى GPT-6 Cyber، تحقّق من أن الموافقة تشمل هذا النموذج.

• تحقّق من إعدادات 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 لعملاء جهات خارجية أو مستخدمين خارجيين، ولا تدمجها في سير عمل منتجات أخرى تعتمد عليها.