Google Workspace अपडेट
- 30 सितंबर 2024 से: Google अकाउंट और Google Sync तक पहुंचने के लिए केवल पासवर्ड इस्तेमाल करने वाले third-party ऐप्स अब समर्थित नहीं होंगे.
- बदलाव: Google Workspace अब उन third-party ऐप्स या डिवाइसों के login method को सपोर्ट नहीं करेगा जिनके लिए उपयोगकर्ता का Google username और password साझा करना पड़ता है.
- सुरक्षा जोखिम: पुराना तरीका, Less Secure Apps (LSA), Google अकाउंट credentials को third-party ऐप्स और डिवाइसों के साथ साझा करने की मांग करता है, जिससे सुरक्षा जोखिम बढ़ जाता है.
- ज्यादा सुरक्षित तरीका: Google से sign in करने का विकल्प इस्तेमाल करना चाहिए, जो OAuth authentication method का उपयोग करके ईमेल को दूसरे ऐप्स के साथ sync करने का अधिक सुरक्षित और संरक्षित तरीका है.
LSA एक्सेस बंद करने का शेड्यूल
- 15 जून 2024 से: LSA setting को admin console से हटा दिया जाएगा और इसे बदला नहीं जा सकेगा. जिन उपयोगकर्ताओं के लिए यह पहले से enabled है वे कनेक्ट कर सकेंगे, लेकिन जिनके लिए यह disabled है वे अब LSA तक पहुंच नहीं पाएंगे.
- 30 सितंबर 2024 से: सभी Google Workspace अकाउंट्स के लिए LSA access बंद कर दिया जाएगा. CalDAV, CardDAV, IMAP, POP और Google Sync केवल पासवर्ड से login करने पर काम नहीं करेंगे और OAuth का उपयोग करना होगा.
Google Sync सेवा बंद होना
- 15 जून 2024 से: नए उपयोगकर्ता Google Sync के जरिए Google Workspace से कनेक्ट नहीं कर पाएंगे.
- 30 सितंबर 2024: मौजूदा Google Sync उपयोगकर्ता Google Workspace से कनेक्ट नहीं कर पाएंगे.
एडमिन और end user के लिए निर्देश
- एडमिन: end users को Google Workspace अकाउंट के साथ इस तरह के ऐप्स का उपयोग जारी रखने देने के लिए OAuth नाम के अधिक सुरक्षित access type पर migrate करना होगा.
- मोबाइल डिवाइस प्रबंधन (MDM) प्रभाव: जो संगठन IMAP, CalDAV, CardDAV, POP या Exchange ActiveSync (Google Sync) profiles को configure करने के लिए MDM vendor का उपयोग करते हैं, उनकी यह सेवा चरणबद्ध तरीके से बंद की जाएगी.
- स्कैनर और अन्य डिवाइस: SMTP या LSA का उपयोग करके ईमेल भेजने वाले स्कैनर या अन्य डिवाइसों को OAuth का उपयोग करने के लिए configure करना होगा, या कोई वैकल्पिक तरीका अपनाना होगा, या डिवाइस के साथ उपयोग के लिए app password configure करना होगा.
end user के लिए निर्देश
- ईमेल एप्लिकेशन: यदि आप Outlook 2016 से पुराने version का उपयोग कर रहे हैं, तो आपको Microsoft 365 पर जाना होगा या Windows या Mac के लिए ऐसे Outlook पर switch करना होगा जो OAuth access को support करता हो.
- कैलेंडर एप्लिकेशन: यदि आप ऐसा ऐप इस्तेमाल कर रहे हैं जो password-based CalDAV का उपयोग करता है, तो आपको OAuth support करने वाले तरीके पर switch करना होगा.
- संपर्क एप्लिकेशन: यदि आप iOS या MacOS पर CardDAV के जरिए contacts sync करते हैं और केवल password से sign in करते हैं, तो आपको अकाउंट हटाकर फिर से जोड़ना होगा.
डेवलपर्स के लिए निर्देश
- डेवलपर्स: Google Workspace अकाउंट्स के साथ compatibility बनाए रखने के लिए ऐप्स को update करना होगा ताकि connection method के रूप में OAuth 2.0 का उपयोग किया जा सके.
उपलब्धता
- यह बदलाव सभी Google Workspace ग्राहकों को प्रभावित करता है.
GN⁺ की राय
- यह अपडेट Google Workspace उपयोगकर्ताओं की सुरक्षा मजबूत करने के लिए एक महत्वपूर्ण कदम है. केवल पासवर्ड इस्तेमाल करने वाले कम सुरक्षित ऐप्स (LSA) की जगह OAuth का उपयोग करके अकाउंट सुरक्षा बढ़ाना आज के cyber security माहौल में आवश्यक है.
- इसका असर एडमिन और end users दोनों पर पड़ेगा, और खासकर ईमेल, कैलेंडर और contacts ऐप्स का उपयोग करने वाले उपयोगकर्ताओं को नई authentication method पर जाना होगा.
- यह लेख Google Workspace उपयोगकर्ताओं और एडमिन्स को आने वाले सुरक्षा अपडेट्स की तैयारी करने और आवश्यक कदम उठाने में उपयोगी जानकारी देता है.
1 टिप्पणियां
Hacker News की राय
एक उपयोगकर्ता के पास Gmail के साथ इंटरैक्ट करने वाली scripts हैं, इसलिए "Less Secure Apps" सपोर्ट बंद होने की खबर से वह चौंक गया, लेकिन यह देखकर आश्वस्त हुआ कि app passwords शायद काम करते रहेंगे। उसे चिंता है कि अगर स्थिति केवल OAuth सपोर्ट तक पहुंच गई, तो बहुत-सी automation रुक जाएगी। वह OAuth की जटिलता पर असंतोष जताता है और OAuth कैसे काम करता है, इसे स्पष्ट रूप से समझाने वाले Perl module के docs की सकारात्मक सराहना करता है.
जब OAuth इस्तेमाल नहीं किया जा सकता, तब उपयोगकर्ता अपना proxy इस्तेमाल कर सकता है ताकि IMAP या POP/SMTP client, OAuth 2.0 सपोर्ट न करने पर भी, "modern" email provider के साथ काम कर सके। client को OAuth के बारे में जानने की जरूरत नहीं होती.
IMAP, SMTP, POP Google account तक काफी पहुंच देते हैं, लेकिन वे 2-step verification या bot-prevention verification नहीं कर सकते, इसलिए वे credential stuffing attacks के प्रति कमजोर हैं। Google ने उपयोगकर्ताओं को ऐसे हमलों से बचाने के लिए इस तरह की access को default रूप से disable किया था, और इस कदम को बाकी उपयोगकर्ताओं के लिए उठाया गया सकारात्मक कदम माना गया.
यह इशारा किया गया कि इस बदलाव का मकसद उपयोगकर्ताओं को Google के अपने mail app की ओर ले जाना है। Gmail app या जल्द बंद होने वाले Google Sync के बिना real-time mail notifications नहीं मिल सकते। उपयोगकर्ता Google Workspace के लिए भुगतान करने के बावजूद असुविधा पर नाराज़गी जताता है। desktop पर Mimestream अभी भी काम करता है, लेकिन उसे चिंता है कि Google इसे भी रोकने की कोशिश करेगा.
Android पर Oauth2 और Google की सबसे परेशान करने वाली बात यह है कि पूरे फोन को Google account से जोड़े बिना email client या calendar में Google account से sign in नहीं किया जा सकता। साथ ही, यह Google account device पर policy permissions भी दे देता है। उपयोगकर्ता कहता है कि इसे पूरी तरह अनदेखा नहीं किया जा सकता, और बताता है कि Android पर Google, WebView के भीतर oauth2 के उपयोग को आसानी से सीमित कर सकता है.
app passwords 16-अंकों के password होते हैं, जिन्हें केवल उन्हीं accounts पर इस्तेमाल किया जा सकता है जिनमें 2-step verification enabled हो। यह बताया गया कि "less secure apps" भी OAuth सपोर्ट करने वाले apps जितना ही सुरक्षा स्तर दे सकते हैं, लेकिन यह उन server-side mechanisms का उपयोग करके संभव होता है जिन्हें Google लंबे समय से प्रचारित कर पा रहा था। Google सुरक्षा मुद्दों की व्याख्या अपने एजेंडा को आगे बढ़ाने के तरीके से करता है, इस पर आलोचनात्मक राय दी गई.
यह समझाया गया कि App-Specific Passwords शायद काम करते रहेंगे, और अगर कोई OAuth सपोर्ट न करने वाले apps का इस्तेमाल करता है, तो उसे या तो OAuth सपोर्ट करने वाले app पर जाना होगा या app password बनाकर access करना होगा.
यह समझाया गया कि यह बदलाव केवल Workspace accounts पर लागू होता है; सामान्य Gmail accounts पर इसे कई साल पहले ही लागू किया जा चुका था.
लगभग 10 साल पहले, Google account directory के साथ integration के जरिए एक ऐसा system बनाया गया था जिसमें individual Google accounts से internal network पर authenticate किया जा सकता था। आज के मानकों से यह कम सुरक्षित है, लेकिन VPN के बिना भी internal network से तुरंत जुड़ने की सुविधा देकर इसने सभी का समय बचाया, इस रूप में इसकी सराहना की गई.
Microsoft के OAuth transition को संभालते समय कठिनाइयों का सामना करना पड़ा, और समस्या यह थी कि process बेहद अपारदर्शी है। token भेजने पर server सिर्फ "नहीं" कहता है, लेकिन यह नहीं बताता कि वह क्यों काम नहीं कर रहा, इसलिए troubleshooting में कई दिन लग गए। यह भी सवाल उठाया गया कि क्या Google के mail servers इस मामले में बेहतर हैं.