Web Sitemiz

Önemli Siteler

Oracle Veritabanı'nda Veri ve Sistem Güvenliği
Yazan: Mengü Yazıcıoğlu
Çoğaltım (c) : Bu belgeyi, kaynak göstermek koşuluyla ve ücretsiz edinilebileceğini ve nereden elde edilebileceğini belirtmek koşuluyla istediğiniz gibi kullanabilirsiniz. Yazarına ve emeğine saygı nedeniyle belge üzerinde ve bilgilerde değişiklik yapsanız da yazarlarını sırasıyla belirterek sizden sonraki değişikliklerde de aynı şekilde sürmesini sağlamalısınız.
Bu belgenin izleyen geliştirmelerinde sizin katkınız özgününe göre çok farklı olsa da burada belirtilen konuların yeni üretilen belgelerde de korunması gerekmektedir.

İlk Yayım Tarihi:    17 Mart 2002
Son Güncelleme:     8 Mart 2007

İçindekiler:

0.    Önsöz

1.    Oracle'ın Bulunduğu İşletim Sisteminin Güvenliği

1.1    Sisteme Erişimi Kısıtlama
1.2    Sisteme Güvenli Erişimi Sağlama


2.    Oracle Veritabanı ve Verilerin Güvenliği

2.1    Veritabanı Dosyaları Güvenliği
2.2    Ya veritabanı Çökerse? Yedek Almalı mıydım?
2.3    Online Redo Log Dosyalarını Archive Mode İçin Hazırlama
2.4    Archive Mode'a Geçiş


3.    Oracle'ı Daha Güvenli Hale Getirme

3.1    Kurulumla Gelen Kullanıcılar
3.2    Oracle Araçlarını Çalıştırırken Şifreleri Kullanma, Şifreleri Dosyadan Okutma
3.3    Kurulumla Gelen Servislerin Çalışma Portları
3.4    Listener'a Şifre Koyma
3.5    Veritabanı'na Erişimi Kısıtlama 

4.    Güvenliği Sağladım mı?
0.    Önsöz

Yıllarca aradığım kaynakların Türkçelerine ulaşamamak ve yurtdışından getirmek zorunda kalınan kitapların da pahalılığı nedeniyle hep neden Türkçe içerikli bir kitabı/belgeyi üstelik herkesin ya parasız ya da çok ucuz biçimde edinebilecekleri bir ortamda sunmayayım diye düşündüm.

1998'den beri Oracle ve Informix Veritabanı Yöneticiliği yapıyorum. Aynı zamanda  MySQL, PostgreSQL, Visual FoxPro, FoxBase gibi ürünleri de kullandım/kullanıyorum.

Bu belgeyi de Oracle kullanıp, neyi nasıl yapacakları konusunda emin olamayanlara yardımcı olması için hazırladım. Bu belgede yalnızca Oracle'a yönelik çözümler değil genel bir güvenlik bakışı ve yedek alma yöntemi kazanacağınızı da umuyorum.

Neden bir Oracle Belgesi?

Birçok kurum, adını bir şekilde duyduğu markalara yöneliyor. Eğer bir veritabanı seçecekseniz yapacağınız ve yapmayı düşündüğünüz işlere göre bir veritabanı seçin.
Çoğu zaman çok iyidir diye aldığınız ürünler hem parasal anlamda size çok fazla yük getirebilir, hem de yürütmek, güvenliğini sağlamak açısından zorlanabilirsiniz.

Herhangi bir yazılım yüzde yüz güvenlidir diyebilmek cesaret ister. Ama son dönemde Oracle'ın güvenliğe son derece önem vermeye başladığını görmekteyiz. İster bir marka ürünü ister açık kaynak kodlu bir veritabanı kullanıyor olun mutlaka ve mutlaka güvenliği konusunda ön bir araştırma yapın.

Oracle kullanan biriyseniz, aşağıdaki bilgilerin işinize yarayacağını umarım.

Gördüğünüz bir eksik ya da yanlış varsa aşağıdaki adresime iletmenizi dilerim.

Mengü Yazıcıoğlu
Ankara,Türkiye
 

Bu belgedeki kısıltmalar ve varsayılanlar

İS        : İşletim Sistemi
VT       : Veritabanı
VTY    : Veritabanı Yöneticisi
VTYS : Veritabanı Yönetim Sistemi
$           : Unix komut satırı

SVRMGR> ardından gelen komutlar için öncelikle svrmgrl yazılıp enter'a basıldığı ve daha sonra da  connect internal denerek vt'ye bağlanıldığı varsayılmaktadır.

Buradaki örnekler çoğunlukla Oracle 7.3.x ve 8.0.x'ler için geçerli olabilecek örneklerdir. Ama yeni sürümlerde de aynı yapının korunmuş olması olasıdır.

Oracle ve ilgili dosyaların sahibinin Unix düzeyinde oracle kullanıcısı olduğu varsayılmıştır.

1.    Oracle'ın Bulunduğu İşletim Sisteminin Güvenliği

Bu belgeyi Unix ya da unix benzeri (linux gibi) bir işletim sisteminde çalıştığınızı düşünerek hazırladım. Eğer Windows gibi sorunlu sistemlerde çalışıyorsanız İşletim Sistemi (İS) güvenliği konusunda da ciddi adımlar atmanız gerekecek. İS güvenli olsa da en azından virüs bulaşarak sisteminizi çökertme riskine karşı önlem almalısınız.

Ama burada anlatılacaklar yalnızca Unix ve türevlerinde değil, tüm İS için geçerli bilgileri içereceklerinden tüm Oracle kullanıcılarına yarayacaktır.

1.1.   Sisteme Erişimi Kısıtlama

Oracle'ın bulunduğu sunucuya, bilgisayara erişimi kısıtlayın.

Doğaldır ki bu her zaman olası değil. Ama İS'leri ve donanımlar kimin nereye bağlanacağını ayarlamanıza yardımcı olabiliyorlar. Eğer sizin sunucunuza belirli kişilerin ulaşmasını sağlayabilir, belirli kişilerin ulaşmasını engelleyebiliyorsanız en önemli güvenlik adımlarından birini atmış sayılırsınız.

Bu kısıtlamayı, sisteme belirli IP'lerin dışında ping bile çekemez duruma getirerek sağlayabilirsiniz.
"routing table" a bakarak sizin işletim sisteminize kimler bağlanabilir durumda görebilirsiniz:

        netstat -rn

komutu ile bağlanabilir durumdaki IP'leri görebilirsiniz.

Bu sisteme bir şekilde erişebilir IP'leri göstermekte. Aynı zamanda başka ayarlamalarla
belirli IP'lerin sisteme bağlanabilmelerini (login) de kısıtlayabilir ya da engelleyebilirsiniz:

/etc altındaki hosts.allow ve hosts.deny dosyaları hangi IP'lerin neler yapabileceğini göstermektedir.

Örnek:

$ more /etc/hosts.allow
sshd2: 12.1.72.1

$ more /etc/hosts.deny
ALL: ALL

hosts.allow ve hosts.deny dosyasındaki satırlar bu sunucuya ssh ya da sftp ile 12.1.72.1 IP'si
dışında hiçbir yerden bağlanılamayacığını gösteriyor.

1.2.   Sisteme Güvenli Erişimi Sağlama

Her zaman sisteme erişimi kısıtlamak yeterli olmayacaktır. Hatta bazı durumlarda sisteme erişimi kısıtlamak mümkün olmayacaktır. İşte bu tür durumlarda Sistem Yöneticilerine düşen farklı güvenlik önlemleri devreye girmektedir. Erişimlerin güvenli olmasının sağlanması gibi.

Sisteme telnet ya da ftp ile bağlanılması yerine ssh ya da sftp gibi şifreli veri alışverişi yapan programların kullanılması, İS'deki kullanıcıların basit şifreler seçmesini engelleyecek yapıların oluşturulması, İS açıklarının saptanarak gerekli yamaların yapılmasının sağlanması gerekmektedir. Aksi durumlarda oracle kullanıcısı, daha da kötüsü root kullanıcısının şifresi yaramaz çocukların eline geçtiğinde bundan sonra anlatılacak güvenlik önlemlerine hiç gerek bile kalmıyor olacaktır.

2.    Oracle Veritabanı ve Verilerin Güvenliği

Eğer İS düzeyinde önlemlerinizi aldıysanız artık veritabanı ve verilerin güvenliğine bakabilirsiniz. Almadıysanız da bakın tabii :)
Güvenlik yalnızca sisteminize saldırılıp zarar verilmesini kapsamıyor.

2.1.   Veritabanı Dosyaları Güvenliği

Tablespaceler'ın tutulduğu datafile'lar, loglar ve kontrol dosyaları gibi Oracle veritabanı için olmazsa olmaz dosyaların sağlıklı bir biçimde çalışması gerekmekte.
Bu nedenle bu dosyaların başka Unix kullanıcıları tarafından yazılamaz (silinemez) olmalarını kontrol edin.

Bu dosyalar veritabanı sahibi tarafından ve onun grubu tarafından sahiplenilmeli ve
başkaları tarafından yazılamamalıdır.

Peki bu dosyalar neler ve neredeler?

Bu dosyalar datafile'lar, loglar ve controlfile'lardır. Yerlerini öğrenmek için
sqlplus / ile ya da svrmgrl deyip connect internal diyerek veritabanına bağlanın:

$ svrmgrl
SVRMGR>connect internal

Connected.
SVRMGR>select  * from v$datafile;

ya da

SVRMGR> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
/d1/data/ORNEK/sysORNEK01.dbf
/d2/data/ORNEK/sysORNEK02.dbf
/d3/data/ORNEK/sysORNEK03.dbf
/d2/data/ORNEK/datORNEK01.dbf
/d3/data/ORNEK/datORNEK02.dbf
/d3/data/ORNEK/rbsORNEK01.dbf
6 rows selected.

Yukarıdan da anlaşılacağı üzere datafile'larımız /d1/data/ORNEK, /d2/data/ORNEK vb
yerlerde duruyor.

Aynı şekilde controlfile'ların yerini bulmak için:

SVRMGR> select * from v$controlfile;

ve online redo logfile'ları bulmak içinse:

SVRMGR> select * from v$logfile;

komutlarını verebiliriz.

Dosyaların yerlerini bulduktan sonra bunların kime ait olduğuna bakmamız gereklidir.

SVRMGR>exit

diyerek Server Manager'dan çıkıp komut satırına düştükten sonra

$ cd /d1/data/ORNEK diyerek bu dizine gidebiliriz (sizin dosyalarınız farklı yerlerde olacağı için ilgili dizini yazmalısınız)

$ ls -al *.dbf diyerek (controlfile ve logfile'ların uzantıları ve yerleri değişik olabilir)

-rw-r-----   1 oracle   dba      1859584 Mar 17 16:34 ctlORNEK01.dbf
-rw-r-----   1 oracle   dba      314580992 Mar 17 06:08 sysORNEK01.dbf

ilgili dosyaların kime ait olduğunu ve kimlere yazma yetkisi verildiğini görüyoruz.
Bu örneğimizde yalnızca oracle kullanıcısına yazma yetkisi verildiğine dikkat edin.
Eğer dba grubuna ya da tüm kullanıcılara yazma yetkisi verilmiş olsaydı şuna
benzer bir durumla karşılaşırdık.

-rw-rw-rw-   1 oracle   dba      1859584 Mar 17 16:34 ctlORNEK01.dbf
-rw-rw-rw-   1 oracle   dba      314580992 Mar 17 06:08 sysORNEK01.dbf

Bu ise ciddi bir güvenlik açığı oluşturmaktadır.
Sisteme bağlı farklı bir kullanıcı bilerek ya da bilmeyerek bu dosyalardan birini silebilir,
üzerine yazabilir. Bu durumda veritabanınız artık çalışmayacaktır.

Bu nedenle eğer yukarıdakine benzer bir durumla karşı karşıyaysanız vt'yi kapatın ve
dosya haklarını değiştirin:

$svrgrml
SVRMGR>connect internal
Connected.
SVRMGR>shutdown
....

SVRMGR>exit

$ chmod 600 *.dbf

2.2.   Ya Veritabanı Çökerse? Yedek Almalı mıydım?

Yedek almalı mısınız? Size kalmış. Eğer verilerinizi yitirmek gibi bir kaygınız varsa, mutlaka yedek almalısınız. Ya da işinizi yitirmek gibi bir kaygınız varsa.

İS, donanımlarınız ve ağ bileşenleriniz  mükemmel olsa da her zaman fiziksel ya da başka bir nedenle vt'nizin başına bir iş gelebilir. Fiziksel bir bozukluk ya da başka bir nedenle vt çökebilir, dosyalar bozulabilir.

Yaptığınız işleme uygun yedek alma ve bu yedekleri doğrulamayı sizin saptamanız gerekiyor.

Eğer vt üzerinde sürekli işlemler yapılıyor ve bunların hiçbirini yitirmek istemiyorsanız
vt'yi Archive Mode'a geçirmelisiniz. Öte yandan belirli aralıklarla da hot backup (online) ya da cold backup (offline) yedekler almanız gerekmektedir.

Offline backup, vt kapalıyken alınan yedek biçimidir. Veritabanının düzgün olarak
kapatılmış olması gereklidir; shutdown ya da shutdown immediate ile.

Daha sonra ilgili tüm dosyaların bir yedeğinin alınması gereklidir (datafile'lar, controlfile'lar,  log dosyaları ve parametre dosyaları gibi). Bunu İS düzeyinde farklı bir yere alabileceğiniz gibi, tape gibi bir dış yedekleme aracına da alabilirsiniz.

Her zaman sistemi kapatarak yedek almanız mümkün olmayabilir. Bu nedenle de sistem açıkken de yedek almanız gerekebilir.

Bunun için de değişik yöntemler sözkonusu. İsterseniz vt açıkken tablespace'ler düzeyinde yedek alabilirsiniz. Bunun ayrıntılarına burada değinmeyeceğiz.
Bir de export ile de tablo ya da tüm tabloların ve ilişkili diğer yapıların bir yedeğini çıkarabilirsiniz.

$ exp help=y

komutu size başlangıç için bazı bilgiler verecektir.

Bunun için de ilgili belgelere bakmanızı, yanlış bir iş yapmamanız için önereceğim.

Bunlar yedek alma biçimlerine örneklerdi. Hepinizin bildiği gibi vt'na sürekli veriler eklenmekte, çıkarılmakta ve değişiklik yapılmaktadır. Bir çökme sırasında geri dönüş ve eksiksiz geri dönüş oldukça önem taşıyor. Bu nedenle de vt'yi Archive Mode'da çalıştırmalısınız dedik. Böylece sorun çıktığı noktaya deönüşünüz olasıdır.

Peki Archive Mode'a nasıl geçerim? Bunun için önceden yapmam gerekli işler nelerdir?

Vt'nin arşiv alarak çalıştırılması demek, bir döngü içinde üst üste yazılan online redo log dosyalarının, üzerine yazılmasına izin verilmeyecek biçimde başka bir yere yazılmasının sağlanması anlamına geliyor. Bu yüzden de online redo log'ların boyutu önem taşıyor. Öncelikle vt'nizde kaç gruptan oluşan log dosyası var buna bakalım.

2.3.   Online Redo Log Dosyalarını Archive Mode İçin Hazırlama

Yedek Almalı mısınız? Size kalmış. Eğer verilerinizi yitirmek gibi bir kaygınız varsa, mutlaka yedek almalısınız. Ya da işinizi yitirmek gibi bir kaygınız varsa.

SVRMGR>select * from v$log;

GROUP#     THREAD#    SEQUENCE#  BYTES      MEMBERS    ARC STATUS           FIRST_CHAN FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------------- ---------- --------------------
         1          1       3618   3145728          2 YES INACTIVE           98297105 03/19/02 16:28:30
         2          1       3619   3145728          2 NO  CURRENT            98322294 03/20/02 11:49:36
2 rows selected.
 

Yukarıda "2 rows selected" ya da group# sütunundaki en büyük sayı olan 2'den de anlaşılacağı gibi, bu vt iki grouplu bir yapı içeriyor.

Vt'de işlem yaptıkça, yapılan işlemler bu log dosyalarına yazılır ve biri dolunca sıradakine geçer. Eğer bu dosyaların boyutu küçükse, grup sayısı yukarıdaki örnekte olduğu gibi azsa ve logların değişim süreleri kısaysa; Archive Mode'daki bir vt'da log diske yazılmadan diğer log dosyasına geçemeyeceği için vt askıda (hang-up) kalır.

Online redo logların değişim sürelerini şu komutla görebilirsiniz:

SVRMGR>select * from v$loghist;

Ya da alert dosyasına bakabilirsiniz.
Alert dosyasının nerede olduğuna bakmak için:

SVRMGR> select value from v$parameter
                 2> where name='background_dump_dest';

VALUE
--------------------------------
/usr/oradata/ORNEK/log/bdump
1 row selected.

sonucunda çıkan dizine gidip orada alert_<vtadı>.log dosyasının içine bakın.

Yukarıdaki örnekte ORNEK adlı vt için  /usr/oradata/ORNEK/log/bdump altındaki
alert_ORNEK.log dosyasıdır alert dosyam.

Bu aynı zamanda bir veritabanı yöneticisiniz sürekli izlemesi gereken bir dosyadır.
Burada vt üzerinde olan önemli işlerin ve hataların bilgileri yazar.

Eğer online redo logların sayısının az olduğunu düşünüyorsanız ya da sayısı az ama boyutu yetersizse ya yeni bir grup ekleyeceksiniz ya da logların boyutunu büyüteceksiniz.

Aşağıdaki örnek yeterli sayıda log'u olan bir vt için log'ların boyutunu büyültmeyi göstermektedir. Bu örnekte 3 tane log file olduğu ve boyutlarının küçük olduğu varsayıldı.
Bunun için önce bu dosyalar nerelerde ona bakıldı:

SVRMGR>select * from v$logfile;

GROUP#     STATUS  MEMBER
---------- ------- --------------------------------------------------------------------------------
         1         /d1/data/ORNEK/redoORNEK01_a.log
         1         /d2/data/ORNEK/redoORNEK01_b.log
         2         /d1/data/ORNEK/redoORNEK02_a.log
         2         /d2/data/ORNEK/redoORNEK02_b.log
         3         /d1/data/ORNEK/redoORNEK03_a.log
         3         /d2/data/ORNEK/redoORNEK03_b.log
6 rows selected.

Görüldüğü gibi 3 grup, her grupta iki üye ve tüm dosyalar /d1 ile /d2 altındalar.

$ svrmgrl
SVRMGR>connect internal
Connected.
SVRMGR>shutdown                            <-- vt'yi kapatıyorum
SVRMGR>startup open restrict        <-- vt'yi kısıtlı açıyorum, yalnızca ben bağlıyım.
SVRMGR>alter database add logfile group 4 ('/d1/data/ORNEK/redoORNEK04_a.log',
                  2>'/d2/data/ORNEK/redoORNEK04_b.log') size 5M;

diyerek 1.grubun dosyalarının bulunduğu yerlerde (sırasıyla /d1/... ve /d2/... altında) 2 üyeli 4.grup log dosyalarını yeni adlar vererek oluşturdum.

Benzer işlemleri 2. ve 3. gruplar içinde yaparak 5. ve 6. grupları oluşturdum.

SVRMGR>select * from v$log;
dediğimde STATUS sütununda CURRENT olarak gördüğüm grup benim eski log dosyalarımdan biri olacaktır.

SVRMGR>alter system switch logfile;

diyerek bir sonraki gruba geçmesini sağlarım. v$log'da gördüğüm duruma göre yeterince bu komutu vererek yeni yarattığım gruplardan birinin CURRENT olmasını sağlarım.

Daha sonra ise,

SVRMGR>alter database drop logfile group 1;
ve 2. ve 3. gruplar için de aynı işlemleri yaparak artık gerek duymadığım eski log file'ları silerim.

Ancak bu İS düzeyinde bir silme değil, vt düzeyinde bir silmedir. Bu nedenle İS düzeyinde gidip eski dosyalarımı silmem gerekir.

İsterseniz şimdi vt'yi tam kullanıma açın, isterseniz shutdown ile kapatıp
bir yedek alın. Hatta ne olur olmaz diyerek bu işlemlere başlamadan önce de vt'yi kapatıp bir yedek almayı tercih edebilirsiniz.

Logları'da ayarladığımıza göre artık vt'yi Archive Mode'a geçirebiliriz.

2.4.   Archive Mode'a Geçiş

Belki de veritabanınız Archive Mode'ta çalışıyordur.Bunu anlamak için

SVRMGR>select name,log_mode from v$database;

NAME      LOG_MODE
--------- ------------
ORNEK    NOARCHIVELOG
1 row selected.

ile de görüldüğü gibi vt'nizin henüzArchive Mode'da çalışmadığını görebilirsiniz. Eğer  Archive Mode'da olsaydı ARCHIVELOG görecektiniz.

Veritabanınızı Archive Mode'a geçirmeden önce mutlaka kapatmalı ve uygun bir yedek almalısınız. Eğer işlemler sırasında bir sorunla kerşı karşıya kalırsanız bu sizin geri dönüşünüzü kolaylaştıracaktır.

SVRMGR>shutdown

Database Closed'u görüp

$ ps -fe|grep -i oracle

ile oracle'a ait çalışan bir iş var mı diye de kontrol edin. Eğer ora_ ile başlayan bilgiler geliyorsa ve içerisinde vt adını da taşıyorsa, vt'niz kapanmamış demektir.

Şimdi Unix düzeyinde yedeklerinizi alın.

Artık vt'yi Archive Mode'a geçirebiliriz.

İlk önce init.ora dosyasına (buradaki ornekte initORNEK.ora) bazı eklemeler yapmalıyız.
init.ora dosyası 8.x ve sonrasında ORACLE_HOME altındaki dbs dizininde bulunuyor çoğunlukla. Daha önceki sürümlerde farklı yerlerde olabilir.

oracle kullanıcısı ile

$ echo $ORACLE_HOME

dediğinizde bir değer çıkıyor olmalı. Öyleyse

$ cd $ORACLE_HOME/dbs

yazıp enter'a basarak ilgili dizine gidin ve önce bunun bir yedeğini alın:

$ cp initORNEK.ora initORNEK.ora.17032002

yazarak örneğin. Sonra da initORNEK.ora içerisine girerek en altına şu satırları yazın:

log_archive_dest=/archive
log_archive_start = true
log_archive_format=%s.arc

ve dosyayı saklayın.

İlk satır arşivlenecek dosyaların nereye yazılacağını gösterir.

2. satır otomatik arşivlemenin doğrudan yapılıp yapılmayacağını gösterir. Buna true demezseniz zaman zaman svrmgrl'ye bağlanarak log archive start diyerek, arşiv dosyalarını yazma işlemini elle kontrol etmeniz gerekir ki bunu önermiyorum. Ama tape gibi farklı bir yere zaman zaman arşivlemek için bu yöntemi kullanabilirsiniz.

3.satır ise üretilecek arşiv dosyalarının yazılma biçimini gösteriyor.  %s ile Log'ların sıra numarasını (Sequence #) .arc ile de uzantısını belirlemiş oldum.

$ svrmgrl
SVRMGR> startup mount ORNEK
SVRMGR> alter database ORNEK archivelog;
SVRMGR> alter database ORNEK open;

diyerek artık vt'yi Archive Mode'a geçirmiş olduk.

SVRMGR>alter system switch log file;

ile log dosyasını 1 atlatarak arşivin yazılacağı yere yazmasını sağlayabiliriz.

Şimdi ister

SVRMGR> select name,log_mode from v$database;

ile isterseniz de

SVRMGR> archive log list;
Database log mode                         Archive Mode
Automatic archival                         Enabled
Archive destination                         /archive/
Oldest online log sequence            1315
Next log sequence to archive       1316
Current log sequence                      1316

ile vt'nin Archive Mode'ta olup olmadığını görebiliriz.

Şimdi yine vt'yi normal yöntemle (shutdown ile) kapatıp yedek almalıyız.
Bu yedek Archive Mode'a geçiş sonrası yedeği olduğu için önem taşıyor. Bunu temel alarak üretilmiş arşiv dosyalarını kullanabilir ve ileride çıkacak bir sorunda çözüm üretmiş olabiliriz. Ama yoğun kullanılan veritabanlarında çok fazla arşiv dosyası oluşacağından, bunları sırasıyla uygulayıp son hale gelmek günler sürebilir. Bunu önlemek için belirli aralıklarla vt kapalıyken yedekler (cold backup) alınmalıdır.

$ ls -al /archive diyerek oluşan dosyalara bakabilirsiniz. Yukarıdaki örnek nedeniyle oluşan dosyalar 1315.arc, 1316.arc şeklinde olacaktır.

Arşiv dosyalarının yazıldığı dizin bir süre dolabilir ve vt yeni bir arşiv dosyası yazacak yer bulamazsa askıda (hang-up) kalır. Bu nedenle arşiv dizinini zaman zaman başka bir ortama atarak ya da gerek kalmayanlarını silerek izlemelesiniz. Bu dosyaların sıkıştırılması da yer sorununuzu aza indirecektir. Aşağıdaki betik (script) arşiv dizinindeki dosyaları sıkıştırmak için yazılmış ve crontab'tan belirli aralıklarda çalıştırılan bir betikdir:
 

#!/usr/local/bin/bash
cd /archive
/usr/local/bin/gzip `ls|sort -rn|tail +2 |grep -v gz`

gzip ve bash'ın farklı yerlerde olabileceğini gözardı etmeyin lütfen.

$ which gzip

ile nerede olduğunu bulabilirsiniz.

3.    Oracle'ı Daha Güvenli Hale Getirme

Şu ana kadar İS düzeyinde alınacak önlemlerle veri güvenliğini gördük. Bir de Oracle'ın güvenliği var. Hem gerekli yamalarla açıkların giderilmesi, hem de VTYS (Veri Tabanı Yönetim Sistemi) düzeyinde alınacak önlemlerle olası sorunların önüne geçilmesi mümkündür.

3.1.   Kurulumla Gelen Kullanıcılar

Oracle VTYS kurulduğunda iki kullanıcı ve bunların şifreleri de yaratılmış olur. Bunlar system ve sys kullanıcıları ve sırasıyla manager ve change_on_install şifreleridir.

Bir veritabanı yöneticisi olarak yapmanız gereken ilk iş bu şifreleri değiştirmek olmalıdır.
Eğer VTYS'siyi siz kurmadıysanız ve kurulmuş bir vt'deki şifreleri kontrol etmek isterseniz şu yöntemi deneyebilirsiniz:

$ svrmgrl
SVRMGR>connect system/manager;

eğer "Connected." gibi bir bilgi yazıyorsa ekrana system kullanıcısının şifresi hala manager kalmış demektir.

$ sqlplus system/manager

ile de deneyebilirsiniz aynı işlemi.

Bir de connect sys/change_on_install diyerek deneyin.
Buna da bağlıysa Connected, bağlanamazsa "invalid username/password; logon denied" gibi bir bilgi göreceksiniz.

Şimdi bu kullanıcıların şifrelerini değiştirelim.

alter user <kullanıcı_adı> identified by <sifre>;

komutu kullanıcı_adı adlı kullanıcının şifresini verdiğiniz sifre olarak değiştirir.
Diyelim ki system kullanıcısının şifresini değiştirmek istiyorum, o zaman;

$  svrmgrl
SVRMGR>connect internal
Connected.
SVRMGR>alter user system identified by dene12;
Statement processed.

derim ve system kullanıcısının şifresi dene12 olur.  Unutmayın ki vereceğiniz şifre,
burada yaptığım gibi, kolayca bulunabilecek bir şifre olmamalıdır.

Aynı işlemi sys kullanıcısı için de yapın.

Oracle'ın yeni sürümleriyle ve özellikle de Application (9iAS vb) gibi ürünleriyle de birçok varsayılan kullanıcı/şifreler geldi. Bunları da değiştirmeniz iyi olacaktır. Ancak Oracle Uygulama Yazılımı'nın bazı yerlerinde bu kullanıcı ve şifreler gömülü olarak tutulduğu için onları da değiştirmeniz gerekebilir.

Yine vt yöneticiliğine başladığınız kurumdaki programlarda bir yerlerde gömülü olarak kullanıcı/şifre varsa bunları değiştirmek sorun olabilir. Ama iyi programcıların bu şekilde yazmadıklarını varsayın ve en azından system, sys kullanıcılarının şifrelerini değiştirin. Olmazsa eski şifreleri verebilirsiniz.

3.2.   Oracle Araçlarını Çalıştırırken Şifreleri Kullanma, Şifreleri Dosyadan Okutma

Oracle araçlarından sqlpus,exp,imp gibi programlar kullanıcı adı ve şifre isterler. Diyelim ki bir programı çalıştırıp daha sonra connect kullanıcı_adı diyerek şifreyi girmek yerine şunu yapıyorsunuz:

$ sqlplus system/manager

Bu durumda, sistemdeki bir başka kullanıcı ps -fe|grep oracle dediyse sizin yazdığın kullanıcı adı ve şifreyi görebilir.  Ya da .sh_history ya da .bash_history'i görme yetkisi varsa, yazdığınız şifreyi görebilir ve oldukça yetkili bir kullanıcı olarak vt'ye bağlanabilir.

Bu nedenle doğrudan komut satırından, ya da bir dosyaya yazıp oradan okutarak kullanıcı adı /şifre kullanmayın. Ya da böyle birşey yaptıysanız ve bunun görüldüğünü düşünüyorsanız 3.1'de anlatıldığı gibi kullanıcı şifresini değiştirin.

3.3.   Kurulumla Gelen Servislerin Çalışma Portları

Oracle veritabanı kurulduğunda, VTYS dosyaları dışında bağlanmaları sağlayan/kontrol eden listener gibi bazı servisler de kurulabiliyor. Ya da özellikle Oracle Uygulama yazılımları ile gelen Oracle Web, Oracle Forms gibi başka programlar da olabiliyor ve bunlar İS'nin kapılarını (portlarını) kullanarak çalışıyorlar.

Kurulum sırasında da bu kapılar varsayılan değerleriyle kurulduğu için dışarıdan bir kullanıcının sizin sunucunuzda ne çalışıyor, nerede çalışıyor gibi sorularına kolayca yanıt vermiş oluyorsunuz.

Kurulum sırasında ya da sonrasında sisteminizde hangi servislerin çalışması gerektiğini saptayarak, gerekli olanları kurun ve bunları, varsayılan kapıların dışında kurun. Böylece en azından, amacı doğrudan Oracle'ın bir parçasında çıkan bir açığa yönelik bir saldırı yapmak isteyen kişinin işini zorlaştırmış olursunuz. Zorlaştırmış olursunuz diyorum çünkü, saldıran işini bilen birisiyse, sizin İS'nizde neyin açlıştığını ve nereden hizmet verdiğini bulabilecek yazılımlara sahiptir. Ama en azından uğraşması gerektiği için, yaptığı işlemlerin farkına varılabilir, ya da uğraşmaktan vazgeçebilir.

Unutmayın saldırılarda birincil amaç, kolayca saldırılabilecek alanları bulmaktır.

8.1.x'lerle gelen Oracle Universal Installer aracılığı ile Oracle ve araçlarını kurduğunuzda bir aşamasında kurulacak servisleri ve bunların hangi kapılarda çalışacağını size soracaktır. Buradaki varsayılan değerleri değiştirin. Ama yeni seçtiğiniz değerin başka bir servisçe kullanılmaması gerekir. Her ne kadar, kurulum yazılımı, seçtiğiniz değerlerin olabilirliğini kontrol etse de, /etc/services altındaki
değerlerle ya da netstat -a ile kullanılır durumdaki kapıları görebilirsiniz.

Oracle için kullandığınız değerleri daha sonra /etc/services altına yazarak daha sonra kurulacak yazılımlar için ipucu verebilirsiniz.

3.4.   Listener'a Şifre Koyma

Oracle'ı kurdunuz ve listener'ı da çalıştırdınız. Listener'ıza da genellikle vt'nizin adı verilmiş oluyor. Bunu da değiştirmenizi öneriyorum.

Listener'ınızı şifrelemezseniz, izinsiz bir kullanıcı başka bir Oracle VTYS'yi kullanarak, sanki kendi listener'ını kapatıyormuşçasına sizinkini kapatabilir. Bunu bir 8.0.5 veritabanında yapmıştım. Çalışan bir veritabanının listener'ının sizden habersiz kapatılmış olması ise pek hoş sonuçlar doğurmayacaktır. Bu nedenler listener'ınıza bir şifre koyun. Parolalanmış (encryted) şifre koyabileceğiniz gibi doğrudan bir metin şifre de koyabilirsiniz. Size burada ikincisini göstereceğim.

Önce listener'ınızı bulun:

$ cd $ORACLE_HOME/network/admin

diyerek listener'ınızın yapılandırma dosyası listener.ora'nın olduğu yere gidersiniz.

listener.ora'yı açtığınızda en alt satırına passwords_<listeneradı>=<sifre> satırını ekleyin.

Diyelim ki listener adı LISTENER ve şifreniz denemesifre olsun. Bu durumda
            passwords_LISTENER=denemesifre
satırını eklemelisiniz.

Bunu ekledikten sonra listener.ora dosyasının haklarının dosya sahibine read-write olmasına dikkat edin.

$ chmod 600 listener.ora

komutu bunu sağlayacaktır:

$ ls -al listener.ora

-rw-------   1 oracle   dba         1919 May 30  1999 listener.ora

Bunu başka kişiler metin olarak yazdığımız şifreyi görmesinler diye yaptık.

Listener'ı lsnrctl aracını kullanarak açıp kapatıyorsanız, şunları yapmalısınız:

$ lsnrctl

Welcome to LSNRCTL, type "help" for information.

LSNRCTL> set current_listener LISTENER
Current Listener is LISTENER
LSNRCTL>set password denemesifre
The command completed successfully
LSNRCTL>stop

diyerek kapatabilir ya da aynı işlemleri uygulayarak ama stop yerine start diyerek başlatabilirsiniz.

Listener'a verilen metin şifre listener'ın loguna da yazılıyor ne yazık ki. Bu nedenle listener.log dosyasını da bularak chmod 600 listener.log diyerek yalnızca kendiniz okur-yazar duruma getirmelisiniz.

listener.log dosyası

$ lsnrctl status

komutunu verdiğinizde gördüğünüz Listener Log File değişkeninin olduğu dizindedir.

Eğer bir betik aracılığı ile vt'yi ve listener'ı açıp kapatıyorsanız, lsnrctl'ye yukarıda verilen komutları sırasıyla verdirmelisiniz. Bunun için listener.ora'nın olduğu dizine bir dosya yaratın (yalnız sizin okuyup yazacağınız olsun yine).

Diyelim ki yap.txt adında bir dosya olsun bu ve içine şu 3 satırı ekleyin:

set current_listener LISTENER
set password denemesifre
stop

Artık yazacağınız scripte listener'ı kapatmak için şu komutu verebilirsiniz.

lsnrctl < $ORACLE_HOME/network/admin/yap.txt

Ya da bu dizinde iken şöyle bir komut:

$ lsnrctl < yap.txt

3.5.   Veritabanı'na Erişimi Kısıtlama

Sisteme erişimi kısıtlama dışında bazı kullanıcılara erişimi kısıtlamak da isteyebilirsiniz. Bu kullanıcılar farklı amaçlarla sisteme bağlansa da bu sayede SQL komutu çalıştıramaz durumda olacaklardır. Yapmanız gereken ilk iş ORACLE_HOME altındaki network/admin dizinine gitmek. $ cd $ORACLE_HOME/network/admin/
Burada protocol.ora diye bir dosya oluşturun. Daha sonra bunun içine aşağıdaki gibi satırlar ekleyebilirsiniz.

tcp.validnode_checking=yes tcp.invited_nodes=(12.1.72.1,12.1.72.2,12.1.72.8) tcp.excluded_nodes=(12.1.72.10)

Bu örnekte 12.1.72.1,12.1.72.2 ve 12.1.72.8 IP'lerinden gelen kullanıcılar veritabanına erişip SQL komutları çalıştırabilecek ama 12.1.72.10 IP'sine sahip olan kişi SQL komutları çalıştıramayaacktır.
Buradaki SQL komutları çalıştırmaktan kasıt doğrudan sqlplus, TOAD vb araçlarla bağlanıp komut vermektir. Yoksa bir arayüz ile arka tarafta çalışan bir kullanıcı ile farklı SQL komut çalıştırılabilir.
 

4.    Güvenliği Sağladım mı?

Yukarıdaki adımları gerçekleştirdiniz. Artık tamamen güvende misiniz?

Keşke bu sorunun yanıtı evet olsaydı. Yalnızca daha güvenlisiniz artık. Hem veri güvenliği olarak hem de olası saldırılara karşı. Bu yaptıklarınızla birçok sorunu giderebilir durumdasınız.

Birçok insan bir dizi önlem aldıktan sonra işini tamamladığını düşünmekte. Oysa yazılımlar çıktıktan aylarca sonra da yeni açıklar, yeni sorunlar çıkabiliyor. Bir VTY
olarak yukarıdaki adımları zaten yapmanız beklenir. Bunun dışında da olası hataları ve güvenlik açıklarını izleyerek, ürün güncelleştirmelerini yapmalı, yamaları uygulamalı ve önlemleri almalısınız.Ayrıca sisteminizde ne olup bittiğini de izlemelisiniz.

Bunlar için Oracle'ın web sayfalarından;

metalink.oracle.com
ve
otn.oracle.com

adreslerini izlemenizi öneririm. Ama sakın bunlarla yetinmeyin, diğer güvenlik sitelerini de izleyin. Oracle'ın duyurmadığı ya da çok geç duyurduğu açıkları, sorunları başka sitelerde görebiliyorsunuz.