Yönetici oturumlarında parola kadar yetki kontrolü de önemli

Örnek bir iş senaryosu

Arayüzde yönetim düğmesini gizlemek, ilgili API adresini bilen kişinin kayda ulaşmasını engellemez. Yetkisiz bir istemciden aynı adres çağrıldığında sunucunun reddetmesi gerekir. Oturum sona erdiğinde açık kalan sekmenin de yeni veri alamadığı test edilmelidir. Çıkış yalnızca çerezi silmekle kalmamalı, sunucudaki oturum kaydını da geçersiz hale getirmelidir.

Dört adımda çalışma düzeni

İlk bakışta görünmeyen noktalar

Yönetici hesabının kurtarma süreci de güvenlik tasarımının parçasıdır. Kolay tahmin edilen sorular veya herkese açık dosyada tutulan kurtarma bilgileri güçlü parolayı etkisizleştirebilir. Küçük bir sistemde sunucu yöneticisinin kontrollü parola sıfırlama aracı kullanması, aceleyle hazırlanmış güvensiz e-posta kurtarma akışından daha uygun olabilir. Parola değişince mevcut oturumların kapatılması değerlendirilmelidir. Yeni oturum kimliği yüksek rastgelelik içermeli, sunucuda mümkünse özeti tutulmalıdır. Yönetim işlemlerine ait günlükler hassas içerik yerine olay, kullanıcı ve zaman bilgisiyle sınırlanabilir. Yetki ve oturum testleri her önemli sürümde yeniden çalıştırılmalıdır.

Kontrolü kanıtla kapatma

Güvenlik ve yayın kontrolünde her madde için gözlenebilir bir sonuç belirleyin. “Giriş güvenli” demek yerine yetkisiz isteğin reddedildiğini, çıkış sonrası oturumun çalışmadığını veya çok büyük form gövdesinin kabul edilmediğini test edin. Sonuçları kullanılan sürüm ve tarih bilgisiyle kaydedin. Böylece daha sonraki değişikliklerde aynı davranış yeniden kontrol edilebilir. Test verileri gerçek müşteri verisinden ayrılmalıdır. Kayıt oluşturan testler sonrasında yalnızca test kayıtlarının temizlendiği doğrulanmalıdır. Başarılı kontrolün kapsamını açık tutun; birkaç test bütün sistemin kusursuz olduğunu göstermez.

Uygulama ile sunucu sorumluluklarını ayırın. Kod alan doğrulamasını yapabilir fakat dosya izinleri, sertifika bağlaması ve yedek erişimi sunucu düzeyinde doğru kurulmalıdır. Bir katmanın varlığı diğerini gereksiz hale getirmez. Kaynak dosyaları, yapılandırma sırları ve veritabanı herkese açık web klasörüne konulmamalıdır. Kullanıcıya gösterilen hata mesajı teknik ayrıntı veya gizli bilgi içermemeli; sunucu tarafındaki kayıt tanı koymaya yetecek kadar bilgi taşımalıdır. Yeni bir bileşen eklendiğinde saldırı yüzeyi ve bakım sorumluluğu da değerlendirilmelidir. Gereksiz özellikleri açık bırakmak sonraki kontrol yükünü artırır.

Kontrolleri tek seferlik teslim maddesi olarak görmeyin. Yeni sürüm, yeni entegrasyon veya yetki değişikliği bazı varsayımları geçersiz kılabilir. Düzenli bağımlılık taraması, erişim gözden geçirmesi ve geri dönüş denemesi planlayın. Otomatik taramanın bulgu vermemesi bütün açıkların bulunmuş olduğu anlamına gelmez. Kritik uygulamalarda kapsamlı bağımsız güvenlik değerlendirmesi ayrıca düşünülmelidir. Küçük bir işletme için başlangıçta en değerli adım çoğu zaman sorumlulukları ve kontrol takvimini netleştirmektir. Sertifika, yedek ve yönetici hesabı gibi temel bileşenlerin sahibi belli olduğunda sorunlar kişisel hafızaya daha az bağımlı kalır.

Ekibinize sorabileceğiniz sorular

• Yetkisiz API isteği reddediliyor mu?
• Çıkış sonrası eski oturum çalışıyor mu?
• Başarısız girişler sınırlanıyor mu?

Bu soruları seçtiğiniz örnek kayıt üzerinde yanıtlayın. Her açık nokta için sorumlu kişiyi, yapılacak düzeltmeyi ve yeniden kontrol tarihini not edin. Böylece görüşme, uygulanabilir bir iş listesiyle tamamlanır.