- tweet
-
Kurumsal firmalarda uzun bir zamandır hem database hemde operating sytem seviyesinde şirket için gizli ve değerli bilgilerin bir takım kullanıcılar tarafından şirklet dışına çıkartılması veya bu bilgilerin şirket içerisinde kötü amaçlarla kullanılmasnı önlemek için firmalar çok çeşitli yöntemler kullanmaya başlamışlardır. Bir oracle dba olarak burada database seviyesinde kullanıcıları nasıl izleyebiliriz, bunu yaparken nelere dikkat etmeliyiz gibi bir takım teknik konulara değineceğiz.
Oracle ‘ daki audit mekanizmasının biraz tarihçesine inersek, 1992 yılında oracle 7 sürümüyle tüm audit özelliklerini içeren ilk veritabanı olma, 1994 yılında ise bağımsız güvenlik kuruluşlarından onay alan ilk veritabanı olma özelliiğinede sahiptir. Bu açıdan düşünüldüğünde oracle veritabanı diğer ilişkisel veritabanları arasında güvenilirliğini ile ilk sırada yer almayı başarmış bir veritabanıdır.
Peki Auditing nedir ? Özetle, seçilen bazı userların (veya hepsinin) database içerisinde yapmış olduğu aktivitelerin monitör edilmesi ve sonra kayıt altına alınarak saklanması işlemine auditing diyebiliriz. Bu monitöring ve kayıt altına alma işlemi, kullanıcı adı, işlemin yapıldığı an, hangi uygulama kullanılarak yapıldığı, hangi makine üzerinden sisteme giriş yapıldığı gibi bilgileri kapsar. Bir işlemin auditlenmesi için mutlaka başarılı olması gerekmemektedir, başarısız olan tüm işlemlerde izlenebilmektedir. (başarız olan işlemler kimi zaman başarılı olanlardan daha fazla önem taşırlar. Sürekli olarak birinin, sistemde yer alan bir kullanıcı adı ile sisteme giriş yapmayı denemesi şüphelenmek ve araştırmak için yeterli bir nedendir.)
Neden Aduting yapılmaya ihtiyaç duyulur ? Bunun nedenleri ana hatlarıyla ;
· Yapılan İşlemlere Ait Sorumluları Tespit Etmek İçin;
· Davetsiz Misafirleri Caydırmak İçin ,
· Şüpheli İşlemleri Araştırmak için,
· Yetkisiz Kullanıcıya Ait İşlemleri Tespit Etmek ve Denetime Bildirmek İçin,
· Özel bir database işlemi ile ilgili istatistik toplama ve monitor etmek için,
· Yetki ve Erişim Kontolleri ile Problemleri Tespit Etmek İçin.
Neden auditing yapacağımıza karar verdikden sonra, karar verilmesi gereken 2 konu karşımıza çıkmaktadır. Bunlardan birincisi, nelerin audit edileceğine ikincisi ise audit kayıtlarının nerede saklanacağına karar vermekteir. Database’ deki her oturumu her işlemi auditlememelisiniz, sonuçta bu kayıtların tutulması için de bir kaynak kullanılması gerekmektedir ki, audit kayıtları yanlış bir konfigurasyonla çok hızlı büyüyebilir ve sizi olmadık bir anda zor durumda bırakabilir. Sorun sadece kaynak problemi değildir aslında, yapılan auditing işleminin sisteme getirdiği ek bir performans kaybı olmaktadır. Dolayısıyla herşeyi auditlemek kimi zaman çözüm olmakdan uzak bir hal almaktadır. Bir diğer neden ne kadar çok auditin işlemi yaparsanız o kadar çok incelemeniz, denetlemeniz gereken kayıt ortaya çıkacaktır.
Audit işlemleri ile ilgili olarak nasıl yapılacağı konusu aslında ne tarz bir auditing metodu uygulayacağınızla birebir ilişkilidir. Audit yöntemlerinden bahsedelim biraz;
1. Genel Aktivitilerin Standart Auditing ile Auditlenmesi ;
Satndart auditing, SQL statamentlerın, yetkilerin, schema objelerinin ve networkdeki aktivitilerin auditlenmesidir. Standart auditing AUDIT komutu ile başlatılır, NOAUDIT komutu ile sonlandırılır. Bu auditing işlemi AUDIT ANY yetkisi ile AUDIT SYSTEM yetkisine sahip herhangi bir kullanıcı yapabilir.
Audit kayıtları, güvenlik işinden sorumlu adminin database seviyesinde auditingi enable etmesiyle başlar. Auditing enable edilmesiyle , database çalışan SQL statementının çalışmasından sonra bir audit kaydı üretir. Üretilen bu audit kaydı kullanıcının transactionı commit etmesinden bağımsızdır. Aynı şekilde başlatılan bir rollback işlemide yine yeni bir audit kaydı oluşturur.
Burada AUDIT_TRAIL parametresi önemlidir, database tarafından tespit edilen audit kayıtlarının nerede ve nasıl saklanacağının belirlendiği parametredir. Bu parametrenin şu anki değerini görmek için ;
SQL> show parameter audit_trail;
NAME TYPE VALUE
———————————— ———– ——————————
audit_trail string NONE
Şu an bu değer NONE olduğundan dolayı auditing özelliği bu database’ de disable anlamına gelmektedir. AUDIT_TRAIL parametresi statik bir parametre olduğundan dolayı yapılan değişikliğin geçerli olması için database’ in restart olması gerekmektedir. Değişikliği yapmak içinse;
SQL> show user
USER is “SYS”
SQL> ALTER SYSTEM SET AUDIT_TRAIL=DB SCOPE=SPFILE;
System altered.
SQL> shutdown immediate ;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 419430400 bytes
Fixed Size 1249368 bytes
Variable Size 96473000 bytes
Database Buffers 314572800 bytes
Redo Buffers 7135232 bytes
Database mounted.
Database opened.
SQL>
Komutlarından faydalanılabilir. Buarada audit_trail parametresini “db” olarak set ettik. Bunun anlamı ve diğer alternatiflerini şöyle özetleyebiliriz ;
DB ; Audit kayıtlarının database’ de tutulması anlamına gelir. Bu kayıtlar database’ de sys.aud$ tablosunda saklanır. (sys userına ait audit kayıtları hariç, sys userına ait audit kayıtlar OS’ ye yazılır) Audit_trail parametresi DB olarak set edili iken database’ i read only modda açmak isterseniz, database size aşağıdaki gibi hata dönecektir. Bunun nedeni, audit_trail db olarak set edili iken database’ i read only olarak açmak istiyorsanız önce audit_trail parametresini ya OS yada NONE olarak set etmeniz gerektiğidir (read only modda iken audit kayıtlarını database’ e write edemeyeceğinden dolayı).
SQL> startup mount
ORACLE instance started.
Total System Global Area 419430400 bytes
Fixed Size 1249368 bytes
Variable Size 100667304 bytes
Database Buffers 310378496 bytes
Redo Buffers 7135232 bytes
Database mounted.
SQL> alter database open read only
2 /
alter database open read only
*
ERROR at line 1:
ORA-16006: audit_trail destination incompatible with database open mode
SQL> select open_mode from v$database ;
OPEN_MODE
———-
READ WRITE
SQL> show parameter audit_trail;
NAME TYPE VALUE
———————————— ———– ——————————
audit_trail string DB
SQL>
OS ; Audit kayıtları operating sistemde belirtilen bir path’ de saklanır. Buraya file bazında çıkan dosyalar .aud uzantılı olur. Burada iki farklı parametre daha var set etmemiz gereken, AUDIT_FILE_DEST parametresi audit kayıtlarının nerede tutulacağının set edildiği parametredir. Aşağıdaki şekilde set edilebilir;
alter system set AUDIT_FILE_DEST =’d:\oracle11gR2\audit’ scope=spfile;
Diğer parametre SYS userının auditlenip auditlenmemesi ile ilgili, eğer SYS userının sessionlarıda auditlenecekse AUDIT_SYS_OPERATIONS parametresi TRUE olarak set edilmelidir.
Alter system set AUDIT_SYS_OPERATIONS=TRUE scope=spfile;
10g’ de olmayan, 11g ile yeni gelen bir parametremiz daha var; AUDIT_SYSLOG_LEVEL parametresi. Bu parametre sadece Unix ortamlarda kullanılmaktadır. Bu parametre manuel olarak initSID.ora dosyasına eklenilerek set edilebilir. İki farklı değer alabilir;
Facility; İşletim sistemi’ nin, mesajı loglayan bölümünü ifade eder. Kabul ettiği değerler; user, local0-local7, syslog, daemon, kern, mail, auth, lpr, news, uucp ve cron.
Local0 – local7 arasındaki değerler, syslog mesajlarını kategorize etmemize olanak sağlayan önceden tanımlanmış etiketlerdir. Bu kategoriler, syslog aracının ulaşabileceği log dosyaları veya diğer dizinler olabilir. Bu etiket tipler ile ilgili ayrıntılı bilgi için, syslog aracının MAN sayfasına bakabilirsiniz.
Priority ; Mesajın öncelik derecesini belirler. Kabul ettiği değerler, notice, info, debug, warning, err, crit, alert ve emerg’ dir.
Bu parametreyi database’ e set etmek için ;
ALTER SYSTEM SET AUDIT_TRAIL=DB SCOPE=SPFILE;
Komutundan faydalanabiliriz.
DB, EXTENTED ; Audit kayıtları sys.aud$ tablosuna kaydedilir aynı zamanda Sqlbind değerleri ile sqltext’ deki Clob bilgileride bu tabloda tutulur.
Aşağıdaki gibi 2 farklı şekilde set edilebilir.
ALTER SYSTEM SET AUDIT_TRAIL=DB, EXTENDED SCOPE=SPFILE;
ALTER SYSTEM SET AUDIT_TRAIL=’DB’,’EXTENDED’ SCOPE=SPFILE;
Aşağıdaki gibi bu iki kriteri tek tırnak içerisinde kullanılmamalıdır;
ALTER SYSTEM SET AUDIT_TRAIL=’DB, EXTENDED’ SCOPE=SPFILE;
XML ; Auditing kayıtları operating system de xml dosyası olarak saklanır. XML formatındaki audit kayıtlarının default lokasyonu windows’ da dahil olmak üzere tüm platformlarda; $ORACLE_HOME/admin/$ORACLE_SID/adump lokasyonudur.
Sys ve zorunlu audit dosyalarını operating sisteme XML fromatında yazmak için ; Audit_trail = XML or XML,ExTENDED, AUDIT_SYS_OPERATIONS=TRUE fakat AUDIT_SYSLOG_LEVEL parametresi set edilmemiş olmalıdır.
Sys ve zorunlu audit kayıtlarını syslog Audit file’ lerine, Standart Audit kayıtlarını XML Audit file’ lerine yazmak için; Audit_trail = XML or XML,ExTENDED, AUDIT_SYS_OPERATIONS=TRUE ve AUDIT_SYSLOG_LEVEL parametreside set edilmiş olmalıdır.
Bu parametreyi database’ e set etmek için ;
ALTER SYSTEM SET AUDIT_TRAIL=XML SCOPE=SPFILE;
Komutundan faydalanabiliriz.
XML, EXTENTED ; Auditing kayıtları operating system de xml dosyası olarak saklanır aynı zamanda Sqlbind değerleri ile sqltext’ deki Clob bilgileride burada saklanır.
Bu parametreyi set etmek içinde aşağıdaki iki komuttan biri kullanılabilir.
ALTER SYSTEM SET AUDIT_TRAIL=XML, EXTENDED SCOPE=SPFILE;
ALTER SYSTEM SET AUDIT_TRAIL=’XML’,’EXTENDED’ SCOPE=SPFILE;
Aşağıdaki gibi çalıştırılmamalıdır;
ALTER SYSTEM SET AUDIT_TRAIL=’XML, EXTENDED’ SCOPE=SPFILE;
NONE ; Auditing disable anlamına gelir.
Audit_trail parametresini DB olarak set ettiğimizde belirlediğimiz audit kriterlerine uygun sessionlar geldikçe bu tabloda dolmaya başlayacaktır.
select sessionid, userid, userhost, terminal, action# from sys.aud$
SESSIONID USERID USERHOST TERMINAL ACTION#
14708 KAMIL WORKGROUP\KHOME KHOME 101
Burada action alanı çalıştırılan sql komutunun kodunu ifade etmektedir. Hangi kodun hangi komuta denk geldiğini aşağıdaki sorgu ile çekebilirsiniz.
Select * from AUDIT_ACTIONS ;
Ile sorgulayabilirsiniz.
Biraz da AUDIT ve NOAUDIT komutlarının nasıl çalıştığından bahsedelim.
Audit veya Noaudit komutları sisteme gönderilirken komut sonlarında yer alan aşağıdaki 3 parametre önemlidir;
· WHENEVER SUCCESSFUL cümlesi; herhangi bir audit veya noaudit komutunun sonunda bu cümle yer alıyorsa, çalıştırılan komut başarılı olmak kaydıyla auditleneceği veya auditlenmeyeceği anlamına gelir. Yani başarısız olan komut üzerinde işlem yapılmaz.
· WHENEVER NOT SUCCESSFUL cümlesi; Eğer komutun sonunda bu cümle yer alıyorsa, başarısız olan komutların auditleneceği veya auditlenmeyeceği anlamına gelir. Başarılı olan komut üzerinde işlem yapılmayacak demektir.
· Her İkiside kullanılmazsa; Çalıştırılan Audit/Noaudit komutu içerisinde yukarıda belirtilen kısımlar kullanılmaz ise, hem başarılı hemde başarız tüm işlemlerin auditleneceği/auditlenmeyeceği anlamına gelir.
Örneğin;
AUDIT CREATE TABLE BY ACCESS WHENEVER NOT SUCCESSFUL;
Bu script ile create table scriptini çalıştıran tüm userlar içerisinde sadece başarız olanlar (çalıştırdığı komutu hata verenler) auditlenecek demektir.
Oracle audit komutlarında BY ACCSESS cümleciğini kullanmayı önerir. Oracle 11gR2 ile birlikte audit komutunun sonunda by accsess cümleciği kullanılmasa bile defaultunda yer aldığı için kullanılacaktır. Bu komutu kullanmanın bir takım avantajları vardır. Bu avantajları özetleyecek olursak ;
· BY ACCSESS komutu kullanıldığında, elde edilen audit kayısında daha fazla bilgi yer alacaktır. Örneğin, execution status (return code), execution zamanı vetarihi, kullanılan privilege, sql text’ i ve bind variable değerleri gibi . Ek olarak BY ACCSESS kullanımı ile yapılan işleme ait SCN ‘ ıda kaydettiğinden geri dönüş gibi bir aksiyon alınması gerektiğinde bu bilgi ile Flashback komutları kullanılarak çok rahat eski veriye ulaşım sağlanabilecektir.
· Oracle database’ i çalışan her bir sql statement’ını, kullanılan bir privilege ‘ ı ve auditlenen her nesneye erişimi kaydeder. Bu kayıtlar neticesinde bu işlemin kaç defa yapıldığını bulmanıza da yardımcı olur.
· BY ACCSESS audit kayıtlarında oturum açma ve kapatma kayıtlarını fine-grained zamanları ile birlikte tutar.
BY ACCSESS kullanımına örnek olarak ;
AUDIT SELECT TABLE BY ACCESS;
Spesifik bir Usera ait işlemlerin Auditlenmesi ;
Örneğin, Kamil ve Hakan userının çalıştırmış olduğu tüm selectler ile Updateleri auditlenmesini istersek;
AUDIT SELECT TABLE, UPDATE TABLE BY KAMIL,HAKAN BY ACCESS;
Başlıklar altında örnek scriptler başlangıçda az gibi algılanabilir.
NOAUDIT Komutunun Çalıştırılması ;
Audit edilen bir nesne , system privilege, veya bir kullanıcının audit edilmesini n kaldırılması, iptal edilmesini sağlar. NOAUDIT komutunda WHENEVER SUCCESSFUL ve WHENEVER NOT SUCCESSFUL kullanımına dikkat edilmelidir, burada da AUDIT’ dekine benzer bir kullanım sözkonusudur, bu cümle NOAUDIT komutunun sonunda kullanılmazsa başarılı/başarısız tüm işlemler audit kapsamı dışına çıkarılmış olur.
Audit işlemlerleri ile ilgili olarak konu içerisinde vermiş olduğum örnekler ileride konular detaylandıkça artacağından şu aşamada konunun anlaşılması için yeterli olacağını düşünüyorum.
SQL Cümlelerinin Auditlenmesi ;
Database de yapılan tüm selectleri ayırt etmeksizin auditlemek istersek ;
AUDIT SELECT TABLE BY ACCESS;
komutundan faydalanabiliriz.
Eğer tüm SQL komutlarını auditlemek istiyorsanız, user connectionlarını veya var olmayan nesnelere ait referanslar için aşağıdaki adımları izleyebilirsiniz;
· Userların tüm SQL Statement’ larının Auditlenmesi ; ALL STATEMENTS cümleciği ile sadece top-level SQL sorguları auditlenebilir. Bu audit seçeneği diğer audit seçeneklerinden farklıdır. Eğer sql statement’ ı pl/sql proceduru içerisinden çalıştırılıyorsa, All Statement opsiyonu bunları auditlemeyecektir. Bu audit opsiyonu diğer set edilmiş olan audit opsiyonlarından etkilemez.
Kullanımı ile örnek ;
AUDIT ALL STATEMENTS BY KAMIL BY ACCESS WHENEVER SUCCESSFUL;
· Userlar tarafından çalıştırılan tüm Sql Statement’ larının (Komutların Kısayolları İl e) Auditlenmesi ;
Burada ifade edilmek istenen İndex, Procedure, Database Link vs. gibi bazı komutların kısayolları ile bu komutlar ile yapılan tüm işlemleri auditleyebilirsiniz. Oracle’ da çok fazla sayıda komut olduğundan dolayı komutlara ait kısayolları buraya yazmaktansa merak edenler aşağıdaki linkden bunlara ulaşabilirler;
http://download.oracle.com/docs/cd/E11882_01/server.112/e17118/statements_4007.htm#SQLRF53735
Bu konuyla ilgili örnek olarak;
AUDIT ALL BY KAMIL BY ACCESS;
verebiliriz.
· Kullanıcı Ayıt Etmeksizin Geçerli Oturumdaki Tüm SQL Statementlarının Auditlenmesi ; All Statement audit seçeneği için IN SESSION CURRENT cümleciği ile top-level sql statementlarını session sonlanmadığı sürece audit edebilirsiniz. Bu auditi NOAUDIT ile sonlandıramazsınız fakat user sessionı discconect olduğunda zaten auditte sonlamış olacaktır.
Örneğin, mevcut bir sessinındaki tüm işlemleri auditlemek için ;
AUDIT ALL STATEMENTS IN SESSION CURRENT BY ACCESS WHENEVER NOT SUCCESSFUL;
komutunu kullanabilirsiniz.
· Login ve logout’ ların Audilenmesi ; İsterseni z AUDIT_SESSION komutu ile tüm login ve logooutları auditleyebilirsiniz.
Örneğin,
AUDIT SESSION BY ACCESS;
Sadece belli bir kullanıcının login ve logoutlarını auditlemek isterseniz,
AUDIT SESSION BY kamil BY ACCESS;
Komutunu kullanabiliriz.
· Object doesn’ t exist hatasıyla fail olan sql statementlarının Auditlenmesi ; NOT EXIST cümleciği ile object doesn’ t exist hatasıyla fail olan sorguları auditleyebilirsiniz.
Örneğin,
AUDIT NOT EXIST ;
SQL Stamentları ile İlgili Audintingleri Sonlandırmak İçin;
Kamil Turkyilmaz
1979 Tokat/Zile doğumluyum. Yıldız Teknik Üniversitesi 1997 - 2001 mezunuyum ancak 1998 yılından itibaren IT sektöründe, 2000 yılından bu yanada Oracle üzerine çalışmaktayım. 2005 yılına kadar oracle database'i üzerine yazılmış olan kimi uygulamalara software support hizmeti, sonrasında ise oracle veritabanı yöneticiliği olmak üzere yaklaşık 12 yıldır sektör içerisindeyim. Oracle' ın hemen hemen tüm ürünlerinin kurulumu, konfigurasyonu, yönetimi konusundaki çalışmalarıma özel bir bankada oracle dba olarak devam etmekteyim. Aynı zamanda kimi bilişim sitelerinde yazarlık yapıyorum, bunun yanısıra bu alandaki deneyim ve tecrübelerimi daha fazla kullanıcıyla paylaşabilmek adına bir de oracle blog yazarıyım.
Latest posts by Kamil Turkyilmaz (see all)
- Oracle Manıksal Yapı - Ara 9, 2013
- Oracle 11g Flashback Data Archive Özelliği - Ara 9, 2013
- Crontab : You Are Not Authorized To Use Cran.Sorry - Ara 9, 2013
Oracle RAC veritabanı kurulu bir ODA makinasında /adump klasörü içindeki audit (*.aud) uzantılı dosyaları işletim sisteminden rm komutu ile silmek doğru mudur yoksa yanlış mıdır? SQLplus tarafından mı silinmesi gerekir. Teşekkürler.