इस समस्या का Oracle का अंतर्निर्मित समाधान एन्क्रिप्शन नहीं है, बल्कि DBA या अन्य उपयोगकर्ताओं को क्रमशः डेटा देखने से रोकने के लिए डेटाबेस वॉल्ट या वर्चुअल प्राइवेट डेटाबेस का उपयोग करके एक्सेस कंट्रोल है, और डेटा को आराम से एन्क्रिप्ट करने के लिए ट्रांसपेरेंट डेटा एन्क्रिप्शन (OS/फ़ाइल) -लेवल एन्क्रिप्शन)। यह न केवल DBA को डेटा देखने से रोकता है, बल्कि उसे बदलने या हटाने से भी रोकता है।
यदि आप वैसे भी डेटा मानों को एन्क्रिप्ट करना चाहते हैं, तो सभी एन्क्रिप्शन/डिक्रिप्शन और कुंजी प्रबंधन को बाहरी रूप से संभाला जाना चाहिए डेटाबेस से जहां डीबीए के पास एन्क्रिप्शन कुंजी तक पहुंच नहीं होगी। यह कैसे काम करता है यह आपके एप्लिकेशन डिज़ाइन और प्रोग्रामिंग भाषा (भाषाओं) की पसंद पर निर्भर करेगा। ध्यान रखें कि एक मजबूत एन्क्रिप्शन और प्रमुख प्रबंधन वास्तुकला का निर्माण नहीं है एक तुच्छ व्यायाम...
यह भी जान लें कि पीएल/एसक्यूएल सोर्स कोड को लपेटना केवल obfuscation है कोड का और एन्क्रिप्शन का नहीं। यह आसानी से हो सकता है मौजूदा वेब साइटों या आंतरिक संग्रहीत प्रक्रियाओं की किसी भी संख्या का उपयोग करके उलट दिया गया है। एक सच्चे DBA में execute any procedure . भी होगा विशेषाधिकार या किसी भी डिक्रिप्शन फ़ंक्शन को निष्पादित करने के लिए खुद को स्पष्ट अनुमति देने में सक्षम हो और यहां तक कि यह भी परवाह न करें कि कुंजी क्या थी (केवल डेटाबेस वॉल्ट इसे रोक सकता था)।
कोड में सीधे एम्बेड करने के बजाय फ़ंक्शन की कुंजी को इनपुट के रूप में ट्रांसमिट करना भी समस्याग्रस्त होगा, क्योंकि DBA आपके SQL को किसी भी तरह से देख सकता है। SQL क्वेरी के माध्यम से प्रेषित होने पर कुंजी को ADDM रिपोर्ट, डेटाबेस ट्रेस फ़ाइलों या ऑडिट ट्रेल में भी दिखाया जा सकता है।
नहीं है एन्क्रिप्शन को संभालने का सुरक्षित तरीका जैसा कि आप पीएल/एसक्यूएल के साथ वर्णन कर रहे हैं जो डेटा को डीबीए से भी बचाता है।
