סקירה כללית

מדריך זה מיועד למי שמרכזים את ההצטרפות ל-Daybreak בארגון וצריכים להתקדם מהגשת הבקשה ובדיקת הזכאות לתצורה מוכנה להפעלה.

Daybreak Access היא התוכנית של OpenAI לגישה מהימנה לכלי סייבר. Daybreak Blue ו-Daybreak Red הן רמות גישה במסגרת Daybreak.

לרוב הצוותים בארגונים מומלץ להתחיל ב-Daybreak Blue לתהליכי עבודת הגנה פנימיים ומאושרים.

Daybreak Red מחייב אישור נפרד לתהליכי עבודה מתקדמים ומורשים בתחום אבטחת הסייבר. חלק ממודלי החזית בתחום הסייבר מחייבים אישור נוסף, ייעודי למודל.

קבלת אישור כשלעצמה אינה מפעילה את הפחתת הסירובים. אפשרויות Daybreak כבויות בתחילה. הבעלים של ה-workspace מפעיל את הגישה למשתמשים ולקבוצות שאושרו; הבעלים של ארגון ה-API מפעיל אותה לפרויקטים מאושרים שאינם פרויקטי ברירת מחדל. אם הצוות שלכם משתמש בשני מסלולי הגישה, הגדירו את שניהם. משתמשים שנכנסים ל-Codex באמצעות ChatGPT צריכים גם להפעיל את Daybreak לפני שליחת בקשה.

חלק מתהליכי העבודה הכרוכים בסיכון מוגבר עדיין עשויים להיתקל בסירוב לאחר הפעלת הגישה. לכן התחילו בתהליך עבודת הגנה בהיקף מוגדר, בדיוק בממשק, בפרויקט ובמודל שבהם הצוות שלכם מתכנן להשתמש.

מעקב אחר מצב ההצטרפות והגישה

הכרת מסלול הגישה המאושר

אישור ההצטרפות אמור לפרט מהם המודלים המאושרים, מי רשאי להשתמש בהם ובאילו ארגון, workspace, ארגון API ופרויקט API יש להשתמש תחילה.

לתהליכי עבודה מעשיים במאגרי קוד, התחילו ב-Codex או בתוסף Codex Security. לאוטומציה מאושרת, השתמשו ב-Codex CLI או ב-Codex GitHub Action. בתהליכי עבודה דרך ה-API, הגבילו את הבקשות ואת פרטי הגישה לפרויקט המאושר לשימוש פנימי בלבד.

לגישה דרך ה-API של OpenAI, השתמשו במזהה מודל ספציפי שנכלל באישור הגישה שלכם ובהגדרת 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, הגדירו תפקידים ב-workspace בנפרד; הפעלת הגישה בפרויקט API אינה מגדירה את הגישה ל-workspace.

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: הבעלים של ה-workspace פותח את מסוף הניהול ← מודלים ← ברירת המחדל של ה-workspace. תחת אבטחת סייבר, כבו את Daybreak Red אם הוא מופעל, לאחר מכן כבו את Blue ובחרו בשמירת שינויים. פתחו את תפקידים ובחרו בעריכת הגדרה עוקפת עבור התפקיד הרצוי, או בהוספת הגדרה עוקפת לתפקיד. תחת אבטחת סייבר, הגדירו את Daybreak Blue למצב מופעל; הפעילו את Red רק אם הוא אושר ל-workspace ולאותם משתמשים. בחרו בשמירה והמתינו כ-10 דקות. בדקו את הקצאות התפקידים הישירות ודרך קבוצות, ואז היכנסו ל-workspace המאושר ובצעו בדיקה עם מודל מאושר. ב-Codex, הפעילו את המתג של Daybreak לפני הבדיקה; כשהוא כבוי, חלים מנגנוני ההגנה הרגילים.

אם אפשרות ההגדרה הצפויה חסרה, בדקו את ה-workspace או את ארגון ה-API שאושרו, את הרשאות מנהל המערכת והאם הקצאת הגישה הושלמה. לגישה דרך ה-API, ודאו שאתם צופים בפרויקט שאינו פרויקט ברירת מחדל; לגישה דרך workspace, בדקו במסוף הניהול ← מודלים. אם האפשרות עדיין אינה מופיעה, פנו לצוות ניהול החשבון שלכם ב-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.

אם הבקשה נכשלת, נתקלת בסירוב או מניבה תוצאה בלתי צפויה, ודאו תחילה את כל הפרטים הבאים:

• הזהות שבה התחברתם והארגון, ה-workspace או פרויקט ה-API המדויקים.

• זכאות הארגון לרמת Daybreak המבוקשת וכל אישור נוסף שנדרש למודל. ב-Astra או ב-GPT-6.1 Sol, גישה ברמת Blue משאירה את מנגנוני ההגנה הרגילים בתוקף.

• בכניסה ל-Codex באמצעות ChatGPT, שהבעלים של ה-workspace הפעיל גישה למשתמש המיועד ושהמתג של Daybreak אצל המשתמש מופעל. בכניסה באמצעות מפתח API, הגישה נקבעת לפי פרויקט ה-API שבו היא הופעלה; אין ממשק נפרד ל-Daybreak.

• בגישה דרך ה-API, שהבעלים של ארגון ה-API שמר את רמת Daybreak המאושרת עבור הפרויקט המיועד, שאינו פרויקט ברירת מחדל.

• בגישה דרך ה-API, שהבקשה משתמשת במפתח מהפרויקט שבו הופעלה הגישה, ושכל עומס עבודה שהועבר עודכן לשימוש בפרויקט היעד.

• מזהה המודל המאושר המדויק, בעזרת טבלת ה-API של OpenAI שלעיל, לפי הצורך.

סירוב או תוצאה בלתי צפויה עשויים להעיד על אי-התאמה בזכאות או בהגדרות, על פרטי גישה לא מעודכנים, על מיפוי שגוי של המודל או על מגבלה מכוח המדיניות. אין בכך כשלעצמו כדי לאשר שחסרה גישה.

לשלבי אבחון ולפרטים שיש לכלול בפנייה לתמיכה, עיינו במאמר גישה מהימנה לכלי סייבר — בעיות נפוצות ופתרון תקלות. לפתיחת פנייה לתמיכה, עיינו במאמר איך אפשר ליצור קשר עם התמיכה?. סירוב עשוי להיראות כך:

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.

העברת בעיות בהגדרות לטיפול

לפני שינוי ארגונים, סביבות workspace, פרויקטי API, מאגרים או פרטי גישה, בדקו את התצורה בסדר הבא:

• ודאו את מסלול הגישה המאושר של הארגון ואת זכאותו לרמת Daybreak המבוקשת.

• ודאו את הגדרות Daybreak שנשמרו עבור משתמשי ה-workspace המיועדים או עבור פרויקט ה-API שאינו פרויקט ברירת מחדל, לפי הסעיף ״בדיקת הגישה המאושרת״ שלעיל.

• ודאו שהבקשה משתמשת במפתח API ששייך לפרויקט שבו הופעלה הגישה.

• ודאו את מזהה המודל המדויק ואת פרויקט ה-API המיועד.

אם מתג צפוי אינו מופיע, אם נראה שזכאות הארגון שגויה או אם אפשרויות ההגדרה ברמת הפרויקט אינן זמינות, בקשו מצוות ניהול החשבון שלכם ב-OpenAI לאשר את הזכאות ואת מסלול הגישה המאושר לפני העברת עומס העבודה לארגון או לפרויקט אחר.

לבעיות באימות, בגישה, במודלים או בבטיחות סייבר, פעלו לפי המאמר OpenAI Daybreak: בעיות נפוצות ופתרון תקלות. כללו את מזהה הארגון או ה-workspace, מזהה הפרויקט אם רלוונטי, ממשק המוצר, רמת Daybreak, מזהה המודל, ההגדרות שנשמרו, תפקיד מנהל המערכת, האם פרטי הגישה שייכים לפרויקט שבו הופעלה הגישה, הודעת השגיאה המלאה, מזהה הבקשה, חותמת הזמן ואזור הזמן, צילום מסך לפי הצורך ותיאור קצר של המשימה ללא מידע רגיש.

לפתיחת פנייה לתמיכה, עיינו במאמר איך אפשר ליצור קשר עם התמיכה?.

התחלת תהליך העבודה הראשון

לרוב הצוותים מומלץ להתחיל את תהליך העבודה הראשון בתוסף Codex Security, בהיקף מצומצם המוגדר לפי מאגר, ענף או התראות. Codex CLI הוא המסלול לאוטומציה בקנה מידה רחב, כאשר לאחראים על תהליך העבודה כבר יש תהליך CI/CD מהימן שהם רוצים לבדוק. לתהליכי עבודה דרך ה-API, השתמשו בפרויקט המאושר לשימוש פנימי בלבד, ברמת Daybreak שאושרה ובמפתח ה-API של אותו פרויקט.

תיקון אי-התאמה ב-workspace, בארגון API או בפרויקט

פעלו לפי מסלול זה כשהתצורה המאושרת מפנה לארגון, ל-workspace או לפרויקט API שגויים; כשהפרויקט המיועד אינו מוגבל לשימוש פנימי בלבד; כשאפשרות הגדרה צפויה חסרה; כשרמת Daybreak שגויה מופעלת; כשנעשה שימוש בפרטי גישה של פרויקט שגוי; כשצריך להעביר את הגישה בין מסלולי API ו-workspace; או כשממתינים לביטול שינוי או להסרה.

• השהו את הבדיקות ב-workspace, בארגון ה-API או בפרויקט שאינם תואמים לאישור.

• זהו את התצורה הנוכחית ואת התצורה המיועדת לשימוש פנימי בלבד.

• לגישה דרך ה-API, בקשו מהבעלים של ארגון ה-API לבדוק את אפשרויות Daybreak הזכאיות בפרויקט המיועד, שאינו פרויקט ברירת מחדל, לפי השלבים שלעיל.

• אם מתג ה-API המאושר מופיע אך כבוי, בקשו מהבעלים של ארגון ה-API להפעיל אותו ולשמור. לגישה דרך workspace, בקשו מהבעלים של ה-workspace לבדוק את תפקידי המשתמש המיועד, הן הישירים והן דרך קבוצות, ואת הרשאות המודלים שנשמרו. לפני בדיקה חוזרת ב-Codex עם כניסה באמצעות ChatGPT, ודאו שהמתג של Daybreak אצל המשתמש מופעל.

• לגישה דרך ה-API, השתמשו במפתח מפרויקט היעד שבו הופעלה הגישה והמתינו עד כ-15 דקות להחלת השינויים. לאחר שינויים ב-workspace, המתינו כ-10 דקות לפני בדיקה חוזרת.

• ודאו אם יש להסיר את התצורה הישנה, לבטל את השינויים בה או להשאיר אותה ללא שינוי.

• אם המתג הצפוי חסר או שהזכאות שגויה, שלחו את הפרטים הבאים לצוות ניהול החשבון שלכם ב-OpenAI כבקשת תיקון.

• הריצו שוב את הבדיקה להוכחת הגישה בתצורה המתוקנת, עם מזהה המודל המאושר המדויק.

כללו:

• שם החברה ואיש הקשר הראשי לעניינים טכניים או לניהול המערכת בארגון.

• השמות והמזהים של ה-workspace, ארגון ה-API ופרויקט ה-API הנוכחיים והמיועדים, אם הם ידועים.

• רמת Daybreak שאושרה והאפשרויות שמופיעות תחת הגדרות הפרויקט ← כללי ← גישה למודלי Daybreak, או הגדרות ה-workspace והתפקידים שנשמרו.

• מזהה המודל המדויק ששימש לבדיקה.

• האם הבקשה משתמשת במפתח מהפרויקט שבו הופעלה הגישה, והאם עומסי העבודה שהועברו עודכנו לשימוש בפרויקט היעד.

• אישור שהתצורה המיועדת אינה משמשת ליישומים המיועדים ללקוחות, לתעבורת צד שלישי או לתהליכי עבודה במוצרים המתבססים על Daybreak.

• האם יש להסיר את הגישה בתצורה הקודמת או לבטל את השינויים שנעשו בה.

• האם התצורה החדשה מעלה שאלה בנוגע לחיוב, למגבלת התקציב או לגורם האחראי מבחינה מסחרית.

• תהליך העבודה הראשון שהצוות מתכנן להריץ, מי צפוי להפעיל אותו ומי יבצע את הבדיקה האנושית.

• אילוצי זמן או מפגש הדרכה קרוב לקראת ההפעלה, אם יש כאלה.

כאשר אפשרויות הגדרה מאושרות ברמת הפרויקט זמינות, הן נועדו לבודד את הגישה ל-Daybreak לפי פרויקט, במקום לחייב תת-ארגון API נפרד. אם האפשרויות אינן זמינות או שהתצורה המאושרת עדיין מחייבת ארגון API ייעודי, פעלו לפי ההנחיות של צוות ניהול החשבון שלכם ב-OpenAI.

אם הסרת ארגון או פרויקט ישנים עדיין ממתינה לביצוע, אם החלפה טרם הושלמה או אם תיקון הזכאות טרם הוסדר, התייחסו לתצורה המתוקנת כלא מוכנה עד לאישור השינוי.

הערה בנוגע לשימוש

יש להגביל את הגישה ל-Daybreak למשתמשים פנימיים מאושרים ולעבודת אבטחה פנימית. שימוש פנימי בלבד פירושו עבודה של הצוות המורשה שלכם, ולא תעבורה של לקוחות, שירותי אבטחה המוצעים לגורמים חיצוניים או תכונות במוצרים אחרים שמעבירות בקשות של צד שלישי דרך Daybreak. כאשר אפשרויות ההגדרה זמינות, השתמשו בתפקידים ב-workspace ובפרויקטי API לשימוש פנימי בלבד כדי לאכוף את מסגרת השימוש שאושרה.

כאשר אפשרויות הגדרה מאושרות ברמת הפרויקט זמינות, פרויקט לשימוש פנימי בלבד יכול לבודד את הגישה ל-Daybreak בתוך ארגון API זכאי, במקום לחייב תת-ארגון API נפרד. הפעלת הגישה בפרויקט אינה מתירה שימוש עבור לקוחות או צדדים שלישיים.

אפס שמירת נתונים (ZDR)

זכאות ל-Daybreak והפעלת הגישה בפרויקט אינן מפעילות אוטומטית אפס שמירת נתונים (ZDR). יש לבקש ולהגדיר ZDR בנפרד עבור ארגון ה-API המדויק וה-endpoint הרלוונטי. אם הארגון שלכם מחייב ZDR או הסדר ספציפי אחר לשמירת נתונים, ודאו שהתנאים האלה חלים על התעבורה מהפרויקט שבו הופעלה הגישה, לפני שהצוות מתחיל בתהליך העבודה הראשון. אין להניח שהפעלת המתג של Daybreak Blue או Daybreak Red בפרויקט משנה את הגדרות שמירת הנתונים.

גבולות הפעילות

• השתמשו בתצורה שהוקצתה לכם רק לעבודת הגנה מורשית.

• השתמשו במערכות שבבעלות הארגון שלכם או במערכות שיש לו הרשאה מפורשת לבדוק.

• הקפידו שתהליך העבודה הראשון יהיה מצומצם וניתן לבחינה.

• הקפידו על מעורבות אנושית בבחינת ממצאים בעלי השפעה משמעותית ובתיקון הבעיות.

• השתמשו בדיוק בארגון, ב-workspace, בפרויקט ה-API, ברמת Daybreak ובמזהה המודל שצוינו בפרטי ההצטרפות שלכם.

• אפשרו רק לבעלים של ארגון ה-API להגדיר את אפשרויות Daybreak ברמת הפרויקט. הבעלים של ה-workspace מנהלים את ברירות המחדל שלו ואת הקצאות התפקידים המותאמים אישית. אישור ל-Daybreak Blue אינו כולל את Daybreak Red.

• שמרו על אבטחת פרטי הגישה לפרויקט והגבילו אותם לפרויקט לשימוש פנימי בלבד שבו הופעלה הגישה.

• אל תאפשרו שימוש ביכולות Daybreak ללקוחות צד שלישי, למשתמשים חיצוניים או לתהליכי עבודה במוצרים המתבססים עליהן.