CSPM का दायरा, सबूत और वर्कलोड

पोस्चर (स्थिति) को रनटाइम व्यवहार से अलग करें

कॉन्फ़िगरेशन का सबूत यह बताता है कि डेटा इकट्ठा करते समय प्रोवाइडर का कंट्रोल प्लेन क्या रिपोर्ट करता है। एक्टिविटी लॉग मैनेजमेंट से जुड़े कामों का पुराना रिकॉर्ड रखते हैं, जैसे कि किसी प्रिंसिपल का पॉलिसी बदलना या कोई रिसोर्स बनाना। AWS में ये AWS Config और CloudTrail हैं, Azure में Azure Resource Graph और Activity Log हैं, और Google Cloud में Cloud Asset Inventory और Cloud Audit Logs हैं। ये सभी सोर्स मिलकर यह दिखा सकते हैं कि कोई सेटिंग मौजूद है और यह भी बता सकते हैं कि उसे किसने बदला, लेकिन इनमें से कोई भी यह साबित नहीं करता कि कोई एप्लीकेशन रिक्वेस्ट सफल रही, डेटा एक्सेस किया गया, या नेटवर्क पैकेट सुरक्षित था।

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

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

अधूरे नतीजों को पहचानें

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

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

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

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

सीमित वर्कलोड सेट अप करें

हम orders-api नाम के एक जानबूझकर छोटे वर्कलोड का इस्तेमाल करेंगे। यह एक एप्लिकेशन सर्विस है जो पोर्ट 8080 पर काम करती है और ऑर्डर डेटा को प्रोवाइडर-नेटिव ऑब्जेक्ट स्टोरेज रिसोर्स में स्टोर करती है। हर वर्ज़न अपने प्रोवाइडर की सीमा के अंदर ही रहता है, इसलिए यह नहीं माना जाता कि कोई आइडेंटिटी, स्टोरेज परमिशन या जानकारी एक क्लाउड से दूसरे क्लाउड में जाएगी।

AWS में, orders-api रोल orders-api-role और बकेट orders-data-s3 का इस्तेमाल करता है। Azure में, यह मैनेज्ड आइडेंटिटी orders-api-mi और स्टोरेज अकाउंट ordersdatast का इस्तेमाल करता है। Google Cloud में, यह सर्विस अकाउंट orders-api-sa और बकेट orders-data-gcs का इस्तेमाल करता है। ये आइडेंटिफायर काल्पनिक हैं, लेकिन जिस सीमा को वे दिखाते हैं, उसे दोबारा इस्तेमाल किया जा सकता है।

हम देख सकते हैं कि हर वर्कलोड आइडेंटिटी कैसे अपने प्रोवाइडर के रिसोर्स तक ही सीमित रहती है।