Apache इग्नाइट में TDE: एक बड़े ओपन सोर्स प्रोजेक्ट में एक मेजर फीचर स्टोरी

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

अपाचे इग्नाइट का उपयोग बैंकों में किया जाता है, इसलिए, इसमें TDE को लागू करने का निर्णय लिया गया।

मैं अपाचेव प्रक्रियाओं के माध्यम से, सार्वजनिक रूप से, समुदाय के माध्यम से TDE को कैसे विकसित किया, इसका वर्णन करूँगा।


नीचे रिपोर्ट का एक पाठ संस्करण है:

मैं वास्तुकला के बारे में बात करने की कोशिश करूंगा, विकास की जटिलता के बारे में, यह वास्तव में खुले स्रोत में कैसे दिखता है।

क्या किया गया है और क्या किया जाना बाकी है?

वर्तमान में लागू अपाचे इग्नाइट टीडीई। चरण 1।

इसमें एन्क्रिप्टेड कैश के साथ काम करने की बुनियादी विशेषताएं शामिल हैं:

• प्रमुख प्रबंधन
• एन्क्रिप्टेड कैश बनाना
• एन्क्रिप्टेड रूप में डिस्क पर सभी कैश डेटा को सहेजना

चरण 2 में, मास्टर कुंजी के रोटेशन (परिवर्तन) की संभावना को सक्षम करने की योजना बनाई गई है।
चरण 3 में, कैश कुंजियों को घुमाने की क्षमता।

शब्दावली

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

आर्किटेक्चर

सब कुछ निम्नलिखित योजना के अनुसार लागू किया गया है:

• सभी कैश डेटा को नए एन्क्रिप्शन SPI का उपयोग करके एन्क्रिप्ट किया गया है।
• डिफ़ॉल्ट रूप से, एईएस का उपयोग किया जाता है - एक औद्योगिक एन्क्रिप्शन एल्गोरिथ्म।
• मास्टर कुंजी को JKS फ़ाइल में संग्रहीत किया जाता है - कुंजियों के लिए एक मानक जावा फ़ाइल।

बैंक और अन्य संगठन अपने स्वयं के एन्क्रिप्शन एल्गोरिदम का उपयोग करते हैं: GOST और अन्य। यह स्पष्ट है कि हमने अपने एन्क्रिप्शन SPI - एन्क्रिप्शन कार्यान्वयन को पर्ची करने का अवसर प्रदान किया है जो एक विशिष्ट उपयोगकर्ता की आवश्यकता है।

कार्य योजना

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

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

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

कार्यों की एल्गोरिथ्म निम्नानुसार है:

• नोड की शुरुआत में, मास्टर कुंजी को jks से घटाएं।
• नोड्स की शुरुआत में, मेटा स्टोर पढ़ें और कैश कीज को डिक्रिप्ट करें।
• जब एक क्लस्टर में नोड्स शामिल हों:
  - मास्टर कुंजी हैश को सत्यापित करें।
  - साझा किए गए कैश के लिए कुंजियों की जांच करें।
  - नए कैश के लिए कुंजियाँ सहेजें।
  
• गतिशील रूप से कैश बनाते समय, हम एक कुंजी बनाते हैं और इसे मेटा स्टोर में सहेजते हैं।
• किसी पृष्ठ को पढ़ते / लिखते समय हम उसे डिक्रिप्ट / एन्क्रिप्ट करते हैं।
• एन्क्रिप्टेड कैश के लिए प्रत्येक वाल प्रविष्टि भी एन्क्रिप्ट किया गया है।

अब और अधिक विस्तार में:

नोड की शुरुआत में, हमारे पास एक कॉलबैक है जो हमारे एन्क्रिप्शन एन्क्रिप्शन को लॉन्च करता है। मापदंडों के अनुसार, हम मास्टर कुंजी को jks फ़ाइल से घटाते हैं।

अगला, जब मेटास्टोर तैयार होता है, तो हमें संग्रहीत एन्क्रिप्शन कुंजियाँ मिलती हैं। इस मामले में, हमारे पास पहले से ही एक मास्टर कुंजी है, ताकि हम कुंजियों को डिक्रिप्ट कर सकें और कैश डेटा तक पहुंच प्राप्त कर सकें।

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

हम ये कार्य करते हैं:

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

दूसरा भाग I / O संचालन पर एक अधिरचना है। पृष्ठ विभाजन फ़ाइल में लिखे गए हैं। हमारा ऐड-इन किस पेज कैश पर दिखता है, उसी के अनुसार उन्हें एनक्रिप्ट करता है और उन्हें सेव करता है।

वही वाल के लिए चला जाता है। एक धारावाहिक है जो वाल रिकॉर्ड वस्तुओं को क्रमबद्ध करता है। और यदि रिकॉर्ड एन्क्रिप्टेड कैश के लिए है, तो हमें इसे एन्क्रिप्ट करना होगा और उसके बाद ही इसे डिस्क पर सहेजें।

विकास की कठिनाइयाँ

सभी अधिक या कम जटिल ओपन सोर्स प्रोजेक्ट्स के लिए आम मुश्किलें:

1. पहले आपको इग्नाइट डिवाइस को पूरी तरह से समझने की जरूरत है। क्यों, क्या, और यह वहाँ कैसे किया गया था, कैसे और किन स्थानों पर अपने हैंडलर संलग्न करने के लिए।
2. पिछड़े अनुकूलता प्रदान करना आवश्यक है। यह काफी मुश्किल हो सकता है, स्पष्ट नहीं। किसी ऐसे उत्पाद को विकसित करते समय जिसे अन्य उपयोग करते हैं, आपको यह विचार करने की आवश्यकता है कि उपयोगकर्ता समस्याओं के बिना अपडेट होना चाहते हैं। पिछड़ी अनुकूलता सही और अच्छी है। जब आप TDE के रूप में इतना बड़ा सुधार करते हैं, तो आप डिस्क पर सहेजने के नियमों को बदल देते हैं, आप कुछ एन्क्रिप्ट करते हैं। और पिछड़ी अनुकूलता पर काम करना होगा।
3. एक और गैर-स्पष्ट बिंदु हमारे सिस्टम के वितरण से संबंधित है। जब विभिन्न ग्राहक एक ही कैश बनाने का प्रयास करते हैं, तो आपको एन्क्रिप्शन कुंजी पर सहमत होने की आवश्यकता होती है, क्योंकि डिफ़ॉल्ट रूप से दो अलग-अलग उत्पन्न होंगे। हमने इस समस्या को हल कर दिया है। मैं और अधिक विस्तार से ध्यान केंद्रित नहीं करूंगा - समाधान एक अलग पोस्ट का हकदार है। अब हमें एक कुंजी का उपयोग करने की गारंटी दी गई है।
4. अगली महत्वपूर्ण बात से बहुत सुधार हुआ, जब लगा कि सब कुछ तैयार है (एक परिचित कहानी?) :)। एन्क्रिप्शन ओवरहेड है। हमारे पास एक init वेक्टर है - शून्य यादृच्छिक डेटा जो एईएस एल्गोरिथ्म में उपयोग किया जाता है। वे खुले रूप में संग्रहीत होते हैं, और उनकी मदद से हम एन्ट्रापी बढ़ाते हैं: एक ही डेटा को अलग-अलग एन्क्रिप्शन सत्रों में अलग-अलग एन्क्रिप्ट किया जाएगा। मोटे तौर पर, भले ही हमारे पास एक ही उपनाम के साथ दो इवान पेट्रोव हों, हर बार जब हम एन्क्रिप्ट करते हैं, तो हम अलग-अलग एन्क्रिप्टेड डेटा प्राप्त करेंगे। इससे हैकिंग की संभावना कम हो जाती है।
   
   एन्क्रिप्शन 16 बाइट्स के ब्लॉक में होता है, और यदि डेटा 16 बाइट्स द्वारा संरेखित नहीं किया जाता है, तो हम पेडिंग जानकारी जोड़ते हैं - हमने वास्तव में कितना डेटा एन्क्रिप्ट किया है। एक डिस्क पर आपको एक पेज लिखने की ज़रूरत है जो कि 2 Kb का एक बहु है। ये प्रदर्शन आवश्यकताएं हैं: हमें डिस्क बफर का उपयोग करना चाहिए। यदि हम डिस्क बफर पर निर्भर करते हुए 2 Kb (4 या 8 नहीं) लिखते हैं, तो हमें तुरंत एक बड़ा प्रदर्शन मिलता है।
   
   हमने समस्या का समाधान कैसे किया? मुझे RAM में PageIO में क्रॉल करना था, और प्रत्येक पेज से 16 बाइट्स काटनी थी, जिसे डिस्क पर लिखे जाने पर एन्क्रिप्ट किया जाएगा। इन 16 बाइट्स में हम init वेक्टर लिखते हैं।
   
5. एक और कठिनाई कुछ भी तोड़ने के लिए नहीं है। जब आप आते हैं और कुछ बदलाव करते हैं तो यह एक सामान्य बात है। वास्तव में, यह उतना सरल नहीं है जितना लगता है।
   
6. एमवीपी में यह 6 हजार लाइनों में बदल गया। इसकी समीक्षा करना मुश्किल है, और कुछ लोग ऐसा करना चाहते हैं - विशेष रूप से उन विशेषज्ञों से, जिनके पास पहले से ही समय नहीं है। हमारे पास विभिन्न भाग हैं - सार्वजनिक एपीआई, मुख्य भाग, एसपीआई प्रबंधक, पृष्ठों के लिए लगातार स्टोर, वाल प्रबंधक। विभिन्न उप-प्रणालियों में परिवर्तन के लिए आवश्यक है कि उनकी समीक्षा अलग-अलग लोगों द्वारा की जाए। और इससे अतिरिक्त कठिनाइयां भी आती हैं। खासकर जब आप एक ऐसे समुदाय में काम करते हैं जहाँ सभी लोग अपने कार्यों में व्यस्त होते हैं। फिर भी, हमारे लिए सब कुछ काम कर गया।
   

TDE.Phase 2 और 3 में क्या होगा

चरण 1 अब लागू किया गया है। आप एक डेवलपर के रूप में, चरण 2 के साथ मदद कर सकते हैं। आगे की चुनौतियां दिलचस्प हैं। PCI DSS, अन्य मानकों की तरह, एन्क्रिप्शन सिस्टम की अतिरिक्त सुविधाओं की आवश्यकता है। हमारा सिस्टम मास्टर कुंजी को बदलने में सक्षम होना चाहिए। उदाहरण के लिए, यदि उसने समझौता किया था या समय अभी सुरक्षा नीति के अनुसार आया है। अब इग्नाइट को पता नहीं कैसे। लेकिन भविष्य के रिलीज में, हम मास्टर कुंजी को बदलने के लिए TDE सिखाएंगे।

क्लस्टर को रोकने और डेटा के साथ काम करने के बिना कैश कुंजी को बदलने की क्षमता के साथ एक ही बात। यदि कैश लंबे समय तक जीवित रहता है और एक ही समय में कुछ डेटा स्टोर करता है - वित्तीय, चिकित्सा - इग्नाइट कैश कैश कुंजी को बदलने और मक्खी पर सब कुछ फिर से एन्क्रिप्ट करने में सक्षम होना चाहिए। हम तीसरे चरण में इस समस्या का समाधान करेंगे।

कुल: एक ओपन सोर्स प्रोजेक्ट में एक बड़ी सुविधा को कैसे लागू किया जाए?

संक्षेप में देना। वे किसी भी खुले स्रोत के लिए प्रासंगिक होंगे। मैंने काफ्का और अन्य परियोजनाओं में भाग लिया - हर जगह कहानी एक समान है।

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

आगे और अधिक स्पष्ट सुझाव जो पालन करना इतना आसान नहीं है:

• बिना कुछ तोड़े फीचर को लागू करें। परीक्षण करते हैं।
• सही लोगों से, समुदाय के सही सदस्यों से समीक्षा करने के लिए पूछें और प्रतीक्षा करें (यह सबसे कठिन है)।
• बेंचमार्क बनाएं, पता करें कि क्या आपके पास प्रदर्शन ड्रॉप है। कुछ महत्वपूर्ण उप-प्रणालियों को अंतिम रूप देते समय यह विशेष रूप से महत्वपूर्ण है।
• मर्ज की प्रतीक्षा करें, कुछ उदाहरण और प्रलेखन करें।

पढ़ने के लिए धन्यवाद!