Supabase RLS: manuel denetim mi, tarama mı?

Satır Düzeyinde Güvenlik, verilerini koruyan bir Supabase projesi ile onu sessizce açığa çıkaran bir proje arasındaki çizgidir. RLS iyi yapılandırıldığında veritabanınız, RLS'ye tabi roller için satır düzeyinde erişim kurallarını uygular. Hizmet rolü de dahil olmak üzere ayrıcalıklı roller bu kuralları atlayabilir. Kötü yapılandırıldığında, tablolar korumalı görünürken politikalar istediğinizden daha fazlasının geçmesine izin verir.

Bu makalede Supabase RLS güvenlik kontrolü çalıştırmanın iki yolu karşılaştırılmaktadır: politikaların elle doğrulanması ve otomatik RLS denetiminin çalıştırılması. Her ikisinin de yeri var. Her birinin nerede bozulduğunu bilmek, veritabanı erişim politikalarınızın amaçlandığı gibi çalıştığını nasıl doğrulayacağınızdır.

RLS, Supabase'nin tablo başına sunduğu bir Postgres özelliğidir. Etkinleştirildiğinde tablo, politika izin vermediği sürece RLS'ye tabi rollere satır erişimini reddeder; tablo sahipleri ve atlama ayrıcalıklarına sahip roller istisnadır. Politikalar geçerli kullanıcıya, taleplerine ve çalıştırılan sorguya göre değerlendirilir. auth.uid() işlev genellikle çapadır: şöyle bir politika using (auth.uid() = user_id) oturum açan kullanıcının kendi veritabanı satırlarına erişimi sınırlar.

Model temizdir. Başarısızlıklar öyle değildir çünkü nadiren başarısızlık gibi görünürler.

Çoğu RLS sorununun nedeni birkaç modeldir:

• RLS tüm tablolarda değil bazı tablolarda etkindir. Lansmandan sonra eklenen veya geçiş yoluyla oluşturulan yeni bir tablo, RLS kapalı olarak gönderilebilir. Daha sonra her satır, tablo erişimi olan herhangi bir rol tarafından okunabilir.

• Göründüğünden daha geniş bir politika. using (true) bir seçme politikasında her satırın görünür olduğu anlamına gelir. Hata ayıklamak için geliştirme sırasında eklemek kolaydır ve kaldırmayı unutursunuz.

• Hizmet rolü her yerde üstlenildi. Hizmet rolü anahtarını kullanan sunucu tarafı kodu, RLS'yi tamamen atlar. Kullanıcıya yönelik istekler bu anahtar üzerinden yürütülürse politikalar hiçbir zaman uygulanmaz.

• Yanlış sütunu kontrol eden politikalar. auth.uid() = id bir masanın üzerinde id satırın birincil anahtarıdır, sahibi değil, hiçbir zaman amaçla eşleşmeyecektir. Politika mevcut, bir hata veya boş küme döndürüyor ve yüzey hala davranıyor.

• Uygun erişim kontrolleri olmadan veritabanı güncellemeleri ve silinmeleri. Geliştiriciler genellikle seçimi kapsamlı bir şekilde güvence altına alır ve yazma politikalarını gevşek bırakır. Okuma kontrolünü geçmek, bir sonraki satırı kimin değiştirebileceği hakkında hiçbir şey söylemez.

Bunların hiçbiri kendini duyurmuyor. Her biri uygulamanın çalışır durumda kalmasını sağlıyor ve tam da bu nedenle üretime kadar hayatta kalıyorlar.

Manuel denetim doğrudan yapılır ve yeni araçlar gerektirmez. Politikaların kendisi üzerinde masa masa çalışırsınız.

Her tabloyu listeleyerek ve her birinde RLS'nin etkinleştirildiğini onaylayarak başlayın. Daha sonra, her tablo için politikaları sıralayın ve bunları amaçlanan erişimle eşleştirin: kim okumalı, kim yazmalı ve kim ona asla dokunmamalı. Her politika ifadesini karşılaştırdığı sütuna göre okuyun. Seçme, ekleme, güncelleme ve silme işlemlerinin her birinin amaçlanan rolle eşleşen bir ilkesi olduğunu doğrulayın.

Ardından kod yolunu kontrol edin. Uygulamanızın kullanıcıya yönelik istekler için gerçekte hangi anahtarı kullandığını ve bunlardan herhangi birinin hizmet rolü üzerinden çalışıp çalışmadığını belirleyin. Daha sonra farklı kullanıcılar olarak test sorguları yazın ve sonuçların beklentilerle eşleştiğini doğrulayın: Kullanıcı kendi satırlarını, başka kimseninkini okumamalı ve kendisine ait olmayan bir satırı güncelleyememelidir.

Manuel inceleme yapmaya değer ve çok şey yakalıyor. Aynı zamanda öngörülebilir kör noktalara da sahiptir.

• Test etmeyi hatırladığınız şeyleri test eder. İkinci kullanıcı olarak silmeyi denemeyi düşünmüyorsanız aşırı geniş bir silme politikasını kaçırabilirsiniz. RLS etkinleştirildiğinde, geçerli silme politikasının olmaması, silme işleminin reddedildiği anlamına gelir.

• Yaşlanır. Özellikler eklendikçe politikalar değişir. Geçen çeyrekte kapsamlı bir inceleme, geçen hafta eklediğiniz tablo hakkında hiçbir şey söylemiyor.

• Politikaları yapılandıran aynı kişiye bağlıdır. Politikayı yazan inşaatçının kendi varsayımını fark etme olasılığı en düşüktür.

• Kayıtlı kanıtlara ihtiyacı var. "İnceledim ve doğru görünüyordu" ifadesi geride hiçbir şey bırakmıyor: kanıt yok, kapsam yok, daha sonra yeniden tarayabileceğiniz hiçbir yapı yok.

Manuel denetim "bu benim zihinsel sistem modelime uyuyor mu?" sorusunu yanıtlıyor. Tek başına veritabanının gerçekte ne döndüreceğini kanıtlamaz.

Otomatik bir Supabase RLS güvenlik kontrolü diğer yönden çalışır. Projeyi bir saldırganın veya yanlış yapılandırılmış bir istemcinin yapacağı şekilde çalıştırır ve veri katmanının gerçekte neye izin verdiğini rapor eder.

Bu değişim üç nedenden dolayı önemlidir. İlk olarak geçmiş belleği ölçeklendirir: tarama, yapılandırılmış kapsamı dahilindeki tablolar ve uç noktalardaki kontrolleri tekrarlar. Harici bir tarama, uygun erişim olmadan her politikayı inceleyemez. İkincisi, üzerinde işlem yapabileceğiniz kanıtlar üretir: Bulgu tabloyu, politika durumunu ve onu ulaşılabilir kılan koşulu adlandırır, böylece neyi ve nedenini değiştirmeniz gerektiğini bilirsiniz. Üçüncüsü tekrarlanabilir olmasıdır. Tekrar çalıştırabileceğiniz bir kontrol, tek seferlik incelemeyi sürekli doğrulamaya dönüştürür.

VICE, web uygulamalarını ve Supabase/RLS yapılandırmalarını tarar, ardından bulguları arkalarındaki kanıtlarla ve üzerinde çalışılacak düzeltme kılavuzuyla birlikte rapor eder. Bir düzeltmeyi işaretleyebilir ve yeniden kontrol talebinde bulunabilirsiniz, ancak yalnızca karşılaştırılabilir bir yeniden tarama sorunun çözüldüğünü doğrular: düzeltme, düzenlemeden varsayılmaz, aynı kapsamda doğrulanır. Planlanmış taramalar ve uyarılar devam eden izlemeyi desteklemektedir, dolayısıyla gelecek ay eklenen bir tablo aradaki boşluğu sessizce yeniden ortaya çıkarmayacaktır.

İş bölümü basittir. Manuel incelemenizin neyi gözden kaçırdığını bulmak için otomatik kontrolü çalıştırın, ardından tarama işaretlerinin her politikanın ardındaki amacı doğrulamak için manuel geçiş kullanın. Otomasyon size veritabanının neye izin verdiğini söyler; Bu iznin kasıtlı olup olmadığına siz karar verirsiniz.

Herhangi bir taramadan elde edilen puan, test edilen kapsamı tanımlar, projenin tamamen güvenli olduğunu garanti etmez. Bunu bir sertifika olarak değil, nereye bakılacağının bir işareti olarak değerlendirin.

Supabase ile oluşturulmuş bir ürünü dağıtıyorsanız ve politikalarınızı hiç denetlemediyseniz, dürüst cevap sırasıyla her ikisidir. Otomatik bir RLS kontrolüyle başlayın, böylece tablolarınızın neye izin verdiğine dair güncel, kanıta dayalı bir resme sahip olursunuz. Daha sonra bulguları elle yürütün, her politikanın amacını doğrulayın ve sapmaları düzeltin. Yeni tabloların ve yeni politikaların orijinalleriyle aynı incelemeye tabi tutulması için otomatik kontrolü bir programa yerleştirin.

Her iki yaklaşımın da atlanması, verileri koruyormuş gibi görünen ancak yine de yetkisiz erişime izin veren bir veritabanı erişim politikasının ortaya çıkmasına neden olabilir.

Ücretsiz taramayı başlatın Kaydolmadan önce genel web sitenizi kontrol etmek için vice-platform.com adresini ziyaret edin. Özel bir Supabase taraması, doğrulanmış bir alan adı ve ücretli bir abonelik veya satın alınan kredi gerektirir; kapsamı yapılandırılmış erişime bağlıdır.