DeployBot को बिल्ड पाइपलाइन से आर्टिफैक्ट्स पब्लिश करने के लिए एक लंबे समय तक चलने वाला टोकन मिलता है। एक जॉब CI लॉग में टोकन प्रिंट करती है, एक अटैकर लॉग आउटपुट हासिल करता है, और वही टोकन एक नए IP एड्रेस से सफलतापूर्वक एक इंटरनल पैकेज पब्लिश करता है। अटैकर को किसी कर्मचारी के पासवर्ड, फ़िशिंग पेज या यूज़र सेशन की ज़रूरत नहीं थी। अटैकर को बस एक ऐसे क्रेडेंशियल की ज़रूरत थी जो एक ऑटोमेटेड प्रिंसिपल को दर्शाता हो।
नॉन-ह्यूमन आइडेंटिटी एक ऑटोमेटेड वर्कलोड, सर्विस, पाइपलाइन, डिवाइस या एजेंट के पीछे का प्रिंसिपल होता है। इस एनवायरनमेंट में, DeployBot के पास अधिकार इसलिए है क्योंकि डाउनस्ट्रीम सर्विसेज़ उसके टोकन को स्वीकार करती हैं, न कि इसलिए कि कोई इंसान हर रिक्वेस्ट पर MFA पूरा करता है। इसलिए डिफेंडर का सवाल ऑपरेशनल है: हम सीमित दायरे वाले अधिकार कैसे जारी करें, प्रोडक्शन को बाधित किए बिना उसे कैसे रोटेट करें, और जब क्रेडेंशियल अपने तय रनटाइम से बाहर निकल जाए तो उसके गलत इस्तेमाल को कैसे पहचानें?
सबसे आसान विफलता में एक इनपुट और एक परिणाम होता है। DeployBot आर्टिफैक्ट रजिस्ट्री को एक कॉपी किया हुआ बेयरर टोकन देता है, और रजिस्ट्री एक आर्टिफैक्ट पब्लिश करती है क्योंकि टोकन वैध रहता है और उसमें ज़रूरी परमिशन होती है। टोकन कब्ज़े को साबित करता है, न कि उस वैध स्थान या प्रक्रिया को जिससे वह प्राप्त हुआ था, जब तक कि आस-पास का आइडेंटिटी डिज़ाइन उन चेक्स को न जोड़े।
बाउंड्री नियम एक नॉन-ह्यूमन क्रेडेंशियल को एक प्रिंसिपल की पहचान करनी चाहिए, उसके अधिकार को सीमित करना चाहिए, और जारी होने के बाद भी निगरानी में रहना चाहिए।
टोकन लीक मायने रखता है क्योंकि DeployBot prod-gke-1 में केवल एक आइडेंटिटी पाथ है। कुबेरनेट्स क्लस्टर Orders API, Billing API, और Inventory API चलाता है। उन सर्विसेज़ के साथ-साथ, SupportAgent स्वीकृत सपोर्ट टूल्स को कॉल करता है, ETLBot डेटा इम्पोर्ट करता है, और DeployBot आर्टिफैक्ट्स बनाता और पब्लिश करता है। प्रत्येक प्रिंसिपल एक ऑथराइज़ेशन निर्णय, एक क्रेडेंशियल लाइफ़साइकल और सबूत बनाता है जिसे डिफेंडर्स को बनाए रखना चाहिए।
अटैक सरफेस केवल क्लस्टर नहीं है। रिक्वेस्ट्स क्लस्टर बाउंड्री, वर्कलोड्स के बीच सर्विस-मेश बाउंड्री, आर्टिफैक्ट रजिस्ट्री, सीक्रेट्स स्टोर, आइडेंटिटी प्रोवाइडर और ऑथराइज़ेशन सर्वर, और बाहरी SaaS प्रोवाइडर API को पार करती हैं। एक बाउंड्री से कॉपी किया गया क्रेडेंशियल दूसरी बाउंड्री पर स्वीकार किया जा सकता है जब पॉलिसीज़ क्रेडेंशियल को उसके जारीकर्ता, ऑडियंस, वर्कलोड, स्रोत या अनुमत कार्रवाई पर विचार किए बिना पर्याप्त सबूत मानती हैं। नीचे दिया गया एनवायरनमेंट बाद के कंट्रोल्स को एक सुसंगत लक्ष्य देता है।
आइए पता करें कि क्रेडेंशियल्स और टोकन उन बाउंड्रीज़ को कहाँ पार करते हैं:
यह डायग्राम दिखाता है कि अथॉरिटी टोकन के साथ कई सिस्टम में घूमती है, जबकि हर सिस्टम रिक्वेस्ट ट्रेल का सिर्फ़ कुछ हिस्सा ही रिकॉर्ड करता है।
क्योंकि इन्वेंट्री में हर अथॉरिटी पाथ का नाम होता है, इसलिए हम कंट्रोल चुनने से पहले फेलियर का मॉडल बना सकते हैं। रिपॉजिटरी या CI लॉग से लीक हुई API की (key) हमलावर को रिवोकेशन (रद्द होने) तक प्रिंसिपल का रूप धरने देती है। चोरी हुआ OAuth क्लाइंट सीक्रेट नए एक्सेस टोकन बना सकता है। रीप्ले किया गया एक्सेस टोकन किसी अनपेक्षित नेटवर्क या रनटाइम से काम कर सकता है। ये चोरी के अलग-अलग रास्ते हैं, लेकिन हर एक एक ही सीमा को पार करता है: एक बाहरी एक्टर ऐसे क्रेडेंशियल पेश करता है जो एक कंट्रोल्ड वर्कलोड के लिए होते हैं।
बहुत ज़्यादा दायरा (स्कोप) चोरी के बाद असर को बदल देता है। अगर SupportAgent एक व्यापक ग्रांट के तहत बिलिंग रिकॉर्ड पढ़ सकता है और रिफंड टूल चला सकता है, तो प्रॉम्प्ट-आधारित टूल रिक्वेस्ट या कॉम्प्रोमाइज़्ड एजेंट कंपोनेंट ऐसी कार्रवाई कर सकता है जो रिक्वेस्ट करने वाले की मंशा वाली अथॉरिटी से बाहर हो। यह कन्फ्यूज्ड डेप्युटी समस्या है: वैध अथॉरिटी वाली सर्विस किसी ऐसे कॉलर के लिए कार्रवाई करती है जिस पर भरोसा नहीं है या जिसके पास पर्याप्त अथॉरिटी नहीं है। कंट्रोल सिर्फ़ मज़बूत ऑथेंटिकेशन नहीं है। टूल कॉल के लिए एक स्पष्ट पॉलिसी की ज़रूरत होती है जो रिक्वेस्ट करने वाले प्रिंसिपल, टारगेट रिसोर्स और अनुमति वाले ऑपरेशन को जोड़ती है।
रोटेशन एक शांत फेलियर लाता है। सीक्रेट स्टोर में नया क्रेडेंशियल हो सकता है जबकि ETLBot पुराने कैश किए गए सीक्रेट का इस्तेमाल करता रहता है, या कोई डाउनस्ट्रीम SaaS प्रोवाइडर दोनों वर्शन को योजना से ज़्यादा समय तक स्वीकार कर सकता है। रोटेशन तभी पूरा होता है जब पुराना क्रेडेंशियल रिक्वेस्ट को ऑथराइज़ नहीं कर पाता और वर्कलोड यह साबित कर देता है कि वह नए क्रेडेंशियल का इस्तेमाल कर सकता है।
बाद का बिल्ड हर खतरे को रोकथाम और सबूत के साथ जोड़ता है:
नीचे दी गई तुलना हर क्रेडेंशियल फेलियर के साथ सीमा, रोकथाम के उपाय और सबूत के सोर्स को जोड़कर रखती है।