Günümüzde, kurumlar için en önemli varlık “veri”dir. Peki nedir bu veri? Bankalar ve telekomünikasyon kurumları için veri, Müşteri Bilgisi (anne kızlık soyadı, adres, telefon, mevduat bilgisi, en çok kullanılan servisler vb) olarak adlandırılabilir. Kurumlar bu bilgilerin bütünlüğünden (integrity), erişilebilirliğinden (availability) ve gizliliğinden (confidentiality) sorumludur. Veriyi kullanarak kurumlar gelir elde ederler. Bu durumda veri, ticari bir varlık olarak da nitelendirilebilir. Aynı zamanda, bu bilgileri kullanarak kanun düzenleyiciye sundukları raporların doğruluğundan da sorumludurlar.
Buraya kadar, verinin ne olduğundan ve ne işe yaradığından bahsettik. Peki, bu derece önemli bir varlığı nasıl korumalıyız? Ya da korunduğunu nasıl denetim kanıtı olarak denetimlerde nasıl göstermeliyiz?
Bilgiyi fiziksel ve mantıksal olarak koruyabiliriz. Fiziksel olarak, güvenlik görevlileri, döner kapılar, çelik kasalar vb; mantıksal olarak ise, verinin saklandığı sunucudan başlayarak onu işleyen son kullanıcıya kadarki döngüde geçen her sistem sayılabilir.
Yasal zorunluluklar (BDDK, BTK, SOX, PCI vb) nedeniyle veriye olan her tür erişim talebinin yetkilendirilmesi, erişimlerin de kayıt altına alınması gerekmektedir (least priviledge, need-to-know).
Kurumlar, denetimler için çeşitli bağımsız denetim firmaları ile çalışarak, gerçekleştirdikleri operasyonları nasıl kontrol ettiklerini ilgili denetim kanıtları ile ispatlamak zorundadırlar. Sürmekte olan teknik operasyonlara gerekli kontrol noktaları ilave ederek denetim kanıtı sunmak tüm kurumlar için başarılı denetimin en önemli başlangıç noktasıdır.
Denetimlere hazırlanırken de, kendi öz değerlendirmelerini yapmak ve gerekli kontrolleri devreye almak denetimlerde sorun yaşamamak adına en önemli yardımcıları olacaktır. Peki, bu denetimlerde neler nasıl kontrol edilmektedir?
Bu yazımızda, bunları açıklarken gerekli sql cümleciklerini ve çıktılarının nasıl yorumlanacağından bahsedeceğiz.
Denetimlerde, öncelikle kullanıcı hesapları, üye oldukları roller ve sahip oldukları haklar en büyük paya sahip diye düşünebiliriz. Bu denetimleri yaparken uygulama kullanıcılarımızı kısmen bu işin dışında tutmamız gerekiyor. Çünkü uygulama kullanıcıları, doğası gereği uygulama sunucuları üzerinden gelecekleri ve uygulama sahibinin scheması altında tüm tablolar üzerinde yetkileri olması gerektiği için denetimlerde sadece Yetkili IPden ve uygulamadan geldiğinin kontrolü yeterlidir. Ama bu şu demek değildir, uygulama userı full yetkiye sahip olabilir, örneğin dba yetkisine! Hayır, sadece uygulama sahibinin schemaları üzerinde yetkiye sahip olmaları gerekmektedir. Dolayısıyla sistemde dba yetkisine sahip kullanıcılar kimlerdir diye bakarken bu kullanıcılara da dikkate alınır ancak select dışında kimlerin yetkisi var gibi bir denetim maddesine bakarken bu kulanıcılar hariç tutularak bakılması gerekecektir.
Örneğimizde de hemen hemen tüm bankalarda bir INFRA scheması olduğunu düşünerekden uygulama ownerımız INFRA, uygulama userlarımız APP_INFRA1, APP_ INFRA2, APP_ INFRA3 olsun.
Aşağıdaki sorguların outputlarında örnek olması açısından bir sadece kısmını yazıya ekliyor olacağız. Dolayısıyla sizlerdeki sorgu sonuçları satır ve sutun sayıları bakımından farklılık gösterebilir. Aşağıdaki maddeleri örneklerle açıklayabilmek için data oluşturabilmek adına test ortamım da farklı isimlerde bir takım userlar oluşturarak farklı yetkiler atadık.
Son olarak production ortamlarda oluşturulan tüm userların create edilme talepleri ve bu userlara verilen tüm yetkilere ait yetki talepleri (tabi gerekli onay aşamalarından geçmiş ve onaylanmış olmaları şartıyla) olmaları gerekmektedir. Bu durum aşağıdaki tüm maddeler içinde geçerli olduğundan dolayı her maddede sürekli olarak bu hatırlatmayı yapmamak için burada özellikle belirtmek istiyoruz. Denetim ekibi bir userda olmaması gereken bir yetkiye rastladıklarında bu yetkinin kim tarafından ve ne zaman verildiğini sizden belgelemenizi isteyeceklerdir. Dolayısıyla da sizin de bunu (bu genelde güvenlik departmanının sorumluluğunda olan bir süreçtir) gösterebiliyor olmanız gerekmektedir.
Artık denetim maddelerimizin üzerinden sırayla geçmeye başlayabiliriz;
1 – Select Yetkisi Dışında Yetkisi Olan Tüm Kullanıcıların Tespiti ;
Burada beklenilen database’ i manage eden dba’ ler dışında her kim olursa olsun (kimi zaman dba’ lerin bile dba yetkileri sorgulanabilmektedir!) database’ de update, delete vs gibi kritik yetkilerin olmaması gerektiğidir. Bu sorgu sonucunda bu yetkiye sahip kullanıcılar çıkabilir, bunu da denetimcilere ikna edebilecek şekilde gerekliliğini açıklayabiliyor olmanız gerekmektedir.
Account statusu locklı olan userlar haricindekleri bulmak için aşağıdaki sorguyu kullanabiliriz;
SELECT *
FROM dba_tab_privs
WHERE privilege NOT IN (‘SELECT’)
AND grantee NOT IN (‘APP_INFRA1’, ‘APP_INFRA2’, ‘APP_INFRA3’)
AND grantee NOT IN (SELECT username
FROM dba_users
WHERE account_status = ‘LOCKED’)
ORDER BY privilege
Sorgunun çıktısı ;
Bu sorgu sonucunda gelen tüm userlar incelenerek örneğin, ozgul kullanıcısının neden infra scheması altındaki satis_detay tablosuna ALTER yetkisi olduğu açıklanır. Önceden kalmış olan veya yanlışlıkla verilmiş olan yetkiler var ise bunlar geri alınır.
2 – Database’ de Kritik Bir Takım Önemli Rollere Sahip Olan Kullanıcıların Tespiti ;
Kritik role’ den nelerin kastedildiğini aşağıdaki sorgu içerisinden görebilirsiniz. (Kontrol aşamasında bakılan temel roller bunlardır ama denetmenin talebi doğrultusunda değişiklik gösterebilir)
SELECT *
FROM dba_role_privs
WHERE granted_role IN
(‘SELECT_CATALOG_ROLE’,
‘DELETE_CATALOG_ROLE’,
‘EXECUTE_CATALOG_ROLE’,
‘DBA’,
‘DROP ANY TABLE’,
‘ALTER TABLE’,
‘ALTER ANY TABLE’,
‘DROP TABLE’,
‘ALTER SYSTEM’,
‘CREATE ANY TABLE’,
‘CREATE TABLE’)
Sorgunun çıktısı ;
Yukarıdaki kullanıcıların neden bu yetkiye sahip olmaları gerektiği açıklanır. Önceden kalmış olan veya yanlışlıkla verilmiş olan yetkiler var ise bunlar geri alınır.
3 – Kullanıcı Hesapları Kontrolü ;
Database’ de yer alan tüm kullanıcıların accountlarının statüslerine bakılır. Firmada çalışmadığı halde hala userı olup ve locklı olmayanlar tespit edilmeye çalışır. (çalışan kullanıcı bilgileri listesinin güncel haline IK biriminden ulaşılır)
SELECT username, account_status FROM dba_users;
Sorgunun çıktısı ;
4 – Siteme X Gündür Erişim Yapmamış Olan Kullanıcıların Tespiti ;
Sizin firmanızdaki çalışan sayınıza bağlı olarak yüzlerce userınız olabilir, dolayısıyla bunların zaman zaman içerisinde personel sirkülasyonuda düşünüldüğünde takibinde bir takım aksaklıklar çıkabilir. Bu tarz aksaklıkları gözlemleyebilmek/tespit edebilmek için kullanıcıların sisteme log on – log off aksiyonlarını loglayarak örneğin 1 aydır sisteme hiç giriş yapmayan kullanıcıları tespit edebilirsiniz. Bunu tespit edebilmenin iki yolu bulunmaktadır. Birincisi database’ de oracle’ ın audit parametrelerini kullanarak bir auditing yapıyorsanız aşağıdaki sorguyu kullanabilirsiniz ;
SELECT DISTINCT (u.username)
FROM dba_users u
WHERE account_status = ‘OPEN’
AND NOT EXISTS
(SELECT ‘x’
FROM dba_audit_trail A
WHERE u.username = a.username
AND a.logoff_time > SYSDATE – 30);
Sorgunun çıktısı;
Buradaki gün değeri parametrik olup (SYSDATE – 30) istenirse bu aralık azaltılıp artırılabilinir.
Eğer auditing için third-party bir uygulama kullanıyor ve oracle tarafındaki audit parametreleriniz tümüyle kapalı ise (örneğin Guardium yazılımını kullanıyosanız db tarafında ayrıca bir auditing parametresi açmanıza gerek olmayacaktır.) yazacağınız bir trigger ile connectionları loglayabilir ve sonrasında bu logları dba_users tablosundaki userlar ile karşılaştırabilirsiniz.
Logon trigger yapılandırılması için;
3rd party Audit Uygulamalası için;
http://www.bilgiguvenligi.gov.tr/kayit-yonetimi/veritabani-loglama.html
linkleri yardımcı olacaktır.
5 – Database’ de Kritik Bir Takım Yetkilere Sahip Olan Kullanıcıların Tespiti ;
3 nolu madde de kritik rollere sahip kullanıcılardan bahsetmiştik. Burada ise kritik yetkilere sahip kullanıcıları nasıl tespit edebileceğimizden bahsedeceğiz.
Bunun için aşağıdaki sorgudan faydalanabiliriz;
SELECT *
FROM dba_sys_privs
WHERE PRIVILEGE IN
(‘SELECT ANY TABLE’
‘SELECT ANY DICTIONARY’,
‘CREATE LIBRARY’,
‘CREATE ANY LIBRARY’,
‘ALTER ANY LIBRARY’,
‘EXECUTE ANY LIBRARY’,
‘CREATE PROCEDURE’,
‘EXECUTE ANY PROCEDURE’,
‘ALTER SESSION’,
‘BECOME USER’,
‘ALTER SYSTEM’)
Sorgunun çıktısı;
Bu çıktı sonucunda olmaması gereken userlar var ise açıklamaya devam ediyor olacağız.
6 – With Admin Option Opsiyonu ile Atanmış Olan (Role & System) Yetkilerin Tespiti ;
Kullanıcılara yetkileri vermenin bir yolu grant komutunun sonuna with admin option komutu eklemektir. Bu şekilde grant vermeniz durumunda yetkiyi verdiğiniz bu kullanıcı sahip olduğu bu yetkiyi istediği bir kullanıcıya atayabilir demektir. Yani aslında sadece yetkiyi değil, yetkinin bir anlamda devir edebilme hakkını da vermiş oluyorsunuz. Dolayısıyla zaman zaman açık olarak değerlendirilmektedir. Bu durumu tespit edebilmek için aşağdıki sorgu kullanılabilirsiniz;
SELECT ‘ROLE’, grantee, granted_role
FROM dba_role_privs
WHERE admin_option = ‘YES’ AND grantee NOT IN (‘SYS’, ‘SYSTEM’, ‘DBA’)
UNION
SELECT ‘SYSTEM’, grantee, PRIVILEGE
FROM dba_sys_privs
WHERE admin_option = ‘YES’ AND grantee NOT IN (‘SYS’, ‘SYSTEM’, ‘DBA’)
Scriptin çıktısı ;
Bu durumunda, bir açıklamanız olduğunu varsayarak devam ediyoruz J
Burada system ve role privilege’ lerinden with admin option opsiyonu ile yetkilendirme olup olmadığını kontrol ettik.
19. madde de yine bu kapsamda değerlendirilebilir, object grantları verilirken with admin option opsiyonu ile verilmiş olanları bulabilirsiniz.
7 – Auditing Parametrelerinin Kontrol Edilmesi ;
Burada hedeflenen Oracle’ın Auditing sistemini kullanarak bir auditing yapıyorsanız burada auditing ile ilgili sistem parametrelerinin nasıl set edildiğini sorgulamak için aşağıdaki scriptten yaranılabilir ;
SELECT name, value FROM v$parameter WHERE NAME LIKE ‘%audit%’
Scriptin çıktısı ;
Burada audit_trail set edilmiş olmalı, audit_sysoperations TRUE olarak set edilmeliki sys’ nin yapmış olduğu tüm işlemlerde audit kapmamına alınmış olsun.
Oracle’ da auditing işlemleri için aşağıdaki makale yardımcı olacaktır;
http://www.kamilturkyilmaz.com/2011/01/21/oracle%E2%80%99-da-audit-mekanizmasi/
8 – Hangi Yetkilerin Audit Edildiğinin Tespit Edilmesi ;
Burada yine auditing açık olabilir ama hiçbirşeyi auditlemiyorda olabilirsiniz fikrinden hareketle aslında neleri auditlediğinizi sorgulama için yapılan bir denetim aşamasıdır. Hangi yetkilerin auditlendiğini tespit etmek için aşağıdaki sorguyu kullanabilirsiniz;
SELECT * FROM sys.dba_priv_audit_opts;
Sorgunun çıktısı ;
Hangi yetkilerin kullanıldığında audilendiği bilgisine buradan ulaşabilirsiniz. Audit edilmeyen yetkileri tespit etmek içinse aşağıdaki sorgudan faydalanabilirsiniz ;
SELECT privilege
FROM role_sys_privs
minus
SELECT privilege FROM sys.dba_priv_audit_opts;
Sorgu çıktısı ;
Yukarıdaki yetkiler ile yapılan işlemler audit kapmamında olmayan işlemlerdir. Burada şunu iyi değerlendirmek gerekir. Herşeyi auditlemek iyi bir çözüm değildir. Bu şekilde yapmanız durumunda milyonlarca datanın içinde boğulmak durumunda kalabilirsiniz. Örneğin Alter any index yetkisinin auditlenmesinin kime ne faydası olacaktır? Index’ i alter etmekle data üzerinde bir değişikliğe sebeb oluyor musunuz, kullanıcı datası yapılan bu işlemden ne kadar etkileniyor gibi sorulara vereceğiniz cevap aslında size audit yapıp yapmamanızı da söylüyor olacaktır. Hangi verinin loglanacağı, loglanacak olanların ne detayda loglanıp raporlarının kimlere iletilceği kurum içinde alınacak bir karardır.
9 – Hangi Objelerin Audit Edildiğinin Tespit Edilmesi ;
Bir önceki madde de role bazında auditing işleminin nasıl yapıldıüından bahsetmiştik. Bu kısımda da obje bazında da nelerin audit edilğini tespit ediyor olacağız. Bunun için aşağıdaki sorguyu kullanabiliriz ;
SELECT * FROM sys.dba_obj_audit_opts;
Sorgu çıktısı ;
Bunlar INFRA schemasındaki olan tablolardan hangi komutların auditing edildiğini gösteriyor.
10 – Hangi Statementların Audit Edildiğinin Tespit Edilmesi ;
Database’ de çalıştırılan hangi komutların auditlendiğini tespit etmek içinse aşağıdaki script kullanılabilir ;
select * from dba_stmt_audit_opts ;
Scriptin çıktısı ;
11 – Sistemdeki Profile Settinglerini Kontrol Etmek Edilmesi ;
Database’ deki profile settinglerini kontrol etmek için aşağıdaki sorguları kullanabilirsiniz ;
— Sistemde tanımlı olan profileleri sorgulamak için ;
SELECT distinct profile
FROM sys.dba_profiles
— Mevcut profilelerin nasıl set edildiğini görmek için ;
SELECT *
FROM sys.dba_profiles
Sorgunun çıktısı ;
Sistemde tanımlı olan her user mutlaka daha önceden tanımlanmış olan profile’ lere atanmış olmalıdır. Yöntem, uygulama userları için farklı bir profile, dba’ ler için farklı bir profile, yazılımcılar için farklı profile varsa diğer userlar içinde farklı bir profile tanımlaması yapılması şeklindedir. Örneğin uygulama userları için oluşturulacak profile’ da password_life_time, failed_logon_attemps gibi değerlerin unlimited olması gerekmektedir. Ancak diğer userlar için bu değerlerin mutlaka sınırlandırılmış olması gerekmektedir.
12 – Tüm Kullanıcılara ve Rollere Atanmış Olan Rolleri Kontrol Edilmesi ;
Bu madde ile dataabse’ de yer alan tüm kullanıcılara ve rollere (bir role farklı bir role’ de atanabileceğinden) verilmiş olan role yetkilerini göstermektedir.
SELECT *
FROM dba_role_privs
Sorgunun çıktısı ;
Burada da sahip olmaması gereken bir role sahip kullanıcı veya bir role grubu olup olmadığı kontrol edilmektedir.
13 – Database’ deki Public DB Link Kontrolleri ;
Farklı database’ ler arasında veri aktarımı sağlayabilmek için kullanılan database linkleri zaman zaman oluşturulma biçimlerine göre güvenlik açığı teşkil edebilmektedirler. Database linkler iki farklı şekilde oluşturulur; Birincisi private olarak create edilebilir ki, aslında önerilen yöntemi de budur. Private olarak create edilen bir link hangi userın altında oluşturuluyor ise sadece o user tarafından kullanılabilir. Public linkler ise denetim esnasında bulgu olarak belirtilen durumlardır ki, public olan bir link sisteme connect olan yetkili/yetkisiz herhangi bir user tarafından kullanılabilecek olan linklerdir. Bu linkleri tespit etmek için ;
select * FROM SYS.dba_db_links where status = ‘PUBLIC’
Sorgunun çıktısı ;
Database’ de public link olmamalıdır. Kontroller öncesinde olanlar var ise bunlar drop edilerek hangi user kullanıyor ise o userın schemasının altına oluşturulmalıdır. Bu işlemin nasıl yapılacağı ile ilgili detaylı bilgi için aşağıdaki makaleye yardımcı olacaktır:
http://www.kamilturkyilmaz.com/2010/11/10/database%E2%80%99-ler-arasi-link-kurulumu-dblink/
14 – Sistemde Sysdba Yetkisine Sahip Olan Kullanıcıların Tespiti;
Sysdba, oracle database’lerindeki en yetkili user’ dır. Dolayısıyla da çok kritik bir öneme sahiptir. Sistemde bu yetkiye sahip olan userlar sürekli olarak kontrol edilmelidir. Bu kullanıcıların tespiti için aşağıdaki sorguyu kullanabilirsiniz ;
SELECT * FROM v$pwfile_users;
Sorgunun çıktısı ;
Bu yetkiye sahip olmaması gereken userlar tespit edilirse, mutlaka yetki ilgili userdan revoke edilmelidir.
15 – Unlimited Tablespace Yetkisine Sahip Kullanıcıların Tespiti;
Unlimited tablespace yetkisine production ortamlarda genellikle uygulama ownerı dışında kimsenin ihtiyacı olmaması gerekmektedir. Çünkü production ortama veri girişi sadece uygulama scheması altına olmalıdır. En azından beklenti bu yöndedir. Çoğunlukla bazı kritik sistemlerin yönetilmesi için kimi developerlara zaman zaman sahip olması gerektiğinden daha fazla bir yetki verilmesi gündeme gelebilir. Bu tarz durumlarda bu sürecinde mutlaka sürekli olarak takip ediliyor olması gerekecektir. Aynı şekilde yetkinin verilmesi nedenin ve onay aşamalarınında mutlaka ispatlanabiliyor olması gerekmektedir.
SELECT grantee, privilege
FROM dba_sys_privs, dba_users
WHERE dba_users.username = dba_sys_privs.grantee
AND privilege = ‘UNLIMITED TABLESPACE’
AND dba_users.account_status = ‘OPEN’;
Script çıktısı ;
Bu yetkiye sahip olmaması gereken user tespit edilirse, yetki geri alınmalıdır. Userlara tablespace bazında da kota verilebilir ;
alter user murat quota 500 M on users ;
User bazında kotaları select etmek istersek ;
SELECT SUBSTR (TABLESPACE_NAME, 1, 10) TABLESPACE,
SUBSTR (USERNAME, 1, 15) USERNAME,
SUBSTR (BYTES, 1, 10) / 1024 / 1024 USED_MB,
DECODE (MAX_BYTES,
‘-1’, ‘Unlimited’,
SUBSTR (MAX_BYTES, 1, 10) / 1024 / 1024)
QUOTA_MB
FROM dba_ts_quotas;
Scriptin çıktısı ;
16 – Role İçerisindeki Yetkilerin Kontrolü ;
Öncelikle database’ deki tüm role’ leri listelemek için aşağıdaki sorgudan faydalanabiliriz.
select * from dba_roles;
Database’ de oluşturulan role’ lerin içerisindeki yetkileri kontrol etmek için aşağıdaki sorgu kontrol kullanılabilir;
select * from DBA_TAB_PRIVS where grantee=‘READ’;
SELECT * FROM role_sys_privs where role=‘READ’;
Yukarıdaki ilk sorgu ile READ isimli role’ içerisindeki object grantları, ikinci sorgu ilede system yetkileri kontrol edilmektedir.
İlk scriptin çıktısı ;
İkinci scriptin çıktısı ;
Bu örnekde READ isimli role içerisinde aslında olmaması gereken role’ ler olduğu gözlenmektedir. Buda bu haliyle bulgu olarak önümüze gelmektedir.
Role’ ler aslında üzerinde dikkatle durulması gereken noktalardan biridir. Neden bu kadar önemli olduğunu bir örnekle açıklamaya çalışalım. Örneğin database’ deki dba rolü bu tarz kontrollerde ilk bakılan yetkilerden biridir. Kimlerin dba rolüne sahip olduğuna denetçilerin mutlaka kontrol edeceğini herkes bildiği için kimi durumlarda kullanıcıya dba rolü vermek yerine dba rolünün içini dolduran yetkileri direk olarak kullanıcıya atama yoluna gidenler olabilmektedir. Ancak denetimler esnasında rollerinde mutlaka kontrol edildiği unutulmamalıdır.
Aşağıdaki sorgu ile dba role’ ünün sahip olduğu yetkilerden hangilerinin READ rolünde de olduğunu kıyaslamak istersek ;
SELECT * FROM role_sys_privs where role=‘READ’
and privilege in (
SELECT * FROM role_sys_privs where role=‘DBA’)
Bu sorguyu sonradan create edilen tüm role’ ler için kullanabilirsiniz.
Script çıktısı ;
17 – Oracle Kurulumu İle Birlikte Gelen Default Userların Kontrolü ;
Oracle database kurulumu ile birlikte kurulan Oracle componentlerine bağlı olarak kimi userlar default olarak gelir. Burada dikkat edilmesi gereken nokta bu default userların accountlarının locklanması, mümkünse silinmesidir. Default user listesi oracle’ ın versiyonuna göre farklılık gösterebilmektedir.
Oracle 10g ve 11g için default user listesini aşağıda belirtilmiştir:
SELECT username, account_status
FROM dba_users
WHERE username IN
(‘SYS’,
‘SYSTEM’,
‘DBSNMP’,
‘MDSYS’,
‘ORDSYS’,
‘ORDPLUGINS’,
‘CTXSYS’,
‘DSSYS’,
‘PERFSTAT’,
‘WKPROXY’,
‘WKSYS’,
‘WMSYS’,
‘XDB’,
‘ANONYMOUS’,
‘ODM’,
‘ODM_MTR’,
‘OLAPSYS’,
‘TRACESVR’,
‘REPADMIN’,
‘MGMT_VIEW’,
‘LBACSYS’,
‘OUTLN’,
‘FLOWS_FILES’,
‘EXFSYS’,
‘APPQOSSYS’,
‘APEX_030200’,
‘ORDDATA’,
‘ORDPLUGINS’,
‘SI_INFORMTN_SCHEMA’,
‘ORACLE_OCM’,
‘XS$NULL’,
‘DIP’,
‘APEX_PUBLIC_USER’)
Script çıktısı ;
18 – Sys, System, Sysman, Public Userları Dışındaki Tüm Userların System ve Object Grantlarının Kontrolü ;
Database’ deki tüm userların sahip oldukları (sys,system,sysman ve public userlar hariç) tüm system privilege’ leri ile object grantlarının görüntülenmesi için ;
SELECT grantee,
‘SYSTEM’,
‘–‘,
privilege
FROM dba_sys_privs
WHERE grantee NOT IN (‘SYSTEM’, ‘SYSMAN’, ‘SYS’, ‘PUBLIC’)
AND NOT EXISTS
(SELECT ‘x’
FROM dba_roles
WHERE role = grantee)
UNION
SELECT grantee,
‘TABLE’,
table_name,
privilege
FROM dba_tab_privs
WHERE grantee NOT IN (‘SYSTEM’, ‘SYSMAN’, ‘SYS’, ‘PUBLIC’)
AND NOT EXISTS
(SELECT ‘x’
FROM dba_roles
WHERE role = grantee)
UNION
SELECT grantee,
‘COLUMN’,
table_name,
privilege
FROM dba_col_privs
WHERE grantee NOT IN (‘SYSTEM’, ‘SYSMAN’, ‘SYS’, ‘PUBLIC’)
AND NOT EXISTS
(SELECT ‘x’
FROM dba_roles
WHERE role = grantee)
Script çıktısı ;
Burada da kullanıcın sahip oldukları yetkileri (system ve object grantları) toplu olarak görüntülendiğinden dolayı kullanıcı – yetki ilişkisi sorgulanmaktadır.
19 – Objectler Üzerinde “With Grant Option” Hakkına Sahip Olan Userlar ;
6. maddede role ve system privilege’ lerinden admin opsiyonuna sahip kullanıcıları görüntülemiştik, burada da benzer bir mantıkla var olan objeler üzerinde with grant opsiyonuna sahip kullanıcıları sorguluyor olacağız;
select * from dba_tab_privs where grantable = ‘YES’
and grantee not in (‘SYS’,‘SYSTEM’,‘DBA’)
and grantee not in (SELECT USERNAME FROM DBA_USERS WHERE PROFILE=‘&APPLICATION_PROFILE’)
union
select * from dba_col_privs
where grantable = ‘YES’
and grantee not in (‘SYS’,‘SYSTEM’,‘DBA’) and grantee not in (SELECT USERNAME FROM DBA_USERS WHERE PROFILE=‘&APPLICATION_PROFILE’)
Script Çıktısı ;
6. maddedeki durumu açıklarken with admin option özelliğinin ne anlama geldiğinden bahsetmiştik. Bu özellik kullanılarak yetki verildiğinde bir süre sonra ilgili tablo üzerindeki yetki dağılımı kontrolden çıkabilir. Buraki çıktıda benzer bir mantıkla tek tek kontrol edilmelidir.
20 – Security Patch’ lerin Uygulanıp Uygulanmadığı Kontrolü ;
Oracle, her 3 ayda bir security path’ leri yayınlamaktadır. Versiyonlar piyasa çıktıkdan bir süre sonra tespit edilen security açıkları bu patchler’ le kapatılmalıdır. Sisteme şimdiye kadar hangi patch’ lerin uygulandığını sorgulamak için OS üzerinde aşağıdaki komutla sorgulanabilmektedir.
$ORACLE_HOME/OPatch/opatch lsinventory
Script çıktısı ;
C:\oracle\product\11.2.0\dbhome_1\OPatch>opatch lsinventory
Invoking OPatch 11.1.0.6.6
Oracle Interim Patch Installer version 11.1.0.6.6
Copyright (c) 2009, Oracle Corporation. All rights reserved.
Oracle Home : c:\oracle\product\11.2.0\dbhome_1
Central Inventory : C:\Program Files\Oracle\Inventory
from : n/a
OPatch version : 11.1.0.6.6
OUI version : 11.2.0.1.0
OUI location : c:\oracle\product\11.2.0\dbhome_1\\oui
Log file location : c:\oracle\product\11.2.0\dbhome_1\cfgtoollogs\opatch\opatch2012-01-29_03-09-57AM.log
Patch history file: c:\oracle\product\11.2.0\dbhome_1\cfgtoollogs\opatch\opatch_history.txt
Lsinventory Output file location : c:\oracle\product\11.2.0\dbhome_1\cfgtoollogs\opatch\lsinv\lsinventory2012-01-29_03-09-57AM.txt
——————————————————————————–
Installed Top-level Products (1):
Oracle Database 11g 11.2.0.1.0
There are 1 products installed in this Oracle Home.
There are no Interim patches installed in this Oracle Home.
——————————————————————————-
OPatch succeeded.
Buradan da anlaşılacağı üzere benim test ortamıma hiçbir patch apply edilmemiş.
21 – Oracle Dosyalarına / Dizinlerine Erişim Kontrolü ;
Burada vurgulanmak istenen Oracle’ ın işletim sisteminde kullandığı dizinlerine sadece Oracle userının eriştiğinden emin olunmasıdır. Örneğin OS’ de ORACLE_HOME ve ORACLE_BASE dizinlerinin sahibi oracle olmalıdır. Aslında bunu oracle’ ın kullandığı ve ürettiği tüm file dizinleri için düşünebilirsiniz. (Linux sistemler için ORACLE_BASE ve ORACLE_HOME dizinlerinin yetkilendirilmesi 750, diğer file pathleri içinde 600 olarak yapılandırılması uygun olacaktır.)
22 – Default Listener Port Kontrolü ;
Listener servisinin default portu 1521 dir. Bu port herkes tarafından bilindiği için bu şekilde kullanımı açık olarak değerlendirilmektedir. Listener servisinin default portunun nasıl değiştirilmesi gerektiği ile ilgili aşağıdaki linkten daha detaylı bilgi edinebilirsiniz ;
23 –Listener Servisi Parola Kontrolü ;
Kullanıcıların oracle database’ ine ulaşması için Listener servisi çok kritik bir öneme sahiptir. Dolayısıyla bu servisi olabildiğince güvenlik altına almak gerekmektedir. Listener servisinde parola olmaması bir güvenlik açığı sayıldığından dolayı bu servisede mutlaka parola konulması gerekmektedir. Bu işlemin nasıl yapılması gerektiği ile ilgili olarak aşağıdaki linkten faydalanabilirsiniz;
http://www.kamilturkyilmaz.com/2011/08/07/listener-service%E2%80%99-ine-sifre-atama/
24 – Kullanıcı Password Oluşturma Politikası Kontrolü ;
Burada kontrol edilen, production ortamlardaki kullanıcılar şifrelerini oluştururken hangi kriterlere göre oluşturuyorlar. Nelere dikkat ediliyor ve bunların güvenlik seviyesi nedir gibi sorulara cevap aranıyor. Bunu yaparken de sisteme bir password_verify functionı tanımlıyorsunuz. Sonrasında database’ de kullanıdığınız tüm profile’ lere (password_verify_funtion kısmına) bu functionı atadığınız zaman sorununuz ortadan kalkmış olmaktadır. Bu function kullanıcı şifresini belirlerken kaç karakter olması gerektiğini, password içerisinde numeric ve alfa numeric karakterlerin kullanılıp kullanılmadığını, ardarda 3 karakterin kullanılıp kullanılmadığını, paswordun username ile aynı verilip verilmediğini kontrol etmektedir. Bu arada bu bahsetmiş olduğumuz kontrolleri yapacak verify functionı ben nerden bulacağım veya nasıl yazacağım diye düşünmenize gerek yok. Oracle, sizin için bunu önceden hazırlayıp $ORACLE_HOME\RDBMS\ADMIN altına utlpwdmg.sql adıyla text formatında saklıyor sizin tek yapmanız gereken bu scripti çalıştırmanız. İhtiyaç duyacağınız tüm kontrolleri bu function fazlasıyla yapmaktadır.
25 – Public Kullanıcısı Yetkileri ;
Detayına çok girmeden bazı paketlerdeki açıklardan dolayı PUBLIC kullanıcısının bu paketler üzerindeki haklarının revoke edilmesi gerekmektedir. Aksi takdirde örneğin sys.dbms_export_extention paketi kullanılarak dba yetkisine sahip kullanıcı oluşturulması riskiyle karşı karşıya kalabilirsiniz. Bu paketler ve barındırdıkları riskler itibariyle detaylı bilgiye Tübitak’ ın yayınlamış olduğu Oracle Veritabanı Güvenliği Klavuzundan ulaşabilirsiniz. Yazımın sonunda bende referans olarak bu dökümanı belirtiyor olacağım.
Alınması gereken yetkiler;
REVOKE EXECUTE ON DBMS_EXPORT_EXTENSION FROM PUBLIC;
REVOKE EXECUTE ON UTL_FILE FROM PUBLIC;
REVOKE EXECUTE ON UTL_SMTP FROM PUBLIC;
REVOKE EXECUTE ON UTL_HTTP FROM PUBLIC;
REVOKE EXECUTE ON UTL_TCP FROM PUBLIC;
REVOKE EXECUTE ON SYS.DBMS_EXPORT_EXTENSION FROM PUBLIC;
26 – SYS Scheması Altındaki Tablolara Erşim Kontrolü ;
Database Select any table yetkisine sahip olan kullanıcıların User tabloları dışında Sys altındaki tablolarıda görüp göremeyeceği database’ deki 07_DICTIONARY_ACCESSIBILITY parametresi ile belirlenir. Bu değer default’ da false olarak gelmekle birlikte kontrol edilmesinde fayda vardır. TRUE olması açık kapsamında değerlendirilmektedir. Bu değer False olmasına rağmen SELECT_CATALOG_ROLE, EXECUTE_CATALOG_ROLE veya DELETE_CATALOG_ROLE yetkilerinden birine sahip olan kullanıcıları bu tabloları görebilme yetkisinede sahip olmuş demektir. Dolayısıyla bu kritik role’ lerinde kontrol edilmesi gerektiğini 2. maddede belirtmiştik.
27 – Oracle Database SID Kontrolü ;
Denetimlerde bulgu olarak değerlendirilen bir diğer madde ise oracle database SID’ lerinin sistemin ne olduğu ile ilgili fikir veriyor olmasıdır. Örneğin production database’ nizin adının PROD olması, İnternet bankacılığı database’ inin Sid’ nin INT_BANK veya bu tarz anımsatıcı bir isim olması, kredi kartları database’ inizin adının KART, KREDI_KART gibi isimler olması açık kapsamında değerlendirilmektedir.
Database’ in SID ‘ sinin nasıl değiştirilmesi gerektiği ile ilgili bilgiye aşağıdaki linkden ulaşabilirsiniz ;
28 – Uygulama Userlarının Erişim Kontrolü ;
Buraya kadarki olan kısımdan da anlayacağınız üzere, denetimlerin temeli aslında temel kim hangi dataya neden ve nasıl ulaşıyor üzerinde dönüyor. Önceki maddelerde yetkileri, rolleri object grantlarını sorguladık ve bunu yaparkende kimilerinde uygulama userlarını hariç tutarak yaptık. Çünkü bu userların zaten amacı uygulama schemalarına erişmeleri (program üzerinde) olduğu için, burda bunu yaparken şunu atlamamız gereken nokta şu aslında, o zaman uygulama userları ile sadece application üzerinden sisteme connect olmalarını bekliyebiliriz yani hiçbir uygulamacı kendi clientından toad veya benzer bir tool ile bu userları kullanarak sisteme giriş yapamamalıdır. Bu önemli bir nokta, o zaman alınması gereken önlem yine bir trigger yardımı ile bu userlardan birisi ile sisteme connection kurmaya çalıştığında ip bazında kontrol yapıp (eğer geldiği ip application sunucunun ip’ si ise giriş yapabilecek farklı bir ip ise girişine izin verilmeyecektir) sonrasında girişine izin verilmesi gerekecektir.
Bahsi geçen trigger´ ın bir örneğine aşağıdaki linkden ulaşabilirsiniz ;
http://www.kamilturkyilmaz.com/2011/01/21/bilinen-adiyla-logon-trigger/
29 – Uygulama Ownerı Accountu Kontrolü ;
Database’ deki uygulama ownerı ile işlem yapılmaması gerekmektedir. Dolayısıyla bu userın acountunun lock’ lı olmasına dikkat edilmelidir ;
Bizim database’ imizde INFRA kullanıcımızı uygulama ownerı olduğunu kabul etmiştik ;
SQL> select username, account_status from dba_users where username = ‘INFRA’
USERNAME ACCOUNT_STATUS
—————– ————————
INFRA LOCKED
1 row selected.
30 – Alınan Backupların Başarılı Olarak Alındığının Kontrolü ;
Database’ den alınan günlük rman backuplarının (sıkca bu yöntem kullanıldığı için örnek veriyorum) düzgün olarak alındığının loglar üzerinden gösterilebiliyor olması gerekmektedir. Bunun için third-party bir tool kullanıyor iseniz kullandığınız tool’ un loglarından veya database’ den aşağıdaki sorguyu kullanarak da loglara ulaşabilirsiniz ;
SELECT *
FROM ( SELECT start_time Backup_baslangic_suresi,
end_time Backup_bitis_süresi,
output_device_type backup_lokasyonu,
input_type Backup_Type,
status backup_durumu,
output_bytes_display backup_boyutu,
time_taken_display backup_alma_süresi
FROM V$RMAN_BACKUP_JOB_DETAILS
ORDER BY 1 DESC)
WHERE ROWNUM < 10
Script çıktısı ;
Test ortamımızda, diskte yer probleminden dolayı tüm backuplarım fail etmiş durumda, sizler production database’ lerinizde tümünü succesful olarak göreceğinizi tahmin ediyorum.
31 – Wievler ve Yetki Kontrolleri ;
Denetimler esnasında dikkat edilen bir diğer nokta ise, görüntüler yani viewlerdir. Database’ de yer alan view’ lerin neler olduğuna bu viewlerde hangi alanların görüntülendiğine ve bu viewleri kimlerin görüntülediğine dikkat edilmektedir.
Database’ deki tüm view’ leri sorgulamak için ;
select * from all_objects where OBJECT_TYPE = ‘VIEW’ ;
Script çıktısı ;
Bu viewler üzerindeki yetkileri görmek içinse;
select grantee, owner ,table_name , privilege from dba_tab_privs
where table_name in (
select view_name table_name from dba_views)
Script çıktısı ;
32 – Public Synonym Kullanımı Denetimi ;
13. maddede public database linklerden bahsetmiştik. Public db linkler nasıl ki yetkisiz erişimlere olanak sağlıyor ise public synonym’ lerde bu kapsamda değerlendirilmekte olup açık olarak işlem görmektedir. Adında anlaşılacağı üzere siz bir tablo üzerinde public synonym oluştursanız bütün veritabanı kullanıcıları bu synonym’ ler üzerinden tabloları okuyabilir hale gelebilmektedir. (public userına da ilgili tablo için grant hakkıda verildiğinde) Dolayısıyla bu açıdan bakıldığında public synonym’ ler veri güvenliği açısından bakıldığında kullanılması pek istenilmeyen nesnelerdir.
Database’ de kullanılan synonym’ leri tespit etmek isterseniz ;
select * from dba_synonyms;
Script çıktısı ;
Yukarıdaki tabloda owner schemalarına ait public erişimlerin olup olmadığı ve owner schemalarına erişimin public synonym’ ler aracılığıyla sağlanıp sağlanılmadığı incelenecektir. Developer’ lar eğer yazılım yaparken sorgularında kullanıdığı tabloların başına schema isimlerinide yazarlarsa aslında public synonym kullanımın büyük ölçüde önüne geçilmiş olacaktır. Public synonym’ in kolaylık açısından bir çare gibi algılanmasında son derece karşı olduğumuzu da belirtmeden geçemeyeceğiz.
Yaklaşık 32 madde de nelerin nasıl denetlendiğini özetlemeye çalıştık. En azından denetimin arkasında nelerin kontrol edildiği konusunda artık herkes fikir sahibi olmuştur diye düşünüyoruz.
Bilgi paylaştıkça çoğalır düşüncesinden hareketle, bu konudaki her türlü fikre diğer tüm yazılarımızda olduğu gibi sonuna kadar açığız. Sizler de denetim maddeleri arasında bu da var dedikleriniz var ise lütfen yorum olarak eklemekten çekinmeyiniz, sizlerin de katkısıyla bu alanda güzel bir yazıya imza atmış oluruz diye düşünüyoruz.
Umarım faydalı olabilmişizdir.
Yazarlar:
Kamil Türkyılmaz
Çağatay Işıkcı
Referans ;
2) http://www.petefinnigan.com/tools.htm
3) http://www.bilgiguvenligi.gov.tr/kayit-yonetimi/veritabani-loglama.html
