Güvenlik değerlendirmesi öncesi kontrol listesi

Penetrasyon testi öncesi neden “hazırlık” ayrı bir fazdır?

Kurumsal yazılım projelerinde güvenlik değerlendirmesi (penetrasyon testi, sızma testi veya bağımsız denetim) genelde sözleşmede tek satırla geçer; pratikte ise haftalar süren koordinasyon gerektirir. Hazırlıksız girilen testler yüksek sayıda “bilinen” bulgu üretir, asıl mimari zayıflıkları gölgede bırakır ve ekip moralini düşürür. Ön kontrol listesi, değerlendirmeyi olgunluk ölçümüne dönüştürür.

Aksiyon Soft kurumsal yazılım ve müşteri portalı projelerinde bu listeyi Definition of Done ve go-live kapılarına bağlar.

• • •

Kimlik doğrulama ve oturum yönetimi

Değerlendirme ekibi ilk gün giriş mekanizmasına odaklanır. Kontrol edin:

• Çok faktörlü doğrulama kritik rollerde zorunlu mu?
• Parola politikası ve kilitleme eşikleri merkezi kimlik ile uyumlu mu?
• Oturum süresi, idle timeout ve güvenli çıkış senaryoları tanımlı mı?
• SSO entegrasyonunda token yenileme ve iptal akışları test edildi mi?

Portal projelerinde SSO ve oturum güvenliği rehberimizdeki maddeler bu bölümle örtüşür.

Yetkilendirme ve veri sınırları

“Giriş yapabiliyorum” yetmez; “başkasının verisini göremiyorum” kanıtlanmalıdır. Rol ve kapsam modeli dokümante mi? RBAC erişim modeli ile uyumlu mu? Yatay yetki yükseltme (ID değiştirerek başka kayda erişim) senaryoları otomatik testlerde var mı?

API katmanında yetkisiz uç nokta çağrıları tutarlı 403/401 dönüyor mu; hata gövdesi iç yapı sızdırmıyor mu?

• • •

Günlük, izleme ve olay müdahale

Denetçiler sadece kodu değil operasyonu da sorar. Kimlik doğrulama hataları, yetkisiz erişim denemeleri ve yönetici işlemleri loglanıyor mu? Loglarda kişisel veri ve gizli anahtar maskeleniyor mu? Erişim rol tabanlı mı?

Gözlemlenebilirlik yatırımı burada değer kazanır: alarm, runbook ve eskalasyon yolu yazılı değilse bulgular kapanmaz.

Bağımlılık yüzeyi ve tedarik zinciri

Kurumsal uygulamalarda üçüncü parti kütüphane ve container imajları sürekli güncellenmelidir. Kontrol listesi:

• CI’da bilinen CVE taraması çalışıyor mu?
• Kritik bulgular için SLA tanımlı mı?
• Gizli anahtarlar kod deposunda değil, güvenli kasada mı?
• Üretim ve test ortamları ayrılmış mı; varsayılan parolalar kapatıldı mı?

Veri koruma ve uyumluluk

KVKK ve sektör regülasyonları “teknik önlem” listesi ister: şifreleme (aktarım ve gerektiğinde durağan), yedekleme, erişim kaydı, veri silme ve anonimleştirme prosedürleri. Veri sınıflandırması (kişisel, finansal, operasyonel) yapıldı mı? Penetrasyon testi kapsamı hangi ortamda, hangi veri setiyle yürütülecek—net mi?

API ve entegrasyon güvenliği

Dışa açık API’ler rate limit, kimlik doğrulama ve sözleşme disiplini gerektirir. API sözleşmesi dokümantasyonunda güvenlik bölümü var mı? Webhook imzaları ve replay koruması değerlendirme kapsamına dahil mi?

Değerlendirme günü organizasyonu

Test ekibine güncel mimari diyagram, rol matrisi, test hesapları ve bilinen kısıtlar (IP whitelist, maintenance penceresi) verin. Bulgu triyajında iş birimi temsilcisi olsun; “kabul edilebilir risk” kararları yazıya dökülsün. Remediation sprint’i planlanmadan rapor kapanmasın.

Çözümler ve özel yazılım sayfalarımız tipik teslimat kapsamını gösterir; güvenlik hazırlığı keşifte konuşulmalıdır.

Bulgu önceliklendirme ve risk kabulü

Değerlendirme raporu geldikten sonra her bulgu için CVSS skoru kadar iş etkisi de tartılmalıdır. Düşük teknik skorlu ama yüksek veri sızıntısı riski taşıyan madde önceliklidir. Risk kabulü (accept) kararları üst yönetim veya atanmış risk sahibi imzası ile kayıt altına alınmalı; “sonra bakarız” notu denetimde geçersizdir.

Remediation sprint’inde kapasite ayrılmazsa bulgular yaşlanır ve bir sonraki yıllık testte aynı maddeler tekrarlanır. Güvenlik borcu, teknik borç gibi görünür backlog maddesi olmalıdır.

Üçüncü parti ve bulut paylaşım modeli

SaaS bağımlılıkları, kimlik sağlayıcıları ve barındırma sağlayıcısı sorumluluk matrisi (shared responsibility) değerlendirme kapsamına girer. Veri nerede duruyor, yedek kimde, alt işleyen sözleşmesi var mı—soruları hazırlık aşamasında yanıtlayın. Penetrasyon testi yalnızca uygulama katmanını değil, yapılandırma hatalarını da hedefler: açık storage bucket, yanlış CORS, debug modunun açık kalması.

Test ortamı ve veri sentetiği

Penetrasyon testinde gerçek müşteri verisi kullanılmamalıdır; sentetik veya maskelenmiş veri seti hazırlayın. Test hesapları her rol için (admin, standart kullanıcı, entegrasyon servisi) ayrı tanımlanmalı; parolalar değerlendirme bitince rotate edilmelidir.

Staging ortamının güvenlik yapılandırması production’dan gevşek olmamalıdır. “Zaten test” mantığıyla açık bırakılan admin paneli veya debug endpoint’i bulguların yarısını oluşturur. Aynı kontrol listesini staging için de uygulayın.

Değerlendirme sonrası süreklilik

Tek seferlik test yerine yıllık tekrar veya major sürüm öncesi kısa test planlayın. CI/CD pipeline’a SAST/DAST adımları eklemek, regresyon riskini azaltır. Güvenlik gereksinimleri Definition of Done’a yazıldığında yeni özellikler eski açıkları yeniden açmaz.

Yönetim kuruluna sunulacak tek sayfalık “güvenlik durumu” özeti: açık kritik bulgu sayısı, ortalama kapatma süresi, son bağımlılık taraması tarihi ve bir sonraki değerlendirme tarihi. Bu özet proje steering toplantısının sabit gündem maddesi olabilir.

Müşteri veya denetçi NDA altında rapor istediğinde redaksiyon süreci önceden tanımlı olmalı; ham penetrasyon raporu paylaşılmamalıdır.

Özet kontrol listesi (tek sayfa)

• Kimlik, oturum, MFA
• RBAC ve yatay erişim testleri
• Log, alarm, runbook
• Bağımlılık ve secret yönetimi
• Veri sınıflandırması ve yedekleme
• API yüzeyi ve entegrasyon
• Remediation sahipliği ve tarih

İç ekip ve tedarikçi koordinasyonu

Penetrasyon testini yapan firma, geliştirme ortağınız ve iç BT aynı iletişim kanalında bulunmalıdır. Bulgu triyajında “bizim mi, onların mı” tartışması günler kaybettirir; RACI tablosu test başlamadan imzalanmalıdır. Kritik bulgu için hotfix branch politikası ve acil onay hattı önceden yazılı olmalıdır.

Değerlendirme kapsam dışı bırakılan sistemleri (legacy modül, eski portal) liste halinde rapora ekleyin; “test edilmedi” alanı denetçi için şeffaflık sağlar ve sonraki dönem planına girdi oluşturur.

Özet

Güvenlik değerlendirmesi öncesi kontrol listesi, bulgu sayısını değil hazır olma seviyesini artırır. Portal, API ve operasyon katmanlarını birlikte ele alın; sonuçları ürün yol haritasına bağlayın. Destek için iletişim formunu kullanın. Değerlendirme tarihinden en az iki hafta önce bu listeyi iç denetimle birlikte gözden geçirmeniz remediation süresini kısaltır. Listeyi PDF olarak arşivleyip yıllık güvenlik takviminize ekleyin; bir sonraki değerlendirme döngüsünde aynı şablonu kullanın. Hazırlık skorunuzu her madde için evet/hayır işaretleyerek ölçün; %80 altındaysa test tarihini ertelemek daha ucuzdur.