GA/T 389-2002 Technical requirements for computer information system security level protection database management system
Some standard content:
ICS_35.020
People's Republic of China Public Security Industry Standard GA/T389--2002
20022166
Computer Information System Security Level Protection
Database Management System Technology Requirementin Computer Information System Classified Security ProtectionQ
2002- 07 - 15 Issued
Issued by the Ministry of Public Security of the People's Republic of China
2002-07-15Implementation
Normative reference documents
Terms and definitions
Technical requirements for database management system security
4.1 Identity authentication
4.1.1 User identification
4.1.2 User authentication
4.2 Discretionary access control
Access operations
Access rules
Authorization propagation restrictions
Tags and mandatory access control
Mandatory access control
Access control granularity and characteristics
Object reuse
Database security audit
Data integrity
Entity integrity and referential integrityWww.bzxZ.net
User-defined integrity
Integrity of data operations
Covered channel analysis
4.8 Trusted path
4.9 Trusted database recovery
Inference control·
5 Technical requirements for security level division
5.1 Level 1: User autonomous protection level
5.1.1 Security function
TCB own security protection
TCB design and implementation
5.1.4TCB security management
5.2 Level 2: System audit protection level·
Security function
TCB own security protection
TCB design and implementation
..........
......
........
GA/T 389—2002
GA/T389—2002
5.2.4TCB security management
5.3Level 3: Security mark protection level
Security function·
TCB’s own security protection
TCB design and implementation
5.3.4TCB security management
5.4Level 4: Structured protection level
5.4． Security function…
TCB’s own security protection
TCB design and implementation
TCB security management requirements
5.5 Level 5: Access verification protection level
Security function·
TCB’s own security protection
TCB design and implementation
TCB security management
Appendix A (informative) Description of standard concepts A.1
Composition and mutual relationship
Special requirements for database management system security User management of database management system
Security of database management system
Data Classification of security levels of database management systems About subjects and objects in database management systems A:6
About TCB, TSF and TSPA in database management systems.8
About reasoning control
About cryptographic technology and database encryption
References
Check the standard on wiz321.net
GA/T389-2002
GB17859-1999 "Guidelines for Classification of Security Protection Levels of Computer Information Systems" is an important standard for the management of security levels of computer information systems in my country, which was issued on September 13, 1999. In order to promote the normal and orderly development of security level management, a series of relevant standards are formulated, including:
Technical requirements for security level protection of computer information systems series standards; - Management requirements for security level protection of computer information systems; - Implementation requirements for security level protection projects of computer information systems; - Evaluation standards for security level protection of computer information systems series standards. Among them, the computer information system security level protection technical requirements series standards are composed of the following standards and other related standards: GA/T390-2002 General technical requirements for computer information system security level protection; GA/T387-2002 Technical requirements for computer information system security level protection network system; GA/T388--2002 Technical requirements for computer information system security level protection operating system; GA/T389-2002 Technical requirements for computer information system security level protection database management system. This standard is the fourth item in the computer information system security level protection technical requirements series standards. Appendix A of this standard is an informative appendix.
This standard is proposed by the Public Information Network Security Supervision Bureau of the Ministry of Public Security of the People's Republic of China. .This standard is under the jurisdiction of the Information System Security Standardization Technical Committee of the Ministry of Public Security. The drafting unit of this standard: Jiangnan Institute of Computing Technology. The main drafters of this standard: Ji Zengrui, Lu Hua, Sun Wei, Xu Lianghua, Yuan Zhiping. Check the standard on the construction standard website wwwiz321.net
GA/T389-2002
This standard is an important part of the series of standards for technical requirements for computer information system security level protection. It is used to guide designers on how to design and implement database management systems with the required security level. It mainly explains its technical requirements from the perspective of dividing the security protection level of the database management system, that is, it mainly explains the security technical measures that should be taken for the database management system to achieve the security requirements of each protection level in GB17859-1999, as well as the differences in the specific implementation of each security technical requirement in different security levels. This standard describes the security function technical requirements and security assurance technical requirements for each security level in detail according to the five security levels of GB17859-1999. The explanation of the relevant concepts in this standard is shown in Appendix A. The main documents referenced by this standard have been included in the references.
Check the standard on wwwiz321.net
1 Scope
Security level protection of computer information system
Technical requirements for database management system
GA/T389—2002
This standard specifies the detailed technical requirements for the classification of security protection levels of database management system in accordance with GB17859-1999.
This standard applies to the design and implementation of database management system in accordance with the security level protection requirements of GB17859-1999. It can also be used as a reference for the testing and management of database management system in accordance with the security level protection requirements of GB17859--1999. 2 Normative references
The clauses in the following documents become the clauses of this standard through reference in this standard. For all dated referenced documents, all subsequent amendments (excluding errata) or revisions are not applicable to this standard. However, parties to an agreement based on this standard are encouraged to study whether the latest versions of these documents can be used. For any undated referenced documents, the latest version shall apply to this standard. GB17859-1999 Computer Information System Security Level Classification Criteria GA/T390-2002 General Technical Requirements for Computer Information System Security Level Protection 3 Terms and Definitions
The following terms and definitions established by GB17859-1999 and GA/T390-2002 shall apply to this standard. 3.1
Entity Integrity
The entity integrity rule requires that any entity represented in the database is distinguishable. For the relational model, entity integrity is manifested in that the primary attributes (primary key, primary code) of the relationship cannot be null values (NULL) or duplicate values, that is, each component of the basic key cannot be null. Because in a relational database, the basic key uniquely identifies each entity. If the basic key is null, it means that the entity has no definite mark and cannot be distinguished from other entities. In the case where the basic key is a joint key, if a component of its value is null, it means that the value of a certain attribute of the entity is unknown and cannot be distinguished from other entities. 3.2
Referential integrityreferenceintegrityIn the relational model, referential integrity means that at any time, if some attributes of relation R1 are foreign keys of relation R2, the value of the foreign key must be the primary key value of a tuple in R2 or a "null value". Null value means "unknown" information and "meaningless" information (it is not an empty string or a space string, nor is it a zero value or any other numerical value). The referential integrity rules between relations are the premise for the correct execution of the "connection" relation operation.
User-defined integrityuserdefined integrity refers to the integrity constraints determined according to the application (such as the valid range of prices, etc.). The system provides a mechanism for defining and checking user-defined integrity rules. Its purpose is to be handled by the system in a unified way instead of by the application, which not only simplifies the application but also improves the reliability of integrity assurance. GA/T389--2002
4Technical requirements for database management system security
4.1 Identity authentication
4.1.1 User identification
Users registered in the database management system should be identified. User identification information is public information, generally implemented as user name and user ID. For the convenience of management, users can be grouped or aliases can be used. Regardless of user name, user ID, user group or user alias, the uniqueness principle of identification must be followed. User identification includes: a) Basic identification: The user who requested the action should be identified before TSF implements the required action. b) Unique identification: The uniqueness of the identified user should be ensured during the life cycle of the computer information system, and the user identification should be associated with the audit.
c) Identification information management: User identification information should be managed and maintained to ensure that it is not accessed, modified or deleted without authorization. 4.1.2 User authentication
The authenticity of the identity of the user who logs in to the database management system should be authenticated. By verifying the "authentication information" provided by the user, it is proved that the user does have the identity claimed. This "authentication information" must be confidential and not easy to forge. User authentication includes: a) Basic authentication: The user who requested the action should be successfully authenticated before TSF implements the required action. b) Unforgeable authentication: The use of forged or copied authentication data should be detected and prevented. On the one hand, the TSF is required to detect or prevent the authentication data forged by any other user, and on the other hand, the TSF is required to detect or prevent the use of authentication data copied by the current user from any other user.
c) One-time use authentication: The authentication mechanism that operates with one-time authentication data should be provided, that is, the TSF should prevent the reuse of authentication data related to the identified authentication mechanism. Multiple mechanism authentication: Different authentication mechanisms should be provided to authenticate the user identity of a specific event, and the TSF should authenticate the identity claimed by any user according to the rules of how multiple authentication mechanisms described in d)
provide authentication. Re-authentication: The event that requires re-authentication of the user should be able to be specified, that is, the TSF should re-authenticate the user under the conditions indicated in the table of conditions requiring re-authentication e)
. For example, after the user terminal operation timeout is disconnected, re-authentication is required when reconnecting. 4.2 Discretionary Access Control
4.2.1 Access operations
Should be defined by the database sublanguage and stored in the data dictionary together with the data. There should be clear permissions for any SQL object operation, and the permissions change with the operation and the object. The security system should be able to determine such permissions. The operation is closely linked to the object, that is, "operation + object" is regarded as an authorization. Table 1 lists the object types and related operations of the GRANT (authorization) statement. Table 1 Object types and related operation objects of the GRANT statement
Basic table
Character set
SQL call
SELECT, INSERT, UPDATE, DELETE, TRIGGER, REFERENCESSELECT, INSERT, UPDATE, DELETE, REFERENCESSELECT, INSERT, UPDATE, REFERENCESUSAGE
EXECUTE
In the table, except for USAGE and UNDER, the remaining operations conform to the verbs used in the SQL statement. 2
GA/T389-2002
4.2.2 Access rules
Should be expressed in the form of access control lists or access matrices and implemented by executing corresponding access control programs. Whenever SQL statements are executed and access requirements arise, the access requirements are controlled by calling corresponding access control programs. 4.2.3 Authorization propagation restrictions
Users with a certain permission should be restricted from passing the permission to other users. When a user is granted a certain permission and has the power to grant the permission to other users, the user has the right to propagate the authorization. In order to enhance the security of the database system, certain restrictions on authorization propagation are required.
4.3 Labeling and mandatory access control
4.3.1 Labeling
4.3.1.1 Subject labeling
TSF should assign sensitive labels to subjects. These sensitive labels are a combination of hierarchical classification and non-hierarchical classification, which are the basis for implementing mandatory access control.
4.3.1.2 Object Tagging
TSF shall assign sensitive tags to objects. These sensitive tags are a combination of hierarchical classification and non-hierarchical classification, and are the basis for implementing mandatory access control.
4.3.2 Mandatory Access Control
A certain security policy model shall be adopted to implement mandatory access control. The currently commonly used security policy model is the multi-level security model. This model sets sensitive tags for all subject and object components within the scope of TCB security control through tags. And read from the bottom and write from the top one by one according to the rules determined by the simple confidentiality principle, and implement mandatory control of each access between the subject and the object according to the sensitive tags of the accessor subject and the object being accessed. According to the different operating environments of the database management system, mandatory access control is divided into: a) A single database management system running on a single computer system or a multi-machine system in a network environment, the sensitive tags required for access control are stored in a unified database dictionary and implemented using a single access rule. For distributed database systems running on multi-machine systems in a network environment, mandatory access control for global applications should be implemented at the global b)
DBMS layer, and mandatory access control for local applications should be implemented at the local DBMS layer. The access rules adopted are consistent.
4.3.3 Access control granularity and characteristics
Access control of different granularities should be implemented according to the characteristics of the database and the different requirements of different security levels. These characteristics are mainly: data is stored in a specific structure format, and the granularity of the object can be: tables, views, tuples (records), columns (fields), a
element (field of each tuple), logs, fragments, partitions, snapshots, constraints and rules, DBMS core code, user applications, stored procedures, triggers, various access interfaces, etc. The database system has fully defined access operations, as shown in Table 1. b)
c) Database is the unity of data and logic. Database not only stores data, but also stores a large number of programs for managing and using these data. These programs and data also need to be protected to prevent unauthorized use, tampering, addition or destruction. The three-level structure (physical structure, logical structure, conceptual model structure) and two types of data independence (physical independence, logical independence) in the database greatly reduce the maintenance workload of database applications. However, since different logical structures may correspond to the same physical structure, it brings new problems to access control, and access rules should be checked for consistency. In distributed database management systems, access control for global applications should be implemented at the global DBMS layer, and access control for local applications should be implemented at the local DBMS layer, and different access control strategies should be selected according to needs. 4.4 Object reuse
The dynamic resources used in large quantities by the database management system are mostly allocated by the operating system. The operating system and database management system that implement object security reuse should meet the following requirements:
a) When the database management system proposes resource allocation requirements, such as creating a new library, initializing database equipment, etc., the resources obtained should not contain any previous information content of the object. 3
GA/T389--2002
When the database management system proposes resource retrieval requirements, it should ensure that all information in these resources is cleared. b)
The database management system requires the creation of a new database user process, and it should ensure that the resources allocated to each process do not contain residual c)
information.
d) The database management system should ensure that information that has been deleted or released is no longer available. 4.5 Database security audit
The security audit of the database management system should: a)
Establish an independent security audit system.
Define audit events related to database security. c)
Set up a dedicated security auditor.
Set up a security audit library specifically for storing audit data of the database system. d)
Provide tools for setting, analyzing and checking security audits for database systems. e)
4.6 Data integrity
4.6.1 Entity integrity and referential integrity
a) The database management system should ensure that the data in the database has entity integrity and referential integrity. The referential integrity rules between relationships are the prerequisite for the correct execution of the "connection" relationship operation. b) When the user defines the basic table, the primary key, foreign key, referenced table, column and reference behavior should be described. When data is entered, updated or deleted, the database management system should automatically maintain entity integrity and referential integrity according to the description. 4.6.2 User-defined integrity
The database management system should provide functions to support user-defined integrity. The system should provide a mechanism for defining and checking user-defined integrity a)
rules, the purpose of which is to be processed by the system in a unified way instead of being completed by the application, thereby not only simplifying the application but also improving the reliability of integrity assurance. The database management system should support naming constraints or assertions (or providing default names), defining check time, delay mode or setting default check time and delay mode, and support revocation of constraints and assertions. 4.6.3 Integrity of data operations
The integrity constraints of data operations are:
When users define basic tables, they should define primary keys and foreign keys. a)
For candidate keys, the user should specify their uniqueness. b)
For foreign keys, the user should specify the referenced relationship and reference behavior. c)
The database management system should check whether the data operations on primary keys, foreign keys, and candidate keys meet the integrity requirements, and any transactions that violate integrity are not allowed to be submitted.
When deleting or updating a tuple, the database management system should check whether the tuple contains a foreign key. If so, it should be deleted according to the reference behavior predefined by the user.
4.7 Covert Channel Analysis
The covert channel analysis of the database management system is closely related to the design of the database management system and should be carried out during the system development process. System developers should search for covert channels and determine the maximum bandwidth of each identified covert channel based on actual measurements or engineering calculations. 4.8 Trusted Path
When database users register or perform other security operations, a trusted communication path should be provided between the TCB and the user to achieve secure data exchange between the user and the TSF.
4.9 Trusted Database Recovery
Trusted recovery in a database management system has a specific meaning, which mainly includes: a) Ensuring that the TSF can start the DBMS of the secure database system without weakening protection. b) When a failure or abnormal situation occurs during operation, it can be restored to a correct, consistent, and effective state in the shortest possible time. This state is a normal and safe state for system operation and a real and meaningful state for applications. 4.
GA/T 389-—2002
c) Database technologies related to trusted recovery include transaction management, logs, checkpoints, backups, special processing of distributed databases, etc. 4.10 Reasoning control
The reasoning control method should be used to prevent the data information in the database from being obtained without authorization. Using reasoning methods to obtain database information beyond the authority is a relatively hidden information attack method. In database systems with high security level requirements, defense against such attacks should be considered.
5 Technical requirements for security level division
According to the different requirements of GB17859--1999 for each level, this part mainly describes the technical requirements of security functions and security assurance technical requirements from the perspective of ten security elements and reasoning control that is closely related to the security of database management systems. Table 2 gives the different requirements for ten security elements and security reasoning for each security level described in GB17859--1999.
Table 2 Security function requirements for each security level
Security level
Security elements
Discretionary access control
Mandatory access control
Identity authentication
Object reuse
Data integrity
Covered channel analysis
Trusted path
Trusted recovery
Inference control
User autonomy protection level
Note 1: +—indicates a requirement.
Note 2: +10—indicates an advanced requirement.
System audit protection level
Note 3: +++—indicates a further requirement. Note 4: +++ indicates a higher requirement.
Security tag protection level
Structured protection level
Access verification protection level
The specific technical requirements for each security level are described below. The bold Song font indicates that the content described appears for the first time in this level.
5.1 Level 1: User Self-protection Level
5.1.1 Security Function
5.1.1.1. Identity Authentication
Identity Authentication shall include the identification and authentication of the user's identity. The identity authentication function of the database management system shall be designed according to the description in 4.1 and the requirements of 6.1.3.1 identity authentication in GA/T390-2002. This security level requires: User identification shall be designed according to the description in 4.1.1 and the requirements of 6.1.3.1.1 in GA/T390-2002. a)
User authentication shall be designed according to the description in 4.1.2 and the requirements of 6.1.3.1.2 in GA/T390-2002. All users who need to enter the database management system shall be identified first (accounts shall be established). The user identification of the database management system shall use the user name and user ID (UID). Passwords are used for identity authentication, and authentication is required every time a user logs into the system. Identification information should be invisible and securely protected when stored.
5.1.1.2 Autonomous Access Control
Based on the description of access operations, access rules and authorization propagation in 4.2, the autonomous access control function of the database management system should be designed in accordance with the requirements of 6.1.3.2 of GA/T390-2002. This security level requires: Allow named users to define and control the sharing of objects as users and/or user groups, and prevent unauthorized users from sharing objects.
5.1.1.3 Data Integrity
Based on the description of 4.6, the data integrity function of the database management system should be designed in accordance with the requirements of 6.1.3.3 of GA/T390--2002. This security level requires:
a) For data transmission within the database management system, such as communication between processes, the function of ensuring data integrity should be provided. b) For data processed in the database management system, entity integrity, referential integrity and user-defined integrity should be implemented according to the descriptions of 4.6.1, 4.6.2 and 4.6.3, and the requirements of 6.1.3.3 of GA/T390-2002. The corresponding TCB security function module should be designed according to the requirements of rollback, and transaction rollback in abnormal situations should be performed to ensure data integrity. 5.1.2 TCB Self-Security Protection
5.1.2.1 TSF Protection
Should be in accordance with 6.1.4. of GA/T390-2002.1, design the TSF protection of the database management system. In this security level, the specific requirements for the TSF protection of the database management system are: a) The system should not have "backdoors" when it is designed. That is, any type of entry that violates or bypasses security rules and any mode of entry that is not described in the document should not be designed under the pretext of maintenance, support or operation needs. The security structure should be an independent and strictly defined subset of the system software and should prevent external interference and damage, such as modifying its code or data structure. b) The database management system should be designed in layers, and the database management system program and user program should be isolated. d) An installation mechanism for setting and upgrading configuration parameters should be provided. Before initializing and protecting security-related data structures, the security policy attributes of users and administrators should be defined. 5.1.2.2 Resource Utilization
The resource utilization of the database management system should be designed in accordance with the requirements of 6.1.4.2 in GA/T390-2002. In this security level, the specific requirements for resource utilization design are:
a) Take certain measures to ensure that TSF can maintain normal operation when certain certain failures occur in the system. b) Take appropriate strategies to provide the priority of using a certain resource subset in TSC by the subject according to the limited service priority, and manage and allocate TCB resources.
c) Manage and allocate TCB resources according to the maximum limit requirements in resource allocation to ensure that users and subjects do not monopolize certain controlled resources.
5.1.2.3TCB access control
The TCB access control of the database management system should be designed according to the requirements of 6.1.4.3 in GA/T390-2002. This security level requires:
a) According to the requirements of the minimum level of optional attribute range limitation, select all failed attempts of a certain session security attribute and limit the range of security attributes used to establish a session. b) Design session management according to the requirements of basic limitation in multiple concurrent session limitation. Based on the basic identification, TSF should limit the maximum number of concurrent sessions of the system and use the default value as the limit of the number of sessions. c) Design the management of session establishment according to the minimum level session establishment mechanism. 5.1.3 TCB design and implementation
5.1.3.1 Configuration management
The configuration management of the database management system TCB should be designed in accordance with the requirements of 6.1.5.1 of GA/T3902002.
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.