IaC स्कैनिंग: एक शानदार, अनदेखी सीखने का अवसर

कोड (IaC) के रूप में आप बुनियादी ढांचे के बारे में जो कुछ भी पढ़ते हैं, वह इस बात पर केंद्रित होता है कि यह कैसे काम करता है या आप यह सुनिश्चित क्यों करना चाहते हैं कि यह वास्तव में जिस तरह से आप इसे बनाना चाहते हैं, उसका निर्माण कर रहा है।

ये महत्वपूर्ण क्षेत्र हैं। लेकिन क्या हम इस बारे में पर्याप्त सोच रहे हैं कि हम अपने संगठन में इस दृष्टिकोण का उपयोग कैसे करते हैं?

As मेलिंडा मार्क्स कंपनी की रिपोर्ट में ईएसजी राज्यों से, "83% संगठनों ने IaC टेम्पलेट गलत कॉन्फ़िगरेशन में वृद्धि का अनुभव किया" क्योंकि वे प्रौद्योगिकी को अपनाना जारी रखते हैं।

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

IaC को समर्थित है को कम करने
बुनियादी ढांचे के निर्माण को व्यवस्थित करके गलत कॉन्फ़िगरेशन, कठोरता और प्रक्रिया का एक स्तर जोड़ना जो सुनिश्चित करता है कि टीमें जो चाहती हैं और केवल वही बना रही हैं जो वे चाहते हैं। अगर ~83% टीमें इसे नहीं देख रही हैं, तो खेल में एक गहरी समस्या है।

छोटी टीमों पर, जहां DevOps दर्शन के देव और ऑप्स बिट्स एक साथ हैं, यह समझ में आता है। IaC इन छोटी टीमों को एक ही भाषा - कोड - का उपयोग करने की अनुमति देता है ताकि वे जो कुछ भी कर रहे हैं उसका वर्णन कर सकें।

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

क्लाउड सेवा का ops/SRE/प्लेटफ़ॉर्म परिप्रेक्ष्य उसी सेवा के डेवलपर परिप्रेक्ष्य से बेतहाशा भिन्न होगा। एक डेवलपर एक कतार सेवा को देखेगा और उसके इंटरफ़ेस में गोता लगाएगा - जोड़ने के लिए एक सरल समापन बिंदु और एक पढ़ने के लिए? बेचा। यह एक आसान एकीकरण है।

इस परिचालन परिप्रेक्ष्य का उद्देश्य किनारों को खोजना है। तो, यह कतार अपनी सीमा तक कब पहुँचती है? क्या प्रदर्शन स्थिर है या क्या यह लोड के तहत मौलिक रूप से बदलता है?

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

नतीजतन, यह वह जगह है जहां सुरक्षा चिंताएं अक्सर बढ़ जाती हैं।

अधिकांश टूलिंग - वाणिज्यिक या खुला स्रोत - उन चीजों की पहचान करने पर केंद्रित है जो बुनियादी ढांचे के टेम्पलेट्स में गलत हैं। इस
एक अच्छी रचना है। निर्माण इसका
बुरा होगा। इन उपकरणों का उद्देश्य इन परिणामों को निरंतर एकीकरण/निरंतर वितरण (सीआई/सीडी) पाइपलाइन के हिस्से के रूप में उत्पन्न करना है।

यह एक बेहतरीन शुरुआत है। लेकिन यह उसी भाषा के मुद्दे को प्रतिध्वनित करता है।

कौन बात कर रहा है और कौन सुन रहा है?

जब कोई IaC टूल किसी समस्या को हाइलाइट करता है, तो उसका समाधान कौन करेगा? यदि यह विकास दल है, तो क्या उसके पास यह जानने के लिए पर्याप्त जानकारी है कि इसे एक मुद्दे के रूप में क्यों फ़्लैग किया गया? यदि यह ऑपरेशन टीम है, तो क्या रिपोर्ट में दिए गए मुद्दे के परिणाम हैं?

डेवलपर्स के लिए, अक्सर ऐसा होता है कि वे IaC परीक्षण पास करने के लिए केवल कॉन्फ़िगरेशन को समायोजित करेंगे।

संचालन के लिए, यह आम तौर पर एक बात है कि परीक्षण पास हो रहे हैं या नहीं। यदि वे हैं, तो अगले कार्य पर। यह किसी भी टीम पर दस्तक नहीं है; बल्कि, यह उम्मीदों बनाम वास्तविकता के अंतर को उजागर करता है।

क्या जरूरत है संदर्भ है। IaC सुरक्षा टूलिंग जो (उम्मीद है) बनने वाली है, उसमें दृश्यता प्रदान करती है। लक्ष्य मुद्दों को रोकना है से पहले वे उत्पादन में लग जाते हैं।

आज की IaC सुरक्षा टूलिंग वास्तविक मुद्दों को उजागर कर रही है जिन्हें संबोधित करने की आवश्यकता है। इन उपकरणों का आउटपुट लेना और कोड के लिए जिम्मेदार टीम के लिए विशिष्ट अतिरिक्त संदर्भ के साथ इसे समृद्ध करना कुछ कस्टम ऑटोमेशन के लिए एक सही अवसर है।

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

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

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

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

लेखक के बारे में

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