Yazılım Geliştirme ve Çözümleri
Yazılım Projelerinde Güvenlik Gereksinimlerini Belirleme
Güvenliği proje sonunda kontrol etmek yerine gereksinim toplama sürecine dahil edin. Veri, yetki, tehdit ve kabul ölçütlerini birlikte ele alan uygulanabilir bir rehber.
Güvenlik, gereksinim toplama sürecinin parçasıdır
Yazılım güvenlik gereksinimleri; iş hedefleri, korunacak veriler, kullanıcı yetkileri ve olası kötüye kullanım senaryoları birlikte incelenerek belirlenir. Öncelikli riskler, uygun kontroller ve doğrulanabilir kabul ölçütleriyle ilişkilendirilir. Böylece güvenlik, proje sonunda yapılan belirsiz bir inceleme olmaktan çıkar; analizden bakıma kadar izlenebilen bir teslimat kapsamına dönüşür.
Örneğin müşteri kayıtlarının görüntülenmesi yalnızca bir ekran gereksinimi değildir. Hangi çalışanın hangi kaydı görebileceği, dışa aktarım yapıp yapamayacağı ve işlemin nasıl kaydedileceği de tanımlanmalıdır. Bu konular başlangıçta konuşulmazsa arayüz tamamlandıktan sonra veri modeli ve servis katmanında değişiklik gerekebilir. Erken alınan güvenlik kararları, işlevsel beklentilerle teknik tasarım arasındaki çelişkileri görünür kılar.
Sürece ürün sorumlusu, geliştiriciler, operasyon ekibi ve güvenlik kararlarını değerlendirebilecek kişiler katılmalıdır. Kişisel veri veya sektörel yükümlülük varsa hukuk ve uyum uzmanlarının görüşü de alınmalıdır. İlk çıktı; kapsamı, varsayımları, riskleri ve kabul koşullarını gösteren ortak bir gereksinim kaydıdır. Amaç her projeye aynı kontrolleri eklemek değil, işin riskine uygun korumayı gerekçelendirmektir.
Kontrol listesi
Proje başlangıcında hangi sorular sorulmalı?
Keşif toplantısında yalnızca ekranlar ve iş akışları konuşulmamalıdır. Sistemin yanlış kullanılması, verinin açığa çıkması veya hizmetin durması halinde oluşacak iş etkisi de açıklığa kavuşturulmalıdır. Yanıtı bilinmeyen konular açık soru olarak kaydedilmeli; gerekiyorsa geçici varsayım belirtilmeli ve karar sorumlusu atanmalıdır. Varsayımlar, kesinleşmiş gereksinimler gibi ele alınmamalıdır. Yanıtlar birbirini etkileyebilir: dışa aktarılan bir rapor hem yetkilendirme hem veri saklama konusudur. Kararlar ayrı ekiplerin notlarında dağınık kalmamalı, ilgili kişilerin erişebildiği ortak bir kayıtta tutulmalıdır. İlk sürümde kapsam dışında bırakılan işlevlerin yanı sıra kullanılmayan yönetim uç noktaları, test hesapları ve entegrasyon seçenekleri de değerlendirilmelidir. Böylece inceleme, kullanıcıya gösterilen ekranlarla sınırlı kalmaz. Arka plandaki teknik erişim noktaları ve değişen varsayımlar da kapsam değerlendirmesine alınır. Sözlü mutabakatla ilerlemek yerine kararın gerekçesi ve etkilediği gereksinimler kaydedilir. Bu kayıt, tasarım sırasında ortaya çıkan yeni soruların hangi kişi veya ekip tarafından yanıtlanacağını da gösterir.
- ✓
İş açısından kritik olan nedir?
Yanlış ödeme, yetkisiz değişiklik veya hizmet kesintisi hangi süreçleri etkiler? Etkiyi iş diliyle tanımlayın.
- ✓
Sisteme kimler erişecek?
Çalışanları, müşterileri, yöneticileri ve servis hesaplarını ayırın. Hesapların açılma ve kapatılma koşullarını konuşun.
- ✓
Veri nereden geliyor, nereye gidiyor?
Formları, dosya yüklemelerini, API bağlantılarını, raporları ve yedekleri inceleyin. Üçüncü taraf erişimlerini belirleyin.
- ✓
Öne çıkanlar
Veriyi ve erişim yetkilerini birlikte sınıflandırın
Bir verinin hassasiyetini yalnızca alan adına bakarak değerlendirmek yeterli değildir. Müşteri listesi, ticari fiyatlandırma ve işlem geçmişi farklı nedenlerle korunabilir. Veri envanterinde kullanım amacı, sahibi, saklandığı yer ve erişebilen roller bulunmalıdır. Raporlar ve geçici dosyalar gibi veri kopyaları da envantere dahil edilmelidir. İşlev için kullanılmayan alanların toplanması ayrıca sorgulanmalıdır. Yetki matrisi, rollerin hangi kaynak üzerinde hangi işlemleri yapabileceğini gösterir. Görüntüleme, oluşturma, güncelleme, silme ve dışa aktarma ayrı değerlendirilmelidir. Yetki yalnızca role bağlı olmayabilir; kayıt sahipliği, ekip veya kurum sınırı da belirleyici olabilir. Çok kiracılı ürünlerde kurumlar arası veri yalıtımı özellikle test edilmelidir. Saklama ve silme kararları ise iş ihtiyaçları ve ilgili hukuki yükümlülüklerle birlikte ele alınmalıdır. Bu kararların teknik uygulaması geliştiricilere ait olsa da veri toplamanın amacı ve saklama ihtiyacı yalnız teknik ekibin varsayımına bırakılmamalıdır. İş sahibi kullanım gerekçesini açıklamalı, ilgili uzmanlar yükümlülükleri değerlendirmelidir. Böylece yetki matrisi ile veri envanteri aynı iş bağlamına dayanır ve çelişen kararlar daha erken fark edilir. Belgeler de bu kararlarla birlikte güncellenmelidir.
En az ayrıcalık
Her role yalnızca işi için gerekli yetkileri verin. Yönetici erişimini günlük kullanıcı işlemlerinden ayırın.
Veri yaşam döngüsü
Toplama, aktarım, saklama, arşivleme ve silme aşamalarını tanımlayın. Yedekleri ve loglardaki kopyaları unutmayın.
Sunucu tarafında denetim
Düğmeyi gizlemek erişim kontrolü değildir. Yetki koşullarını ilgili API veya servis katmanında uygulayın.
Uygulama süreci
Tehdit modelini iş akışları üzerinden oluşturun
Tehdit modelleme, sistemin nasıl kötüye kullanılabileceğini tasarım aşamasında tartışma yöntemidir. Başlangıç için kullanıcıları, uygulamaları, servisleri, veri depolarını ve bağlantıları gösteren anlaşılır bir veri akış çizimi kullanılabilir. Güven sınırları, farklı güven düzeyleri arasında bilgi geçişini görünür kılar. İnceleme yalnız dış saldırganları değil, hatalı yapılandırmayı ve yetkili hesapların kötüye kullanımını da kapsamalıdır. Çalışmayı ödeme onayı, dosya yükleme veya şifre yenileme gibi somut akışlarla yürütün. Her senaryoda korunacak varlığı, olası etkiyi, mevcut kontrolü ve açık kalan riski yazın. Örneğin dosya yüklemede zararlı içeriğin yanı sıra başka kullanıcının dosyasına erişim ve depolama kaynaklarının tüketilmesi de değerlendirilmelidir. Öncelikleri olasılık ve iş etkisine göre belirleyin; kontrol seçerken uygulanabilirliği de değerlendirin. Tek bir “dosya yükleme güvenliği” maddesi, bu farklı senaryoların tasarım ve test kapsamını açıklamak için yeterli değildir. Her senaryonun karşılığı ayrı bir kontrol veya kabul koşulu olabilir. Tasarım değiştiğinde model de güncellenmeli; ilk toplantıda hazırlanıp unutulan bir belgeye dönüşmemelidir. Açık kalan riskler, sonraki değerlendirmelerde izlenebilecek şekilde kaydedilmelidir.
- 01
Akışı çizin ve sınırları işaretleyin
Tarayıcıdan API'ye, veritabanına ve dış servislere uzanan yolu gösterin. Yönetim arayüzlerini ayrıca belirtin.
- 02
Kötüye kullanım senaryolarını yazın
Başka kullanıcıya ait kayda erişme veya işlem adımlarını atlama gibi uygulamaya özgü senaryolar üretin.
- 03
Senaryoyu kontrole bağlayın
Kayıt sahipliği, imza doğrulama veya işlem durumu denetimi gibi kontrollerin testini ve sorumlusunu tanımlayın.
Karşılaştırma
Genel beklentileri test edilebilir gereksinimlere çevirin
Kullanıcılar yalnızca yetkili oldukları verilere erişmeli.
Kullanıcı başka kuruma ait kayıt kimliğiyle istek gönderdiğinde veri dönmemeli ve işlem reddedilmelidir.
Loglar hassas veri içermemeli.
Parola, erişim belirteci ve gizli anahtarlar uygulama loglarına yazılmamalıdır.
Oturum kapatma işlemi güvenli olmalı.
Oturum kapatıldıktan sonra ilgili oturum belirteci korunan kaynaklara erişim sağlayamamalıdır.
Uygulama süreci
Gereksinimleri geliştirme ve dağıtım akışına bağlayın
Güvenlik gereksinimleri geliştirme görevlerine dönüştürülmelidir. Kimlik doğrulama, yetkilendirme, girdi doğrulama, şifreleme ve hata yönetimi için ortak uygulama kararları alınmalıdır. Benzer işlevlerin farklı biçimlerde uygulanması denetimi zorlaştırır. Kod inceleme ölçütleri ve tamamlanma koşulları da bu kararları yansıtmalıdır. Kontrolün belgede bulunması, yazılımda doğru uygulandığını tek başına göstermez. Otomatik taramalar yardımcıdır, ancak iş mantığı hatalarını tek başına ortaya koymaz. Bağımlılık taraması bilinen bir bileşen açığını gösterebilir; onaysız ödeme değişikliğini bulmak için senaryoya özgü test gerekir. Araç çıktıları, kod incelemesi ve tehdit modelinden türetilen testler birlikte değerlendirilmelidir. Üretim verisinin test ortamına taşınması ayrıca ele alınmalı; ihtiyaca göre maskeleme veya yapay test verisi planlanmalıdır. Ortam erişimleri, hesaplar ve entegrasyon anahtarları ayrı yönetilmelidir. Bir geliştiricinin test işlemi yapabilmesi, üretim verisini okuyabilmesi anlamına gelmemelidir. Bu ayrım hem erişim tasarımında hem dağıtım yapılandırmasında korunmalıdır. Bulguların önem derecesi de yalnız araç etiketine göre değil, veriye ve iş akışına etkisi dikkate alınarak değerlendirilmelidir.
- 01
Geliştirme görevlerini tanımlayın
Kontrolleri ilgili kullanıcı hikâyelerine ekleyin; kabul koşullarını kod incelemesi ve test görevleriyle ilişkilendirin.
- 02
Gizli bilgileri ve bağımlılıkları yönetin
Anahtarları kaynak kodda tutmayın. Erişim, yenileme, iptal ve bileşen güncellemeleri için sorumluluk atayın.
- 03
Dağıtım kararını görünür hale getirin
Yayını engelleyen bulguları, istisna onaylarını ve başarısız kontrollerde izlenecek yolu tanımlayın.
Kontrol listesi
Teslimatta hangi kanıtlar aranmalı?
Teslimatta yalnızca testlerin çalıştırıldığı bilgisi değil, hangi gereksinimlerin hangi sonuçlarla doğrulandığı aranmalıdır. Risk düzeyine göre ek güvenlik incelemeleri planlanabilir; ancak tek bir inceleme bütün gereksinimlerin karşılandığını göstermez. Kapsam, yöntem, bulgular ve yeniden test sonuçları birlikte değerlendirilmelidir. Gereksinim, test edilen sürüm ve sonuç ilişkilendirilerek kanıtların teslim edilen yazılıma ait olduğu gösterilmelidir. Kalan risklerin etkisi, geçici önlemi, sorumlusu ve takip koşulu açıkça kaydedilmelidir. Yayına alma kararı teknik ekibin tek başına üstlendiği belirsiz bir sorumluluk olmamalıdır. İş sahibi kabul edilen riskleri anlayarak karar vermeli; operasyon ekibi ise sistemi izlemek ve sorunlara müdahale etmek için gerekli bilgiye sahip olmalıdır. Önceki sürümde başarılı olan testler, değişen kuralları yeniden doğrulamaz. Eksik kanıt ile başarısız test aynı durum değildir; ikisi de ayrı kaydedilmelidir. Bir gereksinimin henüz doğrulanmadığı açıkça görülürse teslimat kararında bu belirsizlik değerlendirilebilir. Düzeltme sonrasında test kapsamının yalnız hatalı noktayı mı yoksa ilişkili işlevleri de mi kapsayacağı, değişikliğin etkisine göre belirlenmelidir. Sonuçlar karar kaydına işlenmelidir.
- ✓
Gereksinim ve test eşleşmesi
Yetki matrisi, veri koruma kararları ve kötüye kullanım senaryoları için sonuçları kontrol edin. Eksik doğrulamaları kaydedin.
- ✓
Bulguların kapanışı
Düzeltilen bulguların yeniden test edildiğini doğrulayın. Açık bulgular için sahiplik ve risk kararı arayın.
- ✓
Operasyon devri
Erişim iptali, anahtar yenileme, alarm takibi, olay müdahalesi ve yedekten dönüş sorumlularını netleştirin.
Hizmet değerlendirirken kapsam ve sorumlulukları netleştirin
Bir yazılım geliştirme teklifinde “güvenlik dahil” ifadesi tek başına yeterli değildir. Hazırlanacak analiz çıktıları, erişim modelini onaylayacak kişiler, uygulanacak testler ve bulguların ele alınma biçimi açıklanmalıdır. Altyapı, uygulama ve üçüncü taraf servisler arasındaki sorumluluk paylaşımı da görünür olmalıdır. Böylece teklifler yalnız fiyatla değil, üstlendikleri işler üzerinden karşılaştırılabilir.
Bikare'nin özel yazılım geliştirme hizmetini değerlendirirken iş akışlarınızı, veri türlerinizi, kullanıcı rollerinizi ve mevcut entegrasyonlarınızı keşif görüşmesine taşıyabilirsiniz. Güvenlik ve erişim yönetimi ihtiyaçlarını ayrıca ele almak, uygulama ile kurumsal erişim kararlarının birlikte değerlendirilmesine yardımcı olur. Sistemler arası veri alışverişi varsa API ve sistem entegrasyonları kapsamı da aynı gereksinimlerle ilişkilendirilmelidir.
Mevcut rol listesi, örnek veri akışı ve kritik iş senaryoları iyi bir başlangıçtır. Ardından teslimatlar, kapsam dışı işler ve kabul ölçütleri üzerinde mutabakat aranmalıdır. Hedef, riskin tamamen ortadan kalktığını söylemek değil; hangi risklerin nasıl yönetildiğini ve bunun nasıl doğrulandığını açıkça gösteren bir proje planı oluşturmaktır. Sorumlulukların yazılı olması, teslimat sonrasındaki bakım beklentilerini de netleştirir.
Keşfetmeye devam et
İlgili içerik ve hizmetler
Konuyu tamamlayan Bikare içeriklerine göz atın.
