.NET ile Güvenlik Alt Yapısı Oluşturma Yazı Dizisi - I

.NET ile Güvenlik Alt Yapısı Oluşturma Yazı Dizisi - I Güvenlik Bölümünde artık yeni bir yazı dizisine başlıyoruz. Bu yazı dizimizde daha önceki makalelerimizde bahsettiğimiz .NET Framework Güvenlik alt yapısını biraz daha derli toplu ve örnek kodlarıyla inceleyeceğiz. .NET Framework"ün, CLR (Common Language Runtime) "sinde üzerinde çalıştığı işletim sisteminin sınırlarından bağımsız olarak kendi özel güvenli çalışma modeli vardır. Şimdiye kadar var olan prensip temelli güvenliğe nazaran, CLR kullanılacak güvenlik politikasının çift taraflı olması için bizi zorlamaktadır. Yani o kodu kimin çalıştırdığı kadar o kodun nereden geldiği ve ne kadar güvenli olduğunu sorgulamaktadır. Bu modelin Kod Erişim Güvenliği (Code Access Security) olarak isimlendirildiğinden daha önceki makalelerimizde bahsetmiştik. Yaygınlaşan İnternet teknolojileri ile, İnternet üzerinden indirdiğimiz bir yazılım hangi kaynaktan geldiği ve ya güvenilir olup olmadığının denetlenmesi zorunlu bir hale gelmiştir.CLR kendi güvenli çalışma modelini bir sunucuya ihtiyaç duymadan gerçekleştirmiştir. Bununla beraber Windows® 98 gibi gömülü bir güvenlik sistemi olmayan işletim sistemlerine bir güvenlik alt yapısı getirmiştir. Bu bizi dinamik olarak oluşturulan sistemlerde daha bileşen merkezli bir güvenlik modeli geliştirmeye zorlamaktadır. CLR Nasıl Çalışır ?CLR hem managed hem de unmanaged kodları çalıştırmaktadır. Yönetilen kodlar(managed) CLR"nin kontrolü altında olduğundan, bellek yönetimi, JIT(Just In Time) -Çalışma zamanında derlenme, güvenlik politikası sistemi ve doğrulama gibi CLR tarafından sağlanan tüm servislere de erişebilmektedirler. Yönetilmeyen (Unmanaged) kodlar, belirli bir ortam ve donanım üzerinde çalışacak şekilde derlendiklerinden, CLR"nin sağladığı bu imkanlardan doğrudan yararlanamazlar. Bununla beraber, uygulamanın geliştirildiği derleyiciler yönetilen(managed) kod gönderirlerse, derleyicinin çıktısı Microsoft Intermediate Language(MSIL)- ara dil olarak temsil edilmiş olur. MSIL yığıt mimarisi üzerine çalışan sanal bir makine için tasarlanmış nesneye dayalı bir assembly olarak tanımlanmaktadır. MSIL nesneye dayalı programlama yaklaşımını destekleyen bir nesneye dayalı assembly dilidir. Örnek vermek gerekirse, virtual metotları çağırmak için "callvirt" komutu ve dinamik nesne oluşturabilmek için de "newobj" komutu vardır. Sanal bir makine olduğu için herhangi bir donanıma ya da platforma bağımlı da değildir. Bu da çalıştığı sistem hakkında hiç bir kabullenme yapmamış olduğunu gösterir. MSIL yığıt tabanlı olduğundan, esasen bir yığıta değerleri atıp çekerek ve metotları çağırarak çalışır. MSIL, çalıştırılmadan önce tipik olarak native kod olarak çalışma zamanında derlenir. Not: Native Kod: Belirli bir işlemciye göre derlenmiş makine kodudur. Doğrulama(Verification) CLR"de iki çeşit doğrulama vardır. MSIL doğrulanır ve assembly meta verisi (metadata - veriyle ilgili veri) onaylanır. CLR"deki tüm veri tipleri gerçeklenmesi gerekenleri bir kontrat gibi tanımlar, ve bu bilgi MSIL"in içinde meta verisi olarak yönetilen PE/COFF (Portable Executable/Common Object File Format - Portatif Çalıştırabilir/Genel Nesne Dosya Biçimi) dosyada kalıcı olarak saklanır. Örneğin, geliştirdiğimiz bir sınıf herhangi bir sınıf ya da arayüzden türüyorsa, türetildiği arayüz ve/veya sınıfa ait metotlara sahip olmak zorundadır. Bu bir kontrattır. Aynı şekilde bir kontrat erişilebilirlik olarak da olabilir. Örneğin public olarak tanımlanmamış metotların ve/veya özelliklerin assemblyde görünüp görünmemesini sağlanır. Doğrulama .NET Framework Güvenlik Sisteminin temel yapı taşıdır, şu an için doğrulama sadece yönetilen (managed) kodlarda yapılabilmektedir. Yönetilmeyen(unmanaged) kodlar, CLR tarafından doğrulanamadığı için tamamen güvenilir olarak çalıştırılmaktadır. MSIL doğrulamasının daha iyi anlayabilmek için, MSIL"in nasıl sınıflandırıldığını anlamamız gerekmektedir. MSIL aşağıdaki gibi sınıflandırılmıştır; geçersiz(invalid): JIT ile çalışma zamanında derlendiğinde derleyicinin native kodunu üretemediği MSIL"dir. Örneğin hatalı bir işlem koduna sahip bir MSIL kodu, native koda dönüştürülemez. Başka bir örnek vermek gerekirse bir işlem kodunun adresi yerine bir operand"ın adresine göre "jump" komutu olan bir MSIL kodu native koda çevirelemez. geçerli(valid): MSIL söz dizimi ve dilin diğer kurallarına uyan MSIL kodudur, sorunsuz olarak native koda çevrilebilir. güvenli tip(type safe): sadece kontratında "public" olarak herkese açılmış veri tipleri ile çalışan MSIL kodudur. Kontratta "private" olarak tanımlanmış özellik ve metotlara erişim non type-safe(güvenilir olmayan tip) olarak tanımlanır. doğrulanabilir(verifiable): Bir doğrulama algoritmasıyla type-safe (güvenli tip) olduğu kanıtlanabilen MSIL kodudur. Doğrulama algoritması çok kararlıdır; yani, her type-safe(güvenilir tip)  olan MSIL kodu doğrulanamayabilir. Bir MSIL kodunun doğrulabilir olması için hem geçerli olması hem de güvenilir tipte olması gerekir. MSIL doğrulaması sırasında sadece geçerlilik ve güvenilir tip kontrolü yapmamaktadır. Bunlara ek olarak nesnelerin doğru olarak ilk değerlerinin atanıp atanmadığının, yığıt taşması(stack overflow)/aşağı taşması(stack underflow) varlığının, istisna yakalama kurallarına uyulup uyulmadığının kontrolü de yapılmaktadır. Diskten yüklenen bir kodun doğrulanması işlemi JIT derleyecisinin işinin bir parçasıdır, JIT derleyecisininde ara ara yapılır. Doğrulama ve JIT derlemesi iki ayrı süreçte yapılmaz. Eğer doğrulama sırasında doğrulamadan geçemeyen herhangi bir MSIL koduna rastlanırsa, güvenlik sistemi doğrulamayı atlayabilecek kadar koda güvenilip güvenilemeyeceğinin denetimini yapar. Bu demektir ki MSIL kodu, doğrulamadan hataları göz ardı edecek kadar güvenilir bir kod ise kod native koda dönüştürülür. Tüm bunlara ek olarak yüklenen assembly"nin meta verisi(veri hakkında bilgi) de doğrulanmaktadır. Bir assembly"nin meta verisi 3 ayrı zamanda doğrulanabilir; GAC(Global Assembly Cache)" a yüklendiğinde, Download Cache" e yüklendiğinde, GAC"a yüklenmeyecekse diskten okunduğunda Meta verisi doğrulanması sırasında bellek aşımı gibi özel hatalar da denetlenmektedir.Not: GAC: herhangi bir program tarafından kullanılacak olan assembly"lerin yüklendikleri ortak merkezcil bir önbellektir.Download Cache: herhangi bir dış kaynaktan, genellikle İnternetten elde edilmiş kodların çalıştırılmadan önce yüklendikleri önbellektir. Herhangi bir İnternet sunucusundaki bir web servisini kullandığımız zaman, ilgili kodlar Download Cache"e yüklenir.Son SözBu yazı dizimizde çokça kullanılacak olan terimlere ve CLR"nin nasıl çalıştığına değindik. Ayrıca daha sonra çokça geçecek bir terim olan doğrulama"yı detaylı olarak inceledik. Bu yazı dizimizde sırasıyla aşağıdaki makalelere yer vereceğiz: Bileşenler ve Güvenlik Kanıt (Evidence) Güvenlik Politikaları - I Güvenlik Politikaları - II İzin (Permission) Yığıt Yürüyüşü (StackWalk), Rol Tabanlı Güvenlik (Role-based Security)  Zorlama(Enforcement) - I Zorlama(Enforcement)- II Bu yazı dizimizin bir sonraki makalesş olan "Bileşenler ve Güvenlik" adlı makalemizde görüşünceye kadar güvende kalın.. Referanslar[1] MSDN, Introduction to Security In Windows Forms[2] http://msdn.microsoft.com/net/ECMA/ Yazar : Yunus Emre ALPÖZENe-Posta : yunus.alpozen et msakademik.net

Döküman Arama

Başlık :

Kapat