संवेदनशील एक्सेस से पहले एजेंट क्लाइंट का संस्करण पिन करें

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

एजेंट क्लाइंट के लिए संस्करण पिनिंग रिलीज़ नियंत्रण का तरीका है, खराब प्रॉम्प्ट या बहुत अधिक अनुमतियों का इलाज नहीं। इससे आपको एक उपयोगी सुविधा मिलती है: आप किसी ज्ञात आर्टिफैक्ट की जांच कर सकते हैं, दर्ज कर सकते हैं कि आपने क्या परखा और किसी ऐसी बदली हुई कॉपी को संवेदनशील एक्सेस देने से मना कर सकते हैं जिसकी समीक्षा नहीं हुई है। यह साधारण बात लगती है, लेकिन इससे बची जा सकने वाली कई विफलताएं रुकती हैं।

मैंने टीमों को वॉल्ट और मंज़ूरी डायलॉग पर गंभीर मेहनत करते देखा है, फिर भी वे डेस्कटॉप अपडेटर को रातोंरात अनुरोध भेजने वाले प्रोग्राम को बदलने देते हैं। लूप में इंसान अब भी था, लेकिन वह ऐसे कोड के व्यवहार को मंज़ूरी दे रहा था जिसकी किसी ने जांच नहीं की थी। यह कोई सार्थक सुरक्षा सीमा नहीं है।

दोस्ताना संस्करण लेबल नहीं, एक्जीक्यूटेबल की पहचान पिन करें

सटीक संस्करण संख्या ज़रूरी है, लेकिन अकेले वह स्थानीय क्लाइंट की पर्याप्त पहचान नहीं करती। 2.4.1 जैसा रिलीज़ लेबल बताता है कि प्रकाशक ने क्या भेजने का इरादा किया था। यह साबित नहीं करता कि आपने कौन-से बाइट इंस्टॉल किए, उन पर किसने हस्ताक्षर किए, कौन-सा रनटाइम उन्हें चला रहा है या स्टार्टअप के बाद किसी एक्सटेंशन ने उनका व्यवहार बदल दिया है।

एक उपयोगी मंज़ूरी रिकॉर्ड कई स्तरों पर आर्टिफैक्ट की पहचान करता है:

• क्लाइंट का नाम और सटीक रिलीज़ स्ट्रिंग।
• डाउनलोड किए गए इंस्टॉलर या एक्जीक्यूटेबल का SHA-256 डाइजेस्ट।
• कोड-साइनिंग अथॉरिटी और बंडल आइडेंटिफ़ायर, जहां ऑपरेटिंग सिस्टम इन्हें दिखाता हो।
• इंस्टॉल पथ, रनटाइम संस्करण और एक्सटेंशन की सूची।
• तारीख, समीक्षक और उस रिकॉर्ड के लिए स्वीकृत सेवाएं या क्रेडेंशियल स्कोप।

वर्ज़न पिन और आर्टिफैक्ट पिन के बीच का अंतर महत्वपूर्ण है। वर्ज़न पिन इंस्टॉलर को बताता है कि उसे कौन-सा रिलीज़ खोजना चाहिए। आर्टिफैक्ट पिन आपको उस फाइल को अस्वीकार करने देता है जो जांची गई फाइल से अलग है। टीमें अक्सर इन शब्दों को मिला देती हैं, क्योंकि पैकेज मैनेजर दोनों के लिए «पिन» शब्द इस्तेमाल करते हैं। नतीजा खराब हो सकता है: वे 1.4.3 को स्वीकृत करते हैं, किसी संक्रमित मिरर या बदले हुए कैश से फिर से बनाया गया 1.4.3 प्राप्त करते हैं और उनके पास यह पता लगाने वाला कोई स्थानीय टेस्ट नहीं होता।

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

इसे केवल कागजी कार्रवाई न बनाएं। घटना के दौरान रिकॉर्ड को एक सवाल का जवाब देना चाहिए: «उस अनुरोध को भेजने की अनुमति किस कोड के पास थी?» अगर उसमें केवल «कोडिंग एजेंट» लिखा है, तो वह इसका जवाब नहीं दे सकता।

लॉक की गई डिपेंडेंसी ट्री और समीक्षा किए गए क्लाइंट में अंतर है

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

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

OpenSSF SLSA विनिर्देश प्रोवेनेंस और इंटीग्रिटी के बीच उपयोगी अंतर बताता है। प्रोवेनेंस बताती है कि आर्टिफैक्ट कहां और कैसे बनाया गया। इंटीग्रिटी जांच यह स्थापित करती है कि आर्टिफैक्ट बदला नहीं है। इनमें से कोई भी दावा यह नहीं कहता कि प्रोग्राम को क्रेडेंशियल देना सुरक्षित है। फिर भी दोनों महत्वपूर्ण हैं, क्योंकि टीम किसी ऐसे लक्ष्य की समीक्षा या पुनर्निर्माण नहीं कर सकती जो लगातार बदल रहा हो।

डेवलपर एजेंट शुरू करता है तो क्या-क्या चलता है, पहले उसका नक्शा बनाएं। macOS पर Dock आइकन पर भरोसा करने के बजाय शेल से पूछें:

command -v agent-client
file "$(command -v agent-client)"
head -n 1 "$(command -v agent-client)"

पहली कमांड का परिणाम स्क्रिप्ट होने पर head कमांड महत्वपूर्ण है। #!/usr/bin/env node जैसी पहली लाइन बताती है कि Node रनटाइम और पैकेज ट्री निष्पादन पथ का हिस्सा हैं। अगर पहली लाइन किसी दूसरे लॉन्चर को चलाती है, तो आपको ट्रेसिंग जारी रखनी होगी। शेल एलियस, सिमलिंक या बूटस्ट्रैप स्क्रिप्ट को क्लाइंट मानकर स्वीकृत न करें।

एप्लिकेशन बंडल के लिए असली एक्जीक्यूटेबल और साइनिंग मेटाडेटा देखें:

APP="/Applications/Agent Client.app"
BIN="$APP/Contents/MacOS/Agent Client"
shasum -a 256 "$BIN"
codesign -dv --verbose=4 "$APP" 2>&1 | grep -E 'Identifier=|TeamIdentifier=|Authority='
spctl --assess --type execute --verbose=4 "$APP"

हैश आउटपुट का रूप digest path होता है। codesign आउटपुट में आम तौर पर आइडेंटिफ़ायर, टीम आइडेंटिफ़ायर और एक या अधिक अथॉरिटी लाइन शामिल होती हैं। उस आउटपुट को मंज़ूरी रिकॉर्ड के साथ सुरक्षित रखें। spctl macOS से ऐप का उसकी मौजूदा सुरक्षा नीति के तहत आकलन करने को कहता है। यह उपयोगी प्रमाण है, लेकिन इसका मतलब यह नहीं कि ऐप को डिप्लॉयमेंट क्रेडेंशियल मिलना चाहिए।

«लॉकफाइल कमिट की गई है» जैसी समीक्षा बहुत-से सवाल अनुत्तरित छोड़ देती है। लॉकफाइल रखें। फिर उस आर्टिफैक्ट की पहचान करें जो वास्तव में संवेदनशील कार्रवाई शुरू करता है।

प्रोटोकॉल संगतता क्लाइंट पर भरोसा स्थापित नहीं करती

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

Model Context Protocol का दस्तावेज़ बताता है कि इनिशियलाइज़ेशन के दौरान क्लाइंट और सर्वर घोषित क्षमताओं का आदान-प्रदान करते हैं। यह क्षमता वार्ता इंटरऑपरेबिलिटी के लिए उपयोगी है। यह क्लाइंट बाइनरी का प्रमाणीकरण, लोड किए गए एक्सटेंशन का बयान या उपयोगकर्ता के इरादे को बनाए रखने का वादा नहीं है। सफल हैंडशेक को पहचान जांच न मानें।

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

तीन रिकॉर्ड अलग रखें:

1. आपने जिस प्रोटोकॉल संस्करण और क्षमताओं की जांच की।
2. वह क्लाइंट आर्टिफैक्ट, साइनिंग पहचान, रनटाइम और एक्सटेंशन जिन्हें आपने स्वीकृत किया।
3. वे सेवा अनुमतियां जिनका अनुरोध यह क्लाइंट कर सकता है।

इनमें से किसी एक रिकॉर्ड में बदलाव समीक्षा योग्य है। प्रोटोकॉल अपग्रेड डिफ़ॉल्ट या संदेश प्रबंधन बदल सकता है। क्लाइंट अपग्रेड यह बदल सकता है कि वह कौन-से टूल चलाता है या कब दोबारा कोशिश करता है। सेवा अनुमति में बदलाव पहले सुरक्षित लगने वाली रीट्राई को नुकसानदेह बना सकता है।

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

केवल चैट विंडो नहीं, अनुमति का पूरा रास्ता जांचें

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

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

इन मामलों की जानबूझकर जांच करें:

• अपेक्षित प्रतिक्रिया वाला सामान्य अनुमत अनुरोध।
• ऐसा अनुरोध जो क्रेडेंशियल का स्कोप पार करे और अस्वीकृति पाए।
• प्रतिक्रिया में देरी या कनेक्शन विफलता, जिससे रीट्राई व्यवहार शुरू हो।
• रीडायरेक्ट या बदला हुआ एंडपॉइंट, अगर क्लाइंट HTTP इस्तेमाल करता है।
• बदली हुई होस्ट कुंजी वाला SSH कनेक्शन, अगर क्लाइंट SSH इस्तेमाल करता है।

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

सीक्रेट दर्ज किए बिना अनुरोध मेटाडेटा कैप्चर करें। HTTP के लिए टेस्ट एंडपॉइंट मेथड, होस्ट, पथ, स्टेटस और चुने हुए गैर-संवेदनशील हेडर लॉग कर सकता है। पता करें कि गेटवे कौन-सा ऑथराइज़ेशन हेडर जोड़ता है, फिर यह भी पक्का करें कि क्लाइंट को वह हेडर मान टूल परिणाम, त्रुटि संदेश या स्थानीय ट्रांसक्रिप्ट में वापस न मिले।

नुकसान पहुंचाने वाली एंडपॉइंट के लिए स्टेजिंग कार्रवाई में पहचानने योग्य निशान छोड़ें। केवल HTTP 200 लौटाने वाला टेस्ट बहुत कम साबित करता है। आपको प्रमाण चाहिए कि ठीक एक इच्छित कार्रवाई हुई, रीट्राई के बाद गलत कार्रवाई नहीं हुई और ऑडिट रिकॉर्ड सही सत्र की पहचान करता है।

कैंडिडेट को स्वीकृत क्लाइंट से अलग रखें

कैंडिडेट रिलीज़ की अपनी इंस्टॉलेशन, कॉन्फ़िगरेशन, कैश और एक्सटेंशन डायरेक्टरी होनी चाहिए। इन्हें साझा करने पर टेस्ट बिल्ड को ऐसी स्थिति मिलती है जो साफ इंस्टॉल से अलग हो सकती है और रोलबैक कम भरोसेमंद बनता है। जिन परेशान करने वाली विफलताओं की मैंने जांच की, उनमें सबसे आम यह था कि «नया» क्लाइंट चुपचाप पुराना प्लगइन लोड कर रहा था या प्रमाणीकृत ब्राउज़र सत्र का दोबारा इस्तेमाल कर रहा था।

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

दोनों संस्करणों को एक ही लिखने योग्य कॉन्फ़िगरेशन फाइल से न जोड़ें। क्लाइंट अक्सर शुरू होते समय कॉन्फ़िगरेशन फ़ॉर्मैट अपडेट करते हैं। नया बिल्ड ऐसी फील्ड लिख सकता है जिसे पुराना बिल्ड नज़रअंदाज़ करे या गलत ढंग से संभाले। इससे रोलबैक आंशिक माइग्रेशन बन जाता है, जबकि आपको रोलबैक को बिल्कुल साधारण रखना चाहिए।

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

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

प्रमोशन को छोटा और दोहराने योग्य रिलीज़ बदलाव बनाएं

प्रमोशन में एक समीक्षा किए गए रिकॉर्ड की जगह दूसरे रिकॉर्ड को रखना चाहिए। यह इस बात पर निर्भर नहीं होना चाहिए कि किसी ने कौन-सा डाउनलोड बटन दबाया था। हर बार एक ही क्रम लिखकर रखें। इससे समीक्षकों को साझा शब्दावली और ऑन-कॉल इंजीनियर को समझदार रोलबैक रास्ता मिलता है।

1. प्रकाशक के सामान्य रिलीज़ चैनल से कैंडिडेट डाउनलोड करें और उसका स्रोत, सटीक संस्करण, हैश और साइनर दर्ज करें।
2. उसे अलग टेस्ट स्थान पर इंस्टॉल करें और लोड होने वाले रनटाइम तथा एक्सटेंशन दर्ज करें।
3. स्टेजिंग क्रेडेंशियल से अनुमति-पथ के टेस्ट चलाएं, जिनमें अस्वीकृत और विफलता वाले मामले भी हों।
4. देखे गए अनुरोधों, प्रॉम्प्ट और लॉग की तुलना स्वीकृत व्यवहार से करें। हर नए विशेषाधिकार अनुरोध की जांच करें।
5. स्वीकृत कैंडिडेट को विशेषाधिकार वाले स्थान पर इंस्टॉल करें, पिछला आर्टिफैक्ट सुरक्षित रखें और इंस्टॉलेशन जांच रिकॉर्ड से मेल खाने के बाद ही एक्सेस बदलें।

आखिरी क्रम महत्वपूर्ण है। पहले एक्सेस देकर बाद में इंस्टॉल की गई फाइल देखने की योजना न बनाएं। अगर इंस्टॉलेशन जांच विफल हो, तो कैंडिडेट को संवेदनशील सेवाओं को कॉल करने से रोकें। रिलीज़ को अस्वीकार करना सामान्य परिणाम है, प्रक्रिया की विफलता नहीं।

ऐसा सरल रिकॉर्ड रखें जो ऑपरेशनल नोट्स के साथ रखा जा सके। YAML उपयोगी है, क्योंकि घटना के दौरान लोग इसे पढ़ सकते हैं:

client:
  name: agent-client
  version: "2.4.1"
  executable_sha256: "replace-with-verified-digest"
  signer_team_id: "record-the-observed-team-id"
  install_path: "/Applications/Agent Client.app"
  runtime: "native bundle"
review:
  tested_on: "2025-03-08"
  reviewer: "initials"
  extensions: []
access:
  environments: ["staging", "production-read"]
  forbidden_actions: ["secret-rotation", "deployment-write"]
rollback:
  previous_version: "2.4.0"

ऊपर के मान प्लेसहोल्डर हैं, प्रमाण के रूप में कॉपी करने का टेम्पलेट नहीं। इन्हें अपनी वास्तविक जांच से भरें। खास तौर पर, डाउनलोड की गई फाइल का हैश निकाले बिना किसी रिलीज़ घोषणा से डाइजेस्ट कभी पेस्ट न करें।

«इस विक्रेता के सभी रिलीज़ अनुमत हैं» जैसे व्यापक नियमों से बचें। वे लोकप्रिय हैं, क्योंकि उनसे समीक्षा का काम कम होता है। साथ ही वे पिनिंग के सटीक नियंत्रण को मिटा देते हैं। विक्रेता की पहचान समीक्षा का एक इनपुट हो सकती है, लेकिन यह अज्ञात कोड को आपके प्रोडक्शन क्रेडेंशियल इस्तेमाल करने की स्थायी अनुमति नहीं है।

ऑटोमैटिक अपडेट और संवेदनशील एक्सेस की सीमा अलग होनी चाहिए

कई डेस्कटॉप ऐप्लिकेशन के लिए ऑटोमैटिक अपडेट उचित हैं। जोखिम तब बदलता है जब ऐप स्टोर किए गए क्रेडेंशियल, SSH कुंजी या विशेषाधिकार वाले सेवा खातों के ज़रिए बाहरी कार्रवाई कर सकता है। ऐसे में अपडेटर एक कार्यदिवस और अगले कार्यदिवस के बीच प्रोग्राम बदल सकता है जो प्राधिकरण मांगता है।

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

तीसरा तरीका अनपेक्षित अपडेट से होने वाले नुकसान को सीमित करता है, लेकिन इसे बढ़ा-चढ़ाकर न देखें। नया मंज़ूरी कार्ड तभी उपयोगी है जब वह प्रोसेस की सार्थक पहचान करे। सामान्य क्लाइंट नाम देखकर हर सुबह क्लिक करना लोगों को सामने आने वाली किसी भी चीज़ को स्वीकृत करने की आदत डालता है। साइनिंग अथॉरिटी, प्रोसेस पथ या ऐसी दूसरी पहचान दिखाएं जिसकी तुलना समीक्षक स्वीकृत रिकॉर्ड से कर सके।

अपडेट किए गए क्लाइंट को केवल इसलिए चुपचाप अनुमति न दें कि वह ऑपरेटिंग सिस्टम ऐप स्टोर से आया है या macOS उसे साइन किया हुआ मानता है। ये तरीके सप्लाई-चेन के कुछ जोखिम कम करते हैं। वे यह नहीं बताते कि नया व्यवहार आपके एक्सेस नियमों से मेल खाता है या नहीं। अपने क्रेडेंशियल देने का निर्णय अब भी आपका संगठन लेता है।

संस्करण पिनिंग के साथ समय-सीमा की आदत भी चाहिए। स्थायी पिन ऐसा पिन बन जाता है जिसे पैच नहीं किया गया। क्लाइंट, उससे पहुंच वाली सेवाओं और विक्रेता की सुरक्षा सलाह के आधार पर समीक्षा की आवृत्ति तय करें। व्यवहार न बदला हो तो समीक्षा को नाटकीय बनाने की ज़रूरत नहीं। फिर भी एक जानबूझकर लिया गया निर्णय ज़रूरी है।

हर कार्रवाई का प्राधिकरण उस व्यवहार को पकड़ता है जिसे पिन नहीं पकड़ सकती

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

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

एक व्यावहारिक विभाजन यह है कि कम जोखिम वाली रीड को सत्र मंज़ूरी के तहत जाने दें और ऐसी कार्रवाइयों के लिए स्पष्ट मंज़ूरी मांगें जो स्थिति बदल सकती हैं या डेटा उजागर कर सकती हैं। सीमा सेवा पर निर्भर करती है। सोर्स रिपॉज़िटरी को पढ़ना सामान्य हो सकता है। ग्राहक डेटाबेस को पढ़ना डेटा प्रकटीकरण हो सकता है। केवल HTTP वर्ब के आधार पर वर्गीकरण न करें।

Sallyport एक तय निर्णय क्रम अपनाता है: वॉल्ट लॉक होने पर हर कार्रवाई अस्वीकार होती है, नए एजेंट प्रोसेस को डिफ़ॉल्ट रूप से सत्र प्राधिकरण चाहिए और चुनी हुई क्रेडेंशियल एंट्री हर उपयोग पर मंज़ूरी मांग सकती है। यह सीमित मॉडल जानबूझकर रखा गया है। सामान्य पॉलिसी लैंग्वेज ज्यादा विकल्प देती, लेकिन टीमों को ऐसे अपवाद लिखने के और रास्ते भी देती जिन्हें वे समझ नहीं पातीं।

रद्द करने की सुविधा तुरंत उपलब्ध रखें। जब कैंडिडेट क्लाइंट अनपेक्षित व्यवहार करे, तो लंबी जांच शुरू करने से पहले उसका मौजूदा एक्सेस सत्र रोक पाना चाहिए। बाद में सेवा क्रेडेंशियल रद्द करना ज़रूरी हो सकता है, लेकिन यह कठोर कदम है और असंबंधित काम तोड़ सकता है। पहले सत्र रद्द करके चल रही प्रोसेस को रोकें।

ऑडिट रिकॉर्ड को कार्रवाई और स्वीकृत रन के बीच संबंध दिखाना चाहिए

«API कॉल सफल हुई» कहने वाला कार्रवाई लॉग एजेंट के काम के लिए पर्याप्त नहीं है। कॉल को स्थानीय प्रोसेस, मंज़ूरी निर्णय, इस्तेमाल की गई क्रेडेंशियल और उस समय लागू क्लाइंट रिकॉर्ड से जोड़ना ज़रूरी है। वरना घटना की समीक्षा टर्मिनल, ब्राउज़र इतिहास और सेवा लॉग में समय मिलाने तक सीमित रह जाएगी।

हर एजेंट प्रोसेस के लिए सत्र रिकॉर्ड रखें। उसमें प्रोसेस शुरू होने का समय, उपयोगकर्ता ने उसे कैसे अधिकृत किया, उसकी देखी गई पहचान और वह कब समाप्त या रद्द हुई, शामिल होना चाहिए। अलग-अलग कार्रवाइयों के लिए अलग गतिविधि रिकॉर्ड रखें। उसमें गंतव्य, ऑपरेशन, परिणाम और सत्र संबंध दर्ज हों, लेकिन सीक्रेट सामग्री न हो।

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

Sallyport अपने Sessions और Activity जर्नल को एक ही एन्क्रिप्टेड, हैश-चेन वाले ऑडिट लॉग से प्रोजेक्ट करता है, और sp audit verify वॉल्ट कुंजी के बिना सिफरटेक्स्ट पर ऑफलाइन चेन जांच सकता है। यह डिजाइन तब उपयोगी है जब ट्रेल की समीक्षा करने वाले व्यक्ति को कार्रवाइयों में इस्तेमाल सीक्रेट तक पहुंच नहीं देनी हो।

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

आसपास का सिस्टम बदलता रहे तो पिनिंग विफल हो जाती है

सावधानी से हैश किया गया क्लाइंट भी ऐसी मशीन पर चलता है जो उसके नीचे बदल सकती है। ऑपरेटिंग सिस्टम, रनटाइम, शेल वातावरण, DNS कॉन्फ़िगरेशन, प्रॉक्सी सेटिंग, सर्टिफिकेट स्टोर, स्थानीय हेल्पर बाइनरी और डेवलपर द्वारा इंस्टॉल किए गए एक्सटेंशन सभी प्रभावित करते हैं कि अनुरोध मशीन से कैसे बाहर जाते हैं। पिनिंग पूरी श्रृंखला का एक नियंत्रण है, जोखिम भरे सेटअप पर चिपकाया जाने वाला लेबल नहीं।

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

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

ऑपरेशनल आदत सरल है: क्लाइंट बदलने पर एक्सेस तब तक रोकें जब तक नया आर्टिफैक्ट उसे हासिल न कर ले। पुरानी स्वीकृत कॉपी उपलब्ध रखें, वास्तविक अनुमति पथ पर रिप्लेसमेंट की जांच करें और प्रमाण दर्ज करें। यह अनुशासन स्वायत्त डेमो जितना रोमांचक नहीं है। यही आपको बैकग्राउंड अपडेट को बिना समीक्षा वाले प्रोडक्शन बदलाव में बदलने से बचाता है।