pgAudit
ओपन सोर्स PostgreSQL ऑडिट लॉगिंग

परिचय

PostgreSQL ऑडिट एक्सटेंशन (pgAudit) मानक PostgreSQL लॉगिंग सुविधा के माध्यम से विस्तृत सत्र और/या ऑब्जेक्ट ऑडिट लॉगिंग प्रदान करता है।

pgAudit का उद्देश्य PostgreSQL उपयोगकर्ताओं को सरकारी, वित्तीय, या ISO प्रमाणपत्रों के अनुपालन के लिए अक्सर आवश्यक ऑडिट लॉग उत्पन्न करने की क्षमता प्रदान करना है।

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

pgAudit क्यों?

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

उदाहरण के लिए, एक ऑडिटर यह सत्यापित करना चाह सकता है कि एक दस्तावेजित रखरखाव विंडो के अंदर एक विशेष तालिका बनाई गई थी। यह grep के लिए एक सरल कार्य लग सकता है, लेकिन क्या होगा यदि आपको इस तरह का (जानबूझकर अस्पष्ट) उदाहरण प्रस्तुत किया जाए:

DO $$
BEGIN
    EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
END $$;

मानक लॉगिंग आपको यह देगी:

LOG:  statement: DO $$
BEGIN
    EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
END $$;

ऐसा प्रतीत होता है कि रुचि की तालिका खोजने के लिए उन मामलों में कोड के कुछ ज्ञान की आवश्यकता हो सकती है जहां तालिकाएं गतिशील रूप से बनाई जाती हैं। यह आदर्श नहीं है क्योंकि तालिका के नाम पर ही खोज करना बेहतर होगा। यहीं पर pgAudit आता है। समान इनपुट के लिए, यह लॉग में यह आउटपुट उत्पन्न करेगा:

AUDIT: SESSION,33,1,FUNCTION,DO,,,"DO $$
BEGIN
    EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
END $$;"
AUDIT: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)

न केवल DO ब्लॉक लॉग किया गया है, बल्कि उप-कथन 2 में स्टेटमेंट प्रकार, ऑब्जेक्ट प्रकार और पूर्ण-योग्य नाम के साथ CREATE TABLE का पूरा टेक्स्ट शामिल है ताकि खोज आसान हो सके।

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

उपयोग संबंधी विचार

सेटिंग्स के आधार पर, pgAudit के लिए लॉगिंग की एक बहुत बड़ी मात्रा उत्पन्न करना संभव है। अपने वातावरण में वास्तव में क्या ऑडिट लॉग करने की आवश्यकता है, यह निर्धारित करने के लिए सावधान रहें ताकि बहुत अधिक लॉगिंग से बचा जा सके।

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

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

PostgreSQL संस्करण अनुकूलता

pgAudit PostgreSQL 14 या उससे अधिक का समर्थन करता है।

प्रत्येक PostgreSQL रिलीज़ में शामिल नई कार्यक्षमता का समर्थन करने के लिए, pgAudit प्रत्येक PostgreSQL प्रमुख संस्करण (वर्तमान में PostgreSQL 14 - 19) के लिए एक अलग शाखा बनाए रखता है, जिसे PostgreSQL प्रोजेक्ट के समान तरीके से बनाए रखा जाएगा।

बग फिक्स के अलावा, स्थिर शाखाओं के लिए कोई और विकास की अनुमति नहीं है। नया विकास, यदि कोई हो, सख्ती से PostgreSQL के अगले अप्रकाशित प्रमुख संस्करण के लिए होगा।

pgAudit संस्करण PostgreSQL प्रमुख संस्करणों से निम्नानुसार संबंधित हैं:

• pgAudit v19.X PostgreSQL 19 का समर्थन करने के लिए है।

• pgAudit v18.X PostgreSQL 18 का समर्थन करने के लिए है।

• pgAudit v17.X PostgreSQL 17 का समर्थन करने के लिए है।

• pgAudit v16.X PostgreSQL 16 का समर्थन करने के लिए है।

• pgAudit v1.7.X PostgreSQL 15 का समर्थन करने के लिए है।

• pgAudit v1.6.X PostgreSQL 14 का समर्थन करने के लिए है।

संकलन और स्थापना

pgAudit को विकास पैकेजों के साथ PostgreSQL की एक स्थापित प्रतिलिपि के विरुद्ध PGXS का उपयोग करके संकलित किया जा सकता है। निम्नलिखित निर्देश अधिकांश Unix-जैसे ऑपरेटिंग सिस्टम पर काम करने चाहिए।

pgAudit एक्सटेंशन को क्लोन करें:

git clone https://github.com/pgaudit/pgaudit.git

pgAudit निर्देशिका में बदलें:

cd pgaudit

REL_19_STABLE शाखा चेकआउट करें (ध्यान दें कि PostgreSQL के अप्रकाशित संस्करणों के लिए स्थिर शाखा मौजूद नहीं हो सकती है):

git checkout REL_19_STABLE

pgAudit बनाएँ और स्थापित करें:

make install USE_PGXS=1 PG_CONFIG=/usr/pgsql-19/bin/pg_config

परीक्षण और विकास के निर्देश test में पाए जा सकते हैं।

सेटिंग्स

सेटिंग्स को केवल एक सुपरयूज़र द्वारा संशोधित किया जा सकता है। सामान्य उपयोगकर्ताओं को उनकी सेटिंग्स बदलने की अनुमति देना ऑडिट लॉग के उद्देश्य को विफल कर देगा।

सेटिंग्स को वैश्विक रूप से (postgresql.conf में या ALTER SYSTEM ... SET का उपयोग करके), डेटाबेस स्तर पर (ALTER DATABASE ... SET का उपयोग करके), या भूमिका स्तर पर (ALTER ROLE ... SET का उपयोग करके) निर्दिष्ट किया जा सकता है। ध्यान दें कि सेटिंग्स सामान्य भूमिका वंशानुक्रम के माध्यम से विरासत में नहीं मिलती हैं और SET ROLE किसी उपयोगकर्ता की pgAudit सेटिंग्स को नहीं बदलेगा। यह भूमिका प्रणाली की एक सीमा है न कि pgAudit में निहित।

pgAudit एक्सटेंशन को shared_preload_libraries में लोड किया जाना चाहिए। अन्यथा, लोड समय पर एक त्रुटि उठाई जाएगी और कोई ऑडिट लॉगिंग नहीं होगी।

इसके अलावा, उचित pgaudit कार्यक्षमता सुनिश्चित करने के लिए pgaudit.log सेट करने से पहले CREATE EXTENSION pgaudit को कॉल किया जाना चाहिए। एक्सटेंशन इवेंट ट्रिगर स्थापित करता है जो DDL के लिए अतिरिक्त ऑडिटिंग जोड़ता है। pgAudit एक्सटेंशन स्थापित किए बिना काम करेगा लेकिन DDL स्टेटमेंट में ऑब्जेक्ट प्रकार और नाम के बारे में जानकारी नहीं होगी।

यदि pgaudit एक्सटेंशन ड्रॉप किया जाता है और इसे पुनः बनाने की आवश्यकता है तो पहले pgaudit.log को अनसेट किया जाना चाहिए अन्यथा एक त्रुटि उठाई जाएगी।

pgaudit.log

निर्दिष्ट करता है कि सत्र ऑडिट लॉगिंग द्वारा कथनों के कौन से वर्ग लॉग किए जाएंगे। संभावित मान हैं:

• READ: SELECT और COPY जब स्रोत कोई संबंध या क्वेरी हो।

• WRITE: INSERT, UPDATE, DELETE, TRUNCATE, और COPY जब गंतव्य कोई संबंध हो।

• FUNCTION: फ़ंक्शन कॉल और DO ब्लॉक।

• ROLE: भूमिकाओं और विशेषाधिकारों से संबंधित कथन: GRANT, REVOKE, CREATE/ALTER/DROP ROLE।

• DDL: सभी DDL जो ROLE वर्ग में शामिल नहीं हैं।

• MISC: विविध आदेश, जैसे DISCARD, FETCH, CHECKPOINT, VACUUM, SET।

• MISC_SET: विविध SET आदेश, जैसे SET ROLE।

• ALL: उपरोक्त सभी शामिल करें।

एक अल्पविराम-पृथक सूची का उपयोग करके कई वर्ग प्रदान किए जा सकते हैं और वर्ग को - चिह्न से पहले रखकर घटाया जा सकता है (देखें सत्र ऑडिट लॉगिंग)।