Architecture-center: क्या हम जंप बॉक्स को हटा सकते हैं?

रिपोर्ट करने के लिए धन्यवाद - इस मुद्दे की समीक्षा की जा रही है। यह एक Microsoft आंतरिक DevOps बग आईडी है AB#210868

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

@ckittel स्पष्टीकरण प्रदान करने के लिए धन्यवाद।

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

मुझे समझ नहीं आ रहा है। जब समस्या का समाधान नहीं होगा तो हम उसे बंद क्यों करेंगे।

@ बगिरा-केआर चाड पहले ही स्पष्टीकरण दे चुके हैं। क्या आप कुछ और ढूंढ रहे हैं?

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

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

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

जबकि मैं निश्चित रूप से एमएसएफटी एज़ूर समग्र सेवा पेशकश का उपयोग करने की इच्छा को समझ सकता हूं, वहां अधिक सामान्य दृष्टिकोण हैं जो सर्वोत्तम प्रथाओं के रूप में कार्य कर सकते हैं। क्या हम उस दस्तावेज़ के उपभोक्ताओं को सुरक्षित रूप से ग्रहण किए गए प्रभाव के कारण वास्तुशिल्प दस्तावेज़ लिखते समय "सामान्य प्रथम" दृष्टिकोण का पता लगा सकते हैं?

(दोहराए गए संपादन के लिए खेद है - आज अंग्रेजी में कठिन है)

बगिरा-क्र के साथ 100% सहमत हैं। मैं इसे पहली बार देख रहा एक सुरक्षा व्यक्ति हूं, इस बात से गहरा संबंध है कि हम नए उपयोगकर्ताओं को उन चीजों को करने का एक तरीका सिखा रहे हैं जो 1990 के दशक से संबंधित हैं। यह इस विचार को प्रख्यापित करता है कि MSFT और Azure या तो स्वभाव से असुरक्षित हैं या सुरक्षा से असंबद्ध हैं।

एक आवश्यक परिवर्तन किए बिना मुद्दे को बंद करना यहां एक बहुत ही वास्तविक समस्या को ठीक करने के लिए कुछ भी नहीं करता है। सुझाव है कि आप किसी सुरक्षा दल से संसाधन प्राप्त करें और उसके अनुसार अपने दस्तावेज़ों को अपडेट करें।