Aynı girişi kullanarak iki veritabanını bağlamak için 3. bir veritabanından geçmek daha mı güvenli?

Aşağıdaki kurulumlarımız var:

• Masaüstü yazılımı tarafından kullanılan özel verileri içeren çoklu üretim veritabanı
• Özel veritabanlarından bazı verilere ihtiyaç duyan genel bir web sitesi için bir web veritabanı
• Özel veritabanlarından veri çeken birkaç görünüm ve saklı yordam içeren bir aracı veritabanı

Şu anda web sitesi web veritabanında oturum açıyor ve web veritabanı, üretim veritabanlarında veri çekmek veya saklı yordamları yürütmek için ara veritabanına bağlanıyor. Tüm veritabanları aynı SQL örneğinde ve işlemin tamamı aynı kullanıcı hesabını kullanıyor.

Kullanıcı hesabının web veritabanına ve aracı veritabanına tam erişimi vardır, ancak özel veritabanının yalnızca belirli görünümlerine ve saklı yordamlarına erişebilir

Bu, genel veritabanının doğrudan özel veritabanlarına bağlanmasını sağlamaktan daha mı güvenli?

Tüm veritabanlarındaki verilere erişmek için aynı giriş kullanıldığından, ara veritabanı sadece işleri karmaşıklaştırmak için var gibi görünüyor ve zaten özel veritabanlarında ihtiyaç duyduğu görünümler / SP'ler ile sınırlı. Kaldırmayı umuyorum.

Burada bir şey atlıyor:

Tüm süreç aynı oturum açma kimlik bilgilerini kullanır

Sorun

Yani varsayımsal userX (ister Excel, ister IIS AppPool Identity kullanan bazı eşyalar olsun) bazı görünümleri ve kodları görebilir. Bu görünümlerin ve kodun hangi veritabanında olduğu önemli değildir, çünkü userX zaten 3 veritabanında kurulur.

Ancak, böyle zincirleme sahipliğini kaybedersiniz.

Diyelim ki WebDB.dbo.SomeProcçağrılar PrivateDB.dbo.SomeTable. UserX, her iki nesne için de izin gerektirir. Bu ise OneDB.WebGUI.SomeProckullanılarak OneDB.dbo.SomeTabledaha sonra sadece OneDB.WebGUI.SomeProcizinleri ihtiyaç duyar. Aynı sahibi olan başvurulan nesnelerin izinleri kontrol edilmez.

Not: Çapraz veritabanı sahipliği zincirine çok fazla bakmadım . Ben sadece düz eski "mülkiyet zincirleme" iyi biliyorum

Şimdi, yorumlara göre gerçekten birleştirilebilir 2 veritabanınız var. Başlangıçta ima edilen 3 değil. Bununla birlikte, ara madde ve ağ birleştirilebilir.

Diğer "özel" veritabanları birleştirilebilir, ancak bu ayrı bir sorun olacaktır. "Bir veritabanı veya daha fazlası" hakkında daha ayrıntılı bir tartışma için alt bağlantıya bakın

Çözüm?

Ek veritabanları yalnızca kod kapsayıcıysa, şemalar daha iyi bir fikirdir.

Bu, "Şema" kullanmanız gereken "Veritabanı" 'yı kullandığınız anlaşılıyor (SQL Server anlamında, MySQL anlamında değil). Bir WebGUI şeması, Yardımcı veya Ortak şema (Ara veritabanını değiştirmek için) ve Masaüstü şeması olurdu. Bu şekilde izinleri istemcilere göre ayırırsınız ve yalnızca bir veritabanınız olur

Bir veritabanı ile ("sahiplik zincirine" ek olarak) ayrıca dizinli görünümleri, SCHEMABINDING (her zaman kullanıyorum) ve ayrı veritabanları ile yapılamayacak şekilde düşünmeye başlayabilirsiniz.

Şemalar hakkında daha fazla bilgi için şu sorulara bakın:

• Şema tasarımı - en iyi uygulamalar?
• Şemaların aşırı kullanımı / doğru kullanımı?

Son olarak, "işlemsel bütünlük gerekli değildir" temelinde ayrı veritabanlarına sahip olmak için hiçbir neden görünmemektedir. Bunu açıklamak için şu soruya bakın: dbo olmayan bir şemanın yeni bir Veritabanı ile ne zaman kullanılacağına ilişkin karar kriterleri

Cevap, duruma bağlı. Özel veritabanına dış iç LAN'dan (veya yalnızca bir VPN üzerinden) erişilmezse, WebSite'nin kimlik bilgilerini kullanan birinin o özel DB Sunucusuna sınırlı erişimi olacağı (ve almak için daha fazla işi olacağı için), bu şema güvenliği ekler. dahili ağınıza girer - izinsiz girişleri keşfetmede ve deliği kapatmada kullanışlı olabilir).

Değilse, karmaşıklık dışında bir şey kattığını düşünmüyorum.

DÜZENLE:

Sorunuzu yanlış okuduğum anlaşılıyor, şimdi doğru anladım mı bakalım: IntermDb sadece PrivateDB'ye bağlanmak için boş bir veritabanı VEYA veri almak için PrivateDB'ye bağlanan kendi 'görünümleri / prosedürü olan bir DB ?

İlk durumda, WTF? Yırt. Birisi PrivateDB'ye profil erişimini daha tembel bir şekilde denetlemek istemediği sürece (ve WebApp geliştiricilerinin daha fazla çalışmasını sağlamak) değersizdir. SQL Profiler DB_ID kullanarak filtre ...

İkinci durumda, önceki cevabımı sürdürüyorum.

EDIT: "Ben hala aynı SQL örneğindeki 3 veritabanlarının tümü ve tüm 3 veritabanları için kullanılan giriş aynı olduğundan ve yalnızca erişebilirsiniz, çünkü özel db doğrudan genel db bağlamak daha güvenli görmüyorum msgstr "özel görünümlerde saklı yordamlar ve özel prosedürler".

Aracı araçlarını olması istilacı Kodunuzdaki kazmak zorunda olacağı biliyorum bir IntermDB varlığını - ve buna dair bir PrivateDB var bilmek kodunuzu kazmak zorunda.

PrivateDB'nizi kuruluşunuzun LAN / WAN'ının içindeki başka bir sunucuya koyarsanız (mümkünse), yöneticinin istila girişimini algılaması ve engellemesi için yeterli zaman verebilir. Eşanlamlıları kullanırsanız, bu hareket pürüzsüzdür çünkü sahip olduğunuz tüm kodları yeniden oluşturmak doğru yere gider.

Tüm kod PrivateDB verilerine erişmek için IntermDB geçmek zorunda olduğundan, hiçbir geliştirici denemek için cazip olacağını: Ayrıca diğer avantajlar elde baypas bunun - ve bu girişimi kolayca PrivateDb verilerinin talebinin DB_ID olarak SQL Server Profiler üzerinde lekeli olabilir WebAppDb olur.