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

Agent की पहचान: non-human identities और least privilege

हर agent को अपनी खुद की पहचान से लॉग इन करना चाहिए, short-lived credentials के साथ और सिर्फ़ उतनी ही permissions के साथ जितनी उसके काम के लिए ज़रूरी हों। इंसानों के शेयर्ड अकाउंट्स और हमेशा चलने वाली keys (forever-keys) हर गलती को एक रहस्य बना देती हैं।

✦ ट्यूटर से पूछें🧪 लैब · 30 min📝 पाठ का टेस्ट
पाठ वीडियो में

60 सेकंड में

Agent की पहचान: non-human identities और least privilege

हर agent को अपनी खुद की पहचान से लॉग इन करना चाहिए, short-lived credentials के साथ और सिर्फ़ उतनी ही permissions के साथ जितनी उसके काम के लिए ज़रूरी हों। इंसानों के शेयर्ड…

1/6
आसान शब्दों में
एक बड़े दफ़्तर में, हर कर्मचारी को उसका अपना ID कार्ड मिलता है। यह सिर्फ़ उन्हीं दरवाज़ों को खोलता है जिनकी उन्हें ज़रूरत होती है, और उनके नौकरी छोड़ने पर काम करना बंद कर देता है। एक AI agent भी एक नए तरह का कर्मचारी है। उसे भी अपने खुद के कार्ड की ज़रूरत होती है, किसी और के कार्ड की कॉपी की नहीं।
एक non-human identity (NHI) कोई भी ऐसी पहचान है जिसका इस्तेमाल किसी इंसान की जगह सॉफ़्टवेयर करता है: service accounts, API keys, cloud roles, bot accounts, और अब AI agents। कई कंपनियों में, non-human identities की संख्या इंसानी पहचानों से पहले ही ज़्यादा हो चुकी है, और अक्सर उन्हें ठीक से मैनेज भी नहीं किया जाता: कोई owner नहीं, कोई expiry नहीं, और बहुत ज़्यादा अधिकार।
secrets और identity पर पिछले पाठ में एक agent के लिए नियम तय किए गए थे। यहाँ सवाल बड़े पैमाने (scale) का है: कोई कंपनी नियंत्रण खोए बिना सैकड़ों agents के लिए पहचान कैसे जारी, ट्रैक और हटा सकती है?

आम गलत तरीके (anti-patterns)

अक्सर क्या देखने को मिलता है
  • Agent किसी असली कर्मचारी के अकाउंट से लॉग इन करता है
  • टीम के हर agent द्वारा शेयर की गई एक ही API key
  • Keys जो कभी expire नहीं होतीं, config फ़ाइलों में पेस्ट की हुई
  • Admin अधिकार "क्योंकि सेटअप करना आसान था"
  • कोई owner दर्ज नहीं; किसी को नहीं पता कि इसकी अब भी ज़रूरत है या नहीं
सही तरीका कैसा दिखता है
  • हर agent के लिए, हर environment में अलग पहचान (test और production अलग-अलग)
  • Run time पर जारी किए जाने वाले short-lived credentials
  • Secrets manager में रखे गए secrets, जिन्हें tool code फ़ेच करता है, मॉडल को कभी नहीं दिखाए जाते
  • एक ऐसा role जिसमें ठीक वही permissions दर्ज हों जिनकी काम के लिए ज़रूरत है
  • हर पहचान के लिए एक तय owner और एक expiry या रिव्यू की तारीख

कम समय वाले (short-lived) हमेशा बेहतर होते हैं

लंबे समय तक चलने वाली key हमेशा बना रहने वाला जोखिम है। अगर यह किसी लॉग, स्क्रीनशॉट या प्रॉम्प्ट में लीक हो जाती है, तो जिसे भी यह मिलेगी वह इसका इस्तेमाल तब तक कर सकता है जब तक किसी का ध्यान न जाए। एक short-lived credential अपने आप expire हो जाता है, अक्सर कुछ मिनटों या घंटों में। जब agent कोई काम शुरू करता है, तो उसका runtime किसी भरोसेमंद जारीकर्ता (issuer) से एक नया credential ले लेता है।
इसे workload identity कहा जाता है: प्लेटफ़ॉर्म यह साबित करता है कि कौन सा workload चल रहा है (यह कंटेनर, यह जॉब, यह agent) और उसे उस समय के लिए एक credential देता है। Cloud providers अपने खुद के वर्शन देते हैं। अलग-अलग प्लेटफ़ॉर्म पर workloads को जांची-परखी जा सकने वाली पहचान देने के लिए SPIFFE एक खुला मानक (open standard) है। आपको किसी खास प्रोडक्ट की ज़रूरत नहीं है; आपको इस विचार की ज़रूरत है: पहचान इस बात से तय होती है कि workload कहाँ और क्या है, न कि किसी ऐसे सीक्रेट से जिसे किसी ने कॉपी कर लिया हो।
  1. 1

    Agent काम शुरू करता है

    मॉडल नहीं, बल्कि runtime identity service से credential मांगता है।
  2. 2

    प्लेटफ़ॉर्म workload को साबित करता है

    यह पुष्टि करता है कि यह वाकई environment Y में agent X ही है।
  3. 3

    Short-lived token जारी किया गया

    Agent X के रोल तक सीमित। जल्द ही expire हो जाता है।
  4. 4

    Tool code टोकन का इस्तेमाल करता है

    मॉडल किसी टूल को कॉल करता है; टूल टोकन रखता है। मॉडल इसे कभी नहीं देखता।
  5. 5

    टोकन expire हो जाता है

    हाथ से rotate करने की कोई ज़रूरत नहीं। लीक हुई कॉपी जल्द ही बेकार हो जाती है।

Least privilege, स्पष्ट रूप से तय

Agentज़रूरत हैज़रूरत नहीं है
Invoice पढ़ने वाला agentInvoices फ़ोल्डर पढ़ना; review queue में लिखनाInvoices का भुगतान करना; HR फ़ाइलें पढ़ना; कुछ भी डिलीट करना
IT helpdesk agentटिकट पढ़ना; जांच के बाद non-admin यूज़र्स के पासवर्ड रीसेट करनाAdmin अकाउंट्स में बदलाव करना; सुरक्षा सेटिंग्स बदलना
रिपोर्ट लिखने वाला agentरिपोर्टिंग डेटाबेस व्यू का read-only एक्सेसProduction टेबल्स का write एक्सेस

जीवनचक्र: joiners, movers, leavers

  • Joiner: पहचान केवल मंज़ूरी प्रक्रिया (approval process) के ज़रिए बनाई जाती है, जिसमें owner और role तय होते हैं।
  • Mover: जब agent का काम बदलता है, तो उसके रोल की समीक्षा की जाती है; पुरानी permissions हटाई जाती हैं, न कि सिर्फ़ नई जोड़ी जाती हैं।
  • Leaver: जब agent को हटा दिया जाता है (retire किया जाता है) या उसका owner छोड़ देता है, तो पहचान को disable कर दिया जाता है और credentials रद्द (revoke) कर दिए जाते हैं। लावारिस पड़ी agent identities हमलावरों के घुसने का एक आम ज़रिया होती हैं।
  • Rotation: बाकी बचे किसी भी लंबे समय वाले secrets (ऐसे सिस्टम्स के लिए जो short-lived secrets जारी नहीं कर सकते) को एक तय शेड्यूल पर और किसी भी संदिग्ध लीक के बाद rotate किया जाता है।
ख़तरा
किसी agent को कभी भी किसी इंसान के पासवर्ड या पर्सनल सेशन का इस्तेमाल करके "उनकी जगह काम करने" न दें। आप ऑडिट ट्रेल खो देते हैं, agent के कामों के लिए उस इंसान को ज़िम्मेदार ठहराया जा सकता है, और आप उस इंसान को ब्लॉक किए बिना agent का एक्सेस बंद नहीं कर सकते।
इसे आज़माएं। अपने कार्यस्थल पर किसी एक agent या ऑटोमेशन को चुनें। क्या आप बता सकते हैं: यह किस पहचान का इस्तेमाल करता है, इसका owner कौन है, इसका credential कब expire होता है, और आप इसे एक ही स्टेप में कैसे बंद करेंगे?

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

SPIFFE: secure identities for workloadsSPIFFE project · reading

लैब

तीन agents के लिए पहचान की योजना: identity, permissions, credential का प्रकार, owner और off-switch।

~30 min

समस्या

आप identity lead हैं। तीन agents लाइव होने वाले हैं: एक invoice-reading agent, एक IT helpdesk agent जो पासवर्ड रीसेट कर सकता है, और एक sales report agent जो डेटाबेस को क्वेरी करता है।

  1. हर agent के लिए, शुरुआती टेबल भरें।
  2. Permissions को खास रिसोर्स पर खास एक्शन के तौर पर लिस्ट करें, न कि सिर्फ़ "फाइनेंस का एक्सेस" लिखकर।
  3. दर्ज करें कि कौन सा credential short-lived है और इसे कैसे जारी किया जाता है। अगर आपको कहीं भी static key का इस्तेमाल करना ही पड़े, तो बताएं कि इसे कैसे स्टोर और rotate किया जाता है।
  4. हर agent के लिए, वह एक एक्शन लिखें जो आपातकालीन स्थिति में इसे बंद कर दे।
  5. हर agent के लिए एक "must never" (कभी नहीं करना है) नियम जोड़ें और बताएं कि इसे कहाँ लागू किया गया है (कोड में, identity system में, या टारगेट ऐप में, लेकिन केवल प्रॉम्प्ट में नहीं)।
शुरुआती कोडtext
agent            | identity name        | environment | permissions (action:resource) | credential type & lifetime | owner | off-switch | must never (enforced where?)
invoice-reader   | agent-invoice-read-prod | prod     |                               |                            |       |            |
helpdesk-agent   |                      |             |                               |                            |       |            |
sales-report     |                      |             |                               |                            |       |            |

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

कठिन सवाल

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

Q1Helpdesk agent को पासवर्ड रीसेट करने होंगे, लेकिन एडमिनिस्ट्रेटर के लिए कभी नहीं। आप इसे कहाँ लागू करेंगे, और प्रॉम्प्ट में क्यों नहीं?दिखाएं

इसे identity system में या रीसेट टूल के कोड में लागू करें: agent के रोल के पास एडमिन अकाउंट्स के लिए permissions ही न हों, या टूल टारगेट के ग्रुप की जांच करे और इनकार कर दे। प्रॉम्प्ट में लिखे नियम को किसी चालाकी भरे टिकट से झांसे में लिया जा सकता है। कोड में की गई permission जांच को फुसलाया नहीं जा सकता।

Q2Short-lived tokens मिनटों में expire हो जाते हैं, लेकिन जो हमलावर agent के runtime को कंट्रोल करता है वह लगातार नए टोकन मांग सकता है। क्या short-lived अब भी मददगार है?दिखाएं

हाँ, लेकिन सिर्फ यह अपने आप में काफी नहीं है। यह लीक हुई कॉपियों (logs, prompts, screenshots में) से बचाता है और attacker को runtime के अंदर ही रहने पर मजबूर करता है। किसी active attacker को रोकने के लिए, आपको agent की नए tokens पाने की क्षमता को भी बंद करना होगा (identity को disable करना होगा), यही वजह है कि एक one-step off-switch और token requests की monitoring बहुत मायने रखती है।

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

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

क्या हमारे सभी agents के लिए एक ही service account होना ज़्यादा आसान नहीं है?

सेटअप करने में आसान है, लेकिन चलाना बहुत मुश्किल। एक शेयर्ड अकाउंट के साथ आप यह नहीं बता सकते कि किस agent ने क्या किया, आप हर agent को सिर्फ़ उसकी ज़रूरत की permissions नहीं दे सकते, और किसी गड़बड़ी के दौरान इसे रद्द करने से सभी agents एक साथ बंद हो जाएंगे।

अगर कोई सिस्टम सिर्फ़ static API keys को ही सपोर्ट करता हो तो क्या करें?

Key को secrets manager में रखें, उसे सिस्टम द्वारा अनुमत सबसे सीमित अधिकार दें, सिर्फ़ tool code को इसे फ़ेच करने दें, इसे तय शेड्यूल पर rotate करें, और इसके इस्तेमाल पर नज़र रखें। बाद में किसी बेहतर विकल्प के लिए उस सिस्टम को लिस्ट में डाल दें।

क्या इसे ठीक से करने के लिए मुझे SPIFFE की ज़रूरत है?

नहीं। SPIFFE workload identity के लिए केवल एक खुला मानक है। Cloud platforms के अपने workload identity फ़ीचर्स होते हैं। जो बात मायने रखती है वह है यह पैटर्न: रनिंग workload पर आधारित पहचान, short-lived credentials, और कॉपी किए गए secrets से बचाव।

क्या मॉडल को कभी कोई credential देखना चाहिए?

नहीं। मॉडल के context में मौजूद कोई भी चीज़ आउटपुट, लॉग या URL में जा सकती है। मॉडल किसी काम के लिए कहता है; tool code credential रखता है और उस काम को पूरा करता है।

पाठ का टेस्ट

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

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