विश्वास का भ्रम: कैसे हमारे मल्टी-टेनेंट डॉकर सेटअप ने डेटा लीक किया (और हमने इसे कैसे ठीक किया)

सारांश

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

घटना: जब कंटेनर बहुत अधिक बात करते हैं

आपने एक ही होस्ट पर कई क्लाइंट वेबसाइट चलाने के लिए डॉकर सेट अप किया है। प्रत्येक क्लाइंट का अपना कंटेनर है—एक साफ-सुथरा, अलग वातावरण, है ना? हमने भी यही सोचा था। जब तक एक नियमित सुरक्षा ऑडिट से पता नहीं चला कि क्लाइंट A का कंटेनर उसी होस्ट पर क्लाइंट B के कंटेनर के MySQL सॉकेट को पढ़ रहा था। उन्होंने डिफ़ॉल्ट bridge नेटवर्क साझा किया था। बदतर, कंटेनर रूट के रूप में चल रहे थे, इसलिए एक हमलावर जो एक को समझौता कर लेता, वह होस्ट के डॉकर सॉकेट या दूसरे कंटेनर के फ़ाइलसिस्टम से छेड़छाड़ कर सकता था। उल्लंघन कोई जटिल शोषण नहीं था; यह बुनियादी गलत कॉन्फ़िगरेशन था। डेटा लीक हुआ। विश्वास टूट गया।

विफलता का परिदृश्य असामान्य नहीं है। कई टीमें मानती हैं कि डॉकर के नेमस्पेस और cgroups स्वचालित रूप से टेनेंट को अलग कर देते हैं, लेकिन वे कम आंकते हैं कि डिफ़ॉल्ट रूप से कितने एस्केप हैच खुले रहते हैं। डिफ़ॉल्ट ब्रिज नेटवर्क कंटेनरों के बीच कोई नेटवर्क अलगाव प्रदान नहीं करते। रूट के रूप में चलने से कंटेनर को आवश्यकता से अधिक शक्ति मिलती है। और स्पष्ट संसाधन सीमाओं के बिना, एक शोरगुल वाला पड़ोसी दूसरों को CPU या मेमोरी से वंचित कर सकता है।

चरण 1: एकल नेटवर्क साझा करना बंद करें

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

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

नेटवर्क अलगाव रणनीतियों में गहराई से जाने के लिए, देखें मल्टी-टेनेंट होस्टिंग के लिए एक व्यावहारिक डॉकर आइसोलेशन सुरक्षा चेकलिस्ट।

चरण 2: अनावश्यक विशेषाधिकार हटाएँ

डिफ़ॉल्ट रूप से, डॉकर कंटेनर लिनक्स क्षमताओं के एक सीमित सेट के साथ चलते हैं, लेकिन उनके पास अभी भी अधिकांश अनुप्रयोगों की आवश्यकता से अधिक होती है। हमारे कंटेनर रूट के रूप में चलते थे, जो अंदर की प्रक्रियाओं को फ़ाइलसिस्टम माउंट करने या कर्नेल पैरामीटर बदलने जैसे कार्य करने की अनुमति देता था। हमने एप्लिकेशन को कंटेनर के अंदर एक गैर-रूट उपयोगकर्ता के रूप में चलाने के लिए स्विच किया (डॉकरफ़ाइल में USER निर्देश का उपयोग करके) और बिल्कुल आवश्यक को छोड़कर सभी क्षमताओं को हटा दिया। एक सामान्य वेब ऐप के लिए, वह केवल NET_BIND_SERVICE (1024 से कम पोर्ट से बंधने के लिए) और CHOWN (निर्देशिकाओं में लिखने के लिए) हो सकता है। हमने विशेषाधिकार वृद्धि को रोकने के लिए --security-opt no-new-privileges भी जोड़ा।

इस एक कदम ने ही कई सामान्य कंटेनर एस्केप वेक्टर को समाप्त कर दिया। एक हमलावर जो वेब सर्वर से समझौता करता है, वह पैकेज स्थापित नहीं कर सकता, सिस्टम बाइनरी को संशोधित नहीं कर सकता, या होस्ट के डॉकर सॉकेट तक नहीं पहुँच सकता क्योंकि प्रक्रिया में CAP_SYS_ADMIN या CAP_DAC_OVERRIDE क्षमताओं का अभाव है।

चरण 3: फ़ाइलसिस्टम को लॉक डाउन करें

लेखन योग्य फ़ाइलसिस्टम एक सामान्य हमले की सतह हैं। हमने सभी कंटेनरों के लिए रूट फ़ाइलसिस्टम को केवल-पढ़ने योग्य (--read-only) बनाया, और फिर उन निर्देशिकाओं के लिए अस्थायी फ़ाइलसिस्टम (tmpfs) माउंट किया जिन्हें लिखने की पहुँच की आवश्यकता है, जैसे /tmp और एप्लिकेशन की कैश निर्देशिका। यह एक हमलावर को एप्लिकेशन कोड को संशोधित करने या दुर्भावनापूर्ण बाइनरी को बनाए रखने से रोकता है।

इसके अतिरिक्त, हमने डॉकर के --mount विकल्प का उपयोग केवल तभी किया जब बिल्कुल आवश्यक हो—और कभी भी उत्पादन कंटेनरों पर नहीं। सिद्धांत: यदि कंटेनर को किसी पथ पर लिखने की आवश्यकता नहीं है, तो उसे केवल-पढ़ने योग्य बनाएँ।

चरण 4: सेकॉम्प और अप्पआर्मर प्रोफ़ाइल लागू करें

डिफ़ॉल्ट सेकॉम्प प्रोफ़ाइल पहले से ही कई खतरनाक सिस्कॉल को ब्लॉक करती हैं, लेकिन हमने उन्हें और अनुकूलित करके केवल उन सिस्कॉल को व्हाइटलिस्ट किया जिनकी हमारे एप्लिकेशन को वास्तव में आवश्यकता है। यह एक समझौता है क्योंकि इसके लिए एप्लिकेशन की प्रोफाइलिंग की आवश्यकता होती है। एक सरल दृष्टिकोण डॉकर के डिफ़ॉल्ट सेकॉम्प प्रोफ़ाइल का उपयोग करना है और फिर यदि कड़े नियमों की आवश्यकता हो तो --security-opt seccomp=path/to/profile.json जोड़ना है। इसी तरह, अप्पआर्मर प्रोफ़ाइल कंटेनर प्रक्रियाओं को विशिष्ट फ़ाइल पथ और क्षमताओं तक सीमित कर सकती हैं। हमने अप्पआर्मर सक्षम किया और एक कस्टम प्रोफ़ाइल का उपयोग किया जिसने केवल एप्लिकेशन के डेटा निर्देशिकाओं तक पहुँच प्रतिबंधित की।

इन सख्तीकरण चरणों पर एक व्यापक मार्गदर्शिका के लिए, देखें मल्टी-टेनेंट होस्टिंग के लिए डॉकर कंटेनरों को सख्त करना: एक चरण-दर-चरण अलगाव मार्गदर्शिका।

विरोधी दृष्टिकोण: कभी-कभी आपको वीएम की आवश्यकता होती है

चाहे कितना भी सख्त किया जाए, कंटेनर होस्ट के कर्नेल को साझा करते हैं। एक कर्नेल भेद्यता एक बार में सभी अलगाव को तोड़ सकती है। यही कारण है कि कई सुरक्षा-सचेत प्लेटफ़ॉर्म हल्के वीएम के अंदर कंटेनर चलाते हैं—प्रत्येक टेनेंट को अपना स्वयं का कर्नेल मिलता है। इससे ओवरहेड बढ़ता है लेकिन एक हार्डवेयर-स्तरीय सीमा प्रदान करता है जो अकेले कंटेनर नहीं कर सकते। यदि आपके टेनेंट क्रेडिट कार्ड डेटा या स्वास्थ्य रिकॉर्ड संभालते हैं, तो एक हाइब्रिड दृष्टिकोण (वीएम के अंदर कंटेनर) सही विकल्प हो सकता है। यह न मानें कि कंटेनर अलगाव आपके खतरे के मॉडल के लिए पर्याप्त है; डेटा की संवेदनशीलता और नियामक आवश्यकताओं का मूल्यांकन करें।

अलगाव स्तरों की गहरी तुलना के लिए, पढ़ें मल्टी-टेनेंट डॉकर आर्किटेक्चर डिज़ाइन करना: सही अलगाव स्तर चुनना।

निष्कर्ष: अलगाव एक स्टैक है, स्विच नहीं

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