# क्या AI प्रोवाइडर फॉलबैक क्रेडेंशियल और ऑडिट को सुरक्षित रखता है?

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

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

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

## फॉलबैक रूट दूसरा अथॉरिटी पथ है

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

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

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

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

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

## तीन पहचानें स्वतंत्र रूप से बदल सकती हैं

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

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

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

नेटवर्क कनेक्शन खोलने से पहले रूट को एक पूरे ऑब्जेक्ट के रूप में लिखें। यह छद्म कॉन्फ़िगरेशन न्यूनतम ढांचा दिखाता है:

```json
{
  "operation_class": "customer-text-summary",
  "primary": {
    "provider": "provider-a",
    "account": "production-eu",
    "credential_ref": "vault:provider-a-prod-eu",
    "region": "eu",
    "data_class": "redacted-customer-text"
  },
  "fallbacks": [
    {
      "provider": "provider-b",
      "account": "production-backup-eu",
      "credential_ref": "vault:provider-b-backup-eu",
      "region": "eu",
      "data_class": "redacted-customer-text",
      "approval": "destination-specific"
    }
  ],
  "deny_when": ["account_missing", "region_mismatch", "credential_ref_missing"]
}
```

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

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

## डिफॉल्ट क्रेडेंशियल चुपचाप अकाउंट बदल देते हैं

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

एक आम विफलता क्रम इस तरह होता है:

1. एक वर्कर स्पष्ट प्रोडक्शन क्रेडेंशियल रेफरेंस से प्रोवाइडर A को अनुरोध भेजता है।
2. अनुरोध पहुंचने की अनिश्चित स्थिति के बाद प्रोवाइडर A टाइमआउट लौटाता है।
3. रीट्राई रैपर प्रोवाइडर B को चुनता है और डिफॉल्ट क्रेडेंशियल खोज के साथ उसका क्लाइंट बनाता है।
4. प्रोवाइडर B वर्कर एनवायरनमेंट से क्रेडेंशियल स्वीकार कर लेता है, जो साझा क्लाउड रोल या डेवलपर का बनाया टोकन हो सकता है।
5. वर्कर केवल `fallback succeeded` लिखता है और परिणाम लौटा देता है।

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

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

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

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

## एक लगातार ट्रेस के लिए केवल रिक्वेस्ट ID पर्याप्त नहीं

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

प्राथमिक रूट चुनने से पहले ऑपरेशन ID बनाएं। उसे यूज़र रिक्वेस्ट, एजेंट रन या क्यू जॉब के लिए स्थिर रखें। फिर हर प्रोवाइडर कॉल के लिए प्रयास नंबर बनाएं, जिसमें नेटवर्क से पहले रोकी गई कॉल भी शामिल हो। उपयोगी रिकॉर्ड का ढांचा कुछ ऐसा हो सकता है:

```json
{
  "operation_id": "op_7c1d",
  "attempt": 2,
  "parent_attempt": 1,
  "reason": "primary_timeout",
  "provider": "provider-b",
  "account": "production-backup-eu",
  "credential_ref": "vault:provider-b-backup-eu",
  "region": "eu",
  "data_class": "redacted-customer-text",
  "approval_id": "apr_391",
  "result": "sent"
}
```

बाद का परिणाम इवेंट उसी ऑपरेशन ID और प्रयास नंबर के साथ लिखें। प्रोवाइडर की ओर से मिलने वाली रिमोट रिक्वेस्ट IDs भी शामिल करें, लेकिन उन्हें प्राथमिक कॉरिलेशन फ़ील्ड न बनाएं। रोकी गई कॉल के लिए वे मौजूद ही नहीं होतीं और दो प्रोवाइडर उनके फ़ॉर्मैट पर सहमत नहीं होंगे।

W3C Trace Context Recommendation एक ऐसा ट्रेस आइडेंटिफ़ायर परिभाषित करती है जो सर्विस सीमाओं के पार जाता है, और OpenTelemetry इस कॉन्टेक्स्ट का इस्तेमाल स्पैन को जोड़ने के लिए करता है। जहां आपकी सेवाएं इसे सपोर्ट करती हों, वहां ऑपरेशनल ट्रेसिंग के लिए इसका इस्तेमाल करें। यह ऊपर बताए गए अथॉरिटी फ़ील्ड का विकल्प नहीं है। कोई ट्रेस सही-सही दिखा सकता है कि अनुरोध पांच सेवाओं से गुजरा, फिर भी यह नहीं बता सकता कि अंतिम सीमा के पार कौन सा क्रेडेंशियल गया।

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

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

## डेटा रेजिडेंसी के लिए स्पष्ट अस्वीकृति पथ चाहिए

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

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

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

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

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

## क्रेडेंशियल से पहले राउटर रखें

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

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

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

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

macOS टीमों के लिए Sallyport एजेंट क्रेडेंशियल को एन्क्रिप्टेड वॉल्ट में रखता है और एजेंट सेशन के साथ अलग-अलग HTTP या SSH कार्रवाइयां दर्ज करता है। फिर भी राउटर को Sallyport से कॉल कराने से पहले हर इच्छित डेस्टिनेशन स्पष्ट रूप से निर्दिष्ट करना होगा।

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

## मंज़ूरी में डेस्टिनेशन शामिल होना चाहिए

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

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

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

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

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

## खराबी को प्रोडक्शन विफलता की तरह जांचें

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

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

हर विफलता मामले में इन पांच परिणामों की पुष्टि करें:

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

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

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

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

## घटना के बाद सबूत सुरक्षित रखें

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

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

जर्नल की नियमित अंतराल पर और घटना की प्रतिक्रिया के दौरान जांच करें। Sallyport का `sp audit verify` एन्क्रिप्टेड हैश-चेन वाले ऑडिट लॉग की ऑफलाइन जांच करता है और इसके लिए वॉल्ट कुंजी की जरूरत नहीं होती। जब आप कार्रवाई करने वाले सीक्रेट खोले बिना सबूत जांचना चाहते हैं, तो यही सही तरह की जांच है।

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