Oracle AI Database 26ai'nin Deep Data Security'si satır, sütun ve hücre erişimini zorunlu kılıyor

Deep Data Security ne yapıyor

dev.to'da yayımlanan uygulamalı bir incelemeye göre Oracle AI Database 26ai, Deep Data Security ya da kısaca "Deep Sec" adlı yeni bir yetkilendirme çerçevesiyle geliyor. Erişim kurallarının uygulama kodu, middleware veya bir AI agent tarafından doğru şekilde uygulandığına güvenmek yerine, yöneticiler SQL ile hangi kullanıcı, rol veya uygulamanın hangi satırlara, sütunlara, hatta tek tek hücrelere dokunabileceğini tam olarak bildiriyor. Veritabanı da bu kuralı sorguyu kimin veya neyin gönderdiğinden bağımsız olarak her sorguda uyguluyor.

İnceleme, Deep Sec'i Oracle Label Security ve Data Masking gibi tanıdık araçların bir yol arkadaşı olarak nitelendiriyor; ancak PL/SQL ile yazılan satır düzeyi güvenliğe kıyasla daha iyi ölçeklenen, daha temiz ve SQL'e özgü bir ince erişim ifadesi sunuyor. Üç yapı taşına dayanıyor:

• Yerel son kullanıcılar — geleneksel veritabanı kullanıcılarının aksine şema veya nesne sahipliği olmayan, uygulama kullanıcıları için hafif kimlikler.
• Data role'ler — ya Microsoft Entra ID veya OCI IAM gibi harici bir kimlik sağlayıcıdaki rollerle eşlenen ya da tamamen veritabanı içinde yönetilen, ince ayrıcalıklar taşımak üzere tasarlanmış roller.
• Data grant'ler — kimin hangi satır ve sütunlarda SELECT, INSERT, UPDATE veya DELETE yapabileceğini, gizli prosedürel mantık yerine sıradan okunabilir SQL ile belirten politika nesnelerinin kendileri.

Yazarın öne çıkardığı sonuç şudur: İstek ister insan bir kullanıcıdan, ister bir raporlama aracından, ister otonom bir AI agent'tan gelsin, aynı koruma geçerlidir.

Son kullanıcılar sıfır ayrıcalıkla başlar

Yerel bir son kullanıcı, tanıdık CREATE USER söz dizimini yansıtan yeni bir CREATE END USER ifadesiyle oluşturulur ve DBA_END_USERS adlı özel bir sözlük görünümü, yöneticilerin bu hesapları standart kullanıcılar için DBA_USERS'ın yaptığı gibi izlemesini sağlar.

Yazının belirttiğine göre insanları şaşırtan ilk davranış, bir son kullanıcı oluşturmanın ona bağlanma yeteneği vermemesidir. Yeni oluşturulmuş bir son kullanıcıyla oturum açma girişimi ORA-01045 hatasıyla başarısız olur çünkü hesapta CREATE SESSION ayrıcalığı yoktur. Bu bilinçli bir tasarım: Son kullanıcı hiçbir ayrıcalıkla başlamaz ve oturum açmak dahil herhangi bir şey yapabilmesi için önce bir data role üzerinden yetkilendirilmelidir.

Yetkilendirmeyi data role'ler taşır

Yetki zinciri şöyle işler: CREATE SESSION gibi sıradan bir ayrıcalık taşıyan standart bir veritabanı rolü bir data role'e verilir ve data role de GRANT DATA ROLE ile bir veya daha fazla son kullanıcıya atanır. Bu, yetkilendirmeyi doğrudan ayrıcalıkları ayrı ayrı kullanıcılara dağıtmak yerine bildirimsel ve merkezi tutar. Data role'ler ayrıca satır ve sütun düzeyindeki erişimi tanımlayan ince ayrıntılı data grant'lerin taşıyıcısıdır.

Kaputun altında: oturumlar XS$NULL olarak çalışır

Son kullanıcılar şema sahibi olmadığından oturumları fiilen rezerve edilmiş, şemasız XS$NULL hesabı olarak çalışır ve son kullanıcı güvenlik bağlamı bunun üstüne katmanlanır. Bir son kullanıcı oturumundan USER_USERS sorgulandığında XS$NULL dönerken, USER_END_USERS son kullanıcının kendi adını döner; etkin data role ise V$END_USER_DATA_ROLE içinde görünür. Veri erişimini belirleyen, temeldeki oturum hesabı değil bu katmanlı bağlamdır.

Data role'ler yine de fazla yetki verebilir

İnceleme bilinçli bir uyarı içeriyor: Data role'lere DBA dahil geniş geleneksel ayrıcalıklar da verilebilir ve bu ayrıcalıklar rolü tutan her son kullanıcıya akar. Yazar bir data role'e DBA verme örneğini gösteriyor; bunun sonucunda son kullanıcı, veritabanındaki herhangi bir tabloya karşı her türlü DML'i çalıştırma yeteneğini kalıtsal olarak alıyor. Bunun gösterilmesine değer olmasının nedeni tam olarak tehlikeli olması: Deep Sec'in ince ayrıntılı garantileri, yöneticilerin kaba ayrıcalıkları arka kapıdan yeniden sokmamalarına bağlıdır.

Neden önemli

İstemcinin bunu uygulayacağına güvenilemediğinde, veritabanının içinde zorunlu kılınan ince erişim denetimi en çok önem taşır ve otonom AI agent'lar bunun en belirgin son örneğidir. Kullanıcı adına veritabanlarını sorgulayan agent'lar, elindeki kimlik bilgileri kadar güvenlidir; bir agent geniş bir hesapla bağlanırsa, bir prompt enjeksiyonu veya halüsinasyon görmüş bir sorgu planı, o hesabın erişebildiği her şeye ulaşabilir. Deep Sec bu modeli tersine çevirip yetkilendirme sınırını verinin kendisine taşır; böylece bir kullanıcının asla görmemesi gereken satır, sütun veya hücre, sorguyu hangi araç, agent veya geçici istemcinin gönderdiğinden bağımsız olarak gizli kalır.

Kimliği şema sapliğinden ayırmak, uygulama ekiplerine binlerce uygulama kullanıcısı arasında tek bir veritabanı hesabını paylaşmaktan daha temiz bir model de sunar; harici kimlik sağlayıcı eşlemesi sayesinde bu kimlikler Entra ID veya OCI IAM'de yaşayabilir. Ancak DBA verme örneği dürüst bir uyarıdır: Çerçeve tam olarak kendisine söyleneni uygular ve özensiz bir rol ataması yine de her şeyi sızdırır. Buradaki tüm ayrıntılar Oracle'ın resmî dokümantasyonundan değil tek bir uygulayıcının incelemesinden geldiği için, özellik olgunlaştıkça ayrıntılar değişebilir.