Praktik Terbaik Pencatatan Audit PostgreSQL

Di setiap sistem TI tempat tugas bisnis penting berlangsung, penting untuk memiliki serangkaian kebijakan dan praktik yang eksplisit, dan untuk memastikan kebijakan dan praktik tersebut dihormati dan diikuti.

Pengantar Audit

Audit sistem Teknologi Informasi adalah pemeriksaan kebijakan, proses, prosedur, dan praktik organisasi mengenai infrastruktur TI terhadap serangkaian tujuan tertentu. Audit TI dapat terdiri dari dua jenis umum:

• Memeriksa serangkaian standar pada sebagian data yang terbatas
• Memeriksa seluruh sistem

Audit TI dapat mencakup bagian sistem penting tertentu, seperti yang terkait dengan data keuangan untuk mendukung serangkaian peraturan tertentu (misalnya SOX), atau seluruh infrastruktur keamanan terhadap peraturan seperti peraturan GDPR UE baru yang membahas kebutuhan untuk melindungi privasi dan menetapkan pedoman untuk pengelolaan data pribadi. Contoh SOX adalah dari tipe sebelumnya yang dijelaskan di atas sedangkan GDPR adalah tipe yang terakhir.

Siklus Proses Audit

Perencanaan

Cakupan audit tergantung pada tujuan audit. Cakupannya dapat mencakup aplikasi khusus yang diidentifikasi oleh aktivitas bisnis tertentu, seperti aktivitas keuangan, atau seluruh infrastruktur TI yang mencakup keamanan sistem, keamanan data, dan sebagainya. Ruang lingkup harus diidentifikasi dengan benar sebelumnya sebagai langkah awal dalam fase perencanaan awal. Organisasi seharusnya memberikan kepada auditor semua informasi latar belakang yang diperlukan untuk membantu perencanaan audit. Ini mungkin spesifikasi fungsional/teknis, diagram arsitektur sistem, atau informasi lain yang diminta.

Tujuan Kontrol

Berdasarkan ruang lingkup, auditor membentuk satu set tujuan pengendalian untuk diuji oleh audit. Tujuan pengendalian tersebut diimplementasikan melalui praktik manajemen yang seharusnya ada untuk mencapai pengendalian sejauh yang dijelaskan oleh ruang lingkup. Tujuan pengendalian dikaitkan dengan rencana pengujian dan bersama-sama membentuk program audit. Berdasarkan program audit organisasi yang diaudit mengalokasikan sumber daya untuk memfasilitasi auditor.

Temuan

Auditor mencoba untuk mendapatkan bukti bahwa semua tujuan pengendalian terpenuhi. Jika untuk beberapa tujuan pengendalian tidak ada bukti seperti itu, pertama-tama auditor mencoba untuk melihat apakah ada beberapa cara alternatif yang digunakan perusahaan untuk menangani tujuan pengendalian tertentu, dan jika ada cara seperti itu maka tujuan pengendalian ini ditandai sebagai kompensasi. dan auditor mempertimbangkan bahwa tujuan tersebut tercapai. Namun, jika tidak ada bukti sama sekali bahwa tujuan tercapai, maka ini ditandai sebagai temuan . Setiap temuan terdiri dari kondisi, kriteria, sebab, akibat dan rekomendasi. Manajer TI harus berhubungan dekat dengan auditor untuk diberitahu tentang semua temuan potensial dan memastikan bahwa semua informasi yang diminta dibagikan antara manajemen dan auditor untuk memastikan bahwa tujuan pengendalian terpenuhi (dan dengan demikian menghindari temuan).

Laporan Penilaian

Pada akhir proses audit, auditor akan menulis laporan penilaian sebagai ringkasan yang mencakup semua bagian penting dari audit, termasuk setiap temuan potensial yang diikuti dengan pernyataan apakah tujuan tersebut telah ditangani secara memadai dan rekomendasi untuk menghilangkan dampak temuan tersebut.

Apa itu Audit Logging dan Mengapa Anda Harus Melakukannya?

Auditor ingin memiliki akses penuh ke perubahan pada perangkat lunak, data, dan sistem keamanan. Dia tidak hanya ingin dapat melacak setiap perubahan pada data bisnis, tetapi juga melacak perubahan pada bagan organisasi, kebijakan keamanan, definisi peran/grup, dan perubahan peran/keanggotaan grup. Cara paling umum untuk melakukan audit adalah melalui logging. Meskipun di masa lalu dimungkinkan untuk lulus audit TI tanpa file log, hari ini adalah cara yang lebih disukai (jika bukan satu-satunya).

Biasanya sistem TI rata-rata terdiri dari setidaknya dua lapisan:

• Basis Data
• Aplikasi (mungkin di atas server aplikasi)

Aplikasi memelihara lognya sendiri yang mencakup akses dan tindakan pengguna, dan database dan mungkin sistem server aplikasi memelihara log mereka sendiri. Informasi yang bersih dan siap digunakan dalam file log yang memiliki nilai bisnis nyata dari perspektif auditor disebut jejak audit . Jejak audit berbeda dari file log biasa (terkadang disebut log asli) karena:

• File log dapat dibuang
• Jejak audit harus disimpan untuk waktu yang lebih lama
• File log menambahkan overhead ke sumber daya sistem
• Tujuan file log adalah untuk membantu admin sistem
• Tujuan jejak audit adalah untuk membantu auditor

Kami merangkum hal di atas dalam tabel berikut:

Log aplikasi dapat dengan mudah disesuaikan untuk digunakan sebagai jejak audit. Log sistem tidak begitu mudah karena:

• Formatnya dibatasi oleh perangkat lunak sistem
• Mereka bertindak secara global di seluruh sistem
• Mereka tidak memiliki pengetahuan langsung tentang konteks bisnis tertentu
• Mereka biasanya memerlukan perangkat lunak tambahan untuk penguraian/pemrosesan offline nanti guna menghasilkan jejak audit yang dapat digunakan untuk audit.

Namun di sisi lain, log Aplikasi menempatkan lapisan perangkat lunak tambahan di atas data aktual, dengan demikian:

• Membuat sistem audit lebih rentan terhadap bug aplikasi/salah konfigurasi
• Membuat lubang potensial dalam proses logging jika seseorang mencoba mengakses data secara langsung di database melewati sistem logging aplikasi, seperti pengguna yang memiliki hak istimewa atau DBA
• Membuat sistem audit lebih kompleks dan lebih sulit untuk dikelola dan dipelihara jika kita memiliki banyak aplikasi atau banyak tim perangkat lunak.

Jadi, idealnya kami akan mencari yang terbaik dari keduanya:Memiliki jejak audit yang dapat digunakan dengan cakupan terbesar di seluruh sistem termasuk lapisan basis data, dan dapat dikonfigurasi di satu tempat, sehingga logging itu sendiri dapat dengan mudah diaudit dengan cara lain ( sistem) log.

Audit Logging dengan PostgreSQL

Opsi yang kami miliki di PostgreSQL terkait logging audit adalah sebagai berikut:

• Dengan menggunakan pencatatan yang lengkap ( log_statement =all )
• Dengan menulis solusi pemicu khusus
• Dengan menggunakan alat PostgreSQL standar yang disediakan oleh komunitas, seperti
  • audit-trigger 91plus (https://github.com/2ndQuadrant/audit-trigger)
  • ekstensi pgaudit (https://github.com/pgaudit/pgaudit)

Pencatatan log yang lengkap setidaknya untuk penggunaan standar dalam beban kerja OLTP atau OLAP harus dihindari karena:

• Menghasilkan file besar, menambah beban
• Tidak memiliki pengetahuan internal tentang tabel yang sedang diakses atau dimodifikasi, hanya mencetak pernyataan yang mungkin berupa blok DO dengan pernyataan gabungan yang samar
• Membutuhkan perangkat lunak/sumber daya tambahan untuk penguraian dan pemrosesan offline (untuk menghasilkan jejak audit) yang pada gilirannya harus disertakan dalam ruang lingkup audit, agar dianggap dapat dipercaya

Di sisa artikel ini kami akan mencoba alat yang disediakan oleh komunitas. Misalkan kita memiliki tabel sederhana yang ingin kita audit:

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)

pemicu audit 91plus

Dokumen tentang penggunaan pemicu dapat ditemukan di sini:https://wiki.postgresql.org/wiki/Audit_trigger_91plus. Pertama kita download dan install DDL (fungsi, skema) yang disediakan:

$ 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

Kemudian kami mendefinisikan pemicu untuk pesanan tabel kami menggunakan penggunaan dasar:

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

Ini akan membuat dua pemicu pada urutan tabel:pemicu baris insert_update_delere dan pemicu pernyataan truncate. Sekarang mari kita lihat apa yang dilakukan pemicunya:

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    |

Perhatikan nilai change_fields pada Pembaruan (REKAM 2). Ada penggunaan pemicu audit yang lebih lanjut, seperti mengecualikan kolom, atau menggunakan klausa WHEN seperti yang ditunjukkan dalam dokumen. Pemicu audit tampaknya melakukan pekerjaan menciptakan jejak audit yang berguna di dalam tabel audit.logged_actions. Namun ada beberapa peringatan:

• Tidak ada SELECT (pemicu tidak diaktifkan pada SELECT) atau DDL dilacak
• Perubahan oleh pemilik tabel dan pengguna super dapat dengan mudah diubah
• Praktik terbaik harus diikuti terkait pengguna aplikasi serta pemilik skema dan tabel aplikasi

Pgaudit

Pgaudit adalah tambahan terbaru untuk PostgreSQL sejauh menyangkut audit. Pgaudit harus diinstal sebagai ekstensi, seperti yang ditunjukkan di halaman github proyek:https://github.com/pgaudit/pgaudit. Log Pgaudit di log PostgreSQL standar. Pgaudit bekerja dengan mendaftarkan dirinya saat modul dimuat dan menyediakan kait untuk executorStart, executorCheckPerms, processUtility dan object_access. Oleh karena itu pgaudit (berbeda dengan solusi berbasis pemicu seperti pemicu audit yang dibahas dalam paragraf sebelumnya) mendukung READ (PILIH, SALIN). Umumnya dengan pgaudit kita dapat memiliki dua mode operasi atau menggunakannya secara gabungan:

• Pencatatan audit SESI
• Pencatatan audit OBJEK

Logging audit sesi mendukung sebagian besar perintah DML, DDL, hak istimewa, dan misc melalui kelas:

• BACA (pilih, salin dari)
• MENULIS (menyisipkan, memperbarui, menghapus, memotong, menyalin ke)
• FUNCTION (panggilan fungsi dan blok DO)
• PERAN (beri, cabut, buat/ubah/hapus peran)
• DDL (semua DDL kecuali yang ada di ROLE)
• MISC (buang, ambil, pos pemeriksaan, vakum)

Metaclass "semua" mencakup semua kelas. - tidak termasuk kelas. Misalnya, mari kita konfigurasikan logging audit Sesi untuk semua kecuali MISC, dengan parameter GUC berikut di postgresql.conf:

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

Dengan memberikan perintah berikut (sama seperti pada contoh pemicu)

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=#

Kami mendapatkan entri berikut di log 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>

Perhatikan bahwa teks setelah AUDIT:merupakan jejak audit yang sempurna, hampir siap untuk dikirim ke auditor dalam format csv yang siap-spreadsheet. Menggunakan logging audit sesi akan memberi kami entri log audit untuk semua operasi milik kelas yang ditentukan oleh parameter pgaudit.log di semua tabel. Namun ada kasus yang kami inginkan hanya sebagian kecil dari data yaitu hanya beberapa tabel yang akan diaudit. Dalam kasus seperti itu, kami mungkin lebih memilih logging audit objek yang memberi kami kriteria berbutir halus daripada tabel/kolom yang dipilih melalui sistem hak istimewa PostgreSQL. Untuk mulai menggunakan Object audit logging, pertama-tama kita harus mengonfigurasi parameter pgaudit.role yang mendefinisikan peran master yang akan digunakan pgaudit. Masuk akal untuk tidak memberikan hak login apa pun kepada pengguna ini.

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

Kami menentukan nilai ini untuk pgaudit.role di postgresql.conf:

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

Pgaudit OBJECT logging akan bekerja dengan mencari apakah pengguna auditor diberikan (secara langsung atau diwariskan) hak untuk melakukan tindakan tertentu yang dilakukan pada relasi/kolom yang digunakan dalam sebuah pernyataan. Jadi jika kita perlu mengabaikan semua tabel, tetapi memiliki pencatatan rinci ke urutan tabel, inilah caranya:

grant ALL on orders to auditor ;

Dengan hibah di atas, kami mengaktifkan SELECT, INSERT, UPDATE, dan DELETE logging penuh pada pesanan tabel. Mari kita berikan sekali lagi INSERT, UPDATE, DELETE dari contoh sebelumnya dan perhatikan log 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>

Kami mengamati bahwa output identik dengan logging SESSION yang dibahas di atas dengan perbedaan bahwa alih-alih SESSION sebagai jenis audit (string di sebelah AUDIT:) sekarang kami mendapatkan OBJECT.

Satu peringatan dengan OBJECT logging adalah bahwa TRUNCATE tidak dicatat. Kita harus menggunakan SESSION logging untuk ini. Tetapi dalam kasus ini kami akhirnya mendapatkan semua aktivitas MENULIS untuk semua tabel. Ada pembicaraan di antara para peretas yang terlibat untuk membuat setiap perintah menjadi kelas yang terpisah.

Hal lain yang perlu diingat adalah bahwa dalam kasus pewarisan jika kita MEMBERIKAN akses ke auditor pada beberapa tabel anak, dan bukan orang tua, tindakan pada tabel induk yang diterjemahkan ke tindakan pada baris tabel anak tidak akan dicatat.

Selain hal di atas, orang TI yang bertanggung jawab atas integritas log harus mendokumentasikan prosedur yang ketat dan terdefinisi dengan baik yang mencakup ekstraksi jejak audit dari file log PostgreSQL. Log tersebut mungkin dialirkan ke server syslog aman eksternal untuk meminimalkan kemungkinan gangguan atau gangguan.

Ringkasan

Kami harap blog ini membantu Anda lebih memahami praktik terbaik untuk log audit di PostgreSQL dan mengapa membuat jejak audit sangat penting dalam mempersiapkan audit TI. Jejak audit akan memberikan serangkaian informasi yang bersih dan dapat digunakan yang akan membantu audit Anda berjalan dengan lancar.

ClusterControl dapat membantu mengotomatiskan dan mengelola sebagian besar tugas terkait database sambil memastikan keamanan, ketersediaan, dan kinerja database — terlepas dari sistem yang Anda pilih. Unduh uji coba gratis ClusterControl hari ini untuk melihat bagaimana bisnis Anda dapat memperoleh manfaat dari alat dan operasi yang dijalankannya. Jika Anda belum melakukannya, pastikan untuk mengikuti kami di Twitter dan LinkedIn, dan berlangganan feed kami, dan sampai jumpa di blog berikutnya.