- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Practical Tutorial
- API Documentation
- History
- Introduction
- API Category
- Making API Requests
- Report Download APIs
- Scan Task APIs
- Risk Center APIs
- DescribeRiskCenterAssetViewCFGRiskList
- DescribeRiskCenterAssetViewPortRiskList
- DescribeRiskCenterAssetViewVULRiskList
- DescribeRiskCenterAssetViewWeakPasswordRiskList
- DescribeRiskCenterPortViewPortRiskList
- DescribeRiskCenterVULViewVULRiskList
- DescribeRiskCenterWebsiteRiskList
- DescribeScanReportList
- ModifyRiskCenterRiskStatus
- DescribeRiskCenterServerRiskList
- Asset Center APIs
- Solid Protection APIs
- Cloud Security Center Overview APIs
- Data Types
- Error Codes
- Related Protocol,
- FAQs
- Glossary
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Practical Tutorial
- API Documentation
- History
- Introduction
- API Category
- Making API Requests
- Report Download APIs
- Scan Task APIs
- Risk Center APIs
- DescribeRiskCenterAssetViewCFGRiskList
- DescribeRiskCenterAssetViewPortRiskList
- DescribeRiskCenterAssetViewVULRiskList
- DescribeRiskCenterAssetViewWeakPasswordRiskList
- DescribeRiskCenterPortViewPortRiskList
- DescribeRiskCenterVULViewVULRiskList
- DescribeRiskCenterWebsiteRiskList
- DescribeScanReportList
- ModifyRiskCenterRiskStatus
- DescribeRiskCenterServerRiskList
- Asset Center APIs
- Solid Protection APIs
- Cloud Security Center Overview APIs
- Data Types
- Error Codes
- Related Protocol,
- FAQs
- Glossary
How do I choose a health check quota?
To mitigate asset security risks, it is recommended to conduct four automatic checks and one comprehensive manual check each month. Please calculate the number of asset health checks to purchase based on the quantity of your cloud assets.
Formula for calculating consumed health check quota
In a single security check, selecting one domain and one IP asset each consumes one health check quota, totaling two health check quotas. If you select a cloud resource configuration risk health check project, the consumed health check quota is the number of selected cloud resources.
Is it abnormal if the health check duration is too long?
If a security health check task involves inspecting a web site, it requires content recognition analysis of your specified URL using crawling technology authorized by you. Moreover, conducting the health check too quickly can easily impact the business, hence a slower health check duration is normal.
Will a report still be generated after a health check task is terminated?
If a security health check task is terminated, no report will be generated. However, detected risks will still exist in the Risk Center and can be queried based on the report ID.
Does an abnormal health check task consume health checks and occupy task quotas?
If a security health check task cannot be executed, it occupies the task quota but does not consume the health check quota. If a security health check task begins execution, it immediately consumes the health check quota and occupies the task quota.
In addition to hosts and containers, what other cloud resources are included in the configuration risk detection?
Check Item Name | Check type | Check target | Risk level | Associated standard | Configuration risk notes |
TDSQL for MySQL should not be open to public network access. | Data Security | tdmysql | Medium | Default security standards | Direct exposure of the database to the public network may lead to the leakage of sensitive data in the database, posing a high security risk. This check item will inspect TDSQL MySQL Edition, and if public network access is enabled, it does not meet the requirements. |
Network ACL should not have all inbound rules allowed. | Network access control | subnet | High | Default security standards | A Network ACL is a subnet-level access control attack. If you use a rule that allows all inbound traffic, i.e., the source in the inbound direction is 0.0.0.0/0 and the action is to allow, it may cause the subnet to be overly exposed, leading to unnecessary exposure of assets. This check item will inspect the inbound rules of the Network ACL service. If there is a rule where the source address is 0.0.0.0/0, all ports are allowed, and the action is to allow, then it does not meet the requirements. |
It is not recommended for Network ACL to have inbound rules that allow all non-business ports. | Network access control | subnet | High | Default security standards | A Network ACL is an access control attack at the subnet level. If you use inbound rules that allow all non-business (default: 80,443) traffic, i.e., inbound rules where the source is 0.0.0.0/0, the port is any port other than 80/443, and the action is 'allow', this could potentially lead to an overly broad opening of the subnet, unnecessarily exposing assets. This check will examine the inbound rules of the Network ACL service. There should not be any rules where the source address is 0.0.0.0/0, the port is 'all' or a non-business port (default: 80,443), and the action is 'allow'. |
The SSL certificate should be within its validity period. | Data Security | ssl | Medium | Default security standards | Check whether the SSL certificate has exceeded its validity period. You need to renew or replace the certificate in a timely manner before it expires. Otherwise, you will not be able to continue using the SSL certificate service, leading to data security risks. The current check scope is all SSL certificates. You need to determine whether to repair or delete unused certificates based on whether the certificate is associated with resources and whether the domain name is still in use. |
The permissions for the image repository should be set appropriately. | Data Security | repository | Medium | Default security specifications, technical requirements for level three cybersecurity protection | Repositories are divided into public repositories and private repositories. Public repositories allow all users on the Internet to access and download images. If the image contains sensitive information, it is recommended to configure it as a private repository to prevent information leakage. |
High-risk commands should be disabled in TencentDB for Redis. | Data Security | redis | Medium | Default security standards | Databases often have high levels of security protection. If high-risk commands are not disabled (default: flushall, flushdb, keys, hgetall, eval, evalsha, script), it can easily lead to application blocking and data deletion risks. This check will examine the Redis instance's command disablement configuration. If high-risk commands are not disabled (default includes: flushall, flushdb, keys, hgetall, eval, evalsha, script), it does not meet the requirements. |
The NoSQL database - Redis should enable automatic backup. | Data Security | redis | Medium | Default security specifications, technical requirements for level three cybersecurity protection | To determine if the backup function of the Redis database is abnormal, under normal circumstances, data should be backed up at least once a day. |
The NoSQL database - Redis should not be open to all network segments. | Network access control | redis | High | Default security specifications, technical requirements for level three cybersecurity protection | Determining whether the service port of the Redis database is open to all IPs. Under normal circumstances, the database service port should only be open to trusted IPs or ranges. |
NoSQL-Redis should be located in the Mainland China region. | Infrastructure Location | redis | Low risk | Technical requirements for Level 3 Cybersecurity Protection | Requirement 8.2.1.1 in GB 22239-2008 stipulates that the cloud computing infrastructure should be located within the Chinese mainland. |
It is not recommended to allow public network access to TencentDB for PostgreSQL. | Network access control | postgres | High | Default security standards | Direct exposure of a database to the public network may lead to the leakage of sensitive data within the database, posing a high security risk. |
Relational Database - PostgreSQL should enable backup. | Data Security | postgres | Medium | Default security specifications, technical requirements for level three cybersecurity protection | To determine whether the backup function of the PostgreSQL database is abnormal, under normal circumstances, data should be backed up at least once a day. |
The relational database - TencentDB for PostgreSQL should be located in the mainland China region. | Infrastructure Location | postgres | Low risk | Technical requirements for Level 3 Cybersecurity Protection | Requirement 8.2.1.1 in GB 22239-2008 stipulates that the cloud computing infrastructure should be located within the Chinese mainland. |
NoSQL-MongoDB should be located in the mainland China region. | Infrastructure Location | mongodb | Low risk | Technical requirements for Level 3 Cybersecurity Protection | Requirement 8.2.1.1 in GB 22239-2008 stipulates that the cloud computing infrastructure should be located within the Chinese mainland. |
TencentDB for MariaDB should restrict the use of high-risk commands. | Data Security | mariadb | Medium | Default security standards | Databases often have a high level of security protection. If all accounts have global command permissions such as drop and delete, there is a risk of accidental data deletion or malicious deletion. This check will inspect MariaDB. If all users have not prohibited the drop and delete commands, it does not meet the requirements. |
It is not recommended to allow public network access to TencentDB for MariaDB. | Network access control | mariadb | High | Default security standards | Direct exposure of a database to the public network may lead to the leakage of sensitive data within the database, posing a high security risk. |
TencentDB for MariaDB should not enable access for all network segments. | Network access control | mariadb | High | Default security standards | If a cloud database is configured to allow access from all network segments, it enlarges the attack surface of the database, thereby increasing the risk of attacks and data breaches. |
Relational Database - MariaDB should enable backup | Data Security | mariadb | Medium | Default security specifications, technical requirements for level three cybersecurity protection | To determine whether the backup function of the MariaDB database is abnormal, under normal circumstances, data should be backed up at least once a day. |
The relational database - TencentDB for MariaDB should be located in the mainland China region. | Infrastructure Location | mariadb | Low risk | Technical requirements for Level 3 Cybersecurity Protection | Requirement 8.2.1.1 in GB 22239-2008 stipulates that the cloud computing infrastructure should be located within the Chinese mainland. |
Elasticsearch clusters should not be open to public network access. | Data Security | es | High | Default security standards | Elasticsearch clusters often store data. If public network access is enabled, it may expose unnecessary attack surfaces, leading to risks to data integrity, confidentiality, and availability. |
The Kibana component of the Elasticsearch cluster should not be open to public network access. | Data Security | es | High | Default security standards | Elasticsearch clusters often store data and can be accessed and controlled via the Kibana component. If public network access is enabled, it may expose unnecessary attack surfaces, leading to risks to data integrity, confidentiality, and availability. |
The security group should not open any port to all network segments. | Network access control | cvm | High | Default security specifications, technical requirements for level three cybersecurity protection | A security group is a type of virtual firewall. It is recommended to configure firewall policies based on the principle of minimal granularity and add trusted IP allowlists for server port access. |
The CVM should be located in the Chinese mainland region. | Infrastructure Location | cvm | Medium | Technical requirements for Level 3 Cybersecurity Protection | Requirement 8.2.1.1 in GB 22239-2008 stipulates that the cloud computing infrastructure should be located within the Chinese mainland. |
CVM should use key pair login | Identity Verification and Permissions | cvm | Medium | Default security standards | Check whether the CVM is logged in using an SSH key. Compared to traditional password login, SSH key login is more convenient and secure. (Only checks for Linux system machines) |
The host security agent on the CVM should operate normally. | Basic Security Protection | cvm | High | Default security specifications, technical requirements for level three cybersecurity protection | Tencent Cloud Workload Protection Platform provides a variety of security features including trojan detection and removal, brute force attack prevention, login behavior auditing, vulnerability management, and asset component identification. Without the installation of the CWPP client, there is a risk of network security breaches and data leakage. |
It is recommended to enable bucket replication for the COS bucket. | Data Security | cos | Medium | Default security specifications, technical requirements for level three cybersecurity protection | Cross-region replication is a configuration for storage buckets. By setting up cross-region replication rules, incremental objects can be automatically and asynchronously replicated between storage buckets in different regions. Once cross-region replication is enabled, COS will precisely replicate the object content in the source bucket (such as object metadata and version ID) to the target bucket, and the replicated object copies will have completely consistent attribute information. In addition, operations on objects in the source bucket, such as adding or deleting objects, will also be replicated to the target bucket. It is recommended to perform cross-region replication to enhance your data disaster recovery capabilities. |
A reasonable bucket policy should be configured for the COS bucket. | Data Security | cos | High | Default security specifications, technical requirements for level three cybersecurity protection | A bucket policy refers to the access policy configured within a bucket, allowing specified users to perform designated operations on the bucket and its resources. It should be configured according to the principle of "minimal permissions". It is not recommended to grant read access to any user, as this poses a risk of file names being traversed or files being downloaded. |
The COS bucket should be located in the China Mainland region. | Infrastructure Location | cos | Low risk | Technical requirements for Level 3 Cybersecurity Protection | Requirement 8.2.1.1 in GB 22239-2008 stipulates that the cloud computing infrastructure should be located within the Chinese mainland. |
The COS bucket should enable the anti-leech feature. | Data Security | cos | Medium | Default security specifications, technical requirements for level three cybersecurity protection | To prevent malicious programs from using resource URLs to steal public network traffic or employing malicious methods to misappropriate resources, causing unnecessary losses, it is recommended that you configure a blocklist/allowlist through the console's hotlink protection settings to provide security protection for storage objects. |
The COS bucket should enable server-side encryption. | Data Security | cos | Medium | Default security specifications, technical requirements for level three cybersecurity protection | Buckets support the application of data encryption protection policies at the object level and automatically decrypt data upon access. Both the encryption and decryption processes are completed on the server side. This server-side encryption feature can effectively protect static data. It is recommended to enable this configuration for sensitive data types. |
The COS bucket should have log recording enabled. | Data Security | cos | Medium | Default security specifications, technical requirements for level three cybersecurity protection | The log management feature can record detailed access information for a specified source bucket and save this information in the form of log files in a designated bucket, facilitating better bucket management. The log management feature requires that the source bucket and the target bucket be in the same region, currently supported in Beijing, Shanghai, Guangzhou, and Chengdu. If your region supports the log management feature, it is recommended to enable this function. |
The ACL public permission for the COS bucket should not be set to public read and write. | Data Security | cos | High | Default security specifications, technical requirements for level three cybersecurity protection | The public read and write permissions of a bucket allow data in the bucket to be directly read and written by anonymous identities, posing certain security risks. To ensure the safety of your data, it is not recommended to set the bucket permissions to public read/write or public read/private write. Instead, it is advisable to choose private read/write permissions. |
The certificate bound to the CLB should be within its validity period. | Monitoring and Alarms | clb | Medium | Default security standards | Check whether the certificate bound with the CLB has expired. If it has, it needs to be replaced to avoid affecting normal business operations. |
The health check status of the CLB backend server group should remain normal. | Monitoring and Alarms | clb | Low risk | Default security standards | The health status of the Tencent Cloud Load Balancer (CLB) service is checked to determine whether there are any anomalies with the backend services of the CLB. |
CLB should not forward high-risk ports | Network access control | clb | High | Default security specifications, technical requirements for level three cybersecurity protection | The CLB forwarding strategy should be set based on the "minimum service" principle, forwarding only necessary public service ports (such as 80, 443, etc.), and other ports should not be forwarded. |
CLB should not enable non-business port access for all network segments. | Network access control | clb | High | Default security specifications, technical requirements for level three cybersecurity protection | Inspect the access control configuration of the CLB load balancing instance. There is a potential security risk in opening 0.0.0.0/0 to non-business ports. It is recommended to enable access control for non-http/https services. |
TencentDB for MySQL should enable database auditing. | Data Security | cdb | Medium | Default security standards | Databases often store data of high importance. If database auditing is not enabled, it would be difficult to trace back in case of issues such as misoperations or malicious operations. This check item will verify whether database auditing is enabled for the MySQL database. If it is not, it does not meet the requirements. |
The network type for TencentDB for MySQL should utilize a private network. | Data Security | cdb | Medium | Default security standards | A VPC can isolate different networks based on tenant requirements. Databases often store data of high importance. If a non-private network is used, precise access control rules need to be maintained. Any oversight or error in maintenance could potentially expose your database unnecessarily. This check item will inspect the MySQL database type. If it is a private network, it meets the requirements; otherwise, it does not. |
A password should be set for the admin account in TencentDB for MySQL. | Network access control | cdb | High | Default security standards | TencentDB for MySQL is a database service. If you have not configured the administrator account and password for the database, it may be maliciously logged in, leading to data leakage. |
A non-root user should be created for use with TencentDB for MySQL. | Data Security | cdb | Medium | Default security standards | Databases often store data of high importance. If a database only has a root account and no other application accounts, it indicates excessive permissions, posing a risk of data security being affected by erroneous or malicious operations. This check item will inspect the user list of the primary instance database of MySQL that has been initialized. If there are no other users besides the root user and the default mysql.* created by Tencent Cloud, it does not meet the requirements. |
TencentDB for MySQL database instances should be deployed in different availability zones. | Data Security | cdb | Low risk | Default security standards | TencentDB for MySQL offers various high-availability architectures. Selecting different primary and secondary availability zones (i.e., multi-AZ deployment) can protect the database from failures or AZ interruptions. This check item will inspect the MySQL database. If the primary and secondary instances of the same database are in the same region and availability zone, it does not meet the requirements. |
The retention period for TencentDB for MySQL database audit should meet the requirements. | Data Security | cdb | Medium | Default security standards | Databases often store data of high importance. Based on compliance requirements, database audit logs should be retained for at least six months or more. This check will examine the retention time of MySQL database audits. If the retention time is less than the audit time (default 180 days), it does not meet the requirements. |
It is recommended to limit the high-risk command permissions of non-root users in TencentDB for MySQL. | Data Security | cdb | Medium | Default security standards | Non-root database accounts should be subject to permission control. If application accounts have high-risk command permissions, such as drop and delete, there is a risk of accidental or malicious data deletion. This check item will inspect the MySQL database (checking the master instance, not checking read-only instances and disaster recovery instances), and the configuration of users other than the root user. If the configuration allows the execution of commands: drop, delete, then it is not satisfactory. For instances where non-root users do not exist, this check item is satisfactory and other check items are used for compliance checks. |
It is not recommended to open TencentDB for MySQL for public network access. | Network access control | cdb | High | Default security standards | TencentDB for MySQL is a database service. If the database is directly exposed to the public network, it may lead to the leakage of sensitive data in the database, posing a high security risk. |
Relational Database - MySQL should enable backup. | Data Security | cdb | Medium | Default security specifications, technical requirements for level three cybersecurity protection | To determine whether the backup function of the MySQL database is abnormal, under normal circumstances, data should be backed up at least once a day. |
The relational database - MySQL database should be located in the mainland China region. | Infrastructure Location | cdb | Low risk | Technical requirements for Level 3 Cybersecurity Protection | Requirement 8.2.1.1 in GB 22239-2008 stipulates that the cloud computing infrastructure should be located within the Chinese mainland. |
The relational database - MySQL should not be open to all IP ranges. | Network access control | cdb | Medium | Default security specifications, technical requirements for level three cybersecurity protection | Determining whether the service port of the MySQL database is open to all IP addresses. Under normal circumstances, the database service port should only be open to trusted IPs or ranges. |
The CBS data disk should be set as an encrypted disk. | Data Security | cbs | Medium | Default security specifications, technical requirements for level three cybersecurity protection | Check whether the data disk of the cloud disk is an encrypted disk. Encrypted disks can not only provide better data confidentiality, but also meet security compliance requirements. (Only non-system disks can be checked) |
CBS should enable the scheduled snapshot feature. | Data Security | cbs | Medium | Default security specifications, technical requirements for level three cybersecurity protection | Verify if the automatic scheduled snapshot feature is enabled for the cloud disk. Regular snapshot creation can enhance data security, achieving low-cost and high-disaster tolerance for your business. |
Sub-accounts should use MFA for login protection | Basic Security Protection | cam | Medium | Default security standards | If a sub-account has not bound an MFA device, it cannot use MFA for secondary verification in login protection or operation protection, which poses a risk. This check item will verify whether the sub-account has bound an MFA device. If not, it does not meet the requirements. |
Sub-accounts should use MFA for operation protection. | Basic Security Protection | cam | Medium | Default security standards | If a sub-account has not bound an MFA device, it cannot use MFA for secondary verification in login protection or operation protection, which poses a risk. This check item will verify whether the sub-account has bound an MFA device. If not, it does not meet the requirements. |
Sub-account passwords should be changed regularly. | Basic Security Protection | cam | Medium | Default security standards | The sub-account password is the primary credential for user access. Not changing the password for a long period (90 days) can increase the risk of password leakage. The account information involved in this check may be subject to synchronization delays, so it is recommended to have an interval of more than 4 hours between checks. |
Obsolete sub-accounts should be deleted. | Basic Security Protection | cam | High | Default security standards | If a sub-account is not logged in for a long period (30 days), it is possible that the account has been abandoned. Abandoned accounts may be used by individuals no longer affiliated with your organization, leading to unavailability of your assets or data leakage. |
Obsolete API keys of sub-accounts should be deleted. | Basic Security Protection | cam | High | Default security standards | If a sub-account API key has not been used for a long period (30 days), it is possible that the API key has been abandoned. Abandoned API keys may be used by members no longer belonging to your organization, leading to unavailability of your assets or data leakage. The account information involved in this check may be subject to synchronization delays, so it is recommended to have a check interval of more than 4 hours. |
Obsolete collaborator API keys should be deleted. | Basic Security Protection | cam | High | Default security standards | If a collaborator's API key has not been used for a long period (30 days), it is possible that the API key has been abandoned. Abandoned API keys may be used by members no longer belonging to your organization, leading to unavailability of your assets or data leakage. The account information involved in this check may be subject to synchronization delays, so it is recommended to have a check interval of more than 4 hours. |
The API keys of sub-accounts should be regularly updated. | Basic Security Protection | cam | Medium | Default security standards | The API key of a sub-account is the primary credential for programmatic access. Not changing the key for a long period (90 days) can increase the risk of key exposure. The account information involved in this check may be subject to synchronization delays, so it is recommended to have a check interval of more than 4 hours. |
The API key of the collaborator should be regularly updated. | Basic Security Protection | cam | Medium | Default security standards | The collaborator's API key is a primary credential for programmatic access. Not changing the key for a long period (90 days) can increase the risk of key leakage. The account information involved in this check may be subject to synchronization delays, so it is recommended to have a check interval of more than 4 hours. |
Collaborators should use MFA for login protection. | Basic Security Protection | cam | Medium | Default security standards | If a collaborator has not bound an MFA device, they cannot use MFA for secondary verification in login protection or operation protection, which poses a risk. This check item will verify whether the collaborator has bound an MFA device. If not, they do not meet the requirements. |
Collaborators should use MFA for operation protection. | Basic Security Protection | cam | Medium | Default security standards | If a collaborator has not bound an MFA device, they cannot use MFA for secondary verification in login protection or operation protection, which poses a risk. This check item will verify whether the collaborator has bound an MFA device. If not, they do not meet the requirements. |
Collaborators should activate login protection. | Basic Security Protection | cam | Medium | Default security standards | Collaborator accounts do not belong to your account management system and pose uncontrollable security risks. If a collaborator account is compromised, it may lead to the destruction of assets that the collaborator has access to or data leakage. By enabling login protection and implementing multi-factor authentication for collaborator logins, the risk of damage caused by collaborator account leakage can be reduced. |
Collaborators should enable operation protection | Basic Security Protection | cam | Medium | Default security standards | Collaborator accounts do not belong to your account management system and their security risks are uncontrollable. If a collaborator account is compromised, it may lead to the destruction of assets that the collaborator has permission to access or data leakage. By enabling operation protection, sensitive operations by collaborators are subject to secondary verification, reducing the risks associated with collaborator account leakage. |
Collaborators should not use programming access and user interface access simultaneously. | Basic Security Protection | cam | High | Default security standards | If both access methods are enabled for a collaborator account, it may increase the exposure of a single account and potentially lead to the mixed use of automated and manual accounts, increasing the likelihood of malicious use. The account information involved in this check may be subject to synchronization delays, so it is recommended to have an interval of more than four hours between checks. |
Collaborators with high-risk permissions should enable login protection. | Basic Security Protection | cam | High | Default security standards | Collaborator accounts do not belong to your account management system and their security risks are uncontrollable. High-permission collaborators have super admin privileges. If a collaborator account is compromised, your cloud assets will face significant security risks. By enabling login protection and implementing secondary verification for collaborator logins, the risk of collaborator account leakage can be reduced. |
Operation protection should be enabled for collaborators with high-risk permissions. | Basic Security Protection | cam | High | Default security standards | A collaborator account does not belong to your account management system, and its security risks are uncontrollable. High-permission collaborators have super administrator permissions. If a collaborator account is leaked, your cloud assets will face very high security risks. By enabling operation protection, sensitive operations of collaborators are subject to secondary verification, reducing the risks caused by the leakage of collaborator accounts. |
It is recommended that a sub-account has no more than one API key. | Basic Security Protection | cam | Low risk | Default security standards | Maintaining multiple API keys for a single sub-account can increase the exposure of the keys and the risk of key leakage. The account information involved in this check may be subject to synchronization delays, so it is recommended to have an interval of more than 4 hours between checks. |
Login protection should be enabled for sub-accounts with high-risk permissions. | Basic Security Protection | cam | High | Default security standards | High-privilege sub-accounts possess super administrator permissions. If such high-risk sub-accounts are maliciously logged in, your cloud assets could face significant risks. Login protection provides a second verification for your sub-account logins, reducing the likelihood of high-risk sub-accounts being maliciously logged in. |
Operation protection should be enabled for sub-accounts with high-risk permissions. | Basic Security Protection | cam | Medium | Default security standards | A high-privilege sub-account has the authority of a super administrator. If the main account is misused or maliciously operated after being stolen, it may affect all your cloud assets. Operation protection provides a second verification for your sensitive operations, reducing the risk of misuse or malicious operations. |
It is not recommended to enable API keys for sub-accounts with high-risk permissions. | Basic Security Protection | cam | Low risk | Default security standards | A high-privilege sub-account has the authority of a super administrator, and the API key is the identity credential for account programming access. It is often written into the configuration and is prone to leakage. If the API key is leaked, an attacker can use this key to control all your assets in the cloud, posing a high risk. The account information involved in this check may be subject to synchronization delays, so it is recommended to have a check interval of more than four hours. |
You cannot simultaneously enable programming access and user interface access for a sub-account. | Basic Security Protection | cam | Medium | Default security standards | Sub-accounts have two access methods. If both are enabled, it may increase the exposure of a single account and potentially lead to the mixed use of automated and manual accounts, increasing the likelihood of malicious account usage. The account information involved in this check may be subject to synchronization delays, so it is recommended to have an interval of more than 4 hours between checks. |
The root account should use MFA for login protection. | Basic Security Protection | account | Medium | Default security standards | The primary account inherently possesses all Tencent Cloud resources under the account and has super administrator privileges. If the primary account is compromised, your cloud assets could face significant security risks. Multi-factor authentication (MFA) is a simple and effective security authentication method that adds an additional layer of protection beyond the username and password. Login protection can utilize Tencent Cloud's virtual MFA device, reducing the likelihood of malicious logins to the primary account. |
The root account should use MFA for operation protection. | Basic Security Protection | account | Medium | Default security standards | The root account by default possesses all Tencent Cloud resources under the account and has super administrator privileges. Misoperation or malicious operation by the root account due to theft may affect all your cloud assets. Multi-factor authentication (MFA) is a simple and effective security authentication method that adds an extra layer of protection beyond the username and password. Enabling virtual MFA in operation protection can provide a second verification for your sensitive operations, reducing the risk of misoperation or malicious operation. |
The primary account should activate login protection. | Basic Security Protection | account | High | Default security standards | The root account by default has access to all Tencent Cloud resources under the account and has super administrator permissions. If the root account is compromised, your cloud assets face a high security risk. Login protection provides a second verification for your account login, reducing the likelihood of malicious logins to the root account. |
The master account should enable operation protection. | Basic Security Protection | account | Medium | Default security standards | The root account by default owns all Tencent Cloud resources under the account and has super administrator privileges. Any misoperation or malicious operation due to the root account being compromised could potentially affect all your cloud assets. Operation protection provides a second verification for your sensitive operations, reducing the risk of misoperation or malicious activities. |
It is recommended that the main account enables protection against logins from different locations. | Basic Security Protection | account | Low risk | Default security standards | The root account by default possesses all Tencent Cloud resources under the account and has super administrator permissions. If the root account is compromised, your cloud assets face a very high security risk. Remote login protection provides location verification for your account login. If a remote login is detected, a second verification will be conducted to reduce the likelihood of malicious login to the root account. |
The root account should not enable API keys. | Basic Security Protection | account | High | Default security standards | The root account by default has access to all Tencent Cloud resources under the account and has super administrator permissions. The API key is the identity credential for programmatic access to the account and is often written into the configuration, making it prone to leakage. If the API key is leaked, an attacker can manipulate all your assets in the cloud using this key, posing a high risk. The account information involved in this check may be subject to synchronization delays, so it is recommended to have a check interval of more than 4 hours. |
Yes
No
Was this page helpful?