AI एजेंटों के लिए क्लाउड लागत कार्रवाइयों में सख्त सीमा जरूरी है

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

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

रिपोर्टिंग के साथ खर्च करने की अनुमति नहीं होनी चाहिए

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

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

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

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

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

झूठे भरोसे से बचने के लिए रिपोर्ट में पर्याप्त संदर्भ भी होना चाहिए। कम से कम यह जानकारी रखें:

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

यह नौकरशाही नहीं है। मासिक अमोर्टाइज्ड लागत और रोज का नकद शुल्क, दोनों सही हो सकते हैं, फिर भी प्रस्तावित कमिटमेंट पर इनके आधार पर विपरीत निष्कर्ष निकल सकते हैं।

कार्रवाई को API क्रिया से नहीं, परिणाम से वर्गीकृत करें

update जैसा क्रिया-शब्द जोखिम के बारे में लगभग कुछ नहीं बताता। क्लाउड लागत कार्रवाई को इस आधार पर वर्गीकृत करें कि वह क्या बदलती है, उसका प्रभाव कितना दूर तक जाता है और उसे वापस करना कितना कठिन है।

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

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

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

{
  "action": "resize_compute_group",
  "scope": {
    "billing_account": "finance-prod",
    "region": "eu-west-1",
    "resource_group": "batch-workers"
  },
  "before": {"instance_type": "c6i.2xlarge", "minimum": 6},
  "after": {"instance_type": "c6i.xlarge", "minimum": 6},
  "expected_monthly_delta": {"currency": "USD", "amount": -412},
  "service_effect": "rolling replacement of batch workers",
  "rollback": "restore c6i.2xlarge and wait for replacements",
  "approval": "per_call"
}

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

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

सुझाव प्रमाण है, निर्देश नहीं

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

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

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

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

जब प्रमाण कम हो, तो एजेंट से साफ तौर पर रुकने को कहें। अच्छा रुकना कुछ ऐसा होगा:

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

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

कमिटमेंट के लिए अलग खरीद समीक्षा रखें

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

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

प्रस्ताव में ये बातें सरल भाषा में लिखी हों:

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

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

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

प्रोवाइडर का दस्तावेजीकरण आमतौर पर योग्यता के नियमों को सटीकता से बताता है, जबकि बिलिंग कंसोल उन्हें मोटे तौर पर दिखाता है। दोनों में अंतर हो तो API और बिलिंग दस्तावेज को सही स्रोत मानें। कंसोल की «estimated savings» एक परिस्थिति का अनुमान है, अनुबंध समीक्षा नहीं।

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

क्षमता का आकार बदलने से बचत से पहले सेवा टूट सकती है

आकार बदलना चल रही प्रणाली को बदलता है, भले ही प्रोवाइडर उसे सामान्य काम माने। कम बिल मंजूर करने से पहले एजेंट को परिचालन परिणाम दिखाना चाहिए।

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

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

कार्रवाई अनुरोध में सभी लक्ष्य चयनकर्ता तय होने चाहिए। resize all nonproduction workers जैसी स्वतंत्र टेक्स्ट कमांड को अनुमति सीमा पार न करने दें। पहले लक्ष्य सूची तय करके दिखाएं और मंजूरी के बाद ऐसे पहचानकर्ता भेजें जो स्वीकृति के बाद बने नए संसाधनों से मेल न खा सकें।

एक उपयोगी कार्रवाई क्रम में चार हिस्से होते हैं:

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

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

अकाउंट बंद करने के लिए अलग क्रेडेंशियल और मानवीय पुष्टि चाहिए

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

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

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

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

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

अनुमोदन सटीक कॉल से जुड़ा होना चाहिए

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

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

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

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

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

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

ऐसा ऑडिट रिकॉर्ड रखें जिसे एजेंट बदल न सके

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

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

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

NIST SP 800-92, Guide to Computer Security Log Management, लॉग की अखंडता सुरक्षित रखने और समीक्षा के लिए लॉग उपलब्ध कराने की सलाह देता है। यह सलाह पुरानी है क्योंकि समस्या भी पुरानी है: टीमें लॉग उसी जगह जमा करती हैं जहां वही समझौता किया गया प्रोसेस उन्हें बदल सकता है। एजेंट कार्रवाइयों के लिए ऑडिट राइटर को एजेंट की सीधी फाइल सिस्टम और क्रेडेंशियल पहुंच से बाहर रखें।

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

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

क्लाउड सुपरयूजर के बजाय सीमित कार्रवाई मार्ग बनाएं

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

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

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

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

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