This topic provides an overview of Multi-Level Protection Scheme (MLPS) 2.0 and describes the managed rules that are included in the ClassifiedProtectionPreCheck compliance package template.
What is MLPS 2.0?
MLPS 2.0 is based on the national cybersecurity standards in China. The Chinese government officially released MLPS 2.0 on May 13, 2019 and officially implemented MPLS 2.0 on December 1, 2019.
Important changes in MLPS 2.0
Information systems in the cloud can be evaluated.
The specifications of the following systems are added to MPLS 2.0 based on MPLS 1.0: cloud computing platforms, big data platforms, IoT platforms, mobile computing systems, and industrial control systems. The specifications are provided based on the diverse and complex requirements of enterprises that use enterprise information systems.
Cloud tenants are independently evaluated.
In MLPS 1.0, the level of a cloud platform on which enterprise resources are hosted determines the level of an information system that a cloud tenant builds on the platform. Cloud tenants can better manage hosted resources when cloud services become more flexible and adaptable to complex environments. Starting MLPS 2.0, information systems that are built by cloud tenants through cloud platforms are independently evaluated.
Continuous security evaluation is emphasized.
In MLPS 1.0, the compliance of a system is evaluated only once. After the evaluation is complete, you cannot continuously monitor the system to check whether the system is compliant with the specifications. MLPS 2.0 integrates the requirements for continuous compliance into the specifications to help enterprises build information systems that support sustainable security capabilities. MLPS 2.0 is based on the policy-centered protection, detection, and response (PPDR) model, and allows enterprises to construct a three-dimensional and in-depth defense system that is trusted and can be managed. The defense system that is constructed must support security authentication and access management.
Characteristic
Description
Trusted
Construct a trusted execution environment for business systems based on trusted computing. To prevent the data of users from being leaked, and to prevent viruses and intrusions, all users, platforms, and applications must be trusted. A trusted environment ensures the security and reliability of the business systems. This way, business systems can run as expected without being interrupted by unexpected processes.
Controllable
Allow subjects to perform access control to manage the access behavior of objects and ensure that all access activities can be managed. This way, you can perform access management on services to prevent internal attacks and external attacks. Access management for services helps protect information systems from unauthorized operations and unauthorized resource access. This helps ensure that information systems are secure and can be managed.
Manageable
Construct a management platform that allows administrators to manage permissions in a centralized and hierarchical manner, and grant minimal permissions to users for better system management. This can help users focus on other operations. This also ensures that information systems are secure and can be managed.
MLPS 2.0 uses the "one center, triple protection" design philosophy for cybersecurity technology. One center refers to the security management center. Triple protection refers to the secure computing environment, the security zone border, and the secure communications network.
The security management center must support centralized management operations for system management, security management, and audit management. The protection mode must be changed from passive to active, from static to dynamic, from single-point to all-around, and from extensive to intensive.
Triple protection requires enterprises to use security devices and technologies to configure security measures such as identity authentication, access management, intrusion prevention, data integrity, data confidentiality, and personal information protection. Triple protection provides unified protection capabilities for cloud platforms.
The following table describes the differences between MLPS 1.0 and MLPS 2.0.
MLPS 1.0 | MLPS 2.0 |
In-depth defense capabilities such as attack prevention, attack response, and security audit are supported. | Unified defense capabilities such as active prevention, security authentication, threat detection, and comprehensive audit are supported. |
If the evaluation points are greater than zero, the official evaluation is passed. The official evaluation for MLPS 1.0 Level 3 must be performed on a yearly basis and the official evaluation for MLPS 1.0 Level 4 must be performed at an interval of six months. | If the evaluation points reach 70, the official evaluation is passed. Annual evaluations are required for both MLPS 2.0 Level 3 and MLPS 2.0 Level 4. |
The following section describes the challenges related to the deployment of information systems in the cloud based on MLPS 2.0
MLPS 2.0 focuses on continuous compliance supervision. Annual evaluations are required for MLPS 2.0 Level 3 and MLPS 2.0 Level 4. Information systems in the cloud face challenges related to MLPS 2.0 because resources are hosted on the cloud. The following table describes the challenges.
Challenge | Description |
Unclear evaluation objects | Some concepts of the virtualized IT infrastructure are different from some concepts related to traditional IT infrastructure. The evaluation of complex cloud configurations is difficult. |
Non-centralized resource management | If a cloud platform does not support configuration management databases (CMDBs), you need to perform extensive operations to provide evidence and submit information systems that are deployed in the cloud to authoritative agencies during the repeated evaluation and rectification process. |
Less control over the system data | Resources are hosted on the cloud. You must obtain security audit data from the cloud platform if MLPS 2.0 requires management logs and compliance reports as evidence. |
Unable to perform self-evaluation by writing code | During previous years, all enterprises used on-premises CMDBs, and wrote code to internally monitor and evaluate their configurations before the official evaluation. In the latest versions of services, resources are hosted on the cloud. The internal evaluation of configurations by writing code requires continuous configuration synchronization to the cloud. This process incurs high costs. |
Separated deployment of a business system | In a hybrid cloud model, a business system is separately deployed on the cloud and on on-premises machines. In this case, you must perform self-evaluation, scanning, monitoring, or detection twice. These processes incur high manpower costs and require a long period of time. |
Continuous monitoring on cloud platforms
To resolve the preceding challenges, Alibaba Cloud provides the classified protection precheck feature in Cloud Config free of charge. This feature allows you to perform self-evaluation and resolve issues related to your business.
Cloud Config processes the specifications of MLPS 2.0 as rules, continuously monitors resource configuration changes, evaluates resource compliance in real time, and triggers alerts for non-compliance. This way, enterprises can continuously monitor the compliance of information systems.
ClassifiedProtectionPreCheck
The ClassifiedProtectionPreCheck compliance package template contains rules that correspond to the requirements that are listed in MLPS 2.0. For more information, see the following table.
The ClassifiedProtectionPreCheck compliance package template provides a common compliance evaluation framework. You can specify input parameters for rules and configure settings for fixes to create compliance packages that meet your business requirements in an efficient manner. If resources are evaluated as compliant, the resources are based on only the compliance rules. In this case, the resources may not be compliant with legal requirements, regulations, and industry standards.
Rule name | Description | Requirement No. | Requirement detail |
ecs-instances-in-vpc | Checks whether the network type of each Elastic Compute Service (ECS) instance is VPC when the vpcIds parameter is not configured. If so, the evaluation result is Compliant. Checks whether each ECS instance is deployed in one of the specified virtual private clouds (VPCs) when the vpcIds parameter is configured. If so, the evaluation result is Compliant. | 8.1.2.1 | Make sure that the network devices support capabilities that can be used to process business requests during peak hours. |
8.1.2.1 | Plan network zones and assign addresses to each zone to perform efficient management operations. | ||
8.1.2.1 | Do not deploy important network zones at borders. Perform operations to isolate important network zones from other network zones. | ||
8.1.2.1 | Provide additional hardware for communication lines and key network devices to ensure system availability. | ||
8.1.2.2 | Use cryptography techniques to ensure data integrity during communication. | ||
8.1.2.2 | Use cryptography techniques to ensure data confidentiality during communication. | ||
rds-instances-in-vpc | Checks whether the network type of each ApsaraDB RDS instance is VPC when the vpcIds parameter is not configured. If so, the evaluation result is Compliant. Checks whether each ApsaraDB RDS instance is deployed in one of the specified VPCswhen the vpcIds parameter is configured. If so, the evaluation result is Compliant. | 8.1.2.1 | Make sure that the network devices support capabilities that can be used to process business requests during peak hours. |
8.1.2.1 | Plan network zones and assign addresses to each zone to perform efficient management operations. | ||
8.1.2.1 | Do not deploy important network zones at borders. Perform operations to isolate important network zones from other network zones. | ||
8.1.2.1 | Provide additional hardware for communication lines and key network devices to ensure system availability. | ||
8.1.2.2 | Use cryptography techniques to ensure data integrity during communication. | ||
8.1.2.2 | Use cryptography techniques to ensure data confidentiality during communication. | ||
redis-instance-in-vpc | Checks whether the network type of each ApsaraDB for Redis instance is VPC when the vpcIds parameter is not configured. If so, the evaluation result is Compliant. Checks whether each ApsaraDB for Redis instance is deployed in one of the specified VPCs when the vpcIds parameter is configured. If so, the evaluation result is Compliant. | 8.1.2.1 | Make sure that the network devices support capabilities that can be used to process business requests during peak hours. |
8.1.2.1 | Plan network zones and assign addresses to each zone to perform efficient management operations. | ||
8.1.2.1 | Do not deploy important network zones at borders. Perform operations to isolate important network zones from other network zones. | ||
8.1.2.1 | Provide additional hardware for communication lines and key network devices to ensure system availability. | ||
8.1.2.2 | Use cryptography techniques to ensure data integrity during communication. | ||
8.1.2.2 | Use cryptography techniques to ensure data confidentiality during communication. | ||
mongodb-instance-in-vpc | Checks whether the network type of each ApsaraDB for MongoDB instance is VPC when the vpcIds parameter is not configured. If so, the evaluation result is Compliant. Checks whether each ApsaraDB for MongoDB instance is deployed in one of the specified VPCs when the vpcIds parameter is configured. If so, the evaluation result is Compliant. | 8.1.2.1 | Make sure that the network devices support capabilities that can be used to process business requests during peak hours. |
8.1.2.1 | Plan network zones and assign addresses to each zone to perform efficient management operations. | ||
8.1.2.1 | Do not deploy important network zones at borders. Perform operations to isolate important network zones from other network zones. | ||
8.1.2.1 | Provide additional hardware for communication lines and key network devices to ensure system availability. | ||
8.1.2.2 | Use cryptography techniques to ensure data integrity during communication. | ||
8.1.2.2 | Use cryptography techniques to ensure data confidentiality during communication. | ||
polardb-dbcluster-in-vpc | Checks whether the network type of each PolarDB cluster is VPC when the vpcIds parameter is not configured. If so, the evaluation result is Compliant. Checks whether each PolarDB cluster is deployed in one of the specified VPCs when the vpcIds parameter is configured. If so, the evaluation result is Compliant. | 8.1.2.1 | Make sure that the network devices support capabilities that can be used to process business requests during peak hours. |
8.1.2.1 | Plan network zones and assign addresses to each zone to perform efficient management operations. | ||
8.1.2.1 | Do not deploy important network zones at borders. Perform operations to isolate important network zones from other network zones. | ||
8.1.2.1 | Provide additional hardware for communication lines and key network devices to ensure system availability. | ||
8.1.2.2 | Use cryptography techniques to ensure data integrity during communication. | ||
8.1.2.2 | Use cryptography techniques to ensure data confidentiality during communication. | ||
eip-bandwidth-limit | Checks whether the available bandwidth of each elastic IP address (EIP) is greater than or equal to a specified value. If so, the evaluation result is Compliant. | 8.1.2.1 | Make sure that the bandwidth of each network component meets your requirements during peak hours. |
slb-loadbalancer-bandwidth-limit | Checks whether the available bandwidth of each Server Load Balancer (SLB) instance is greater than or equal to a specified value. If so, the evaluation result is Compliant. | 8.1.2.1 | Make sure that the bandwidth of each network component meets your requirements during peak hours. |
sg-risky-ports-check | Checks whether the inbound CIDR block of a security group is set to 0.0.0.0/0. If not, the evaluation result is Compliant. Checks whether the specified high-risk ports are disabled when the inbound CIDR block of a security group is set to 0.0.0.0/0. If so, the evaluation result is Compliant. | 8.1.3.1 | Perform access control or check access requests that are sent from unauthorized devices over the internal network. |
8.1.4.4 | Configure access control rules at network borders or between network zones based on access control policies. Managed interfaces allow only communication requests that comply with the rules. | ||
sg-public-access-check | Checks whether the Port Range parameter is set to All or Authorization Object parameter is set to 0.0.0.0/0 for each inbound rule of a security group when the Action parameter of the inbound rule is set to Allow. If so, the evaluation result is Compliant. | 8.1.3.1 | Perform access control or check access requests that are sent from unauthorized devices over the internal network. |
8.1.3.2 | Configure access control rules at network borders or between network zones based on access control policies. Managed interfaces allow only communication requests that comply with the rules. | ||
slb-no-public-ip | Checks whether a public IP address is specified for each SLB instance. If not, the evaluation result is Compliant. | 8.1.3.1 | Perform access control or check access requests that are sent from unauthorized devices over the internal network. |
8.1.3.2 | Configure access control rules at network borders or between network zones based on access control policies. Managed interfaces allow only communication requests that comply with the rules. | ||
rds-public-access-check | Checks whether each ApsaraDB RDS instance has a public endpoint. If not, the evaluation result is Compliant. | 8.1.3.1 | Perform access control or check access requests that are sent from unauthorized devices over the internal network. |
8.1.3.2 | Configure access control rules at network borders or between network zones based on access control policies. Managed interfaces allow only communication requests that comply with the rules. | ||
ecs-instance-no-public-ip | Checks whether a public IPv4 address or EIP is specified for each ECS instance. If not, the evaluation result is Compliant. | 8.1.3.1 | Perform access control or check access requests that are sent from unauthorized devices over the internal network. |
8.1.3.2 | Configure access control rules at network borders or between network zones based on access control policies. Managed interfaces allow only communication requests that comply with the rules. | ||
oss-bucket-public-read-prohibited | Checks whether the access control list (ACL) policy of each Object Storage Service (OSS) bucket denies read access from the Internet. If so, the evaluation result is Compliant. | 8.1.3.1 | Perform access control or check access requests that are sent from unauthorized devices over the internal network. |
8.1.3.2 | Configure access control rules at network borders or between network zones based on access control policies. Managed interfaces allow only communication requests that comply with the rules. | ||
redis-public-access-check | Checks whether 0.0.0.0/0 is added to the IP address whitelist of an ApsaraDB for Redis instance. If not, the evaluation result is Compliant. | 8.1.3.1 | Perform access control or check access requests that are sent from unauthorized devices over the internal network. |
8.1.3.2 | Configure access control rules at network borders or between network zones based on access control policies. Managed interfaces allow only communication requests that comply with the rules. | ||
mongodb-public-access-check | Checks whether 0.0.0.0/0 is added to the IP address whitelist of each ApsaraDB for MongoDB instance. If not, the evaluation result is Compliant. | 8.1.3.1 | Perform access control or check access requests that are sent from unauthorized devices over the internal network. |
8.1.3.2 | Configure access control rules at network borders or between network zones based on access control policies. Managed interfaces allow only communication requests that comply with the rules. | ||
polardb-public-access-check | Checks whether 0.0.0.0/0 is added to the IP address whitelist of each PolarDB cluster. If not, the evaluation result is Compliant. | 8.1.3.1 | Perform access control or check access requests that are sent from unauthorized devices over the internal network. |
8.1.3.2 | Configure access control rules at network borders or between network zones based on access control policies. Managed interfaces allow only communication requests that comply with the rules. | ||
slb-acl-public-access-check | Checks whether an IP address whitelist is configured for each SLB instance and 0.0.0.0/0 is not added to the IP address whitelist. If so, the evaluation result is Compliant. | 8.1.3.1 | Perform access control or check access requests that are sent from unauthorized devices over the internal network. |
8.1.3.2 | Configure access control rules at network borders or between network zones based on access control policies. Managed interfaces allow only communication requests that comply with the rules. | ||
rds-instance-enabled-security-ip-list | Checks whether an IP address whitelist is configured for each ApsaraDB RDS instance and 0.0.0.0/0 is not added to the IP address whitelist. If so, the evaluation result is Compliant. | 8.1.3.1 | Perform access control or check access requests that are sent from unauthorized devices over the internal network. |
8.1.3.2 | Configure access control rules at network borders or between network zones based on access control policies. Managed interfaces allow only communication requests that comply with the rules. | ||
actiontrail-enabled | Checks whether at least one active trail exists in ActionTrail. If so, the evaluation result is Compliant. | 8.1.3.5 or 8.1.4.3 | Back up audit logs at regular intervals to protect them from being accidentally deleted, modified, or overwritten. |
ram-user-mfa-check | Checks whether multi-factor authentication (MFA) is enabled for each RAM user. If so, the evaluation result is Compliant. | 8.1.4.1 | Use a combination of two or more of the following techniques to authenticate user identities: password, cryptography technique, and biotechnology. A cryptography technique must be used in each combination. |
slb-listener-https-enabled | Checks whether an HTTPS listener is enabled for a specified port on each SLB instance. If so, the evaluation result is Compliant. | 8.1.4.7 | Use cryptography techniques to ensure the integrity of important data during transmission, including authentication of data and important business data, audit data, configuration data, videos, and personal data. |
cdn-domain-https-enabled | Checks whether HTTPS is enabled for a domain name accelerated by Alibaba Cloud CDN. If so, the evaluation result is Compliant. | 8.1.4.7 | Use cryptography techniques to ensure the integrity of important data during transmission, including authentication of data and important business data, audit data, configuration data, videos, and personal data. |
oss-bucket-server-side-encryption-enabled | Checks whether the Encryption Method parameter of the server-side encryption feature is set to OSS-managed for each OSS bucket. If so, the evaluation result is Compliant. | 8.1.4.7 | Use cryptography techniques to ensure the integrity of important data during transmission, including authentication of data and important business data, audit data, configuration data, videos, and personal data. |
8.1.4.8 | Use cryptography techniques to ensure the integrity of important data during transmission, including authentication of data and important business data, audit data, configuration data, videos, and personal data. | ||
ecs-disk-encrypted | Checks whether the encryption feature is enabled for each ECS data disk. If so, the evaluation result is Compliant. | 8.1.4.7 | Use cryptography techniques to ensure the integrity of important data during transmission, including authentication of data and important business data, audit data, configuration data, videos, and personal data. |
rds-high-availability-category | Checks whether the edition of each ApsaraDB RDS instance is High-availability. If so, the evaluation result is Compliant. | 8.1.4.9 | Provide the required features to back up and restore important local data. |
8.1.4.9 | Provide the required features to back up important data to a remote destination site in real time over communication networks. | ||
8.1.4.9 | Provide hot redundancy for important data processing systems to ensure system availability. | ||
rds-multi-az-support | Checks whether the deployment method of each ApsaraDB RDS instance is Multi-zone Deployment. If so, the evaluation result is Compliant. | 8.1.4.9 | Provide hot redundancy for important data processing systems to ensure system availability. |
oss-zrs-enabled | Checks whether the zone-redundant storage (ZRS) feature is enabled for each OSS bucket. If so, the evaluation result is Compliant. | 8.1.4.9 | Provide hot redundancy for important data processing systems to ensure system availability. |
rds-connectionmode-safe-enabled | Checks whether the proxy mode is enabled for each ApsaraDB RDS for SQL Server instance. If so, the evaluation result is Compliant. | 8.1.4.9 | Provide hot redundancy for important data processing systems to ensure system availability. |