WCF Güvenlik Kılavuzu – 2 (Denetim ve Log’lama)
"WCF Güvenlik Kılavuzu" ana başlığı altında döktürmeye devam ediyoruz. İlk çeviri yazımızda "Tasarım Hususları"nı işlemiştik. Bu yazıyla WCF servislerinde denetimi ve log'lamayı "güvenlik" paradigmasıyla ele alacağız. Tekrar hatırlatmakta faide var ki bu yazı serisi, Patterns&Practices ekibinin "WCF 3.5 Security Guidelines" belgesi esas alınarak hazırlanıyor.
Denetleme ve Log'lama
Denetleme ve log'lama "sürekli güvenlik" için iki ayrı vazgeçilmez unsur. İkisi de bir uygulamanın hayatı boyunca karşılaştığı durumlardan haberdar olmamızı sağlıyor. Görelim bakalım, neler yapmalıyız.
Servisinizi denetlemek için WCF Auditing özelliğini kullanın:
WCF servisinizin denetim özelliğini, güvenlikle ilgili başarı ve başarısızlık durumlarını log'lamak üzere yapılandırın. Log'lar tahmin edebileceğiniz gibi Event Log'a yazılacak. Bu log'lar size güvenlik ile ilgili istenmedik durumları yakalamanızı sağlar. Bakım için de veri oluşturur. Kod örneğini şuradan alabilirsiniz.
Denetimsel bir hataya hoşgörünüz yok ise SuppressAuditFailure özelliğini kapatın:
Bu özellik açık olursa ortaya çıkan herhangi bir denetimsel hata servisin çalışmasını durdurmaz. Özelliğin açık olması "denial of service" (DoS) ataklarını da göz önünde bulundurmanızı gerektirir.
Mesaj log'lamalayı kullanın:
WCF mesajlar üzerinden çalışıyor mâlum. Gidip gelen mesajları takip etmek için mesaj log'lamayı açın. Config'ten kolayca yapabiliyorsunuz. Ama dikkatli olun. Nedeni son maddede açıklanacak.
Log dosyalarını meraklılardan sakının:
Denetleme ve log dosyalarını Windows'un "Access Control List" ile koruyun ve bunlara erişimi kısıtlayın. Dosya dışında başka bir yere yazıyorsanız oranın erişim denetimini gözden geçirin. Mesela yazma müsadesini kendi uygulamanızın hesaplarına, tüm hakları yöneticilere ve okuma hakkınını da operatörlere vererek temiz bir iş yapın.
Bu tedbir, saldırganların izlerini kaybettirmelerini zorlaştırır.
Hassas bilgileri log'lamayın:
Hassas ve mühim kullanıcı ve uygulama bilgilerini log'lamayın. Çünkü bu bilgilerin gerçekte durduğu yerden daha farklı erişim yetkileri var log dosyalarında. Kredi kartlarının bulunduğu tabloya erişemeyen birisi bu log dosyalarına da erişememelidir. Yukarıdaki nasihatlere uyup her giden gelen mesajı içeriğine bakmadan gövdesiyle log'larsanız bu maddeyle katı bir çelişkiye düşebilirsiniz.
Log'lamaktan sakınmanız lâzım gelen bilgiler: kişileri kimliklendiren vergi no, kimlik no, kredi kartı no vs. bilgileri; uygulamaya dair tercihler, giriş bilgileri gibi kişisel hassasiyeti olan veriler ve veritabanı bağlantı cümlesi, servise ait hesap adı gibi uygulama bilgileri.
...
Patterns&Practices yukarıdaki maddede "tüm mesajları loglayın" nasihatiyle biraz çelişmiş. Zaten ilgili maddenin yorumlarında da bir şahıs bu çelişkiye kayıtsız kalamamış. Yetkili kişi de bu çelişkiyi özel log'lama yazarak çözün diyor. Buradan şu mesajı almamız gerekiyor: söyleyen her kim olursa olsun duyduğunuz, okuduğunuz sözleri etraflıca düşünmeden uygulamaya koymayın. Biri size "mesajları log'layın, süper olur, olan biteni görürsünüz" dediğinda cazip bir tavsiye hediye ediyormuş gibi görünebilir. Oysa işinizin ciddiyetine göre değişebilecek düzeyde bir güvenlik zaafiyetine kapı araladığınızı da söylemelidir aynı kişi. Söylemiyorsa ya eksik bilgilidir ya da kötü niyetlidir.
Kolay gelsin.
Sonraki bahis: Kullanıcı doğrulama
WCF Güvenlik Kılavuzu – 1 (Tasarım Hususları)
Windows Communication Foundation (WCF) uygulamaları geliştiriyorsanız "güvenlik" asla ihmal etmemeniz gereken bir boyut. Ancak WCF'nin henüz yeni bir altyapı oluşu (1.0 sürümünde) nedeniyle işin sahiplerinden nasihatler bekliyoruz.
Microsoft'un Patterns&Practices bölümünden bir grup hayatlarını sadece WCF güvenliğine adamışlar ve CodePlex'te konuşlanmış bu sahife ile çeşitli "yol yordam" tavsiyeleri yazıyorlar. Ekibin ilgili projedeki "WCF Security Guidance" başlıklı kaynak belgesini doğrudan değil ama katkılar yaparak parça parça tercüme etmeye çalıştık. Faydalı olması dileğiyle.
Özgün Belgenin Müellifleri: J.D. Meier , Jason Taylor , Prashant Bansode , Carlos Farre, Madhu Sundararajan, Steve Gregersen
Aşağıda verilen nasihatler dizisi tekrar kullanılabilirlik adına olabildiğince soyutlanmıştır. Bu nedenle başlangıç noktası olarak dikkate almanız ve yolculuk esnasında kendi yoğurt yiyişinizi geliştirmeniz salık verilir.
Tasarım Hususları
Servis'i sarmalayıcı (wrapper) olarak tasarlayın:
"Wrapper" Türkçeye çevirince manasını kaybeden birçok yabancı kelimeden birisi. Bu madde ile anlatılmak istenen, servisinizin işi yapan değil, işi yaptıran bir konumda olması. Bu servis kodları içerisinde mantık gömmeyin, o mantığı farklı bileşenlere dağıtın; bakımınız kolaylaşsın, modülerliğiniz artsın demek istiyorlar.
ASMX'ten geliyorsanız var olan istemcileri desteklemek için basicHttpBinding kullanın:
Klasik web servisleri (.asmx) sunuyor idiyseniz, WCF'ye geçiş yapıp aynı servisleri basicHttpBinding binding'i ile sunabilirsiniz. Bu binding seçeneğinin özelliği güvenlik için hususi müdahaleler gerektirmesi. Varsayılan olarak açılmış bir güvenliği yok. Östelik WS* özelliklerini de desteklemiyor.
DCOM'dan geliyorsanız netTcpBinding kullanın:
.NET'ten .NET'e konuşan sistemler üzerindeyseniz ve daha önceden de COM+ yollarından geçtiyseniz tercihiniz varsayılan olarak güvenlik ve güvenilirlik özelliklerini destekleyen netTcpBinding binding'i olmalıdır. DCOM'dan geçiş yapıyorsanız işleyişin çok da benzer olmadığını göreceksiniz. Alışın, SOA farklı.
İstemcileriniz intranet içinde ise "transport security"yi tercih edin:
Servisinizin müşterilerinin bir intranet ortamında olduğundan eminseniz, netTcpBinding'i kullanıp "transport security"yi açmak hem performanslı hem de gayet güvenli bir yöntem olacaktır. Ayarınıza göre iletimdeki güvenliği Windows ağının güvenli iletişim mekanizmasına veya sertifikasyona emanet ediyorsunuz demektir bu.
Kullanıcı doğrulama seçeneklerinizi bilin:
Hangi binding için nasıl doğrulama seçenekleriniz olabileceğini bilmelisiniz. Ona göre binding'lerinizi de çeşitlersiniz. Meselâ "transport security"yi netTcpBinding ile kullanıyorsanız kullanıcı doğrulama için sadece Windows veya "sertifika" seçenekleriniz var. Yok ben kendi kullanıcı adım ile doğrulama yapıyorum diyorsanız buna uygun binding ve security tercihleri yapmalısınız. Seçenek listeniz şurada.
Binding (bağlama) seçeneklerinizi bilin:
Şimdiye kadar da söyledik, binding tercihiniz güvenlik ve güvenilirlik mevzularını etkileyecektir. İhtiyacınıza uyuşan bir binding (bağlama) mutlaka vardır. Şu listeyi inceleyebilirsiniz.
Microsoft dışı sistemlerle beraber çalışacaksanız basicHttpBinding veya wsHttpBinding kullanın:
Eğer Microsoft haricindeki sistemlerle konuşacaksanız tabî olarak HTTP ve HTTPS protokolünü kullanmanız gerekecektir. Bu protokolü de bahsettiğimiz binding'ler destekliyor.
Microsoft dışı istemcileriniz "WS* stack"ten anlıyorsa wsHttpBinding kullanın:
Microsoft dışı sistemleriniz WS* stack'i destekliyorsa, "text encoding" (metin kodlamayı) ve HTTP prokolünü destekleyen wsHttpBinding tek seçeneğiniz.
...
Sonraki Bahis: Denetim ve Log'lama
SOA Nedir Hoca?
Ülkemizde henüz rağbet görmese de hizmet temelli mimari yani SOA, önümüzdeki 5 senenin popüler temayülü olma yolunda. Tamam bu cümle güzel, akıcı, yasal. Ama SOA veya "hizmet"in ne olduğuna yabancı bir kişi için ne ifade eder?
İşbu söyleşide, soğuk yazılım geliştirme makalelerinde gördüğünüz SOA tasvirinden uzak şeyler bulacaksınız. En azından fakir öyle umud ediyor. Tevfik Allah'tan.
Derdimiz Nedir?
Efendim derdin tarifi biraz geniş.
Artık bilgisayar gani. Elinizdeki cep telefonu bile bilgisayar özellikleri taşıyor. Ve malesef "iletişim çağındayız." Kopuk bir çağ bu. (Bir sonraki çağı bekliyorum ben heyecanla.) Bu kadar nimet, yeni ihtiyaçlar doğuruyor ademoğlu için.
Bu iletişim imkanı bu kadar yaygınlaşmamışken, programcılar bileşen temelli mimariyle tekrar kullanılabilir kod parçaları meselesini çözmüşlerdi. Bir kere yazıp, elli yerde kullanabileceğiniz küçük birimler oluşturuyordunuz. (MS Örneği: COM)
İletişim çağı, bileşen temelli mimariyi de bozdu. Mühendisler, ya madem bileşenlerimiz var elimizde, bunları neden uzak makinelerde çalıştırmıyoruz, diye sorunca... Dağıtık bileşen mimarileri doğdu. Yine bir kere yazdınız ama bu sefer elli yere değil, tek yere koydunuz. Yine elli uygulama, sizin bileşeninizi kullandı. "Application Server" denen şeyler icat oldu. (MS Örneği: DCOM, COM+)
Sandınız ki dert bitti, herkes mutlu oldu. Hayır efendim. Biter mi? Bu sefer de platform çeşitliliği, evrensellik kaygısını ortaya çıkardı. Yazdığımız bileşen aynı cins platformlarda çalışıyor ama farklı bir cinsle karşılaştığımızde elimiz ayağımıza dolaşıyordu. Şu dağıtık bileşen midir nedir o mimarinin tekrar ele alınması gerekliydi.
İşte dert buydu. Dert budur. SOA denen felsefe de bu derdin çözümünü adreslemektedir.
Peki nasıl?
SOA Teorisi
SOA'dan bahsederken felsefe dedik az önce. Maksatlıydı o. Zira, SOA denen şey, bir ürün veya teknoloji olmamakla birlikte bir firmanın tasarrufu altında da değil.
SOA diyor ki, yapacağımız işler sınırları sârih (açık), (explicit boundary) bir hizmet paketi içerisinde dursun. Bu paketler akıllı (autonomus) olsun. Mukavelelerle (contract) haberleşsin, işlesin.
SOA sadece konsepti belirliyor, geri çekiliyor aslında.
Günümüzde SOA ile uyuşan bir çok uygulama görmekteyiz. Meselâ ülkemizde çılgın atan "Web 2.0" paradigması, o özündeki birlikteliği sağlamak için çevrim-içi hizmetlere dayanıyor. Nerede bir hizmet var ise orada SOA izi bulmak mümkündür.
Bildiğimiz Web Servisleri (XML Web Services) de SOA mimarisini uygulamanın ana yöntemlerinden birisi.
Çıkaracağımız ders şudur ki; SOA büyük büyük adamların kafa yorup ürettiği bir ilkeler topluluğu. Ne kadarını uygulayacağınız size kalmış. Hesap soran yok.
Teorisine daha detaylı inmek isteyenler için adres: http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf.
Kendi Kendine SOA
Eğer SOA'yı uyguladım diyorsanız ürününüzün aşağıdaki ilkeleri taşıyor olması lâzım:
- Tekrar tekrar kullanılabilirlik.
- Tanecikli yapı. (Hâni çikolata tanecikleri gibi. Ayrıştırılabilir.)
- Modülerlik. (Tak-çalıştır.)
- Bileşenli olma.
- Birbiriyle çalışabilirlik. (Interoperability.)
- Endüstriyel standartlara uygunluk.
Ayrıca sunduğunuz "hizmet"in:
- Kapsüllenmiş. (Salça gibi bir kapsülü olmalı yani.)
- Gevşek bağlı. (Bu çok önemli. X kişisi olmadan restorana gidememek kabul edilmiyor.)
- Kendi kendini tarifi etmiş. Kendini soyutlamış, izale etmiş. (Gülüyorum ama içim kan ağlıyor ilkesi.)
- Akıllı. (Kendi kararlarını kendi veren, aklı başında, özgür bir birey gibi.)
- Kaliteli. (Ucuz etin yahnisi de servisi de ucuz olur.)
- Keşfedilebilir, bulunabilir. (Sarı çizmeli Mehmet Ağa olmamalı yani.)
olması da gerekiyor.
Kolay SOA
Yukarıdaki ilkeleri uygulamaktan acizim diyorsanız hâzır SOA iskeletleri aramaya başlıyorsunuz. Microsoft da sesinizin yankısını dinleyenlerden. .NET 3.0'a koyduğu Windows Communication Foundation (WCF) iskeleti, yukarıdaki ilkelerle bir uygulama hizmeti oluşturmayı epey kolaylaştırıyor.
WCF, Web Servisleri'nin adını değişmişi diyebilirsiniz. Haksız da sayılmazsınız. Çünkü SOA'ya da aynı eleştiriler yöneltiliyor.
.NET perspektifinden bakıldığında, web servislerinin durduğu noktadan sıyrılmak gerekiyordu zaten. Hem Remoting, hem Web Servisleri, vs. WCF tüm dağıtık işleri birleştirip SOA ilkelerini dayatıyor bize. İyi de yapıyor hani. Artık uygulamanızın iş yapan kısımlarını bir "hizmet" olarak fikretmeye başlıyorsunuz. Ön yüz, yani kullanıcı son noktası, "hizmet"leri kullanan bir müşteri hükmünde kalıyor.
İlerisi...
SOA 2.0 veya Advanced SOA kavramları ortaya atılmış durumda. Mâlum SOA'nın şu hâlinde "olay" denen programlama yapısına yer verilmiyor. Bu gelişmiş sürümde SOA'ya olay güdümlü mimariyi de sokuyorlar. Bunu yapan Oracle aslında. Henüz yaygın kabul görmüş bir girişim değil.
SOA öksüz çocuk değil. Hızla ilerliyor ve kamu oyunda gördüğü kabul düzeyi artıyor. Lider yazılım firmaları da samimi olarak destekliyor. Microsoft desteklediği gibi Sun da destekliyor demek istiyoruz. Ortada kalmazsınız.
Bir müesseseye bağımlı olmaktansa evrensel ve açık standartlar düzleminde hareket etmek her zaman yeğdir. Bunu ActiveX bilgileri çöpe gidenler çok daha iyi anlarlar efendim.
Kalemin ucu bitmiş. Yeni bir kalemle, yeni bir söyleşide buluşmak üzere.
SOA ile.
WAS yordamıyla WCF Hosting
WAS nedir hocam?
Aslında arada bir "P" harfi noksan: Windows Process Activation Services. Windows 2008 ve Vista'nın bir iç bileşeni.
Ne işe yarıyor?
Yeni Web sunucumuz IIS 7'nin işlem etkinleştirme (process activation) mimarisini tamamlıyor. Bir sürü teknik dokuman okuyarak elde edeceğiniz bilgi şu ki, IIS uygulamaları artık sadece HTTP protokolünden değil de TCP, MSMQ ve Named Pipes gibi farklı protokoller ile de ayağa kalkabiliyor. Böylelikle Windows Communication Services (WCF) uygulamaları (yani servisler) bu saydığımız protokoller üzerinden IIS'in bir takım işlem yetenekleri ile çalışabiliyor.
Önceki durum, IIS-WCF işbirliğinde HTTP protokolüyle sınırlı olmaktı. Şimdi servis sunma işi daha doğru bir yere oturdu. Meselâ hem NetTcpBinding kullanıp performans kazanalım hem de IIS'in Application Pool nimetlerinden (recycling, health monitoring, rapid failure protection, vs.) sonuna kadar istifade edelim. İşin özü bu.
WAS Nerede?
Ararsanız bulamazsınız. Windows 2008 ve Vista'da sonradan açılan bir özellik olarak duruyor. Ancak bu isimde bir konsol veya ekran bulamayacaksınız kursanız bile. Çünkü kendisi bir arka plan teknolojisi. IIS üzerinde TCP Binding ile bir WCF uygulaması host ettiğiniz anda WAS kullanmışsınız da haberiniz yok demektir. O hâlde W3SVC'yi kapatabilirsiniz, çünkü web sunucuya ihtiyacınız yok.
Faydalı Okumalar
WAS ile bir servis çalıştırmaya kararlı iseniz sizi kimse tutmasın. Biz daha anlaşılırını yazana kadar şu okumalar isabetlidir:
WCF Burada Halkımız Nerede?
Dağıtık Uygulamalar...
Kim çevirdiyse dilimize, çok iyi yapmış. "Distributed" demeye dilimiz varmıyor artık. Her neyse. Bu tür uygulamalar yazmak için her üç yılda bir alternatifler sunuluyor önümüze. Microsoft'un en son ikramı ise, .NET 3.0 kutusundan çıkan Windows Communication Foundation.
Bu "foundation" ile ilgili yazıları, muhabbetleri muhtelif mecralardan takip etmişsinizdir zaten. Bizim merak ettiğimiz ise bu teknolojiyle boğuşanların varlığı. Hiç acaba ben mevcut dağıtık yapımı WCF ile yeniden gerçekleyeyim deyip kolları sıvayan oldu mu? Lütfen yerel düşünün. Kendi şehrinizden, İstanbul'dan ya da mahallenizden başlayın.
WCF acaba COM+ - Remoting - Web Services evrelerine bulaşmış yerli yazılım kuvvetlerimizin kaçında hayat bulmaya başladı?
Microsoft sunumları devirdi, bitirdi. Halkımızda bir kıpırtı, bir kımıltı filan göremiyoruz? Yoksa var da biz mi halkımıza duyarsızlaştık a dostlar?
WCF'nin süper bir şey olduğundan mı bu aşırı merakımız? Asla. Daha ilk sürümündeki bir yazılım ürünü için temkinli durmak elbette akıllıcadır. Ama bu onunla ilgili tecrübelerimizin oluşmayacağı anlamına da gelemez.
İmdi, WCF yatağını buldu akıyor. Dünya üzerinde, yazılım mimarları bu olaya odaklanmış kahvelerini yudumluyorlar. Sorduğunda da 5 sene ömür biçiyorlar bu abuk teknolojiye. Bebek doğdu, olgunlaşacak ve ölecek.
Bebeği kucağınıza alıp, onunla beraber insanoğlunun başımıza sardığı yeni bir mimari yaklaşımı öğrenmeye ve uygulamaya ne dersiniz? Yoksa uyguluyor musunuz?
Tecrübelerinizi kamu oyu ile paylaşabilirsiniz efendim. Evcil.net'in kapıları açık, bilgievcil.net.
WCF ile.
SOAP Nedir? Avantajları Nelerdir – I
Dağıtık, tek merkezli olmayan uygulamaların veya çeşitli noktalardaki nesnelerin,
kendi barındıkları platformla aynı veya farklı platformlardaki nesnelerle aynı dili
konuşması mevcut nesne iletişim arayüzlerinin (COM, CORBA, EJB
gibi) kullandığı transfer protokollerinin gerek uygulamayla bağdaşmaması, yani kullanılan
programlama diline veya işletim sistemine uyumsuzluğu, gerekse protokolun mevcut
diğer protokollerle olan uyumsuzluğundan dolayı hep sorun teşkil etmiştir ve ortak
standart bir protokole ulaşılamamıştır.