Güvenli özellikleri yavaşlamadan yayına almak

Güvenliği kendilerini yavaşlatan bir unsur olarak tanımlayan ekipler, aslında genellikle yeniden yapılması gereken işlerden (rework) bahsediyorlardır.

Bir özellik yayına alınır. İki hafta sonra yapılan bir sızma testi, bir müşterinin URL'deki bir sayıyı değiştirerek başka bir müşterinin belgelerini okuyabildiğini ortaya çıkarır. Bunu düzgün bir şekilde çözmek, veri katmanının kimin neyi görmeye yetkili olduğuna karar verme mantığını değiştirmeyi gerektirir; bu da o katman üzerine inşa edilmiş tüm ekranları etkiler. O iki haftalık süre, üzerinde yeterince düşünülmemiş bir temel üzerine inşa etmenin bedelidir ve faturası güvenlik çalışmalarına kesilir.

Bunu önleyecek olan konuşma tasarım aşamasında yapılır, yarım saat sürer ve odada uzman birinin bulunmasını gerektirmez.

Şemayı oluşturmadan önce dört soru

Bunu yapmaya kimin yetkisi var? Tartışma genellikle bir rolün adının konulmasıyla sona erer; oysa asıl mesele, hangi spesifik satırlara erişilebileceğidir. Bir müşteri ilişkileri yöneticisi, kendi müşterilerinin hesaplarını görebilir. Peki, hangi ilişki? Nerede kayıtlı? Nasıl kontrol ediliyor?

İstek iki kez, sıra dışı bir sırayla veya beklenmedik bir yerden gelirse ne olur? Sabırsız kişiler veya kötü bağlantıya sahip kullanıcılar ödeme işlemlerini iki kez gönderebilir. Eğer mükerrer gönderimin sonucu iki kez para transferi yapılmasıysa, bu sonradan bulunacak bir yazılım hatası (bug) değil, bir tasarım sorunudur.

Nelerin kaydı tutulmalı, nelerin kaydı asla tutulmamalıdır? İşlem referansı kayıtta yer almalıdır. Ancak kart numarası veya içinde kart numarası barındıran isteğin tüm gövdesi (request body) kayıtta yer almamalıdır.

Ve gelelim o rahatsız edici soruya: Kararlı birinin bu özelliği kullanarak yapabileceği en kötü şey nedir? Amaç bunu toplantıda çözmek değil; sadece cevabın utanç verici mi yoksa maliyetli mi olduğunu anlamaktır.

Hataların asıl kaynağı yetkilendirme mekanizmasıdır

Tüm ilgi odağı şifrelemededir. Oysa asıl sorunlar yetkilendirme kısmında yatar ve kod incelemelerinde (code review) göze sıkıcı görünürler.

Sorunların çoğuna yol açan kalıp şudur: Arayüz kullanıcıya yalnızca kendi kayıtlarını sunar, bu nedenle arka plandaki sorgu kaydı ID'ye göre getirecek şekilde yazılır. Kaydın isteği yapan kişiye ait olduğu kontrolü, bağlantıyı oluşturan ekranda yapılır ve uç nokta (endpoint) bu kontrole güvenir. Sonra birisi uç noktayı doğrudan çağırır.

Bunun çözümü, dikkatli olmaktan ziyade yapısal bir değişiklik gerektirir. Yetkilendirme işlemi, veriyi çeken katmanda yer almalıdır; böylece bu işlemi atlayan bir sorgu en baştan yazılamaz hale gelir. Postgres'teki Satır Düzeyinde Güvenlik (Row Level Security) bunu başarıyla uygular: Güvenlik politikası doğrudan tablo üzerinde tanımlanır; dolayısıyla, Cuma günü yorgun bir geliştirici tarafından yazılan bir sorgu da, dikkatli bir geliştiricinin yazdığı sorguyla birebir aynı güvenlik kurallarına tabi olur. Bu sitenin kendi veritabanı da bu prensiple çalışır; bu yüzden iletişim formu tablosunda hiçbir okuma politikası yok.

Bu tür bir mekanizmanın mevcut olmadığı durumlarda ise aynı mantık bir yazılım geleneği olarak uygulanır: Çağıran tarafı parametre olarak alıp yalnızca görmeye yetkili oldukları kayıtları döndüren tek bir fonksiyon kullanılır ve tabloya bu fonksiyonu devre dışı bırakarak erişilmesini sağlayan başka hiçbir yol oluşturulmaz.

Geriye kalan risklerin büyük bir kısmı, üç temel alışkanlıkla daha kontrol altına alınır. Gizli bilgiler (şifreler, API anahtarları vb.) asla kod deposuna (repository) dahil edilmez ve istemci tarafındaki paketlere (bundle) gömülmez; çünkü tarayıcının indirebildiği her şey, dosya adı ne olursa olsun herkese açıktır. Bağımlılıklar panik içinde değil, belirli bir takvime göre güncellenir; zira ana sürümü dört sürüm geride kalmış bir framework'ü güncellemek basit bir görev değil, başlı başına bir projedir ve bu ihtiyaç genellikle yayınlanan bir güvenlik açığı nedeniyle zorunlu hale geldiği o kritik haftada karşınıza çıkar. Son olarak, form verileri tarayıcıda doğrulanmış olsa bile sunucu tarafında da mutlaka doğrulanır; tarayıcıdaki kontrol, sisteme erişimi engellemek için değil, kullanıcının yaptığı hatayı anında fark etmesini sağlamak içindir. Zira herhangi biri, ilgili sayfayı yüklemeden de doğrudan uç noktaya (endpoint) istek gönderebilir.

Kod incelemesinde (review) neler sorgulanır?

Bir özellik canlıya alınmadan önce, kasıtlı olarak kısa tutulmuş bir kontrol listesi üzerinden gözden geçirilir; listenin kısa tutulmasının nedeni, gerçekten kullanılmasını sağlamaktır.

Bu uç nokta oturum açmamış biri tarafından çağrılabilir mi; çağrılırsa ne olur? Kayıt döndüren her sorgu, çağrıyı yapan tarafın o kayda erişim yetkisi olduğunu kanıtlıyor mu? Hata mesajları, bir e-posta adresinin kayıtlı olup olmadığı gibi, normal bir kullanıcının bilmesine gerek olmayan bilgileri saldırgana ifşa ediyor mu? Hassas veriler günlük kayıtlarına (log) işleniyor mu? E-posta gönderen, hesap oluşturan veya çalıştırılması maliyetli olan işlemler için bir hız sınırı (rate limit) mevcut mu? Aynı istek iki kez geldiğinde özellik hala doğru şekilde çalışıyor mu?

İncelemelerin çoğunda herhangi bir sorun tespit edilmez. Sorun bulunan durumlarda ise bu genellikle ilk iki soruda ortaya çıkar.

Düzenlemeye tabi çalışmalar, mühendislik disiplininin tek başına kapsamadığı bir gereksinimi ekler: sonrasında ne olduğunu gösterebilme yeteneği. Bu, işlemle birlikte kaydedilmek yerine işlemin bir parçası olarak yazılan bir denetim izi demek; böylece tanımladığı kayıtla çelişemiyor. Veritabanı geri yüklemesinden sonra hangi olayların ayakta kalması gerektiğini bilmeyi gerektiriyor. Bir de güçlü müşteri kimlik doğrulamasını baştan ödeme akışına yerleştirmeyi; çünkü tek faktörlü bir ödeme sistemine ikinci bir faktör eklemek, ödeme sistemini yeniden oluşturmaya çok yakındır.

Bunların hiçbiri yavaş değildir. Hepsini sonradan eklemek yavaştır.

Şemayı yazmadan önce yetkilendirmeyi düşünen, bağımlılıklarını güncel tutan ve yayınlamadan önce kısa bir inceleme yapan bir ekip, bu üçünü de atlayan bir ekipten daha yavaş yayınlamaz. Test raporuyla birlikte gelen iki haftalık planlanmamış çalışma olmadan yayınlanır. Yürüttüğümüz en hızlı projeler, bunu ortadan kaldıranlar değildi. Hiç durmak zorunda kalmayanlardı.