विचारधारा और विकासशील वित्तीय प्रणालियों की समस्याएं। भाग 1

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



मतभेदों का एक उदाहरण पारंपरिक प्रणालियों का निर्माण है जो वर्तमान सूचना और वित्तीय प्रणालियों पर ध्यान केंद्रित करते हैं।



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





इसके बाद, मैं उन कठिनाइयों के बारे में बात करना चाहूंगा जो हमारी टीम ने सामना की हैं। शायद अगर कुछ साल पहले मैं इस तरह की सामग्री के साथ आया था, तो हमने बहुत सारी समस्याओं से बचा लिया होगा (और लेना जारी रखेंगे)। यहां तक ​​कि एक साधारण उल्लेख भी मेरे लिए पर्याप्त होगा कि इस तरह और इस तरह की समस्या उत्पन्न हो सकती है। अब मैं खुद इनमें से कई के बारे में बात करने के लिए तैयार हूं। इसके अलावा, हम उन समाधानों की रूपरेखा तैयार करने की कोशिश करेंगे, जिन पर हमने चर्चा की और जिन्हें हमने अंततः अपनाया। तो चलिए शुरू करते हैं।



प्राधिकरण एल्गोरिथ्म और डिजाइन मंच पर पहुंच अधिकार प्रणाली की वास्तुकला योजना



जाहिर है, व्यापार प्रक्रिया के कार्यान्वयन से जुड़ी सभी बारीकियों, कभी भी ध्यान में नहीं रखती हैं, लेकिन यह उनके बारे में सोचने योग्य है।

1. डेटाबेस से कनेक्शन।

सबसे सरल और सबसे सरल पथ, जिसे चुनने के लिए फॉर्म का डिज़ाइन बनाना होता है:



DB_Class_Class_Copy उदाहरण। कनेक्शन विधि (उपयोगकर्ता नाम, पासवर्ड)



उपयोगकर्ता नाम और पासवर्ड वह डेटा है, जो ग्राहक को शुरू करने के दौरान उपयोगकर्ता द्वारा दर्ज किया जाता है।



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



एक हमलावर जो उपयोगकर्ता की मशीन तक पहुंच प्राप्त कर सकता है, वह क्या कर सकता है? वह एक साधारण काम कर सकते हैं - मीडिया पर एक मेमोरी डंप फेंक दें और शांत वातावरण में उपयोगकर्ता नाम और पासवर्ड को फाड़ दें।



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



अब हम समस्या को हल करते हैं: कैसे सत्यापित करें कि उपयोगकर्ता उपयोगकर्ता है और उसका कंप्यूटर उसका कंप्यूटर है?



मानक MS SQL उपकरण (उदाहरण के लिए) इस समस्या को हल नहीं कर सकता। इसके अलावा, इसे छोड़ दिया जाना चाहिए (कम से कम डोमेन प्राधिकरण के कारण, जो सबसे पहले, उपरोक्त उदाहरण में पूरी सुरक्षा नीति को मारता है, और दूसरी बात, कोई लचीलापन नहीं देता है, जिसकी चर्चा बाद में की जाएगी)।



यह ध्यान देने योग्य है कि कई प्रणालियों के एकीकरण के लिए यह डेटाबेस नीतियों के अलावा किसी भी चीज़ का उपयोग करने के लिए काम नहीं करेगा (या विभिन्न कार्यक्रमों के बीच काम करने के लिए एक परत लिखें, लेकिन इसमें बहुत समय लगेगा)। इसलिए हमें शुरू में अलग-अलग डेटा की कोशिश करनी चाहिए जो संभवतः अन्य सिस्टम और डेटा में बदल जाएंगे जिन्हें केवल हमारे सिस्टम में संपादित करने की अनुमति है। उसी समय, उन्हें केवल तालिकाओं द्वारा अलग नहीं किया जाना चाहिए, लेकिन अलग-अलग डेटाबेस में ले जाया गया। लेकिन मैं अगली बार इस बारे में लिखने की कोशिश करूंगा।



तो, प्राधिकरण।



सबसे सरल (जिसमें अधिक समय नहीं लगा) और जो प्रभावी हमारे साथ आया वह निम्न योजना है:



उपयोगकर्ता और उपयोगकर्ता नाम और पासवर्ड दर्ज करता है

स्थानीय मशीन के हार्डवेयर के बारे में सभी संभव डेटा का उपयोग करते हुए, पासवर्ड एक मुश्किल एल्गोरिथ्म का उपयोग करके परिवर्तित किया जाता है

o उपयोगकर्ता नाम और प्राप्त पासवर्ड के साथ एक कनेक्शन बनाया गया है।



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

बेशक, हम समझते हैं कि कोई अभेद्य प्रणाली नहीं हैं, लेकिन हमारी चालाक एल्गोरिथ्म उन लोगों को बना देगा जो कोड पसीने को हटाने की कोशिश करते हैं, और इसलिए हमें समय देते हैं।

लेकिन सबसे महत्वपूर्ण बात: यहां तक ​​कि उपयोगकर्ता के पासवर्ड को जानने और कंप्यूटर तक पहुंच होने के बावजूद, यह वास्तव में डरावना कुछ हासिल करना संभव नहीं होगा: पहुंच अधिकार नीति इसे रोक देगी।

2. पहुँच नीति

हम उन उपकरणों के बीच एक लंबे समय से एक मध्यम जमीन की तलाश कर रहे हैं जो डेटाबेस (MS SQL) हमें प्रदान करता है और जो हम निर्माण करते हैं। अंत में, यह असमान रूप से तय किया गया था कि डेटाबेस द्वारा प्रदान की गई ग्रैन्युलैरिटी (प्रत्येक तालिका, प्रस्तुति और भंडारण के लिए व्यक्तिगत अधिकार) पर्याप्त नहीं है - व्यवसाय प्रक्रिया का पूरा तर्क बहुत अधिक जटिल है।

अंत में, हमने ग्राहक अनुप्रयोगों से निम्नलिखित दो-स्तरीय सुरक्षा प्रणाली योजना लागू की:



o अनुप्रयोग शुरू करते समय, डेटाबेस कनेक्शन स्वचालित रूप से बनाया जाता है

o उपयोगकर्ता एक उपयोगकर्ता नाम, पासवर्ड दर्ज करता है, जो उस ऑपरेशन के कोड के साथ एन्क्रिप्टेड रूप में सर्वर को प्रेषित होता है जिसे उपयोगकर्ता प्रदर्शन करना चाहता है (इस मामले में, कनेक्शन)

ओ आगे, अधिकारों की खुद की प्रणाली एक परिणाम देती है जो इस कार्रवाई की वैधता को इंगित करती है (परिणाम कोड प्राप्त करने के बाद, कार्यक्रम "समझता है" डेटा अगले डेटा अनुरोध में इसे वापस कर दिया जाएगा)।



इसके अलावा, इस योजना का उपयोग हर जगह किया जाता है, जो आपको व्यापार प्रक्रिया को पूरी तरह से स्थानांतरित करने की अनुमति देता है, सबसे परिष्कृत अधिकारों को ध्यान में रखता है।

इस प्रकार, डेटाबेस टूलकिट हमें डेटाबेस के साथ विभिन्न प्रणालियों के काम के संबंध में पैंतरेबाज़ी करने के लिए जगह देता है, और आवेदन और डेटाबेस स्तर पर विस्तृत तर्क निर्धारित किया जाता है: यदि उपयोगकर्ता फ़ंक्शन की वैधता की जांच करने वाला फ़ंक्शन विफलता कोड देता है, तो संग्रहीत प्रक्रिया कभी भी डेटा वापस नहीं करेगी।



परिणाम

परिणाम एक बल्कि थकाऊ और लंबा लेख था, लेकिन मुझे आशा है कि किसी के लिए यह उपयोगी होगा। यदि यह सब समान होता है, तो अगली बार मैं कई प्रणालियों के इंटरैक्शन की समस्या और तर्क के बारे में बात करना चाहूंगा।