Kawalan Akses untuk Pengguna dan Peranan dalam SQL

Keselamatan adalah penting untuk pentadbir pangkalan data yang berusaha untuk melindungi gigabait data perniagaan penting mereka dari mata yang bersuara orang luar yang tidak dibenarkan dan orang dalam yang cuba melebihi kuasa mereka. Semua sistem pengurusan pangkalan data hubungan menyediakan semacam mekanisme keselamatan intrinsik yang direka untuk meminimumkan ancaman ini. Mereka terdiri daripada perlindungan kata laluan yang mudah yang ditawarkan oleh Microsoft Access kepada struktur pengguna / peranan kompleks yang disokong oleh pangkalan data relasi maju seperti Oracle dan Microsoft SQL Server. Artikel ini memfokuskan pada mekanisme keselamatan yang sama kepada semua pangkalan data yang melaksanakan Bahasa Kuasa Struktur (atau SQL ). Bersama-sama, kami akan berjalan melalui proses memperkuat kawalan akses data dan memastikan keselamatan data anda.

Pengguna

Pangkalan data berasaskan pelayan semua menyokong konsep pengguna yang serupa dengan yang digunakan dalam sistem pengendalian komputer. Jika anda biasa dengan pengguna / kumpulan hierarki yang terdapat di Microsoft Windows NT dan Windows 2000, anda akan mendapati bahawa pengguna / peranan kumpulan yang disokong oleh SQL Server dan Oracle adalah sangat serupa.

Adalah amat disyorkan bahawa anda membuat akaun pengguna pangkalan data individu untuk setiap orang yang akan mengakses pangkalan data anda. Secara teknikalnya mungkin untuk berkongsi akaun antara pengguna atau hanya menggunakan satu akaun pengguna untuk setiap jenis pengguna yang perlu mengakses pangkalan data anda, tetapi saya sangat tidak menggalakkan amalan ini untuk dua sebab. Pertama, ia akan menghapuskan akauntabiliti individu-jika pengguna membuat perubahan kepada pangkalan data anda (katakan dengan memberi dirinya $ 5,000), anda tidak akan dapat mengesannya kembali kepada orang tertentu melalui penggunaan log audit. Selain itu, jika pengguna tertentu meninggalkan organisasi anda dan anda ingin mengalih keluar aksesnya dari pangkalan data, anda akan terpaksa menukar kata laluan yang semua pengguna bergantung.

Kaedah untuk membuat akaun pengguna berbeza dari platform ke platform dan anda perlu merujuk dokumentasi khusus DBMS anda untuk prosedur yang tepat. Pengguna Microsoft SQL Server harus menyiasat penggunaan prosedur sp_adduser yang disimpan. Pentadbir pangkalan data Oracle akan mencari arahan PENGUINAN CREATE berguna. Anda juga mungkin mahu menyiasat skim pengesahan alternatif. Sebagai contoh, Microsoft SQL Server menyokong penggunaan Windows NT Integrated Security. Di bawah skim ini, pengguna telah dikenal pasti ke pangkalan data oleh akaun pengguna Windows NT mereka dan tidak perlu memasukkan ID pengguna dan kata laluan tambahan untuk mengakses pangkalan data. Pendekatan ini sangat popular di kalangan pentadbir pangkalan data kerana ia mengalihkan beban pengurusan akaun kepada kakitangan pentadbiran rangkaian dan ia memberikan kemudahan kepada pengguna akhir.

Peranan

Sekiranya anda berada dalam persekitaran dengan sejumlah kecil pengguna, anda mungkin akan mendapati bahawa mencipta akaun pengguna dan memberi kebenaran langsung kepada mereka adalah mencukupi untuk keperluan anda. Walau bagaimanapun, jika anda mempunyai sejumlah besar pengguna, kemungkinan besar anda akan dibebani oleh beban mempertahankan akaun dan kebenaran yang tepat. Untuk meringankan beban ini, pangkalan data relasi menyokong tanggapan peranan. Peranan pangkalan data berfungsi sama dengan kumpulan Windows NT. Akaun pengguna ditugaskan untuk peranan dan keizinan kemudian ditugaskan kepada peranan secara keseluruhan daripada akaun pengguna individu. Contohnya, kami boleh membuat peranan DBA dan kemudian menambah akaun pengguna kakitangan pentadbiran kami kepada peranan ini. Sebaik sahaja kami melakukan ini, kami boleh memberikan kebenaran khusus kepada semua pentadbir sekarang (dan akan datang) dengan hanya memberi kebenaran kepada peranan. Sekali lagi, prosedur untuk mewujudkan peranan berbeza dari platform ke platform. Pentadbir MS SQL Server harus menyiasat prosedur yang disimpan sp_addrole sementara Oracle DBAs harus menggunakan sintaks ROLE CREATE.

Pemberian Pemberian

Kini kami telah menambah pengguna ke pangkalan data kami, sudah tiba masanya untuk memulakan pengukuhan keselamatan dengan menambah kebenaran. Langkah pertama kami ialah memberikan kebenaran pangkalan data yang sesuai kepada pengguna kami. Kami akan menyelesaikannya melalui penggunaan pernyataan SQL GRANT.

Inilah sintaks kenyataan:

GANTI
[ON

]
UNTUK
[DENGAN OPSI GANJARAN]

Sekarang, mari kita perhatikan kenyataan ini demi baris. Baris pertama, GANTI , membolehkan kami menentukan kebenaran jadual tertentu yang kami berikan. Ini boleh sama ada kebenaran tahap meja (seperti SELECT, INSERT, UPDATE dan DELETE) atau kebenaran pangkalan data (seperti CREATE TABLE, ALTER DATABASE dan GRANT). Lebih daripada satu kebenaran boleh diberikan dalam satu kenyataan GRANT, tetapi keizinan peringkat meja dan kebenaran peringkat pangkalan data tidak boleh digabungkan dalam satu pernyataan.

Baris kedua, PADA

, digunakan untuk menentukan jadual yang terjejas untuk keizinan peringkat meja. Baris ini ditinggalkan jika kami memberikan keizinan peringkat pangkalan data. Baris ketiga menentukan pengguna atau peranan yang diberikan kebenaran.

Akhirnya, baris keempat, DENGAN OPSI GANTI, adalah pilihan. Jika baris ini dimasukkan ke dalam pernyataan itu, pengguna yang terjejas juga dibenarkan memberikan kebenaran yang sama kepada pengguna lain. Ambil perhatian bahawa OPTION DENGAN DENGAN JANJI tidak dapat ditentukan apabila keizinan diberikan kepada peranan.

Contoh

Mari lihat beberapa contoh. Dalam senario pertama kami, kami baru-baru mengupah sekumpulan 42 pengendali kemasukan data yang akan menambah dan mengekalkan rekod pelanggan. Mereka perlu dapat mengakses maklumat di dalam jadual Pelanggan, mengubah maklumat ini dan menambah rekod baru ke meja. Mereka tidak boleh memadam rekod sepenuhnya dari pangkalan data. Pertama, kita harus membuat akaun pengguna untuk setiap pengendali dan kemudian menambahkannya kepada peranan baru, DataEntry. Seterusnya, kita harus menggunakan pernyataan SQL berikut untuk memberi mereka keizinan yang sesuai:

PILIH GRAND, INSERT, UPDATE
ON Pelanggan
TO DataEntry

Dan itu semua ada padanya! Sekarang mari kita periksa kes di mana kita memberikan kebenaran tingkat pangkalan data. Kami mahu membenarkan ahli peranan DBA menambah jadual baru ke pangkalan data kami. Selain itu, kami mahu mereka dapat memberi kebenaran kepada pengguna lain untuk melakukan perkara yang sama. Berikut adalah pernyataan SQL:

JUMAAT MEMBUAT JADUAL
DBA
DENGAN PILIHAN GANJARAN

Perhatikan bahawa kami telah memasukkan garis OPTION DENGAN GRANT untuk memastikan DBA kami boleh memberikan kebenaran ini kepada pengguna lain.

Mengalih keluar Kebenaran

Sebaik sahaja kami memberikan kebenaran, ia sering membuktikan perlu untuk membatalkannya pada masa akan datang. Mujurlah, SQL memberikan kami arahan REVOKE untuk menghapuskan kebenaran yang diberikan sebelum ini. Inilah sintaksnya:

REVOKE [OPTION GRANT FOR]
PADA


FROM

Anda akan melihat bahawa sintaks arahan ini adalah serupa dengan arahan GRANT. Satu-satunya perbezaan ialah DENGAN OPSI GANTI ditetapkan pada baris arahan REVOKE dan bukan pada akhir arahan. Sebagai contoh, bayangkan kita ingin membatalkan kebenaran Mary sebelum ini untuk menghapuskan rekod dari pangkalan pelanggan. Kami akan menggunakan arahan berikut:

REVOKE DELETE
ON Pelanggan
DARI MEREKA

Dan itu semua ada padanya! Terdapat satu mekanisme tambahan yang disokong oleh Microsoft SQL Server yang patut disebut-perintah DENY. Perintah ini boleh digunakan untuk secara nyata menafikan kebenaran kepada pengguna yang mereka mungkin mempunyai keahlian semasa atau masa hadapan. Inilah sintaksnya:

DENY
PADA


UNTUK

Contoh

Kembali kepada contoh terdahulu kita, mari kita bayangkan bahawa Maria juga merupakan anggota peranan Pengurus yang juga mempunyai akses ke meja Pelanggan. Kenyataan REVOKE sebelumnya tidak mencukupi untuk menafikan aksesnya ke meja. Ia akan menghapuskan kebenaran yang diberikan kepadanya melalui pernyataan GRANT yang mensasarkan akaun penggunanya, tetapi tidak akan menjejaskan keizinan yang diperoleh melalui keahliannya dalam peranan Pengurus. Walau bagaimanapun, jika kami menggunakan kenyataan DENY, ia akan menghalang warisan kebenarannya. Inilah arahannya:

DENY DELETE
ON Pelanggan
Kepada Maria

Perintah DENY pada asasnya mewujudkan "izin negatif" dalam kawalan akses pangkalan data. Sekiranya kita kemudian memutuskan untuk memberikan kebenaran kepada Mary untuk menghapus baris dari meja Pelanggan, kita tidak boleh menggunakan arahan GRANT sahaja. Perintah itu akan segera ditindih oleh DENY yang sedia ada. Sebaliknya, kami akan menggunakan arahan REVOKE terlebih dahulu untuk mengalih keluar kemasukan kebenaran negatif seperti berikut:

REVOKE DELETE
ON Pelanggan
DARI MEREKA

Anda akan perhatikan bahawa arahan ini sama persis dengan yang digunakan untuk menghapus kebenaran positif. Ingat bahawa arahan DENY dan GRANT kedua-duanya berfungsi dengan cara yang serupa * mdash; kedua-duanya menghasilkan keizinan (positif atau negatif) dalam mekanisme kawalan akses pangkalan data. Perintah REVOKE membuang semua kebenaran dan negatif untuk pengguna yang ditentukan. Sebaik sahaja arahan ini dikeluarkan, Mary akan dapat memadam baris dari jadual jika dia adalah ahli peranan yang memiliki kebenaran itu. Sebagai alternatif, arahan GRANT boleh dikeluarkan untuk memberikan kebenaran DELETE secara langsung ke akaunnya.

Sepanjang perjalanan artikel ini, anda telah belajar banyak tentang mekanisme kawalan akses yang disokong oleh Language Query Standard. Pengenalan ini harus memberikan anda titik permulaan yang baik, tetapi saya menggalakkan anda untuk merujuk dokumentasi DBMS anda untuk mempelajari langkah keselamatan yang disokong oleh sistem anda. Anda akan mendapati bahawa banyak pangkalan data menyokong mekanisme kawalan akses yang lebih canggih, seperti memberikan kebenaran pada lajur tertentu.