Kurumsal web uygulaması güvenliği, yayın öncesi yapılan tek bir testten ibaret değildir.

Kısa yanıt: kurumsal web uygulaması nasıl güvenli geliştirilir?

Önce veri sınıfları, kullanıcı rolleri, tehditler ve güven sınırları belirlenir. Kimlik doğrulama, yetkilendirme, oturum, girdi doğrulama, şifreleme, kayıt ve hata yönetimi merkezi kontrollerle uygulanır. Kod ve bağımlılıklar otomatik taranır; kritik akışlar manuel güvenlik testinden geçirilir. Yayında izleme, yedekleme ve olay müdahale planı devreye alınır.

• Tehdit modeli ve veri sınıflandırma
• Sunucu tarafında rol ve nesne bazlı yetki
• Güvenli oturum ve gizli bilgi yönetimi
• API, dosya yükleme ve girdi doğrulama
• Güvenlik kayıtları, alarm ve olay müdahalesi
• Risk düzeyine uygun doğrulama ve sızma testi

1. Güvenlik kapsamını riskle ilişkilendirin

Her uygulamaya aynı kontrol listesini mekanik biçimde uygulamak yeterli değildir. İşlenen verinin hassasiyeti, internetten erişim, kullanıcı rolleri, işlem değeri, entegrasyonlar ve olası kötüye kullanım senaryoları güvence düzeyini belirler.

OWASP ASVS, web uygulaması güvenlik kontrollerini tanımlamak ve doğrulama kapsamını sözleşme ile kabul kriterlerine bağlamak için açık bir temel sunar.

2. Kimlik ve yetkiyi birbirinden ayırın

Kimlik doğrulama kullanıcının kim olduğunu; yetkilendirme ise hangi kayıt ve işlemlere erişebileceğini belirler. Arayüzde butonu gizlemek güvenlik kontrolü değildir. Her hassas işlem ve veri isteği sunucu tarafında rol, sahiplik, müşteri hesabı ve nesne düzeyinde doğrulanmalıdır.

• Çok faktörlü kimlik doğrulama gerektiren roller
• Kısa ömürlü ve güvenli oturum yönetimi
• Yetki değişikliğinde oturumların yenilenmesi
• Müşteriler arasında veri ayrımının test edilmesi
• Yönetici işlemleri için ek kayıt ve onay

3. Veri ve API sınırlarını koruyun

İstemciden gelen her veri güvenilmez kabul edilir. Şema ve iş kuralı doğrulaması sunucuda yapılmalı; API yanıtları yalnızca gereken alanları dönmelidir. Dosya yükleme, dış bağlantı çağrıları, arama ve raporlama uçları ayrı kötüye kullanım senaryolarıyla test edilmelidir.

• Aktarımda ve gerekli alanlarda depolamada şifreleme
• Gizli anahtarların kod ve istemciden ayrılması
• Hız sınırlama ve kötüye kullanım kontrolleri
• Parametreli sorgular ve güvenli çıktı kodlama
• Yedeklerin erişim ve geri yükleme testleri

4. Güvenliği geliştirme akışına yerleştirin

Güvenlik yalnızca canlı öncesi sızma testine bırakılırsa temel mimari sorunları pahalı aşamada ortaya çıkar. Kod inceleme, statik analiz, bağımlılık ve gizli bilgi taraması her değişiklikte; dinamik testler ve kritik akış incelemeleri planlı aralıklarla çalıştırılmalıdır.

Otomatik tarama tek başına yeterli değildir. İş kuralı atlama, rol yükseltme ve müşteri verisi karışması gibi bağlama özgü riskler insan tarafından senaryo bazlı doğrulanmalıdır.

5. Kayıt, alarm ve olay müdahalesini test edin

Başarısız giriş, yetki reddi, kritik veri değişikliği, yönetici işlemi ve beklenmedik veri erişimi güvenlik kaydına dönüşmelidir. Kayıtların hassas veriyi açığa çıkarmaması, değiştirilmeye karşı korunması ve sorumlu ekibe zamanında alarm üretmesi gerekir.

• Kritik olayların sahibi ve müdahale süresi
• Şüpheli davranış için alarm eşikleri
• Kayıt saklama ve erişim politikası
• İhlal durumunda izolasyon ve iletişim planı
• Düzenli geri yükleme ve olay tatbikatı

Yayın öncesi kabul kriterleri

Canlıya geçiş kararı, 'test edildi' ifadesi yerine kanıtlanabilir kriterlere dayanmalıdır. Açık kritik bulgu bulunmaması, yüksek riskli bulgular için onaylı plan, rol matrisinin test sonucu, geri yükleme kanıtı, alarm denemesi ve güvenlik sorumlularının atanması yayın paketinde yer almalıdır.