Güvenlik bir özellik listesi değil, varsayılanların toplamı
Bir sistemin güvenliğini belirleyen şey eklediğin kontroller değil, hiç kimse düşünmediğinde ne olduğu. Ve çoğu ihlal, kapatılmamış bir varsayılandan çıkıyor.
This post is in Turkish.
Güvenlik konuşmaları genelde eklenen şeyler üzerinden yürüyor: şifreleme var mı, iki adımlı doğrulama var mı, denetim kaydı var mı.
Ama üretimde gördüğüm hataların çoğu eksik bir özellikten çıkmadı. Kimsenin dokunmadığı bir varsayılandan çıktı. Herkese açık kalmış bir depolama kovası, kapatılmayan bir hata ayıklama uç noktası, silinmemiş bir örnek hesap.
Bu iki şey arasındaki fark önemli: özellik eklemek bir karar gerektiriyor, varsayılan ise karar verilmediğinde geçerli olan şey. Ve sistemler çoğu zaman karar verilmemiş alanlardan sızıyor.
Reddet, sonra izin ver
En temel kural: bir kaynağa erişim varsayılan olarak kapalı olmalı ve açmak açık bir işlem gerektirmeli.
Bunun tersi — varsayılan açık, tehlikelileri kapat — teoride aynı sonucu veriyor, pratikte vermiyor. Çünkü kapatılacaklar listesi tamamlanmıyor. Yeni bir tablo ekleniyor, yeni bir uç nokta yazılıyor, ve listeye eklenmesi unutuluyor. Unutulan şey açık kalıyor.
Reddet-önce modelinde unutmanın sonucu farklı: unutulan şey çalışmıyor. Bu bir hata olarak görünüyor, geliştirici fark ediyor, düzeltiyor. Yani hata modu sessiz sızıntı değil, gürültülü arıza.
RLS yazısında anlattığım şeyin özü buydu. Politikası olmayan tablo veri döndürmüyor — sessizce her şeyi döndürmüyor.
İyi bir güvenlik modelinde unutmak, açığa değil arızaya yol açar.
En sık üç varsayılan
Somut olarak en çok karşılaştığım üçü şu.
Depolama. Veritabanı politikaları özenle yazılmış, dosya kovası herkese açık. Belge taşıyan bir üründe bu, veritabanı sızıntısıyla aynı sonucu veriyor — sadece daha kolay fark ediliyor, çünkü URL paylaşılabiliyor.
Yönetim arayüzleri. Geliştirme sırasında açılan bir panel, bir metrik uç noktası, bir sorgu konsolu. Üretime çıkarken kapatılması gerekiyor ama kapatma işi kimsenin görev listesinde yok.
Hata mesajları. Ayrıntılı yığın izleri geliştirmede faydalı, üretimde saldırgana harita veriyor. Varsayılan ayrıntılıysa, birinin bunu kapatmayı hatırlaması gerekiyor.
Sırlar koddan önce sızıyor
Dördüncü ve en yaygın kategori sırlar.
Bir anahtarın sızmasının en sık yolu bir saldırı değil. Depoya işlenmiş bir yapılandırma dosyası, hata ayıklama çıktısına basılmış bir başlık, bir ekran görüntüsü, bir destek biletine yapıştırılmış istek örneği.
Bu yüzden sandbox yazısında anlattığım kural — logların sırları filtrelemesi — aslında bir güvenlik kontrolü değil, bir varsayılan. Filtreleme varsayılan olarak açık olduğunda, kimsenin dikkatli olmasına gerek kalmıyor.
Ve bir sır sızdığında en önemli soru "nasıl oldu" değil, "ne kadar sürede döndürebiliyoruz". Döndürülemeyen bir anahtar, sızdığı gün ürünü yeniden yazmak demek.
Rahatsızlık bir sinyal
Son bir gözlem. Güvenli varsayılanlar rahatsız edici — bir şeyi çalıştırmak için fazladan adım atıyorsun, bir uyarı seni bloke ediyor, bir izin açıkça verilmek zorunda.
Bu rahatsızlığı azaltmanın iki yolu var. Biri kuralı gevşetmek. Diğeri, izin vermeyi kolay ama açık hâle getirmek — tek satırlık, incelenebilir, sürümlenmiş bir izin tanımı.
Birincisi kısa vadede hızlandırıyor. İkincisi, altı ay sonra "bu neden açıktı" sorusuna cevap verebilmeni sağlıyor.