Bilişim Belgeleri
Oracle Veritabanı'nda Veri ve Sistem Güvenliği
Yazan: Mengü Yazıcıoğlu
© : www.oracledanismanlik.com ve E-Kitap.orgHer hakkı saklıdır.
İ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
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 iletmenizi dilerim.
Mengü Yazıcıoğlu
Ankara,Türkiye
Bu belgedeki kısaltmalar 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.
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.
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.
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.