Bu makalenin yazılma amacı web uygulamalarınızda korunması gereken, aynı zamanda kolayca değiştirmeniz gereken durumlarda kolayca müdahale edebileceğiniz verilerin nereye yazılacağı konusunda Best Practicelerle sizi tanıştırmaktır. Öncelikle belirtmem gerekiyor ki bu makaleyi yazarken "Best practices for deploying passwords and other sensitive data to ASP.NET and Azure App Service" makalesinden çok yararlandım. İngilizceniz çok kötü değilse bu makaleye de bir göz atmanızı tavsiye ederim. Zira ben bu makalede okuduklarımı ve iş tecrübemi de katarak bu yazıyı yazıyorum. Burada makaleyi Asp.net bazından anlatıyorum. Ama kullandığınız programlama dilinden bağımsız bir makale olduğunu söylemek zorundayım. Çünkü bu makale daha çok doğru stratejiler üzerine kurulmuştur. Umarım burada okuduklarınız iş hayatınızda size çok yardımcı olacaktır...
Öncelikle yukarıda anlattığım makalenin de başlangıcında yer alan bir cümleyle başlayacağım. Önemli olan nokta şifrelerinizi, korunması gereken diğer hassas verilerinizi asla kod içerisinde barındırmayın ve korunması gereken verileriniz varsa bu verileri development ve test ortamını ayrı tutarak devam edin.
Konuya bu cümleyle başlamamın çok önemli nedenleri var. Aslında bu nedeni anlatmak için bir örneği kullanacağım. Örneğim de şöyle...
Diyelim ki web uygulamanızda şifresini değiştiren kullanıcıların telefonuna bir onay mesajı gönderiyorsunuz. Bu mesajı göndermek için başka bir firmadan servis aldınız. Bu servisi kullanmak için url adresi, kullanıcı adı, şifresi ve başka verileriniz var. Ama siz bu verilerin hassas veriler olduğunu düşünüyorsunuz ve bu yüzden de bu verileri kod içerisinde bir yere yazmaya karar verdiniz. Kod içerisinde bir değişkene değerleri yazdınız ve kullandınız. Diyelim ki sms hizmeti aldığınız firma iflas etti ve artık size mesaj hizmeti veremiyor. Bu durumda başka bir firmayla anlaşıp aynı hizmeti alacaksınız ama tekrar kodu da derlemeniz gerekir. Çünkü siz bu verileri kod içerisine yazmıştınız. Eğer bundan geç haberiniz olursa belki de sisteminiz uzunca bir süre hatalı olarak çalışmaya devam eder. Ve acil mudahale gerek durumlarda developerlarınız da ortada yoksa çok büyük sıkıntılara girebilirsiniz...
Anlattığım örnek basit bir örnek belki, ama düşünüyorum ki bu örnekte sonra sizin aklınıza daha karamsar senaryolar da gelmiştir.. Ama bu makalenin de temel amacı zaten bu senaryolardan kendimizi mümkün olduğu kadar uzak tutmak için stratejiler geliştirmektir...
Bu konu ile bağlantılı olduğu için açıklamakta fayda gördüğüm bir diğer önemli nokta daha var. Aslında sorulması gereken en önemli soru belki de neden kritik verileri kod içerisinde tutarız sorusudur. Örneğin .NET programlama dilinde bir yazılım geliştiriyorsak bu yazılım reverse engineering ile kodları elde etmek sadece uygulama boyutuna bağlı. Bu java için de geçerli diğer programlama dillerinin tümü için geçerli. Önemli olan saldırganlar için koda erişimi doğru engelleyebilmektir. Koda eriştikten sonra daha doğrusu fiziksel olarak koda ulaşabilen bir hacker için bu koddaki kritik verileri elde etmek çok basit bir işleme dönüşür. Yani özetle demeye çalıştığım şey config dosyası içerisinde saklamak yerine kod içerisine güvenli verileri gömmek sadece bu verileri elde etmek isteyen birinin koda erişimi, veya projenin derlenmiş haline erişimi olduğu taktirde sadece geç erişmesine neden olacaktır. Bunun yanında ise size yukarıda bahsettiğim senaryoların üstünde daha büyük sıkıntıların oluşmasına neden olabilir...
Sanırım bu makalenin en önemli noktası zaten yukarıda bahsettiğim neden verileri kod içerisinde tutmayı tercih ederiz konusuydu. Bunun üzerine yukarıda bahsettiğim makaleden türkçeye çevirmeden bir örnek daha vermek istiyorum. Biliyorsunuz ki web uygulamarının çoğunda ayarlar web.config içerisinde yer alır. Ama unutmamamız gereken konu ise web.config dosyasının da uygulamanın bir parçası olduğudur. Bu konu makalede de şu sözlerle açıklanmış. "The web.config file is source code, so these secrets should never be stored in that file. The web.config file is source code, so these secrets should never be stored in that file. " Bu kısımdan sonrası size kalmış bir şey. Ayarlarını dosyalar veya diğer config dosyları içerisinde tutabilirsiniz. Eminim ki kullandığınız programlama dilinin bu yapı için muhakkak ki bir desteği vardır. Makalemin bu kısmından itibaren ise .NET programlama dili için bu yapıyı destekleyen yöntemden bahsedeceğim.
Öncelikle kısa bilgi vermem gerekirse .NET config doyalarından verileri çekerken appsettings tagının içine bakar. Eğer verdiğiniz stringle eşleşen bir veri varsa bu veriyi geri döndürür. .NET tarafından sağlanan diğer bir özellik ise bu config dosyalarını parçalara bölmenizi sağlayan yapıdır. Önemli olan nokta sadece parçaladığınız kısmın appsettings taglarıyla başlamasını sağlamaktır. Bu konuyla alakalı detaylı örnek için makaleye bakmanızı tavsiye ederim. Makalede verilen örnekte de göreceğiniz gibi daha güvenlik gerektiren ayarlar başka ir config doyası içine alınmış ve bu dosya web.config doyasının içindeki appsettings tagı içinden file parametresi kullanılarak çağrılmıştır.
Bu makaledeki temel amacım konuya giriş yaparken de bahsettiğim gibi doğru ve best practice config dizaynına yoğunlaşmak olduğu için kod örneklerine çok girmek istemedim. Açıkçası bunun çok gerekli olduğunu da düşünmüyorum.
Son olarak konuyu özetlemek gerekirse aklınızda best practice config tasarımı ile ilgili tutmanız gereken 3 konu var. Bunlardan birincisi asla güvenli verilerini kod içerisinde tutmayın, web configin de program kodlarının bir parçası olduğunu bilin ve güvenli verileri burada saklamayın ve üçüncüsü ise production ürününüzle development ve test ortamını bir birinden ayrıştırın...
Umut ediyorum ki makalede anlattığım konular ve stratejiler faydalı olmuştur. Konuyla alakalı sorularınız olursa lütfen sormaktan çekinmeyin. En kısa sürede yanıtlamaya çalışacağım...
Öncelikle yukarıda anlattığım makalenin de başlangıcında yer alan bir cümleyle başlayacağım. Önemli olan nokta şifrelerinizi, korunması gereken diğer hassas verilerinizi asla kod içerisinde barındırmayın ve korunması gereken verileriniz varsa bu verileri development ve test ortamını ayrı tutarak devam edin.
Konuya bu cümleyle başlamamın çok önemli nedenleri var. Aslında bu nedeni anlatmak için bir örneği kullanacağım. Örneğim de şöyle...
Diyelim ki web uygulamanızda şifresini değiştiren kullanıcıların telefonuna bir onay mesajı gönderiyorsunuz. Bu mesajı göndermek için başka bir firmadan servis aldınız. Bu servisi kullanmak için url adresi, kullanıcı adı, şifresi ve başka verileriniz var. Ama siz bu verilerin hassas veriler olduğunu düşünüyorsunuz ve bu yüzden de bu verileri kod içerisinde bir yere yazmaya karar verdiniz. Kod içerisinde bir değişkene değerleri yazdınız ve kullandınız. Diyelim ki sms hizmeti aldığınız firma iflas etti ve artık size mesaj hizmeti veremiyor. Bu durumda başka bir firmayla anlaşıp aynı hizmeti alacaksınız ama tekrar kodu da derlemeniz gerekir. Çünkü siz bu verileri kod içerisine yazmıştınız. Eğer bundan geç haberiniz olursa belki de sisteminiz uzunca bir süre hatalı olarak çalışmaya devam eder. Ve acil mudahale gerek durumlarda developerlarınız da ortada yoksa çok büyük sıkıntılara girebilirsiniz...
Anlattığım örnek basit bir örnek belki, ama düşünüyorum ki bu örnekte sonra sizin aklınıza daha karamsar senaryolar da gelmiştir.. Ama bu makalenin de temel amacı zaten bu senaryolardan kendimizi mümkün olduğu kadar uzak tutmak için stratejiler geliştirmektir...
Bu konu ile bağlantılı olduğu için açıklamakta fayda gördüğüm bir diğer önemli nokta daha var. Aslında sorulması gereken en önemli soru belki de neden kritik verileri kod içerisinde tutarız sorusudur. Örneğin .NET programlama dilinde bir yazılım geliştiriyorsak bu yazılım reverse engineering ile kodları elde etmek sadece uygulama boyutuna bağlı. Bu java için de geçerli diğer programlama dillerinin tümü için geçerli. Önemli olan saldırganlar için koda erişimi doğru engelleyebilmektir. Koda eriştikten sonra daha doğrusu fiziksel olarak koda ulaşabilen bir hacker için bu koddaki kritik verileri elde etmek çok basit bir işleme dönüşür. Yani özetle demeye çalıştığım şey config dosyası içerisinde saklamak yerine kod içerisine güvenli verileri gömmek sadece bu verileri elde etmek isteyen birinin koda erişimi, veya projenin derlenmiş haline erişimi olduğu taktirde sadece geç erişmesine neden olacaktır. Bunun yanında ise size yukarıda bahsettiğim senaryoların üstünde daha büyük sıkıntıların oluşmasına neden olabilir...
Sanırım bu makalenin en önemli noktası zaten yukarıda bahsettiğim neden verileri kod içerisinde tutmayı tercih ederiz konusuydu. Bunun üzerine yukarıda bahsettiğim makaleden türkçeye çevirmeden bir örnek daha vermek istiyorum. Biliyorsunuz ki web uygulamarının çoğunda ayarlar web.config içerisinde yer alır. Ama unutmamamız gereken konu ise web.config dosyasının da uygulamanın bir parçası olduğudur. Bu konu makalede de şu sözlerle açıklanmış. "The web.config file is source code, so these secrets should never be stored in that file. The web.config file is source code, so these secrets should never be stored in that file. " Bu kısımdan sonrası size kalmış bir şey. Ayarlarını dosyalar veya diğer config dosyları içerisinde tutabilirsiniz. Eminim ki kullandığınız programlama dilinin bu yapı için muhakkak ki bir desteği vardır. Makalemin bu kısmından itibaren ise .NET programlama dili için bu yapıyı destekleyen yöntemden bahsedeceğim.
Öncelikle kısa bilgi vermem gerekirse .NET config doyalarından verileri çekerken appsettings tagının içine bakar. Eğer verdiğiniz stringle eşleşen bir veri varsa bu veriyi geri döndürür. .NET tarafından sağlanan diğer bir özellik ise bu config dosyalarını parçalara bölmenizi sağlayan yapıdır. Önemli olan nokta sadece parçaladığınız kısmın appsettings taglarıyla başlamasını sağlamaktır. Bu konuyla alakalı detaylı örnek için makaleye bakmanızı tavsiye ederim. Makalede verilen örnekte de göreceğiniz gibi daha güvenlik gerektiren ayarlar başka ir config doyası içine alınmış ve bu dosya web.config doyasının içindeki appsettings tagı içinden file parametresi kullanılarak çağrılmıştır.
Bu makaledeki temel amacım konuya giriş yaparken de bahsettiğim gibi doğru ve best practice config dizaynına yoğunlaşmak olduğu için kod örneklerine çok girmek istemedim. Açıkçası bunun çok gerekli olduğunu da düşünmüyorum.
Son olarak konuyu özetlemek gerekirse aklınızda best practice config tasarımı ile ilgili tutmanız gereken 3 konu var. Bunlardan birincisi asla güvenli verilerini kod içerisinde tutmayın, web configin de program kodlarının bir parçası olduğunu bilin ve güvenli verileri burada saklamayın ve üçüncüsü ise production ürününüzle development ve test ortamını bir birinden ayrıştırın...
Umut ediyorum ki makalede anlattığım konular ve stratejiler faydalı olmuştur. Konuyla alakalı sorularınız olursa lütfen sormaktan çekinmeyin. En kısa sürede yanıtlamaya çalışacağım...
Yorumlar
Yorum Gönder