[Database Principle] Overview of Database Security

Database security.

In order to adapt to and meet the data sharing environment and requirements, the DBMS must ensure the normal operation of the entire system, prevent data leakage, malicious modification, inconsistency, and timely recovery after problems occur, requiring a complete set of effective protection measures. The protection function of DBMS for data security includes the following 4 aspects:

• Security control
• Integrity control
• Concurrency control
• Database recovery

1. Security control.

5 major methods:

• User identification and authentication
• User access control
• Define view
• data encryption
• Data audit

1.1 User identification and authentication.

• The system provides a certain way for users to identify their own name or identity, and the system records the identification of all legal users.
• Every time a user requests to enter the system, the system will verify it, and the right to use the machine will only be provided after passing the authentication.

However, the method of user identification also has some problems:

• The user identifier is a public identifier of the user, and it is not enough to be a credential to identify the user.
• The method of authenticating users through user names and passwords is simple and easy to implement, but the generation and use of user names and passwords are relatively simple and easy to be stolen, so more complex methods can be used.

1.2 User access authority control.

• User access rights refer to the operation rights that different users are allowed to perform for different data objects. In a database system, defining user access rights is called authorization. These authorization definitions are compiled and stored in the data dictionary DD in the form of an authorization table.

• For the use of authorization, an important indicator to measure the authorization mechanism is authorization granularity, that is, the range of data objects that can be defined. In a relational database, authorization granularity includes relationships, records, or attributes.
• The finer the authorization granularity, the more flexible the authorization subsystem and the more complete the security it can provide.

1.3 Define the view.

• Define different views for different users, you can limit the scope of each user's access.
• The view is logical, and its modification operations will be restricted.

1.4 Data encryption.

The basic idea of ​​encryption is to encrypt the original data into an unrecognizable format according to a certain algorithm, and the data is stored and transmitted in the form of ciphertext. The basic implementation methods are divided into the following two categories. Usually, a combination of these two methods can achieve a high degree of security. :

• Replacement method, which uses a key to convert each character in the plain text to a character in the cipher text.
• Conversion method, which rearranges the characters in the plaintext in a different order.

1.5 Data audit.

• The audit function is a monitoring measure that tracks and records access activities related to data.
• The audit trail automatically records all user operations on the database and stores it in a special file, the audit log.
• The recorded content generally includes: operation type (such as modification, query, etc.), operation terminal identification and operator identification, operation date and time, relevant data involved in the operation (such as basic tables, views, records, attributes, etc.), data The front image and the back image etc.

2. Integrity control.

Integrity control means to ensure the correctness, validity and compatibility of data in the database. On the basis of security, integrity can be understood as:

• Prevent legitimate users from adding non-semantic data to the database when using the database.
• The object of integrity measures is non-semantic data.

2.1 Rule.

• Rule (Rule) is the database's provisions and restrictions on the values ​​stored in the table columns or user-defined data types.
• The rule and the table or user-defined data type it acts on are independent of each other, that is, the deletion or modification of the table or user-defined object will not affect the rules connected to it.
• Rules and constraints can be used at the same time, the column of the table can have one rule and multiple check constraints.
• SQL provides statements CREATE RULEto create rules, and the syntax format is as follows:

CREATE RULE NAME_OF_RULE 
AS CONDITION_EXPRESSION

[Example] Create a student age rule: the student’s age is within the closed interval of [18,50].

CREATE RULE age_rule
AS @age＞=18and @age＜=50

• After the rule is created, the rule is just an object that exists in the database and has no effect. It is necessary to associate rules with database tables or user-defined objects to achieve the purpose of creating rules.
• After the rule is created, it needs to be bound to the database object to play the role of integrity control. When we do not want the rule to take effect, we must loosen the bound rule. The two operations are stored sp_bindruleand sp_unbindrulecompleted by the system in SQL Server. . The syntax format is as follows:

sp_bindrule 'NAME_OF_RULE','NAME_OF_OBJECT'

sp_unbindrule 'NAME_OF_OBJECT'

[Example] Bind the rule age_rule to the field Age of the S table.

EXEC sp_bindrule 'age_rule', 'S.Age'

[Example] Cancel the age_rule rule that has been bound to the field Age of the S table.

EXEC sp_unbindrule 'S.Age'

• note! The rules have no effect on the data that already exists in the table, but only restrict the data that is subsequently modified and inserted.
• Delete a rule usage statement DROP RULE NAME_OF_RULE, but note that you must unbind the object bound to it before deleting a rule.

[Example] Delete age_rule rule.

DROP RULE age_rule

2.2 Default.

• Default is the data automatically inserted in the column for which no specific data is specified when entering the record to the user.
• A column of the table or a user-defined data type can only be bound to one default.
• SQL provides statements CREATE DEFAULTto create defaults, and its syntax format is as follows:

CREATE DEFAULT NAME_OF_DEFAULT
AS CONSTANT

[Example] Create birthday_defa by default.

CREATE DEFAULT birthday_defa
AS '1978-1-1'

• Use system procedures sp_helptext NAME_OF_DEFAULTto view information about a default object.

[Example] View the default birthday_defa.

EXEC sp_helptext birthday_defa

• Like the rule Rule, the default Default also needs to be bound to the object to take effect. We can also unbind it when we don't need it. The corresponding operations are stored by the system sp_bindefaultand sp_unbindefaultthe syntax format is as follows:

sp_bindefault 'NAME_OF_DEFAULT','NAME_OF_OBJECT'

sp_unbindefault 'NAME_OF_OBJECT'

[Example] Bind the default birthday_defa to the Birthday column of the data table S.

EXEC sp_bindefault birthday_defa,'S.Birthday'

[Example] Unbind the default birthday_defa with the Birthday column of table S.

EXEC sp_unbindefault 'S.Birthday'

• Deleting a default usage statement is DROP DEFAULT NAME_OF_DEFAULTimplemented, just like the rule, the object bound to it must be unbound before deleting a default.

[Example] Delete the default birthday_defa of the student's birthday.

DROP DEFAULT birthday_defa

3. Concurrency control.

• Multiple users access the database at the same time, if concurrent operations are not controlled, incorrect data may be generated and the integrity of the data may be damaged.
• Concurrency control is to solve this type of problem to maintain the consistency of the data in the database, that is, the database will provide data to users in the same form at any time.

3.1 Transaction

• A transaction is a unit of work performed in the database system, which is a set of operation sequences defined by the user. A transaction can be a set of SQL statements, a SQL statement or the entire program, and an application can include multiple transactions.
• There are three statements that define a transaction: ① BEGIN TRANSACTIONthe beginning of the COMMITtransaction ; ② the commit of the ROLLBACKtransaction ; ③ the rollback of the transaction.
• The 4 properties of transactions: Atomicity, Consistency, Isolation and Durability.
• [Atomicity] A transaction is an indivisible unit of work. When a transaction is executed, it should follow the "Nothing or All" principle, that is, it is not allowed to complete part of the transaction.
• [Consistency] The effect of transactions on the database is that the database changes from one consistent state to another consistent state. The so-called consistent state of the database means that the data in the database meets the integrity constraints.
• [Isolation] If multiple transactions are executed concurrently, it should be the same as the independent execution of each transaction. The execution of one transaction cannot be interfered by other transactions.
• [Persistence] Persistence means that once a transaction is committed, its changes to the data in the database should be persistent. Even if the database is damaged due to a failure, the DBMS should be able to recover.
• There are three main database inconsistencies caused by concurrent database operations: ①Lost Update; ②Dirty Read; ③Unrepeatable Read.

[Example] Lost update

when two transactions $T_1$And $T_2$When reading the same data and concurrently executing modification operations, $T_2$Put $T_1$Or $T_1$Put $T_2$The result of the modification is overwritten, causing data loss and updating, resulting in data inconsistency.

[Example] Poor reading

transaction $T_1$Updated data R, transaction $T_2$Read the updated data R, transaction $T_1$It is revoked for some reason, the modification is invalid, and the data R is restored to its original value. Transaction $T_2$The data obtained is inconsistent with the content of the database. This situation is called "dirty reading".

[Example] Non-rereadable

transaction $T_1$Read data R, transaction $T_2$Read and update data R, when transaction $T_1$When the data R is read again for verification, the two read values ​​obtained are inconsistent, which is called "non-rereadable".

3.2 Blocking agreement.

• There are two main ways to achieve concurrency control: Lock technology and Timestamping technology, focusing on the lock technology.
• The so-called blockade is when a transaction must obtain a corresponding lock before operating on a data object (which can be a data item, record, data set, or even the entire database) to ensure the correctness and consistency of the data operation. After exposure to multiple threads and concurrent programming, you will have a deeper understanding of this concept.
• There are two basic types of lockouts: Exclusive Lock and Share Lock. The former is also called write blockade, or X blockade for short. It uses the principle of prohibiting concurrent operations ; the latter is also called read blockade, or S lock for short. It uses the principle to allow other users to query the same data object , but not The data object is modified .
• [Lock Protocol] Locking can ensure reasonable concurrency control and ensure data consistency. When blocking, we must consider certain blocking rules, such as when to start blocking, how long the blocking, when to release, etc. These blocking rules are called blocking agreements.
• Blocking granularity refers to the unit of blockade. According to the different processing of data, the blocked objects can be such logical units: fields, records, tables, databases, etc. The size of the blocked data objects is called the blocking granularity. The smaller the blockade granularity, the more objects that can be blocked in the system, and the higher the concurrency, but the blockade mechanism is complex and the system overhead is also greater. The larger the blocking granularity, the fewer objects that can be blocked in the system, the lower the concurrency, the simpler the blocking mechanism, and the smaller the corresponding system overhead.

3.2.1 The primary lockout agreement.

Transaction T must add X lock to the data object before modifying it until the end of the transaction.

3.2.2 Second-level blockade agreement.

On the basis of the first-level lockout protocol, transaction T must first lock the data R before reading it, and release the S lock after reading it.

3.2.3 Three-level lockout agreement.

On the basis of the first-level lockout protocol, transaction T must first add S lock to data R before reading it, and does not release S lock after reading it, but does not release until transaction T ends.

3.2.4 Problems caused by blockade.

• [Livelock Livelock] When a transaction requests exclusive blockade of a certain data, the transaction is in a permanent waiting state due to the operation of the data by other transactions. This state is called livelock, such as the following transaction $T_2$:
  
• [Deadlock] In two or more transactions that are in a waiting state at the same time, each of them is waiting for some data before it can proceed, and this data has been blocked by one of them. This state is called a deadlock.
  

3.2.5 Solution and prevention of Deadlock.

• [One-time lock method] Lock all resources at one time, if one resource cannot be locked, wait.
• [Sequential locking method] Specify the sequence number of the resource, and lock according to the sequence number.
• [Transaction dependency graph] If there is a cycle along the arrow direction in the transaction dependency graph, then a deadlock condition is formed and the system will deadlock. Choose a transaction with the least cost to deal with the deadlock and cancel it to remove the deadlock. There is a special chapter about deadlock in the operating system principle, which can be viewed.
  

4. Database recovery.

• The DBMS must have the function of detecting failures and restoring data from an error state to a correct state. This is database recovery.
• The basic principle of database recovery is to use data redundancy. Damaged or erroneous data can be repaired using redundant data stored elsewhere. Therefore, the recovery system should have the two functions of preparing redundant data and rebuilding the database based on the redundant data.
• Two common techniques for preparing redundant data are log file registration and data dumping, which are often used in combination.

4.1 Log file

• Update the transaction ID of the database (indicate which transaction)
• Type of operation (insert, delete or modify)
• Operation object
• The old value of the data before the update (for insert operations, there is no old value)
• The new value of the updated data (for the delete operation, there is no new value)
• All key moments in transaction processing (transaction start, end and true write-back time)
• [Write first principle] All operations (undo, redo, update, query) and other content are written to the log first, and then the transaction is executed in the database.

4.2 Data dump.

• Periodically copy the database to multiple storage devices (such as tapes, disks).
• Storage method: Mass dump and incremental dump.
• Storage operation mode: static dump and dynamic dump.
• Storage location: same city and different place.

4.3 Database failure.

• [Transaction Failure Transaction Failure] The failure caused by the abnormal end of the program, you can reverse scan the log file to find the update operation of the transaction, and then perform the reverse operation on the update operation of the transaction.
• [System Failure] During the operation process, due to some reason, the system stops functioning, causing all running transactions to terminate abnormally, requiring the system to restart. The recovery method is to find the transaction that has not yet been committed, and record its transaction ID in the undo queue . At the same time, it finds the transaction that has been committed, and records its transaction ID in the redo queue . Perform undo processing on each transaction in the undo queue; redo each transaction in the redo queue.
• [Media Failure] The storage medium is damaged, causing partial or complete loss of data stored in the external storage. The recovery method is: load the latest dump, load the latest log file copy, find out the transaction that has been committed before the failure, and record it in the redo queue. Then redo each transaction in the redo queue.