मारियाडीबी के लिए ऑडिट लॉगिंग का उपयोग करके टिप्स और ट्रिक

MariaDB का ऑडिट प्लगिन न केवल MariaDB बल्कि MySQL (संस्करण 5.5.34 और 10.0.7) और Percona सर्वर के लिए भी ऑडिटिंग कार्यक्षमता प्रदान करता है। मारियाडीबी ने डिफ़ॉल्ट रूप से संस्करण 10.0.10 और 5.5.37 से ऑडिट प्लगइन को शामिल करना शुरू किया, और इसे मारियाडीबी 5.5.20 से किसी भी संस्करण में स्थापित किया जा सकता है।

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

इस ब्लॉग पोस्ट में, हम आपको कुछ सर्वोत्तम-अभ्यास ट्यूनिंग और मारियाडीबी सर्वर के लिए ऑडिट लॉगिंग को कॉन्फ़िगर करने के तरीके के बारे में सुझाव दिखाने जा रहे हैं। लेखन मारियाडीबी 10.5.9 पर आधारित है, मारियाडीबी ऑडिट प्लगइन 1.4.4 के नवीनतम संस्करण के साथ।

इंस्टॉलेशन ट्यूनिंग

ऑडिट लॉगिंग को सक्षम करने का अनुशंसित तरीका मारियाडीबी कॉन्फ़िगरेशन फ़ाइल के अंदर निम्नलिखित पंक्तियों को सेट करना है:

[mariadb]
plugin_load_add = server_audit # load plugin
server_audit=FORCE_PLUS_PERMANENT  # do not allow users to uninstall plugin
server_audit_file_path=/var/log/mysql/mariadb-audit.log # path to the audit log
server_audit_logging=ON  # enable audit logging

ऑडिट लॉग को लागू करने के लिए "server_audit=FORCE_PLUS_PERMANENT" सेट करना न भूलें और इसे UNINSTALL SONAME स्टेटमेंट का उपयोग करके अन्य उपयोगकर्ताओं द्वारा अनइंस्टॉल करने की अनुमति न दें। डिफ़ॉल्ट रूप से, लॉगिंग गंतव्य MariaDB डेटा निर्देशिका में एक लॉग फ़ाइल है। हमें ऑडिट लॉग को इस निर्देशिका से बाहर रखना चाहिए क्योंकि एक मौका है कि डेटादिर मिटा दिया जाएगा (गैलेरा क्लस्टर के लिए एसएसटी), या मारियाडीबी बैकअप से लिए गए बैकअप को पुनर्स्थापित करते समय डेटादिर स्वैपिंग जैसे भौतिक पुनर्स्थापना के लिए प्रतिस्थापित किया जा रहा है।

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

ऑडिट ईवेंट फ़िल्टरिंग

MariaDB ऑडिट प्लगइन कई लॉग सेटिंग्स का उपयोग करता है जो प्लगइन संस्करण पर निर्भर करता है। निम्नलिखित ऑडिट इवेंट नवीनतम प्लगइन संस्करण 1.4.4 पर उपलब्ध हैं:

प्रकार	विवरण
कनेक्ट करें	त्रुटि कोड सहित कनेक्ट, डिस्कनेक्ट और विफल कनेक्ट होता है
QUERY	निष्पादित क्वेरी और उनके परिणाम सादे पाठ में, सिंटैक्स या अनुमति त्रुटियों के कारण विफल क्वेरी सहित
टेबल	क्वेरी निष्पादन से प्रभावित तालिकाएं
QUERY_DDL	QUERY के समान, लेकिन केवल DDL-प्रकार की क्वेरी को फ़िल्टर करता है (CREATE, ALTER, DROP, RENAME और TRUNCATE स्टेटमेंट - CREATE/DROP [PROCEDURE / FUNCTION / USER] और RENAME USER को छोड़कर (वे 'डीडीएल नहीं हैं)
QUERY_DML	QUERY के समान, लेकिन केवल DML-प्रकार की क्वेरी को फ़िल्टर करता है (DO, CALL, LOAD DATA/XML, DELETE, INSERT, SELECT, UPDATE, HANDLER और REPLACE स्टेटमेंट)
QUERY_DML_NO_SELECT	QUERY_DML के समान, लेकिन SELECT क्वेरी लॉग नहीं करता है। (संस्करण 1.4.4 के बाद से) (DO, CALL, LOAD DATA/XML, DELETE, INSERT, UPDATE, HANDLER और REPLACE स्टेटमेंट)
QUERY_DCL	QUERY के समान, लेकिन केवल DCL-प्रकार की क्वेरी को फ़िल्टर करता है (क्रिएट यूजर, DROP USER, RENAME USER, GRANT, REVOKE और SET PASSWORD स्टेटमेंट)

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

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

विशिष्ट घटनाओं को फ़िल्टर करने के लिए, निम्न पंक्ति को MariaDB कॉन्फ़िगरेशन फ़ाइल के अंदर सेट करें (पुनरारंभ करने की आवश्यकता है):

server_audit_events = 'CONNECT,QUERY,TABLE'

या SET GLOBAL का उपयोग करके इसे गतिशील रूप से रनटाइम में सेट करें (फिर से शुरू करने की आवश्यकता नहीं है, लेकिन लगातार नहीं):

MariaDB> SET GLOBAL server_audit_events = 'CONNECT,QUERY,TABLE';

यह एक ऑडिट इवेंट का उदाहरण है:

20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,226,QUERY,information_schema,'SHOW GLOBAL VARIABLES',0

इस लॉग की एक प्रविष्टि में निम्नलिखित जानकारी वाले अल्पविराम द्वारा अलग की गई जानकारी का एक समूह होता है:

टाइमस्टैम्प
MySQL होस्ट (SELECT @@hostname के मान के समान)
डेटाबेस उपयोगकर्ता
वह होस्ट करें जहां उपयोगकर्ता कनेक्ट हो रहा था
कनेक्शन आईडी
थ्रेड आईडी
ऑपरेशन
डेटाबेस
SQL कथन/कमांड
रिटर्न कोड। 0 का अर्थ है कि ऑपरेशन एक सफलता प्रतिक्रिया (यहां तक कि खाली) देता है, जबकि एक गैर-शून्य मान का अर्थ है सिंटैक्स या अनुमति त्रुटियों के कारण विफल क्वेरी की तरह ऑपरेशन को निष्पादित करने में त्रुटि।

प्रविष्टियों को फ़िल्टर करते समय, कोई साधारण grep करेगा और एक विशिष्ट पैटर्न की तलाश करेगा:

$ grep -i global /var/lib/mysql/server_audit.log
20210325 04:19:17,ip-172-31-0-44,root,localhost,14,37080,QUERY,,'set global server_audit_file_rotate_now = 1',0
20210326 00:46:48,ip-172-31-0-44,root,localhost,35,329003,QUERY,,'set global server_audit_output_type = \'syslog\'',0

डिफ़ॉल्ट रूप से, सभी पासवर्ड मान तारांकन के साथ छिपाए जाएंगे:

20210326 05:39:41,ip-172-31-0-44,root,localhost,52,398793,QUERY,mysql,'GRANT ALL PRIVILEGES ON sbtest.* TO [email protected] IDENTIFIED BY *****',0

ऑडिट उपयोगकर्ता फ़िल्टरिंग

यदि आप सब कुछ ट्रैक करते हैं, तो संभवतः आप निगरानी करने वाले उपयोगकर्ता से उसकी नमूना जिम्मेदारी के लिए भर जाएंगे, जैसा कि नीचे दिए गए उदाहरण में दिखाया गया है:

20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,226,QUERY,information_schema,'SHOW GLOBAL VARIABLES',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,227,QUERY,information_schema,'select @@global.wsrep_provider_options',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,228,QUERY,information_schema,'SHOW SLAVE STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,229,QUERY,information_schema,'SHOW MASTER STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,230,QUERY,information_schema,'SHOW SLAVE HOSTS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,231,QUERY,information_schema,'SHOW GLOBAL VARIABLES',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,232,QUERY,information_schema,'select @@global.wsrep_provider_options',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,233,QUERY,information_schema,'SHOW SLAVE STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,234,QUERY,information_schema,'SHOW MASTER STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,235,QUERY,information_schema,'SHOW SLAVE HOSTS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,5,236,QUERY,information_schema,'SET GLOBAL SLOW_QUERY_LOG=0',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,5,237,QUERY,information_schema,'FLUSH /*!50500 SLOW */ LOGS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,6,238,QUERY,information_schema,'SHOW GLOBAL STATUS',0

एक सेकंड की अवधि में, हम "cmon" नामक हमारे निगरानी उपयोगकर्ता के लिए ऑडिट प्लगइन द्वारा रिकॉर्ड की गई 14 QUERY घटनाओं को देख सकते हैं। हमारे परीक्षण कार्यभार में, लॉगिंग दर लगभग 32 केबी प्रति मिनट है, जो प्रति दिन 46 एमबी तक जमा हो जाएगी। भंडारण आकार और आईओ क्षमता के आधार पर, यह कुछ कार्यभार में अत्यधिक हो सकता है। इसलिए ऑडिट लॉगिंग से मॉनिटरिंग उपयोगकर्ता को फ़िल्टर करना बेहतर होगा, ताकि हमारे पास एक क्लीनर आउटपुट हो और ऑडिट और विश्लेषण करना बहुत आसान हो।

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

server_audit_excl_users='cmon'

MariaDB> SET GLOBAL server_audit_excl_users = 'cmon'

आप अल्पविराम द्वारा अलग किए गए एकाधिक डेटाबेस उपयोगकर्ता जोड़ सकते हैं। उपरोक्त को जोड़ने के बाद, हमें नीचे के रूप में एक क्लीनर ऑडिट लॉग मिला (अब 'cmon' उपयोगकर्ता से कुछ भी नहीं):

$ tail -f /var/log/mysql/mysql-audit.log
20210325 04:16:06,ip-172-31-0-44,cmon,172.31.1.119,6,36218,QUERY,information_schema,'SHOW GLOBAL STATUS',0
20210325 04:16:06,ip-172-31-0-44,root,localhost,13,36219,QUERY,,'set global server_audit_excl_users = \'cmon\'',0
20210325 04:16:09,ip-172-31-0-44,root,localhost,13,36237,QUERY,,'show global variables like \'%server_audit%\'',0
20210325 04:16:12,ip-172-31-0-44,root,localhost,13,0,DISCONNECT,,,0

लॉग रोटेशन प्रबंधन

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

MariaDB> SET GLOBAL server_audit_file_rotate_now = 1;

स्वचालित लॉग रोटेशन के लिए, हमें मारियाडीबी कॉन्फ़िगरेशन फ़ाइल के अंदर निम्नलिखित चर सेट करने चाहिए:

server_audit_file_rotate_size=1000000 # in bytes
server_audit_file_rotations=30

या SET GLOBAL का उपयोग करके इसे गतिशील रूप से रनटाइम में सेट करें (फिर से शुरू करने की आवश्यकता नहीं है):

MariaDB> SET GLOBAL server_audit_file_rotate_size=1000000;
MariaDB> SET GLOBAL server_audit_file_rotations=30;

ऑडिट लॉग रोटेशन को अक्षम करने के लिए, बस सर्वर_ऑडिट_फाइल_रोटेशन को 0 पर सेट करें। डिफ़ॉल्ट मान 9 है। निर्दिष्ट सीमा तक पहुंचने के बाद लॉग रोटेशन स्वचालित रूप से होगा और अंतिम 30 लॉग रखेगा, जिसका अर्थ है कि पिछले 30 दिनों की ऑडिट लॉगिंग के लायक।

Syslog या Rsyslog सुविधा का उपयोग करके ऑडिट करना

syslog या rsyslog सुविधा का उपयोग करने से लॉग प्रबंधन आसान हो जाएगा क्योंकि यह केंद्रीय भंडार में विभिन्न प्रकार के सिस्टम से लॉगिंग की अनुमति देता है। एक अन्य लॉगिंग घटक को बनाए रखने के बजाय, हम MariaDB ऑडिट को syslog में लॉग इन करने का निर्देश दे सकते हैं। यह आसान है अगर आपके पास स्प्लंक, लॉगस्टैश, लॉगली या अमेज़ॅन क्लाउडवॉच जैसी लॉग विश्लेषक सेवाओं के लिए लॉग कलेक्टर/स्ट्रीमर है।

ऐसा करने के लिए, निम्न पंक्तियों को MariaDB कॉन्फ़िगरेशन फ़ाइल के अंदर सेट करें (पुनरारंभ करने की आवश्यकता है):

server_audit_logging = 'syslog'
server_audit_syslog_ident = 'mariadb-audit'

या यदि आप रनटाइम में बदलाव करना चाहते हैं (फिर से शुरू करने की आवश्यकता नहीं है, लेकिन लगातार नहीं):

MariaDB> SET GLOBAL server_audit_logging = 'syslog';
MariaDB> SET GLOBAL server_audit_syslog_ident = 'mariadb-audit';

प्रविष्टियां Syslog प्रारूप के समान होंगी:

$ grep mariadb-audit /var/log/syslog
Mar 26 00:48:49 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,36,329540,QUERY,,'SET GLOBAL server_audit_syslog_ident = \'mariadb-audit\'',0
Mar 26 00:48:54 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,36,0,DISCONNECT,,,0

यदि आप एक केंद्रीकृत लॉगिंग रिपॉजिटरी के लिए एक दूरस्थ लॉगिंग सेवा स्थापित करना चाहते हैं, तो हम rsyslog का उपयोग कर सकते हैं। चाल सर्वर_ऑडिट_सिसलॉग_सुविधा चर का उपयोग करना है जहां हम लॉगिंग की सुविधा के लिए फ़िल्टर बना सकते हैं, जैसा कि नीचे दिया गया है:

MariaDB> SET GLOBAL server_audit_logging = 'syslog';
MariaDB> SET GLOBAL server_audit_syslog_ident = 'mariadb-audit';
MariaDB> SET GLOBAL server_audit_syslog_facility = 'LOG_LOCAL6';

हालांकि, पहले से कुछ आवश्यक कदम हैं। एक केंद्रीकृत rsyslog सर्वर के साथ निम्नलिखित MariaDB मास्टर-स्लेव प्रतिकृति आर्किटेक्चर पर विचार करें:

इस उदाहरण में, सभी सर्वर Ubuntu 20.04 पर चल रहे हैं। rsyslog गंतव्य सर्वर पर, हमें /etc/rsyslog.conf के अंदर निम्नलिखित सेट करने की आवश्यकता है:

module(load="imtcp")
input(type="imtcp" port="514")
$ModLoad imtcp
$InputTCPServerRun 514
if $fromhost-ip=='172.31.0.44' then /var/log/mariadb-centralized-audit.log
& ~
if $fromhost-ip=='172.31.0.82' then /var/log/mariadb-centralized-audit.log
& ~

ध्यान दें कि "&~" भाग महत्वपूर्ण है और इसे देखना न भूलें। यह मूल रूप से लॉगिंग सुविधा को /var/log/mariadb-centralized-audit.log में लॉग इन करने और उसके ठीक बाद आगे की प्रक्रिया को रोकने के लिए कहता है।

अगला, सही फ़ाइल स्वामित्व और अनुमति के साथ गंतव्य लॉग फ़ाइल बनाएं:

$ touch /var/log/mariadb-centralized-audit.log
$ chown syslog:adm /var/log/mariadb-centralized-audit.log
$ chmod 640 /var/log/mariadb-centralized-audit.log

rsyslog पुनः प्रारंभ करें:

$ systemctl restart rsyslog

सुनिश्चित करें कि यह TCP पोर्ट 514 पर सभी पहुँच योग्य IP पतों पर सुनता है:

$ netstat -tulpn | grep rsyslog
tcp        0      0 0.0.0.0:514             0.0.0.0:*               LISTEN      3143247/rsyslogd
tcp6       0      0 :::514                  :::*                    LISTEN      3143247/rsyslogd

हमने गंतव्य rsyslog सर्वर को कॉन्फ़िगर करना पूरा कर लिया है। अब हम स्रोत भाग को कॉन्फ़िगर करने के लिए तैयार हैं। MariaDB सर्वर पर /etc/rsyslog.d/50-mariadb-audit.conf पर एक नई अलग rsyslog कॉन्फ़िगरेशन फ़ाइल बनाएँ और निम्न पंक्तियाँ जोड़ें:

$WorkDirectory /var/lib/rsyslog # where to place spool files
$ActionQueueFileName queue1     # unique name prefix for spool files
$ActionQueueMaxDiskSpace 1g     # 1GB space limit (use as much as possible)
$ActionQueueSaveOnShutdown on   # save messages to disk on shutdown
$ActionQueueType LinkedList     # run asynchronously
$ActionResumeRetryCount -1      # infinite retries if rsyslog host is down
local6.* action(type="omfwd" target="172.31.6.200" port="514" protocol="tcp")

पहले खंड में सेटिंग्स एक ऑन-डिस्क कतार बनाने के बारे में हैं, जिसकी अनुशंसा की जाती है कि कोई भी लॉग प्रविष्टि खो न जाए। अंतिम पंक्ति महत्वपूर्ण है। हमने ऑडिट प्लगइन के लिए वेरिएबल server_audit_syslog_facility को LOG_LOCAL6 में बदल दिया है। यहां, हमने "लोकल6.*" को केवल टीसीपी प्रोटोकॉल के माध्यम से पोर्ट 514 पर rsyslog सर्वर 172.31.6.200 पर चल रहे rsyslog सुविधा local6 का उपयोग करके Syslog प्रविष्टियों को अग्रेषित करने के लिए एक फ़िल्टर के रूप में निर्दिष्ट किया है।

rsyslog के लिए परिवर्तनों को सक्रिय करने के लिए, अंतिम चरण परिवर्तनों को सक्रिय करने के लिए MariaDB सर्वर पर rsyslog को पुनरारंभ करना है:

$ systemctl restart rsyslog

अब, स्रोत नोड पर rsyslog सही ढंग से कॉन्फ़िगर किया गया है। हम मारियाडीबी सर्वर तक पहुंच कर परीक्षण कर सकते हैं और ऑडिट इवेंट जेनरेट करने के लिए कुछ गतिविधियां कर सकते हैं। आपको यह देखना चाहिए कि ऑडिट लॉग प्रविष्टियाँ यहाँ अग्रेषित की गई हैं:

$ tail -f /var/log/mariadb-centralized-audit.log
Mar 26 12:56:18 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,69,0,CONNECT,,,0
Mar 26 12:56:18 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,69,489413,QUERY,,'select @@version_comment limit 1',0
Mar 26 12:56:19 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,69,489414,QUERY,,'show databases',0
Mar 26 12:56:37 ip-172-31-0-44 mariadb-audit:  ip-172-31-0-44,root,localhost,69,0,DISCONNECT,,,0

अंतिम विचार

MariaDB ऑडिट प्लगिन को आपकी सुरक्षा और ऑडिटिंग नीतियों के अनुरूप कई तरह से कॉन्फ़िगर किया जा सकता है। ऑडिटिंग जानकारी आपको प्रदर्शन या एप्लिकेशन समस्याओं का निवारण करने में मदद कर सकती है, और आपको यह देखने देती है कि वास्तव में कौन सी SQL क्वेरी संसाधित की जा रही हैं।