نمای کلی

اگر هماهنگی راه‌اندازی اولیه Daybreak در سازمانتان بر عهده شماست و باید از مرحله ثبت درخواست و بررسی شرایط به پیکربندی آماده اجرا برسید، از این راهنما استفاده کنید.

Daybreak Access برنامه «دسترسی مورد اعتماد برای امنیت سایبری» OpenAI است. Daybreak Blue و Daybreak Red سطوح دسترسی در Daybreak هستند.

بیشتر تیم‌های سازمانی باید برای گردش‌کارهای دفاعی داخلیِ تأییدشده، با Daybreak Blue شروع کنند.

Daybreak Red برای گردش‌کارهای پیشرفته و مجاز امنیت سایبری به تأیید جداگانه نیاز دارد. برخی مدل‌های پیشرو امنیت سایبری به تأییدیه اضافی مخصوص همان مدل نیاز دارند.

دریافت تأییدیه به‌تنهایی حالت کاهش موارد امتناع از پاسخ‌گویی را فعال نمی‌کند. گزینه‌های Daybreak در ابتدا خاموش هستند. مالک فضای کاری دسترسی را برای کاربران و گروه‌های تأییدشده فعال می‌کند؛ مالک سازمان API نیز آن را برای پروژه‌های غیرپیش‌فرضِ تأییدشده فعال می‌کند. اگر تیم شما از هر دو مسیر دسترسی استفاده می‌کند، هر دو را پیکربندی کنید. کاربرانی که با ChatGPT وارد Codex می‌شوند نیز باید پیش از ارسال درخواست، Daybreak را روشن کنند.

ممکن است پس از فعال‌شدن دسترسی، مدل همچنان از اجرای برخی گردش‌کارهای پرخطرتر امتناع کند؛ بنابراین با یک گردش‌کار دفاعی با محدوده مشخص، دقیقاً در همان محیط و با همان پروژه و مدلی شروع کنید که تیم شما قصد استفاده از آن‌ها را دارد.

وضعیت راه‌اندازی اولیه و دسترسی را پیگیری کنید

با مسیر دسترسی تأییدشده آشنا شوید

تأییدیه راه‌اندازی اولیه شما باید مدل‌های تأییدشده، افراد مجاز به استفاده از آن‌ها و سازمان، فضای کاری، سازمان API و پروژه API را که باید ابتدا استفاده کنید، مشخص کند.

برای گردش‌کارهای عملی در محل نگهداری کد، با Codex یا افزونه Codex Security شروع کنید. برای خودکارسازی تأییدشده، از Codex CLI یا Codex GitHub Action استفاده کنید. در گردش‌کارهای API، درخواست‌ها و اطلاعات احراز هویت را به پروژه تأییدشده‌ای محدود کنید که صرفاً برای استفاده داخلی است.

برای دسترسی به OpenAI API، از شناسه مدل مشخصی که در دسترسی تأییدشده شما گنجانده شده و تنظیم درخواست Daybreak متناظر با آن استفاده کنید. کاربرد مثال‌های زیر به مدل‌های تأییدشده برای سازمان شما بستگی دارد.

در درخواست‌های Responses API، برای gpt-6-sol مقدار access_programs.cyber را روی daybreak_blue تنظیم کنید؛ حتی اگر سازمان شما تأییدیه 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 را فعال و ذخیره کنید. پروژه‌های پیش‌فرض واجد شرایط نیستند و مالک پروژه بودن به‌تنهایی مجوز ایجاد تغییرات را نمی‌دهد. تا حدود ۱۵ دقیقه صبر کنید، سپس با استفاده از کلید همان پروژه و شناسه یک مدل تأییدشده، درخواستی مستقیم به Responses API ارسال کنید. نبودن یک مدل در /models به‌تنهایی به معنای در دسترس نبودن آن نیست.

• ChatGPT و Codex با ورود از طریق ChatGPT: یکی از مالکان فضای کاری، کنسول مدیریت ← مدل‌ها ← پیش‌فرض فضای کاری را باز می‌کند. در بخش امنیت سایبری، اگر Daybreak Red روشن است آن را خاموش کنید، سپس Blue را خاموش کنید و «ذخیره تغییرات» را انتخاب کنید. بخش «نقش‌ها» را باز کنید و برای نقش موردنظر «ویرایش تنظیمات جایگزین» یا «افزودن تنظیمات جایگزین نقش» را انتخاب کنید. در بخش امنیت سایبری، Daybreak Blue را روی «روشن» تنظیم کنید؛ Red را فقط در صورتی فعال کنید که برای فضای کاری و آن کاربران تأیید شده باشد. «ذخیره» را انتخاب کنید و حدود ۱۰ دقیقه صبر کنید. تخصیص نقش‌ها به‌صورت مستقیم و از طریق گروه را بررسی کنید، سپس وارد فضای کاری تأییدشده شوید و با یک مدل تأییدشده آزمایش کنید. در 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 آغاز شود و دامنه آن از نظر محل نگهداری کد، شاخه یا هشدار محدود باشد. وقتی مسئولان گردش‌کار از قبل یک گردش‌کار قابل اعتماد CI/CD برای اعتبارسنجی دارند، Codex CLI مسیر خودکارسازی در مقیاس گسترده است. برای گردش‌کارهای API، از پروژه تأییدشده ویژه استفاده داخلی، سطح تأییدشده Daybreak و کلید API همان پروژه استفاده کنید.

ناهماهنگی فضای کاری، سازمان API یا پروژه را اصلاح کنید

در این موارد از این مسیر استفاده کنید: پیکربندی تأییدشده به سازمان، فضای کاری یا پروژه API اشتباه اشاره دارد؛ پروژه موردنظر صرفاً داخلی نیست؛ کنترل مورد انتظار وجود ندارد؛ سطح نادرست Daybreak فعال است؛ اطلاعات احراز هویت متعلق به پروژه اشتباه استفاده می‌شود؛ دسترسی باید بین مسیر API و فضای کاری منتقل شود؛ یا بازگردانی یا حذف هنوز انجام نشده است.

• آزمایش را در فضای کاری، سازمان API یا پروژه ناهماهنگ متوقف کنید.

• پیکربندی فعلی و پیکربندی صرفاً داخلیِ موردنظر را مشخص کنید.

• برای دسترسی API، از یکی از مالکان سازمان API بخواهید با استفاده از مراحل بالا، کنترل‌های مجاز Daybreak را برای پروژه غیرپیش‌فرض موردنظر بررسی کند.

• اگر کلید تأییدشده API نمایش داده می‌شود اما غیرفعال است، از مالک سازمان API بخواهید آن را فعال و ذخیره کند. برای دسترسی فضای کاری، از یکی از مالکان فضای کاری بخواهید نقش‌های مستقیم و گروهی کاربر موردنظر و مجوزهای ذخیره‌شده مدل را بررسی کند. پیش از آزمایش مجدد در Codex با ورود از طریق ChatGPT، مطمئن شوید که کلید Daybreak کاربر روشن است.

• برای دسترسی API، از کلید پروژه مقصد فعال‌شده استفاده کنید و تا حدود ۱۵ دقیقه برای اعمال تغییرات صبر کنید. پیش از آزمایش مجدد، حدود ۱۰ دقیقه برای اعمال تغییرات فضای کاری صبر کنید.

• مشخص کنید که پیکربندی قدیمی باید حذف شود، به وضعیت قبلی برگردد یا بدون تغییر بماند.

• اگر کلید مورد انتظار وجود ندارد یا وضعیت احراز شرایط نادرست است، جزئیات زیر را به‌عنوان درخواست اصلاح برای تیم مسئول حساب خود در 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 را در اختیار مشتریان شخص ثالث، کاربران بیرونی یا گردش‌کارهای محصولات پایین‌دستی قرار ندهید.