Security in plaintext: use Shielded VMs to harden your GCP workloads

Security in plaintext: use Shielded VMs to harden your GCP workloads

2018-08-07 admin Uncategorized No comments

Source: Security in plaintext: use Shielded VMs to harden your GCP workloads from Google Cloud

Trust is a prerequisite of moving to the cloud. When evaluating a cloud provider, you want to know that it helps keep your information safe, helps protect you from bad actors, and that you’re in control of your workloads.

Trust has to be maintained starting from hardware and firmware, as well as host and guest operating systems. For example, a BIOS can be dynamically compromised by a bad NetBoot, or act as a “confused deputy” based on untrusted input reported by BIOS configuration parameters, leaving the OS vulnerable to privilege escalation attacks. A guest OS can also be dynamically compromised by attacking its kernel components via remote attack, by local code gaining escalation privileges, or by insiders (e.g., your privileged employees).

That’s why we recently introduced Shielded VMs in beta, so you can be confident that workloads running on Google Cloud Platform (GCP) haven’t been penetrated by boot malware or firmware rootkits. Unfortunately, these threats can stay undetected for a long time, and the infected virtual machine continues to boot in a compromised state even after you’ve installed legitimate software. Working alongside Titan, a custom chip that establishes root-of-trust , Shielded VMs help assure you that when your VM boots, it’s running code that hasn’t been compromised.

Shielded VMs provide the following security features:

Trusted firmware based on Unified Extended Firmware Interface (UEFI) 2.3.1 to replace legacy BIOS sub-systems and enable UEFI Secure Boot capability

vTPM, a virtual Trusted Platform Module , which validates your guest VM pre-boot and boot integrity, and generates and protects encryption keys. vTPM is fully compatible with Trusted Computing Group TPM 2.0 specifications validated with FIPS 140-2 L1 cryptography. vTPM is required to enable Measured Boot. In addition, vTPM also enables the guest operating system to generate and securely protect keys or other secrets.

Secure Boot and Measured Boot to help protect VMs against boot- and kernel-level malware and rootkits.

Integrity measurements collected as part of Measured Boot that are available to you via Stackdriver and help to identify any mismatch between the “healthy” baseline of your VM and current runtime state.

Secure and Measured Boot help ensure that your VM boots a known firmware and kernel software stack. vTPM underpins Measured Boot by providing guest VM instances with cryptographic functionality, i.e., cryptographically verifying this stack and allowing the VM to gain (or fail to gain) access to cloud resources. Secure Boot helps ensure that the system only runs authentic software, while Measured Boot gives a much more detailed picture about the integrity of the VM boot process and system software.

With Shielded VMs, we aim to protect the system from the following attack vectors:

Malicious insiders within your organization: with Shielded VMs, malicious insiders within your organization can’t tamper with a guest VM image without those actions being logged. Nor can they alter sensitive crypto operations or easily exfiltrate secrets sealed with vTPM.

Guest system firmware via malicious guest firmware, including UEFI drivers.

Guest OS through malicious guest-VM kernel or user-mode vulnerabilities.

Currently in beta, Shielded VMs are available for the following Google-curated images:

windows Server 2012 R2 (Core and Datacenter)

Windows Server 2016 (Core and Datacenter)

Windows Server version 1709 Datacenter Core

Windows server version 1803 Datacenter Core

Container-Optimized OS 68+

Ubuntu 1804

Container-Optimized OS is actively used in several GCP products including Google Kubernetes Engine, Cloud Machine Learning, Cloud Dataflow, and Cloud SQL.

Now let’s talk about our hardening capabilities in more detail and explain how you can benefit from them.

Boot basics

As a refresher, here’s an overview of the current boot process on GCP:

The Titan chip verifies that the production server has booted known system firmware.

Assuming an uncompromised host OS BIOS, the Titan chip then verifies that the production server boots a Google-approved OS image.

Assuming an uncompromised OS, it checks that the production server obtained its credentials and is ready to load the host OS with the KVM hypervisor .

KVM then passes control to the VM instance’s UEFI firmware, which then configures the image properly, and loads the bootloader into system memory.

The guest firmware boots and then passes execution control to the bootloader, which loads the initial Shielded OS image into system memory and passes the execution control to the guest operating system.

The guest OS continues loading kernel drivers that are digitally signed and validates them using vTPM.

Once those steps are complete, you have a fully loaded Shielded VMs up and running. During boot, Shielded VMs also implement Secure Boot and Measured Boot, and performs runtime boot integrity monitoring.

Secure Boot

With the increase in privileged software attacks and rootkits, more customers require Secure Boot and root-of-trust for their VMs. We enable UEFI Secure Boot via trusted firmware to help ensure the integrity of the system firmware and system boot loader. Secure Boot helps protect the system against malicious code from being loaded early in the boot sequence, by procuring control of the OS and masking its presence. With Secure Boot, we offer authenticated boot guest firmware and a bootloader along with cryptographically signed boot files. During every boot, Secure Boot makes sure that the UEFI firmware inspects EFI binaries for a valid digital signature, and verifies that the system firmware and system boot loader are signed with an authorized cryptographic key. If any component in the firmware is not properly signed or not signed at all, the boot process is stopped.

Measured Boot

Working with the vTPM, the goal of Measured Boot is to ensure the integrity of the critical load path of boot and kernel drivers, offering protection against malicious modifications to the VM. This is accomplished by maintaining chain-of-trust measurements throughout the entire boot process, thus allowing vTPM to validate that kernel and system drivers have not been tampered with, or rolled back to signed-but-unpatched binaries, or load binaries out of order.

vTPM crypto processor

Trusted Platform Module (TPM) devices have become the de-facto standard for providing strong, low-cost cryptographic capabilities in modern computer systems. TPM adoption is on the rise, and many security scenarios take advantage of this capability. The goal of the vTPM service is to provide guest VM instances with TPM functionality that is TPM2.0 compatible and FIPS 140-2 L1 certified. We also exposed open-source GoLang TPM apis ( go-TPM ) to ensure that you will be able to use vTPMs easily to seal your secrets and keys, protecting them against exfiltration.

Integrity measurements

Shielded VMs offer easy access to the integrity reports via Stackdriver, so you can obtain them for your own verification. We measure the integrity of your VMs based on the implicitly trusted default baseline, and enable you to update it. You can define your own policy and specify custom actions if the integrity report indicates that your VM does not meet your expected healthy baseline. You will be able to the Stackdriver Pub/Sub sync to associate custom actions with any integrity failures: e.g., you can stop a VM instance and export it for forensic investigation. Or, if you know why integrity checks failed, you can update the baseline to include these changes into a new baseline. From then on, we will be measuring the integrity state based on the new definition you provided.

Getting started with Shielded VMs

In the beta release, you can create a VM instance GCP console to give you more granular control over Shielded VMs functionality. By default, all options are enabled.

When you create an instance with Shielded VMs configuration options, a shield icon next to the VM boot disk denotes that Shielded VMs are enabled.

Boot disk selection with a Shielded VMs enabled image.

You can adjust your Shielded VMs configuration options from the VM instance details page, including the option to enable or disable Secure Boot and vTPM, or enable/disable Integrity monitoring. You can also create instance templates that use Shielded VMs.

VM instance details showing Secure Boot, vTPM and Integrity Monitoring enabled.

You can also use gcloud APIs to manage Shielded VMs settings, including creation of new Shielded VMs, or enabling or disabling individual Shielded VMs features in an existing instance. To do so, we created dedicated security IAM roles, compute.instances.updateShieldedVmConfig and compute.instances.setShieldedVmIntegrityPolicy , which can be granted to custom IAM roles in addition to the default SecureAdmin IAM role. We want to ensure that highly privileged operations, like secure boot disabling or turning off vTPM or Integrity monitoring, can be done only by dedicated administrators using separation of duties principle in mind. These privileged operations are recorded with tamper-evident logs, and shared with our users so the actions can be monitored and audited.

Conclusion

Every day we hear of new methods of exploiting vulnerabilities in computing systems. Fortunately, while the attackers get more sophisticated, we’re working hard to stay one step ahead of them. Shielded VMs UEFI firmware, Secure Boot, Measured Boot, vTPMs and Integrity Monitoring offer integrity verification and enforcement of your VM boot system, giving you confidence in your business-critical cloud workloads. To learn more, watch the screencast below, fill out this form to hear about upcoming releases, and sign up for the Shielded VMs discussion group.

除非特别声明，此文章内容采用 知识共享署名 3.0 许可，代码示例采用 Apache 2.0 许可。更多细节请查看我们的 服务条款 。

Tags: AdWords