نمای کلی

اگر هماهنگی راه‌اندازی اولیه 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 استفاده کنید. نام‌های مستعار ممکن است با گذشت زمان به مدل‌های جدیدترِ واجد شرایط اشاره کنند؛ نمونه‌های زیر مقصد ثابت این نام‌های مستعار نیستند. این نام‌های مستعار OpenAI API در Amazon Bedrock در دسترس نیستند.

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

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

برای ثبت درخواست پشتیبانی، به چگونه می‌توانم با پشتیبانی تماس بگیرم؟ مراجعه کنید.

اولین گردش‌کار را شروع کنید

برای بیشتر تیم‌ها، اولین گردش‌کار باید در افزونه 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، یا تنظیمات ذخیره‌شده فضای کاری و نقش‌ها.

• نام مستعار API یا شناسه مدل دقیقِ استفاده‌شده در آزمایش.

• اینکه آیا درخواست از کلید پروژه فعال‌شده استفاده می‌کند و آیا بارهای کاری مهاجرت‌یافته برای استفاده از پروژه مقصد به‌روزرسانی شده‌اند.

• تأیید اینکه پیکربندی موردنظر برای برنامه‌های ارائه‌شده به مشتریان، ترافیک اشخاص ثالث یا گردش‌کارهای محصولات پایین‌دستی استفاده نمی‌شود.

• اینکه آیا دسترسی در پیکربندی قبلی باید حذف شود یا به حالت پیشین برگردد.

• اینکه آیا پیکربندی جدید پرسشی درباره صورتحساب، سقف بودجه یا مسئول امور تجاری ایجاد می‌کند.

• اولین گردش‌کاری که تیم قصد اجرای آن را دارد و افراد در نظر گرفته‌شده برای اجرا و بازبینی انسانی آن.

• محدودیت‌های زمانی یا جلسه پیشِ رو برای آماده‌سازی استفاده، در صورت وجود.

در مواردی که تنظیمات تأییدشده پروژه در دسترس هستند، هدف آن‌ها تفکیک دسترسی Daybreak بر اساس پروژه است تا نیازی به یک زیرسازمان API جداگانه نباشد. اگر این تنظیمات در دسترس نیستند یا پیکربندی تأییدشده همچنان به یک سازمان API اختصاصی نیاز دارد، طبق راهنمایی تیم مسئول حساب خود در OpenAI عمل کنید.

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

نکته‌ای درباره استفاده

دسترسی Daybreak باید به کاربران داخلیِ تأییدشده و فعالیت‌های امنیتی داخلی محدود باشد. «صرفاً برای استفاده داخلی» یعنی فعالیت تیم مجاز خودتان، نه ترافیک مشتریان، خدمات امنیتی ارائه‌شده به بیرون از سازمان یا قابلیت‌های پایین‌دستی که درخواست‌های اشخاص ثالث را از Daybreak عبور می‌دهند. در مواردی که تنظیمات فعال هستند، از نقش‌های فضای کاری و پروژه‌های API ویژه استفاده داخلی برای اعمال محدوده تأییدشده استفاده کنید.

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

عدم ذخیره داده (ZDR)

احراز شرایط Daybreak و فعال‌سازی پروژه، عدم ذخیره داده (ZDR) را به‌طور خودکار فعال نمی‌کنند. ZDR باید جداگانه برای همان سازمان API و نقطه پایان مربوطه درخواست و راه‌اندازی شود. اگر سازمان شما به ZDR یا شیوه مشخص دیگری برای نگهداری داده نیاز دارد، پیش از شروع اولین گردش‌کار توسط تیم، مطمئن شوید که ترافیک پروژه فعال‌شده مشمول آن شرایط است. فرض نکنید که روشن‌کردن گزینه Daybreak Blue یا Daybreak Red در پروژه، تنظیمات نگهداری داده را تغییر می‌دهد.

محدودیت‌های عملیاتی

• از محیط راه‌اندازی‌شده فقط برای فعالیت‌های دفاعی مجاز استفاده کنید.

• فقط روی سیستم‌هایی کار کنید که سازمانتان مالک آن‌هاست یا مجوز صریح ارزیابی آن‌ها را دارد.

• اولین گردش‌کار را محدود و قابل بازبینی نگه دارید.

• در بررسی یافته‌های مهم و اقدامات اصلاحی، نظارت و مشارکت انسانی را حفظ کنید.

• دقیقاً از همان سازمان، فضای کاری، پروژه API، سطح Daybreak، نام مستعار API یا شناسه مدلی استفاده کنید که در جزئیات راه‌اندازی اولیه شما ذکر شده است.

• اجازه پیکربندی تنظیمات Daybreak پروژه را فقط به مالکان سازمان API بدهید. مالکان فضای کاری، تنظیمات پیش‌فرض فضای کاری و تخصیص نقش‌های سفارشی را مدیریت می‌کنند. تأییدیه Daybreak Blue شامل Daybreak Red نمی‌شود.

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

• قابلیت‌های Daybreak را در اختیار مشتریان شخص ثالث، کاربران بیرونی یا گردش‌کارهای محصولات پایین‌دستی قرار ندهید.