Bagaimana saya bisa menyembunyikan kata sandi di skrip shell? Ada beberapa script yang mengakses database. Jika kita membuka script orang lain juga mengetahui username dan password. Jadi, jika ada yang tahu cara menyembunyikannya, beri tahu saya.
Saya punya satu cara:letakkan kata sandi dalam file dan jadikan file sebagai tersembunyi dan tidak ada yang akan mengakses file (ubah izin dan gunakan file dalam skrip saat mengakses database).
Jawaban yang Diterima:
Pertama , seperti yang telah dikatakan beberapa orang, menjaga kredensial terpisah dari skrip sangat penting. (Selain peningkatan keamanan, ini juga berarti Anda dapat menggunakan kembali skrip yang sama untuk beberapa sistem dengan kredensial berbeda.)
Kedua , Anda harus mempertimbangkan tidak hanya keamanan kredensial tetapi juga dampaknya jika/saat kredensial tersebut disusupi. Anda tidak boleh hanya memiliki satu kata sandi untuk semua akses ke database, Anda harus memiliki kredensial yang berbeda dengan tingkat akses yang berbeda. Anda dapat, misalnya, memiliki satu pengguna DB yang memiliki kemampuan untuk melakukan pencarian di database – pengguna tersebut harus memiliki akses hanya-baca. Pengguna lain mungkin memiliki izin untuk memasukkan catatan baru, tetapi tidak untuk menghapusnya. Orang ketiga mungkin memiliki izin untuk menghapus catatan.
Selain membatasi izin untuk setiap akun, Anda juga harus membatasi dari mana setiap akun dapat digunakan. Misalnya, akun yang digunakan oleh server web Anda tidak boleh terhubung dari alamat IP lain selain dari server web. Akun dengan izin root penuh ke database harus sangat dibatasi dalam hal dari mana ia dapat terhubung dan tidak boleh digunakan selain secara interaktif. Selain itu, pertimbangkan untuk menggunakan prosedur tersimpan dalam database untuk membatasi secara tepat apa yang dapat dilakukan oleh setiap akun.
Pembatasan ini perlu diterapkan pada sisi server DB dari sistem sehingga meskipun sisi klien dikompromikan, pembatasan tidak dapat diubah darinya. (Dan, tentu saja, server DB perlu dilindungi dengan firewall dll selain konfigurasi DB…)
Dalam kasus akun DB yang hanya diizinkan akses baca-saja terbatas, dan hanya dari alamat IP tertentu, Anda mungkin tidak memerlukan kredensial lebih lanjut dari itu, tergantung pada sensitivitas data dan keamanan skrip host sedang dijalankan dari. Salah satu contoh mungkin formulir pencarian di situs web Anda, yang dapat dijalankan dengan pengguna yang hanya diperbolehkan menggunakan prosedur tersimpan yang mengekstrak hanya informasi yang akan disajikan di halaman web. Dalam hal ini, menambahkan sandi tidak benar-benar memberikan keamanan ekstra, karena informasi tersebut sudah dimaksudkan untuk publik, dan pengguna tidak dapat mengakses data lain yang lebih sensitif.
Selain itu, pastikan koneksi ke database dibuat menggunakan TLS, atau siapa pun yang mendengarkan di jaringan bisa mendapatkan kredensial Anda.
Ketiga , pertimbangkan jenis kredensial yang akan digunakan. Kata sandi hanyalah satu bentuk, dan bukan yang paling aman. Anda dapat menggunakan beberapa bentuk pasangan kunci publik/pribadi, atau AD/PAM atau sejenisnya.
Keempat , pertimbangkan kondisi di mana skrip akan dijalankan:
Terkait:Kode sumber netstat?Jika dijalankan secara interaktif, maka Anda harus memasukkan kata sandi, atau kata sandi ke kunci pribadi, atau kunci pribadi, atau masuk dengan tiket Kerberos yang valid, ketika Anda menjalankannya – dengan kata lain, skrip harus mendapatkan kredensial langsung dari Anda pada saat Anda menjalankannya, alih-alih membacanya dari beberapa file.
Jika dijalankan dari server web, pertimbangkan untuk menyiapkan kredensial pada saat Anda memulai server web. Contoh yang baik di sini adalah sertifikat SSL – mereka memiliki sertifikat publik dan kunci pribadi, dan kunci pribadi memiliki kata sandi. Anda dapat menyimpan kunci pribadi di server web, tetapi Anda masih harus memasukkan kata sandinya saat memulai Apache. Anda juga dapat memiliki kredensial pada beberapa jenis perangkat keras, seperti kartu fisik atau HSM, yang dapat dilepas atau dikunci setelah server dimulai. (Tentu saja, kelemahan metode ini adalah server tidak dapat memulai ulang sendiri jika terjadi sesuatu. Saya lebih suka ini daripada risiko sistem saya disusupi, tetapi jarak tempuh Anda mungkin berbeda…)
Jika skrip dijalankan dari cron, ini adalah bagian yang sulit. Anda tidak ingin kredensial tergeletak di mana saja di sistem Anda di mana seseorang dapat mengaksesnya – tetapi Anda ingin memilikinya sehingga skrip Anda dapat mengaksesnya, bukan? Yah, kurang tepat. Pertimbangkan dengan tepat apa yang dilakukan skrip. Izin apa yang diperlukan pada database? Bisakah itu dibatasi sehingga tidak masalah jika orang yang salah terhubung dengan izin itu? Bisakah Anda menjalankan skrip langsung di server DB yang tidak dapat diakses orang lain, alih-alih dari server yang memiliki pengguna lain? Jika, untuk beberapa alasan yang tidak dapat saya pikirkan, Anda benar-benar harus menjalankan skrip di server yang tidak aman dan harus dapat melakukan sesuatu yang berbahaya/merusak… sekarang adalah waktu yang tepat untuk memikirkan kembali arsitektur Anda.
Kelima , jika Anda menghargai keamanan database Anda, Anda tidak boleh menjalankan skrip ini di server yang dapat diakses orang lain. Jika seseorang masuk ke sistem Anda, maka mereka akan memiliki kemungkinan untuk mendapatkan kredensial Anda. Misalnya, dalam kasus server web dengan sertifikat SSL, setidaknya ada kemungkinan teoretis seseorang dapat memperoleh root dan mengakses area memori proses httpd dan mengekstrak kredensial. Setidaknya ada satu eksploitasi akhir-akhir ini yang dapat dilakukan melalui SSL, bahkan penyerang tidak perlu login.
Juga, pertimbangkan untuk menggunakan SELinux atau AppArmor atau apa pun yang tersedia untuk sistem Anda untuk membatasi pengguna mana yang dapat melakukan apa. Mereka akan memungkinkan Anda untuk melarang pengguna mencoba terhubung ke database, bahkan jika mereka berhasil mendapatkan akses ke kredensial.
Jika semua ini terdengar berlebihan bagi Anda , dan Anda tidak mampu atau tidak punya waktu untuk melakukannya – maka, menurut pendapat saya (sombong dan elitis), Anda tidak boleh menyimpan sesuatu yang penting atau sensitif dalam database Anda. Dan jika Anda tidak menyimpan sesuatu yang penting atau sensitif, maka di mana Anda menyimpan kredensial Anda juga tidak penting – dalam hal ini, mengapa menggunakan sandi sama sekali?
Terkait:Hasilkan empat kata acak dari daftar kata sandi seperti XKCD?Terakhir , jika Anda benar-benar tidak dapat menghindari penyimpanan semacam kredensial, Anda dapat memiliki kredensial hanya-baca dan dimiliki oleh root dan root dapat memberikan kepemilikan secara sangat sementara ketika diminta untuk melakukannya oleh skrip (karena skrip Anda harus tidak dijalankan sebagai root kecuali benar-benar diperlukan, dan menghubungkan ke database tidak membuatnya perlu). Tapi itu masih bukan ide yang bagus.