आइडेंटिटी और एक्सेस मैनेजमेंट (IAM) यह तय करता है कि कौन सी आइडेंटिटी ऑथेंटिकेट कर सकती है और वह आइडेंटिटी किसी खास रिसोर्स पर कौन से काम कर सकती है। मल्टी-क्लाउड एनवायरनमेंट में, एक कॉर्पोरेट आइडेंटिटी प्रोवाइडर वर्कफोर्स साइन-इन की सुविधा दे सकता है, जबकि AWS, Azure और Google Cloud अपनी-अपनी एडमिनिस्ट्रेटिव सीमाओं के भीतर ऑथराइज़ेशन से जुड़े फैसले लेते हैं। सफल साइन-इन का मतलब यह नहीं है कि रिसोर्स API रिक्वेस्ट के लिए ऑथराइज़ेशन मिल गया है। AWS में, वर्कफोर्स SSO को आमतौर पर IAM आइडेंटिटी सेंटर के ज़रिए कॉन्फ़िगर किया जाता है, और AWS सिक्योरिटी टोकन सर्विस (STS) के साथ IAM रोल अस्थायी क्रेडेंशियल जारी करते हैं।
काम की सीमा आइडेंटिटी प्रोवाइडर, हर क्लाउड कंट्रोल प्लेन और हर क्लाउड के डेटा प्लेन के बीच होती है। कंट्रोल प्लेन क्लाउड रिसोर्स और उनके कॉन्फ़िगरेशन को मैनेज करता है। डेटा प्लेन खुद रिसोर्स के लिए आने वाली रिक्वेस्ट को संभालता है; जब ऐसी कोई रिक्वेस्ट आती है, तो हर क्लाउड अपने IAM में प्रिंसिपल, एक्शन, रिसोर्स और संबंधित शर्तों का मूल्यांकन करता है। ये प्लेन आइडेंटिटी की जानकारी शेयर कर सकते हैं, लेकिन वे एक ही यूनिवर्सल परमिशन सेट शेयर नहीं करते हैं।
अब हम रिसोर्स एक्सेस का मतलब निकाले बिना साइन-इन सीमाओं का पता लगा सकते हैं।
मल्टी-क्लाउड IAM में गड़बड़ियाँ अक्सर जाने-पहचाने शब्दों से शुरू होती हैं, जिनके दायरे (स्कोप) अलग-अलग होते हैं। AWS अकाउंट, AWS रिसोर्स के लिए एक एडमिनिस्ट्रेटिव बाउंड्री (प्रशासनिक दायरा) है। Azure टेनेंट, Microsoft Entra ID डायरेक्टरी की बाउंड्री है, जबकि Azure रिसोर्स का एक्सेस आम तौर पर Azure RBAC (रोल-बेस्ड एक्सेस कंट्रोल) के ज़रिए मैनेजमेंट ग्रुप, सब्सक्रिप्शन, रिसोर्स ग्रुप या रिसोर्स के दायरे में ऑथराइज़ किया जाता है। Google Cloud में, ऑर्गनाइज़ेशन और प्रोजेक्ट, Cloud IAM पॉलिसी अटैचमेंट और रिसोर्स ओनरशिप के लिए अलग-अलग दायरे देते हैं।
यह फ़र्क इसलिए ज़रूरी है क्योंकि आइडेंटिटी मेंबरशिप, रिसोर्स की परमिशन नहीं है। Azure में, Microsoft Entra ID किसी यूज़र को ऑथेंटिकेट कर सकता है और ग्रुप मेंबरशिप दिखा सकता है, लेकिन Azure RBAC को फिर भी अनुरोध किए गए Azure एक्शन को ऑथराइज़ करने के लिए एक लागू होने वाला रोल देना होगा। AWS में, AWS IAM पॉलिसी और AWS STS क्रेडेंशियल, AWS ऑथराइज़ेशन में शामिल होते हैं। Google Cloud में, Cloud IAM संबंधित रिसोर्स हायरार्की के लिए अपनी पॉलिसी बाइंडिंग का मूल्यांकन करता है। एक जैसे दिखने वाले ग्रुप के नाम इन बाउंड्री के बीच एक जैसा एक्सेस नहीं बनाते हैं।
ऑपरेशनल सबूत भी इसी तरह सीमित होते हैं। कॉर्पोरेट आइडेंटिटी प्रोवाइडर का साइन-इन इवेंट यह दिखा सकता है कि ऑथेंटिकेशन हुआ था, लेकिन अकेले यह साबित नहीं कर सकता कि AWS, Azure या Google Cloud ने बाद में API अनुरोध की अनुमति दी थी। क्लाउड ऑडिट रिकॉर्ड उस क्लाउड में कंट्रोल-प्लेन या रिसोर्स API के प्रयास को दिखा सकता है, लेकिन यह साबित नहीं करता कि कॉर्पोरेट आइडेंटिटी प्रोवाइडर का लाइफ़साइकल डेटा सही था। हमें उस प्लेन से सबूत चाहिए जिसने फ़ैसला लिया था, जिसमें उसकी आइडेंटिटी, रिसोर्स, एक्शन और समय की अवधि शामिल हो।
फ़ैसले का नियम एक बार में एक क्लाउड और एक अनुरोध के एक्सेस की जाँच करें। सबसे पहले प्रिंसिपल, टारगेट रिसोर्स, API एक्शन और उस ऑथराइज़ेशन प्लेन की पहचान करें जिसने इसका मूल्यांकन किया था।
हम सभी आइडेंटिटी को एक जैसा मानने के बजाय एक सीमित वर्कलोड का इस्तेमाल करेंगे। orders-api सर्विस पोर्ट 8080 पर काम करती है। एक वर्कफ़ोर्स आइडेंटिटी, orders-workforce-user, उस ऑपरेटर को दिखाती है जिसे कॉर्पोरेट आइडेंटिटी प्रोवाइडर के ज़रिए इंटरैक्टिव एक्सेस की ज़रूरत होती है। app-operators ग्रुप तय ऑपरेशनल रोल को दिखाता है, जबकि cloud-admins को जान-बूझकर अलग रखा गया है क्योंकि एडमिनिस्ट्रेटिव एक्सेस में अलग तरह का जोखिम और मंज़ूरी की बाउंड्री होती है।
ऑटोमेटेड आइडेंटिटी orders-ci है, जो एक कंटीन्यूअस इंटीग्रेशन जॉब को दिखाती है जो वर्कलोड को डिप्लॉय या मैनेज करती है। इसके अनुरोध वर्कफ़ोर्स ब्राउज़र सेशन नहीं होते हैं। यह लंबे समय तक चलने वाली क्लाउड एक्सेस कीज़ रखने के बजाय हर क्लाउड के लिए कम समय तक चलने वाले फ़ेडरेटेड क्रेडेंशियल प्राप्त करती है। हमारे प्रोवाइडर की सीमाएँ AWS अकाउंट dev, Azure टेनेंट contoso, और Google Cloud प्रोजेक्ट orders-prod हैं; बाद में आने वाले हर ऑथराइज़ेशन सवाल में इनमें से किसी एक टारगेट का साफ़ तौर पर ज़िक्र होना चाहिए।
अब हम देख सकते हैं कि वर्कफ़ोर्स और CI आइडेंटिटी पाथ हर क्लाउड तक कैसे पहुँचते हैं।