Cara Menggunakan Peran yang Telah Berubah di MySQL 8.0

Keamanan Basis Data penting untuk pengaturan MySQL apa pun. Pengguna adalah dasar dari sistem apa pun. Dalam hal sistem basis data, saya biasanya menganggapnya dalam dua kelompok berbeda:

Pengguna aplikasi, layanan, atau program - pada dasarnya pelanggan atau klien yang menggunakan layanan.
Pengembang basis data, administrator, analis, dll… - Mereka yang memelihara, bekerja dengan, atau memantau infrastruktur basis data.

Meskipun setiap pengguna memang perlu mengakses database pada tingkat tertentu, izin tersebut tidak semuanya dibuat sama.

Misalnya, klien dan pelanggan memerlukan akses ke data 'akun pengguna terkait' mereka, tetapi itu pun harus dipantau dengan beberapa tingkat kontrol. Namun, beberapa tabel dan data harus benar-benar terlarang (Misalnya, tabel sistem).

Namun demikian:

Analis membutuhkan 'akses baca ', untuk mengumpulkan informasi dan wawasan melalui tabel kueri…
Developer memerlukan banyak izin dan hak istimewa untuk menjalankan pekerjaannya…
DBA membutuhkan 'root' atau hak akses sejenis untuk menjalankan acara…
Pembeli layanan perlu melihat riwayat pesanan dan pembayaran mereka…

Anda dapat membayangkan (saya tahu saya melakukannya) betapa sulitnya tugas mengelola banyak pengguna atau grup pengguna dalam ekosistem basis data.

Dalam versi MySQL yang lebih lama, lingkungan multi-pengguna dibuat dengan cara yang agak monoton dan berulang.

Namun, versi 8 mengimplementasikan fitur standar SQL yang luar biasa dan kuat - Peran - yang meringankan salah satu area yang lebih berlebihan dari keseluruhan proses:memberikan hak istimewa kepada pengguna.

Jadi, apa peran dalam MySQL?

Anda pasti dapat mengunjungi, MySQL pada tahun 2018:Apa yang ada di 8.0 dan Pengamatan Lainnya, saya menulis untuk blog Somenines di sini di mana saya menyebutkan peran untuk ikhtisar tingkat tinggi. Namun, di mana saya hanya merangkumnya di sana, postingan kali ini terlihat lebih dalam dan hanya fokus pada peran.

Berikut adalah bagaimana dokumentasi MySQL online mendefinisikan peran:"Peran MySQL adalah kumpulan hak istimewa yang diberi nama".

Bukankah definisi itu saja sudah membantu?

Tapi bagaimana?

Kita akan melihat pada contoh berikut.

Untuk Mencatat Contoh yang Diberikan

Contoh-contoh yang disertakan dalam posting ini adalah dalam pengembangan 'pengguna tunggal' pribadi dan tempat kerja/lingkungan pembelajaran, jadi pastikan dan terapkan praktik terbaik yang bermanfaat bagi Anda untuk kebutuhan atau persyaratan khusus Anda. Nama pengguna dan kata sandi yang ditunjukkan murni arbitrer dan lemah.

Pengguna dan Hak Istimewa di Versi Sebelumnya

Di MySQL 5.7, peran tidak ada. Menetapkan hak istimewa kepada pengguna dilakukan secara individual. Untuk lebih memahami peran apa yang diberikan, mari kita tidak menggunakannya. Itu tidak masuk akal sama sekali, aku tahu. Namun, seiring berjalannya waktu melalui pos, itu akan terjadi.

Di bawah ini kami membuat beberapa pengguna:

CREATE USER 'reader_1'@'localhost' IDENTIFIED BY 'some_password'; 
CREATE USER 'reader_writer'@'localhost' IDENTIFIED BY 'another_password'; 
CREATE USER 'changer_1'@'localhost' IDENTIFIED BY 'a_password';

Kemudian pengguna tersebut diberikan beberapa hak istimewa:

GRANT SELECT ON some_db.specific_table TO 'reader_1'@'localhost';
GRANT SELECT, INSERT ON some_db.specific_table TO 'reader_writer'@'localhost';
GRANT UPDATE, DELETE ON some_db.specific_table TO 'changer_1'@'localhost';

Wah, senang itu sudah berakhir. Sekarang kembali ke…

Dan begitu saja, Anda memiliki permintaan untuk menerapkan dua pengguna 'hanya-baca' lagi…

Kembali ke papan gambar:

CREATE USER 'reader_2'@'localhost' IDENTIFIED BY 'password_2'; 
CREATE USER 'reader_3'@'localhost' IDENTIFIED BY 'password_3';

Memberi mereka hak istimewa juga:

GRANT SELECT ON some_db.specific_table TO 'reader_2'@'localhost';
GRANT ALL ON some_db.specific_table TO 'reader_3'@'localhost';

Dapatkah Anda melihat bagaimana ini kurang produktif, penuh pengulangan, dan rawan kesalahan? Tapi, yang lebih penting, apakah Anda menyadari kesalahannya?

Bagus untukmu!

Saat memberikan hak istimewa untuk dua pengguna tambahan ini, saya tidak sengaja memberikan SEMUA hak istimewa kepada pengguna baru reader_3.

Ups.

Kesalahan yang bisa dilakukan siapa saja.

Masukkan Peran MySQL

Dengan peran, sebagian besar sistematis di atas penugasan hak istimewa dan delegasi dapat sedikit disederhanakan .

Pembuatan pengguna pada dasarnya tetap sama, tetapi memberikan hak istimewa melalui peran yang berbeda:

mysql> CREATE USER 'reader_1'@'localhost' IDENTIFIED BY 'some_password';
Query OK, 0 rows affected (0.19 sec)

mysql> CREATE USER 'reader_writer'@'localhost' IDENTIFIED BY 'another_password';
Query OK, 0 rows affected (0.22 sec)

mysql> CREATE USER 'changer_1'@'localhost' IDENTIFIED BY 'a_password';
Query OK, 0 rows affected (0.08 sec)

mysql> CREATE USER 'reader_2'@'localhost' IDENTIFIED BY 'password_2';
Query OK, 0 rows affected (0.28 sec)

mysql> CREATE USER 'reader_3'@'localhost' IDENTIFIED BY 'password_3';
Query OK, 0 rows affected (0.12 sec)

Query tabel sistem mysql.user, Anda dapat melihat pengguna yang baru dibuat itu ada:

(Catatan:Saya memiliki beberapa akun pengguna dalam lingkungan pembelajaran/pengembangan ini dan telah menekan banyak keluaran untuk kejelasan di layar yang lebih baik.)

mysql> SELECT User FROM mysql.user;
+------------------+
| User             |
+------------------+
| changer_1        |
| mysql.infoschema |
| mysql.session    |
| mysql.sys        |
| reader_1         |
| reader_2         |
| reader_3         |
| reader_writer    |
| root             |
|                  | --multiple rows remaining here...
+------------------+
23 rows in set (0.00 sec)

Saya memiliki tabel dan sampel data arbitrer ini:

mysql> SELECT * FROM name;
+--------+------------+
| f_name | l_name     |
+--------+------------+
| Jim    | Dandy      |
| Johhny | Applesauce |
| Ashley | Zerro      |
| Ashton | Zerra      |
| Ashmon | Zerro      |
+--------+------------+
5 rows in set (0.00 sec)

Sekarang mari kita gunakan peran untuk menetapkan dan menetapkan, hak istimewa bagi pengguna baru untuk menggunakan tabel nama.

Pertama, buat peran:

mysql> CREATE ROLE main_read_only;
Query OK, 0 rows affected (0.11 sec)

mysql> CREATE ROLE main_read_write;
Query OK, 0 rows affected (0.11 sec)

mysql> CREATE ROLE main_changer;
Query OK, 0 rows affected (0.14 sec)

Perhatikan tabel mysql.user lagi:

mysql> SELECT User FROM mysql.user;
+------------------+
| User             |
+------------------+
| main_changer     |
| main_read_only   |
| main_read_write  |
| changer_1        |
| mysql.infoschema |
| mysql.session    |
| mysql.sys        |
| reader_1         |
| reader_2         |
| reader_3         |
| reader_writer    |
| root             |
|                  |
+------------------+
26 rows in set (0.00 sec)

Berdasarkan output ini, kita dapat menduga; bahwa pada dasarnya, peran sebenarnya adalah pengguna itu sendiri.

Selanjutnya, penetapan hak istimewa:

mysql> GRANT SELECT ON practice.name TO 'main_read_only';
Query OK, 0 rows affected (0.14 sec)

mysql> GRANT SELECT, INSERT ON practice.name TO 'main_read_write';
Query OK, 0 rows affected (0.07 sec)

mysql> GRANT UPDATE, DELETE ON practice.name TO 'main_changer';
Query OK, 0 rows affected (0.16 sec)

Selingan Singkat

Tunggu sebentar. Bisakah saya masuk dan melakukan tugas apa pun dengan akun peran itu sendiri? Bagaimanapun, mereka adalah pengguna dan mereka memiliki hak istimewa yang diperlukan.

Mari kita coba login ke database latihan dengan role main_changer:

:~$ mysql -u main_changer -p practice
Enter password: 
ERROR 1045 (28000): Access denied for user 'main_changer'@'localhost' (using password: YES

Fakta sederhana bahwa kita disajikan dengan prompt kata sandi adalah indikasi yang baik bahwa kita tidak bisa (setidaknya saat ini). Seperti yang Anda ingat, saya tidak menetapkan kata sandi untuk peran apa pun selama pembuatannya.

Apa yang dikatakan kolom otentikasi_string tabel sistem mysql.user?

mysql> SELECT User, authentication_string, password_expired
    -> FROM mysql.user
    -> WHERE User IN ('main_read_only', 'root', 'main_read_write', 'main_changer')\G
*************************** 1. row ***************************
                 User: main_changer
authentication_string: 
     password_expired: Y
*************************** 2. row ***************************
                 User: main_read_only
authentication_string: 
     password_expired: Y
*************************** 3. row ***************************
                 User: main_read_write
authentication_string: 
     password_expired: Y
*************************** 4. row ***************************
                 User: root
authentication_string: ***various_jumbled_mess_here*&&*&*&*##
     password_expired: N
4 rows in set (0.00 sec)

Saya menyertakan pengguna root di antara nama peran untuk pemeriksaan predikat IN() untuk menunjukkan bahwa ia memiliki otentikasi_string, sedangkan peran tidak.

Bagian ini dalam dokumentasi CREATE ROLE menjelaskannya dengan baik:"Peran saat dibuat terkunci, tidak memiliki kata sandi, dan diberikan plugin otentikasi default. (Atribut peran ini dapat diubah nanti dengan pernyataan ALTER USER, oleh pengguna yang memiliki hak istimewa BUAT PENGGUNA global.)"

Kembali ke tugas yang ada, sekarang kita dapat menetapkan peran kepada pengguna berdasarkan tingkat hak istimewa yang mereka butuhkan.

Perhatikan tidak ada klausa ON dalam perintah:

mysql> GRANT 'main_read_only' TO 'reader_1'@'localhost', 'reader_2'@'localhost', 'reader_3'@'localhost';
Query OK, 0 rows affected (0.13 sec)

mysql> GRANT 'main_read_write' TO 'reader_writer'@'localhost';
Query OK, 0 rows affected (0.16 sec)

mysql> GRANT 'main_changer', 'main_read_only' TO 'changer_1'@'localhost';
Query OK, 0 rows affected (0.13 sec)

Mungkin tidak terlalu membingungkan jika Anda menggunakan semacam 'konvensi penamaan ' ketika membuat nama peran, (saya tidak tahu apakah MySQL menyediakannya saat ini… Komunitas?) jika tidak ada alasan lain selain untuk membedakan antara mereka dan pengguna 'non-peran' biasa secara visual.

Masih Ada Beberapa Pekerjaan Yang Harus Dilakukan

Itu sangat mudah bukan?

Kurang berlebihan dari cara lama pemberian hak istimewa.

Mari kita gunakan pengguna tersebut untuk bekerja sekarang.

Kita dapat melihat hak istimewa yang diberikan untuk pengguna dengan sintaks SHOW GRANTS. Inilah yang saat ini ditetapkan ke akun pengguna reader_1:

mysql> SHOW GRANTS FOR 'reader_1'@'localhost';
+------------------------------------------------------+
| Grants for [email protected]                        |
+------------------------------------------------------+
| GRANT USAGE ON *.* TO `reader_1`@`localhost`         |
| GRANT `main_read_only`@`%` TO `reader_1`@`localhost` |
+------------------------------------------------------+
2 rows in set (0.02 sec)

Meskipun itu memberikan hasil yang informatif, Anda dapat 'menyetel ' pernyataan untuk informasi yang lebih terperinci tentang hak istimewa apa pun yang diberikan oleh peran yang diberikan dengan menyertakan klausa USING dalam pernyataan SHOW GRANTS dan memberi nama nama peran yang ditetapkan:

mysql> SHOW GRANTS FOR 'reader_1'@'localhost' USING 'main_read_only';
+-------------------------------------------------------------+
| Grants for [email protected]                               |
+-------------------------------------------------------------+
| GRANT USAGE ON *.* TO `reader_1`@`localhost`                |
| GRANT SELECT ON `practice`.`name` TO `reader_1`@`localhost` |
| GRANT `main_read_only`@`%` TO `reader_1`@`localhost`        |
+-------------------------------------------------------------+
3 rows in set (0.00 sec)

Setelah masuk dengan reader_1:

mysql> SELECT * FROM practice.name;
ERROR 1142 (42000): SELECT command denied to user 'reader_1'@'localhost' for table 'name'

Apa di bumi? Pengguna tersebut diberikan hak istimewa SELECT melalui peran main_read_only.

Untuk menyelidiki, mari kunjungi 2 tabel baru di versi 8, khusus untuk peran.

Tabel mysql.role_edges menunjukkan peran apa yang telah diberikan kepada pengguna mana pun:

mysql> SELECT * FROM mysql.role_edges;
+-----------+-----------------+-----------+---------------+-------------------+
| FROM_HOST | FROM_USER       | TO_HOST   | TO_USER       | WITH_ADMIN_OPTION |
+-----------+-----------------+-----------+---------------+-------------------+
| %         | main_changer    | localhost | changer_1     | N                 |
| %         | main_read_only  | localhost | changer_1     | N                 |
| %         | main_read_only  | localhost | reader_1      | N                 |
| %         | main_read_only  | localhost | reader_2      | N                 |
| %         | main_read_only  | localhost | reader_3      | N                 |
| %         | main_read_write | localhost | reader_writer | N                 |
+-----------+-----------------+-----------+---------------+-------------------+
6 rows in set (0.00 sec)

Tapi, saya merasa tabel tambahan lainnya, mysql.default_roles, akan lebih membantu kami memecahkan masalah SELECT untuk pembaca pengguna_1:

mysql> DESC mysql.default_roles;
+-------------------+----------+------+-----+---------+-------+
| Field             | Type     | Null | Key | Default | Extra |
+-------------------+----------+------+-----+---------+-------+
| HOST              | char(60) | NO   | PRI |         |       |
| USER              | char(32) | NO   | PRI |         |       |
| DEFAULT_ROLE_HOST | char(60) | NO   | PRI | %       |       |
| DEFAULT_ROLE_USER | char(32) | NO   | PRI |         |       |
+-------------------+----------+------+-----+---------+-------+
4 rows in set (0.00 sec)

mysql> SELECT * FROM mysql.default_roles;
Empty set (0.00 sec)

Kumpulan hasil kosong.

Ternyata, agar pengguna dapat menggunakan peran - dan akhirnya hak istimewa - pengguna harus diberi peran default.

mysql> SET DEFAULT ROLE main_read_only TO 'reader_1'@'localhost', 'reader_2'@'localhost', 'reader_3'@'localhost';
Query OK, 0 rows affected (0.11 sec)

(Peran default dapat ditetapkan ke beberapa pengguna dalam satu perintah seperti di atas…)

mysql> SET DEFAULT ROLE main_read_only, main_changer TO 'changer_1'@'localhost';
Query OK, 0 rows affected (0.10 sec)

(Pengguna dapat memiliki beberapa peran default yang ditentukan seperti dalam kasus untuk user changer_1…)

Pembaca pengguna_1 sekarang telah masuk...

mysql> SELECT CURRENT_USER();
+--------------------+
| CURRENT_USER()     |
+--------------------+
| [email protected] |
+--------------------+
1 row in set (0.00 sec)

mysql> SELECT CURRENT_ROLE();
+----------------------+
| CURRENT_ROLE()       |
+----------------------+
| `main_read_only`@`%` |
+----------------------+
1 row in set (0.03 sec)

Kita dapat melihat peran aktif saat ini dan juga, bahwa reader_1 dapat mengeluarkan perintah SELECT sekarang:

mysql> SELECT * FROM practice.name;
+--------+------------+
| f_name | l_name     |
+--------+------------+
| Jim    | Dandy      |
| Johhny | Applesauce |
| Ashley | Zerro      |
| Ashton | Zerra      |
| Ashmon | Zerro      |
+--------+------------+
5 rows in set (0.00 sec)

Nuansa Tersembunyi Lainnya

Ada bagian penting lain dari teka-teki kita perlu mengerti.

Ada kemungkinan 3 'tingkat' atau 'varian' penetapan peran yang berbeda:

SET ROLE …;
SET DEFAULT ROLE …;
SET ROLE DEFAULT …;

Saya akan MEMBERIKAN peran tambahan kepada pembaca pengguna_1 dan kemudian masuk dengan pengguna itu (tidak ditampilkan):

mysql> GRANT 'main_read_write' TO 'reader_1'@'localhost';
Query OK, 0 rows affected (0.17 sec)

Karena role main_read_write memang memiliki hak istimewa INSERT, user reader_1 sekarang dapat menjalankan perintah itu kan?

mysql> INSERT INTO name(f_name, l_name)
    -> VALUES('Josh', 'Otwell');
ERROR 1142 (42000): INSERT command denied to user 'reader_1'@'localhost' for table 'name'

Apa yang terjadi di sini?

Ini mungkin membantu...

mysql> SELECT CURRENT_ROLE();
+----------------------+
| CURRENT_ROLE()       |
+----------------------+
| `main_read_only`@`%` |
+----------------------+
1 row in set (0.00 sec)

Ingat, kami awalnya menetapkan pembaca pengguna_1 sebagai peran default main_read_only. Di sinilah kita perlu menggunakan salah satu 'tingkat' yang berbeda dari apa yang saya istilahkan secara longgar 'pengaturan peran':

mysql> SET ROLE main_read_write;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT CURRENT_ROLE();
+-----------------------+
| CURRENT_ROLE()        |
+-----------------------+
| `main_read_write`@`%` |
+-----------------------+
1 row in set (0.00 sec)

Sekarang coba INSERT itu lagi:

mysql> INSERT INTO name(f_name, l_name)
    -> VALUES('Josh', 'Otwell');
Query OK, 1 row affected (0.12 sec)

Namun, setelah user reader_1 logout kembali, peran main_read_write tidak akan lagi aktif saat reader_1 login kembali. Meskipun user reader_1 memiliki peran main_read_write yang diberikan, itu bukan default.

Sekarang mari kita mengenal 'tingkat' ke-3 dari 'pengaturan peran', SET ROLE DEFAULT.

Misalkan user reader_1 belum memiliki peran yang ditetapkan:

mysql> SHOW GRANTS FOR 'reader_1'@'localhost';
+----------------------------------------------+
| Grants for [email protected]                |
+----------------------------------------------+
| GRANT USAGE ON *.* TO `reader_1`@`localhost` |
+----------------------------------------------+
1 row in set (0.00 sec)

Mari BERIKAN peran 2 pengguna ini:

mysql> GRANT 'main_changer', 'main_read_write' TO 'reader_1'@'localhost';
Query OK, 0 rows affected (0.07 sec)

Tetapkan peran default:

mysql> SET DEFAULT ROLE ‘main_changer’ TO 'reader_1'@'localhost';
Query OK, 0 rows affected (0.17 sec)

Kemudian dengan user reader_1 masuk, peran default itu aktif:

mysql> SELECT CURRENT_ROLE();
+--------------------+
| CURRENT_ROLE()     |
+--------------------+
| `main_changer`@`%` |
+--------------------+
1 row in set (0.00 sec)

Sekarang beralih ke peran main_read_write:

mysql> SET ROLE 'main_read_write';
Query OK, 0 rows affected (0.01 sec)

mysql> SELECT CURRENT_ROLE();
+-----------------------+
| CURRENT_ROLE()        |
+-----------------------+
| `main_read_write`@`%` |
+-----------------------+
1 row in set (0.00 sec)

Namun, untuk kembali ke peran default yang ditetapkan, gunakan SET ROLE DEFAULT seperti yang ditunjukkan di bawah ini:

mysql> SET ROLE DEFAULT;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT CURRENT_ROLE();
+--------------------+
| CURRENT_ROLE()     |
+--------------------+
| `main_changer`@`%` |
+--------------------+
1 row in set (0.00 sec)

Peran Tidak Diberikan

Meskipun user changer_1 memiliki 2 peran yang tersedia selama sesi:

mysql> SELECT CURRENT_ROLE();
+-----------------------------------------+
| CURRENT_ROLE()                          |
+-----------------------------------------+
| `main_changer`@`%`,`main_read_only`@`%` |
+-----------------------------------------+
1 row in set (0.00 sec)

Apa yang terjadi jika Anda mencoba dan menetapkan pengguna ke peran yang belum diberikan kepada mereka?

mysql> SET ROLE main_read_write;
ERROR 3530 (HY000): `main_read_write`@`%` is not granted to `changer_1`@`localhost`

Ditolak.

Bawa Pulang

Tidak ada sistem manajemen pengguna yang lengkap tanpa kemampuan untuk membatasi atau bahkan menghapus akses ke operasi tertentu jika diperlukan.

Kami memiliki perintah SQL REVOKE untuk menghapus hak istimewa dari pengguna dan peran.

Ingat bahwa peran main_changer memiliki serangkaian hak istimewa ini, pada dasarnya, semua pengguna yang diberikan peran ini juga memiliki:

mysql> SHOW GRANTS FOR main_changer;
+-----------------------------------------------------------------+
| Grants for [email protected]%                                       |
+-----------------------------------------------------------------+
| GRANT USAGE ON *.* TO `main_changer`@`%`                        |
| GRANT UPDATE, DELETE ON `practice`.`name` TO `main_changer`@`%` |
+-----------------------------------------------------------------+
2 rows in set (0.00 sec)

mysql> REVOKE DELETE ON practice.name FROM 'main_changer';
Query OK, 0 rows affected (0.11 sec)

mysql> SHOW GRANTS FOR main_changer;
+---------------------------------------------------------+
| Grants for [email protected]%                               |
+---------------------------------------------------------+
| GRANT USAGE ON *.* TO `main_changer`@`%`                |
| GRANT UPDATE ON `practice`.`name` TO `main_changer`@`%` |
+---------------------------------------------------------+
2 rows in set (0.00 sec)

Untuk mengetahui pengguna mana yang terpengaruh oleh perubahan ini, kita dapat mengunjungi tabel mysql.role_edges lagi:

mysql> SELECT * FROM mysql.role_edges WHERE FROM_USER = 'main_changer';
+-----------+--------------+-----------+-----------+-------------------+
| FROM_HOST | FROM_USER    | TO_HOST   | TO_USER   | WITH_ADMIN_OPTION |
+-----------+--------------+-----------+-----------+-------------------+
| %         | main_changer | localhost | changer_1 | N                 |
+-----------+--------------+-----------+-----------+-------------------+
1 row in set (0.00 sec)

Dan kita dapat melihat bahwa user changer_1 tidak lagi memiliki hak DELETE:

mysql> SHOW GRANTS FOR 'changer_1'@'localhost' USING 'main_changer';
+--------------------------------------------------------------------------+
| Grants for [email protected]                                           |
+--------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `changer_1`@`localhost`                            |
| GRANT UPDATE ON `practice`.`name` TO `changer_1`@`localhost`             |
| GRANT `main_changer`@`%`,`main_read_only`@`%` TO `changer_1`@`localhost` |
+--------------------------------------------------------------------------+
3 rows in set (0.00 sec)

Terakhir, jika kita perlu menyingkirkan peran sepenuhnya, kita memiliki perintah DROP ROLE untuk itu:

mysql> DROP ROLE main_read_only;
Query OK, 0 rows affected (0.17 sec)

Dan menanyakan tabel mysql.role_edges, role main_read_only telah dihapus:

mysql> SELECT * FROM mysql.role_edges;
+-----------+-----------------+-----------+---------------+-------------------+
| FROM_HOST | FROM_USER       | TO_HOST   | TO_USER       | WITH_ADMIN_OPTION |
+-----------+-----------------+-----------+---------------+-------------------+
| %         | main_changer    | localhost | changer_1     | N                 |
| %         | main_read_write | localhost | reader_1      | N                 |
| %         | main_read_write | localhost | reader_writer | N                 |
+-----------+-----------------+-----------+---------------+-------------------+
3 rows in set (0.00 sec)

(Bonus:Video YouTube yang fantastis ini adalah sumber pembelajaran yang bagus bagi saya di Roles.)

Contoh pembuatan pengguna, penetapan peran, dan penyiapan ini sangat sederhana. Namun, peran memiliki seperangkat aturan sendiri yang membuatnya jauh dari sepele. Harapan saya adalah bahwa melalui posting blog ini, saya telah menjelaskan area-area yang kurang intuitif daripada yang lain, memungkinkan pembaca untuk lebih memahami potensi penggunaan peran dalam sistem mereka.

Terima kasih telah membaca.