एंटरप्राइज में एजेंटिक सुरक्षाएडवांस्डपाठ 1486 मिनट का पाठ

डेलिगेटेड एक्सेस: यूज़र्स की ओर से काम करना

जब कोई एजेंट किसी व्यक्ति के लिए काम करता है, तो उसके पास उस व्यक्ति की ही अनुमतियाँ (permissions) होनी चाहिए, जो ज़रूरत पड़ने पर और सीमित की जा सकें, पर कभी बढ़ाई न जाएँ। OAuth scopes, सहमति (consent) और ऑडिट इसे मुमकिन बनाते हैं।

पाठ वीडियो में

60 सेकंड में

डेलिगेटेड एक्सेस: यूज़र्स की ओर से काम करना

जब कोई एजेंट किसी व्यक्ति के लिए काम करता है, तो उसके पास उस व्यक्ति की ही अनुमतियाँ (permissions) होनी चाहिए, जो ज़रूरत पड़ने पर और सीमित की जा सकें, पर कभी बढ़ाई न जाएँ। OAuth…

1/4
आसान शब्दों में
अगर आप अपने छोटे भाई को साइन किया हुआ नोट देकर बैंक भेजते हैं, तो उस नोट में साफ़ लिखा होना चाहिए कि वह क्या कर सकता है: "मेरी पासबुक ले आओ"। यह नहीं कि "मेरे खाते के साथ कुछ भी करो"। और बैंक को यह लिख कर रखना चाहिए कि वह आपके नोट की वजह से आया था।
कई एजेंट किसी यूज़र की ओर से काम करते हैं: कोई असिस्टेंट आपका मेल पढ़ता है, कोई शेड्यूलिंग एजेंट आपकी मीटिंग्स बुक करता है, कोई सपोर्ट एजेंट आपके ऑर्डर्स देखता है। अब एजेंट को हर काम पर दो बातों का जवाब चाहिए: कौन सा एजेंट काम कर रहा है, और किस इंसान के लिए।
इस तरह के डेलिगेशन के लिए OAuth 2.0 सबसे ज़्यादा इस्तेमाल होने वाला स्टैंडर्ड है। यूज़र रिक्वेस्ट को मंज़ूरी देता है; एजेंट को scopes (वह क्या कर सकता है) और लाइफटाइम (कितने समय तक) द्वारा सीमित एक access token मिलता है। यूज़र का पासवर्ड कभी भी एजेंट के पास नहीं जाता।

एजेंट के पास अधिकार होने के दो तरीके

मॉडलयह कैसे काम करता हैकिसके लिए अच्छा हैमुख्य जोखिम
एजेंट के अपने अधिकारएजेंट की अपनी पहचान और अनुमतियाँ होती हैं, जो हर यूज़र के लिए एक जैसी होती हैंबिना किसी यूज़र वाले बैकग्राउंड काम, जैसे रोज़ रात को बनने वाली रिपोर्ट्सConfused deputy: कोई भी यूज़र इससे ऐसे अधिकारों का इस्तेमाल करने को कह सकता है जो उनके पास नहीं हैं
यूज़र की ओर सेएजेंट को उस खास यूज़र से जुड़ा एक टोकन मिलता है, जिसमें scopes सीमित होते हैंऐसे असिस्टेंट जो यूज़र के डेटा को पढ़ते हैं या उस पर काम करते हैंScopes का ज़रूरत से ज़्यादा बड़ा होना; टोकन का बहुत लंबे समय तक चलना
सुनहरा नियम: यूज़र की ओर से काम करने वाला एजेंट कभी भी उस यूज़र से ज़्यादा काम करने में सक्षम नहीं होना चाहिए। आदर्श रूप से यह बहुत कम कर सके: यूज़र के एक्सेस का सिर्फ़ वही हिस्सा जिसकी इस काम को ज़रूरत है।
Effective access (the idea)text
effective access = user's permissions
                 ∩ scopes granted to this agent
                 ∩ what this task needs right now

Example: Meera can read and send mail and read all shared drives.
The agent was granted: mail.read, calendar.read
This task ("summarise today's mail") needs: mail.read (today only)
=> The agent may read today's mail. It cannot send, and cannot open drives.

Scopes डिज़ाइन करना

Scopes जो ज़रूरत से ज़्यादा बड़े हैं
  • मेलबॉक्स का "full_access"
  • "बस यूँ ही ज़रूरत पड़ सकती है" सोचकर पढ़ने और लिखने (read and write) दोनों का एक्सेस एक साथ मांगना
  • Refresh tokens जो बिना किसी रिव्यू के महीनों तक चलते रहते हैं
  • एक ही सहमति (consent) स्क्रीन जो हमेशा के लिए हर फ़ीचर को कवर कर लेती है
Scopes जो बिल्कुल सही हैं
  • पढ़ने और लिखने के अलग-अलग scopes; लिखने का एक्सेस केवल तभी मांगें जब लिखने वाले फ़ीचर का इस्तेमाल हो
  • जहाँ प्लेटफ़ॉर्म सपोर्ट करता हो वहाँ रिसोर्स की सीमाएँ तय करना (एक फ़ोल्डर, एक प्रोजेक्ट)
  • कम समय वाले access tokens; सीमित और रद्द करने योग्य (revocable) रिफ्रेश
  • स्टेप-अप सहमति: जब एजेंट को कोई नया, ज़्यादा जोखिम भरा अधिकार चाहिए, तो दोबारा पूछें

डेलिगेशन की कड़ियाँ (Chains of delegation)

कभी-कभी कोई एजेंट किसी दूसरी सर्विस को कॉल करता है जिसे यह भी जानना होता है कि यूज़र कौन है। यूज़र का असली टोकन हर जगह भेजते रहना जोखिम भरा है: जो भी सर्विस इसे देखेगी, वह इसका दोबारा इस्तेमाल कर सकती है। एक सुरक्षित तरीका token exchange है (OAuth 2.0 Token Exchange, RFC 8693, एक स्टैंडर्ड तरीका है): एजेंट अपने टोकन को एक नए टोकन से बदल लेता है जो सिर्फ़ अगली सर्विस के लिए होता है, और जिसके scopes ज़्यादा सीमित होते हैं। कुछ आइडेंटिटी प्लेटफ़ॉर्म इसे "on-behalf-of" फ़्लो कहते हैं।

ऐसी सहमति जिसे लोग समझ सकें

  • सीधे-सादे शब्दों में बताएं कि एजेंट क्या करेगा: "मीटिंग का समय सुझाने के लिए आपका कैलेंडर पढ़ें। यह इवेंट्स को डिलीट नहीं कर सकता।"
  • पहले सबसे छोटे scopes मांगें; जब किसी फ़ीचर को ज़रूरत हो तब और मांगें।
  • यूज़र्स को एक ही जगह देखने और हटाने दें कि उन्होंने क्या अनुमति दी थी।
  • कंपनी के डेटा के लिए, यूज़र्स किन ऐप्स को एक्सेस दे सकते हैं, इसके लिए एडमिन की मंज़ूरी की ज़रूरत हो सकती है। वरना, कोई भी कंपनी का मेल किसी भी ऐप को सौंप सकता है।

ऑडिट: किसने क्या अनुमति दी

डेलिगेट की गई कार्रवाई के लिए हर लॉग लाइन में एजेंट की पहचान, वह इंसान जिसके लिए उसने काम किया, इस्तेमाल किए गए scopes और उसके पीछे की सहमति या मंज़ूरी दिखनी चाहिए। आपका रनटाइम इन्हें जोड़ता है, मॉडल नहीं। अगर मॉडल टूल आर्ग्युमेंट में यूज़र ID टाइप कर सकता है, तो मॉडल किसी और की ID भी टाइप कर सकता है।
सावधान रहें
एजेंट को जारी किया गया टोकन अभी भी एक बियरर क्रेडेंशियल (bearer credential) है: जिसके पास यह होगा, वह इसका इस्तेमाल कर सकता है। टोकन्स को मॉडल के संदर्भ (context) और लॉग्स से बाहर रखें, और कम समय वाली अवधि को प्राथमिकता दें।
इसे आज़माएँ। अपने अकाउंट से कनेक्टेड ऐप्स की लिस्ट खोलें (मेल, कैलेंडर या कोड होस्टिंग)। किसी एक AI ऐप के लिए जाँचें कि वह क्या कर सकता है। क्या यह केवल पढ़ने (read-only) के लिए है? क्या इसे वास्तव में वह सब चाहिए जो इसके पास है?

और देखें और पढ़ें

लैब

एक मीटिंग असिस्टेंट एजेंट के लिए scope डिज़ाइन और आसान भाषा में सहमति (consent) स्क्रीन।

~30 min

समस्या

एक मीटिंग असिस्टेंट के लिए डेलिगेटेड एक्सेस डिज़ाइन करें जो (a) यूज़र का कैलेंडर पढ़ता है, (b) मीटिंग के समय सुझाता है, (c) यूज़र की पुष्टि के बाद मीटिंग बुक करता है, और (d) एक शेयर्ड नोट्स फ़ोल्डर में सारांश लिखता है।

  1. उन scopes की लिस्ट बनाएं जिनका आप अनुरोध करेंगे, उन्हें पढ़ने और लिखने (read and write) में बाँटें। मार्क करें कि कौन से पहली बार साइन-इन करने पर मांगे जाते हैं और कौन से केवल तब जब किसी फ़ीचर का पहली बार इस्तेमाल किया जाता है (स्टेप-अप)।
  2. वह सहमति टेक्स्ट लिखें जो यूज़र देखेगा, आसान भाषा में, 80 शब्दों से कम।
  3. "मीटिंग बुक करें" के लिए प्रभावी-पहुँच (effective-access) नियम को यूज़र की अनुमतियाँ ∩ एजेंट के scopes ∩ काम की ज़रूरत के रूप में लिखें।
  4. वे फ़ील्ड्स लिखें जो हर ऑडिट लॉग लाइन में होने चाहिए।
  5. बताएं कि किसी भी कर्मचारी द्वारा इस एजेंट को एक्सेस देने से पहले एक एडमिन को क्या मंज़ूर करना होगा।

आपका काम तब पूरा होगा जब

कठिन सवाल

उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।

Q1नोट्स फ़ोल्डर पूरे विभाग के साथ शेयर किया गया है। एजेंट यूज़र की ओर से वहाँ सारांश लिखता है। कौन सा नया जोखिम सामने आता है?दिखाएं

एजेंट डेटा को एक निजी जगह (यूज़र का कैलेंडर और मीटिंग्स) से बड़े समूह (पूरे विभाग) में ले जा सकता है। भले ही हर अनुमति सही हो, सारांश में निजी जानकारी शामिल हो सकती है। सारांश में क्या जाता है उसे सीमित करें, पोस्ट करने से पहले यूज़र को रिव्यू करने दें, या केवल उस फ़ोल्डर में लिखें जिसे सिर्फ़ शामिल होने वाले लोग ही देख सकते हैं।

Q2एक यूज़र एजेंट का एक्सेस रद्द कर देता है, लेकिन एजेंट के पास अभी भी कुछ मिनटों के लिए एक मान्य access token है। आप उस अंतर (gap) को कैसे संभालते हैं?दिखाएं

Access tokens को कम समय तक चलने वाला रखें ताकि अंतर छोटा हो, पक्का करें कि refresh tokens तुरंत रद्द कर दिए जाएँ, और उच्च-जोखिम वाले कामों के लिए, केवल टोकन पर भरोसा करने के बजाय रिसोर्स से रियल टाइम में रद्दीकरण या सेशन की स्थिति की जाँच करवाएं। इसके अलावा, एक्सेस रद्द होने पर उस यूज़र के लिए चल रहे किसी भी काम को रोक दें।

जारी रखने के लिए कृपया साइन इन करें।

अक्सर पूछे जाने वाले सवाल

एजेंट को सीधे यूज़र का पासवर्ड ही क्यों न दे दें?

क्योंकि तब एजेंट के पास वह सब कुछ होगा जो यूज़र के पास है, हमेशा के लिए, और कोई भी एजेंट के काम को यूज़र के काम से अलग नहीं पहचान पाएगा। OAuth इसके बजाय एक सीमित, रद्द किया जा सकने वाला टोकन देता है, और पासवर्ड यूज़र के पास ही रहता है।

क्या हो अगर एजेंट को ऐसे एक्सेस की ज़रूरत हो जो यूज़र के पास नहीं है?

तब वह वास्तव में यूज़र की ओर से काम नहीं कर रहा है; वह अपने अधिकारों के साथ काम कर रहा है। कभी-कभी यह ठीक होता है (जैसे कोई सिस्टम चेक) लेकिन इसे सावधानी से डिज़ाइन किया जाना चाहिए: कुछ भी वापस भेजने से पहले एजेंट को यह जाँचना होगा कि यूज़र को क्या देखने की अनुमति है, वरना आप एक confused deputy बना देंगे।

टोकन्स कितने समय तक चलने चाहिए?

उस काम के लिए जितना कम व्यावहारिक हो। Access tokens आमतौर पर कम समय के लिए होते हैं, और refresh tokens सीमित, रद्द करने योग्य और रिव्यू किए जाने वाले होने चाहिए। इसका कोई एक सही नंबर नहीं है; एक टोकन जितना ज़्यादा कर सकता है, उसे उतना ही कम चलना चाहिए।

क्या यूज़र्स अपने दम पर किसी एजेंट को कंपनी के डेटा का एक्सेस दे सकते हैं?

कई प्लेटफ़ॉर्म पर, हाँ, जब तक कि एडमिन इसे प्रतिबंधित न करें। ज़्यादातर एंटरप्राइज़ आइडेंटिटी प्लेटफ़ॉर्म एडमिन को यह तय करने देते हैं कि यूज़र्स द्वारा थर्ड-पार्टी ऐप्स को कंपनी का डेटा देने से पहले मंज़ूरी ज़रूरी हो। इसे चालू करना शैडो एजेंट्स (shadow agents) से बचने का एक मुख्य उपाय है।

पाठ का टेस्ट

5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।

टेस्ट देने और अपनी प्रोग्रेस सेव करने के लिए साइन इन करें