सिक्योरिटी इंजीनियरिंग वर्कलोड की ज़रूरत को एक ऐसे कंट्रोल में बदलती है जिसे टेस्ट किया जा सके, मॉनिटर किया जा सके और सुरक्षित रूप से हटाया जा सके। Azure में, यह काम Microsoft Entra टेनेंट, सब्सक्रिप्शन के अंदर Azure रिसोर्स मैनेजर और हर सर्विस के डेटा प्लेन तक फैला होता है, इसलिए हो सकता है कि कोई सेटिंग देखने में सही लगे लेकिन वह गलत दायरे (scope) को सुरक्षित कर रही हो।
हम काल्पनिक रिसोर्स ग्रुप rg-orders-dev में एक सीमित डेवलपमेंट वर्कलोड का इस्तेमाल करेंगे। इसका मकसद उन फैसलों, सबूतों और सीमाओं को सामने लाना है जिन्हें क्लाउड सिक्योरिटी इंजीनियर को किसी कॉन्फ़िगरेशन को सुरक्षा के तौर पर मानने से पहले तय करना होता है।
किसी एसेट और खतरे (threat) से जुड़ी ज़रूरत से शुरुआत करें। उदाहरण के लिए, एक ऑर्डर-प्रोसेसिंग API को पब्लिक इंटरनेट पर सीक्रेट को उजागर किए बिना सीक्रेट हासिल करना चाहिए। कंट्रोल वह कॉन्फ़िगर किया गया तरीका है जिसका मकसद उस ज़रूरत को पूरा करना है, जबकि सबूत (evidence) एक ऐसा रिकॉर्ड है जो इसके कॉन्फ़िगरेशन या गतिविधि के बारे में किसी सीमित दावे का समर्थन करता है।
हमारा वर्कफ़्लो एक जैसा रहता है। हम एसेट, डेटा बाउंड्री, पहचान और खतरे की पहचान करते हैं; सबसे छोटा सही कंट्रोल चुनते हैं; अगर एक्सेस से मना किया जाता है या ट्रैफ़िक किसी अनचाहे रास्ते से जाता है तो होने वाली संभावित विफलता (failure) को तय करते हैं; फिर कॉन्फ़िगरेशन और रनटाइम सबूतों के साथ मनचाहे नतीजे की पुष्टि करते हैं। क्लीनअप अस्थायी परमिशन, टेस्ट सीक्रेट या डायग्नोस्टिक सेटिंग को तब हटा देता है जब उनकी ज़रूरत नहीं रह जाती, जिससे टेस्टिंग आर्टिफैक्ट्स स्थायी जोखिम (exposure) नहीं बनते।
कॉन्फ़िगरेशन सबूत और रनटाइम सबूत अलग-अलग सवालों के जवाब देते हैं। रोल असाइनमेंट या प्राइवेट एंडपॉइंट कॉन्फ़िगरेशन कंट्रोल-प्लेन की मनचाही स्थिति को दिखाते हैं। Key Vault ऑडिट इवेंट, स्टोरेज डायग्नोस्टिक लॉग या एप्लिकेशन की विफलता रिकॉर्ड किए गए समय के दौरान डेटा-प्लेन पर की गई कोशिश को दिखाते हैं। इनमें से कोई भी अकेले यह साबित नहीं करता कि हर रास्ता सुरक्षित है या किसी घटना का कोई और कारण नहीं है।
सिफ़ारिशें सुरक्षा स्थिति में कमियों (posture gaps) की पहचान करती हैं, लेकिन उन्हें लागू करने का काम ‘deny policy’ या खुद कंट्रोल के ज़रिए होना चाहिए।
Microsoft बुनियादी Azure फिजिकल इंफ्रास्ट्रक्चर को सुरक्षित करता है, जबकि कस्टमर वर्कलोड डेटा, एप्लिकेशन के व्यवहार, आइडेंटिटी और एक्सेस विकल्पों के लिए ज़िम्मेदार होता है। इस साझा-ज़िम्मेदारी वाली सीमा का मतलब यह नहीं है कि प्लेटफ़ॉर्म-मैनेज्ड सर्विस के लिए कस्टमर को सुरक्षा से जुड़ा कोई काम नहीं करना है। इसका मतलब है कि सबूत या सुधार के उपाय चुनने से पहले हमें यह पहचानना होगा कि किस लेयर का मालिक कौन है।
Microsoft Entra डायरेक्टरी यूज़र्स, एप्लिकेशन और मैनेज्ड आइडेंटिटी को ऑथेंटिकेट करती है। Azure Resource Manager, जिसे अक्सर ARM कहा जाता है, सब्सक्रिप्शन या रिसोर्स ग्रुप में रिसोर्स बनाने और कॉन्फ़िगर करने के लिए Azure का कंट्रोल प्लेन है। इन स्कोप पर Azure RBAC रोल असाइनमेंट कंट्रोल-प्लेन के कामों को ऑथराइज़ करते हैं, जैसे कि स्टोरेज अकाउंट के नेटवर्किंग कॉन्फ़िगरेशन को बदलना।
सर्विस डेटा प्लेन एक सर्विस-स्पेसिफिक इंटरफ़ेस है जो सुरक्षित डेटा को पढ़ता, लिखता या इस्तेमाल करता है। Key Vault सीक्रेट को निकालना और Blob डेटा को एक्सेस करना उनके संबंधित डेटा प्लेन पर होता है, जहाँ उनके डेटा-प्लेन ऑथराइज़ेशन और नेटवर्क कंट्रोल ARM ऑथराइज़ेशन से स्वतंत्र रूप से लागू होते हैं। कोई कॉन्ट्रिब्यूटर जो वॉल्ट को कॉन्फ़िगर कर सकता है, वह ज़रूरी नहीं कि उसके सीक्रेट्स को पढ़ने के लिए भी ऑथराइज़्ड हो।
इसका एक बार-बार इस्तेमाल होने वाला नियम यह है कि यह तय करने से पहले कि एक्सेस सफल होना चाहिए या नहीं, प्रिंसिपल, एक्शन, स्कोप और प्लेन का नाम तय किया जाए।
हमारा काल्पनिक वर्कलोड app-orders-api है, जो एक काल्पनिक सब्सक्रिप्शन <subscription-id> के अंदर rg-orders-dev में मौजूद Azure App Service ऐप है। यह चुने हुए Azure क्षेत्र में चलता है और आउटबाउंड वर्चुअल नेटवर्क इंटीग्रेशन के लिए vnet-orders-dev का इस्तेमाल करता है। एप्लिकेशन को stordersdev में ऑर्डर डेटा और kv-orders-dev में एक सीक्रेट की ज़रूरत होती है, जबकि law-sec-01 वह Log Analytics वर्कस्पेस है जिसका इस्तेमाल Microsoft Sentinel करता है।
वर्चुअल नेटवर्क एप्लिकेशन की नेटवर्क सीमा है, न कि हर Azure सर्विस रिसोर्स की लोकेशन। stordersdev और kv-orders-dev Azure प्लेटफ़ॉर्म सेवाएँ हैं जो vnet-orders-dev के बाहर रहती हैं; प्राइवेट एंडपॉइंट इन सेवाओं के लिए वर्चुअल नेटवर्क में प्राइवेट नेटवर्क इंटरफ़ेस बनाते हैं। प्राइवेट DNS और सर्विस की नेटवर्क सेटिंग्स को API के आउटबाउंड अनुरोध को पब्लिक एंडपॉइंट के बजाय उन एंडपॉइंट एड्रेस पर भेजना चाहिए।
ऐप की मैनेज्ड आइडेंटिटी को बाद में अपने तय Key Vault और Storage कार्यों के लिए अलग डेटा-प्लेन परमिशन की ज़रूरत होगी। Sentinel law-sec-01 पर चलता है, जहाँ कनेक्टर और डायग्नोस्टिक सेटिंग्स यह तय करती हैं कि विश्लेषण के लिए कौन से रिकॉर्ड आएँगे। एक वर्कस्पेस केवल उस डेटा की जाँच में मदद कर सकता है जो असल में उसमें इकट्ठा किया गया था।
API से उसके प्राइवेट एंडपॉइंट और मॉनिटरिंग वर्कस्पेस तक वर्कलोड की सीमा का पता लगाएँ।