थोड़ी पृष्ठभूमि
हाईलाड ++ 2017 के एक व्याख्यान के बाद मैंने इस रिपोर्ट को देखा, "रिकॉर्डिंग में हमने एडमिन को कैसे निकाल दिया"। स्पीकर ने कहा कि सभी वेब कंपनियों को पासवर्ड की समस्या है, और मुझे इस बात का अंदाजा था कि इसे कैसे हल किया जाए। सबसे अधिक संभावना है कि किसी ने इसे पहले ही कर लिया है, लेकिन ईमानदार होने के लिए, मुझे पता नहीं है, मैं सिर्फ इसका वर्णन करना चाहता हूं, फिर शायद कोई ऐसा करेगा या मैं किसी तरह इसे खुद करूंगा। मुझे उम्मीद है कि अगर कोई इस तरह से कुछ करने का फैसला करता है तो यह ओपनसोर्स होगा।
वास्तव में समस्या का वर्णन और इसे कैसे हल किया जाए
समस्या क्या है, हालांकि यह अजीब है कि यह पासवर्ड में ही है, या बल्कि, ताकि बेईमान कर्मचारी उन्हें कंपनी से दूर न करें।
इस समस्या को हल करने के लिए दो विकल्प हैं।
- साइट के सभी परिवर्तनों को कंपनी के प्रमुख को व्यक्तिगत रूप से पोस्ट करें।
- आविष्कार करना और कुछ करना।
सामान्य तौर पर, हम दूसरे विकल्प पर कार्य करते हैं। पहला मुश्किल और महंगा है अगर कंपनी में कम संख्या में लोग होते हैं।
क्या करना है, यह अब आपको तय करना है कि इसे कैसे करना है।
यहाँ एक बार सबसे सरल विचार, क्यों नहीं एक छद्म बना? खैर, सबसे अधिक संभावना एक सुपर प्रॉक्सी। कार्य योजना मूल रूप से सरल है और मैंने इसे नीचे आकर्षित किया है।
चित्र 1 - प्रणाली की सामान्य योजनाजैसा कि आरेख और विचार से ही देखा जा सकता है, यहां मुख्य तत्व एक प्रॉक्सी सर्वर होगा।
उनके कार्य इस प्रकार हैं:
- शुरुआत में, ट्रैफ़िक को स्वीकार करें, या यहां तक कि शुरुआत के लिए एसएसएच और एसएफटीपी कमांड के स्तर पर काम करें, और क्लाइंट सर्वर से किसी विशेषज्ञ को प्रतिक्रिया भेजें।
- किसी विशेषज्ञ का प्रमाणीकरण और प्राधिकरण
- टीमों की वैधता की जाँच, यह बाद में किया जा सकता है।
प्रॉक्सी सर्वर की संरचना स्वयं इस प्रकार होगी:
चित्रा 2 - सुपर प्रॉक्सी घटक के ब्लॉक आरेखप्रॉक्सी - SSH, (S) FTP, HTTP, HTTPS पर सीधे प्रॉक्सी ट्रैफ़िक
CA (कंट्रोल एक्सेस) - क्लाइंट संसाधनों के लिए विशेषज्ञ एक्सेस को नियंत्रित करता है।
SAP (सेवेर एडमिन पैनल) - सीधे सर्वर जो कंट्रोलर पैनल के माध्यम से प्रशासक से संवाद करता है।
कोर - सिस्टम का मूल स्वयं मॉड्यूल और मॉडल प्रबंधन के बीच अनुरोधों का प्रबंधन कर रहा है।मेरा मानना है कि पहुंच को अलग से संबोधित किया जाना चाहिए, क्योंकि सब कुछ इस वजह से शुरू किया गया था।
सभी उपयोगकर्ता समूह नीतियों में शामिल हैं, समूह नीतियाँ क्लाइंट सर्वर तक पहुँच के लिए नियमों को परिभाषित करती हैं, साथ ही साथ नियम जो कि व्यवस्थापकों का पालन करते हैं। समूह नीतियों में एक पदानुक्रमित संरचना होती है, प्रत्येक ऊपरी स्तर की अपनी समान शक्तियाँ होती हैं जो निचले स्तर की होती हैं। शुरू से ही एक नीति है '।', इसमें हर चीज के लिए सभी अनुमतियां शामिल हैं और इसमें एक उपयोगकर्ता, मुख्य व्यवस्थापक शामिल हो सकते हैं। फिर नीतियों, सिस्टम प्रशासकों और परियोजनाओं के लिए दो समूह हैं।
पिवट टेबल - प्रशासक और उनके अधिकार| भूमिका शीर्षक | पहुँच अधिकार | |
|---|
| समूह नीति प्रशासक | समूह उपयोगकर्ता संपादन | |
| समूह नीति प्रशासक | समूह नीति बनाएँ | समूह नीति में उपयोगकर्ता हटाना और संपादन करना |
| उपयोगकर्ता प्रबंधन व्यवस्थापक | उपयोगकर्ता को समूह नीति से निकालना | उपयोगकर्ता बनाएँ और संपादित करें |
| बैकअप व्यवस्थापक | उपयोगकर्ताओं और प्रशासकों के बारे में जानकारी पढ़ना | पढ़ना समूह नीति प्रविष्टियां |
| मुख्य प्रशासक | बाकी सब कुछ, साथ ही समूह नीतियों को संपादित करना और हटाना | क्लाइंट सर्वर पर बल पासवर्ड बदलता है |
समूह नीतियों में स्वयं एक सर्वर रिकॉर्ड होता है जिससे यह नीति लागू होती है।
और उपयोगकर्ताओं के पास निम्नलिखित नियम होते हैं, जो प्रत्येक उपयोगकर्ता या समूह के लिए अलग-अलग निर्धारित होते हैं, वास्तव में, ये बूलियन मूल्य हैं जो यह निर्धारित करते हैं कि ऑब्जेक्ट के पास संसाधन नियंत्रण कक्ष (व्यवस्थापक पैनल), एसएफटीपी / एफ़टीपी, एसएसएच एक्सेस तक HTTP / HTTPS का उपयोग है या नहीं।
अब कंट्रोल पैनल और क्लाइंट के बारे में कुछ शब्द।
नियंत्रण कक्ष या सब कुछ स्पष्ट है, लेकिन आपको फिर से लिखना होगा, यह स्पष्ट होगा।
नियंत्रण कक्ष समूह नीतियों और सर्वर को संपूर्ण रूप से प्रबंधित करने के लिए प्रत्यक्ष रूप से आवश्यक है, एक सुपर प्रॉक्सी। एक स्वसंपूर्ण अनुप्रयोग या वेब सेवा के रूप में वितरित किया गया।
तदनुसार, प्रशासकों की पहुंच नियंत्रण कक्ष तक है।
ग्राहक दिखने में सरल है, अंदर जटिल है।
क्लाइंट को एक आवेदन की जरूरत है, HTTP (एस) के मामले में, विशुद्ध रूप से सैद्धांतिक रूप से, यह एप्लिकेशन प्रॉक्सी सर्वर के माध्यम से काम करने के लिए सीधे कॉन्फ़िगर किया गया ब्राउज़र हो सकता है, और हमारे प्रॉक्सी सर्वर को ट्रैफ़िक में खुद को जागृत करना होगा। सामान्य तौर पर, सबसे अधिक संभावना है, हमारे सुपर-प्रॉक्सी सर्वर के माध्यम से ग्राहक सर्वर के साथ एसएसएच, (एस) एफ़टीपी, एचटीटीपी (एस) के माध्यम से काम करने वाले एक अलग एप्लिकेशन को विकसित करना आवश्यक होगा, या वास्तव में स्थापित करना और संचार करना भी आसान होगा क्लाइंट का सर्वर स्वयं एक सुपर-प्रॉक्सी सर्वर है, और कंप्यूटर में स्थापित क्लाइंट में, पूरी प्रक्रिया को केवल विशेषज्ञों द्वारा अनुकरण किया जाएगा।
HTTP (एस) के उदाहरण पर विचार करें।
- क्लाइंट क्लाइंट के साथ संचार के लिए एक अनुरोध प्रॉक्सी सर्वर को भेजता है।
- सुपर प्रॉक्सी सर्वर इसे अनुमति देता है या नहीं, अगर यह इसकी अनुमति देता है, तो सुपर प्रॉक्सी सर्वर स्वयं नियंत्रण पैनल को उठाता है और लॉग करता है।
- सुपर प्रॉक्सी सर्वर सीधे व्यवस्थापक पैनल के मुख्य पृष्ठ को प्राप्त करता है।
- सुपर प्रॉक्सी सर्वर क्लाइंट को एक विशेष मार्कर के साथ संसाधन के पते की जगह, इस पेज को भेजता है।
- विशेषज्ञ ब्राउज़र में फ़ील्ड में लिंक का अनुसरण करता है या भरता है और फ़ॉर्म को सबमिट करता है। डेटा एक सुपर प्रॉक्सी सर्वर पर जाता है।
- सुपर प्रॉक्सी सर्वर क्लाइंट संसाधन के पते पर टोकन को फिर से बदल देता है और तदनुसार, इसे सीधे क्लाइंट संसाधन को भेजता है।
एसएसएच पर काम के साथ, आप शुद्ध पाठ स्थानांतरित कर सकते हैं। और सीधे सुपर-प्रॉक्सी सर्वर से क्लाइंट संसाधन तक, एक सामान्य एसएसएच कनेक्शन बढ़ जाता है।
कुछ इस तरह। मैं टिप्पणियों में आपकी प्रतिक्रिया के लिए तत्पर हूं, और रिपॉजिटरी से लिंक करता हूं, अगर कोई ऐसी प्रणाली बनाने का फैसला करता है।