Apakah lebih aman melalui database ke-3 untuk menghubungkan dua database menggunakan login yang sama?

Kami memiliki pengaturan berikut:

Database produksi berganda yang berisi data pribadi yang digunakan oleh perangkat lunak desktop
Database web untuk situs web publik yang memerlukan beberapa data dari database pribadi
Database perantara yang berisi beberapa tampilan dan prosedur tersimpan yang menarik data dari database pribadi

Saat ini situs web login ke database web, dan database web terhubung ke database perantara untuk menarik data atau menjalankan prosedur yang tersimpan pada database produksi. Semua database menggunakan instance SQL yang sama, dan seluruh proses menggunakan akun pengguna yang sama.

Akun pengguna memiliki akses penuh ke basis data web dan basis data perantara, tetapi hanya dapat mengakses tampilan spesifik dan prosedur tersimpan dan basis data pribadi

Apakah ini benar-benar lebih aman daripada hanya membuat database publik terhubung langsung ke yang pribadi?

Sepertinya database perantara hanya ada untuk mempersulit hal-hal karena login yang sama digunakan untuk mengakses data di semua database, dan itu sudah terbatas hanya pada pandangan / SP yang dibutuhkan dalam database pribadi. Saya berharap untuk menghapusnya.

database-design security

— Rachel
sumber

Anda memiliki perantara; mereka procs / pandangan di DB web. Selama perm Anda diatur dengan benar, basis data tambahan sepertinya adalah abstraksi yang tidak perlu tanpa implikasi keamanan sama sekali.

— Ben Brocka

@ BenBrocka Itulah yang saya pikirkan, tetapi saya ingin memeriksa ulang sebelum menghapusnya sepenuhnya

— Rachel

Jawaban:

Satu hal muncul di sini:

Seluruh proses menggunakan set kredensial masuk yang sama

Masalah

Jadi userX hipotetis (apakah beberapa meatsack menggunakan Excel, atau IIS AppPool Identity) dapat melihat beberapa tampilan dan kode. Tidak masalah apa basis data yang dilihat dan kode ini karena userX diatur dalam 3 database.

Namun, Anda kehilangan rantai kepemilikan seperti ini.

Katakanlah WebDB.dbo.SomeProcpanggilan PrivateDB.dbo.SomeTable. UserX membutuhkan izin pada kedua objek. Jika ini OneDB.WebGUI.SomeProcmenggunakan OneDB.dbo.SomeTablemaka hanya OneDB.WebGUI.SomeProcizin kebutuhan. Izin pada objek yang direferensikan dengan pemilik yang sama tidak dicentang.

Catatan: Saya belum melihat terlalu dalam pada chaining kepemilikan database silang . Saya hanya tahu "rantai kepemilikan" lama dengan baik

Sekarang, sesuai komentar Anda benar-benar memiliki 2 database yang dapat digabungkan. Bukan 3 yang awalnya tersirat. Namun, perantara dan web dapat digabungkan.

Basis data "pribadi" lainnya mungkin dapat digabungkan, tetapi itu akan menjadi masalah tersendiri. Lihat tautan bawah untuk diskusi yang lebih lengkap tentang "satu database atau banyak"

Larutan?

Jika database tambahan hanya merupakan wadah kode, maka skema adalah ide yang lebih baik.

Ini kedengarannya seperti Anda telah menggunakan "Database" di mana Anda harus menggunakan "Skema" (dalam arti SQL Server, bukan pengertian MySQL). Saya akan memiliki skema WebGUI, skema Helper atau Common (untuk menggantikan database Intermediate) dan skema Desktop. Dengan cara ini Anda memisahkan izin berdasarkan klien dan hanya memiliki satu basis data

Dengan satu basis data (selain "rantai kepemilikan") Anda juga dapat mulai mempertimbangkan tampilan yang diindeks, SCHEMABINDING (Saya selalu menggunakannya) dan sedemikian rupa sehingga tidak dapat dilakukan dengan basis data terpisah

Untuk lebih lanjut tentang skema, lihat pertanyaan ini:

Akhirnya, tampaknya tidak ada alasan untuk memiliki database terpisah berdasarkan "integritas transaksional tidak diperlukan". Lihat pertanyaan ini untuk menjelaskan ini: Kriteria keputusan kapan harus menggunakan skema non-dbo vs Database baru

— gbn
sumber

Terima kasih. Ada beberapa alasan mengapa data web berada dalam database yang terpisah, tetapi yang terbesar adalah bahwa sebenarnya ada beberapa database pribadi, dan web yang bertanggung jawab untuk pergi ke database pribadi yang benar untuk mendapatkan data. Perhatian utama saya adalah mencari tahu apakah perantara db benar-benar menambahkan sesuatu ke keamanan situs karena saya ingin menghapusnya. Sejauh ini terdengar seperti tidak menambah apa pun selain lapisan kompleksitas tambahan.

— Rachel

@Rachel: bit "multiple private databases" cukup relevan untuk jawaban apa pun, terutama jawaban ini ... Saya akan mengatakan sesuatu yang berbeda jika ini diketahui

— gbn

@ Rachel: mengapa Anda tidak menyebut "multiple PrivateDB" pada pertanyaan? Itu mengubah segalanya ...; - \

— Fabricio Araujo

@FabricioAraujo Saya mengedit pertanyaan saya 2 jam yang lalu untuk memasukkan informasi itu. Saya tidak berpikir itu penting pada saat itu karena saya bertanya tentang keamanan pengaturan database, bukan desainnya.

— Rachel

@FabricioAraujo: syarat mendefinisikan desain, jadi desain harus benar sebelum aman. Desain yang salah dan aman tidak berguna - desain yang tidak aman dan benar dapat dibuat aman kapan saja.

— Fabricio Araujo

Jawabannya adalah, tergantung. Jika database pribadi tidak diakses dari luar LAN internal (atau hanya melalui VPN), skema ini menambah keamanan karena seseorang yang menggunakan kredensial WebSite hanya akan memiliki akses terbatas ke DB Server pribadi itu (dan akan memiliki lebih banyak pekerjaan untuk didapatkan ke dalam jaringan internal Anda - waktu yang berguna untuk menemukan intrusi dan menutup lubang).

Jika tidak, saya tidak berpikir itu menambah apa pun kecuali kompleksitas.

EDIT:

Sepertinya saya salah membaca pertanyaan Anda, jadi mari kita lihat apakah saya mengerti dengan benar sekarang: IntermDb adalah database kosong hanya untuk terhubung ke PrivateDB ATAU itu adalah DB yang memiliki pandangan / prosedur sendiri yang menghubungkan ke PrivateDB untuk mengambil data ?

Dalam kasus pertama, WTF? Merobek, mencabik. Tidak ada artinya, kecuali seseorang ingin mengauditnya untuk akses profil ke PrivateDB dengan cara yang lebih malas (dan membuat pengembang WebApp bekerja lebih keras). SQL Profiler dapat memfilter menggunakan DB_ID ...

Dalam kasus kedua, saya mendukung jawaban saya sebelumnya.

EDIT: "Saya masih tidak melihat bagaimana ini lebih aman daripada menghubungkan private db langsung ke public db karena ketiga database aktif pada contoh SQL yang sama dan login yang digunakan untuk ketiga database adalah sama, dan hanya dapat mengakses pandangan spesifik dan prosedur tersimpan dalam db pribadi. "

Memiliki perantara berarti bahwa penyerang harus menggali dalam kode Anda mengetahui keberadaan IntermDB - dan itu harus menggali kode Anda di atasnya untuk mengetahui bahwa ada PrivateDB.

Jika Anda meletakkan PrivateDB di server lain internal ke LAN / WAN organisasi Anda (jika mungkin), ini dapat memberi waktu yang cukup bagi admin untuk mendeteksi dan memblokir upaya invasi. Jika Anda menggunakan sinonim, langkah ini lancar karena yang Anda miliki adalah membangunnya kembali ke kode yang ada, pergi ke tempat yang tepat.

Anda juga mendapatkan keuntungan lain: karena semua kode harus melewati IntermDB untuk mengakses data di PrivateDB, tidak ada pengembang yang tergoda untuk mencoba memintasnya - dan upaya itu dapat dengan mudah terlihat pada SQL Server Profiler sebagai DB_ID dari permintaan data PrivateDb akan menjadi WebAppDb.

— Fabricio Araujo
sumber

Bukankah keamanannya sama seperti jika Anda memiliki db publik pada satu server, dan yang pribadi pada yang lain? Apa yang dilakukan dengan menambahkan database ke-3 ke skema itu untuk meningkatkan keamanan? Meskipun dalam situasi saya, semua 3 database berada pada contoh server SQL yang sama (menambahkan info ini ke pertanyaan saya juga)

— Rachel

Menanggapi hasil edit Anda, db tengah berisi tampilan sendiri dan prosedur tersimpan yang mengembalikan data dari db pribadi. Saya masih tidak melihat bagaimana ini lebih aman daripada menghubungkan private db langsung ke public db karena ketiga database aktif pada instance SQL yang sama dan login yang digunakan untuk ketiga database adalah sama, dan hanya dapat mengakses tampilan spesifik dan disimpan prosedur di db pribadi lagian

— Rachel