Cevap.

SQL sunucusu, roller, kullanıcı hakları (GRANT/REVOKE) ve şemalar (schemas) aracılığıyla çok katmanlı bir erişim hakları sistemi destekler. Temel ilkeler:

• Rol= bir dizi izin, bunlar daha sonra kullanıcıya verilir.
• Sadece gerekli en az hakları verin (en az ayrıcalık ilkesi).
• Hakları veritabanı, tablo, görünüm, prosedür seviyelerinde ayrı ayrı bölün.
• Özellikle önemli işlemler için yalnızca saklı prosedürler veya görünümler aracılığıyla kullanın, doğrudan tablo erişimi sağlamayın.

Rol oluşturma ve hak atama örneği:

-- Analistler için bir rol oluştur
CREATE ROLE Analyst;
-- Gerekli tablolara sadece SELECT hakkı ver
GRANT SELECT ON Sales TO Analyst;
-- Veri değiştirilmesini yasakla
REVOKE INSERT, UPDATE, DELETE ON Sales FROM Analyst;
-- Kullanıcıya rol ata
GRANT Analyst TO user_ivan;

Sık sık okuma (read-only), değişiklik, yönetim ve belirli işlemler için roller ayrılır.

Kandırmaca sorusu.

Kandırmaca: "Sadece görünüm (VIEW) erişimi olan bir kullanıcı, temel tabloyu bunun aracılığıyla değiştirebilir mi? Örnek verin."

Cevap: Evet, eğer VIEW toplama/gruplama içermiyorsa ve yalnızca okuma amaçlı değilse (WITH CHECK OPTION) – VIEW üzerinde INSERT/UPDATE/DELETE işlemleri yapılabilir ve değişiklikler temel tabloya ulaşır, izinler uygun olduğunda.

-- Gereksiz sütunları dışlayan bir görünüm oluştur
CREATE VIEW SalesAsView AS SELECT id, total, manager_id FROM Sales;
-- Eğer izin verilirse, kullanıcı şu şekilde değişiklik yapabilir:
UPDATE SalesAsView SET total=1000 WHERE id=42;
-- Bu, Sales.total için id=42'yi etkileyecektir

Çözüm: yalnızca readonly VIEW kullanmak veya görünümler aracılığıyla veri değişikliklerini yasaklamaktır.

Konuyla ilgili ince detayların bilinmemesinden kaynaklanan gerçek hata örnekleri.

---

Hikaye

Proje: İK portalı, çalışanların kişisel verileri.

Hata: Operatörler, UPDATE kısıtlaması olmadan VIEW aracılığıyla temel tabloya erişim sağladı - birbirlerinin maaşlarını yanlışlıkla değiştirdi, oysa VIEW başlangıçta "sadece raporlar için" tasarlanmıştı.

---

---

Hikaye

Proje: Muhasebe, harici entegrasyonlar.

Hata: Harici sisteme tüm DB üzerinde INSERT ve SELECT hakları verildi, sadece gerekli tablolarda INSERT izni verilmedi. Sonuç: tüm DB'ye okuma açığı ve GDPR yasasının ihlal edilme riski.

---

---

Hikaye

Proje: SaaS platformu, çok kullanıcılı raporlar.

Hata: Tüm müşteriler aynı şemada ortak haklarla çalıştı: yanlışlıkla başkalarının verilerini gördü ve düzenleyebildi. Çözüm - şemalara ayırma, ayrı roller ve Row Level Security (RLS) seviyesinde kendi kısıtlamaları sağlamak.

---