CISA artık Türkçe..

ISACA İstanbul tarafında CISA Sınavının Türkçeleştirilmesi amacıyla bir süredir çalışmalar devam ediyordu. Toplantılarda ve çalışmalarda gönüllerden geçen ve sınavın Türkçeleştirilmesine yönelik çalışmaların meyvesini aldığımıza yönelik maili bugün Kaya Hocam bizlerle paylaştı.

Hedef Haziran 2015 sınavından itibaren CISA sınavının Türkçe sunulması ve kamu kesimi başta olmak üzere sektörde anadilimizde de sertifikasyonun sağlanması. Malumunuz son dönemlerde BDDK, SPK, KGK bünyelerinde gerçekleştirilen çeşitli çalışmalar ve taslak tebliğler Bilgi Teknolojileri Denetimi'nin ve doğal olarak sertifikasyonun önemini günden güne artırmakta. Bilgi Teknolojileri fonksiyonlarına yönelik denetim ve yönetişim farkındalığı her geçen gün artmaktadır.

Elbette CISA'nın Türkçeleştirilmesi önemli aşamaların kat edilmesi ve ISACA International nazarında ülkemizin BT Denetim ve Yönetişim alanının gelişmekte olduğunu, kaliteli bir ivme ile gelişmeye devam edildiğinin anlatmak ve doğru temasların sağlanması ile oldu. Bu noktada ISACA'nın belirlediği bazı çalışmalar yetkililer ile paylaşıldı ve CISA Sınavının Türkçe sunulmasına yönelik gereken olurlar alındı.

Bu noktada sektörün anadilimizdeki sertifikasyon ile de gelişecek olmasını önemsiyor ve Türkçe olması münasebetiyle kamu kesimi tarafından da yüksek bir kabul ile karşılanacağını düşünüyorum.

Bu noktada başta CISA'nın Türkçeleştirilmesine yönelik dokümantasyonda önemli rolü olan sayın Kaya Kazmirci, Yekta Bahadıroğlu ve başkanımız Mustafa Gülmüş özelinde bütün ISACA Ailesine ve emeği geçen herkese teşekkür etmek isterim.

Sektörün gelişmesine yönelik önemli adımlar atıldıkça içerisinde olmanın ayrı bir keyif olduğunu belirtmek istiyorum.

ISACA İstanbul komitelerinde çeşitli görevlerde yer alarak sizler de bu keyfi yakinen yaşamak isterseniz ISACA İstanbul'un kapıları sizlere sonuna kadar açık olacaktır.

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.

Oracle Veritabanı Denetim Rehberi I

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 aşağıdaki gibidir:

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 veri tabanı erişim ve yetkilendirmeye yönelik başlıklar, öneri olabilecek kontroller incelenecek, sonraki yazılar ile ise diğer maddeler değerlendirilmeye 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.

Türkçe bir kaynak olması ve faydalı olacağı düşüncesi ile İç Denetim Koordinasyon Kurulu tarafından hazırlanan ve Oracle Veritabanı denetimini 3 temel başlık altında inceleyen Kamu Bilgi Teknolojileri Rehberi ayrıca önerilmektedir. Rehber Oracle Veritabanı denetimini aşağıdaki başlıklarda detayı ile incelemektedir.

1.       Kullanıcı Hesap Yönetimi ve Parolalar

2.       Kritik Dosyalara Erişim

3.      Parola ve Güvenlik Parametreleri

Rehbere http://www.idkk.gov.tr/Sayfalar/HaberDetay.aspx?rid=61&lst=MansetListesi adresinden erişim sağlayabilirsiniz. 

Erişim ve Yetkilendirme: Hesaplara ve şifrelere yönelik uygun kontrollerin tasarlanması, işletilmesi, kontrollerin sürekli iyileştirilmesi, kontrollerin başarımının periyodik olarak izlenmesi önemlidir. Sistemde yer alan bütün kullanıcıların(iç, dış ve geçici kullanıcılar) ve kullanıcı hareketlerinin özgün olarak tanımlanabiliyor olması gerekmektedir.

1) DBA’lerin veri tabanına nasıl erişim sağladıkları önemli bir husustur. DBA’ler tarafından CONNECT INTERNAL opsiyonunun kullanılmadığından emin olunmalıdır. Çünkü Internal olarak gerçekleştirilen bağlantı ile sistemde en  yetkili kullanıcı olan SYS olarak tanınılmaktadır ve Internal bağlanma veri tabanının açılıp, kapatılması amacıyla tasarlanmış bağlantı opsiyonudur. Bunun yanı sıra her DBA’in kendine ait hesap ile sisteme log on olduğundan ve veri tabanını yönettiğinden emin olunmalıdır. Ortak hesaplar ile yapılan yönetimler her hangi bir inceleme ya da araştırma faaliyeti esnasında inkar edilebilirlik açısından problem yaratmaktadır.

2)Aşağıdaki komut yardımı ile sistem kullanıcılarının listesini alıp, listede DBA’lerin ayrı hesaplara sahip olma durumunu kontrol edebilirsiniz.

Select * FROM DBA_USERS;

3) Default Profile için gerçekleştirilmiş ayarları aşağıdaki komut ile alıp, inceleyebilirsiniz.

SELECT * FROM DBA_PROFILES;

4) Kullanıcı listesinde generik ve ortak kullanıma konu olabilecek kullanıcıları tespit edebilirsiniz. Uygulamalar tarafından kullanıcıları tespit edip, sadece uygulama tarafından kullanıldığının nasıl sağlandığını dinleyebilirsiniz.

5) Hesaplara atanmış olan profilleri inceleyip, uygun olmayan profil-kullanıcı atamalarını tespit edebilirsiniz.

6) DBA’ler tarafından sisteme kayıt edilen kullanıcıların ilk şifrelerinin nasıl dağıtıldığını dinleyebilir, belirlenmiş ortak şifrenin ya da kolay tahmin edilebilir bir şifrenin ilk dağıtımda kullanılmadığından emin olabilirsiniz.

7) Şifre değiştirme frekansı, şifre uzunluğu, eski şifrenin kullanımı gibi şifre yönetimine yönelik özelliklerin kullanıcılara sağlanan bilginin hassasiyetine göre politikalar ile belirlendiğinden emin olabilirsiniz. Kullanıcı profillerine göre farklı tanımlamalar yapılabilir. (Kullanıcı, yönetici, teknik personel, sistem yöneticisi gibi)

8) Aşağıda sıralanan şifre kontrolleri ve kaynak limitlerinin tahsisine yönelik olarak profil ayarlarını inceleyebilirsiniz.

· COMPOSITE_LIMIT

· SESSIONS_PER_USER

· CPU_PER_SESSION

· CPU_PER_CALL

· LOGICAL_READS_PER_SESSION

· LOGICAL_READS_PER_CALL

· IDLE_TIME

· PRIVATE_SGA

· CONNECT_TIME

· FAILED_LOGIN_ATTEMPTS

· PASSWORD_LIFE_TIME

· PASSWORD_REUSE_TIME

· PASSWORD_REUSE_MAX

· PASSWORD_VERIFY_FUNCTION

· PASSWORD_LOCK_TIME

· PASSWORD_GRACE_TIME

 9) DBA ve Güvenlik Yöneticisi ile acil durumlar için veritabanına erişime yönelik süreci konuşup, acil durumlar için erişime yönelik prosedürlerin tasarlandığından, vuku bulan acil erişimlerin dokümante edilmesine ve gerekli erişim sağlandıktan sonra erişimin yok edilmesine yönelik süreçlerin tasarlanmasından emin olabilirsiniz.

10) init<SID>.ora içerisinde REMOTE_OS_AUTHENT parametresini kontrol edip, OS Security’nin kullanılır olduğundan emin olabilirsiniz. REMOTE_OS_AUTHENT “false” olarak ayarlandığından emin olabilirsiniz. Bu parametre FALSE ise uzaktan password file dosyası olmadan sysdba ile bağlanamazsın anlamına gelmektedir. Parametre “true” ayarlandıysa buna olan ihtiyacı değerlendirmelisiniz.

11) Eğer OS Authentication kullanılıyor ise init<SID>.ora içerisindeki OS_AUTHENT_PREFIX parametresini kontrol etmelisiniz. Aşağıdaki komutu kullanarak password file dosyası ile bağlanma yetkisine sahip olan kullanıcıları listeleyebilirsiniz. Listeledikten sonra DBA ile bu şekilde erişime ihtiyaç duyulmasının nedenini tartışabilir, ihtiyaç ve riskliliğe göre değerlendirme yapabilirsiniz.

SELECT * FROM V$PWFILE_USERS;

12) Hizmet tedarik edilen firmalar, danışmanlar gibi dış paydaşlara yönelik erişim sağlanması ve erişim yetkilerinin sonlandırılmasına yönelik prosedür ve işleyişleri tartışabilir. Erişim sağlanmasının sadece iş ihtiyacı için gerektiği kadar, iş sorumluluklarına uygun verilmesi ve uygun zaman içerisinde yok edilmesine yönelik işleyişi değerlendirebilirsiniz.

Sonraki yazılarımda diğer alt başlıklara değiniyor olacağım. Faydalı olması dileğiyle.