This topic describes how to use and maintain trusted instances that are based on virtual Trusted Platform Module (vTPM). You can search for trusted instances, view the trusted status of trusted instances, and handle abnormal instance status.
View the trusted status of an instance
The integrity measurement benchmark is generated when an instance is created. The measurement values collected on subsequent instance boots are compared with the benchmark measurement value to determine whether the instance has changed. The comparison result indicates the trusted status of the instance and is displayed in the Security Center console.
Log on to the ECS console.
In the left-side navigation pane, choose .
On the Instances page, click Filter by Tag and select acs:ecs:supportVtpm to search for trusted instances.
Find the trusted instance that you want to view and click the icon in the Operating System column.
You are directed to the Host page in the Security Center console.
Click the Trusted information tab to view the trusted status of the instance.
The circles in the ① Asset startup overview section are mapped with the components listed in the ② Trusted Status of components in assets section. The color of each circle in the ① Asset startup overview section indicates whether the corresponding stage is normal:
If all of the circles are green, the instance boot process is normal. In this case, the values in the Actual measure column (the actual status collected by Alibaba Cloud Trusted System) are the same as those in the Standard value column.
If an error occurs at one stage during the instance boot process, the corresponding circle turns red and those that follow turn gray. You can view detailed information about the stage on the Alerts tab and fix the exception. For more information, see the Handle trust exceptions section of this topic.
If an error message similar to "your device is in the unmeasured state" is displayed on the Trusted information tab, it indicates that the trusted instance has not reported valid measurements for a long time. In this case, no detailed trust information about the instance is displayed in the Security Center console. For information about how to resolve this issue, see the Handle the unmeasured state section of this topic.
Platform Configuration Registers (PCRs) are storage units of trusted security devices and are capable of reliably storing the status information collected during the instance boot process. Each PCR corresponds to a specific stage of the instance boot process and the PCR value represents the status of the measured object at the stage. If the actual measurement value stored in the PCR is the same as the expected standard value, the stage is considered to be as expected. The following objects are measured at each stage of the instance boot process:
pcr0: the Static Root of Trust for Measurements (SRTM), BIOS, embedded option ROM, and PI driver.
pcr1: the host platform configurations.
pcr2: the Unified Extensible Firmware Interface (UEFI) driver and application code.
pcr3: the UEFI driver, application configurations, and application data.
pcr4: the UEFI boot management code (typically MBR).
pcr5: the UEFI boot management code (typically MBR), boot-related data (data used by the UEFI boot management code), and GUID Partition Table (GPT) partition table.
pcr6: the specific UEFI firmware defined by the platform manufacturer.
pcr7: the secure boot policy.
pcr8: the critical commands to be run as provided in configuration files such as grub.cfg and command line information transmitted to the Linux kernel. Non-critical commands are not measured, such as the command that are used to define boot menu titles.
pcr9: the GRand Unified Bootloader (GRUB) module, Linux kernel, and initramfs.
ISO provides detailed definitions. For more information, see ISO/IEC 11889:2015 Trusted Platform Module Library.
Handle trust exceptions
If an error occurs at one stage during the instance boot process, the corresponding circle on the Trusted information tab turns red. You must go to the Alerts tab to view detailed alert information and fix the exception.
Click the Alerts tab and set Alert type to Trusted exception.
On the right side of alert information, click Details to view detailed error information.Note
If the alert is not handled, it is periodically raised, but no more alerts are generated for the exception. Only the time when the alert last occurred is displayed in the Last Occurred At column.
Contact the system administrator to check whether system upgrade and maintenance operations have been recently performed, such as upgrading the operating system kernel, changing the operating system boot parameters, and modifying the initial file system (initramfs). Then, take different measures to fix the exception based on actual situations.
Scenario 1: If no system upgrade or maintenance operations have been performed recently, ignore the alert after you check and fix the exception.
In this scenario, an alert may occur because a security event occurred on your instance. For example, the instance is damaged by malware, such as rootkit or bootkit. We recommend that you contact the system administrator to perform an in-depth check on the instance, fix the exceptions, and then ignore the alert. Perform the following steps:
Enable and use the Anti-Virus and Vulnerabilities features in the Security Center console. Then, upgrade the virus library to the latest version, check for malware in the system, and then fix the vulnerability or delete the malware.
On the Alerts tab, click Handle.
Select Ignore and click Immediate processing.
If an alert is generated on multiple instances, you can select Handle the same alarms at the same time to handle the same alert on the instances at once.Important
Alerts that are ignored are still displayed on the Trusted information tab. The ignored alerts are continuously generated because Security Center periodically generates security alerts. These situations persist until you restart the instance and pass the verification.
Scenario 2: If a system upgrade or maintenance operation has been performed recently, add a whitelist after you check and fix the exception.
If a system upgrade or maintenance operation has been performed recently, the system status after the upgrade or maintenance becomes the new benchmark status of your system. The status value of each stage during the instance boot process also becomes the new benchmark value of the corresponding PCR. In this case, you must select Add whitelist.
After the collected actual measurement values are added to the whitelist, the values become the new benchmark measurement values.
Handle the unmeasured state
If an error message similar to "your device is in the unmeasured state" is displayed on the Trusted information tab, it indicates that the trusted instance has not reported valid measurements for a long time. In most cases, this situation occurs because the trust client cannot access the Trusted System service. You can perform the following steps to troubleshoot the issue:
Check the instance Resource Access Management (RAM) role of the trusted instance.
If you did not attach an instance RAM role to the trusted instance, attach the required instance RAM role to the instance.
If you attached an instance RAM role to the trusted instance, check whether the instance RAM role has access to the Trusted System service. For more information, see Create a trusted instance.
Check network connectivity.
Run the following command on the trusted instance to check network connectivity:
Replace <region-id> with the region ID of the trusted instance. If a command output is returned, it indicates that network connectivity is good.
Check the security group settings.
Check the settings of the security groups with which the trusted instance is associated and make sure that the security groups do not deny access to
Check the status of the client.
systemctl status t-trustclientcommand to check the status of the client. If the client is not in the
runningstate, run the
systemctl restart t-trustclientcommand to restart the client.