OpenAI
این صفحه به‌صورت ماشینی ترجمه شده است. مقاله اصلی انگلیسی را مشاهده کنید.

آماده‌سازی سازمانی Daybreak

نحوه تکمیل راه‌اندازی سازمانی Trusted Access، اعتبارسنجی دسترسی تخصیص‌یافته، رفع مشکلات سازمان یا فضای کاری، و آماده‌شدن برای نخستین روند کاری.

به‌روزرسانی: 6 days ago

نمای کلی

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

Daybreak Access برنامه «دسترسی مطمئن برای امنیت سایبری» OpenAI است. Daybreak Blue و Daybreak Red سطوح دسترسی هستند. این برنامه شامل مدل‌ها، مسیرهای دسترسی، Codex، امنیت Codex و خدمات پشتیبانی است.

بیشتر تیم‌های سازمانی باید برای گردش‌کارهای دفاعی داخلیِ تأییدشده، کار را با Daybreak Blue آغاز کنند. Daybreak Blue از نام مستعار API به‌شکل gpt-daybreak-blue استفاده می‌کند که به شناسه مدل gpt-5.6-sol نگاشت می‌شود.

Daybreak Red از نام مستعار API به‌شکل gpt-daybreak-red استفاده می‌کند که به شناسه مدل gpt-5.6-cyber نگاشت می‌شود. Daybreak Red مستلزم احراز صلاحیت جداگانه است و ممکن است فقط شامل مدل‌های تخصصی تأییدشده برای سازمان باشد.

مشتریانی که از قبل برای GPT-5.5 با «دسترسی مطمئن برای امنیت سایبری» تأیید شده‌اند، باید همچنان دستورالعمل‌های دسترسی تأییدشده خود را دنبال کنند.

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

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

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

مرحلهشرحگام بعدی
ارسال فرم پذیرشسازمان شما فرم پذیرش سازمانی Daybreak را تکمیل کرده است.منتظر ایمیلی از Persona باشید و مطمئن شوید به رابط صحیح سازمان می‌رسد. اگر سازمان شما از قبل «دسترسی مطمئن» تأییدشده دارد و رابط OpenAI اعلام کرده که پذیرش جدید لازم نیست، به‌جای ارسال درخواست تکراری، دستورالعمل او را دنبال کنید.
تکمیل احراز هویت KYBPersona برای تکمیل فرایند «شناخت کسب‌وکار شما» (KYB) به رابط درج‌شده در فرم پذیرش ایمیل می‌زند.درخواست Persona را تکمیل کنید. سپس OpenAI بررسی‌های داخلی صلاحیت و تناسب را انجام می‌دهد.
دریافت نتیجه بررسی صلاحیتOpenAI مسیر دسترسی تأییدشده و واجد شرایط بودن سازمان شما برای Daybreak Blue،‏ Daybreak Red یا هر دو را اعلام می‌کند. Daybreak Red مستلزم احراز صلاحیت جداگانه است.کاربران تأییدشده، سازمان یا فضای کاری، سازمان API، مدل‌ها و محیط‌های محصول را تأیید کنید. از صلاحیت Blue، صلاحیت Red را نتیجه نگیرید.
فعال‌سازی Daybreak برای یک پروژه APIوقتی کنترل‌های پروژه برای سازمان API واجد شرایط در دسترس باشد، مدیر سازمان به تنظیمات پروژه ← محدودیت‌ها می‌رود، Daybreak را برای پروژه صرفاً داخلی فعال می‌کند و سپس مدل واجد شرایط مشخص را نیز فعال می‌کند. فقط مدیران سازمان می‌توانند این تنظیمات را ببینند یا تغییر دهند.Daybreak را فقط برای پروژه واجد شرایط فعال کنید و سپس فقط مدل واجد شرایط موردنیاز همان پروژه را فعال کنید.
نوسازی اعتبارنامه‌های پروژهممکن است کلید API یا اعتبارنامه فعلی، دسترسی تازه‌فعال‌شده را منعکس نکند.پس از فعال‌سازی، یک کلید API جدید برای پروژه بسازید یا اعتبارنامه پروژه مورد استفاده سرویس را نوسازی کنید. اعتبارنامه را محدود به پروژه فعال و صرفاً داخلی نگه دارید.
اعتبارسنجی دسترسی و آغاز یک گردش‌کار دفاعی محدودمسیر دسترسی، پروژه و مدل موردنظر و اعتبارنامه جدید برای بررسی دسترسی آماده‌اند.بررسی اثبات دسترسی زیر را در محیط تأییدشده اجرا کنید. پیش از آغاز نخستین گردش‌کار، مجری و بازبین آن را مشخص کنید.

شناخت مسیر دسترسی تأییدشده

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

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

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

دقیقاً از نگاشت‌های API زیر استفاده کنید:

سطح دسترسی Daybreakنام مستعار APIشناسه مدلشرایط احراز صلاحیت
Daybreak Bluegpt-daybreak-bluegpt-5.6-solمستلزم احراز صلاحیت Daybreak Blue است.
Daybreak Redgpt-daybreak-redgpt-5.6-cyberمستلزم احراز صلاحیت جداگانه Daybreak Red است.

وقتی کنترل‌های پروژه در دسترس باشد، مدیر سازمان به تنظیمات پروژه ← محدودیت‌ها می‌رود، Daybreak را برای پروژه واجد شرایط فعال می‌کند و سپس مدل واجد شرایط مشخص را نیز فعال می‌کند. فقط مدیران سازمان می‌توانند این تنظیمات را ببینند یا تغییر دهند.

تنظیمات پروژه، دسترس‌پذیری API را برای پروژه انتخاب‌شده تعیین می‌کند. ممکن است هنگام انتقال، برخی رفتارهای فعلی «دسترسی مطمئن» در سطح سازمان ادامه یابد؛ برای اطلاع از محدوده دقیق دسترسی، تأییدیه راه‌اندازی خود را دنبال کنید. اگر کنترل‌ها وجود ندارند یا پیکربندی تأییدشده شما همچنان به یک سازمان API اختصاصی نیاز دارد، پیش از آزمایش دقیقاً دستورالعمل‌های رابط OpenAI خود را دنبال کنید. فرض نکنید که کنترل‌های پروژه API، دسترسی Codex یا ChatGPT را تغییر می‌دهند.

برای Daybreak Blue و دسترسی فعلی GPT-5.5 با «دسترسی مطمئن برای امنیت سایبری»، دسترسی فضای کاری به سازمان نام‌برده‌شده Codex یا ChatGPT و دسترسی API به سازمان API نام‌برده‌شده و پروژه فعال مربوط می‌شود؛ همان‌طور که در تأییدیه مشخص شده است. Daybreak Red مستلزم احراز صلاحیت جداگانه است و ممکن است الزامات بیشتری در سطح مدل یا کاربر داشته باشد. دستورالعمل‌های دقیق مربوط به سازمان، کاربر، پروژه، مدل و محیط محصول را در تأییدیه خود دنبال کنید.

اعتبارسنجی دسترسی تأییدشده

دسترسی را دقیقاً در محیط تأییدشده اعتبارسنجی کنید:

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

  • Codex یا ChatGPT: وارد همان سازمان یا فضای کاری صرفاً داخلی شوید که در تأییدیه راه‌اندازی نام برده شده است و دستورالعمل‌های مربوط به مدل و کاربر را در همان تأییدیه دنبال کنید.

اگر کنترل‌های پروژه 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

بررسی دسترسی زمانی موفق است که GPT-5.5 اثبات مفهوم محدود و فقط محلی را با قیود ایمنی، فایل‌های محلی و نتیجه راستی‌آزمایی‌ای مانند نمونه زیر تکمیل کند:

یک اثبات مفهوم CVE فقط محلی پیاده‌سازی شد؛ راستی‌آزمایی موفق بود؛ حالت آسیب‌پذیر یک نشانگر اثبات می‌نویسد و حالت وصله‌شده همان محموله ساخته‌شده را رد می‌کند.

اگر اعلان رد شد یا نتیجه محدود مورد انتظار را ایجاد نکرد، ابتدا همه موارد زیر را بررسی کنید:

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

  • واجد شرایط بودن سازمان برای سطح دسترسی درخواستی Daybreak.

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

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

  • نگاشت دقیق API: برای Blue،‏ gpt-daybreak-blue یا gpt-5.6-sol؛ و برای دسترسی Red با صلاحیت جداگانه، gpt-daybreak-red یا gpt-5.6-cyber.

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

برای مراحل تشخیص و اطلاعات لازم هنگام تماس با پشتیبانی، راهنمای دسترسی مطمئن برای امنیت سایبری — مشکلات رایج و عیب‌یابی را دنبال کنید. برای ثبت درخواست پشتیبانی، به چگونه با پشتیبانی تماس بگیرم؟ مراجعه کنید. پیام رد ممکن است به این شکل باشد:

نمی‌توانم برای یک RCE پیش از احراز هویت، اثبات مفهوم اکسپلویت بسازم یا بسته‌بندی کنم؛ اما می‌توانم یک راستی‌آزمای دفاعی بسازم و اثر، تشخیص و اصلاح را مستند کنم.

ارجاع مشکلات راه‌اندازی

پیش از تغییر سازمان‌ها، فضاهای کاری، پروژه‌های API، محل‌های نگهداری یا اعتبارنامه‌ها، پیکربندی را به‌ترتیب زیر بررسی کنید:

  1. مسیر دسترسی تأییدشده سازمان و واجد شرایط بودن آن برای سطح دسترسی درخواستی Daybreak را تأیید کنید.

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

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

  4. نام مستعار یا شناسه دقیق مدل و پروژه API موردنظر را تأیید کنید.

اگر تنظیم مورد انتظار Daybreak یا مدل دیده نمی‌شود، صلاحیت سازمان نادرست به نظر می‌رسد یا کنترل‌های پروژه در دسترس نیست، پیش از انتقال بار کاری به سازمان یا پروژه‌ای دیگر، از تیم حساب OpenAI خود بخواهید صلاحیت و مسیر دسترسی تأییدشده را بررسی کند.

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

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

آغاز نخستین گردش‌کار

برای بیشتر تیم‌ها، نخستین گردش‌کار باید در افزونه امنیت Codex و با دامنه‌ای محدود از محل نگهداری، شاخه یا هشدار آغاز شود. وقتی مالکان گردش‌کار از قبل یک گردش‌کار CI/CD مطمئن برای اعتبارسنجی دارند، Codex CLI مسیر خودکارسازی در مقیاس وسیع است. برای گردش‌کار API، از پروژه صرفاً داخلی تأییدشده، سطح دسترسی واجد شرایط Daybreak و اعتبارنامه جدید پروژه استفاده کنید.

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

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

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

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

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

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

  • پس از فعال‌سازی، یک کلید API جدید برای آن پروژه بسازید یا اعتبارنامه پروژه مورد استفاده سرویس را نوسازی کنید.

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

  • اگر کلید تغییر مورد انتظار وجود ندارد یا صلاحیت نادرست است، جزئیات زیر را در قالب درخواست اصلاح برای تیم حساب OpenAI خود بفرستید.

  • بررسی اثبات دسترسی را با نام مستعار یا شناسه مدل دقیقاً تأییدشده، دوباره در پیکربندی اصلاح‌شده اجرا کنید.

این موارد را ارائه کنید:

  • نام شرکت و اطلاعات تماس مدیر فنی اصلی یا مدیر سازمان.

  • نام و شناسه فضای کاری، سازمان API و پروژه API فعلی و موردنظر، در صورت اطلاع.

  • سطح دسترسی تأییدشده Daybreak و تنظیمات Daybreak و مدل که در تنظیمات پروژه ← محدودیت‌ها دیده می‌شوند.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • فقط مدیران سازمان را مجاز به تغییر تنظیمات پروژه و مدل Daybreak کنید و از واجد شرایط بودن برای Daybreak Blue، صلاحیت Daybreak Red را نتیجه نگیرید.

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

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

آیا این مقاله مفید بود؟