Ընդհանուր նկարագիր

Օգտվեք այս ուղեցույցից, եթե համակարգում եք ձեր կազմակերպության միացումը Daybreak-ին և պետք է հայտի ընդունման ու իրավասության ստուգման փուլից անցնեք աշխատանքի պատրաստ կարգավորմանը։

Daybreak Access-ը OpenAI-ի՝ կիբեռանվտանգության համար վստահելի հասանելիության ծրագիրն է։ Daybreak Blue-ը և Daybreak Red-ը Daybreak-ի հասանելիության մակարդակներն են։

Կորպորատիվ թիմերի մեծ մասը ներքին պաշտպանական հաստատված աշխատանքների համար պետք է սկսի Daybreak Blue-ից։

Daybreak Red-ը պահանջում է առանձին հաստատում՝ կիբեռանվտանգության առաջադեմ, թույլատրված աշխատանքների համար։ Daybreak Red-ից օգտվող բոլոր կազմակերպություններն ունեն GPT-5.6 Cyber-ից օգտվելու իրավասություն։ GPT-6 Cyber-ի համար պահանջվում է մոդելի առանձին հաստատում։ Յուրաքանչյուր կազմակերպությունում կամ աշխատատարածքում, որտեղ օգտագործում եք Daybreak Red-ը, միացրեք և պարտադիր դարձրեք միասնական մուտքը (SSO)։ Լռելյայն GPT-6 Cyber API-ի հասանելիության համար պահանջվում է IP հասցեների թույլատրելի ցանկի սահմանում։ «Ոչ մի պահվող տվյալ» կարգավորումն օգտագործող API նախագծերի համար սովորաբար պահանջվում է նաև անվտանգության մասնավոր մշակում։

Միայն հաստատումը չի միացնում մերժումների նվազեցումը։ Daybreak-ի կառավարման տարրերը սկզբում ԱՆՋԱՏՎԱԾ են։ Աշխատատարածքի սեփականատերը հասանելիությունը միացնում է հաստատված օգտատերերի և խմբերի համար, իսկ API կազմակերպության սեփականատերը՝ հաստատված ոչ լռելյայն նախագծերի համար։ Եթե ձեր թիմն օգտագործում է հասանելիության երկու եղանակն էլ, կարգավորեք երկուսն էլ։ ChatGPT-ով Codex մուտք գործող օգտատերերը նույնպես պետք է միացնեն Daybreak-ը՝ նախքան հարցում ուղարկելը։

Ավելի բարձր ռիսկով որոշ աշխատանքներ կարող են մերժվել նույնիսկ հասանելիությունը միացնելուց հետո։ Ուստի սկսեք հստակ սահմանված պաշտպանական աշխատանքից՝ հենց այն միջավայրում, նախագծում և մոդելով, որոնք ձեր թիմը նախատեսում է օգտագործել։

Հետևեք միացման ընթացքին և հասանելիության վիճակին

Ծանոթացեք հասանելիության հաստատված եղանակին

Միացման հաստատման մեջ պետք է նշված լինի, թե որ մոդելներն են հաստատված, ովքեր կարող են օգտագործել դրանք, և որ կազմակերպությունը, աշխատատարածքը, API կազմակերպությունն ու API նախագիծը պետք է օգտագործել սկզբում։

Պահոցում գործնական աշխատանքների համար սկսեք Codex-ից կամ Codex Security փլագինից։ Հաստատված ավտոմատացման համար օգտագործեք Codex CLI կամ Codex GitHub Action։ API-ով աշխատանքներում հարցումներն ու մուտքի տվյալները սահմանափակեք միայն ներքին օգտագործման համար հաստատված նախագծի շրջանակով։

OpenAI API-ից օգտվելու համար օգտագործեք ձեզ տրամադրված հասանելիության շրջանակում հաստատված մոդելի կոնկրետ ID-ն և հարցման համապատասխան Daybreak կարգավորումը։ Ստորև բերված օրինակների կիրառելիությունը կախված է ձեր կազմակերպության համար հաստատված մոդելներից։

Responses API-ի հարցումներում gpt-6-sol-ի համար access_programs.cyber-ի արժեքը սահմանեք daybreak_blue, նույնիսկ եթե ձեր կազմակերպությունն ունի Daybreak Red-ի հաստատում։ Ստանդարտ պաշտպանական միջոցները կիրառելու համար արժեքը սահմանեք standard։

Երկու Cyber մոդելների համար էլ Responses API-ում օգտագործեք 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 թիմին։

Ստուգեք GPT-6.1 Terra-ի աշխատանքը Daybreak-ի հետ

GPT-6.1 Terra-ի համար համոզվեք, որ ունեք Daybreak Red-ի հաստատում, և հարցման համար բացահայտ միացրեք Daybreak-ը։ Միայն Daybreak Blue-ը չի միացնում Terra-ում կիբեռանվտանգության հարցումների մերժումների նվազեցումը։ Responses API-ում օգտագործեք միացված՝ ոչ լռելյայն նախագծի բանալին և բացահայտ սահմանեք access_programs.cyber-ի արժեքը․ այն բաց թողնելու դեպքում կիրառվում են ստանդարտ պաշտպանական միջոցները։ Chat Completions-ը չի աջակցում մերժումների նվազեցման այս եղանակին։

Codex-ի և ChatGPT Work-ի համար ստուգեք հաստատված աշխատատարածքն ու օգտատիրոջ Daybreak հասանելիությունը, օգտագործեք աջակցվող հաճախորդային հավելված և միացրեք Daybreak-ի կառավարման տարրը։ API-ի և աշխատատարածքի հասանելիությունը ստուգեք առանձին։ Եթե հաստատված հարցումը դեռ չի հաջողվում, գրանցեք ճշգրիտ մոդելը, վերջնակետը կամ արտադրանքի միջավայրը, կազմակերպությունը, նախագիծը կամ աշխատատարածքը, միացված կառավարման տարրերը, հարցման ID-ն, ժամանակային նշումը և սխալի հաղորդագրությունը՝ գաղտնի տվյալները հեռացրած։

Ստուգեք հաստատված հասանելիությունը

Ստուգեք հասանելիությունը հենց հաստատված միջավայրում․

• API․ API կազմակերպության սեփականատերը բացում է նախատեսված ոչ լռելյայն նախագիծը և անցնում «Նախագծի կարգավորումներ → Ընդհանուր → Daybreak մոդելների հասանելիություն» բաժին։ Միացրեք Daybreak-ի հաստատված մակարդակը և պահպանեք։ Լռելյայն նախագծերն իրավասու չեն, իսկ միայն նախագծի սեփականատեր լինելը փոփոխություններ կատարելու իրավունք չի տալիս։ Սպասեք մինչև մոտ 15 րոպե, ապա ուղարկեք Responses API-ի ուղիղ հարցում՝ օգտագործելով այդ նախագծի բանալին և հաստատված մոդելի ID-ն։ Մոդելի բացակայությունը /models-ից ինքնին չի նշանակում, որ այն հասանելի չէ։

• ChatGPT և Codex՝ ChatGPT-ով մուտքի դեպքում․ աշխատատարածքի սեփականատերը բացում է Ադմինիստրատորի վահանակ → Մոդելներ → Աշխատատարածքի լռելյայն կարգավորումներ բաժինը։ «Կիբեռանվտանգություն» բաժնում անջատեք Daybreak Red-ը, եթե այն միացված է, ապա անջատեք Blue-ը և ընտրեք «Պահպանել փոփոխությունները»։ Բացեք «Դերեր» բաժինը և նախատեսված դերի համար ընտրեք «Խմբագրել վերասահմանումը» կամ «Ավելացնել դերի վերասահմանում»։ «Կիբեռանվտանգություն» բաժնում Daybreak Blue-ը դրեք «Միացված» վիճակի․ Red-ը միացրեք միայն այն դեպքում, երբ այն հաստատված է աշխատատարածքի և այդ օգտատերերի համար։ Ընտրեք «Պահպանել» և սպասեք մոտ 10 րոպե։ Ստուգեք անմիջապես և խմբերի միջոցով նշանակված դերերը, ապա մուտք գործեք հաստատված աշխատատարածք և փորձարկեք հաստատված մոդելով։ Codex-ում փորձարկումից առաջ Daybreak-ի փոխարկիչը դրեք ՄԻԱՑՎԱԾ վիճակի․ ԱՆՋԱՏՎԱԾ վիճակում կիրառվում են ստանդարտ պաշտպանական միջոցները։

Եթե ակնկալվող կառավարման տարրը բացակայում է, ստուգեք հաստատված աշխատատարածքը կամ API կազմակերպությունը, ադմինիստրատորի թույլտվությունները և արդյոք հասանելիության տրամադրումն ավարտված է։ API-ի հասանելիության դեպքում համոզվեք, որ դիտում եք ոչ լռելյայն նախագիծ, իսկ աշխատատարածքի հասանելիության դեպքում ստուգեք «Ադմինիստրատորի վահանակ → Մոդելներ» բաժինը։ Եթե կառավարման տարրը դեռ չի հայտնվում, նախքան փորձարկելը դիմեք ձեր հաշիվը սպասարկող 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.

Եթե հարցումը ձախողվում է, մերժվում կամ տալիս է անսպասելի արդյունք, նախ ստուգեք հետևյալ բոլորը․

• Մուտք գործած օգտահաշիվը և կոնկրետ կազմակերպությունը, աշխատատարածքը կամ API նախագիծը։

• Ձեր կազմակերպության՝ Daybreak-ի պահանջվող մակարդակից օգտվելու իրավասությունը, իսկ GPT-6 Cyber-ի դեպքում՝ նաև այդ մոդելի հաստատումը։ Astra-ի կամ GPT-6.1 Sol-ի դեպքում Blue հասանելիությունը պահպանում է ստանդարտ պաշտպանական միջոցները։

• ChatGPT-ով Codex մուտք գործելու դեպքում՝ արդյոք աշխատատարածքի սեփականատերը միացրել է նախատեսված օգտատիրոջ հասանելիությունը, և օգտատիրոջ Daybreak փոխարկիչը ՄԻԱՑՎԱԾ է։ API բանալիով մուտք գործելու դեպքում հասանելիությունը որոշվում է միացված API նախագծով․ Daybreak-ի առանձին միջերես չկա։

• API-ի հասանելիության դեպքում՝ արդյոք API կազմակերպության սեփականատերը պահպանել է Daybreak-ի հաստատված մակարդակը նախատեսված ոչ լռելյայն նախագծի համար։

• API-ի հասանելիության դեպքում՝ արդյոք հարցումն օգտագործում է միացված նախագծի բանալին, և բոլոր տեղափոխված աշխատանքային գործընթացները թարմացվել են՝ նպատակային նախագիծն օգտագործելու համար։

• Հաստատված մոդելի ճշգրիտ ID-ն՝ անհրաժեշտության դեպքում օգտվելով վերը բերված 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-ի մակարդակի համար։ GPT-6 Cyber-ի դեպքում ստուգեք, որ հաստատումը ներառում է այդ մոդելը։

• Ստուգեք աշխատատարածքի նախատեսված օգտատերերի կամ ոչ լռելյայն API նախագծի համար պահպանված Daybreak կարգավորումները՝ հետևելով վերը բերված «Ստուգեք հաստատված հասանելիությունը» բաժնի ցուցումներին։

• Համոզվեք, որ հարցումն օգտագործում է միացված նախագծին պատկանող API բանալի։

• Ստուգեք մոդելի ճշգրիտ ID-ն և նախատեսված API նախագիծը։

Եթե ակնկալվող փոխարկիչը չի երևում, կազմակերպության իրավասությունը սխալ է նշված թվում, կամ նախագծի կառավարման տարրերը հասանելի չեն, նախքան աշխատանքային գործընթացը մեկ այլ կազմակերպություն կամ նախագիծ տեղափոխելը խնդրեք ձեր հաշիվը սպասարկող OpenAI թիմին հաստատել իրավասությունն ու հասանելիության հաստատված եղանակը։

Ստուգման, հասանելիության, մոդելի կամ կիբեռանվտանգության հետ կապված խնդիրների դեպքում հետևեք OpenAI Daybreak․ տարածված խնդիրներ և դրանց լուծումը ուղեցույցին։ Ներառեք ձեր կազմակերպության կամ աշխատատարածքի ID-ն, անհրաժեշտության դեպքում՝ նախագծի ID-ն, արտադրանքի միջավայրը, Daybreak-ի մակարդակը, մոդելի ID-ն, կառավարման տարրերի պահպանված կարգավորումները, ադմինիստրատորի դերը, նշում այն մասին, թե արդյոք մուտքի տվյալները պատկանում են միացված նախագծին, սխալի ամբողջական հաղորդագրությունը, հարցման ID-ն, ժամանակային նշումն ու ժամային գոտին, անհրաժեշտության դեպքում՝ էկրանակադրը, ինչպես նաև առաջադրանքի համառոտ նկարագրությունը՝ գաղտնի տվյալները հեռացրած։

Աջակցման հարցում ներկայացնելու համար տե՛ս Ինչպե՞ս կարող եմ կապվել աջակցման ծառայության հետ։

Սկսեք առաջին աշխատանքային գործընթացը

Թիմերի մեծ մասի համար առաջին աշխատանքային գործընթացը պետք է սկսել Codex Security փլագինում՝ սահմանափակվելով պահոցի, ճյուղի կամ ահազանգերի նեղ շրջանակով։ Codex CLI-ն լայնածավալ ավտոմատացման եղանակն է այն դեպքերում, երբ գործընթացի պատասխանատուներն արդեն ունեն վստահելի CI/CD աշխատանքային գործընթաց, որը պետք է ստուգել։ API-ով աշխատանքային գործընթացների համար օգտագործեք հաստատված՝ միայն ներքին օգտագործման նախագիծը, Daybreak-ի հաստատված մակարդակը և այդ նախագծի API բանալին։

Շտկեք աշխատատարածքի, API կազմակերպության կամ նախագծի անհամապատասխանությունը

Հետևեք այս ընթացակարգին, եթե հաստատված կազմաձևում նշված է սխալ կազմակերպություն, աշխատատարածք կամ API նախագիծ, նախատեսված նախագիծը միայն ներքին օգտագործման համար չէ, ակնկալվող կառավարման տարրը բացակայում է, միացված է Daybreak-ի սխալ մակարդակ, օգտագործվում են այլ նախագծի մուտքի տվյալներ, անհրաժեշտ է API հասանելիությունից անցնել աշխատատարածքի հասանելիության կամ հակառակը, կամ դեռ սպասվում է նախկին վիճակի վերականգնում կամ հեռացում։

• Դադարեցրեք փորձարկումները անհամապատասխան աշխատատարածքում, API կազմակերպությունում կամ նախագծում։

• Հստակեցրեք ընթացիկ և նախատեսված՝ միայն ներքին օգտագործման կազմաձևերը։

• API հասանելիության դեպքում խնդրեք API կազմակերպության սեփականատիրոջը վերը նշված քայլերով ստուգել Daybreak-ի թույլատրված կառավարման տարրերը նախատեսված՝ ոչ լռելյայն նախագծի համար։

• Եթե API-ի թույլատրված փոխարկիչը տեսանելի է, բայց անջատված, խնդրեք API կազմակերպության սեփականատիրոջը միացնել այն և պահպանել։ Աշխատատարածքի հասանելիության դեպքում խնդրեք աշխատատարածքի սեփականատիրոջը ստուգել նախատեսված օգտատիրոջ ուղղակի և խմբային դերերն ու մոդելների պահպանված թույլտվությունները։ ChatGPT-ով Codex մուտք գործելիս կրկնակի փորձարկումից առաջ համոզվեք, որ օգտատիրոջ Daybreak փոխարկիչը միացված է։

• API հասանելիության դեպքում օգտագործեք ակտիվացված նպատակային նախագծի բանալին և սպասեք մինչև մոտ 15 րոպե, որպեսզի փոփոխությունները կիրառվեն։ Կրկին փորձարկելուց առաջ մոտ 10 րոպե սպասեք, որպեսզի աշխատատարածքի փոփոխությունները կիրառվեն։

• Հստակեցրեք՝ հին կազմաձևը պետք է հեռացնել, վերականգնել նախկին վիճակին, թե թողնել անփոփոխ։

• Եթե ակնկալվող փոխարկիչը բացակայում է, կամ օգտվելու իրավունքը սխալ է նշված, ստորև նշված տվյալներն ուղարկեք ձեր հաշիվը սպասարկող OpenAI-ի թիմին՝ որպես շտկման հարցում։

• Շտկված կազմաձևում կրկին կատարեք հասանելիության հաստատման ստուգումը՝ օգտագործելով թույլատրված մոդելի ճշգրիտ ID-ն։

Ներառեք՝

• Ընկերության անունը և հիմնական տեխնիկական պատասխանատուի կամ կազմակերպության ադմինիստրատորի կոնտակտային տվյալները։

• Ընթացիկ և նախատեսված աշխատատարածքի, API կազմակերպության ու API նախագծի անուններն ու ID-ները, եթե հայտնի են։

• Daybreak-ի թույլատրված մակարդակը և «Նախագծի կարգավորումներ → Ընդհանուր → Daybreak մոդելների հասանելիություն» բաժնում տեսանելի կառավարման տարրերը կամ աշխատատարածքի և դերերի պահպանված կարգավորումները։

• Փորձարկման համար օգտագործված մոդելի ճշգրիտ ID-ն։

• Արդյոք հարցումն օգտագործում է ակտիվացված նախագծի բանալի, և արդյոք տեղափոխված աշխատանքային գործընթացները թարմացվել են՝ նպատակային նախագիծն օգտագործելու համար։

• Հաստատում, որ նախատեսված կազմաձևը չի օգտագործվում հաճախորդներին հասանելի հավելվածների, երրորդ կողմերի տրաֆիկի կամ վերջնական արտադրանքի աշխատանքային գործընթացների համար։

• Արդյոք նախորդ կազմաձևում հասանելիությունը պետք է հեռացնել կամ վերականգնել նախկին վիճակին։

• Արդյոք նոր կազմաձևն առաջացնում է վճարման, բյուջեի սահմանաչափի կամ առևտրային պատասխանատուի հետ կապված հարցեր։

• Առաջին աշխատանքային գործընթացը, որը թիմը նախատեսում է իրականացնել, ինչպես նաև դրա նախատեսված կատարողներին ու ստուգումն իրականացնող անձին։

• Ժամկետային սահմանափակումները կամ առաջիկա ուսուցման հանդիպումը, եթե կան։

Եթե նախագծի հաստատված կառավարման տարրերը հասանելի են, դրանք նախատեսված են Daybreak-ի հասանելիությունն ըստ նախագծի առանձնացնելու համար՝ առանց առանձին API ենթակազմակերպություն պահանջելու։ Եթե կառավարման տարրերն անհասանելի են, կամ հաստատված կազմաձևը դեռ պահանջում է առանձին API կազմակերպություն, հետևեք ձեր հաշիվը սպասարկող OpenAI-ի թիմի հրահանգներին։

Եթե հին կազմակերպության կամ նախագծի հեռացումը դեռ սպասվում է, փոխարինումը դեռ չի կատարվել, կամ օգտվելու իրավունքի շտկման հարցը լուծված չէ, շտկված կազմաձևը պատրաստ մի՛ համարեք, մինչև փոփոխությունը չհաստատվի։

Նշում օգտագործման վերաբերյալ

Daybreak-ի հասանելիությունը պետք է սահմանափակվի հաստատված ներքին օգտատերերով և ներքին անվտանգության աշխատանքներով։ «Միայն ներքին օգտագործման» նշանակում է ձեր սեփական լիազորված թիմի աշխատանքը, այլ ոչ թե հաճախորդների հարցումները, արտաքին կողմերին առաջարկվող անվտանգության ծառայությունները կամ այլ արտադրանքների գործառույթները, որոնք երրորդ կողմերի հարցումներն անցկացնում են Daybreak-ի միջոցով։ Եթե կառավարման տարրերը միացված են, կիրառեք աշխատատարածքի դերեր և միայն ներքին օգտագործման API նախագծեր՝ հաստատված շրջանակի պահպանումն ապահովելու համար։

Եթե նախագծի հաստատված կառավարման տարրերը հասանելի են, միայն ներքին օգտագործման նախագիծը կարող է մեկուսացնել Daybreak-ի հասանելիությունն իրավասու API կազմակերպության ներսում՝ առանձին API ենթակազմակերպություն պահանջելու փոխարեն։ Նախագծի ակտիվացումը թույլատրելի չի դարձնում հաճախորդների կամ երրորդ կողմերի համար օգտագործումը։

Ոչ մի պահվող տվյալ (ZDR)

Daybreak-ից օգտվելու իրավասությունն ու նախագծի ակտիվացումը ինքնաբերաբար չեն միացնում «ոչ մի պահվող տվյալ» (ZDR) ռեժիմը։ ZDR-ը պետք է առանձին հայցել և ակտիվացնել կոնկրետ API կազմակերպության և համապատասխան վերջնակետի համար։ Եթե ձեր կազմակերպությունը պահանջում է ZDR կամ տվյալների պահպանման այլ հատուկ ռեժիմ, մինչև թիմի առաջին աշխատանքային գործընթացը սկսելը համոզվեք, որ այդ պայմանները տարածվում են ակտիվացված նախագծի տվյալների հոսքի վրա։ Մի ենթադրեք, որ նախագծի Daybreak Blue կամ Daybreak Red անջատիչը միացնելը փոխում է տվյալների պահպանման կարգավորումները։

Օգտագործման սահմաններ

• Տրամադրված միջավայրն օգտագործեք միայն թույլատրված պաշտպանական աշխատանքների համար։

• Օգտագործեք ձեր կազմակերպությանը պատկանող համակարգերը կամ այն համակարգերը, որոնք գնահատելու հստակ թույլտվություն ունեք։

• Առաջին աշխատանքային գործընթացը պահեք նեղ շրջանակում և ստուգման համար հարմար։

• Լուրջ հետևանքներ ունեցող խնդիրների հայտնաբերման և շտկման գործընթացում ապահովեք մարդկանց ներգրավվածությունը։

• Օգտագործեք հենց այն կազմակերպությունը, աշխատատարածքը, API նախագիծը, Daybreak-ի մակարդակը և մոդելի ID-ն, որոնք նշված են ձեր միացման տվյալներում։

• Daybreak-ի նախագծի կառավարման տարրերը կարգավորելու թույլտվություն տվեք միայն API կազմակերպության սեփականատերերին։ Աշխատատարածքի սեփականատերերը կառավարում են աշխատատարածքի լռելյայն կարգավորումներն ու հատուկ դերերի նշանակումները։ Daybreak Blue-ի թույլտվությունը չի ներառում Daybreak Red-ը։

• Ապահով պահեք նախագծի մուտքի տվյալները և սահմանափակեք դրանց կիրառումը միայն ներքին օգտագործման ակտիվացված նախագծով։

• Daybreak-ի հնարավորությունները մի՛ տրամադրեք երրորդ կողմ հանդիսացող հաճախորդներին կամ արտաքին օգտատերերին և մի՛ կիրառեք դրանք վերջնական արտադրանքի աշխատանքային գործընթացներում։