Bukan rahasia lagi bahwa informasi membuat dunia berputar saat ini. Jika suatu perusahaan menjaga kekayaan intelektualnya dan setiap karyawan dapat dengan mudah mendapatkan informasi yang diperlukan, perusahaan dapat mengharapkan pertumbuhan. Jika ada kekacauan dalam data, perusahaan akan gagal meskipun ada semangat tim.
Pada artikel ini, kita akan menjelajahi dasar-dasar keamanan database dan contoh perlindungan informasi di Oracle. Sebenarnya, dasar-dasar teoretis untuk melindungi informasi dalam database, yang akan kita bahas dalam artikel ini, juga akan berguna bagi orang yang bekerja dengan database lain.
Izin akses
Di sebagian besar perusahaan tempat saya bekerja, semua administrator dan pengembang memiliki akses penuh ke database, serta karyawan departemen TI adalah dewa dan dapat melakukan apa pun yang mereka inginkan. Mengapa itu terjadi? Ada dua alasan untuk ini:
- Saat bekerja di satu departemen, karyawan dapat bertemu satu sama lain selama 8 jam setiap hari dan menjadi teman. Bagaimana mereka tidak bisa memberikan akses? Persahabatan adalah satu hal, tetapi bisnis adalah bisnis.
- Memberikan beberapa hak akses atau memodifikasi beberapa konfigurasi mungkin memerlukan beberapa hak istimewa. Terkadang, administrator berpikir bahwa programmer mengonfigurasi pengaturan dengan lebih baik. Dengan demikian, mereka memberi programmer hak akses yang tidak perlu. Sebaliknya, pemrogram tidak boleh terlibat dalam administrasi dan tidak boleh memiliki hak apa pun untuk ini.
Menurut pengalaman saya, masalah kedua sangat umum, jadi kami akan menganalisisnya secara detail.
Saat mengembangkan program untuk basis data, pemrogram mengetahui kata sandi pengguna super atau hanya memiliki hak administrator basis data. Ini tidak perlu dan sama sekali tidak aman. Hanya administrator database yang harus memiliki hak penuh. Bahkan kepala departemen, direktur, dan sahabat dapat memiliki lebih sedikit hak istimewa.
Misalnya, ketika mengembangkan program, cukup memiliki hak pemilik skema di database Oracle yang menyimpan tabel kerja. Hak ini cukup untuk membuat tabel baru, paket, indeks, dan objek lain, serta memberikan hak akses ke objek skema kepada pengguna lain. Anda tidak memerlukan hak sistem untuk pekerjaan penuh waktu.
Jika tidak ada administrator database secara penuh waktu, itu sangat buruk. Lebih baik bila ada seseorang yang bertanggung jawab untuk kinerja database, optimasi, dan keamanan. Setidaknya, Anda perlu menunjuk satu programmer yang akan bertanggung jawab untuk ini dan akan memiliki hak eksklusif.
Menurut statistik, karyawan perusahaan paling sering menyebabkan kehilangan data. Namun, terlepas dari kenyataan ini, sebagian besar perusahaan terus mengabaikan utas ini dan basis data berbeda yang disimpan di disk dengan akses gratis dijual bahkan di kereta bawah tanah.
Pengguna dan Peran
Ada dua jenis objek untuk memberikan hak akses dalam database:pengguna dan peran. Peran adalah beberapa grup yang menggabungkan pengguna yang harus memiliki hak yang sama. Misalnya, semua akuntan mungkin memerlukan akses ke dokumen keuangan. Untuk mencegah Anda memberikan hak kepada setiap akuntan, kami dapat menggabungkannya menjadi peran dengan akses yang diperlukan.
Seperti yang Anda lihat, prinsip peran mirip dengan grup di sistem operasi Windows. Namun, ia memiliki beberapa perbedaan. Bukan tanpa alasan, ketiga tipe objek seperti pengguna, grup, dan peran dapat diimplementasikan dalam database. Namun, hanya pengguna dan peran yang diterapkan di sebagian besar basis data. Penting untuk mengelola dan memantau semua objek ini sehingga setiap pengguna yang memperoleh hak yang diberikan oleh peran dapat memiliki akses ke data yang sebenarnya diperlukan untuk menyelesaikan tugas. Penting untuk menggunakan hak akses sebagai aturan untuk firewall. Dengan menggunakan hak ini, Anda dapat memecahkan masalah yang sama – untuk memungkinkan pengguna melakukan tugas tertentu saja dan mencegah kemungkinan kehilangan atau korupsi.
Dengan bantuan peran, cukup nyaman untuk mengontrol akses, memberikan izin, atau memblokir seluruh grup pengguna. Satu peran dapat dimasukkan ke yang lain, dengan demikian, mewarisi hak aksesnya. Oleh karena itu, kita dapat membuat struktur hierarki hak.
Semua karyawan dengan hak akses ke database perusahaan dapat dimasukkan ke dalam satu peran dengan hak minimum. Sekarang, jika Anda memerlukan hak istimewa tambahan, akses ke tabel tertentu, Anda perlu menambahkan pengguna ke peran lain (jika grup memerlukan akses yang sama) atau memberikan hak kepada akun tertentu.
Dalam program, untuk mengontrol akses ke tabel, dimungkinkan untuk memeriksa hasil untuk kesalahan setelah setiap upaya untuk membuka kumpulan data. Jika terjadi kesalahan akses, akses ke tabel yang ditentukan diblokir untuk pengguna. Dengan demikian, tidak perlu mengimplementasikan hak akses ke aplikasi klien. Namun, jika Anda ingin menerapkan ini, tidak ada salahnya dilakukan. Setidaknya, saya tidak melihat sesuatu yang kritis dalam hal ini; tampaknya memiliki efek sebaliknya.
Audit Keamanan
Jika setiap pengguna bekerja di bawah akun mereka sendiri di database Anda, Anda dapat memanggil variabel pengguna untuk menentukan pengguna saat ini, misalnya:
SELECT user from dual
Kueri ini akan mengembalikan nama pengguna, di mana koneksi ke server dibuka. Jika beberapa orang dapat masuk menggunakan satu nama, kueri ini akan mengembalikan nama yang sama untuk keduanya dan tidak akan berguna untuk audit. Terutama, jika kontrol penguncian terjadi di tingkat server.
Jika beberapa pengguna dapat masuk menggunakan nama pengguna yang sama, itu rumit, tetapi masih mungkin, untuk mengidentifikasi siapa yang masuk ke akun. Kueri berikut memungkinkan mendapatkan informasi terperinci tentang sesi:
select s.user#, s.username, s.osuser, s.terminal, s.program from sys.v_$session s WHERE username=user
Seperti yang Anda lihat, kueri mengembalikan nama pengguna, terhubung ke database, nama di sistem operasi, nama pengguna terminal, dan program.
Di sini, Anda dapat mengakses tampilan v_$session dari skema sistem sys. Tampilan ini mengembalikan beberapa informasi tentang koneksi ke server. Dalam klausa WHERE, kami membatasi output hanya untuk pengguna saat ini. Akibatnya, kueri mengembalikan ID pengguna, nama, nama di sistem operasi, terminal, dan program dari mana koneksi dibuat.
Ketika Anda mengetahui nama pengguna dan nama terminal, Anda dapat mengidentifikasi pengguna dengan pasti. Untuk mengetahui peran apa yang ditambahkan pengguna saat ini, Anda dapat menjalankan kueri berikut:
SELECT GRANTED_ROLE FROM dba_role_privs WHERE grantee=user
Keamanan Akun
Kami tidak akan mengatakan bahwa tidak boleh ada kata sandi default. Beberapa database, misalnya, MySQL melakukan kesalahan ketika mereka membuat kata sandi sistem yang sederhana dan terkenal setelah instalasi. Kami juga tidak akan mengatakan bahwa kata sandi harus rumit. Aturan ini berlaku untuk semua area TI dan harus diketahui bahkan oleh pengguna pemula. Kita akan berbicara tentang masalah basis data.
Dalam pengalaman saya, ketika mengembangkan program perusahaan, pengembang menggunakan akun yang sama untuk mengakses database. Parameter akun ini terdaftar langsung dalam program, sedangkan akses ke modul tertentu, termasuk akuntansi, gudang, departemen personalia, dll. diimplementasikan secara terprogram. Di satu sisi, metode ini nyaman, karena program dapat terhubung ke database dengan hak administrator dan tidak perlu mengurus peran dan hak akses ke tabel. Di sisi lain, metode ini jauh dari aman. Tingkat pengguna semakin meningkat, dan teman-teman karyawan perusahaan Anda dapat dididik di bidang keamanan dan peretasan. Setelah mengetahui nama dan kata sandi, di mana program terhubung ke database, pengguna biasa bisa mendapatkan lebih banyak peluang daripada yang Anda inginkan.
Bahasa SQL bukanlah bahasa rahasia dan rumit. Ada banyak program yang dapat digunakan untuk melihat data apa pun dalam database dengan mudah. Dengan nama pengguna dan kata sandi, siapa pun dapat mencuri semua data Anda. Jadi, itu akan dijual di kios mana pun yang menjual disk.
Nama pengguna dan kata sandi tidak boleh disimpan dalam program. Akses ke program juga harus dibatasi dan tidak mungkin bagi pihak ketiga. Cukup logis untuk menggabungkan kedua login menjadi satu. Penting untuk membuat akun terpisah di server basis data dengan hak minimum yang diperlukan untuk setiap pengguna dalam organisasi. Nama dan kata sandi ini harus digunakan saat masuk ke program. Anda dapat menggunakan logika umum dan sangat efektif – jika Anda dapat masuk ke database dengan data yang dimasukkan, akses diperbolehkan; jika tidak, Anda harus membatalkan program. Proses ini sederhana dan efektif karena kami menggunakan otorisasi database.
Untuk memeriksa bahwa pengguna tidak bekerja secara bersamaan dari dua komputer berbeda dengan nama yang sama, Anda dapat menjalankan kueri berikut:
select s.username, s.terminal, count(*) from sys.v_$session s WHERE username=user HAVING count(*)>1 GROUP BY s.username, s.terminal
Faktanya, itu tidak boleh mengembalikan catatan apa pun.
Tampilan
Tampilan adalah cara yang sangat nyaman untuk mematikan struktur data dan membangun tingkat perlindungan tambahan pada saat yang bersamaan. Memang benar bahwa pandangan memiliki dampak negatif pada produktivitas, namun pandangan memiliki dampak positif pada keamanan. Kami dapat memberikan hak akses mereka sendiri, sedangkan tabel dari mana data diambil dapat tetap tidak dapat diakses oleh akun ini.
Kapan sebaiknya menggunakan tampilan? Pertama, mari kita definisikan apa kekurangan mereka. View adalah pernyataan SELECT untuk mengambil data. Itu dapat mengakses keduanya, satu dan beberapa tabel. Jika Anda hanya memilih data dari tampilan, tidak akan ada penurunan kinerja. Namun, kita bisa menggunakan tampilan di kueri lain untuk memilih data dan merujuknya ke tabel. Misalnya:
SELECT list of fields FROM view, table_1, table_2 WHERE some parameters
Dalam hal ini, kueri mengambil data dari tampilan dan dua tabel. Selain itu, kita dapat melihat hubungan antara semua objek dan kondisi tambahan dapat diatur.
Sekarang, mari kita lihat kueri seperti yang dilihat oleh pengoptimal database:
SELECT list of fields FROM (SELECT ...), table1, table2 WHERE some parameters
Dalam hal ini, saya mengganti tampilan dengan pernyataan SELECT abstrak dalam tanda kurung yang terdiri dari tampilan tersebut. Ternyata server melihat kueri dengan subkueri. Jika subquery mengembalikan data dinamis, bukan nilai statis, pemilihan data ini akan bekerja lebih lambat daripada jika kita menulis kueri yang sama tanpa subquery.
Keamanan Data
Anda tidak boleh memberikan akses penuh ke objek tanpa kebutuhan khusus. Saya selalu mulai memberikan hak hanya untuk mengizinkan pemilihan data dengan pernyataan SELECT. Jika pengguna benar-benar perlu memasukkan catatan baru dan mereka tidak dapat melakukan tugas yang diberikan kepadanya, dalam hal ini, tambahkan izin pada pernyataan INSERT dari tabel yang ditentukan.
Operasi yang paling berbahaya untuk data adalah modifikasi dan penghapusan, yaitu UPDATE dan DELETE, masing-masing. Anda perlu memberikan hak-hak ini dengan hati-hati. Pastikan bahwa data dapat diubah atau dihapus. Hanya dalam kasus ini, pilih hak yang sesuai. Beberapa tabel hanya diperluas secara alami.
Penting untuk memastikan bahwa data akan sering terpengaruh. Misalnya, tabel karyawan dapat diperpanjang dan dimodifikasi, tetapi satu catatan tidak boleh dihapus. Penghapusan tersebut dapat memengaruhi latar belakang pekerjaan, pelaporan, dan integritas data karyawan. Kasus ketika seorang petugas sumber daya manusia secara tidak sengaja menambahkan catatan tambahan dan ingin menghapusnya masih mungkin terjadi. Namun, kasus seperti itu jarang terjadi dan kesalahan dapat diperbaiki oleh administrator database. Kami memahami bahwa tidak ada yang ingin bekerja terlalu keras dan lebih mudah untuk memberikan izin, namun, keamanan lebih berharga.
Pemberian hak dilakukan dengan menggunakan operator GRANT. Secara umum, tampilannya seperti ini:
HIBAH apa yang harus diberikan hak untuk objek ON KEPADA pengguna atau peran
Misalnya, kueri berikut memberikan hak untuk menyisipkan dan melihat tabel TestTable ke User1:
GRANT Select, Insert ON TestTable TO User1
Kunci Asing
Banyak pengguna yang takut dengan kunci asing karena biasanya mereka tidak mengizinkan penghapusan data ketika ada gabungan luar. Masalahnya dapat dengan mudah diselesaikan jika penghapusan kaskade dibuat. Namun, kebanyakan spesialis tidak menyukai kemungkinan ini. Satu tindakan konyol dapat merusak data yang sangat penting tanpa permintaan konfirmasi apa pun. Data yang ditautkan harus dihapus secara eksplisit, dan hanya jika pengguna secara sadar telah mengonfirmasi bahwa data tersebut dapat dihapus.
Jangan takut dengan kunci asing. Mereka memberi kami cara mudah untuk mengontrol integritas data dari server basis data, dengan demikian, ini adalah keamanan yang tidak ada salahnya. Fakta bahwa mungkin ada masalah dengan penghapusan hanyalah keuntungan. Lebih baik tidak menghapus data daripada kehilangan selamanya. Kunci asing bersama dengan indeks tidak mengurangi kinerja. Ini hanyalah pemeriksaan kecil saat menghapus data atau memodifikasi bidang kunci tempat data terhubung dalam tabel yang berbeda.
Cadangan
Cadangan juga merupakan salah satu faktor keamanan yang kami abaikan sebelum kehilangan data pertama. Namun, secara pribadi, saya akan memasukkannya ke dalam yang utama. Kehilangan data dapat disebabkan tidak hanya oleh peretas dan pengguna yang tidak kompeten, tetapi juga karena kegagalan fungsi peralatan. Kegagalan pada peralatan dapat menyebabkan hilangnya basis data, yang pemulihannya dapat memakan waktu berjam-jam atau bahkan berhari-hari.
Penting untuk mengembangkan kebijakan pencadangan yang paling efektif terlebih dahulu. Apa yang dimaksud dengan demikian? Waktu henti yang disebabkan oleh hilangnya data dan hingga saat pemulihan kapasitas kerja harus minimal. Kehilangan data juga harus minimal, dan pencadangan tidak akan memengaruhi pekerjaan pengguna. Jika ada uang dan peluang, lebih baik menggunakan sistem seperti RAID, cluster, atau bahkan replikasi data.
Pencadangan dan pemulihan adalah topik yang terpisah dan menarik. Kami tidak dapat menyentuhnya di sini, tetapi kami tidak akan mempertimbangkannya secara detail.
Ringkasan
Kami telah mempertimbangkan dasar-dasar keamanan, khususnya untuk Oracle. Jangan lupa bahwa proteksi yang diberikan oleh database hanya satu level, sedangkan proteksinya harus multilevel. Untuk sedikit tidur dengan pikiran yang jernih, perlu untuk menerapkan seluruh fitur keamanan di jaringan, server dan semua komputer, termasuk antivirus, anti-spyware, VPN, IDS, dll. Semakin banyak tingkat perlindungan, semakin banyak akan sulit untuk mengatasinya.
Harus ada kebijakan dan kontrol keamanan yang jelas. Jika seorang karyawan pergi, akun mereka akan dihapus. Jika Anda memiliki pengguna yang bekerja dengan kata sandi yang sama atau menggunakan kata sandi grup untuk melakukan tugas apa pun, semua kata sandi ini harus diubah. Misalnya, jika seorang administrator keluar, dan Anda memiliki semua administrator yang menggunakan akun yang sama, Anda harus mengubah sandi.
Keamanan itu perlu. Anda harus melindungi diri Anda tidak hanya dari peretas tetapi juga dari pengguna "pemula", yang dapat merusak data karena kurangnya pengalaman mereka. Kebijakan keamanan yang baik membantu mencegah kasus seperti itu dan kemungkinan ini tidak dapat dikecualikan. Lebih baik memberikan kemampuan untuk mengamankan data dari pengalaman sebelumnya daripada kehilangan banyak waktu untuk memulihkan data dan mendapatkan waktu henti yang tidak perlu.
Baca Juga:
Menyetel Izin Akses Basis Data
