PostgreSQL ऑडिट लॉगिंग सर्वोत्तम अभ्यास

प्रत्येक आईटी प्रणाली में जहां महत्वपूर्ण व्यावसायिक कार्य होते हैं, नीतियों और प्रथाओं का एक स्पष्ट सेट होना और यह सुनिश्चित करना महत्वपूर्ण है कि उनका सम्मान किया जाता है और उनका पालन किया जाता है।

ऑडिटिंग का परिचय

एक सूचना प्रौद्योगिकी प्रणाली ऑडिट एक निश्चित उद्देश्यों के खिलाफ आईटी बुनियादी ढांचे के संबंध में एक संगठन की नीतियों, प्रक्रियाओं, प्रक्रियाओं और प्रथाओं की परीक्षा है। एक आईटी ऑडिट दो सामान्य प्रकार का हो सकता है:

• डेटा के सीमित सबसेट पर मानकों के एक सेट के विरुद्ध जाँच करना
• पूरे सिस्टम की जांच की जा रही है

एक आईटी ऑडिट कुछ महत्वपूर्ण सिस्टम भागों को कवर कर सकता है, जैसे कि वित्तीय डेटा से संबंधित नियमों के एक विशिष्ट सेट (जैसे एसओएक्स) का समर्थन करने के लिए, या नए ईयू जीडीपीआर विनियमन जैसे नियमों के खिलाफ संपूर्ण सुरक्षा आधारभूत संरचना जो आवश्यकता को संबोधित करती है गोपनीयता की रक्षा के लिए और व्यक्तिगत डेटा प्रबंधन के लिए दिशानिर्देश निर्धारित करता है। SOX उदाहरण ऊपर वर्णित पूर्व प्रकार का है जबकि GDPR बाद वाला है।

ऑडिट जीवनचक्र

योजना बनाना

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

नियंत्रण उद्देश्य

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

निष्कर्ष

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

आकलन रिपोर्ट

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

ऑडिट लॉगिंग क्या है और आपको इसे क्यों करना चाहिए?

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

आम तौर पर औसत आईटी प्रणाली में कम से कम दो परतें होती हैं:

• डेटाबेस
• एप्लिकेशन (संभवतः किसी एप्लिकेशन सर्वर के शीर्ष पर)

एप्लिकेशन उपयोगकर्ता की पहुंच और कार्यों को कवर करने वाले अपने स्वयं के लॉग रखता है, और डेटाबेस और संभवतः एप्लिकेशन सर्वर सिस्टम अपने स्वयं के लॉग बनाए रखता है। लॉग फाइलों में साफ, आसानी से उपयोग की जा सकने वाली जानकारी जिसका ऑडिटर के नजरिए से वास्तविक व्यावसायिक मूल्य है, उसे ऑडिट ट्रेल कहा जाता है। . ऑडिट ट्रेल्स सामान्य लॉग फ़ाइलों (कभी-कभी नेटिव लॉग कहलाते हैं) से भिन्न होते हैं:

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

हम उपरोक्त को निम्न तालिका में सारांशित करते हैं:

ऐप लॉग को ऑडिट ट्रेल्स के रूप में उपयोग करने के लिए आसानी से तैयार किया जा सकता है। सिस्टम लॉग इतनी आसानी से नहीं होता क्योंकि:

• सिस्टम सॉफ़्टवेयर द्वारा वे अपने प्रारूप में सीमित हैं
• वे पूरे सिस्टम पर विश्व स्तर पर कार्य करते हैं
• उन्हें विशिष्ट व्यावसायिक संदर्भ के बारे में प्रत्यक्ष जानकारी नहीं है
• आम तौर पर उन्हें बाद में ऑफ़लाइन पार्सिंग/प्रसंस्करण के लिए अतिरिक्त सॉफ़्टवेयर की आवश्यकता होती है ताकि उपयोगी ऑडिट-अनुकूल ऑडिट ट्रेल्स तैयार किए जा सकें।

हालाँकि दूसरी ओर ऐप लॉग वास्तविक डेटा के ऊपर एक अतिरिक्त सॉफ़्टवेयर परत डालते हैं, इस प्रकार:

• एप्लिकेशन बग/गलत कॉन्फ़िगरेशन के लिए ऑडिट सिस्टम को अधिक संवेदनशील बनाना
• लॉगिंग प्रक्रिया में एक संभावित छेद बनाना अगर कोई ऐप लॉगिंग सिस्टम, जैसे कि एक विशेषाधिकार प्राप्त उपयोगकर्ता या डीबीए को छोड़कर सीधे डेटाबेस पर डेटा तक पहुंचने का प्रयास करता है
• यदि हमारे पास कई एप्लिकेशन या कई सॉफ़्टवेयर टीमें हैं, तो ऑडिट सिस्टम को अधिक जटिल और प्रबंधन और रखरखाव के लिए कठिन बनाना।

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

PostgreSQL के साथ ऑडिट लॉगिंग

पोस्टग्रेएसक्यूएल में ऑडिट लॉगिंग के संबंध में हमारे पास निम्नलिखित विकल्प हैं:

• संपूर्ण लॉगिंग का उपयोग करके ( log_statement =all )
• एक कस्टम ट्रिगर समाधान लिखकर
• समुदाय द्वारा प्रदान किए गए मानक PostgreSQL टूल का उपयोग करके, जैसे कि
  • ऑडिट-ट्रिगर 91प्लस (https://github.com/2ndQuadrant/audit-trigger)
  • pgaudit एक्सटेंशन (https://github.com/pgaudit/pgaudit)

OLTP या OLAP वर्कलोड में कम से कम मानक उपयोग के लिए व्यापक लॉगिंग से बचा जाना चाहिए क्योंकि:

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

इस लेख के बाकी हिस्सों में हम समुदाय द्वारा प्रदान किए गए टूल का प्रयास करेंगे। मान लीजिए कि हमारे पास यह सरल तालिका है जिसे हम ऑडिट करना चाहते हैं:

myshop=# \d orders
                                       Table "public.orders"
   Column   |           Type           | Collation | Nullable |              Default               
------------+--------------------------+-----------+----------+------------------------------------
 id         | integer                  |           | not null | nextval('orders_id_seq'::regclass)
 customerid | integer                  |           | not null |
 customer   | text                     |           | not null |
 xtime      | timestamp with time zone   |           | not null | now()
 productid  | integer                  |           | not null |
 product    | text                     |           | not null |
 quantity   | integer                  |           | not null |
 unit_price | double precision         |           | not null |
 cur        | character varying(20)    |           | not null | 'EUR'::character varying
Indexes:
    "orders_pkey" PRIMARY KEY, btree (id)

ऑडिट-ट्रिगर 91plus

ट्रिगर का उपयोग करने के बारे में दस्तावेज़ यहां देखे जा सकते हैं:https://wiki.postgresql.org/wiki/Audit_trigger_91plus। सबसे पहले हम प्रदान किए गए डीडीएल (फ़ंक्शंस, स्कीमा) को डाउनलोड और इंस्टॉल करते हैं:

$ wget https://raw.githubusercontent.com/2ndQuadrant/audit-trigger/master/audit.sql
$ psql myshop
psql (10.3 (Debian 10.3-1.pgdg80+1))
Type "help" for help.
myshop=# \i audit.sql

फिर हम अपनी तालिका आदेश . के लिए ट्रिगर्स को परिभाषित करते हैं मूल उपयोग का उपयोग करना:

myshop=# SELECT audit.audit_table('orders');

यह टेबल ऑर्डर पर दो ट्रिगर बनाएगा:एक insert_update_delere पंक्ति ट्रिगर और एक छोटा कथन ट्रिगर। अब देखते हैं कि ट्रिगर क्या करता है:

myshop=# insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);      
INSERT 0 1
myshop=# update orders set quantity=3 where id=2;
UPDATE 1
myshop=# delete from orders  where id=2;
DELETE 1
myshop=# select table_name, action, session_user_name, action_tstamp_clk, row_data, changed_fields from audit.logged_actions;
-[ RECORD 1 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name        | orders
action            | I
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:15:10.887268+03
row_data          | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"2", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields    |
-[ RECORD 2 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name        | orders
action            | U
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:16:12.829065+03
row_data          | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"2", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields    | "quantity"=>"3"
-[ RECORD 3 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name        | orders
action            | D
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:16:24.944117+03
row_data          | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"3", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields    |

अद्यतन (रिकॉर्ड 2) पर change_fields मान नोट करें। ऑडिट ट्रिगर के अधिक उन्नत उपयोग हैं, जैसे कॉलम को बाहर करना, या WHEN क्लॉज का उपयोग करना जैसा कि दस्तावेज़ में दिखाया गया है। ऑडिट ट्रिगर निश्चित रूप से ऑडिट.लॉग्ड_एक्शन टेबल के अंदर उपयोगी ऑडिट ट्रेल्स बनाने का काम करता है। हालांकि कुछ चेतावनी हैं:

• कोई चयन नहीं (चयनों पर ट्रिगर सक्रिय नहीं होते) या DDL ट्रैक किए जाते हैं
• टेबल मालिकों और सुपर उपयोगकर्ताओं द्वारा किए गए परिवर्तनों में आसानी से छेड़छाड़ की जा सकती है
• ऐप उपयोगकर्ता(उपयोगकर्ताओं) और ऐप स्कीमा और टेबल मालिकों के संबंध में सर्वोत्तम प्रथाओं का पालन किया जाना चाहिए

पगौडिट

जहां तक ​​ऑडिटिंग का सवाल है, Pgaudit PostgreSQL का सबसे नया जोड़ है। Pgaudit को एक एक्सटेंशन के रूप में स्थापित किया जाना चाहिए, जैसा कि प्रोजेक्ट के github पेज में दिखाया गया है:https://github.com/pgaudit/pgaudit। Pgaudit मानक PostgreSQL लॉग में लॉग करता है। Pgaudit मॉड्यूल लोड पर खुद को पंजीकृत करके और एक्ज़ीक्यूटर स्टार्ट, एक्ज़ीक्यूटर चेकपर्म, प्रोसेस यूटिलिटी और ऑब्जेक्ट_एक्सेस के लिए हुक प्रदान करके काम करता है। इसलिए pgaudit (पिछले पैराग्राफ में चर्चा किए गए ऑडिट-ट्रिगर जैसे ट्रिगर-आधारित समाधानों के विपरीत) READs (SELECT, COPY) का समर्थन करता है। आम तौर पर pgaudit के साथ हमारे पास संचालन के दो तरीके हो सकते हैं या उनका संयुक्त उपयोग कर सकते हैं:

• सत्र ऑडिट लॉगिंग
• ऑब्जेक्ट ऑडिट लॉगिंग

सत्र ऑडिट लॉगिंग कक्षाओं के माध्यम से अधिकांश डीएमएल, डीडीएल, विशेषाधिकार और विविध आदेशों का समर्थन करता है:

• पढ़ें (चुनें, कॉपी करें)
• लिखें (सम्मिलित करें, अपडेट करें, हटाएं, काटें, कॉपी करें)
• FUNCTION (फ़ंक्शन कॉल और DO ब्लॉक)
• भूमिका (भूमिका देना, निरस्त करना, बनाना/बदलना/छोड़ना)
• DDL (ROLE को छोड़कर सभी DDL)
• MISC (छोड़ें, लाएं, चेकपॉइंट, वैक्यूम)

मेटाक्लास "सभी" में सभी वर्ग शामिल हैं। - एक वर्ग को बाहर करता है। उदाहरण के लिए, MISC को छोड़कर सभी के लिए सत्र ऑडिट लॉगिंग कॉन्फ़िगर करें, postgresql.conf में निम्नलिखित GUC मापदंडों के साथ:

pgaudit.log_catalog = off
pgaudit.log = 'all, -misc'
pgaudit.log_relation = 'on'
pgaudit.log_parameter = 'on'

निम्नलिखित आदेश देकर (ट्रिगर उदाहरण के समान)

myshop=# insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);
INSERT 0 1
myshop=# update orders set quantity=3 where id=2;
UPDATE 1
myshop=# delete from orders  where id=2;
DELETE 1
myshop=#

हमें PostgreSQL लॉग में निम्नलिखित प्रविष्टियाँ मिलती हैं:

% tail -f data/log/postgresql-22.log | grep AUDIT:
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:37.352 EEST psql [email protected] line:7 LOG:  AUDIT: SESSION,5,1,WRITE,INSERT,TABLE,public.orders,"insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);",<none>
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:50.120 EEST psql [email protected] line:8 LOG:  AUDIT: SESSION,6,1,WRITE,UPDATE,TABLE,public.orders,update orders set quantity=3 where id=2;,<none>
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:59.888 EEST psql [email protected] line:9 LOG:  AUDIT: SESSION,7,1,WRITE,DELETE,TABLE,public.orders,delete from orders  where id=2;,<none>

ध्यान दें कि AUDIT के बाद का टेक्स्ट:एक संपूर्ण ऑडिट ट्रेल बनाता है, जो स्प्रैडशीट-तैयार csv प्रारूप में ऑडिटर को भेजने के लिए लगभग तैयार है। सत्र ऑडिट लॉगिंग का उपयोग करने से हमें सभी पर pgaudit.log पैरामीटर द्वारा परिभाषित वर्गों से संबंधित सभी कार्यों के लिए ऑडिट लॉग प्रविष्टियां मिलेंगी। टेबल। हालाँकि ऐसे मामले हैं कि हम चाहते हैं कि डेटा का केवल एक छोटा सा उपसमूह यानी केवल कुछ तालिकाओं का ऑडिट किया जाए। ऐसे मामलों में हम ऑब्जेक्ट ऑडिट लॉगिंग को प्राथमिकता दे सकते हैं जो हमें पोस्टग्रेएसक्यूएल के विशेषाधिकार प्रणाली के माध्यम से चयनित टेबल/कॉलम के लिए बढ़िया मानदंड देता है। ऑब्जेक्ट ऑडिट लॉगिंग का उपयोग शुरू करने के लिए हमें पहले pgaudit.role पैरामीटर को कॉन्फ़िगर करना होगा जो उस मास्टर भूमिका को परिभाषित करता है जिसका उपयोग pgaudit करेगा। इस उपयोगकर्ता को कोई लॉगिन अधिकार नहीं देना समझ में आता है।

CREATE ROLE auditor;
ALTER ROLE auditor WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN NOREPLICATION NOBYPASSRLS CONNECTION LIMIT 0;

हम इस मान को postgresql.conf में pgaudit.role के लिए निर्दिष्ट करते हैं:

pgaudit.log = none # no need for extensive SESSION logging
pgaudit.role = auditor

Pgaudit OBJECT लॉगिंग यह पता लगाकर काम करेगी कि क्या उपयोगकर्ता ऑडिटर . है एक बयान में इस्तेमाल किए गए संबंधों/स्तंभों पर की गई निर्दिष्ट कार्रवाई को निष्पादित करने का अधिकार दिया गया है (सीधे या विरासत में मिला)। इसलिए यदि हमें सभी तालिकाओं को अनदेखा करने की आवश्यकता है, लेकिन तालिका आदेशों के लिए विस्तृत लॉगिंग है, तो इसे करने का यह तरीका है:

grant ALL on orders to auditor ;

उपरोक्त अनुदान द्वारा हम टेबल ऑर्डर पर पूर्ण चयन, सम्मिलित करें, अद्यतन करें और हटाएं लॉगिंग सक्षम करते हैं। आइए एक बार फिर पिछले उदाहरणों में INSERT, UPDATE, DELETE दें और postgresql लॉग देखें:

% tail -f data/log/postgresql-22.log | grep AUDIT:
[local] [60683] 5b040125.ed0b 2018-05-22 14:41:41.989 EEST psql [email protected] line:7 LOG:  AUDIT: OBJECT,2,1,WRITE,INSERT,TABLE,public.orders,"insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);",<none>
[local] [60683] 5b040125.ed0b 2018-05-22 14:41:52.269 EEST psql [email protected] line:8 LOG:  AUDIT: OBJECT,3,1,WRITE,UPDATE,TABLE,public.orders,update orders set quantity=3 where id=2;,<none>
[local] [60683] 5b040125.ed0b 2018-05-22 14:42:03.148 EEST psql [email protected] line:9 LOG:  AUDIT: OBJECT,4,1,WRITE,DELETE,TABLE,public.orders,delete from orders  where id=2;,<none>

हम देखते हैं कि आउटपुट ऊपर चर्चा किए गए सत्र लॉगिंग के समान है, इस अंतर के साथ कि सत्र के बजाय ऑडिट प्रकार (ऑडिट:के बगल में स्ट्रिंग) के बजाय अब हमें ऑब्जेक्ट मिलता है।

OBJECT लॉगिंग के साथ एक चेतावनी यह है कि TRUNCATEs लॉग नहीं होते हैं। इसके लिए हमें SESSION लॉगिंग का सहारा लेना होगा। लेकिन इस मामले में हम सभी तालिकाओं के लिए सभी WRITE गतिविधि प्राप्त कर लेते हैं। प्रत्येक कमांड को एक अलग वर्ग बनाने के लिए शामिल हैकर्स के बीच बातचीत चल रही है।

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

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

सारांश

हमें उम्मीद है कि इस ब्लॉग ने आपको पोस्टग्रेएसक्यूएल में ऑडिट लॉगिंग के लिए सर्वोत्तम प्रथाओं को बेहतर ढंग से समझने में मदद की है और आईटी ऑडिट की तैयारी में ऑडिट ट्रेल बनाना इतना महत्वपूर्ण क्यों है। एक ऑडिट ट्रेल स्वच्छ, प्रयोग करने योग्य जानकारी का एक सेट प्रदान करेगा जो आपके ऑडिट को सुचारू रूप से चलाने में मदद करेगा।

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