क्या API होस्ट एलियस आपकी डेस्टिनेशन समीक्षा को बायपास कर सकते हैं?

डेस्टिनेशन समीक्षा तभी उपयोगी है जब उसमें उस नाम की समीक्षा हो जो क्रेडेंशियल पाता है। यदि कोई टीम https://api.example.test को मंजूर करती है लेकिन एजेंटों को https://api-us.example.test, https://gateway.example.test या वेंडर के दिए संगतता एंडपॉइंट का उपयोग करने की छूट देती है, तो मंजूरी सीमा नहीं, केवल इरादा बताती है।

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

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

डेस्टिनेशन समीक्षा सिर्फ़ सटीक होस्ट को कवर करती है

api.example.test की समीक्षा api-eu.example.test, proxy.example.test या api.example.test.evil.invalid को मंजूरी नहीं देती। क्रेडेंशियल केवल उस सटीक, सामान्यीकृत होस्टनेम तक जाना चाहिए जो उस क्रेडेंशियल की स्पष्ट इन्वेंट्री में मौजूद हो।

टीमें अक्सर ऐसे अनौपचारिक नियम से शुरू करती हैं: “यह टोकन Example के API के लिए है।” यह ओनरशिप का कथन है, डेस्टिनेशन का नियम नहीं। किसी कंपनी के पास कई डोमेन हो सकते हैं, वेंडर कई नामों के पीछे ट्रैफ़िक बदल सकता है और तीसरा पक्ष वेंडर के एज का एक हिस्सा होस्ट कर सकता है। HTTP क्लाइंट को ठोस URL चाहिए। आपके नियंत्रण को भी चाहिए।

सीमा को उन शब्दों में लिखें जिनकी URL पार्सर तुलना कर सकता है:

• स्कीम: आम तौर पर https
• होस्टनेम: IDNA हैंडलिंग के बाद लोअरकेस ASCII होस्टनेम
• पोर्ट: स्पष्ट पोर्ट या स्कीम का डिफ़ॉल्ट
• पाथ नीति: केवल तब, जब क्रेडेंशियल किसी खास API सतह तक सीमित हो

होस्टनेम सूची की जगह सफ़िक्स जांच न लगाएं। endsWith("example.test") notexample.test को स्वीकार करता है। endsWith(".example.test") फिर भी वर्तमान और भविष्य के हर सबडोमेन को स्वीकार करता है। एक मालिक और मजबूत जारीकरण नियंत्रण वाले आंतरिक सर्विस मेश में यह स्वीकार्य हो सकता है। प्रोडक्शन डेटा बदल सकने वाले क्रेडेंशियल के लिए यह आम तौर पर लापरवाही है।

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

यह डेस्टिनेशन नियंत्रण को अनुरोध सामग्री की समीक्षा से अलग करता है। समीक्षक मंजूर होस्ट पर GET से सहज हो सकता है, पर बिलिंग बदलने वाले POST को अस्वीकार कर सकता है। ये अलग सवाल हैं। यह दावा न करें कि होस्टनेम जांच अनुरोध के सुरक्षित होने का फैसला करती है। वह बस तय करती है कि क्रेडेंशियल कहां जा सकता है।

CNAME रूट बदलता है, HTTP होस्ट नहीं

CNAME DNS रिज़ॉल्यूशन बदलता है। वह अपने आप URL का होस्टनेम, HTTP Host हेडर या सामान्य HTTPS क्लाइंट द्वारा भेजा जाने वाला TLS सर्वर नेम इंडिकेशन नहीं बदलता।

मान लें एजेंट यह URL कॉल करता है:

https://api.example.test/v1/orders

DNS यह जवाब दे सकता है:

api.example.test.  300  IN  CNAME  api.edge.vendor.test.
api.edge.vendor.test. 300 IN A      203.0.113.42

TCP कनेक्शन 203.0.113.42 तक पहुंचता है, संभव है वेंडर का इन्फ्रास्ट्रक्चर उसे चला रहा हो। क्लाइंट को फिर भी TLS से api.example.test मांगना चाहिए और Host: api.example.test भेजना चाहिए। यदि सर्वर उस मूल नाम के लिए वैध सर्टिफ़िकेट नहीं देता, तो सर्टिफ़िकेट सत्यापन विफल होना चाहिए। यदि देता है, तो उस समय सर्वर उस नाम का ट्रैफ़िक समाप्त करने के लिए अधिकृत है।

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

RFC 1034 CNAME को दूसरे डोमेन नाम का एलियस बताता है और कैनॉनिकल नाम पर लुकअप जारी रखने की मांग करता है। इससे रिज़ॉल्वर का व्यवहार समझ आता है, HTTP क्रेडेंशियल का फैसला नहीं। DNS को बेयरर टोकन, API स्कोप या आपके चेंज अप्रूवल की कोई जानकारी नहीं होती।

चार व्यावहारिक स्थितियों में CNAME सुरक्षा से जुड़ जाता है:

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

चौथा मामला टोकन लीक करता है। पहले तीन समीक्षा कमजोर करते हैं और भविष्य में लीक की संभावना बढ़ाते हैं। इनके लिए अलग जांच और अलग जिम्मेदार लोग होने चाहिए।

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

वैकल्पिक बेस URL अधिक शांत बायपास बनाते हैं

वैकल्पिक बेस URL ज़्यादा आम बायपास हैं, क्योंकि वे सीधे HTTP अथॉरिटी बदलते हैं। ये नाम एनवायरनमेंट वैरिएबल, SDK डिफ़ॉल्ट, टेस्ट फिक्स्चर और माइग्रेशन नोट्स में छिपे होते हैं।

किसी सेवा में वैध कारणों से ये सभी दस्तावेज़ित हो सकते हैं:

https://api.example.test
https://api-us.example.test
https://sandbox-api.example.test
https://gateway.example.test/service-a
https://tenant-42.api.example.test

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

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

कोड ठीक करने से पहले डेटा मॉडल ठीक करें। हर क्रेडेंशियल का अपना रिकॉर्ड होना चाहिए, जिसमें समीक्षक चार फ़ील्ड देख सकें:

credential: orders-write-prod
allowed authorities:
  https://api.example.test:443
  https://api-us.example.test:443
purpose: create and amend production orders
owner: commerce operations
review trigger: DNS change, new endpoint, scope change

“अथॉरिटीज़” शब्द जानबूझकर चुना गया है। स्कीम, होस्ट और पोर्ट को साथ में स्टोर करें। HTTPS पर ठीक होस्टनेम किसी गैर-मानक पोर्ट के लिए अपने आप मंजूर नहीं होता। साझा गेटवे में एक होस्ट अलग-अलग API के लिए हो तो पाथ मायने रख सकता है, हालांकि पाथ नियमों को बहुत सावधानी से सामान्यीकृत करें और स्कोप अलग होने पर वे कभी अलग क्रेडेंशियल की जगह न लें।

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

क्रेडेंशियल की ऑडियंस ही सीमा है

सही सवाल “इस वेंडर के कौन से सर्वर हैं?” नहीं है। सवाल है “इस सटीक अनुरोध पथ में इस सटीक सीक्रेट को कौन सी HTTP अथॉरिटीज़ मिल सकती हैं?”

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

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

क्रेडेंशियल बाइंडिंग के दो हिस्से हैं:

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

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

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

कोड, DNS और वेंडर दस्तावेज़ों से नामों की इन्वेंट्री बनाएं

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

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

फिर हर उम्मीदवार को उसी रिज़ॉल्वर संदर्भ से रिज़ॉल्व करें जो कॉलिंग मशीन इस्तेमाल करती है। macOS या किसी अन्य Unix सिस्टम पर बुनियादी जांच ऐसी दिखती है:

dig +noall +answer api.example.test CNAME A AAAA

उपयोगी आउटपुट का आकार यह है:

api.example.test.       300 IN CNAME api.edge.vendor.test.
api.edge.vendor.test.    60 IN A     203.0.113.42
api.edge.vendor.test.    60 IN AAAA  2001:db8::42

यदि आपका रिज़ॉल्वर एक उत्तर में पूरी चेन नहीं देता, तो CNAME, A और AAAA के लिए अलग क्वेरी चलाएं। क्वेरी की तारीख और इस्तेमाल हुआ रिज़ॉल्वर दर्ज करें, क्योंकि स्प्लिट DNS लैपटॉप, CI रनर और प्रोडक्शन होस्ट को अलग जवाब दे सकता है। इंटरनेट API के लिए मिले IP पते को स्थायी अलाउलिस्ट में न डालें। एज के पते नियमित रूप से बदलते हैं। उसे समीक्षा के प्रमाण के रूप में दर्ज करें और चौंकाने वाले बदलावों पर अलर्ट करें।

इसके बाद हर वेंडर नहीं, हर अथॉरिटी के लिए एक पंक्ति वाली इन्वेंट्री तालिका बनाएं। उसे बिना मीटिंग के इन सवालों के जवाब देने चाहिए:

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

OWASP की Server-Side Request Forgery Prevention Cheat Sheet संबंधित बात कहती है: जब ऐप्लिकेशन सिर्फ़ पहचाने गए भरोसेमंद ऐप्लिकेशन से बात करता है, तब अलाउलिस्ट व्यवहार्य है, लेकिन केवल डोमेन सत्यापन DNS के व्यवहार का फैसला नहीं करता। यह मार्गदर्शन SSRF के लिए है, फिर भी संचालन संबंधी सबक यहां लागू होता है। होस्टनेम सूची तभी मजबूत है जब आपको पता हो कि नामों का रखरखाव कौन करता है, वे कहां रिज़ॉल्व होते हैं और क्या कोई कॉलर समीक्षा किए गए नाम को बाद में अलग अनुरोध में बदल सकता है।

रीडायरेक्ट की अपनी समीक्षा होनी चाहिए

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

क्रेडेंशियल वाले API कॉल में शुरुआत रीडायरेक्ट बंद रखकर करें। 301, 302, 303, 307 या 308 रिस्पॉन्स को ऐसे रिस्पॉन्स की तरह लें जिसके लिए स्पष्ट फैसला चाहिए। नया URL पहले से क्रेडेंशियल की सटीक अथॉरिटी सूची में हो, और मेथड व बॉडी व्यवहार स्वीकार्य हो, तो उसे अलग अनुरोध के रूप में भेजें। सूची में न हो तो रुक जाएं।

स्टेटस कोड एक जैसे नहीं हैं। 303 आम तौर पर अनुरोध को GET में बदल देता है, जबकि 307 और 308 मेथड और अनुरोध बॉडी बचाए रखते हैं। ऑथराइज़ेशन हेडर के साथ POST का अपने आप दोबारा भेजा जाना, सामान्य दिखने वाले GET से अधिक असरदार है, खासकर जब नया होस्ट अलग हो।

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

सुरक्षित कॉल पथ बताना आसान है:

1. Parse the requested URL.
2. Normalize and match its authority against the credential record.
3. Inject the credential only after that match.
4. Send one request with redirects disabled.
5. If a redirect arrives, parse and review the new authority before any new request.

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

साझा होस्टनेम के लिए अलग क्रेडेंशियल चाहिए

एक होस्टनेम कई API, परिवेश और टेनेंट होस्ट कर सकता है। सटीक होस्ट मैच जरूरी है, लेकिन साझा गेटवे के पीछे के सभी सुरक्षा अंतर नहीं बता सकता।

https://gateway.example.test पर विचार करें। एक पाथ इनवॉइस बना सकता है, दूसरा टेलीमेट्री भेज सकता है और तीसरा उपयोगकर्ताओं का प्रशासन कर सकता है। एक बेयरर टोकन तीनों को अधिकृत करे, तो होस्ट समीक्षा सिर्फ़ मोटा सुरक्षा स्तर देती है। /telemetry को /admin में बदलने वाला बग मंजूर होस्टनेम पर ही रहता है और फिर भी सफल होता है।

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

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

यही तर्क पोर्ट पर लागू होता है। api.example.test:443 और api.example.test:8443 अलग अथॉरिटीज़ हैं। रिवर्स प्रॉक्सी उन्हें अलग सेवाओं तक भेज सकता है और दूसरे पोर्ट की जांच करने वाला डेवलपर मान सकता है कि पहली समीक्षा उसे कवर करती है। दोनों दर्ज करें या किसी को अनुमति न दें।

मंजूरी वहां रखें जहां इंसान अभी भी डेस्टिनेशन समझ सके

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

Sallyport क्रेडेंशियल को अपने एन्क्रिप्टेड वॉल्ट में रखता है और HTTP कार्रवाई खुद करता है, एजेंट को सीक्रेट नहीं देता। यह उपयोगी है, क्योंकि मंजूरी कार्रवाई की सीमा पर ली जा सकती है, जहां डेस्टिनेशन और अनुरोध करने वाली प्रक्रिया साथ दिखाई देते हैं।

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

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

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

हर DNS और इंटीग्रेशन बदलाव के बाद एलियस दोबारा जांचें

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

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

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

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

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