SaaS BYOK AI provider keys: tenant setup और rotation सुरक्षित रखें
Customer के अपने model-provider account को tenant-scoped secret storage, server-side उपयोग, स्पष्ट billing और data disclosure, सुरक्षित rotation तथा भरोसेमंद revocation से जोड़ें।
इस मार्गदर्शिका में
AI SaaS product में BYOK का क्या अर्थ है?
Bring your own key (BYOK) में customer अपना provider credential देता है और SaaS उस customer की model requests के लिए उसका उपयोग करता है। इससे provider को कौन भुगतान करता है और account किसके नियंत्रण में है, बदल सकता है; लेकिन इससे आपकी privacy, tenant isolation या application security की जिम्मेदारी नहीं बदलती। हर key को उच्च-प्रभाव वाला secret मानें, जिसका tenant owner, घोषित उद्देश्य और revocation रास्ता हो।
बताएँ कि provider account और data किसके नियंत्रण में हैं
Credential सहेजने से पहले बताएँ कि कौन-सा provider और account requests process करेगा, provider bill किसे मिलेगा, ऐप कौन-सा data भेजेगा, provider क्या रख सकता है और product के किन features को key चाहिए। BYOK को अपने आप zero retention, data residency या contract protection न बताएँ; customer को अपने provider plan और terms जाँचने होंगे।
Provider credential को browser और model context से बाहर रखें
प्रमाणित HTTPS endpoint पर key server को भेजें, फिर encrypted secret या managed-secret reference सहेजें और trusted backend या नियंत्रित egress proxy से उपयोग करें। Raw value API response में न लौटाएँ, browser storage में न रखें, prompt में न डालें और agent sandbox या support dashboard को न दिखाएँ।
Credential को अधिकृत tenant integration से बाँधें
Authenticated organization के भीतर integration बनाएँ और read, update, test तथा delete routes पर object-level checks रखें। Secret को stable internal ID से server-side resolve करें। Client से मिला tenant ID या provider नाम ownership प्रमाणित नहीं करता। Customer keys, product keys और अलग tenants की keys के records और access paths अलग रखें।
| Provider और account owner | Secret storage और access | अनुमत routes और data | Rotation और revoke owner | Billing और retention disclosure |
|---|---|---|---|---|
Tenant की provider key को कैसे store और उपयोग करें?
सीमित workload access वाला managed secret store चुनें
Credential को managed key से encrypt करें, decrypt access केवल provider call करने वाली service को दें और production तथा staging अलग रखें। Secret values को application logs, traces, crash reports, queues, analytics और जहाँ संभव हो backups में न आने दें। Database में encrypted value हो तो key ownership, rotation और recovery controls दर्ज करें।
Provider destinations सीमित करें और optional endpoint validate करें
Fixed provider hosts और approved routes को प्राथमिकता दें। Product customer-managed compatible endpoint स्वीकार करे तो scheme, host, resolved addresses, redirects और outbound network route जाँचें ताकि SSRF या internal service तक पहुँच न बने। Provider key tenant द्वारा चुने arbitrary URL को अधिकार न दे।
Credential या diagnostic content सहेजे बिना key test करें
सबसे छोटी अनुमत validation request से accepted, invalid, unauthorized या provider unavailable जैसा स्पष्ट status लौटाएँ। Exception में authentication headers और request body redact करें। Troubleshooting के लिए key का prefix या पूरी value न दिखाएँ; सुरक्षित replacement का तरीका दें।
Customer BYOK credential को rotate या revoke कैसे करे?
Replacement और removal को स्पष्ट product actions बनाएँ
Organization owner को पुरानी key फिर दिखाए बिना credential बदलने या हटाने दें। Rotation में नई key validate करें, secret reference atomically बदलें, representative request confirm करें और फिर customer से provider पर पुरानी key revoke करने को कहें। थोड़ी overlap हो तो अवधि दर्ज करें; दो working secrets चुपचाप अनिश्चित समय तक न रखें।
Key revoke या invalid होते ही नई requests रोकें
Integration को unavailable करें, queued jobs को उसका उपयोग जारी रखने से रोकें और customer की स्पष्ट सहमति के बिना अपनी shared product key पर fallback न करें। Secret या दूसरे tenant के provider usage को उजागर किए बिना account owner को उपयोगी संदेश दें।
Access audit करें और dependent systems में deletion जाँचें
किसने integration बनाया, test किया, बदला, उपयोग किया या हटाया—actor, tenant, time और outcome दर्ज करें; secret audit record में न डालें। Secret-store versions, cached clients, job payloads, logs और backup retention में cleanup जाँचें। UI से row हटना इस बात का प्रमाण नहीं कि credential हर जगह हट गया।
SaaS BYOK AI keys: आम सवाल
क्या BYOK का मतलब है कि customer prompts मेरे SaaS से नहीं गुजरते?
ज़रूरी नहीं। Provider तक भेजने से पहले आपकी service request प्राप्त, बदल, route या log कर सकती है। पूरा data flow map करें और सही ढंग से बताएँ; key authentication और अक्सर billing बदलती है, अपने आप data path नहीं।
क्या customer browser app में key paste कर सकता है?
Browser एक बार key को HTTPS से authenticated backend तक भेज सकता है, पर backend को उसे protected secret storage में रखना और browser को फिर कभी न लौटाना होगा। जहाँ server-side tenant enforcement या secret control जरूरी हो वहाँ client-side provider calls से बचें।
क्या customer group के हर tenant में एक BYOK key साझा कर सकते हैं?
केवल जब customer का account model और आपका स्पष्ट organization-level design उस scope को अनुमति दे। अन्यथा credential को configured organization सीमा पर रखें, हर action पर membership लागू करें और administrators को साझा access दिखाई दे।
क्या BYOK key विफल होने पर SaaS चुपचाप अपनी key इस्तेमाल करे?
नहीं। इससे billing का owner और data पर लागू terms बदलते हैं। ऐसा fallback करने से पहले product configuration और provider, billing तथा data path की स्पष्ट जानकारी जरूरी है।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
मसौदा 27 सितंबर 2026 को तैयार; इंजीनियरिंग, सुरक्षा और संपादकीय समीक्षा लंबित · स्रोत जाँचे गए .