Jawaban singkat
Anda tidak bisa.
Jika kata sandi disimpan dalam artefak yang dikirimkan ke pengguna akhir, Anda harus anggap itu dikompromikan! Meskipun artefak adalah biner yang dikompilasi, selalu ada (kurang lebih rumit) cara untuk mendapatkan kata sandi.
Satu-satunya cara untuk melindungi sumber daya Anda adalah dengan hanya mengekspos API terbatas kepada pengguna akhir. Buat API terprogram (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) atau hanya ekspos fungsionalitas tertentu di DB Anda melalui SPROC (lihat di bawah).
Beberapa hal dulu...
Pertanyaannya di sini seharusnya bukan bagaimana menyembunyikan kata sandi, tetapi bagaimana mengamankan database. Ingatlah bahwa kata sandi saja seringkali merupakan perlindungan yang sangat lemah dan tidak boleh dianggap sebagai satu-satunya mekanisme untuk melindungi DB. Apakah Anda menggunakan SSL? Tidak? Yah, bahkan jika Anda berhasil menyembunyikan kata sandi dalam kode aplikasi, masih mudah untuk mengendusnya di jaringan!
Anda memiliki banyak pilihan. Semua dengan berbagai tingkat keamanan:
"Peran Aplikasi"
Buat satu database-user untuk aplikasi. Terapkan otorisasi untuk peran ini. Pengaturan yang sangat umum adalah hanya mengizinkan operasi CRUD.
Pro
- sangat mudah diatur
- Mencegah
DROPkueri (mis. dalam injeksi SQL?)
Kontra
- Semua orang yang melihat sandi memiliki akses ke semua data dalam database. Meskipun data tersebut biasanya disembunyikan di dalam aplikasi.
- Jika sandi disusupi, pengguna dapat menjalankan
UPDATEdanDELETEkueri tanpa kriteria (yaitu:hapus/perbarui seluruh tabel sekaligus).
Otentikasi&otentikasi atom
Buat satu pengguna database per aplikasi-/pengguna akhir. Ini memungkinkan Anda untuk menentukan hak akses atom bahkan pada basis per kolom. Misalnya:Pengguna X hanya dapat memilih kolom jauh dan baz dari tabel foo. Dan tidak ada lagi. Tetapi pengguna Y dapat SELECT semuanya, tetapi tidak ada pembaruan, sementara pengguna Z memiliki akses penuh CRUD (pilih, masukkan, perbarui, hapus).
Beberapa database memungkinkan Anda untuk menggunakan kembali kredensial tingkat OS. Hal ini membuat otentikasi kepada pengguna menjadi transparan (hanya perlu login ke workstation, identitas tersebut kemudian diteruskan ke DB). Ini bekerja paling mudah di tumpukan MS penuh (OS=Windows, Auth=ActiveDirectory, DB=MSSQL) tetapi - sejauh yang saya ketahui - juga mungkin untuk dicapai di DB lain.
Pro
- Cukup mudah disiapkan.
- Skema otorisasi yang sangat atomik
Kontra
- Menyetel semua hak akses di DB bisa jadi membosankan.
- Pengguna dengan
UPDATEdanDELETEhak masih dapat secara tidak sengaja (atau sengaja?) menghapus/memperbarui tanpa kriteria. Anda berisiko kehilangan semua data dalam sebuah tabel.
Prosedur Tersimpan dengan auth&auth atom
Tulis tidak Kueri SQL di aplikasi Anda. Jalankan semuanya melalui SPROC. Kemudian buat akun db untuk setiap pengguna dan berikan hak istimewa ke saja SPROC .
Pro
- Mekanisme perlindungan paling efektif.
- SPROC dapat memaksa pengguna untuk memberikan kriteria ke setiap kueri (termasuk
DELETEdanUPDATE)
Kontra
- tidak yakin apakah ini berfungsi dengan MySQL (pengetahuan saya di bidang itu tidak stabil).
- siklus pengembangan yang kompleks:Semua yang ingin Anda lakukan, harus didefinisikan terlebih dahulu dalam SPROC.
Pemikiran terakhir
Anda tidak boleh mengizinkan tugas administratif database ke aplikasi. Seringkali, satu-satunya operasi yang dibutuhkan aplikasi adalah SELECT , INSERT , DELETE dan UPDATE . Jika Anda mengikuti panduan ini, hampir tidak ada risiko bagi pengguna untuk menemukan kata sandi. Kecuali poin-poin yang disebutkan di atas.
Bagaimanapun, simpan cadangan. Saya berasumsi Anda ingin memproyeksikan basis data Anda terhadap penghapusan atau pembaruan yang tidak disengaja. Tapi kecelakaan terjadi... ingatlah itu;)
