SQL'de Kullanıcı Oluşturma ve Yetki Verme: GRANT ve REVOKE

Hesap, rol, yetki ve nesne: yetki modelinin katmanları

Veritabanı yetkilendirmesi birkaç kavramın birbirine bağlanmasıdır. Hesap, sisteme bağlanabilen kullanıcıdır. Rol, yetkileri gruplayan ve kullanıcılara verilebilen kapsayıcıdır. Yetki, bir nesne üzerindeki izin verilmiş işlemdir. Nesne ise yetkinin uygulandığı tablo, kolon ya da şemadır. Bu zinciri ayrı ayrı düşünmek, "kullanıcı neden bu tabloyu göremiyor" sorusunun cevabını hızla bulmanızı sağlar.

Söz dizimi sistemlere göre değişir. PostgreSQL'de kullanıcı ve rol aynı kavramın farklı adlarıdır: CREATE ROLE ile yaratılan rol, LOGIN özelliği verilirse bağlanabilen kullanıcıya dönüşür; CREATE USER aynı komutun LOGIN içeren kısayoludur. MySQL'de kullanıcı CREATE USER ile hesap adı ve bağlantı yeriyle birlikte tanımlanır. SQL Server'da birbirine bağlı aşamalar vardır: sunucuya giriş için bir login, veritabanında o login'e bağlı bir user yaratılır.

PostgreSQL için kısa bir örnek:

CREATE ROLE rapor_okuyucu LOGIN PASSWORD 'parola_buraya'; GRANT CONNECT ON DATABASE satis TO rapor_okuyucu; GRANT USAGE ON SCHEMA public TO rapor_okuyucu; GRANT SELECT ON siparis TO rapor_okuyucu;

Parolayı komut dosyasına ya da paylaşılan bir belgeye yazmayın; parola yönetim aracından ya da ortam değişkeninden gelmelidir. Örnekteki rapor_okuyucu hesabı yalnızca bağlanabilir, şemayı kullanabilir ve siparis tablosunu okuyabilir; başka hiçbir şey yapamaz.

GRANT ile tablo ve kolon yetkisi vermek

GRANT komutu, bir nesne üzerindeki belirli işlemleri bir hesaba ya da role verir. PostgreSQL belgesine göre tablo düzeyinde yetkiler arasında SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES ve TRIGGER sayılır; ALL PRIVILEGES hepsini birden verir. Gerçek işte nadiren bütün yetkiler gerekir, bu yüzden tek tek yazmak daha güvenlidir.

GRANT SELECT, INSERT ON siparis TO uygulama_rolu; GRANT SELECT ON ALL TABLES IN SCHEMA public TO rapor_rolu;

İlk komut uygulama rolüne siparişleri okuma ve ekleme izni verir, silme ya da güncelleme vermez. İkincisi şemadaki tüm tablolara okuma izni verir; komut yalnızca o anda var olan tabloları kapsar, sonradan eklenen tablolar için varsayılan yetki ayrıca tanımlanmalıdır.

Hassas kolonları gizlemek için yetki kolon düzeyinde de verilebilir. Örneğin müşteri tablosunun ad ve şehir kolonlarını göstermek, telefon ve e-posta kolonlarını göstermemek mümkündür:

GRANT SELECT (ad, sehir) ON musteri TO destek_rolu;

Kolon yetkileri SELECT, INSERT, UPDATE ve REFERENCES ile sınırlıdır. Başka bir seçenek, hassas kolonları dışarıda bırakan bir görünüm (view) yaratıp yetkiyi görünüme vermektir; bu yaklaşım sorgu yazan kişiyi de sadeleştirir.

WITH GRANT OPTION eklenirse yetkiyi alan kişi o yetkiyi başkasına da verebilir. Yetki zincirinin denetimi zorlaştığı için bu seçeneği ancak gerçekten devir gerekiyorsa kullanın.

REVOKE: yetkiyi geri almak ve beklenmedik durumlar

REVOKE, GRANT'in tersidir ve aynı nesne ve yetki adlarını kullanır:

REVOKE INSERT ON siparis FROM uygulama_rolu;

Geri alma işleminde dikkat edilmesi gereken birkaç ayrıntı vardır. PostgreSQL belgesine göre tablo düzeyinde bir yetkiyi geri almak, aynı tablo üzerinde kolon düzeyinde verilmiş yetkileri değiştirmez. Yani tablo okuma yetkisini kaldırdığınızı sanıp kolon yetkisi nedeniyle erişimin sürdüğünü fark edebilirsiniz. Bunu yetki bilgisini sorgulayarak kontrol edin.

Bir hesabın etkili yetkisi, doğrudan verilen yetkiler, üyesi olduğu rollerin yetkileri ve herkese açık (PUBLIC) olarak verilmiş yetkilerin toplamıdır. Dolayısıyla bir kullanıcıdan yetkiyi aldığınızda hâlâ erişebiliyorsa nedeni genellikle bir rol üyeliği ya da PUBLIC'e verilmiş bir yetkidir. PUBLIC, sonradan yaratılacak olanlar dahil tüm rolleri kapsar; buna yetki vermek çoğu zaman gereğinden geniş bir kapı açar.

SQL Server'da ek olarak DENY komutu vardır; yetkiyi vermek yerine açıkça yasaklar ve genel kurala göre yasak, verilmiş izinden önce gelir. Engellemek istediğiniz işlem başka bir yoldan hâlâ açıksa DENY kesin çözümdür.

Yetki değişikliğinden sonra ilgili hesapla yeni bir bağlantı açıp işlemi gerçekten denemek en güvenilir doğrulamadır; ayarın yürürlüğe girdiğini komutun hata vermemesinden çıkarmayın.

Rolle yönetim ve en az yetki ilkesi

Yetkiyi doğrudan kullanıcıya vermek küçük bir ekipte çalışır ama büyüdükçe dağılır. Çözüm, işlevlere göre roller tanımlamak ve kullanıcıları bu rollere üye yapmaktır:

CREATE ROLE rapor_rolu; GRANT SELECT ON ALL TABLES IN SCHEMA public TO rapor_rolu; GRANT rapor_rolu TO ayse;

Ayşe ekipten ayrıldığında rol üyeliğini kaldırmak yeterlidir; tek tek yetki aramak gerekmez. Yeni gelen biri aynı role eklenerek aynı erişimi alır.

En az yetki ilkesi için pratik bir ayrım şudur: uygulamanın bağlandığı hesap yalnızca uygulamanın ihtiyaç duyduğu tablolarda gerekli işlemleri yapabilsin. Tablo yaratma, silme ve yetki verme gibi yönetim işlemleri ayrı, kısıtlı sayıda kişiye ait bir hesapla yapılsın. Raporlama araçları yalnızca okuma yetkisiyle bağlansın. Uygulamayı veritabanı sahibi ya da en yetkili hesapla çalıştırmak, bir sorgu enjeksiyonu açığının bütün veritabanını riske atması anlamına gelir.

Geliştirme, test ve canlı ortamlar için ayrı hesaplar ve parolalar kullanın. Canlı ortamın parolası geliştiricilerin dizüstü bilgisayarlarında bulunmamalıdır.

Yetki yönetiminde sık hatalar ve düzenli gözden geçirme

Yetkilerle ilgili sorunların çoğu bilgisizlikten değil, aceleyle verilmiş geçici izinlerin kalıcı hale gelmesinden doğar.

• Hata mesajı alınca ALL PRIVILEGES vermek: sorun çözülür ama gereğinden fazla erişim kalıcı olur.
• PUBLIC'e yetki vermek: sistemdeki her hesabı etkiler, sonradan yaratılacaklar dahil.
• Rol yerine kişiye yetki vermek: kişi değiştiğinde unutulan yetkiler kalır.
• Ayrılan çalışanın hesabını kapatmamak ya da parolasını değiştirmemek.
• Şema kullanım yetkisini unutmak: tabloya SELECT verildiği halde şema yetkisi yoksa erişim yine reddedilir.
• Yalnızca GRANT yazıp sonucu denememek.

Yetki düzenini canlı tutmak için döngüsel bir süreç işletin: ihtiyacı tanımlayın, ilgili rolü oluşturun ya da güncelleyin, yetkiyi verin, hesapla deneyerek doğrulayın, belirli aralıklarla gözden geçirin ve gereksizleri geri alın. Gözden geçirmede kimin hangi role üye olduğunu ve hangi hesapların uzun süredir kullanılmadığını listeleyin.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Mindset'in Veritabanı Yönetim Sistemleri ve Uygulamaları programında Güvenlik ve Yetkilendirme başlığı yetki modelini ve erişim denetimini ele alır; SQL ile Programlama Eğitimi ise komutların yazımına odaklanır. Veritabanı yöneticileri ve uygulama geliştiriciler için asıl kazanım, uygulama hesabını en az yetkiyle çalıştırmak ve bunu denemeyle kanıtlamaktır.

Başlangıç olarak bir deneme veritabanında salt okuma yetkili bir hesap yaratıp yazma işlemi denemek, yetki hatasının neye benzediğini görmenin en kısa yoludur.