OpenAI API कुंजी शासन: निर्माण नियम, स्वामित्व, समाप्ति और बिना डाउनटाइम रोटेशन

आप OpenAI API कुंजियों पर expiration लागू करना चाहते हैं, लेकिन नियम चालू करते ही एप्लिकेशन रुकने या अगली rotation में सही replacement key न बन पाने का जोखिम नहीं लेना चाहते। साथ ही आपको तय करना है कि production service के लिए service-account key रखें या developers के लिए user-owned keys.

यह मार्गदर्शिका सीधा क्रम देती है: workload के अनुसार ownership चुनें, उतनी lifetime तय करें जितने में आपकी टीम वास्तव में rotation कर सके, और overlap के साथ पुरानी key हटाएँ। शुरुआत से दो बातें याद रखें: नए creation rules मौजूदा keys को नहीं बदलते, और organization restrictions project settings से ऊपर होती हैं।

पहले निष्कर्ष: नए नियंत्रण भविष्य की keys पर लागू हैं, पुरानी keys पर नहीं

सितंबर के बदलावों को दो नियंत्रणों में समझें: कौन-सी नई key type जारी हो सकती है और नई project key अधिकतम कितने समय तक valid रह सकती है।

तारीख	OpenAI अपडेट	टीम के लिए अर्थ
10 सितंबर 2026	प्रोजेक्ट API कुंजी बनाते समय समाप्ति तिथि दी जा सकती है। प्रशासक संगठन या प्रोजेक्ट स्तर पर अधिकतम कुंजी जीवनकाल लागू कर सकते हैं।	नई कुंजियां अनिश्चितकालीन रखने के बजाय समयबद्ध की जा सकती हैं, लेकिन कम अवधि लागू करने से पहले दोहराने योग्य रोटेशन प्रक्रिया चाहिए।
15 सितंबर 2026	संगठन और प्रोजेक्ट नई कुंजी निर्माण को केवल service-account keys, केवल user-owned project keys, या पूरी तरह बंद करने तक सीमित कर सकते हैं।	उत्पादन सेवाओं, व्यक्तिगत विकास और फ्रीज़ किए गए प्रोजेक्ट के लिए अलग जारीकरण नियम बनाए जा सकते हैं।
15 सितंबर 2026	संगठन के प्रतिबंध प्रोजेक्ट सेटिंग पर प्राथमिकता रखते हैं।	प्रोजेक्ट संगठन की सीमा के भीतर नियम और सख्त कर सकता है, लेकिन उसे ढीला नहीं कर सकता।
15 सितंबर 2026	मौजूदा API कुंजियां नए निर्माण नियंत्रण से प्रभावित नहीं होतीं।	नियम चालू करना पुरानी कुंजियों को रद्द नहीं करता और उनका माइग्रेशन पूरा नहीं करता।

दो सीमाएं याद रखें। “नई कुंजी बनाना बंद” का अर्थ “सभी मौजूदा कुंजियां तुरंत रद्द” नहीं है। इसी तरह 10 सितंबर का अधिकतम जीवनकाल नए बनाए गए कुंजी पर लागू बताया गया है। किसी पुरानी कुंजी पर पिछली तारीख से समाप्ति लग जाएगी, ऐसा वास्तविक प्रोजेक्ट में जांचे बिना न मानें।

तीन फैसले अलग रखें: कौन बनाएगा, कितने समय तक चलेगी और कैसे हटेगी

इन तीनों को अलग डिजाइन करें; Platform का एक switch पूरा key lifecycle नहीं संभालता।

जारीकरण नीति तय करती है कि सेवा-खाता कुंजी, उपयोगकर्ता-स्वामित्व वाली प्रोजेक्ट कुंजी, या कोई भी नई कुंजी बनाई जा सकती है या नहीं।

समाप्ति नीति तय करती है कि नई कुंजी का समाप्त होना अनिवार्य है या नहीं और संगठन तथा प्रोजेक्ट अधिकतम कितनी अवधि की अनुमति देते हैं।

जीवनचक्र निष्पादन तय करता है कि प्रतिस्थापन कौन बनाएगा, सीक्रेट कहां रखा जाएगा, एप्लिकेशन तक कैसे पहुंचेगा, किन संकेतों से कटओवर सत्यापित होगा, पुरानी कुंजी कब रद्द होगी और समस्या पर रोलबैक कैसे होगा।

पहले दो नियम OpenAI Platform में लागू किए जा सकते हैं। तीसरा अब भी आपके सीक्रेट मैनेजर, डिप्लॉयमेंट, मॉनिटरिंग, जिम्मेदारी और घटना प्रक्रिया पर निर्भर है। अधिकतम अवधि तो तय कर देना, लेकिन रोटेशन का मालिक और पर्याप्त समय न देना, सुरक्षा नियंत्रण को नियोजित आउटेज बना सकता है।

स्थिति के अनुसार चुनें: production के लिए service account, personal development के लिए user-owned key

Production और shared workloads के लिए service-account key, local या short-term work के लिए user-owned project key, और केवल सचमुच frozen या retiring projects के लिए नई keys बंद करना प्राथमिक विकल्प है।

उपयोग	आम तौर पर उपयुक्त प्रकार	कारण	मुख्य जोखिम
उत्पादन सेवा, साझा backend, scheduled job, टीम द्वारा चलाया गया agent	service-account key	क्रेडेंशियल किसी व्यक्ति के बजाय workload से जुड़ता है; कर्मचारी बदलने पर निरंतरता कम प्रभावित होती है।	एक ही सेवा खाते को कई असंबंधित ऐप में बांटना प्रभाव क्षेत्र बढ़ाता है। प्रोजेक्ट या workload के अनुसार अलग करें।
स्थानीय विकास, थोड़े समय की debugging, exploratory script	user-owned project key	स्वामी और व्यक्तिगत जवाबदेही साफ रहती है; offboarding में उस उपयोगकर्ता की कुंजी शामिल की जा सकती है।	व्यक्तिगत कुंजी चुपचाप साझा उत्पादन निर्भरता नहीं बननी चाहिए।
archived, बंद होने वाला या अस्थायी रूप से frozen project	नई कुंजी निर्माण बंद	प्रोजेक्ट बंद या जांच के दौरान क्रेडेंशियल सूची बढ़ने से रोकता है।	बहुत जल्दी freeze करने से रोटेशन या recovery के लिए जरूरी प्रतिस्थापन कुंजी बनना रुक सकता है।

एक उपयोगी प्रश्न है: क्या यह एप्लिकेशन किसी खास कर्मचारी के टीम छोड़ने के बाद भी चलनी चाहिए? यदि हां, तो उत्पादन कुंजी आम तौर पर उस कर्मचारी के व्यक्तिगत खाते पर निर्भर नहीं होनी चाहिए। दूसरी ओर, सभी डेवलपर को एक साझा सेवा-खाता कुंजी देना attribution कमजोर करता है और सीक्रेट की प्रतियां बढ़ाता है।

कोई भी प्रकार अपने-आप सुरक्षित नहीं है। वास्तविक जोखिम scope, storage, access, lifetime, rotation और revocation से तय होता है। दर्जनों एप्लिकेशन में कॉपी की गई लंबी अवधि वाली सेवा कुंजी भी बड़ा single point of exposure है।

Organization policy सीमा है: project इसे केवल सख्त कर सकता है

Organization restriction सभी projects के लिए ऊपरी सीमा है, इसलिए इसे लागू करने से पहले अगली rotation का अभ्यास करें।

यदि संगठन केवल service-account keys की अनुमति देता है, तो कोई development project अपनी सेटिंग से user-owned project keys की अनुमति नहीं दे सकता। प्रोजेक्ट संगठन की सीमा के भीतर और सख्त हो सकता है, पर उसे ढीला नहीं कर सकता।

संगठन स्तर का नियम बदलने से पहले:

1. सभी प्रोजेक्ट सूचीबद्ध करें और उन्हें production, staging, development, test, temporary, archived या decommissioning के रूप में चिह्नित करें।
2. हर प्रोजेक्ट में आज मौजूद प्रकार के बजाय अगली रोटेशन में जरूरी कुंजी प्रकार दर्ज करें।
3. हर सक्रिय workload के लिए प्रतिस्थापन क्रेडेंशियल पहचानें और सुनिश्चित करें कि प्रस्तावित संगठन नियम उसे बनाने देगा।
4. कम जोखिम वाले प्रोजेक्ट में creation, distribution, validation और revocation का अभ्यास करें।
5. सामान्य रोटेशन संभव साबित होने के बाद ही संगठन प्रतिबंध लागू करें।

मौजूदा कुंजियां चलती रहती हैं, इसलिए जरूरत से ज्यादा सख्त नियम चालू करने के दिन हानिरहित दिख सकता है। समस्या बाद में दिखेगी, जब कुंजी समाप्ति के पास होगी और टीम सही प्रतिस्थापन नहीं बना पाएगी। वर्तमान ट्रैफिक के चलने के बजाय अगली रोटेशन का परीक्षण करें।

हर जगह एक lifetime न रखें: वास्तविक rotation time से शुरू करें

Maximum lifetime इतनी लंबी होनी चाहिए कि approval, creation, secret distribution, deployment, observation और rollback पूरा हो सके।

हर प्रोजेक्ट श्रेणी के लिए कम से कम ये क्षेत्र तय करें:

नीति क्षेत्र	किस प्रश्न का उत्तर
अधिकतम जीवनकाल N	नई कुंजी creation से expiration तक अधिकतम कितनी देर रह सकती है?
रोटेशन lead time R	समाप्ति से कितने पहले प्रतिस्थापन शुरू होना चाहिए?
मुख्य और backup owner	कौन जिम्मेदार है और अनुपस्थिति में कौन संभालेगा?
वितरण तरीका	क्या एप्लिकेशन नई secret version पढ़ सकती है या restart/redeploy चाहिए?
सत्यापन प्रमाण	कौन-से requests, logs, errors और usage signals दिखाएंगे कि नई कुंजी ट्रैफिक ले रही है?
rollback window	कटओवर के बाद पुरानी कुंजी कितनी देर रखनी है?
exception process	विस्तार कौन मंजूर कर सकता है, कितने समय के लिए और किन compensating controls के साथ?

R को पूरी प्रक्रिया कवर करनी चाहिए। बहुत छोटी अवधि लेकिन manual copy-paste, अलग time zones की approvals और कोई backup owner न होना, थोड़ी लंबी अवधि के साथ automation और अभ्यास किए runbook से कम विश्वसनीय है।

संगठन स्तर के maximum को सामान्य ceiling बनाएं। अधिक जोखिम वाले प्रोजेक्ट छोटी सीमा रख सकते हैं, बड़ी नहीं। उत्पादन, व्यक्तिगत development, temporary test और बंद होने वाले project की जिम्मेदारी और recovery speed अलग होती है, इसलिए सभी के लिए एक ही संख्या जरूरी नहीं।

इन सात चरणों से बिना downtime rotation करें

सबसे सुरक्षित तरीका है कुछ समय old और new keys को overlap करना और वास्तविक traffic से cutover साबित होने के बाद ही old key revoke करना।

1. मौजूदा कुंजियों की inventory बनाएं

प्रोजेक्ट, owner type, workload, application, environment, accountable owner, secret location, deployment method, creation date, known expiration और last observed usage दर्ज करें। जिसका उद्देश्य या मालिक अज्ञात हो उसे blind bulk revocation के बजाय high-priority investigation में रखें।

4 अगस्त 2026 के changelog में OpenAI ने बताया कि Usage और Costs dashboards, Usage API और Costs API API key के अनुसार filter और group कर सकते हैं। यह dimension यह जानने में मदद करता है कि कोई कुंजी request बना रही है या नहीं। यह अकेला प्रमाण नहीं है: कम आवृत्ति वाले batch jobs या disaster-recovery paths लंबे समय तक शांत रह सकते हैं।

2. नीति के अनुरूप प्रतिस्थापन बनाएं

सही प्रोजेक्ट में वर्तमान संगठन और प्रोजेक्ट नियमों द्वारा अनुमत owner type की नई कुंजी बनाएं। समाप्ति लागू maximum से आगे न हो। deployment window से पहले creation की अनुमति जांच लें।

3. नई secret version के रूप में रखें

पुराने value की एकमात्र copy तुरंत overwrite न करें। नियंत्रित संक्रमण के दौरान पुरानी और नई version साथ रखें और उन्हें “current production”, “rotation candidate” तथा “pending revocation” जैसे स्पष्ट status दें। कुंजी code, container image, ticket, log या chat में न रखें।

4. ट्रैफिक धीरे-धीरे बदलें

एक instance, कम जोखिम वाले job या थोड़े ट्रैफिक से शुरू करें। authentication, project attribution, permissions और request behavior जांचने के बाद rollout बढ़ाएं। यदि एप्लिकेशन key केवल startup पर पढ़ती है, तो restart और capacity योजना में शामिल करें।

5. एप्लिकेशन health और प्रति-कुंजी usage दोनों देखें

सफल requests, authentication errors, rate limits, latency और business result मॉनिटर करें। साथ ही नई कुंजी पर expected usage और पुरानी पर गिरावट की पुष्टि करें। successful deployment event यह साबित नहीं करता कि ट्रैफिक वास्तव में बदल गया।

6. समयबद्ध rollback window रखें

नई कुंजी स्थिर होने के बाद पुरानी कुंजी को पहले से तय अवधि तक रखें और फिर रद्द करें। अवधि delayed workers, regions और rare jobs को कवर करे, पर अनिश्चितकाल खुली न रहे। स्थायी dual-key operation केवल valid secrets की संख्या दोगुनी करता है।

7. रद्द करें, सत्यापित करें और अगली रोटेशन तय करें

revocation के बाद जांचें कि पुरानी कुंजी से request fail होती है और नई सफल रहती है। inventory, on-call notes, owner, expiration और अगली rotation date अपडेट करें।

Legacy keys अपने-आप compliant नहीं होंगी: risk के अनुसार migrate करें

नए rules लागू होने के बाद भी पुरानी keys के लिए अलग migration queue चाहिए, क्योंकि उनका owner और lifetime अपने-आप नहीं बदलता।

अलग migration queue बनाएं और प्राथमिकता दें:

1. code, tickets, logs या chat में दिख चुकी कुंजियां;
2. जिनका मालिक या उद्देश्य नहीं पता;
3. टीम छोड़ चुके या भूमिका बदल चुके लोगों की user-owned keys;
4. कई production applications में साझा कुंजियां;
5. broad scope या high-impact कुंजियां;
6. स्पष्ट owner, एक workload और tested replacement path वाली कुंजियां।

सफलता को सभी पुरानी कुंजियां एक ही दिन रद्द करने से न मापें। सुरक्षित मानदंड यह है कि हर legacy key का dependency map, approved replacement, cutover evidence और revocation deadline हो। जो अभी migrate नहीं हो सकती उसके exact blocker, owner, compensating control और exception end date लिखें। “Legacy system” स्थायी exception नहीं है।

Internal policy में कम से कम ये 11 fields लिखें

चलने योग्य policy में limit के साथ owner, validation evidence, rollback window और revocation condition भी स्पष्ट होने चाहिए।

नीति बिंदु	क्या दर्ज करें
दायरा	संगठन, प्रोजेक्ट, environments और workload classes
अनुमत नया प्रकार	केवल service account, केवल user-owned, या कोई नई कुंजी नहीं
कारण	continuity, individual accountability, project freeze या अन्य दस्तावेजित कारण
अधिकतम जीवनकाल	संगठन ceiling और कोई अधिक सख्त project limit
lead time	expiration से पहले alert या work item कब बनेगा
secret storage	approved secret manager और access roles
deployment	canary/phased तरीका, restart और rollback
evidence	successful requests, error metrics, per-key usage और old-key traffic zero
revocation condition	नई कुंजी stable, rare jobs covered, rollback window closed
exception approval	approver, reason, compensation और exception expiration
audit trail	creation, policy change, deployment, revocation और owner changes

लंबी अवधि की accountability workload या team role से जोड़ें, लेकिन वर्तमान रोटेशन के लिए व्यक्ति भी नामित करें। “Platform team जिम्मेदार है” तब तक operational नहीं है जब तक on-call path, deadline और escalation तय न हों।

Enforcement से पहले अगली rotation rehearse करें

Organization या project restriction तभी लागू करें जब नीचे की हर बात का जवाब हो और low-risk project पर rehearsal पूरी हो।

• हर सक्रिय एप्लिकेशन किसी खास प्रोजेक्ट और credential से map है;
• हर प्रोजेक्ट की अगली रोटेशन में जरूरी type ज्ञात है;
• संगठन नियम critical replacement को block नहीं करेगा;
• production किसी एक कर्मचारी की personal key पर निर्भर नहीं है;
• secret store versioning या विश्वसनीय rollback support करता है;
• नया secret load करने का तरीका, restart सहित, test किया गया है;
• per-key usage या cost देखी जा सकती है और rare jobs पर विचार हुआ है;
• primary और backup rotation owner हैं;
• expiration alerts पर्याप्त पहले आते हैं;
• revocation criteria overlap को स्थायी नहीं बनने देते;
• हर unresolved legacy key के लिए blocker, owner और deadline है।

सामान्य प्रश्न

क्या नया creation restriction मौजूदा applications को तुरंत तोड़ देगा?

15 सितंबर 2026 के OpenAI अपडेट के अनुसार मौजूदा API कुंजियां नए creation governance से प्रभावित नहीं होतीं। किस तरह की नई कुंजी बन सकती है यह बदलने से चल रही कुंजियां अपने-आप revoke नहीं होतीं। हालांकि अगली रोटेशन प्रभावित हो सकती है, इसलिए replacement creation का अभ्यास पहले करें।

क्या maximum lifetime पुरानी कुंजियों पर पीछे से लागू होती है?

10 सितंबर का अपडेट requirement को नई कुंजियों के लिए बताता है। पुराने credential पर automatic retroactive expiration न मानें; वास्तविक key details जांचें और legacy migration अलग करें।

क्या project administrator संगठन restriction को ढीला कर सकता है?

नहीं। आधिकारिक विवरण के अनुसार संगठन restriction प्रोजेक्ट सेटिंग पर प्राथमिकता रखता है।

क्या पूरे संगठन को केवल service-account keys इस्तेमाल करनी चाहिए?

Production services, shared backends, scheduled jobs और team-operated agents के लिए पहले service-account keys चुनें। Local development और short-lived exploration के लिए user-owned project keys चुनें। पूरे organization में केवल service-account keys का नियम तभी लगाएँ जब लगभग सभी projects पहली श्रेणी में हों और development के लिए workable alternative पहले से मौजूद हो।

सभी नई कुंजियां कब बंद करनी चाहिए?

archived या decommissioning project में, या security investigation के दौरान temporary freeze के रूप में। पहले सुनिश्चित करें कि rotation या recovery के लिए नई कुंजी जरूरी नहीं होगी।

पुरानी कुंजी रद्द करने योग्य है, इसका प्रमाण क्या है?

कई संकेत मिलाएं: rollout state, नई कुंजी से successful requests, error monitoring, per-key usage, rare jobs का execution और rollback window का पूरा होना। थोड़े समय तक traffic न दिखना अकेले पर्याप्त नहीं है।

अभी सबसे पहले क्या करें

पहले तीन काम करें: हर project की अगली rotation में जरूरी key type लिखें, low-risk project पर एक overlap rotation पूरी करें, और उसके बाद ही organization तथा project restrictions लागू करें।

क्रम उल्टा न करें। पहले ceiling लगाने पर मौजूदा applications चलती रह सकती हैं, लेकिन policy भविष्य की replacement key को चुपचाप block कर सकती है। Rules सख्त करने से पहले साबित करें कि अगली rotation पूरी हो सकती है।

आधिकारिक स्रोत:

• OpenAI API Changelog: 10 और 15 सितंबर 2026 के अपडेट