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: उपरोक्त सभी शामिल करें।

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

डिफ़ॉल्ट none है।

pgaudit.log_catalog

निर्दिष्ट करता है कि सत्र लॉगिंग उस स्थिति में सक्षम होनी चाहिए जहां किसी कथन में सभी संबंध pg_catalog में हों। इस सेटिंग को अक्षम करने से psql और PgAdmin जैसे टूल्स से लॉग में शोर कम होगा जो कैटलॉग पर भारी मात्रा में क्वेरी करते हैं।

डिफ़ॉल्ट on है।

pgaudit.log_client

निर्दिष्ट करता है कि लॉग संदेश psql जैसी क्लाइंट प्रक्रिया के लिए दृश्यमान होंगे या नहीं। यह सेटिंग आम तौर पर अक्षम रहनी चाहिए लेकिन डिबगिंग या अन्य उद्देश्यों के लिए उपयोगी हो सकती है।

ध्यान दें कि pgaudit.log_level केवल तभी सक्षम होता है जब pgaudit.log_client on हो।

डिफ़ॉल्ट off है।

pgaudit.log_level

लॉग प्रविष्टियों के लिए उपयोग किए जाने वाले लॉग स्तर को निर्दिष्ट करता है (मान्य स्तरों के लिए देखें संदेश गंभीरता स्तर) लेकिन ध्यान दें कि ERROR, FATAL, और PANIC की अनुमति नहीं है)। यह सेटिंग रिग्रेशन परीक्षण के लिए उपयोग की जाती है और परीक्षण या अन्य उद्देश्यों के लिए अंतिम उपयोगकर्ताओं के लिए भी उपयोगी हो सकती है।

ध्यान दें कि pgaudit.log_level केवल तभी सक्षम होता है जब pgaudit.log_client on हो; अन्यथा डिफ़ॉल्ट का उपयोग किया जाएगा।

डिफ़ॉल्ट log है।

pgaudit.log_parameter

निर्दिष्ट करता है कि ऑडिट लॉगिंग में कथन के साथ पास किए गए पैरामीटर शामिल होने चाहिए। जब पैरामीटर मौजूद होते हैं तो वे कथन टेक्स्ट के बाद CSV प्रारूप में शामिल होंगे।

डिफ़ॉल्ट off है।

pgaudit.log_parameter_max_size

निर्दिष्ट करता है कि इस सेटिंग (बाइट्स में) से अधिक लंबे पैरामीटर मानों को लॉग नहीं किया जाना चाहिए, बल्कि <long param suppressed> से बदल दिया जाना चाहिए। यह बाइट्स में सेट किया गया है, वर्णों में नहीं, इसलिए टेक्स्ट पैरामीटर के एन्कोडिंग में मल्टी-बाइट वर्णों का हिसाब नहीं रखता है। यदि log_parameter off है तो इस सेटिंग का कोई प्रभाव नहीं पड़ता है। यदि यह सेटिंग 0 (डिफ़ॉल्ट) है, तो लंबाई की परवाह किए बिना सभी पैरामीटर लॉग किए जाते हैं।

डिफ़ॉल्ट 0 है।

pgaudit.log_relation

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

डिफ़ॉल्ट off है।

pgaudit.log_rows

निर्दिष्ट करता है कि ऑडिट लॉगिंग में किसी कथन द्वारा प्राप्त या प्रभावित पंक्तियों की संख्या शामिल होनी चाहिए। जब सक्षम होता है तो पंक्ति फ़ील्ड पैरामीटर फ़ील्ड के बाद शामिल होगी।

डिफ़ॉल्ट off है।

pgaudit.log_statement

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

डिफ़ॉल्ट on है।

pgaudit.log_statement_once

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

डिफ़ॉल्ट off है।

pgaudit.role

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

कोई डिफ़ॉल्ट नहीं है।

सत्र ऑडिट लॉगिंग

सत्र ऑडिट लॉगिंग बैकएंड में उपयोगकर्ता द्वारा निष्पादित सभी कथनों का विस्तृत लॉग प्रदान करती है।

कॉन्फ़िगरेशन

सत्र लॉगिंग pgaudit.log सेटिंग से सक्षम होती है।

सभी DML और DDL के लिए सत्र लॉगिंग सक्षम करें और DML कथनों में सभी संबंधों को लॉग करें:

set pgaudit.log = 'write, ddl';
set pgaudit.log_relation = on;

MISC को छोड़कर सभी कमांड के लिए सत्र लॉगिंग सक्षम करें और ऑडिट लॉग संदेशों को NOTICE के रूप में उठाएं:

set pgaudit.log = 'all, -misc';
set pgaudit.log_level = notice;

उदाहरण

इस उदाहरण में सत्र ऑडिट लॉगिंग का उपयोग DDL और SELECT कथनों को लॉग करने के लिए किया जाता है। ध्यान दें कि इन्सर्ट स्टेटमेंट लॉग नहीं किया गया है क्योंकि WRITE वर्ग सक्षम नहीं है।

SQL:

set pgaudit.log = 'read, ddl';

create table account
(
    id int,
    name text,
    password text,
    description text
);

insert into account (id, name, password, description)
             values (1, 'user1', 'HASH1', 'blah, blah');

select *
    from account;

लॉग आउटपुट:

AUDIT: SESSION,1,1,DDL,CREATE TABLE,TABLE,public.account,create table account
(
    id int,
    name text,
    password text,
    description text
);,<not logged>
AUDIT: SESSION,2,1,READ,SELECT,,,select *
    from account,,<not logged>

ऑब्जेक्ट ऑडिट लॉगिंग

ऑब्जेक्ट ऑडिट लॉगिंग उन कथनों को लॉग करती है जो किसी विशेष संबंध को प्रभावित करते हैं। केवल SELECT, INSERT, UPDATE और DELETE कमांड समर्थित हैं। TRUNCATE ऑब्जेक्ट ऑडिट लॉगिंग में शामिल नहीं है।

ऑब्जेक्ट ऑडिट लॉगिंग का उद्देश्य pgaudit.log = 'read, write' का एक अधिक सूक्ष्म-स्तरीय प्रतिस्थापन होना है। इस प्रकार, उन्हें एक साथ उपयोग करना समझ में नहीं आ सकता है लेकिन एक संभावित परिदृश्य प्रत्येक कथन को कैप्चर करने के लिए सत्र लॉगिंग का उपयोग करना और फिर विशिष्ट संबंधों के बारे में अधिक विवरण प्राप्त करने के लिए इसे ऑब्जेक्ट लॉगिंग के साथ पूरक करना होगा।

कॉन्फ़िगरेशन

ऑब्जेक्ट-स्तरीय ऑडिट लॉगिंग भूमिका प्रणाली के माध्यम से कार्यान्वित की जाती है। pgaudit.role सेटिंग उस भूमिका को परिभाषित करती है जिसका उपयोग ऑडिट लॉगिंग के लिए किया जाएगा। एक संबंध (TABLE, VIEW, आदि) ऑडिट लॉग किया जाएगा जब ऑडिट भूमिका के पास निष्पादित कमांड के लिए अनुमतियाँ हों या किसी अन्य भूमिका से अनुमतियाँ विरासत में मिली हों। यह आपको प्रभावी रूप से कई ऑडिट भूमिकाएँ रखने की अनुमति देता है, भले ही किसी भी संदर्भ में एक ही मास्टर भूमिका हो।

pgaudit.role को auditor पर सेट करें और account तालिका पर SELECT और DELETE विशेषाधिकार प्रदान करें। account तालिका पर कोई भी SELECT या DELETE कथन अब लॉग किया जाएगा:

set pgaudit.role = 'auditor';

grant select, delete
   on public.account
   to auditor;

उदाहरण

इस उदाहरण में ऑब्जेक्ट ऑडिट लॉगिंग का उपयोग यह दर्शाने के लिए किया गया है कि SELECT और DML कथनों की लॉगिंग के प्रति एक दानेदार दृष्टिकोण कैसे अपनाया जा सकता है। ध्यान दें कि account तालिका पर लॉगिंग कॉलम-स्तरीय अनुमतियों द्वारा नियंत्रित होती है, जबकि account_role_map तालिका पर लॉगिंग तालिका-स्तरीय है।

SQL:

set pgaudit.role = 'auditor';

create table account
(
    id int,
    name text,
    password text,
    description text
);

grant select (password)
   on public.account
   to auditor;

select id, name
  from account;

select password
  from account;

grant update (name, password)
   on public.account
   to auditor;

update account
   set description = 'yada, yada';

update account
   set password = 'HASH2';

create table account_role_map
(
    account_id int,
    role_id int
);

grant select
   on public.account_role_map
   to auditor;

select account.password,
       account_role_map.role_id
  from account
       inner join account_role_map
            on account.id = account_role_map.account_id

लॉग आउटपुट:

AUDIT: OBJECT,1,1,READ,SELECT,TABLE,public.account,select password
  from account,<not logged>
AUDIT: OBJECT,2,1,WRITE,UPDATE,TABLE,public.account,update account
   set password = 'HASH2',<not logged>
AUDIT: OBJECT,3,1,READ,SELECT,TABLE,public.account,select account.password,
       account_role_map.role_id
  from account
       inner join account_role_map
            on account.id = account_role_map.account_id,<not logged>
AUDIT: OBJECT,3,1,READ,SELECT,TABLE,public.account_role_map,select account.password,
       account_role_map.role_id
  from account
       inner join account_role_map
            on account.id = account_role_map.account_id,<not logged>

प्रारूप

ऑडिट प्रविष्टियाँ मानक लॉगिंग सुविधा में लिखी जाती हैं और अल्पविराम-पृथक प्रारूप में निम्नलिखित कॉलम होते हैं। आउटपुट तभी अनुरूप CSV प्रारूप है जब प्रत्येक लॉग प्रविष्टि के लॉग लाइन उपसर्ग भाग को हटा दिया जाता है।

• AUDIT_TYPE - SESSION या OBJECT।

• STATEMENT_ID - इस सत्र के लिए अद्वितीय कथन आईडी। प्रत्येक कथन आईडी एक बैकएंड कॉल का प्रतिनिधित्व करती है। कथन आईडी अनुक्रमिक होती हैं भले ही कुछ कथन लॉग न किए गए हों। एक कथन आईडी के लिए कई प्रविष्टियाँ हो सकती हैं जब एक से अधिक संबंध लॉग किए जाते हैं।

• SUBSTATEMENT_ID - मुख्य कथन के भीतर प्रत्येक उप-कथन के लिए अनुक्रमिक आईडी। उदाहरण के लिए, क्वेरी से किसी फ़ंक्शन को कॉल करना। उप-कथन आईडी निरंतर होती हैं भले ही कुछ उप-कथन लॉग न किए गए हों। एक उप-कथन आईडी के लिए कई प्रविष्टियाँ हो सकती हैं जब एक से अधिक संबंध लॉग किए जाते हैं।

• CLASS - जैसे READ, ROLE (देखें pgaudit.log)।

• COMMAND - जैसे ALTER TABLE, SELECT।

• OBJECT_TYPE - TABLE, INDEX, VIEW, आदि। SELECT, DML और अधिकांश DDL कथनों के लिए उपलब्ध।

• OBJECT_NAME - पूर्ण-योग्य ऑब्जेक्ट नाम (जैसे public.account)। SELECT, DML और अधिकांश DDL कथनों के लिए उपलब्ध।

• STATEMENT - बैकएंड पर निष्पादित कथन।

• PARAMETER - यदि pgaudit.log_parameter सेट है तो इस फ़ील्ड में उद्धृत CSV के रूप में कथन पैरामीटर होंगे या यदि कोई पैरामीटर नहीं हैं तो <none> होगा। अन्यथा, फ़ील्ड <not logged> है।

अपनी ऑडिट लॉग आवश्यकताओं को संतुष्ट करने के लिए आवश्यक किसी भी अन्य फ़ील्ड को जोड़ने के लिए log_line_prefix का उपयोग करें। एक विशिष्ट लॉग लाइन उपसर्ग '%m %u %d [%p]: ' हो सकता है जो प्रत्येक ऑडिट लॉग के लिए दिनांक/समय, उपयोगकर्ता नाम, डेटाबेस नाम और प्रक्रिया आईडी प्रदान करेगा।

सावधानियाँ

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

ऑब्जेक्ट का नाम बदलने पर उस नाम के तहत लॉग किया जाता है जिसमें उसका नाम बदला गया है। उदाहरण के लिए, किसी तालिका का नाम बदलने पर निम्नलिखित परिणाम प्राप्त होगा:

ALTER TABLE test RENAME TO test2;

AUDIT: SESSION,36,1,DDL,ALTER TABLE,TABLE,public.test2,ALTER TABLE test RENAME TO test2,<not logged>

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

Autovacuum और Autoanalyze लॉग नहीं किए जाते हैं।

एक लेन-देन के निरस्त स्थिति में प्रवेश करने के बाद निष्पादित कथनों को ऑडिट लॉग नहीं किया जाएगा। हालांकि, त्रुटि का कारण बनने वाले कथन और निरस्त लेन-देन में निष्पादित कोई भी बाद के कथन मानक लॉगिंग सुविधा द्वारा ERROR के रूप में लॉग किए जाएंगे।

pgAudit के साथ सुपरयूज़रों का विश्वसनीय रूप से ऑडिट करना संभव नहीं है। एक समाधान सुपरयूज़र खातों तक पहुंच को प्रतिबंधित करना और आवश्यकता पड़ने पर अनुमतियों को बढ़ाने के लिए set_user एक्सटेंशन का उपयोग करना है।

लेखक

PostgreSQL ऑडिट एक्सटेंशन 2ndQuadrant pgaudit प्रोजेक्ट पर आधारित है जिसे Simon Riggs, Abhijit Menon-Sen, और Ian Barwick द्वारा लिखा गया था और PostgreSQL कोर में एक एक्सटेंशन के रूप में प्रस्तुत किया गया था। अतिरिक्त विकास Crunchy Data के David Steele द्वारा किया गया है।