Oracle Veritabanı Denetim Rehberi II

Önceki yazımda Oracle ürüne yönelik denetim esnasında denetçiler açısından üzerinde durulan ve ağırlıkla teknik konuları içeren başlıkları sıralamış ve bu başlıklardan erişim ve yetkilendirme üzerinde detayı ile durmuştum.

Anımsamak adına başlıkları tekrar sıralamak gerekirse;

1.       Erişim ve Yetkilendirme

2.       Güvenlik Süreçleri ve İzleme

3.       Yedekleme ve Yedekten Dönme

4.       Şifreleme

5.       Güvenilir İlişkiler (Trusted Relationships)

6.       Ağ Güvenliği

Bu yazı kapsamında güvenlik süreçleri ve izleme ile yedekleme ve yedekten dönme faaliyetleri detaylandırılarak, Oracle Veritabanı Denetim Rehberi isimli blog serisine devam edilecektir.

Yazılar oluşturulurken ISACA’nın Security, Audit and Control Features Oracle Database, 3rd Edition (Dec 2009) isimli rehberinden faydalanılmıştır.

Güvenlik Süreçleri ve İzleme:

Veritabanı üzerinde tanımlı olan kullanıcılar iş sorumlulukları ile uyumlu olacak şekilde ve ihtiyaçları kadar bilgiye ulaşabilecek şekilde yetkilendirilmelidirler.

Genel ve özel amaçlı kullanıcılar için yeterli erişim haklarının verilmesi ve alınmasına yönelik süreçlerin tasarlandığından emin olunmalıdır.

1)   Kullanıcılara veritabanına erişim yetkisinin verilmesi ve yetkinin alınması sürecini inceleyebilirsiniz. İlk kullanıcının tanımlanması ve işten ayrılan kullanıcıların yetkilerinin alınması sistematik bir şekilde işletilmelidir.

2)   Aşağıdaki komutu alarak veritabanında tanımlı kullanıcı listesini edinebilirsiniz:

a.    SELECT * FROM DBA_USERS;

3)   Aşağıdaki komut yardımı ile sistemde tanımlı olan rollerin listesini edinebilirsiniz, rollerin uygulama seviyesinde tanımlanan güvenlik seviyelerine ya da iş süreç sahipleri tarafından tanımlanan Görevler Ayrılığı ihtiyaçlarına uygun tasarlanması durumunu irdeleyebilirsiniz;

a.    SELECT * FROM DBA_ROLES;

4)   Veritabanında yer alan kullanıcıların atanmış rolleri ile birlikte listesini aşağıdaki komutu çalıştırarak edinebilirsiniz;

a.    SELECT * FROM USER_ROLE_PRIVS;

5)   Belirlediğiniz bir örneklem üzerinde denetim dönemi içerisinde tanımlanan kullanıcıların ve/veya hali hazırda sistemde tanımlı olan kullanıcıların rollerinin ilgili iş/sistem sahibi tarafından onaylanma ve tanımlanan rollerin iş sorumlulukları ile uyumlu olması durumunun inceleyebilirsiniz.

6)   Kullanıcılara atanmış olan roller ile kabul edilmiş rol taleplerini karşılaştırıp, rollerin düzenli atanma durumunu inceleyebilirisiniz.

7)   DBA_SYS_PRIVS, ROLE_PRIVS, ROLE_ROLE_PRIVS ve ROLE_TAB_PRIVS viewlarını görüntüleyerek, rollerin ve ayrıcalıkların (privs) kullanıcılara grup halinde atandığından emin olabilirsiniz. Burada atamaların iş gereksinimleri ile uyumlu olması önemlidir. Yönetsel bağlamda önerilen ayrıcalıkların roller üzerinden atanmasıdır. Kullanıcılara direkt olarak atanan ayrıcalıklara biraz daha dikkat etmeniz gerekebilir.

8)   Denetim dönemi içerisinde işten ayrılan personelin listesini İnsan Kaynaklarınden edinip, veritabanı üzerinde silinen ya da pasif hale getirilen kullanıcıların listesi ile karşılaştırıp, gerektiği zamanlarda hesapların kullanılamayacak duruma getirildiğinden emin olabilirsiniz.

9)   Aşağıdaki komut yardımı ile kullanıcıların DBA_SOURCE view’ı üzerinde erişim yetkilerinin olmadığını doğrulayabilirsiniz. dba_source subprogramların yani paket, procedure, fonksiyon, trigger gibi objelerin scriptlerinin tutulduğu data dictionary viewıdır. Yönetsel durumlar haricinde kullanıcılar tarafından görülmesi önerilen bir view olmadığını söyleyebilirim.

a.    SELECT * FROM DBA_TAB_PRIVS WHERE TABLE_NAME = 'ALL_SOURCE';

10)INSERT, UPDATE ve DELETE ayrıcalığına sahip rolleri ve kullanıcıları kontrol edebilirsiniz. Bu ayrıcalıkların ilgili rol ve/veya kişilere verilmesine yönelik olarak iş ihtiyaçlarını değerlendirebilirsiniz.

11)DBA gibi yüksek yetkili kullanıcı rollerine sahip kullanıcı hesaplarını belirleyip, iş ihtiyaçları ile değerlendirmesini yapabilirsiniz.

12)Rollerin WITH ADMIN OPTION opsiyonu ile sadece iş gereksinimleri açısından çok gerekli olduğu durumlar için oluşturulduğundan emin olabilirsiniz. Bunun için aşağıdaki komutu çalıştırıp, WITH ADMIN option ile oluşturulduğunu gözlemleyebilirsiniz. WITH ADMIN opsiyonu ile bojelere yönelik değil, sisteme yönelik ayrıcalıklar tanımlanabilmektedir. (CREATE TABLE,CREATE INDEX,CREATE SESSION)

a.    SELECT * FROM DBA_ROLE_PRIVS WHERE ADMIN_OPTION = 'YES';

13)PUBLIC hesaba herhangi bir ayrıcalık tanımlanıp, tanımlanmadığını aşağıdaki komutlar yardımı ile inceleyebilirsiniz;

a.    SELECT OWNER, TABLE_NAME, GRANTOR, PRIVILEGE FROM DBA_TAB_PRIVS WHERE GRANTEE = 'PUBLIC' AND GRANTOR <> 'SYS' AND GRANTOR <> 'SYSTEM';

b.    SELECT GRANTED_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'PUBLIC';

14)Kullanıcılara ve rollere atanan ayrıcalıkları gözden geçirebilirsiniz. DBA ile gruba değil de direkt kullanıcılara atanan ayrıcalıkları tartışabilirsiniz.

a.    SELECT * FROM DBA_TAB_PRIVS;

b.    SELECT * FROM DBA_SYS_PRIVS;

15)SYS ve SYSTEM’in SYSTEM tablosunde yer alan bütün objelere sahip olması durumundan emin olabilirsiniz.

16)Data Dictionary’e erişime yönelik güvenlik önlemlerini gözden geçirebilirsiniz. Aşağıdaki sorgu ile O7_DICTIONARY_ACCESSIBILITY ayarını inceleyebilirsiniz.

a.    SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME = 'O7_DICTIONARY_ACCESSIBILITY';

Eğer ki bu değer TRUE olarak set edilmiş ise SELECT ANY TABLE ayrıcalığına sahip kullanıcıları gözden geçiriniz. Çünkü bu tabloda yer alan bütün kullanıcılar Data Dictionary’de yer alan bütün bilgiyi görebilmektedirler. “Sistem kataloğu (system catalogue)” olarakta bilinen “Data Dictionary” ,veritabanında tutulan her türlü objenin metadata’sının (veri hakkında verinin) tutuldugu yerdir. Aynı zamanda DBMS hakkında bilgilerde burada tutulmaktadır. Peki bu metadata(veri hakkında veri) ile kastedilen nedir? Bir tablomuz olduğunu düşünerek özetlemek gerekirse bir tablonun “data dictionary” de tutulan metadata’sı içerisinde adı, ne zaman oluşturulduğu, en son ne zaman ulaşıldığı, sahibi, izin bilgileri, datanın tutulduğu yer hakkında fiziksel bilgiler gibi bilgiler tutulmaktadır.

17)GRANT opsiyonu ile atanan bütün ayrıcalıkları aşağıdaki sorguyu çalıştırarak inceleyebilir, DBA ile gerekliliğini tartışabilirsiniz. GRANT opsiyonu ile obje ayrıcalıkları tanımlanabilmektedir ve yetkiyi sadece imtiyaz sahibi kişi iptal edebilmektedir. Yetki tanımlama Cascade (kademeli) bir yapıya sahiptir demek doğru olacaktır.

a.    SELECT * FROM DBA_TAB_PRIVS WHERE GRANTABLE = 'YES'

Yedekleme ve Yedekten Dönme: Denetim kapsamında periyodik aralıklar ile test edilen bir yedekleme ve yedekten dönme stratejisinin varlığı irdelenir.

1)     Oracle Veritabanı Uygulamasının Servis Seviye Anlaşmasını edinebilirsiniz. (SLA) Veritabanı impelentasyon ve sistemlerin işletimi içerde bir ekip tarafından yönetiliyor ise Operasyonel Seviye Anlaşmasını edinebilirsiniz. (OLA)

2)     Servis seviye anlaşması içerisinde Oracle Veritabanı implamantasyonuna yönelik hükümlerin varlığı irdelenebilir.

3)     Oracle İş Sürekliliği Planı ya da veritabanını ilgilendiren geri dönüş tanımlarını içeren planı edinebilirsiniz.

4)     İş Sürekliliği Planının Oracle veritabanı ile alakalı yedekleme ve yedekten dönme süreçlerini içerme durumu irdelenebilir.

5)     DBA ile yedekleme ve yedekten dönme stratejisi görüşülebilir. DBA ile yaptığınız görüşmede stratejinin düzenli gözden geçirilme durumunu inceleyebilirsiniz. En son gerçekleştirilen testlerin dokümantasyonunu inceleyebilirsiniz.

6)     init<SID>.ora dosyasının bir kopyasını edinebilirsiniz.

7)     LOG_ARCHIVE_START parametresini gözden geçirebilirsiniz. “True” olarak set edilmiş ise ARCHOVELOG mode aktif edilmiştir. LOG_ARCHIVE_DEST ve LOG_ARCHIVE_FORMAT parametrelerini log dosyalarının yeri ve formatı hakkında bilgi edinmek için inceleyebilirisiniz.

8)     DBA ile düzenli arşivleme dosyalarının canlı olmayan medyaya (offline) yedeklenmesi üzerine prosedürü konuşabilirsiniz. Offline medyanın korunması ve saklanmasına (retentation) yönelik prosedürlerin varlığını sorgulayabilirsiniz.