DevOps ओपन-सोर्स डेटाबेस ऑडिट मैनुअल - वह सब कुछ जो आपको जानना चाहिए

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

इस ब्लॉग पोस्ट में, हम अपने ओपन-सोर्स डेटाबेस सिस्टम, विशेष रूप से MySQL, MariaDB, PostgreSQL और MongoDB के ऑडिट के मूलभूत पहलुओं को कवर करने जा रहे हैं। यह लेख उन DevOps इंजीनियरों के लिए लक्षित है जिनके पास आमतौर पर डेटाबेस सिस्टम के लिए बुनियादी ढांचे का प्रबंधन करते समय ऑडिट अनुपालन सर्वोत्तम अभ्यास और अच्छे डेटा शासन में कम अनुभव या जोखिम होता है।

स्टेटमेंट ऑडिटिंग

MySQL स्टेटमेंट ऑडिटिंग

MySQL में सामान्य क्वेरी लॉग (या सामान्य_लॉग) है, जो मूल रूप से रिकॉर्ड करता है कि mysqld क्या कर रहा है। क्लाइंट कनेक्ट या डिस्कनेक्ट होने पर सर्वर इस लॉग में जानकारी लिखता है, और यह क्लाइंट से प्राप्त प्रत्येक SQL कथन को लॉग करता है। समस्या निवारण के दौरान सामान्य क्वेरी लॉग बहुत उपयोगी हो सकता है लेकिन वास्तव में निरंतर ऑडिटिंग के लिए नहीं बनाया गया है। इसका एक बड़ा प्रदर्शन प्रभाव पड़ता है और इसे केवल कम समय के स्लॉट के दौरान ही सक्षम किया जाना चाहिए। इसके बजाय performance_schema.events_statements* टेबल या ऑडिट प्लगिन का उपयोग करने के लिए अन्य विकल्प हैं।

पोस्टग्रेएसक्यूएल स्टेटमेंट ऑडिटिंग

PostgreSQL के लिए, आप log_statment को "all" में सक्षम कर सकते हैं। इस पैरामीटर के लिए समर्थित मान कोई नहीं (बंद), डीडीएल, मॉड और सभी (सभी कथन) हैं। "डीडीएल" के लिए, यह सभी डेटा परिभाषा कथनों को लॉग करता है, जैसे कि CREATE, ALTER, और DROP स्टेटमेंट। "मॉड" के लिए, यह सभी डीडीएल स्टेटमेंट्स को लॉग करता है, साथ ही डेटा-मॉडिफाइंग स्टेटमेंट जैसे INSERT, UPDATE, DELETE, TRUNCATE, और COPY FROM।

आपको संबंधित पैरामीटर जैसे log_directory, log_filename, logging_collector और log_rotation_age को कॉन्फ़िगर करने की आवश्यकता हो सकती है, जैसा कि निम्नलिखित उदाहरण में दिखाया गया है:

log_directory     = 'pg_log'
log_filename      = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_statement     = 'all'
logging_collector = on
log_rotation_age  = 10080 # 1 week in minutes 

उपरोक्त परिवर्तनों के लिए PostgreSQL पुनरारंभ की आवश्यकता होती है, इसलिए कृपया अपने उत्पादन परिवेश पर लागू करने से पहले सावधानीपूर्वक योजना बनाएं। फिर आप pg_log निर्देशिका के अंतर्गत वर्तमान लॉग पा सकते हैं। PostgreSQL 12 के लिए, स्थान /var/lib/pgsql/12/data/pg_log/ पर है। ध्यान दें कि लॉग फ़ाइलें समय के साथ बहुत बढ़ती हैं, और डिस्क स्थान को महत्वपूर्ण रूप से खा सकती हैं। यदि आपके पास सीमित संग्रहण स्थान है, तो आप इसके बजाय log_rotation_size का भी उपयोग कर सकते हैं।

MongoDB स्टेटमेंट ऑडिटिंग

MongoDB के लिए, 3 लॉगिंग स्तर हैं जो हमें स्टेटमेंट (MongoDB टर्म में ऑपरेशन या ऑप्स) का ऑडिट करने में मदद कर सकते हैं:

• स्तर 0 - यह डिफ़ॉल्ट प्रोफाइलर स्तर है जहां प्रोफाइलर कोई डेटा एकत्र नहीं करता है। मोंगॉड हमेशा अपने लॉग के लिए slowOpThresholdMs थ्रेशोल्ड से अधिक लंबा संचालन लिखता है।

• स्तर 1 - केवल धीमे संचालन के लिए प्रोफाइलिंग डेटा एकत्र करता है। डिफ़ॉल्ट रूप से धीमे संचालन 100 मिलीसेकंड से धीमे होते हैं। आप "धीमे" संचालन के लिए थ्रेशोल्ड को slowOpThresholdMs रनटाइम विकल्प या सेटपैरामीटर कमांड के साथ संशोधित कर सकते हैं।

• स्तर 2 - सभी डेटाबेस संचालन के लिए प्रोफाइलिंग डेटा एकत्र करता है।

सभी परिचालनों को लॉग करने के लिए, db.setProfilingLevel(2, 1000) सेट करें, जहां इसे परिभाषित मिलीसेकंड से अधिक समय लेने वाले संचालन के साथ सभी परिचालनों को प्रोफाइल करना चाहिए, इस मामले में, 1 सेकंड (1000 एमएस) है। . टाइमस्टैम्प अवरोही द्वारा क्रमित, एक सेकंड से अधिक समय लेने वाले सभी प्रश्नों के लिए सिस्टम प्रोफ़ाइल संग्रह में देखने के लिए क्वेरी होगी। संचालन को पढ़ने के लिए, हम निम्नलिखित क्वेरी का उपयोग कर सकते हैं:

mongodb> db.system.profile.find( { millis : { $gt:1000 } } ).sort( { ts : -1 } )

इसके अलावा, एक Mongotail प्रोजेक्ट भी है, जो सीधे प्रोफ़ाइल संग्रह को क्वेरी करने के बजाय बाहरी टूल के साथ ऑपरेशन प्रोफाइलिंग प्रक्रिया को सरल बनाता है।

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

MySQL, MariaDB और PostgreSQL के लिए विशेषाधिकार ऑडिटिंग

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

अति-विशेषाधिकार प्राप्त उदाहरण हैं:

• उपयोगकर्ता के एक्सेस होस्ट को बहुत व्यापक श्रेणी से अनुमति है, उदाहरण के लिए उपयोगकर्ता होस्ट प्रदान करना [email protected]' %', एक व्यक्तिगत आईपी पते के बजाय।

• गैर-प्रशासनिक डेटाबेस उपयोगकर्ताओं को प्रशासनिक विशेषाधिकार सौंपे जा रहे हैं, उदाहरण के लिए, एप्लिकेशन के लिए एक डेटाबेस उपयोगकर्ता असाइन किया जा रहा है सुपर या रीलोड विशेषाधिकार के साथ।

• अधिकतम उपयोगकर्ता कनेक्शन, अधिकतम क्वेरी प्रति घंटा, या अधिकतम जैसे किसी भी प्रकार के अत्यधिक उपयोग के विरुद्ध संसाधन नियंत्रण का अभाव प्रति घंटे कनेक्शन।

• विशिष्ट डेटाबेस उपयोगकर्ताओं को अन्य स्कीमा तक भी पहुंचने की अनुमति दें।

MySQL, MariaDB और PostgreSQL के लिए, आप अनुदान, भूमिका और विशेषाधिकार-संबंधित तालिकाओं को क्वेरी करके सूचना स्कीमा के माध्यम से विशेषाधिकार ऑडिटिंग कर सकते हैं। MongoDB के लिए, निम्न क्वेरी का उपयोग करें (अन्य डेटाबेस के लिए viewUser क्रिया की आवश्यकता है):

mongodb> db.getUsers( { usersInfo: { forAllDBs: true } } )

ClusterControl डेटाबेस उपयोगकर्ता को सौंपे गए विशेषाधिकारों का एक अच्छा सारांश प्रदान करता है। प्रबंधित करने के लिए जाओ -> स्कीमा और उपयोगकर्ता -> उपयोगकर्ता और आपको उपयोगकर्ताओं के विशेषाधिकारों की एक रिपोर्ट मिलेगी, साथ में उन्नत विकल्प जैसे एसएसएल की आवश्यकता है, प्रति घंटे अधिकतम कनेक्शन और इतने पर।

ClusterControl एक ही उपयोगकर्ता के तहत MySQL, MariaDB और PostgreSQL के लिए विशेषाधिकार ऑडिटिंग का समर्थन करता है इंटरफेस।

स्कीमा ऑब्जेक्ट ऑडिटिंग

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

MySQL और MariaDB के लिए, जानकारी_स्कीमा और प्रदर्शन_स्कीमा हैं जिनका उपयोग हम मूल रूप से स्कीमा ऑब्जेक्ट का ऑडिट करने के लिए कर सकते हैं। जैसा कि इसके नाम से पता चलता है, Performance_schema इंस्ट्रूमेंटेशन में थोड़ी गहराई है। हालाँकि, MySQL में संस्करण 5.7.7 के बाद से एक sys स्कीमा भी शामिल है, जो कि performance_schema का एक उपयोगकर्ता के अनुकूल संस्करण है। ये सभी डेटाबेस ग्राहकों द्वारा सीधे पहुंच योग्य और क्वेरी करने योग्य हैं।

डेटाबेस ऑडिट प्लगइन्स/एक्सटेंशन

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

PostgreSQL के लिए, pgAudit, एक PostgreSQL एक्सटेंशन है जो मानक PostgreSQL लॉगिंग सुविधा के माध्यम से विस्तृत सत्र और/या ऑब्जेक्ट ऑडिट लॉगिंग प्रदान करता है। यह मूल रूप से PostgreSQL की log_statement सुविधा का एक उन्नत संस्करण है जिसमें मानक ऑडिट लॉग का पालन करके ऑडिटिंग के लिए कैप्चर किए गए डेटा को आसानी से खोजने और देखने की क्षमता है।

MongoDB Enterprise (पेड) और MongoDB (फ्री) के लिए Percona सर्वर में mongod और mongos इंस्टेंस के लिए ऑडिटिंग क्षमता शामिल है। ऑडिटिंग सक्षम होने के साथ, सर्वर ऑडिट संदेश उत्पन्न करेगा जिसे syslog, कंसोल या फ़ाइल (JSON या BSON प्रारूप) में लॉग इन किया जा सकता है। ज्यादातर मामलों में, बीएसओएन प्रारूप में फ़ाइल में लॉग इन करना बेहतर होता है, जहां प्रदर्शन प्रभाव JSON से छोटा होता है। इस फ़ाइल में प्रमाणीकरण, प्राधिकरण विफलताओं, आदि सहित विभिन्न उपयोगकर्ता घटनाओं के बारे में जानकारी है। विवरण के लिए ऑडिटिंग दस्तावेज़ देखें।

ऑपरेटिंग सिस्टम ऑडिट ट्रेल्स

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

उत्पादन उपयोग के लिए किसी भी प्रकार के सर्वर की स्थापना करते समय निम्नलिखित स्थापना चरण हमारे सामान्य अभ्यास हैं:

$ yum -y install audit # apt install auditd python
$ mv /etc/audit/rules.d/audit.rules /etc/audit/rules.d/audit.rules.ori
$ cd /etc/audit/rules.d/
$ wget https://gist.githubusercontent.com/ashraf-s9s/fb1b674e15a5a5b41504faf76a08b4ae/raw/2764bf0e9bf25418bb86e33c13fb80356999d220/audit.rules
$ chmod 640 audit.rules
$ systemctl daemon-reload
$ systemctl start auditd
$ systemctl enable auditd
$ service auditd restart

ध्यान दें कि अंतिम पंक्ति सेवा ऑडिट पुनरारंभ अनिवार्य है क्योंकि सिस्टमड के साथ नियमों को लोड करते समय ऑडिट वास्तव में अच्छी तरह से काम नहीं करता है। हालाँकि, सिस्टमड को अभी भी ऑडिट सेवा की निगरानी के लिए आवश्यक है। स्टार्टअप के दौरान, /etc/audit/audit.rules में नियमों को ऑडिटक्टल द्वारा पढ़ा जाता है। ऑडिट डेमॉन में स्वयं कुछ कॉन्फ़िगरेशन विकल्प होते हैं जिन्हें व्यवस्थापक अनुकूलित करना चाह सकता है। वे ऑडिटड.कॉन्फ़ फ़ाइल में पाए जाते हैं।

निम्न पंक्ति एक कॉन्फ़िगर किए गए ऑडिट लॉग से लिया गया आउटपुट है:

$ ausearch -m EXECVE | grep -i 'password' | head -1
type=EXECVE msg=audit(1615377099.934:11838148): argc=7 a0="mysql" a1="-NAB" a2="--user=appdb1" a3="--password=S3cr3tPassw0rdKP" a4="-h127.0.0.1" a5="-P3306" a6=2D6553484F5720474C4F42414C205641524941424C4553205748455245205641524941424C455F4E414D4520494E20282776657273696F6E272C202776657273696F6E5F636F6D6D656E74272C2027646174616469722729

जैसा कि आप ऊपर से देख सकते हैं, ऑडिट द्वारा कैप्चर की गई ऑसर्च यूटिलिटी का उपयोग करके MySQL ("--password=S3cr3tPassw0rdKP") के लिए एक क्लियरटेक्स्ट पासवर्ड खोजना आसान है। इस तरह की खोज और ऑडिटिंग हमारे डेटाबेस इन्फ्रास्ट्रक्चर को सुरक्षित करने के लिए महत्वपूर्ण है, जहां एक सुरक्षित वातावरण में क्लियरटेक्स्ट पासवर्ड अस्वीकार्य है।

अंतिम विचार

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