Acente Yazılımlarında Güvenli Yazılım Geliştirme Yaşam Döngüsü

Güvenlik çoğu zaman bir yazılımın tamamlandıktan sonra test edilen bir özelliği gibi düşünülür. Ürün geliştirilir, canlıya alınmadan önce bir güvenlik taraması yapılır, bulunan açıklar kapatılır ve süreç tamamlanmış sayılır. Bu yaklaşımın sorunu, güvenlik hatalarının büyük kısmının tasarım ve kodlama aşamalarında ortaya çıkması, ancak geç fark edildiği için düzeltilmesinin çok daha maliyetli olmasıdır. Yanlış kurgulanmış bir yetki modeli, canlıya çıktıktan sonra değiştirilmesi en zor yapılardan biridir.

Güvenli yazılım geliştirme yaşam döngüsü (Secure Software Development Life Cycle), güvenliği sürecin sonuna eklenen bir kontrol olmaktan çıkarıp her aşamanın doğal bir parçası haline getirir. Bu yazıda bu yaklaşımın aşamalarını, sigorta acentelerine yazılım sağlayan bir ekip açısından ele alıyoruz. Acenteler için de değerlidir: Bir yazılım sağlayıcısını değerlendirirken sorulacak soruların çoğu bu aşamalardan çıkar.

Aşama 1: Gereksinimler

Her yeni özellik için iş gereksinimlerinin yanında güvenlik gereksinimleri de yazılır. Bir dışa aktarım özelliği tasarlanırken "kullanıcı müşteri listesini Excel olarak indirebilsin" cümlesinin yanına şu sorular eklenir: Hangi roller bu özelliği kullanabilir? Maskeli alanlar çıktıda nasıl görünecek? İşlem kayıt altına alınacak mı? Ek doğrulama gerekecek mi?

Bu aşamada kişisel veri envanteri de güncellenir. Yeni özellik hangi kişisel verileri işleyecek, nerede saklayacak ve ne kadar süre tutacak? Bu sorular erken sorulduğunda, gereksiz veri toplamanın önüne geçilir.

Aşama 2: Tasarım ve tehdit modelleme

Tehdit modelleme, bir özelliğin nasıl kötüye kullanılabileceğini önceden düşünme çalışmasıdır. Ekip, tasarımı masaya yatırır ve "bir saldırgan bu özellikle ne yapmaya çalışır?" sorusunu sorar. Basit bir çerçeve olarak şu başlıklar kullanılabilir:

• Kimlik taklidi: Biri başka bir kullanıcı ya da servis gibi davranabilir mi?
• Veri değiştirme: İstek veya yanıt yolda ya da istemcide değiştirilebilir mi?
• İnkar: Bir kullanıcı yaptığı işlemi sonradan inkar edebilir mi; kayıt yeterli mi?
• Bilgi ifşası: Yetkisiz biri veri görebilir mi; hata mesajları fazla bilgi veriyor mu?
• Hizmet kesintisi: Özellik aşırı istekle sistemi yavaşlatmak için kullanılabilir mi?
• Yetki yükseltme: Sıradan bir kullanıcı yönetici işlemi yapabilir mi?

Teklif akışları bu çalışmanın iyi bir örneğidir. Trafik, kasko ve DASK sorguları farklı veri girdileri ve farklı sigorta şirketi servisleriyle çalışan ayrı akışlardır. Her akış için girdilerin nasıl doğrulanacağı, hangi kimlik bilgileriyle dış servise gidileceği ve yanıtların nasıl saklanacağı ayrı ayrı değerlendirilmelidir.

Aşama 3: Geliştirme

Kodlama aşamasında güvenlik, ortak kurallar ve araçlarla desteklenir:

• Güvenli kodlama standartları: Girdi doğrulama, parametreli veritabanı sorguları, çıktı kodlama ve hata yönetimi için ekip içinde ortak kurallar bulunur.
• Hazır ve denenmiş kütüphaneler: Kimlik doğrulama veya şifreleme gibi kritik işlevler sıfırdan yazılmaz; olgun kütüphaneler kullanılır.
• Gizli bilgilerin koddan ayrılması: Parolalar ve anahtarlar kaynak koda yazılmaz; kod deposu bu tür bilgiler için otomatik taranır.
• Yetki kontrolünün sunucuda yapılması: Arayüzde bir düğmenin gizlenmesi, yetki kontrolü yerine geçmez.

Aşama 4: İnceleme ve test

Her değişiklik, canlıya alınmadan önce birden fazla süzgeçten geçer:

1. Kod incelemesi: Değişikliği yazan dışında en az bir geliştirici kodu inceler; güvenlik açısından kritik değişikliklerde inceleme listesine yetki, girdi doğrulama ve loglama soruları eklenir.
2. Statik analiz: Kod, bilinen hatalı kalıplar için otomatik araçlarla taranır.
3. Bağımlılık taraması: Kullanılan açık kaynak kütüphanelerde bilinen güvenlik açıkları kontrol edilir.
4. Yetki testleri: Farklı rollerdeki kullanıcıların yalnızca kendi yetkileri dahilindeki verilere erişebildiği otomatik testlerle doğrulanır.
5. Dinamik test: Çalışan uygulama, test ortamında saldırgan bakış açısıyla denenir.

Aşama 5: Dağıtım

Kodun canlı ortama taşınması da güvenlik açısından kritik bir adımdır. Dağıtımın otomatik ve tekrarlanabilir bir süreçle yapılması, elle yapılan yapılandırma hatalarını azaltır. Canlı ortamın erişim bilgileri yalnızca dağıtım sürecinde ve yetkili kişilerde bulunur. Test ortamında canlı müşteri verisi kullanılmaz; gerekiyorsa veri maskelenir. Her dağıtımın neyi değiştirdiği kayıt altına alınır ve bir sorun durumunda hızla önceki sürüme dönülebilir.

Aşama 6: İşletim ve izleme

Canlıya alınan yazılım, sürekli izlenir. Olağan dışı hata oranları, beklenmedik trafik artışları ve başarısız giriş denemeleri gibi sinyaller takip edilir. Kullanılan bileşenlerde yeni güvenlik açıkları yayımlandığında etkilenip etkilenilmediği değerlendirilir ve gerekli güncellemeler planlanır. Kullanıcılardan ve dış araştırmacılardan gelen güvenlik bildirimlerinin ulaşabileceği net bir kanal bulunur.

Döngünün kapanması

Yaşam döngüsü adını, son aşamanın ilk aşamayı beslemesinden alır. İzleme sırasında fark edilen bir zayıflık, bir sonraki özelliğin gereksinimlerine ve tehdit modeline girdi olur. Yaşanan her olay, süreçte hangi kontrolün eksik kaldığını sorgulamak için bir fırsattır. Bu geri besleme olmadan güvenli geliştirme, zamanla şekli bir kontrol listesine dönüşür.

Acenteler bu süreçten ne beklemeli?

Bir acente, yazılım sağlayıcısının iç süreçlerini doğrudan göremez; ancak doğru sorularla süreç hakkında fikir edinebilir. Kod incelemesi yapılıyor mu? Bağımlılıklar düzenli taranıyor mu? Test ortamında gerçek müşteri verisi kullanılıyor mu? Güvenlik açığı bildirildiğinde nasıl bir süreç işliyor? Güncellemeler nasıl duyuruluyor? Bu soruların açık ve tutarlı yanıtları, acente yazılımı seçiminde özellik listeleri kadar belirleyicidir.

Küçük ekipler için sadeleştirilmiş versiyon

Bu aşamaların tamamı büyük bir güvenlik ekibi gerektiriyormuş gibi görünebilir. Oysa küçük bir geliştirme ekibi de özü koruyarak sadeleştirilmiş bir döngü kurabilir: Her yeni özellik için kısa bir "nasıl kötüye kullanılır?" notu, her değişiklikte en az bir kişinin kod incelemesi, otomatik bağımlılık taraması ve rollere göre yazılmış birkaç temel yetki testi. Bu dört alışkanlık, güvenlik hatalarının önemli bir kısmını canlıya ulaşmadan yakalamaya yardımcı olur.

Güvenlik bir aşama değil, bir alışkanlık

Güvenli yazılım geliştirme, tek seferlik bir denetim değil, her gün tekrarlanan küçük kararların toplamıdır. InsureHub olarak acentelere sunduğumuz web paneli ve mobil uygulama için bu alışkanlıkların sürekliliğini önemsiyoruz. Geliştirme ve güncelleme yaklaşımımız hakkında sorularınız için demo talep formunu kullanabilirsiniz.