Keamanan Database Oracle:Audit Database

Pada artikel ini, saya akan melanjutkan dengan Oracle Database Security dan saya akan menyajikan beberapa fakta penting tentang audit database standar, pemicu audit, dan kebijakan audit di Oracle. Audit basis data memiliki dua komponen:pemantauan dan pendaftaran terus-menerus dari rangkaian aktivitas dan peristiwa basis data yang telah ditetapkan. Tujuan dari audit database adalah non-repudiasi, investigasi aktivitas yang mencurigakan, deteksi masalah yang dihasilkan oleh konfigurasi terkait otorisasi (akses sumber daya), kepatuhan terhadap undang-undang dan kontrol yang sebenarnya.

Audit Standar

Kegiatan apa yang kami audit? Pengaktifan dan penghentian basis data serta koneksi yang dibuat oleh administrator basis data secara implisit diaudit oleh Oracle dan data disimpan secara otomatis di sistem operasi. Tabel di bawah ini menunjukkan aktivitas lain yang dapat dipantau:

Di mana kami menyimpan aktivitas yang diaudit?

dalam basis data , menggunakan jejak audit basis data, di mana kita memiliki dua kemungkinan:
- audit_trail =DB
  yang dapat dilakukan dengan kode berikut:
```
alter system set audit_trail=db scope=spfile;
```

- audit_trail =DB,EXTENDED
  menggunakan kode berikut:
```
alter system set audit_trail= db, extended scope=spfile;
```
Perbedaan antara DB dan DB,EXTENDED adalah bahwa yang kedua mengisi kolom SQLBIND dan SQLTEXT CLOB dari tabel SYS.AUD$.

eksternal , menggunakan jejak audit sistem operasi, dengan kemungkinan berikut:
- audit_trail =OS
  dan kode yang digunakan adalah:
```
alter system set audit_trail=os scope=spfile;
```
- audit_trail =XML dan AUDIT_FILE_DEST =path file (secara implisit adalah $ORACLE_BASE/admin/$ORACLE_SID/adump)
  dengan kode:
```
alter system set audit_trail=xml scope=spfile;
```

Untuk menemukan konfigurasi saat ini dari aktivitas yang diaudit yang disimpan, seseorang dapat menjalankan kueri berikut, yang ditulis dengan huruf kecil:

select value from v$parameter where name='audit_trail';

Perintah yang lebih berguna:

[id tabel=43 /]

Sekarang mari kita lihat beberapa contoh audit database.

Berikut adalah contoh audit standar dengan informasi yang telah diaudit disimpan dalam database:

Informasi yang diaudit terdiri dari pernyataan SELECT yang dieksekusi pada tabel database.

Di SQL Developer, jalankan skrip berikut:

alter system set audit_trail= db, extended scope=spfile;
AUDIT SELECT TABLE;

Kemudian, database harus di-restart. Untuk melakukan itu, di terminal SQLPlus, sambungkan dengan nama pengguna sys sebagai sysdba / kata sandi dan jalankan pernyataan berikut:

SHUTDOWN IMMEDIATE
STARTUP

Perhatikan bahwa ukuran di atas berbeda dari satu sistem ke sistem lainnya.

Untuk memverifikasi apakah jejak audit disetel dengan benar, jalankan kueri berikut:

select value from v$parameter where name='audit_trail';

atau:

show parameter audit_trail;

Saat Anda ingin menghentikan audit, jalankan:

NOAUDIT SELECT TABLE;

Untuk melihat pernyataan apa yang dicatat oleh audit, Anda dapat menggunakan:

select dbms_lob.substr( sqltext, 4000, 1 )
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS');

atau

select count(*), OBJ$NAME, USERID
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS')
group by rollup (OBJ$NAME, USERID);

Contoh lain adalah untuk audit standar dengan data yang diaudit disimpan dalam file XML, di jalur standar.

alter system set audit_trail=xml scope=spfile;
AUDIT SELECT, INSERT, UPDATE, DELETE ON employees WHENEVER NOT
SUCCESSFUL;

Sekali lagi, restart database:sambungkan ke terminal SQLPlus dengan username sys sebagai sysdba / password dan jalankan perintah SHUTDOWN IMMEDIATE dan STARTUP.

Kemudian, setiap kali kueri pilih, sisipkan, perbarui, dan hapus gagal di tabel karyawan, itu harus dicatat dalam file XML.

Saat kami ingin menghentikan audit, kami menjalankan perintah berikut di lingkungan pengembangan basis data:

NOAUDIT ALL;
NOAUDIT ALL ON DEFAULT;

Dan pulihkan jejak audit default:

alter system set audit_trail=db scope=spfile;

Di bawah ini adalah contoh bagian dari file audit XML:

Bagaimana cara kami menghapus informasi yang telah diaudit?

Volume data yang diaudit bisa menjadi sangat besar karena banyaknya kegiatan yang diaudit dan frekuensinya. Inilah sebabnya mengapa disarankan untuk mengarsipkan data yang diaudit secara berkala dan menghapusnya dari sistem produksi.

Jika data yang diaudit disimpan dalam database (database audit trail), maka kita dapat menggunakan pernyataan hapus (tetapi hanya setelah kita mengarsipkan datanya!):

DELETE FROM SYS.AUD$;

Anda dapat memilih untuk menghapus informasi yang diaudit untuk objek database tertentu, misalnya, tabel yang disebut produk:

DELETE FROM SYS.AUD$ WHERE OBJ$NAME='PRODUCTS';

Pemicu Audit

Pemicu adalah blok PL/SQL atau pernyataan CALL dari prosedur PL/SQL yang dijalankan secara otomatis setiap kali suatu peristiwa terjadi. Ada dua jenis pemicu:di tingkat basis data (pernyataan basis data) dan di tingkat aplikasi (misalnya menekan tombol pada Formulir Oracle). Pemicu yang digunakan untuk audit adalah pemicu tingkat basis data. Mereka mengklasifikasikan ke dalam kategori berikut:

Pemicu DML – di mana pernyataan DML dipicu di atas meja. Pemicu tersebut dapat dieksekusi sekali pada tingkat perintah terlepas dari jumlah catatan (pemicu pada tingkat pernyataan) atau dapat dieksekusi UNTUK SETIAP ROW (pemicu pada tingkat catatan). Jenis pemicu level rekaman:SEBELUM PERNYATAAN, SETELAH PERNYATAAN, SEBELUM SETIAP ROW, SETELAH SETIAP ROW;
BUKAN pemicu – di mana pernyataan DML dipicu pada tampilan;
Pemicu SISTEM – dipicu oleh peristiwa seperti memulai/menghentikan database, pernyataan DDL, login/logout pengguna. Jenis pemicu sistem:SETELAH ACARA, SEBELUM ACARA.

Membuat kueri SYS.TRIGGER$ tabel atau ALL_TRIGGERS view menawarkan informasi tentang semua pemicu level database. Misalnya, jenis pemicu yang berbeda dari database dapat ditemukan sebagai berikut:

SELECT DISTINCT TRIGGER_TYPE FROM ALL_TRIGGERS;

Tampilan DBA_TRIGGERS menawarkan informasi tentang pemicu yang dibuat secara otomatis oleh produk Oracle saat penginstalan. Jika kita ingin mencari informasi tentang SYSTEM triggers ('BEFORE EVENT' dan 'AFTER EVENT'), kita dapat menjalankan pernyataan berikut:

SELECT SUBSTR(OWNER,1,20) OWNER ,SUBSTR(TRIGGER_NAME,1,30),
TRIGGER_NAME, SUBSTR(TRIGGERING_EVENT,1,30) TRIGGERING_EVENT,
TRIGGER_TYPE
FROM DBA_TRIGGERS
WHERE TRIGGER_TYPE='BEFORE EVENT' OR TRIGGER_TYPE='AFTER EVENT'
ORDER BY TRIGGER_TYPE DESC;

Selain itu, saat penginstalan, pemicu DML dibuat secara otomatis pada skema pengguna HR:

SELECT SUBSTR(TABLE_NAME,1,20) TABLE_NAME,
SUBSTR(TRIGGER_TYPE,1,30) TRIGGER_TYPE,TRIGGER_BODY
FROM DBA_TRIGGERS
WHERE OWNER='HR';

Untuk audit, kita dapat membuat pemicu yang disesuaikan untuk merekam informasi yang diinginkan, tetapi kita harus membuat tabel khusus untuk menyimpan informasi yang telah diaudit.

Penting untuk memastikan bahwa pemicu yang dikembangkan tidak memengaruhi aktivitas database normal. Tujuan audit adalah untuk secara pasif memantau aktivitas database normal sehari-hari dan menyimpannya untuk dianalisis nanti. Akibatnya, tidak disarankan untuk membuat BUKAN pemicu untuk mengembalikan hasil dari tabel target ke tabel audit.

Pemicu DML di tingkat pernyataan dapat berdampingan dengan pemicu DML di tingkat rekaman. Urutan panggilan adalah:

memicu SEBELUM pernyataan
untuk setiap rekaman yang terpengaruh
- memicu SEBELUM merekam
- tindakan DML saat ini
- memicu SETELAH rekaman
memicu pernyataan SETELAH

Pemicu yang ditentukan pengguna akan dieksekusi hanya jika, menurut Oracle, pernyataan itu benar dan dapat terjadi. Untuk pernyataan DML yang salah atau yang melanggar batasan, kesalahan akan dikembalikan dan pemicu tidak akan dieksekusi. Oleh karena itu, untuk audit, disarankan untuk menggunakan pemicu LMD terutama pada tingkat pernyataan.

Contoh pemicu audit:

Mari kita asumsikan kita ingin membuat pemicu untuk mencatat dalam tabel audit (disebut TAB_AUDIT_EMP) informasi tentang pernyataan DML yang menetapkan gaji lebih dari 20.000 (mata uang tidak penting di sini) untuk karyawan perusahaan. Kami ingin menyimpan di TAB_AUDIT_EMP nomor urut kueri, nama pengguna, sesi, host, dan tanggal.

Ini dapat dilakukan dengan yang berikut:

CREATE TABLE TAB_AUDIT_EMP

(secv_id NUMBER(3) PRIMARY KEY,
username VARCHAR2(20),
session_nr NUMBER(10),
hostname VARCHAR2(100),
query_date DATE
);

CREATE SEQUENCE secv_aud_emp START WITH 1 INCREMENT BY 1;
CREATE OR REPLACE TRIGGER huge_salary
AFTER INSERT OR UPDATE OR DELETE OF SALARY ON EMPLOYEES
FOR EACH ROW WHEN (NEW.salary>20000)
BEGIN
INSERT INTO TAB_AUDIT_EMP
VALUES(secv_aud_emp.NEXTVAL , sys_context('userenv', 'session_user'), sys_context('userenv', 'sessionid'), sys_context('userenv', 'host'), sysdate);
END;

Asumsikan kita membuat modifikasi gaji untuk karyawan di departemen tertentu:

UPDATE EMPLOYEES
SET SALARY=25000
WHERE ID_DEPARTMENT = 1;

Dan kemudian kami memverifikasi pemantauan:

select secv_id, substr(username,1,20) username, session_nr, substr(hostname,1,30) hostname, query_date
from TAB_AUDIT_EMP;

Kebijakan audit

Metode audit ketiga mengacu pada kebijakan audit. Definisi kebijakan audit berisi sebagai berikut:

spesifikasi objek (skema, nama objek, kolom) yang dipantau
spesifikasi tindakan yang diaudit untuk suatu objek (SELECT, INSERT, UPDATE, DELETE):secara implisit adalah SELECT
spesifikasi kondisi yang harus dipenuhi untuk merekam informasi yang diaudit, hal itu dilakukan dalam klausa WHEN pada pemicu dan bersifat opsional
penangan acara yang juga menangani acara, yang bersifat opsional.

Kebijakan audit dapat aktif (status AKTIF) atau tidak aktif (status DINONAKTIFKAN). Daftar kebijakan audit dapat diperoleh dengan menginterogasi tampilan ALL_AUDIT_POLICIES:

SELECT POLICY_TEXT, ENABLED
FROM ALL_AUDIT_POLICIES

Untuk administrasi kebijakan audit kami memiliki paket DBMS_FGA. Untuk menggunakan paket ini, perlu memberikan hak istimewa kepada pengguna yang akan menulis kode PL/SQL:

grant execute on dbms_fga to username;

Contoh kebijakan audit:

Kami ingin membuat kebijakan audit untuk merekam pernyataan DML yang mengubah manajer (MANAGER_ID) di tabel DEPARTMENTS. Kita dapat memilih untuk membuat pengendali untuk kebijakan, yang disebut proc_audit_alert, yang menginformasikan kepada kita tentang modifikasi terkait pengelola:

CREATE OR REPLACE PROCEDURE proc_audit_alert ( object_schema VARCHAR2, object_name VARCHAR2, policy_name VARCHAR2 ) AS
BEGIN
DBMS_OUTPUT.PUT_LINE('Alert! Manager Changed !');
END;

Dan kebijakannya dapat berupa:

CREATE OR REPLACE PROCEDURE proc_audit_manager AS
BEGIN
DBMS_FGA.ADD_POLICY
(
object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager',
audit_column=>'ID_MANAGER',
enable=>false,
statement_types=>'UPDATE',
handler_module=>'proc_audit_alert'
);
DBMS_FGA.ENABLE_POLICY
( object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager');
END;

Perhatikan bahwa object_schema, object_name, policy_name, audit_column, statement_types dan handler_module harus disesuaikan dengan kebijakan yang ingin Anda tulis.

Kemudian, kita jalankan prosedurnya:

EXECUTE proc_audit_manager;

Kami dapat memverifikasi jika kebijakan diaktifkan:

SELECT ENABLED, POLICY_NAME
FROM ALL_AUDIT_POLICIES
WHERE OBJECT_NAME='DEPARTMENTS';

Kemudian, verifikasi apakah prosedur dan kebijakan berfungsi dengan benar, dengan menjalankan pembaruan:

UPDATE DEPARTMENTS
SET ID_MANAGER=2
WHERE ID_DEPARTAMENT=1;

Kesimpulannya, audit diperlukan untuk setiap basis data dan metode yang disediakan di atas membantu Anda menemukan aktivitas mencurigakan yang mungkin memengaruhi keamanan basis data Anda. Untuk detail lebih lanjut tentang audit database Oracle, lihat bibliografi di bawah ini.

Bibliografi:

http://www.datadisk.co.uk/html_docs/Oracle/auditing.htm
http://docs.Oracle.com/cd/B10501_01/server.920/a96521/audit.htm
https://docs.Oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm#TDPSG50000