एन्क्रिप्शन कुंजी और क्रेडेंशियल्स जैसे रहस्य को कुछ कारणों से स्रोत नियंत्रण में नहीं जांचना चाहिए। पहला स्पष्ट रूप से यह है कि एन्क्रिप्शन कुंजी और क्रेडेंशियल हमेशा आधार जानने की आवश्यकता पर होना चाहिए, और जानकारी को प्रकटीकरण से बचाने के लिए स्रोत नियंत्रण एक विश्वसनीय तरीका नहीं है। दूसरा कारण कि आप अपने स्रोत नियंत्रण में ऐसे रहस्यों को नहीं चाहते हैं, क्योंकि आम तौर पर रहस्य आमतौर पर (लेकिन हमेशा नहीं) विशिष्ट होते हैं जो आपके आवेदन में चलेंगे पर्यावरण के एक निश्चित गुण के लिए। (जैसे। डिजिटल बनाने के लिए एक निजी कुंजी प्राप्त करना। एक वेब सेवा प्राधिकरण के लिए आवश्यक हस्ताक्षर, उस वेब सेवा का विशिष्ट समापन बिंदु QA वातावरण में चल सकता है, जिसे QA हस्ताक्षर की आवश्यकता होती है)।
एक पर्यावरण (या वैश्विक रहस्य) का इलाज करने का सही तरीका यह है कि आप किसी भी अन्य पर्यावरणीय कॉन्फ़िगरेशन विशेषता की तरह इसका इलाज करें, अच्छे उपाय के लिए अतिरिक्त सुरक्षा नियंत्रण के साथ। एक अच्छी तरह से डिज़ाइन किया गया, स्वतंत्र और संस्करण योग्य कोड मॉड्यूल पूरे वातावरण में समान होना चाहिए, ताकि वे जिस वातावरण में तैनात हों, वह एप्लिकेशन को उसकी विशेषताओं (उदाहरण के लिए। डेटाबेस कनेक्शन विवरण, क्रेडेंशियल्स, वेब सेवा समापन बिंदु, फ़ाइल पथ, आदि ...) के बारे में बताए। आपके एप्लिकेशन के लिए महत्वपूर्ण कॉन्फ़िगरेशन विवरण बाहरी हो गए हैं और आपके वातावरण के कॉन्फ़िगरेशन पैरामीटर बन गए हैं।
अब आपके कुछ तर्कों को संबोधित करने के लिए:
सामान्य तौर पर, क्या हम सिर्फ समस्या नहीं बढ़ा रहे हैं?
सही सुरक्षा जैसी कोई चीज नहीं है, हालांकि समस्या को एक ऐसे क्षेत्र में "ले जाना" है जहां अतिरिक्त उपायों और नियंत्रणों को रखा जा सकता है, यह कठिनाई में सुधार करेगा और रहस्यों के आकस्मिक या दुर्भावनापूर्ण प्रकटीकरण की संभावना को कम करेगा। अंगूठे का एक अच्छा नियम एक प्रणाली को डिजाइन करते समय पालन करना है जहां गोपनीय डेटा को संरक्षित किया जाना चाहिए, हमेशा नियंत्रण को दोहों में रखना चाहिए। मेरे कहने का मतलब यह है कि यह सुनिश्चित करने के लिए कि गोपनीय जानकारी या सुरक्षा घटना के आकस्मिक या दुर्भावनापूर्ण प्रकटीकरण के लिए तब विफलता या दो या अधिक नियंत्रणों में होना होगा।
इसका एक अच्छा उदाहरण एक सर्वर पर एन्क्रिप्टेड फ़ाइल को संग्रहीत करना हो सकता है। मेरे पास एक गुप्त डिक्रिप्शन कुंजी भी है जिसे मुझे दूसरी फ़ाइल में गोपनीय रखना होगा।
- एक ही सर्वर में कुंजी और एन्क्रिप्ट की गई फ़ाइल को स्टोर करें (0 नियंत्रण, सर्वर तक पहुंच रखने वाला कोई भी व्यक्ति गोपनीय जानकारी प्राप्त कर सकता है)
- उपरोक्त चरणों का पालन करें और दोनों फ़ाइलों तक फ़ाइल पहुंच की रक्षा करें ताकि यह केवल OS के एप्लिकेशन रनटाइम उपयोगकर्ता द्वारा पढ़ा जा सके (1 नियंत्रण, रूट उपयोगकर्ता या एप्लिकेशन रनटाइम उपयोगकर्ता के पासवर्ड से समझौता करने से हमलावर को गोपनीय जानकारी प्राप्त करने की अनुमति मिलेगी)
- बाहरी कुंजी तिजोरी में स्टोर कुंजी, आईपी पते की सफेद लिस्टिंग, प्रमाणपत्र प्रमाणीकरण और आवेदन के अन्य उपायों जैसे कि अपने फाइल सिस्टम पर एन्क्रिप्टेड फ़ाइल तक पहुंच सकते हैं जैसे कई सुरक्षा उपायों के साथ कुंजी प्राप्त करें। (गोपनीय नियंत्रण के लिए, गोपनीय नियंत्रण के लिए एकाधिक नियंत्रण की कई विफलताएँ होनी चाहिए)
फिर, पूर्ण सुरक्षा जैसी कोई चीज नहीं है, लेकिन कई नियंत्रण होने का लक्ष्य यह सुनिश्चित करता है कि प्रकटीकरण होने के लिए कई विफलताएं होने की आवश्यकता है।
यह मुझे लगता है कि Azure KeyVault जैसे उत्पाद बेहतर नहीं हैं, और व्यर्थ में अधिक जटिल हैं,
जटिल हां, व्यर्थ पूरी तरह व्यक्तिपरक है। हम वास्तविक डेटा को उजागर किए बिना कितने गंभीर होंगे, इस पर वास्तविक रूप से ध्यान दिए बिना अतिरिक्त सुरक्षा की व्यर्थता के बारे में चर्चा नहीं की जा सकती है। यदि कोई आपके वित्तीय संस्थान से अवैध वायर ट्रांसफर भेजने के लिए गोपनीय डेटा का उपयोग कर सकता है, तो एक महत्वपूर्ण तिजोरी की तरह कुछ व्यर्थ बात से दूर के बारे में है।
एक अलग config फाइल में अपने रहस्यों को रखने और यह सुनिश्चित करने की तुलना में यह आपके .gitignore या समकक्ष में है।
जब तक कोई गलती से इसे स्रोत नियंत्रण में नहीं देखता है, अब रहस्य हमेशा के लिए स्रोत नियंत्रण इतिहास में अंतर्निहित है।
बेशक, लोग शायद असुरक्षित रूप से इसे एक-दूसरे को ईमेल करेंगे ...
सुरक्षा केवल एक तकनीकी समस्या नहीं है, यह लोगों का मुद्दा भी है। हालांकि यह विषय से हटकर होगा लेकिन मुझे लगता है कि इस बिंदु पर आप अपने आप को जरूरतमंदों से बात करने की कोशिश कर रहे हैं।
क्या रहस्य का प्रबंधन करने का एक तरीका है जो समस्या को हल नहीं करता है? मेरा मानना है कि इस प्रश्न का एक स्पष्ट रूप से परिभाषित उत्तर है। सादृश्य से, अगर मुझे पूछा गया कि HTTPS समस्या को कैसे हल नहीं करता है, तो इसका उत्तर यह होगा कि CA कुंजी आपके OS के साथ वितरित की जाती हैं, और हम उन पर भरोसा करते हैं क्योंकि हम OS की वितरण विधि पर भरोसा करते हैं।
सुरक्षा हमेशा समस्याओं को दूर नहीं करती है, जितना समय उनके आसपास नियंत्रण रखता है। आपका सादृश्य सुसाइड है क्योंकि यह वास्तव में सार्वजनिक-निजी कुंजी क्रिप्टोग्राफी करता है। हम सार्वजनिक प्रमाणपत्र के स्वामित्व वाली इकाई की पहचान के लिए अपने सीए में अशिक्षित और पूर्ण विश्वास रखकर सीए के लिए "समस्या को आगे बढ़ा रहे हैं"। मूल रूप से, विफलताओं (जैसे सीए में विश्वास खोना) की एक भयावह स्ट्रिंग से कम कुछ भी नहीं होना चाहिए, जिससे सुरक्षा मुद्दा बन सके।
कई चीजों के साथ, सुरक्षा एक ऐसी रेखा है जिसे आपको व्यक्तिपरक मानदंड, डेटा की प्रकृति, प्रकटीकरण के परिणामों, जोखिम की भूख, बजट, आदि के आधार पर खींचना है ...