Uygulama güvenliği, Bilgi teknolojilerinde güvenlik mimarlarının yeterince odaklanmadığı bir alandır. Uygulama katmanı, güvenlik açıklarının büyük çoğunluğunun bulunduğu yerdir ve güvenlik açıklarının azaltılması çalışmalarında en fazla sızma testi yapılan alandır. Bununla birlikte, Web Uygulama Güvenlik Duvarları (WAF) gibi harici cihazlardan ziyade güvenlik mimarisi açısından uygulama geliştirmeye yönelik araçlara ve bileşenlere odaklanmanız gerekir. WAF’lar mevcut güvenlik açıklarıyla başa çıkmak için harika bir seçimdir, fakat güvenlik açıklarını ortadan kaldırmak için hiçbir şey yapmazlar.
RSA’nın (Rivest–Shamir–Adleman) uygulama güvenliği bölümü, Güvenli Geliştirme Yaşam Döngüsü (SDLC) olarak adlandırılan konuya odaklanmıştır. Güvenliği, Yazılım Geliştirme Yaşam Döngüsü’ne (SDL) entegre etme işlemine SDLC diyoruz. Bu iki kısaltma çok benzer ve sonuç olarak birçok insan iki yaşam döngüsünü birbirine karıştırmaktadır. SDLC, güvenliği SDL’nin her aşamasına entegre etme girişimidir, bu yöntem sayesinde uygulamaları ve kod bloklarını yeniden yazma maliyetini azaltabilirsiniz.
Uygulama geliştirme işlemi sırasında ortaya çıkan güvenlik açıkları, belirli uygulama hatası türlerinden oluşmaktadır ve bu hataları arayan kalite kontrolleri ile azaltabilirsiniz. Kalite kontrolleri yapılmazsa, içinde bir hata bulunan kodu düzeltme maliyetleri katlanarak artar ve yeniden uygulama geliştirme sürecine geri dönersiniz. Aşağıdaki grafikte, bir yazım hatasının giderilme maliyetinin geliştirme sürecine ne kadar devam edeceği gösterilmektedir. Çoğu hatalı tasarım ve kodlama aşamalarında ortaya çıkar, ancak uygulama üretim için hazır oluncaya kadar bulunmaz. Bu nedenle, hatayı düzeltmek için maliyetleriniz artar, çünkü kodu yeniden yazmak için tasarım ve kod aşamalarına geri dönmeniz gerekir.

Grafik Referansı : Applied Software Measurement, Capers Jones, 1996

Bir güvenli yazılım mimarı, bu durumu iyileştirmek amacıyla yapabileceği birkaç güvenlik önlemleri ve kontrol noktaları vardır. Bu sayede söz verdiğiniz proje teslim tarihlerinde gecikme olmaz ve zamanında yazılım projesini tamamlayabilirsiniz. Her aşamada, uygulama güvenliğinde genel iyileşme sağlamak için kullanabileceğiniz yöntemleri aşağıda adım adım sizlerle paylaşıyorum:

  • 1. Gereksinimler Toplama Aşaması: Çoğu proje, gereksinimler düzgün bir şekilde toplanmadığı için başarısız olur. Proje paydaşlarınızla görüştüğünüzde ve onlara güvenlik gereksinimlerinin ne olduğunu sorduğunuzda, muhtemelen güvenlik konusunda sizlere bazı basit şeyler söyleyeceklerdir. Gereksinimleri doğru bir şekilde topladığınızdan emin olmalısınız. Bu aşamayı düzgün yaparsanız, yazılım geliştirme aşamasında daha büyük bir başarı derecesine sahip olacaksınız.
  • 2. Tasarım Aşaması: Tasarım aşaması, uygulama güvenliği mimarlarının en fazla etkiye sahip olabileceği yerdir. Yapmak isteyeceğiniz şey, güvenliğin doğrudan çözüme dahil edilmesini sağlamak için Uygulama Mimarlarınıza aşağıda paylaştığım adımlarda bir yol izlemesinde yardımcı olmalısınız.
    • İlk olarak, kullanılacak olan yazılım diline bağlı olarak kullanılmasını beklediğiniz uygun tasarım modellerinin bir kontrol listesine sahip olunması gerekmektedir. Uygulama dillerinde uzman değilseniz, önceden oluşturulmuş bir kontrol listesi bulmalısınız ve tasarım aşamasında bu listeden yararlanmalısınız.
    • İyi ve kullanılabilir olduğunu bildiğiniz bir dizi tasarım kuralına ve paternine sahip olmalısınız. Örneğin, kavramsal düzeydeki mimarinin farklı güvenlik bölgeleri arasında iletişim kurmayı amaçladığını biliyorsanız, iletişimin yüksek güvenlikli bölgeden başlatılması ve alt güvenlik bölgesine akması gerektiğini belirten bir tasarım kuralına sahip olmalısınız. Asla düşük güvenlikli bölgelerin iletişimi başlatmasına izin vermemelisiniz.
    • Son olarak, Tehdit Modelleme araçlarını kullanmalısınız. Örnek olarak Microsoft bu konuda çok iyidir ve .NET paketine odaklanmış Tehdit Modelleme aracına sahiptir. Tehdit Modelleme araçları toplanan gereksinimlere bakacak ve daha sonra uygulamanın göreceği tehditler ile ilgili önerilen stratejiler sağlayacaktır.
  • 3. Derleme Aşaması: Oluşturduğunuzda, genellikle üç tür uygulama varlığından söz edebiliriz: Kuruluşunuz için özel olarak oluşturulmuş özel uygulamalar, satın alınan uygulamalar ve sonradan uyarlanan Hibrit Uygulamalar (kuruluşunuzun kullanımı için özelleştirilmiş). Bu aşamada güvenlik açıklarının oluşmamasını sağlamak için aşağıda paylaştığım adımlarda bir yol izleyebilirsiniz:
    • Standartlaştırılmış geliştirici kütüphaneleri: İnsanlar doğası gereği genellikle tembel bir davranış sergiler ve genellikle yazılım geliştiricileri için de bu durum farklı değildir. Kendi kodlarını yazmak yerine, genellikle internetten bir yerden geliştirme kitaplıklarını indireceklerdir. Sonuç olarak, bu kod kütüphanelerinde bulunan güvenlik açıklarını devralırsınız. Başkasının kusurlarıyla uğraşmak zorunda kalmamak için güvenli, onaylanmış ve standartlaştırılmış geliştirici kütüphanesini kullanmanızı tavsiye ediyorum.
    • En iyi kodlama uygulamalarını takip etmek: Yazılım geliştiricilerin onaylanmış kodlama uygulamalarına sahip olmalı ve yazılım geliştiricilerin ne yapacağını ve ne yapmamalarını bilmesi için kontrol listelerinden yararlanması gerekmektedir.
    • Kod incelemeleri: Kalite Güvence ekibi tarafından veya tecrübeli yazılım geliştiricilerinin oluşturduğu birim tarafından kodların incelenmesi gerekmektedir. Kod incelemelerini yapan kişilerin neyi arayacaklarını bildiğinden emin olması gerekmektedir.
    • Hizmet odaklı mimari: Muhtemelen son on yıldaki en büyük trendlerden biri Hizmet Odaklı Mimarilere veya SOA’ya geçiş olmuştur. Bu, uygulamalar arasındaki arabirimlerin standartlaştırılmasına izin verir ve sonuç olarak, ilk arabirimde daha fazla zaman harcayabilir ve daha sonra bu arabirimin her kullanımında harcadığınız zamanı azaltabilirsiniz. SOA, uygulama geliştirmede standartlaştırmanın kullanılması nedeniyle Enterprise Services Bus (ESB) kullanımını temeline dayanmaktadır.
    • Kurumsal hizmet veri yolu: ESB, veri yolu kullanan ancak birden çok uygulamanın bağlanmasını sağlayan bir kavramdır. Her uygulama ile yönetilmesi gereken arabirim sayısının azaltılmasına ve yeni uygulamaların dağıtım hızının artırılmasına olanak tanır. Güvenli bir mimaride, kesinlikle bir ESB kullanımını teşvik edilmesi gerekmektedir, çünkü şifreleme kullanımı, kimlik doğrulama / yetkilendirme mekanizmalarının merkezileştirilmesi ve uygulama iletişim akışlarının kontrolünü içeren onaylı güvenlik mimarilerinin kullanılmasını sağlar. Ayrıca hangi uygulamaların diğer uygulamalarla konuşabileceğini söyleyerek kurallar uygulanabilir.
  • 4. Test Aşaması: Test aşaması, herhangi bir hata olup olmadığını belirlemek için Unit kodunun veya entegre kodun test edildiği yerdir. Bu, uygulama koduna güvenlik testinin uygulanması gereken en ideal aşamadır. Bu aşamada göz önünde bulundurmanız gereken dört tür güvenlik testi vardır:
    • Statik kod incelemeleri: Whitebox testi olarak da adlandırılır, statik kod incelemesi derlenmeden önce kodun test edilmesidir. Bu, test aracının kodu gerçekten okumasına ve uygun olmayan kod uygulamalarını veya güvenlik açıklarını aramasına olanak tanır. Ancak, kullandığınız araçların tüm güvenlik hatalarını yakalamasını beklemeyin. Whitebox test araçları, kusurların sadece% 10’unu yakaladıkları günlerden baya bir yol kat etti, fakat henüz% 100 başarıya daha ulaşmamışlardır.
    • Dinamik kod incelemeleri: Blackbox testi olarak da adlandırılan dinamik kod incelemeleri, derlendikten sonra kodun test edilmesidir. Bu tür testler, altta yatan altyapı yapılandırmalarından etkilenmeden uygulamanın davranışını analiz eder.
    • Güvenlik Açığı Değerlendirmesi: Güvenlik Açığı Değerlendirmesi genellikle altyapı yapılandırmasına bakmak içindir. Bazı araçlar uygulamanın kendisinde hata arar, ancak bu araçlar genellikle kodlama davranışına bakmak yerine bilinen hataları arar.
    • Fuzzing: Fuzzing, bir uygulamanın girişlerine baktığınız yerleri test ediyor ve sonuçların ne olduğunu görmek için bu girişlere olası her türlü farklı bilgiyi koyuyor. Fuzzing zaman alır ve pahalı bir test aşamasıdır, ancak günün sonunda buna değer, çünkü fuzzing bilinen kusurlardan ziyade beklenmedik davranışlar aramasıyla güvenlik açısından bir farklılık katar.
  • 5. Üretim aşaması (Production): Çoğu insan Üretim aşamasını düşünmez, çünkü uygulama geliştirmenin aktif olarak yapıldığı bir alan olarak görülmez. Ancak bu genellikle uygun olmayan Kalite Kontrol ve Değişim Yönetimi uygulamalarını yakalayabileceğiniz aşamadır. Üretime hazır onaylanmış bir uygulamanız olması, birinin değişiklik yönetiminden geçmeden uygulamayı değiştirmeyeceği anlamına gelmez. Bu ince ayarlar güvenlik açıklarına neden olabilir. Bu aşamada, Kod İmzalama (onaylanmış bir uygulamanın hash’ini alarak) yapmak istersiniz, böylece uygulama üretildikten sonra düzenli olarak kontroller yapabilirsiniz. Uygulamaları periyodik olarak kontrol ettiğinizde, bir hash oluşturun ve ardından üretim öncesi hash değerine göre kontrol edin. Hash değiştiyse, bu sayede birinin değişiklik yönetiminden geçmeden uygulamayı değiştirdiğini bilebilirsiniz.