Yetkilendirme Güvenliği
1 – Yetki ve Roller
Yetki (Privilege) ve roller (Role) Oracle veritabanında bulunan bir kullanıcının neleri yapıp, neleri yapamayacağını belirlemek için kullanılan kavramlardır. Bu yetki ve roller kullanıcılara verilirken çok dikkat edilmelidir. Çünkü masum görünen bir yetki kullanıcının kötü niyetli olması durumunda güvenlik açığı olarak karşımıza çıkacaktır.
Yetkiler (Privilege), bir kullanıcının belirli bir tipteki SQL komutunu çalıştırma yetkisi, diğer kullanıcıların objelerine erişim yetkisi, bir PL/SQL paketi çalıştırabilme yetkisi gibi kavramlardır. Roller (Role) ise birkaç yetki ya da rolleri bir grup altında toplamaya yarar.
Yetkiler, sistem yetkileri (system privilege) ve obje yetkileri (object privilege) olmak üzere ikiye ayrılır. Sistem yetkileri kullanıcının belirli bir veritabanı operasyonunu yapabilmesini sağlar. Obje yetkileri ise belirli bir veritabanı objesi üzerindeki erişim yetkilerini düzenler.
Örnek olarak, aşağıda Enterprise Manager üzerinde SYSMAN kullanıcısının sahip olduğu roller, system yetkileri ve obje yetkilerinin sorgulandığı ekran çıktısı bulunmaktadır.
Görüldüğü üzere SYSMAN kullanıcısına görevlerini yerine getirebilmesi amacıyla, kurulumda gelen bazı yetki ve roller tanımlanmıştır. Tanımlanan rollerin ve sistem yetkilerinin yanında görülen “Admin Option” ve obje yetkilerinin yanında görülen “Grant Option” ifadesi, kullanıcının bu rol ya da sistem yetkilerini başka kullanıcılara atayıp atayamayacağını gösterir.
Rollerin ve yetkilerin kullanıcılara atanması için Enterprise Manager ya da başka bir yönetim aracı kullanılabileceği gibi aşağıdaki komutlar da belirtilen formatta kullanılabilir.
SQL> grant sistem_yetkisi(rol) to kullanıcı_adı(rol); SQL> grant sistem_yetkisi_1(rol_1), sistem_yetkisi_2(rol_2), .., sistem_yetkisi_n(rol_n) to kullanıcı_adı(rol); SQL> grant sistem_yetkisi to kullanıcı_adı(rol) with admin option; SQL> grant obje_yetkisi to kullanıcı_adı(rol); SQL> grant obje_yetkisi to kullanıcı_adı(rol) with grant option;
Örnek GRANT komutları:
SQL> grant select, insert on customer to fred, mary, joe; SQL> grant insert on order_table to update_role; SQL> grant all on customer to fred; SQL> grant select on customer_view to mary; SQL> grant create any cluster to customer_role; SQL> grant select any table to fred; SQL> grant create any table to public; SQL> grant create tablespace to dba_role;
Yetki ve roller kullanıcılara atanırken yöntemimizin şu şekilde olmasında fayda vardır.
1- Yetki ve Roller kullanıcı tarafından talep edilmediği sürece verilmemelidirler.
2- Talep edilen yetki veya rollerin ne amaçla istenildiği sorgulanmalıdır.
3- Verilecek yetki ve rollerin güvenlik açısından ne gibi sorunlar yaratabileceği araştırılmalı ve kullanıcıya verilmeden önce bu hususlar değerlendirilmelidir.
2 – PUBLIC Yetkileri
Veritabanı yaratıldığında otomatik olarak yaratılan PUBLIC rolü gizli bir roldür. (DBA_ROLES view’ı sorgulandığında görülmez.) PUBLIC rolü veritabanındaki tüm kullanıcıların kalıcı varsayılan rolü olarak düşünülebilir. Başka bir ifade ile, PUBLIC rolüne atanan her türlü yetki, otomatik olarak tüm kullanıcıların kullanabileceği bir yetki haline gelir. Bu nedenle PUBLIC yetkileri, büyük güvenlik açıkları yaratabilecek bir konudur.
Veritabanı yaratıldığında varsayılan olarak PUBLIC rolüne belirli obje yetkileri atanır. Aşağıdaki komut ile, 11g versiyonu bir veritabanında varsayılan olarak PUBLIC rolüne atanmış 27467 adet obje yetkisi olduğunu görüyoruz.
SQL> select count(*) from dba_tab_privs where grantee='PUBLIC';
COUNT(*)
----------
27467
Ancak bu obje yetkilerini kaldırmak çeşitli hatalara yol açabilmektedir. Örneğin versiyon yükseltme, yama atma gibi işlemlerde hata ortaya çıkabilir. Ayrıca bu işlemler genellikle PUBLIC yetkilerini tekrar varsayılana dönüştürür. Bu nedenlerle PUBLIC rolüne atanmış obje yetkilerini kaldırmak tavsiye edilmez. Bu işlem yapılacaksa da çok dikkatli bir çalışma ile tüm etkileri hesaba katılarak yapılmalıdır.
PUBLIC rolüne atanan system yetkilerini aşağıdaki komutla sorguladığımızda ise, varsayılanda PUBLIC rolüne hiçbir sistem yetkisinin atanmadığını görürüz.
SQL> select count(*) from dba_sys_privs where grantee = 'PUBLIC';
COUNT(*)
----------
0
PUBLIC rolüne sistem yetkisi atamak büyük güvenlik tehditlerine yol açacağından, hiçbir zaman tavsiye edilmez. Sistem yetkileri gerekli kullanıcılara roller vasıtasıyla atanmalıdır. Birçok sistem yetkisinin, kötü niyetli kişilerce veritabanı üzerinde hasar verici işlemlerin gerçekleştirilmesinde kullanılabileceği unutulmamalıdır.
3 – Geniş Yetkilerin Kaldırılması
Geniş yetkiler ifadesi kişiye göre farklılık gösterebilecek bir kavramdır. Ancak veritabanı güvenliğini sağlamakla sorumlu uzmanlar bu tanımı kendilerince netleştirip, “geniş yetkilere” sahip kullanıcıları belirleyerek, kullanıcıların bu yetkilere gerçekten ihtiyaçları olup olmadığını sorgulamalıdırlar. Aşağıdaki SQL script ile, bir kullanıcının sahip olmasında güvenlik riski bulunmayan yetkiler belirlenerek, bunların dışındaki yetkiler (geniş yetkiler) ve yetkilere sahip kullanıcılar listesi alınmaktadır. Script, ‘SYS’, ‘SYSTEM’, ‘WKSYS’, ‘XDB’, ‘MDSYS’, ‘ORDPLUGINS’, ‘ODM’, ‘DBA’, ‘IMP_FULL_DATABASE’, ‘EXP_FULL_DATABASE’ gibi varsayılan kullanıcı ve roller için çıktı alınmayacak şekilde oluşturulmuştur.
set pages 50000
break on privilege skip 1
select privilege, grantee, admin_option from dba_sys_privs
where privilege not in (/* list any other privilege here you don't find "sweeping"
*'ALTER SESSION','QUERY REWRITE','CREATE DIMENSION',
'CREATE INDEXTYPE','CREATE LIBRARY','CREATE OPERATOR',
'CREATE PROCEDURE','CREATE SEQUENCE','CREATE SESSION',
'CREATE SNAPSHOT','CREATE SYNONYM','CREATE TABLE',
'CREATE TRIGGER','CREATE TYPE','CREATE USER','CREATE VIEW')
and grantee not in('SYS','SYSTEM','WKSYS','XDB','MDSYS','ORDPLUGINS',
'ODM','DBA', 'IMP_FULL_DATABASE', 'EXP_FULL_DATABASE')
/* Place all the user names you want to exclude */
order by privilege, grantee
Aşağıda ise belirtilen SQL script çıktısının örnek bir bölümü bulunmaktadır. PRIVILEGE kolonu yetkileri, GRANTEE kolonu yetkiye sahip kullanıcıyı, ADM kolonu ise kullanıcının bu yetkiye ADMIN OPTION ile sahip olup olmadığını belirtir. Bu çıktı detaylı incelenerek gerek görülmeyen yetkilerin kaldırılmaları önemli bir güvenlik adımıdır.
PRIVILEGE GRANTEE ADM
-------------------------------- ----------------------------- ------
CREATE ANY TABLE RAPOR NO
TEST NO
SYSMAN NO
WMSYS NO
CREATE ANY TRIGGER TEST NO
WMSYS NO
CREATE ANY TYPE TEST NO
CREATE ANY VIEW TEST NO
WMSYS NO
CREATE CLUSTER TEST NO
RECOVERY_CATALOG_OWNER NO
RESOURCE NO
CREATE DATABASE LINK TEST NO
RECOVERY_CATALOG_OWNER NO
Bir kullanıcının yetkisini kaldırmak dikkatsizce yapılmaması gereken bir işlemdir. Bu nedenle kaldırılması gerektiğine karar verilen yetkilerin, kaldırılmarı durumundaki muhtemel etkileri iyi analiz edilmelidir. Bu noktada önemli bir metod, veritabanı kullanıcısının arkasındaki gerçek kişilerle birebir görüşmektir.
4 – Direkt Yetkilendirmenin Kullanılması
Bir yetki atanırken “with grant/admin option” seçeneğinin kullanılabileceğini daha önce belirtmiştik. Bu seçenek kullanılarak yetki atanan kullanıcı, bu yetkiyi başkalarına da atayabilmektedir. Örneğin aşağıdaki örnekte A kullanıcısı B kullanıcısına tab1 tablosunu sorgulama yetkisi ermektedir. Ancak yetkiyi alan B kullanıcısı bu yetkiyi C kullanıcısına verirken hata almaktadır.
SQL> Connect A/****** SQL> Grant select on tab1 to B; Grant succeeded SQL> Connect B/****** SQL> Grant select on a.tab1 to C; ORA-01031: insufficient privileges
Ancak A kullanıcısı B kullanıcısına yetkiyi aşağıdaki şekilde atasaydı, B kullanıcı da bu yetkiyi C kullanıcısına atayabilecekti.
SQL> Connect A/****** SQL> Grant select on tab1 to B with grant option; Grant succeeded SQL> Connect B/****** SQL> Grant select on a.tab1 to C; Grant succeeded
Benzer şekilde B kullanıcısı da bu yetkiyi C kullanıcısına “with grant option” seçeneği ile verebilir. Bu noktada aklınıza şu soru gelebilir: A kullanıcısı B kullanıcısına verdiği yetkiyi geri alırsa, C kullanıcısının B kullanıcısından aldığı yetkiye ne olur? İşte bu noktada Oracle’ın davranışı, yetkinin sistem ya da obje yetkisi olmasına göre, aşağıdaki şekillerde görüldüğü gibi farklılık göstermektedir.
SİSTEM YETKİSİNİN GERİ ALINMASI 
OBJE YETKİSİNİN GERİ ALINMASI
Şekilde görülebileceği gibi sistem yetkisi söz konusu olduğunda, C’nin yetkisi kalırken, obje yetkisi söz konusu olduğunda C’nin yetkisi de B’nin yetkisi ile birlikte kalkmaktadır. Her iki seçenek te, yeri geldiğinde istenmeyen durumlara yol açabilir.
Başka bir senaryo ise, C kullanıcısına hem B hem de A kullanıcısı tarafından aynı obje yetkisinin verilmesi olarak düşünülebilir. Böyle bir durumda, A ya da B kullanıcılarından herhangi biri C’den söz konusu yetkiyi geri aldığında, diğer kullanıcının atadığı yetki C kullanıcısında kalacaktır. Bu durum ise yanıltıcı olabilir.
Konu başlığındaki ifadede geçtiği gibi “direkt” yetkilerin kullanılması bu tip sorunların önüne geçecektir. Başka bir ifade ile, yetki verirken “with admin/grant option” seçeneğini kullanmaz isek, bahsettiğimiz problemlerle karşılaşmayız. Obje yetkilerini verirken, sadece obje sahibi ya da sys kullanıcısı gibi bir yönetici hesabı ile yetkileri atamalıyız. Güvenlik kontrolü yapacağımız bir veritabanında ise aşağıdaki komutu kullanarak, bir obje yetkisinin, obje sahibi dışındaki kullanıcılar tarafından atandığı yetkileri tespit edebiliriz.
SQL> select owner, table_name, privilege, grantee, grantor from dba_tab_privs
where grantor != owner and grantee != 'PUBLIC';
OWNER TABLE_NAME PRIVILEGE GRANTEE GRANTOR
--------- ---------- ------------- ---------- ----------
A TAB1 SELECT C B
Burada A kullanıcısına ait TAB1 tablosu üzerinde select yetkisinin, B kullanıcısı tarafından C kullanıcısına atadığını görebiliyoruz. Bu durumu düzeltmek için, B kullanıcısı tarafından atanan bu yetkiyi kaldırarak, yetkiyi obje sahibi olan A kullanıcısı ya da SYS kullanıcısı ile atamamız gerekir.
Sistem yetkileri için de “with admin option” seçeneğinin kullanılmaması ve sistem yetkilerinin SYS tarafından verilmesi daha güvenli olacaktır. Bu seçenek kullanılarak verilen yetkileri aşağıdaki komut ile tespit edebiliriz.
SQL> select * from DBA_SYS_PRIVS where ADMIN_OPTION='YES' and
GRANTEE not in ('DBA','SYS','SYSTEM','AQ_ADMINISTRATOR_ROLE','SCHEDULER_ADMIN');
GRANTEE PRIVILEGE ADM ---------- ------------ ------ B CREATE TABLE YES
Görüldüğü gibi B kullanıcısına “with admin option” seçeneği ile tablo yaratma yetkisi verilmiştir. Bu yetkinin kaldırılarak “with admin option” ifadesi olmadan tekrar verilmesi uygun olacaktır.
5 – Tablespace Kotalarının Sınırlandırılması
• İlk olarak aşağıdaki sorgu ile SYTEM tablespace’i üzerindeki kotalar kontrol edilir:
SQL>select username, bytes/1024/1024 used, max_bytes/1024/1024 quota
from dba_ts_quotas where tablespace_name = 'SYSTEM' order by username;
• SYSTEM tablespace’i üzerindeki limitsiz kota yetkileri kaldırılmalıdır. Ancak bundan önce SYSTEM tablespace’inin SYS şeması dışında objeler içermediğinin doğrulanması gerekir. Aşağıdaki sorgu ile kontrol edilebilir.
SQL> select owner, segment_type, segment_name from dba_segments<
where tablespace_name = 'SYSTEM' and owner not in ('SYS','SYSTEM');
• Bir sonraki adımda sınırsız tablespace (unlimited tablespace) sistem yetkisine sahip kullanıcılar belirlenir.
SQL> select grantee from dba_sys_privs where privilege = 'UNLIMITED TABLESPACE';
• “UNLIMITED TABLESPACE” yetkisinin RESOURCE rolüne atanmadığı aşağıdaki sorgu ile doğrulanmalıdır.
SQL> select * from dba_sys_privs where grantee = 'RESOURCE';
