Google भी नहीं रख पा रहा है कदम ─ AI युग में सुरक्षा "सेकंडों" की लड़ाई बन गई है

यहां तक कि Google भी "दौड़ते हुए सुरक्षा" के युग में प्रवेश कर चुका है

AI एक ऐसा उपकरण है जो कंपनियों की उत्पादकता को बढ़ाता है, लेकिन साथ ही यह सुरक्षा अधिकारियों के लिए एक नया हमला सतह भी बन गया है। जनरेटिव AI, इन-हाउस एजेंट, लर्निंग डेटा, प्रॉम्प्ट, बाहरी SaaS, मल्टी-क्लाउड वातावरण। पहले नेटवर्क सीमा, टर्मिनल, सर्वर, और आईडी प्रबंधन पर ध्यान केंद्रित करना पर्याप्त था, लेकिन अब सुरक्षा का दायरा "AI के संपर्क में आने वाली हर चीज़" तक फैल गया है।

TechCrunch ने Google Cloud के COO, Francis de Souza के बयान को रिपोर्ट किया, जो इस बदलाव का प्रतीक है। उन्होंने जोर दिया कि यदि कंपनियां AI को अपनाती हैं, तो सुरक्षा को बाद में जोड़ने वाली चीज़ के रूप में नहीं देखा जाना चाहिए, बल्कि इसे प्लेटफॉर्म डिज़ाइन में शुरू से ही शामिल किया जाना चाहिए। कर्मचारियों द्वारा बाहरी AI टूल का अनधिकृत उपयोग "शैडो AI", मल्टी-क्लाउड में डेटा प्रबंधन, ऑडिटेबिलिटी, गवर्नेंस। ये अब केवल सूचना प्रणाली विभाग की चुनौतियाँ नहीं हैं, बल्कि ये प्रबंधन और निदेशक मंडल द्वारा संभाले जाने वाले जोखिम बन गए हैं।

विशेष रूप से महत्वपूर्ण यह है कि AI का कार्यान्वयन "सुविधाजनक नई विशेषता जोड़ने" तक सीमित नहीं है। जब AI एजेंट आंतरिक सिस्टम के पार काम करने लगते हैं, तो वे पुराने डेटा स्टोरेज, अप्रचलित एक्सेस अधिकार, छोड़े गए SharePoint या पुराने कार्य फ़ाइलों को उजागर कर सकते हैं। पहले जो डेटा "किसी ने नहीं पाया इसलिए समस्या नहीं बनी" था, वह AI द्वारा तुरंत दृश्य में आ सकता है। अर्थात्, AI न केवल हमलावरों को बल्कि कंपनी के अंदरूनी "पिछले प्रबंधन की खामियों" को भी तेजी से खोज सकता है।

हमले "घंटों" में नहीं बल्कि "सेकंडों" में होते हैं

de Souza बताते हैं कि उल्लंघन से अगले हमले के चरण तक पहुंचने का औसत समय पहले के घंटों से घटकर अब सेकंडों में आ गया है। यह सुरक्षा अधिकारियों के लिए अत्यधिक महत्वपूर्ण है। जब तक मानव अलर्ट देखता है, स्थिति की पुष्टि करता है, संबंधित लोगों को इकट्ठा करता है, निर्णय लेता है, और मैन्युअल रूप से रोकता है, तब तक हमला अगले चरण में जा चुका होता है।

इस प्रवृत्ति में, Google Cloud का उत्तर "AI-नेटिव डिफेंस" है। मानव द्वारा सीधे सब कुछ संचालित करने के बजाय, AI एजेंट निगरानी, रक्षा, और प्रारंभिक प्रतिक्रिया करते हैं, और मानव इसे पर्यवेक्षण करता है। यदि हमला मशीन की गति से होता है, तो रक्षा को भी मशीन की गति से चलाना होगा।

यह विचार स्वाभाविक है। लेकिन साथ ही, इसमें एक बड़ा विरोधाभास भी है। AI का उपयोग करके सुरक्षा करने के लिए, उस AI को स्वयं सुरक्षित होना चाहिए। AI द्वारा संदर्भित डेटा, AI को कॉल करने वाले API, AI द्वारा उपयोग किए जाने वाले प्रमाणीकरण जानकारी, AI के उपयोग शुल्क को प्रबंधित करने वाली बिलिंग प्रणाली। यदि इन बुनियादी ढांचों में कोई खामी है, तो AI सुरक्षा एक नई जोखिम बन सकती है।

Gemini API कुंजी समस्या ने "पुराने पूर्वानुमानों" के पतन को दिखाया

TechCrunch का लेख दिलचस्प है क्योंकि यह केवल Google Cloud की सुरक्षा सिफारिशों को नहीं दर्शाता, बल्कि उन समस्याओं को भी उजागर करता है जिनका Google स्वयं सामना कर रहा है। विशेष रूप से ध्यान देने योग्य है Gemini API के आसपास की उच्च लागत वाली बिलिंग समस्याएं।

समस्या के केंद्र में Google Cloud की API कुंजी का प्रबंधन है। वर्षों से, Google Maps और Firebase जैसी सेवाओं में, API कुंजी को क्लाइंट-साइड कोड में एम्बेड करना असामान्य नहीं था। डेवलपर्स के लिए, यह हमेशा "पासवर्ड को सार्वजनिक करने" जैसा नहीं लगता था। इसे सेवा पहचान और बिलिंग के लिए एक सार्वजनिक कुंजी के रूप में माना गया।

हालांकि, जब Gemini API जैसी उच्च लागत वाली AI सेवाएं उसी प्रोजेक्ट में सक्रिय होती हैं, तो मौजूदा API कुंजी AI अनुरोधों के लिए भी उपयोगी हो सकती हैं। यदि वह कुंजी पुराने वेबसाइट के जावास्क्रिप्ट, सार्वजनिक रिपॉजिटरी, या पिछले सेटिंग्स में बची हुई है, तो हमलावर इसे ढूंढ सकते हैं और Gemini या इमेज/वीडियो जनरेशन मॉडल में बड़ी मात्रा में अनुरोध भेज सकते हैं, जिससे डेवलपर के बिलिंग खाते पर भारी खर्च हो सकता है।

यह केवल "डेवलपर ने कुंजी प्रबंधन की उपेक्षा की" की बात नहीं है। क्योंकि कुछ डेवलपर्स ने उस समय के दस्तावेज़ों और सामान्य प्रथाओं के अनुसार कुंजी का उपयोग किया था। एक पहचानकर्ता जिसे सार्वजनिक करने के लिए उपयुक्त माना गया था, बाद में उच्च लागत वाली AI सेवाओं के प्रमाणीकरण के समान भूमिका निभाने लगा। यहां AI युग की सुरक्षा की जटिलता है। कल तक सुरक्षित डिज़ाइन, आज की नई विशेषता जोड़ने से खतरनाक डिज़ाइन में बदल सकता है।

"सीमा" की धारणा जो सीमा नहीं है, के प्रति अविश्वास

इसके अलावा, डेवलपर्स के अविश्वास को बढ़ाने वाली उपयोग सीमा और बिलिंग सीमा से संबंधित समस्याएं हैं। The Register की रिपोर्ट में, Google Cloud के डेवलपर्स ने अनधिकृत API उपयोग के कारण हजारों डॉलर से लेकर दसियों हजार डॉलर तक की बिलिंग प्राप्त की। कुछ मामलों में, मासिक उपयोग जो कुछ दर्जन डॉलर था, वह अचानक $10,000 से अधिक हो गया, या $250 की सीमा को सेट करने के बावजूद, खाता इतिहास के अनुसार उच्च उपयोग सीमा में स्वचालित रूप से बढ़ा दिया गया।

Google का तर्क है कि सेवा को रोकने से बचने और बढ़ते ग्राहकों को सहजता से उपयोग विस्तार करने की अनुमति देने के लिए यह किया गया। वास्तव में, अचानक ट्रैफिक बढ़ने वाली वैध सेवाओं के लिए, कठोर सीमा एक बाधा बन सकती है। AI ऐप्स के तेजी से बढ़ने के युग में, उपयोग सीमा का स्वचालित विस्तार डेवलपर अनुभव को बेहतर बना सकता है।

हालांकि, जैसे ही अनधिकृत उपयोग होता है, यह डिज़ाइन विपरीत दिशा में काम करता है। हमलावरों के लिए, चोरी की गई कुंजी के साथ अधिक उपयोग करने की गुंजाइश बढ़ जाती है। उपयोगकर्ताओं के लिए, "सीमा सेट की गई थी, फिर भी यह नहीं रुकी" की भावना होती है। सोशल मीडिया पर सबसे अधिक देखी गई प्रतिक्रिया भी इसी बिंदु पर केंद्रित थी। डेवलपर्स ने "अलर्ट नहीं, बल्कि वास्तव में रुकने वाली सीमा की आवश्यकता है" की अपील की।

Reddit पर गुस्सा और डर का विस्तार

Reddit के r/googlecloud पर, Gemini API और Google Cloud की उच्च लागत वाली बिलिंग के संबंध में पोस्ट की बाढ़ आ गई। एक पोस्टर ने बताया कि वह B2B SaaS चला रहा था और आमतौर पर $50 मासिक Google Cloud बिलिंग थी, लेकिन Veo 3 और Gemini इमेज आउटपुट टोकन के कारण यह $10,000 से अधिक हो गई। उन्होंने कहा कि वह इन सेवाओं का अपने उत्पाद में उपयोग नहीं कर रहे थे और Google के समर्थन से अनधिकृत उपयोग की शिकायत की, लेकिन शुरू में "अनधिकृत की कोई सबूत नहीं मिला" कहा गया।

एक अन्य पोस्ट में, एक पुरानी Google Maps API कुंजी का दुरुपयोग किया गया और Gemini API सक्षम करने के बाद €36,800 का बिल उत्पन्न हुआ। टिप्पणी अनुभाग में, "यह समस्या पहले से रिपोर्ट की गई थी, फिर भी व्यवहार नहीं बदला?" जैसी आश्चर्यजनक आवाजें और "Google Cloud Console अब डरावना हो गया है। एक कुंजी के साथ हजारों डॉलर उत्पन्न करने का कोई भरोसा नहीं है" जैसी आवाजें देखी गईं।

जापान की एक छोटी कंपनी का दावा करने वाले एक पोस्टर ने भी Gemini API के अनधिकृत उपयोग के कारण $128,000 के बिलिंग जोखिम का सामना किया और दिवालियापन की संभावना का उल्लेख किया। टिप्पणियों में, Google को एक वैकल्पिक हार्ड स्टॉप प्रदान करने की आवश्यकता पर जोर दिया गया, यानी एक निश्चित राशि से अधिक होने पर परियोजना या API को निश्चित रूप से रोकने की प्रणाली। AI कोडिंग टूल्स के प्रसार के साथ Google Cloud का उपयोग करने वाले डेवलपर्स की संख्या बढ़ने के साथ, "हर कोई कुंजी को पूरी तरह से सुरक्षित कर सकता है" की धारणा वास्तविक नहीं रह जाती।

Reddit की प्रतिक्रियाओं में न केवल गुस्सा था, बल्कि व्यावहारिक बचाव उपाय भी शामिल थे। API कुंजी का उपयोग न करना, सेवा खाता या अधिक सीमित प्रमाणीकरण विधियों में स्थानांतरित होना, संगठन स्तर पर Gemini API को अक्षम करना, सार्वजनिक सेवा और AI उपयोग को अलग-अलग परियोजनाओं में विभाजित करना, API प्रतिबंधों को हमेशा सेट करना, जैसे प्रस्ताव थे। अर्थात्, समुदाय Google की प्रतिक्रिया की आलोचना करते हुए भी आत्मरक्षा उपायों को साझा करने का एक मंच बन गया था।

Hacker News पर "डिज़ाइन विचारधारा" की आलोचना प्रबल है

Hacker News पर, डिज़ाइन विचारधारा में गहरी चर्चा देखने को मिली। Truffle Security की जांच के संबंध में एक थ्रेड में, Google API कुंजी को लंबे समय से "सार्वजनिक करने योग्य पहचानकर्ता" के रूप में माना गया था, लेकिन Gemini के कारण यह वास्तव में उच्च लागत वाली AI उपयोग और डेटा एक्सेस की कुंजी बन गई।

एक टिप्पणी में, API कुंजी के लिए $10, $100 जैसी स्पष्ट खर्च सीमा होनी चाहिए, ऐसी तुलना की गई। OpenAI या OpenRouter जैसी सेवाओं में कुंजी स्तर और खाता स्तर पर खर्च प्रबंधन करना आसान है, और Google Cloud के बिलिंग अलर्ट में देरी होती है, जिससे वे वास्तविक बाधा नहीं बनते, ऐसी असंतोष व्यक्त की गई।

इसके अलावा, "यह उपयोगकर्ता नाम को पासवर्ड के रूप में उपयोग करने जैसा है" जैसी आलोचना भी फैल गई। निश्चित रूप से, सभी जिम्मेदारी को Google पर डालना बहुत सरल होगा। Gemini API डिफ़ॉल्ट रूप से सभी परियोजनाओं में सक्षम नहीं होता है, और परियोजना के मालिक को इसे सक्षम करना होता है। इसलिए, परियोजनाओं को अलग करना, कुंजी को सीमित करना, और न्यूनतम अधिकारों का पालन करना चाहिए, ऐसी राय भी प्रबल है।

हालांकि, समग्र चर्चा में, AI के कारण "पुरानी क्लाउड प्रथाओं" के खतरनाक होने की धारणा प्रबल है। सार्वजनिक कुंजी, उच्च लागत वाली AI अनुमान, देरी से होने वाले बिलिंग डेटा, स्वचालित रूप से विस्तारित उपयोग सीमा। व्यक्तिगत रूप से ये विनिर्देश समझने योग्य हो सकते हैं, लेकिन जब मिलकर वे छोटे डेवलपर्स के लिए घातक जोखिम बन जाते हैं।

कुंजी को हटाने के बाद भी समाप्त नहीं होता "23 मिनट" की समस्या

इसके अलावा, Aikido Security की जांच ने एक और चिंता को उजागर किया। कंपनी के परीक्षण के अनुसार, Google API कुंजी को हटाने के बाद भी, कुछ अनुरोधों को अधिकतम 23 मिनट तक प्रमाणित किया जा सकता है। बड़े पैमाने पर वितरित सिस्टम में, सेटिंग परिवर्तन को सभी सर्वरों तक पहुंचने में समय लगना असामान्य नहीं है। लेकिन प्रमाणीकरण जानकारी के समाप्ति के संबंध में, उस देरी का मतलब हमला समय होता है।

यदि हमलावर के पास लीक हुई कुंजी है और उपयोगकर्ता ने घबराकर कुंजी को हटा दिया है, तो भी वे कुछ समय तक बड़ी मात्रा में अनुरोध भेज सकते हैं। यदि Gemini API सक्षम है, तो यह न केवल शुल्क उत्पन्न करेगा, बल्कि अपलोड की गई फाइलों या कैश की गई बातचीत की सामग्री तक पहुंच का जोखिम भी बन सकता है।

यह बिंदु AI सुरक्षा के मूल के करीब है। पारंपरिक क्लाउड संसाधनों के लिए, कुछ मिनटों की देरी स्वीकार्य हो सकती है। लेकिन AI मॉडल के लिए अनुरोध महंगे होते हैं, और डेटा की गोपनीयता उच्च होती है। कुछ मिनटों में, हमलावर बड़ी मात्रा में अनुमान चला सकते हैं। AI युग में, प्रमाणीकरण की "अंततः संगत" होने की धारणा लागत और डेटा सुरक्षा दोनों के लिए खतरनाक है।

Google की सिफारिश सही है। इसलिए यह सवाल उठता है

यहां महत्वपूर्ण यह है कि Google Cloud COO की सिफारिश गलत नहीं है। AI रणनीति के लिए डेटा रणनीति और सुरक्षा रणनीति आवश्यक हैं, और शैडो AI को अनदेखा नहीं किया जाना चाहिए। मल्टी-क्लाउड, SaaS, बाहरी साझेदार, आंतरिक एजेंट के पार एक सुसंगत सुरक्षा रुख होना चाहिए। जब हमले मशीन की गति में होते हैं, तो रक्षा के लिए भी AI का उपयोग करना आवश्यक है।

समस्या यह है कि उस सही सिफारिश को लागू करने के लिए प्लेटफॉर्म प्रदाता स्वयं कितनी सुरक्षित रूप से आधारभूत संरचना प्रदान कर सकते हैं। यदि कंपनियों को "सुरक्षा को बाद में न जोड़ें" कहा जाता है, तो क्लाउड पक्ष को भी "AI सुविधाओं को जोड़ने के परिणामस्वरूप, मौजूदा प्रमाणीकरण और बिलिंग डिज़ाइन खतरनाक हो जाते हैं" की स्थिति से बचना चाहिए।

यह विवाद केवल Google की समस्या नहीं है। यह सभी क्लाउड प्रदाताओं, AI प्लेटफॉर्म, और SaaS कंपनियों के लिए एक सामान्य चेतावनी है। जब AI सुविधाओं को मौजूदा सेवाओं में जोड़ा जाता है, तो पिछले डिज़ाइन पूर्वानुमानों की समीक्षा की जानी चाहिए। सार्वजनिक कुंजी, आंतरिक उपयोग के लिए कुंजी, बिलिंग सीमा, डेटा एक्सेस सीमा, समाप्ति प्रक्रिया, ऑडिट लॉग, समर्थन प्रणाली। AI से पहले की सामान्य धारणाओं का सीधा उपयोग करने से कहीं न कहीं टूटन होगी।

कंपनियों और डेवलपर्स को तुरंत क्या देखना चाहिए

इस समस्या से प्राप्त व्यावहारिक सबक स्पष्ट हैं। पहला, AI को सक्षम करने वाली परियोजना और सार्वजनिक फ्रंटएंड या Maps, Firebase आदि में उपयोग की जाने वाली परियोजनाओं को अलग करना। दूसरा, सभी API कुंजियों पर API प्रतिबंध और एप्लिकेशन प्रतिबंध सेट करना और अनावश्यक API को अक्षम करना। तीसरा, केवल बिलिंग अलर्ट नहीं, बल्कि वास्तव में रुकने वाली खर्च सीमा या कोटा की पुष्टि करना। चौथा, पुराने वेबसाइट, पुराने रिपॉजिटरी, पुराने मोबाइल ऐप में बची हुई कुंजियों की जांच करना। पांचवां, AI उपयोग में API कुंजी की बजाय सेवा खाता या OAuth, न्यूनतम अधिकार प्रमाणीकरण डिज़ाइन को प्राथमिकता देना।

और प्रबंधन को AI कार्यान्वयन को "मौके का सुविधाजनक उपकरण" नहीं, बल्कि वित्तीय जोखिम और डेटा लीक जोखिम के साथ एक बुनियादी ढांचा परिवर्तन के रूप में मानना चाहिए। यदि एक कुंजी का लीक होना लाखों डॉलर की बिलिंग या संवेदनशील डेटा के लीक होने की संभावना बनाता है, तो यह केवल CISO या विकास टीम का नहीं, बल्कि CFO, कानूनी, और प्रबंधन बैठक का विषय होना चाहिए।

AI सुरक्षा की असली चुनौती "गति का अंतर" नहीं