क्या सभी सर्वरों को HTTPS प्रोटोकॉल या सिर्फ पब्लिक फेसिंग सर्वर का उपयोग करने की आवश्यकता है?

Question

मेरे पास HTTPS पर चलने वाला फ्रंट एंड वेब सर्वर है - यह पब्लिक फेसिंग है - यानी पोर्ट ओपन है।

मेरे पास एक बैकएंड एपीआई सर्वर भी है जिसे मेरा वेबसर्वर एपीआई अनुरोध करता है - यह सार्वजनिक सामना करना पड़ रहा है और प्रमाणीकरण की आवश्यकता है - पोर्ट खुला है।

ये 2 सर्वर HTTPS पर चलते हैं।

एपीआई सर्वर के पीछे, अन्य सर्वर के बहुत सारे हैं। एपीआई सर्वर इन सर्वरों के विपरीत होता है। इन अन्य सर्वरों के लिए पोर्ट आने वाले ट्रैफ़िक के लिए खुले नहीं हैं। उनसे केवल एपीआई सर्वर के जरिए बात की जा सकती है।

मेरा प्रश्न ... क्या "बहुत सारे अन्य सर्वर" को एचटीटीपीएस से अधिक चलाने की आवश्यकता है या यह देखते हुए कि उन्हें बाहरी रूप से एक्सेस नहीं किया जा सकता है, क्या वे इसके बजाय HTTP पर सुरक्षित रूप से चल सकते हैं?

मुझे लगा कि यह एक सामान्य प्रश्न होगा लेकिन मुझे इसका उत्तर नहीं मिल रहा है। धन्यवाद। यदि यह एक द्वैध है, तो कृपया मुझे सही उत्तर दें।

Comments

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

— बच्चे को

यह ssl offloading और ssl समाप्ति के रूप में जाना जाता है अगर आप आगे अनुसंधान करना चाहते हैं।

— एबेन स्कोव पेडर्सन

यह पूछने की तरह है कि "क्या सभी दरवाजों को ताले की जरूरत है, या सिर्फ बाहर का सामना करना पड़ रहा है"? केवल आपके नेटवर्क के भीतर और बिना खतरों पर विचार करते हुए आप इस प्रश्न का उत्तर दे सकते हैं।

— रयान ग्रिग्स

जैसा कि Security.SE faq कहता है : "सुरक्षा एक बहुत ही प्रासंगिक विषय है: आपके वातावरण में महत्वपूर्ण माने जाने वाले खतरे किसी और के और इसके विपरीत में असंगत हो सकते हैं। क्या आप उन्नत स्थायी खतरों के खिलाफ वैश्विक मूल्य के कुछ की रक्षा करने की कोशिश कर रहे हैं? या?" क्या आप कम-प्रोफ़ाइल वाले छोटे व्यवसाय के लिए एक लागत-प्रभावी दृष्टिकोण की तलाश कर रहे हैं? सबसे उपयोगी उत्तर प्राप्त करने के लिए आपको हमें बताना चाहिए: आप किन संपत्तियों की रक्षा करने की कोशिश कर रहे हैं; जो संपत्ति आप उपयोग करने की कोशिश कर रहे हैं, और आप कौन हैं लगता है कि यह दुरुपयोग करना चाहते हो सकता है (और क्यों)? ...

— DW

उस परिसंपत्ति की सुरक्षा के लिए आपने क्या कदम उठाए हैं; आपको क्या जोखिम लगता है कि आपको अभी भी शमन करने की आवश्यकता है। "इस तरह का संदर्भ आवश्यक है। मेरा सुझाव है कि आप इस जानकारी को शामिल करने के लिए अपने प्रश्न को संपादित करें।

— DW

Answer 1

यह एक राय का विषय है, और नियामक मुद्दों (यदि आप किसी का सामना करते हैं) के साथ भी करना है।

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

जो मैं आमतौर पर सुझाता हूं वह एक आंतरिक सीए (यदि उपलब्ध हो) या स्व चिह्न (यदि कोई आंतरिक सीए नहीं है) बैक एंड सर्वर का उपयोग कर रहा है। हम अनावश्यक परिवर्तनों से बचने के लिए भविष्य में समाप्ति की तिथि को अच्छा और दूर निर्धारित करेंगे।

Comments

वहाँ शुरू करना बेहतर है - जिन शब्दों ने आपको अंक दिए हैं :)

— danday74

यह एक अच्छा विचार है। आप एनएसए को अपने नेटवर्क टोपोलॉजी के नासमझ चित्र बनाना नहीं चाहते हैं ।

— केविन

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

— डॉकटोर जे

" We'd set the expiration date nice and far into the future to avoid unnecessary changes." और चेतावनी देने के लिए जब यह समय सीमा समाप्त होने के बारे में है अपनी पसंद की निगरानी सुइट के लिए एक नियम जोड़ें। कृप्या!

— GnP

@GnP मैं ऐसा ही करता हूं - यदि यह 10 साल की अवधि के साथ प्रमाणित होता है, तो हमारी नीति हमेशा बैकेंड सर्वर को उस अवधि के भीतर प्रतिस्थापित करती है .. इसे थोड़ा अनावश्यक बनाता है और उत्तर में उल्लेख करना आवश्यक नहीं लगता है।

— टिम ब्रिघम

Answer 2

TL; DR आपको ट्रैफ़िक को एन्क्रिप्ट करना चाहिए जब तक कि यह एक ही होस्ट पर न हो।

आप अपने नेटवर्क पर भरोसा नहीं कर सकते। आपके स्वयं के नेटवर्क के Malwares http अनुरोधों को रोक / संशोधित कर सकते हैं।

यह सैद्धांतिक हमले नहीं हैं, लेकिन वास्तविक जीवन उदाहरण हैं:

• विज्ञापन देने वाले कुछ वेबसाइटों के नेटवर्क के अंदर राउटर (संभवतः हैक किए गए): https://www.blackhat.com/docs/us-16/materials/us-16-Nakibly-TCP-Injection-Attacks-in-the-Wild- ए-बड़े पैमाने पर-अध्ययन-wp.pdf

• बादल और बैक-एंड के बीच भारतीय नेटवर्क सूँघ रहा है: https://medium.com/@karthikb351/airtel-is-sniffing-and-censoring-cloudflares-traffic-in-india-and-y-don-t-even-know -यह-90935f7f6d98 # .hymc3785e

• अब एनएसए से प्रसिद्ध "एसएसएल गयी और हटा दी गयी :-)"

Answer 3

क्या "बहुत सारे अन्य सर्वर" को एचटीटीपीएस से अधिक चलाने की आवश्यकता है या, यह देखते हुए कि उन्हें बाहरी रूप से एक्सेस नहीं किया जा सकता है, क्या वे इसके बजाय HTTP पर सुरक्षित रूप से चल सकते हैं?

यह वास्तव में उस पर निर्भर करता है जिसे आप पूरा करने की कोशिश कर रहे हैं। HTTPS का उपयोग करने का उद्देश्य दो बिंदुओं के बीच पारगमन में डेटा की सुरक्षा करना है। यदि आप अपने नेटवर्क के अंदर डेटा को सूँघने के बारे में चिंतित हैं तो शायद पहले इस बात का ध्यान रखा जाना चाहिए। यदि आपको अपने नेटवर्क के अंदर ट्रांज़िट में डेटा को सुरक्षित रखने की आवश्यकता है जो आप कह रहे हैं कि आपको या तो अपने नेटवर्क के अंदर अपने सिस्टम को ट्रैवर्स करने वाले डेटा की सुरक्षा के बारे में चिंता है या आपके द्वारा ट्रांज़िट में डेटा को एन्क्रिप्ट करने के लिए कुछ अनुपालन संबंधी कारण हैं।

यह वास्तव में एक राय प्रश्न का अधिक है, लेकिन इसका उत्तर यह निर्भर करता है। तुम क्या करने की कोशिश कर रहे हो? आप किस प्रकार का डेटा एन्क्रिप्ट कर रहे हैं? आप किन खतरों से बचाव करने की कोशिश कर रहे हैं? क्या आपके पास कानूनी आवश्यकता है (उदाहरण के लिए PCI-DSS, HIPAA, आदि) जो आपको ट्रांजिट में डेटा एन्क्रिप्ट करने की आवश्यकता है? यदि डेटा संवेदनशील है और आप चिंतित हैं कि इसका दुरुपयोग तब हो सकता है जब इसे आपके नेटवर्क के अंदर प्रसारित किया जा रहा है तो मैं सुझाव दूंगा कि प्रबंधन के साथ मिलकर समस्या को ठीक किया जाए। तो अंत में, आप क्या रक्षा करने की कोशिश कर रहे हैं और आप इसे बचाने की कोशिश क्यों कर रहे हैं?

Answer 4

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

आंतरिक नेटवर्क को अब सुरक्षित नहीं माना जाता है, भले ही आपके पास अपने नेटवर्क पर छात्र लैपटॉप न हो। कुछ उदाहरणों के लिए टॉम का जवाब देखें।

उस ने कहा, हां, यह इस बात पर निर्भर करता है कि कौन सी जानकारी प्रेषित की जा रही है, कोई कानूनी अनुपालन मुद्दे आदि, आप यह तय कर सकते हैं कि अगर किसी को सूँघने, कहने, मौसम के आंकड़ों की परवाह नहीं है। जैसा कि कहा गया है, यह संभव है कि भले ही डेटा भेजा संवेदनशील नहीं है अब , किसी को बाद में अपने आवेदन करने के लिए सुविधाओं को जोड़ने के लिए है कि तय कर सकते हैं , संवेदनशील तो मैं (HTTPS सहित) अधिक से अधिक व्यामोह की सिफारिश करेंगे।

Comments

व्‍हाइट डेटा काफी संवेदनशील हो सकता है: कोई छेड़छाड़ वाले व्‍हाइट डेटा पर अपने गलत फैसलों को आधार बना सकता है।

— हेगन वॉन एटिजन

पर्याप्त रूप से, यह इस बात पर निर्भर करता है कि आप मौसम के आंकड़ों का क्या उपयोग कर रहे हैं। मैं कुछ सहज के साथ आने की कोशिश कर रहा था। :)

— कैथरीन विलिअर्ड

@HagenvonEitzen या हमलावर वहाँ मैलवेयर / विज्ञापनों को इंजेक्ट करेगा, इसलिए जब वह अपनी Windows XP मशीन का उपयोग करके मौसम की जाँच करता है, तो दादी हैरान हो जाती है।

— एंड्रे बोरी

Answer 5

एन्क्रिप्शन को गति देने के लिए विशेष सीपीयू निर्देशों के साथ, और नए परिवहन प्रोटोकॉल जो बिल्कुल भी संचालित नहीं होंगे या एक अनएन्क्रिप्टेड लिंक (HTTP / 2, gRPC, आदि ...) पर अपमानित प्रदर्शन के साथ काम करेंगे, शायद बेहतर सवाल यह है: क्या कोई है कारण आपको HTTP से नेटवर्क लिंक डाउनग्रेड करने की आवश्यकता क्यों है? यदि कोई विशिष्ट कारण नहीं है, तो इसका उत्तर HTTPS के पास है।

Comments

अच्छी विचार प्रक्रिया

— danday74

Answer 6

एन्क्रिप्शन को अक्षम करने का एकमात्र कारण जो मैं सोच सकता हूं वह है प्रदर्शन। हालाँकि, आपके मामले में आंतरिक सर्वरों को HTTP के माध्यम से बाधित किया जाता है, जिसका अर्थ है कि वे पहले से ही वेब सर्वर चलाने, HTTP प्रोटोकॉल का समर्थन करने और HTTP / JSON / जो भी हो, में डेटा को एन्कोड करने की प्रदर्शन लागत वहन करते हैं। एन्क्रिप्शन को अक्षम करने से संभवत: 100KB RAM मुफ्त हो जाएगा और आपको प्रति संचारित KB के कुछ माइक्रोसेकंड अर्जित होंगे, जिसका समग्र प्रदर्शन पर कोई प्रभाव नहीं दिखाई देगा। दूसरी ओर, आपको अपने इंट्रानेट में HTTP चलाने के बाद से सुरक्षा पर अधिक ध्यान देना होगा। वास्तव में, यह संभव है कि अधिक सख्त फ़ायरवॉल कॉन्फ़िगरेशन चीजों को धीमा कर देगा एन्क्रिप्शन को अक्षम करने की तुलना में अधिक उन्हें गति दी है, जिसके परिणामस्वरूप अंतिम उपयोगकर्ताओं द्वारा खराब प्रदर्शन माना जाता है।

यह एक ट्रैक्टर पर स्पॉइलर लगाने जैसा होगा: आप सैद्धांतिक रूप से कुछ भी नहीं के बगल में प्राप्त करते हैं, और व्यावहारिक रूप से बहुत असुविधा होती है।