The field of information system engineering has relatively high requirements for data security. The MySQL database management system is widely used in the development of various information system application software, and the design of roles and permissions is not only related to the performance of data confidentiality in the database, but also related to the performance of users. Minimum requirements for using the database. When designing the security of the database, in order to ensure the security and reliability of the data, it is proposed to achieve safe access to the data by setting roles and permissions, and then conduct experiments by writing codes to verify that this method solves the data security problem in the database effectiveness.
Table of contents
1 Permission table for storing user accounts
2 Account and account authority design
2.1 Log in to the MySQL database from the Windows command line
2.2 Create a user and grant permissions
In today's era of big data, all walks of life are inseparable from computer information technology, especially the use of information system application software to process business, and a large amount of data will be stored in the background of the system, which also makes data more and more important, and as data The database management system, one of the main storages of the database, has assumed an important role in protecting data. In the process of developing the information system, the security design of the data in the database must be paid attention to, in order to improve the security of the data.
At present, the mainstream database management systems include Oracle, SQL Server, MySQL, etc. Any database must consider the design of data security. This article takes MySQL database management system as an example to discuss data security. One of the security issues refers to the Moderately sensitive data is queried by multiple legitimate users, and leaks or malicious tampering occur during use. Database administrators need to track and be familiar with which users have accessed the data, as well as the access rights and operations of these users, so as to resolve related accident responsibilities.
There are basically confidentiality requirements for the key data stored in the database, that is, restricting some users from accessing the data, and also restricting the user's access rights during the access process. Different users have different roles according to their roles. Administrators need to set different access rights to ensure the security of data in the database.
1 Permission table for storing user accounts
In order to facilitate the administrator to manage users, it is necessary to set accounts and access rights for many users. At the same time, for the convenience of management, the database management system has set up important tables to store accounts and permissions. There are mainly 4 tables related to users and permissions in the MySQL database , namely the user table, db table, tables_priv table, and columns_priv table.
The user table is the most important table, which contains a total of 42 fields in four categories: user, authority, security, and resource control. The user includes user name, host name, and password. There are 29 permissions in total, ending with _priv, such as update_priv and so on. For the user table, global-level permissions are stored in it.
The db table is one of the very important tables, which stores the operation authority of one or some databases specified for the user. Only the username, hostname and permissions are stored. For the db table, database-level permissions are stored inside.
The tables_priv table is used to store the user and user permission information of one table or multiple tables under the fixed database.
The columns_priv table is used to store the user and user permission information of one or more columns of the fixed table under the fixed database.
All four tables store users and permissions, and the specific differences are shown in Table 1.
2 Account and account authority design
Under the MySQL database management system, account creation and verification are different from other database management systems. In a stand-alone system, in order to be able to verify, when designing the database, you need to log in under the Windows command line to be able to verify.
2.1 Log in to the MySQL database from the Windows command line
The login process is as follows: Start—Run—enter cmd to enter the Windows command line—enter parameters, that is, the login command (MySQL–u username–h hostname–p password), the first login requires super administrator root to create a user account user to log in.
Note: If you execute the login command, you must switch to the bin directory of the MySQL installation file, because many users do not configure the path variable when installing MySQL. At this time, the Windows command line cannot recognize the name, so it cannot be executed. For example, C:\Users\Administrator>mysql -u root -hlocalhost–p, the error message: "mysql" is not an internal or external command, nor is it an operable program or batch file.
In addition, if the MySQL server is not enabled, the command will also be displayed as invalid, so it is also necessary to ensure that the database server is enabled. The following is a super administrator to enter the MySQL database management system. When creating a user for the first time, only the root super administrator has the authority to create other users. Enter the password to log in to the MySQL database command line. The login process is shown in Figure 1.
Enter the password to enter the MySQL command line. The code is:
c:\wamp\bin\mysql\mysql5.5.24\bin>mysql -u root -hlocalhost -p
Enter password:-- Enter the password here, and the MySQL welcome interface and the time spent on connection will appear later.
mysql>-- This command character finally appears, and the cursor will stay behind mysql>, waiting for the input command.
2.2 Create a user and grant permissions
Under the MySQL database management system, create a database b and a database here, create a data table book under the database b, and design an integer field bid in the book data table to represent the book number, you can enter a record as 1, For verification, create a book2 data table. The fields and records can be designed freely. Here, a simple data table is used to show the
process of creating user accounts and granting permissions. Part of the code is:
Create database a;
Create database b;
create table book(bidint);
insert into book values(1);
create table book2(bidint,bname char(4));
The first user a1 is designed below, the password is: test1, the authority of this user is designed to only operate database b, and the code is designed in the following format, that is, use grant to create a new user and grant permissions. Grammatical rules: Grant permission type on database .Data table to username@hostname identifiedby password[,user@host identified by password][with grantoption]. Note: The permission type indicates the type of permission granted to the user (for example: select, alter, reload, excute, event, etc.), the database. The data table represents the level of permission, a * represents all tables in the current database, and *.* represents all databases All tables under db_name.* represent all tables in the fixed database, db_name.tbl_name represents the fixed tables and views in the fixed database, db_name.routine_name represents the fixed stored procedures and functions in the fixed database, user@host represents the user name and host name, password represents the password, and [with grant option]] represents that the user can grant permissions to other users, and other commands are fixed. This code is:
grant all on b.* to'a1'@'localhost'identified by'test1';
The specific code, that is, the execution process, is shown in Figure 2.
The second user a2 is designed below, the password is: test2, and the design authority is to only view the book table under database b. This code is:
grant select on b.book to'a2'@'localhost'identified by'test2';
The specific code, that is, the execution process, is shown in Figure 3.
