Selam,
Kod: Tümünü seç
büyük sorun olmaz mı hocam. İşlerin çoğunu bizim gibi veritabanı tarafında yapanlar için büyük risk. Birisi DB'yi ele geçirmesi durumunda çok kolay yapıyı çözebilir + isterse mevcut programa 1-2 ayda bir arayüz yapıp piyasaya sürebilir
Tüm veritabanlarında bu sorun mevcut. SP ve trigger kodlarını şifreleseniz bile db yapısı herzaman ulaşılabilir durumda. Neden ? Console a erişen yetkili kullanıcı database lere her zaman ulaşabilir. Nedeni ise bir şekilde password u kaybolmuş bir db nin kurtarılması gerekliliğidir. Firebird de security db yi resetlersiniz, Oracle'da DBA grubuna bağlı bir user ile password olmaksızın bağlanır işinizi görürsünüz, SQL server da ise local auth. ile bağlanır istediğinizi kurcalarsınız (Eğer desteklemiyorsa girer registry ye bunu eklersiniz). Yeter ki db in kurulu olduğu makinayı kullanabilin. Bu bağlamda DB yapısını asla koruyamazsınız ve fakat SP ve Trigger kodlarını koruyabilirsiniz..
Kod: Tümünü seç
Birde şu varki eğer web sitesinde firebird kullanmak istiyorsanız ve adamın biri kalkıpda bunu sezer ve veri tabanının yolunu bulursa işte o gün yandınız demektir.
Çoğu asp sayfasına değişik post değerleri gönderip sayfanın hata vermesini sağlayıp hata metni içerisinden veri tabanı yolunu alıyorlardı.Veri tabanı yolunu bulduktan sonra dosyayı indirip bütün şifre vb. ele geçirmiş oluyorlardı.
Mazallah Firebird de böyle bişey olursa adamın dosyayıda indirmesine gerek kalmadan tüm herşeyi çocuk oyuncağı gibi değiştirebilir.Bu da hiç hoş olmaz.Sonra sayfaya yazar "hacked by felanca".Eline ne geçtiyse!.....
Eğer web server tarafından erişilebilen bir dizine db yi koyacak kadar safiyane davranıyorsanız, en kralından bir db bile olsa hiç şansınız olmaz. Pratik olduğu için insanlar access dosyalarını koydular başlangıçta , hatalarını farkedince dsn kullanarak aştılar sorunu. Eğer bir servis sağlayıcı db nizi web server dizini içinde biryere koyuyorsa hemen o isp yi terkedin, çok geç olmadan.
Kod: Tümünü seç
Firebird Veritabanının şifrelenememesindeki kastım.Veritabanına yazdığınız Stored procedureler ve Triggerler hepsi meydanda başka birisi alıp bu yazılan Sp ve triggerleri istediği gibi kullanabilir.Ve İstediği gibi değiştirebilir.Kolay gelsin.
Şayet kullanıcı sayısı kontrolü gibi sizin için önemli olan bir SP değilse, oluşacak hasar dolayısıyla zarar görecek olan yine kendisi olacaktır. En nihayetinde siz de kardeşim değiştirmeseydin kodları ne yapalım diyebilirsiniz.
.....
Verinin kendisini otomatik şifreleyemiyor, müşteri verilerimizin başka ellere geçmesinden endişe ediyoruz. Ya da iletişim protokolü yerleşik bir encryption sağlamıyor, birilerinin ağı izleyerek verilerimizi çalmasından endişe ediyoruz gibi şeyler söylenebilir. Fakat bu özellikler oracle a bile 10gR2 ile yeni geldi firebird de olmaması çok doğal.
Bir de "Çok büyük proje" adıyla anılan projeler enteresan. Büyük proje nedir sizce ? Çok kayıt, çok tablo, çok kullanıcı, ha gereksinimi, cluster desteği, poliform uygulama yapısı ya da nedir kriteriniz ..? Bunu da anlayamıyorum nedense, çok yuvarlak bir ifade zira.
Kolay gelsin,