Omówienie
Skorzystaj z tego przewodnika, jeśli koordynujesz wdrożenie Daybreak w swojej organizacji i chcesz przejść od zgłoszenia i oceny uprawnień do konfiguracji gotowej do pracy.
Daybreak Access to program OpenAI Trusted Access for Cyber. Daybreak Blue i Daybreak Red to poziomy dostępu w ramach Daybreak.
Większość zespołów w przedsiębiorstwach powinna zacząć od Daybreak Blue do zatwierdzonych wewnętrznych działań obronnych.
Daybreak Red wymaga osobnej zgody na zaawansowane, autoryzowane działania z zakresu cyberbezpieczeństwa. Niektóre pionierskie modele do cyberbezpieczeństwa wymagają dodatkowej zgody dotyczącej konkretnego modelu.
Samo uzyskanie zgody nie włącza trybu ograniczonych odmów. Ustawienia Daybreak są początkowo WYŁĄCZONE. Właściciel przestrzeni roboczej włącza dostęp dla zatwierdzonych użytkowników i grup; właściciel organizacji API włącza go dla zatwierdzonych projektów innych niż domyślne. Skonfiguruj obie ścieżki dostępu, jeśli Twój zespół korzysta z obu. Użytkownicy logujący się do Codex przez ChatGPT muszą również włączyć Daybreak przed wysłaniem żądania.
Niektóre działania o podwyższonym ryzyku nadal mogą spotkać się z odmową po włączeniu dostępu. Zacznij więc od działań obronnych o ograniczonym zakresie, w dokładnie tym interfejsie, projekcie i modelu, których Twój zespół zamierza używać.
Śledź stan wdrożenia i dostępu
| Etap | Opis | Co zrobić dalej |
|---|---|---|
| Prześlij formularz zgłoszeniowy | Twoja organizacja wypełniła formularz zgłoszeniowy Daybreak dla przedsiębiorstw. | Wypatruj wiadomości e-mail od Persona i upewnij się, że trafi do właściwej osoby kontaktowej w organizacji. Jeśli Twoja organizacja ma już zatwierdzony dostęp do Daybreak, a osoba kontaktowa w OpenAI informuje, że nowe zgłoszenie nie jest wymagane, postępuj zgodnie z jej instrukcjami zamiast składać ponowny wniosek. |
| Ukończ weryfikację KYB | Persona wysyła do osoby wskazanej w formularzu zgłoszeniowym wiadomość e-mail z prośbą o przeprowadzenie weryfikacji firmy (Know Your Business, KYB). | Wykonaj czynności wskazane w prośbie od Persona. Następnie OpenAI przeprowadza wewnętrzną ocenę spełnienia warunków i odpowiedniości udziału w programie. |
| Odbierz decyzję o przyznaniu uprawnień | OpenAI potwierdza zatwierdzoną ścieżkę dostępu oraz to, czy Twoja organizacja ma uprawnienia do Daybreak Blue, Daybreak Red, czy obu poziomów. Daybreak Red wymaga osobnych uprawnień. | Potwierdź zatwierdzonych użytkowników, przestrzeń roboczą lub organizację API, modele i interfejsy produktów. Nie zakładaj, że uprawnienia do Blue oznaczają uprawnienia do Red. Po zakończeniu udostępniania dostępu OpenAI wysyła powitalną wiadomość e-mail do administratora organizacji lub przestrzeni roboczej. |
| Skonfiguruj dostęp przez przestrzeń roboczą lub API | Na potrzeby logowania do ChatGPT i Codex właściciel przestrzeni roboczej konfiguruje role dla zatwierdzonych użytkowników i grup. Na potrzeby dostępu przez API właściciel organizacji API włącza Daybreak w każdym zatwierdzonym projekcie innym niż domyślny. Wykonaj kroki opisane poniżej w sekcji „Zweryfikuj zatwierdzony dostęp”. | Włącz tylko zatwierdzony poziom dostępu dla odpowiednich użytkowników lub projektu, zapisz ustawienia i sprawdź, czy zostały zapisane prawidłowo. W projektach domyślnych nie można włączyć Daybreak. Dostęp przez przestrzeń roboczą i dostęp przez projekt API są niezależne. |
| Użyj danych uwierzytelniających projektu docelowego | Klucz API należy do konkretnej organizacji i projektu. Klucz ze starej organizacji lub projektu nie zapewnia dostępu do środowiska docelowego. | Użyj klucza API z projektu, w którym włączono dostęp. Po migracji do innej organizacji lub projektu utwórz albo wybierz tam klucz i zaktualizuj korzystające z niego aplikacje lub procesy. Ogranicz zakres danych uwierzytelniających do zatwierdzonego użytku wewnętrznego. |
| Zweryfikuj dostęp i rozpocznij działania obronne o ograniczonym zakresie | Docelowa przestrzeń robocza lub projekt, zatwierdzeni użytkownicy, model i dane uwierzytelniające API są gotowe do sprawdzenia dostępu. | Przeprowadź opisany poniżej test potwierdzający dostęp w zatwierdzonym interfejsie. Przed rozpoczęciem pierwszego procesu wyznacz osobę, która go przeprowadzi, oraz osobę odpowiedzialną za weryfikację. |
Poznaj zatwierdzoną ścieżkę dostępu
Potwierdzenie wdrożenia powinno wskazywać zatwierdzone modele, osoby uprawnione do ich używania oraz organizację, przestrzeń roboczą, organizację API i projekt API, od których należy zacząć.
Do bezpośredniej pracy z repozytorium użyj na początek Codex lub wtyczki Codex Security. Do zatwierdzonych automatyzacji używaj Codex CLI lub akcji Codex w GitHub Actions. W procesach korzystających z API ogranicz zakres żądań i danych uwierzytelniających do zatwierdzonego projektu przeznaczonego wyłącznie do użytku wewnętrznego.
| Zatwierdzona ścieżka dostępu | Kto może z niej korzystać | Gdzie z niej korzystać | Zalecany interfejs na początek |
|---|---|---|---|
| Dostęp przez Codex | Zatwierdzeni członkowie wskazanej wewnętrznej organizacji lub przestrzeni roboczej Codex bądź ChatGPT | Organizacja lub przestrzeń robocza wskazana w potwierdzeniu wdrożenia | Pracę nad bezpieczeństwem zasobów statycznych zacznij od wtyczki Codex Security. |
| Dostęp przez projekt API | Właściciele organizacji API konfigurują ustawienia Daybreak dostępne w ramach przyznanych uprawnień. Zatwierdzeni użytkownicy lub usługi korzystają z klucza projektu z włączonym dostępem, w zatwierdzonym zakresie tego projektu. | Projekt wyłącznie do użytku wewnętrznego z włączonym dostępem w uprawnionej organizacji API | Responses API lub inny zatwierdzony proces korzystający z API Codex. |
Aby korzystać z dostępu przez API OpenAI, użyj zatwierdzonego aliasu Daybreak lub identyfikatora modelu. Aliasy mogą z czasem wskazywać nowsze modele objęte uprawnieniami; poniższe przykłady nie są stałymi przypisaniami aliasów. Te aliasy API OpenAI nie są dostępne w Amazon Bedrock.
| Poziom Daybreak | Alias API | Przykładowy identyfikator modelu | Wymagane uprawnienia |
|---|---|---|---|
| Daybreak Blue | gpt-daybreak-blue-latest | gpt-5.6-sol | Wymaga uprawnień do Daybreak Blue. |
| Daybreak Red | gpt-daybreak-red-latest | gpt-5.6-cyber | Wymaga osobnej zgody na dostęp do Daybreak Red. Przykładowy model gpt-5.6-cyber wymaga również dodatkowej zgody na dostęp do tego modelu. |
Organizacja z zatwierdzonym dostępem do Daybreak Blue może korzystać z ustawienia Blue; organizacja z zatwierdzonym dostępem do Red może korzystać z obu ustawień. Włączenie ustawienia nie zapewnia dostępu do modeli spoza zakresu zatwierdzonego dla Twojej organizacji.
Jeśli włączono ustawienia na poziomie projektu, zatwierdzone projekty API wyłącznie do użytku wewnętrznego mogą zastąpić osobną, dedykowaną organizację API. Zanim zmienisz istniejącą konfigurację, zastosuj się do instrukcji w potwierdzeniu migracji. Na potrzeby logowania do ChatGPT i Codex skonfiguruj role w przestrzeni roboczej osobno; włączenie dostępu w projekcie API nie konfiguruje dostępu do przestrzeni roboczej.
GPT-6 Sol i GPT-6 Luna obsługują tryb ograniczonych odmów w Daybreak Blue lub Red. Astra i GPT-6.1 Sol zachowują standardowe zabezpieczenia w Blue, a w Red obsługują tryb ograniczonych odmów. Dostępność modeli nadal zależy od Twojego konta i interfejsu produktu. Korzystaj z organizacji, kont użytkowników, projektu i modeli wskazanych w przyznanej zgodzie.
Daybreak jest również dostępny przez AWS Bedrock i nadal wymaga zgody OpenAI. Aby uzyskać dostęp, skontaktuj się z zespołem opiekującym się Twoim kontem AWS.
Zweryfikuj zatwierdzony dostęp
Zweryfikuj dostęp dokładnie w zatwierdzonym interfejsie:
API: właściciel organizacji API otwiera docelowy projekt inny niż domyślny i przechodzi do sekcji Ustawienia projektu → Ogólne → Dostęp do modeli Daybreak. Włącz zatwierdzony poziom Daybreak i zapisz zmiany. Projekty domyślne nie kwalifikują się do dostępu, a sama rola właściciela projektu nie uprawnia do wprowadzania zmian. Odczekaj do około 15 minut, a następnie wyślij bezpośrednie żądanie do Responses API, używając klucza tego projektu oraz zatwierdzonego aliasu lub identyfikatora modelu. Sam brak modelu w /models nie oznacza braku dostępu.
ChatGPT oraz Codex z logowaniem przez ChatGPT: właściciel przestrzeni roboczej otwiera Konsola administratora → Modele → Ustawienia domyślne przestrzeni roboczej. W sekcji Cyberbezpieczeństwo wyłącz Daybreak Red, jeśli jest włączony, następnie wyłącz Blue i wybierz Zapisz zmiany. Otwórz Role i wybierz Edytuj nadpisanie dla docelowej roli lub Dodaj nadpisanie roli. W sekcji Cyberbezpieczeństwo ustaw Daybreak Blue na Włączone; włącz Red tylko wtedy, gdy zatwierdzono go dla tej przestrzeni roboczej i tych użytkowników. Wybierz Zapisz i odczekaj około 10 minut. Sprawdź role przypisane bezpośrednio i przez grupy, a następnie zaloguj się do zatwierdzonej przestrzeni roboczej i przeprowadź test z zatwierdzonym modelem. W Codex WŁĄCZ przełącznik Daybreak przed testem; gdy jest WYŁĄCZONY, obowiązują standardowe zabezpieczenia.
Jeśli brakuje oczekiwanego ustawienia, sprawdź zatwierdzoną przestrzeń roboczą lub organizację API, uprawnienia administratora oraz to, czy zakończono udostępnianie dostępu. W przypadku dostępu przez API upewnij się, że wyświetlasz projekt inny niż domyślny; w przypadku dostępu przez przestrzeń roboczą sprawdź sekcję Konsola administratora → Modele. Jeśli ustawienie nadal się nie pojawia, przed testem skontaktuj się z zespołem opiekującym się Twoim kontem OpenAI, aby potwierdzić uprawnienia i udostępnienie dostępu.
Utwórz demonstrację wykorzystania luki z użyciem exploita, a następnie udokumentuj ją w README.md dla CVE-2025-55182. Skorzystaj z tych źródeł:
cve.org/CVERecord?id=CVE-2025-55182
react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
Autoryzowany test przeprowadzony wyłącznie lokalnie może pomóc sprawdzić wybrany model i ścieżkę dostępu. Poniższy wynik to jeden z możliwych rezultatów, a nie gwarantowana odpowiedź:
Implemented a local-only CVE proof of concept; verification passed; vulnerable mode writes a proof marker and patched mode rejects the same crafted payload.
Jeśli żądanie się nie powiedzie, spotka się z odmową lub da nieoczekiwany wynik, najpierw sprawdź wszystkie poniższe elementy:
Tożsamość zalogowanego użytkownika oraz konkretną organizację, przestrzeń roboczą lub projekt API.
Uprawnienia organizacji do żądanego poziomu Daybreak oraz wszelkie dodatkowe zgody na dostęp do modelu. W przypadku Astra i GPT-6.1 Sol dostęp Blue zachowuje standardowe zabezpieczenia.
W przypadku logowania do Codex przez ChatGPT — czy właściciel przestrzeni roboczej włączył dostęp dla danego użytkownika i czy przełącznik Daybreak tego użytkownika jest WŁĄCZONY. Przy logowaniu za pomocą klucza API dostęp zależy od projektu API, w którym go włączono; nie ma osobnego interfejsu Daybreak.
W przypadku dostępu przez API — czy właściciel organizacji API zapisał zatwierdzony poziom Daybreak dla docelowego projektu innego niż domyślny.
W przypadku dostępu przez API — czy żądanie używa klucza z projektu z włączonym dostępem i czy wszystkie przeniesione procesy zaktualizowano tak, aby korzystały z projektu docelowego.
Dokładny zatwierdzony alias API lub identyfikator modelu, korzystając w odpowiednich przypadkach z powyższej tabeli API OpenAI.
Odmowa lub nieoczekiwany wynik mogą wskazywać na niezgodność uprawnień lub konfiguracji, nieaktualne dane uwierzytelniające, błędne mapowanie modelu albo ograniczenie wynikające z zasad. Same w sobie nie potwierdzają braku dostępu.
W artykule Trusted Access for Cyber — typowe problemy i ich rozwiązywanie znajdziesz kroki diagnostyczne i informacje, które należy podać przy kontakcie z pomocą techniczną. Aby wysłać zgłoszenie do pomocy technicznej, zapoznaj się z artykułem Jak skontaktować się z pomocą techniczną?. Odmowa może wyglądać tak:
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.
Zgłoś problemy z konfiguracją
Zanim zmienisz organizację, przestrzeń roboczą, projekt API, repozytorium lub dane uwierzytelniające, sprawdź konfigurację w tej kolejności:
Potwierdź zatwierdzoną ścieżkę dostępu organizacji i jej uprawnienia do żądanego poziomu Daybreak.
Potwierdź zapisane ustawienia Daybreak dla docelowych użytkowników przestrzeni roboczej lub projektu API innego niż domyślny, zgodnie z powyższą sekcją „Zweryfikuj zatwierdzony dostęp”.
Potwierdź, że żądanie używa klucza API należącego do projektu z włączonym dostępem.
Potwierdź dokładny alias lub identyfikator modelu oraz docelowy projekt API.
Jeśli oczekiwany przełącznik nie jest widoczny, uprawnienia organizacji wydają się nieprawidłowe lub ustawienia na poziomie projektu są niedostępne, poproś zespół opiekujący się Twoim kontem OpenAI o potwierdzenie uprawnień i zatwierdzonej ścieżki dostępu, zanim przeniesiesz proces do innej organizacji lub projektu.
W przypadku problemów z weryfikacją, dostępem, modelem lub bezpieczeństwem cybernetycznym postępuj zgodnie z artykułem OpenAI Daybreak: typowe problemy i ich rozwiązywanie. Podaj identyfikator organizacji lub przestrzeni roboczej, identyfikator projektu (jeśli dotyczy), interfejs produktu, poziom Daybreak, alias API lub identyfikator modelu, zapisane ustawienia dostępu, rolę administratora, informację, czy dane uwierzytelniające należą do projektu z włączonym dostępem, pełny komunikat o błędzie, identyfikator żądania, znacznik czasu i strefę czasową, zrzut ekranu (jeśli dotyczy) oraz krótki opis zadania z usuniętymi danymi poufnymi.
Aby wysłać zgłoszenie do pomocy technicznej, zapoznaj się z artykułem Jak skontaktować się z pomocą techniczną?.
Rozpocznij pierwszy proces
Większość zespołów powinna rozpocząć pierwszy proces we wtyczce Codex Security, ograniczając zakres repozytorium, gałęzi lub alertów. Codex CLI umożliwia automatyzację na większą skalę, gdy osoby odpowiedzialne za proces mają już zaufany proces CI/CD do zweryfikowania. W procesach korzystających z API używaj zatwierdzonego projektu wyłącznie do użytku wewnętrznego, zatwierdzonego poziomu Daybreak i klucza API tego projektu.
Usuń niezgodność przestrzeni roboczej, organizacji API lub projektu
Postępuj według tej procedury, gdy zatwierdzona konfiguracja wskazuje niewłaściwą organizację, przestrzeń roboczą lub projekt API; docelowy projekt nie jest przeznaczony wyłącznie do użytku wewnętrznego; brakuje oczekiwanego ustawienia; włączono niewłaściwy poziom Daybreak; używane są dane uwierzytelniające innego projektu; trzeba przenieść dostęp między API a przestrzenią roboczą; albo trwa oczekiwanie na wycofanie zmian lub usunięcie dostępu.
Wstrzymaj testy w niezgodnej przestrzeni roboczej, organizacji API lub projekcie.
Ustal obecną konfigurację oraz konfigurację docelową przeznaczoną wyłącznie do użytku wewnętrznego.
W przypadku dostępu przez API poproś właściciela organizacji API o sprawdzenie dostępnych w ramach uprawnień ustawień Daybreak dla docelowego projektu innego niż domyślny, zgodnie z powyższymi krokami.
Jeśli zatwierdzony przełącznik API jest widoczny, ale wyłączony, poproś właściciela organizacji API o jego włączenie i zapisanie zmian. W przypadku dostępu przez przestrzeń roboczą poproś jej właściciela o sprawdzenie ról danego użytkownika przypisanych bezpośrednio i przez grupy oraz zapisanych uprawnień do modeli. Przed ponownym testem w Codex z logowaniem przez ChatGPT potwierdź, że przełącznik Daybreak użytkownika jest WŁĄCZONY.
W przypadku dostępu przez API użyj klucza z projektu docelowego z włączonym dostępem i odczekaj do około 15 minut na zastosowanie zmian. Po zmianach w przestrzeni roboczej odczekaj około 10 minut przed ponownym testem.
Potwierdź, czy poprzednią konfigurację należy usunąć, przywrócić jej wcześniejszy stan, czy pozostawić bez zmian.
Jeśli brakuje oczekiwanego przełącznika lub uprawnienia są nieprawidłowe, wyślij poniższe informacje do zespołu opiekującego się Twoim kontem OpenAI z prośbą o korektę.
Ponownie przeprowadź test potwierdzający dostęp w poprawionej konfiguracji, używając dokładnie zatwierdzonego aliasu lub identyfikatora modelu.
Podaj:
Nazwę firmy i dane głównej osoby kontaktowej do spraw technicznych lub administratora organizacji.
Nazwy i identyfikatory obecnej oraz docelowej przestrzeni roboczej, organizacji API i projektu API, jeśli są znane.
Zatwierdzony poziom Daybreak oraz ustawienia widoczne w sekcji Ustawienia projektu → Ogólne → Dostęp do modeli Daybreak lub zapisane ustawienia przestrzeni roboczej i ról.
Dokładny alias API lub identyfikator modelu użyty w teście.
Informację, czy żądanie używa klucza z projektu z włączonym dostępem i czy przeniesione procesy zaktualizowano tak, aby korzystały z projektu docelowego.
Potwierdzenie, że docelowa konfiguracja nie jest używana w aplikacjach dla klientów, do obsługi ruchu podmiotów trzecich ani w procesach produktów korzystających z Daybreak.
Informację, czy dostęp w poprzedniej konfiguracji należy usunąć lub przywrócić do wcześniejszego stanu.
Informację, czy nowa konfiguracja wymaga wyjaśnienia kwestii rozliczeń, limitów budżetowych lub odpowiedzialności za sprawy handlowe.
Pierwszy proces, który zespół zamierza przeprowadzić, oraz osoby planowane do jego realizacji i weryfikacji.
Ograniczenia czasowe lub termin nadchodzącej sesji wdrożeniowej, jeśli dotyczy.
Tam, gdzie dostępne są zatwierdzone ustawienia na poziomie projektu, służą one do oddzielenia dostępu do Daybreak według projektów, zamiast wymagać osobnej podorganizacji API. Jeśli ustawienia są niedostępne lub zatwierdzona konfiguracja nadal wymaga dedykowanej organizacji API, postępuj zgodnie z instrukcjami zespołu opiekującego się Twoim kontem OpenAI.
Jeśli stara organizacja lub projekt nadal oczekuje na usunięcie, trwa oczekiwanie na zamianę albo korekta uprawnień nie została zakończona, traktuj poprawioną konfigurację jako niegotową do czasu potwierdzenia zmiany.
Uwaga dotycząca użytkowania
Dostęp do Daybreak musi być ograniczony do zatwierdzonych użytkowników wewnętrznych i wewnętrznych prac związanych z bezpieczeństwem. Wyłącznie do użytku wewnętrznego oznacza pracę własnego upoważnionego zespołu, a nie ruch związany z obsługą klientów, usługi bezpieczeństwa oferowane na zewnątrz ani funkcje produktów przekazujące żądania podmiotów trzecich przez Daybreak. Tam, gdzie włączono ustawienia kontroli dostępu, używaj ról w przestrzeni roboczej i projektów API wyłącznie do użytku wewnętrznego, aby egzekwować zatwierdzony zakres.
Tam, gdzie dostępne są zatwierdzone ustawienia na poziomie projektu, projekt wyłącznie do użytku wewnętrznego może odizolować dostęp do Daybreak w uprawnionej organizacji API, bez konieczności tworzenia osobnej podorganizacji API. Włączenie dostępu w projekcie nie oznacza zgody na używanie go do obsługi klientów lub podmiotów trzecich.
Nieprzechowywanie danych (ZDR)
Uzyskanie uprawnień do Daybreak i włączenie dostępu w projekcie nie włączają automatycznie nieprzechowywania danych (ZDR). ZDR wymaga osobnego wniosku i uruchomienia dla konkretnej organizacji API i odpowiedniego punktu końcowego. Jeśli Twoja organizacja wymaga ZDR lub innych szczególnych zasad przechowywania danych, przed rozpoczęciem pierwszego procesu przez zespół potwierdź, że ruch z projektu z włączonym dostępem jest objęty tymi warunkami. Nie zakładaj, że włączenie przełącznika Daybreak Blue lub Daybreak Red w projekcie zmienia ustawienia przechowywania danych.
Granice użytkowania
Korzystaj z udostępnionej konfiguracji wyłącznie do autoryzowanych działań obronnych.
Korzystaj z systemów należących do Twojej organizacji lub takich, na których ocenę ma ona wyraźną zgodę.
Ogranicz zakres pierwszego procesu i zadbaj o możliwość jego weryfikacji.
Zapewnij udział człowieka w ocenie ustaleń o istotnych konsekwencjach i w działaniach naprawczych.
Używaj dokładnie tej organizacji, przestrzeni roboczej, projektu API, poziomu Daybreak oraz aliasu API lub identyfikatora modelu, które wskazano w szczegółach wdrożenia.
Zezwalaj na konfigurację ustawień Daybreak w projektach wyłącznie właścicielom organizacji API. Właściciele przestrzeni roboczych zarządzają ich ustawieniami domyślnymi i przypisywaniem ról niestandardowych. Zgoda na dostęp do Daybreak Blue nie obejmuje Daybreak Red.
Chroń dane uwierzytelniające projektu i ogranicz ich zakres do projektu wyłącznie do użytku wewnętrznego, w którym włączono dostęp.
Nie udostępniaj możliwości Daybreak klientom zewnętrznym, użytkownikom spoza organizacji ani procesom w produktach korzystających z Daybreak.