Episode #259
Introduction
In episode 259 of our SAP on Azure video podcast we talk about Trusted Launch VMs for SAP. Azure offers Trusted Launch as a seamless way to improve the security of Generation 2 virtual machines (VM). Trusted Launch protects against advanced and persistent attack techniques. Robert Biro exlains the concepts and outlines how this can also be used in the context of SAP.
Find all the links mentioned here: https://www.saponazurepodcast.de/episode259
Reach out to us for any feedback / questions:
- Goran Condric: https://www.linkedin.com/in/gorancondric/
- Holger Bruchelt: https://www.linkedin.com/in/holger-bruchelt/
#Microsoft #SAP #Azure #SAPonAzure #TrustedCompute #VM #Security
Summary created by AI
- Overview of Trusted Launch on Azure:
- Goran, Holger, and Robert discussed the Trusted Launch security feature on Azure, its role in protecting virtual machines, and its relevance for SAP on Azure customers, emphasizing its importance as it becomes the default deployment option.
- Definition and Purpose: Robert explained that Trusted Launch is a security feature providing boot protection for Azure virtual machines, ensuring a trusted environment by protecting against rootkits, bootkits, and unauthorized kernel drivers. It is distinct from confidential computing, though it can integrate with it.
- Technical Requirements: Trusted Launch requires Generation 2 VMs, which support more features and a different boot process (UEFI). Robert clarified that Trusted Launch is a free feature and is implemented as a security profile on top of Generation 2 VMs.
- Trusted Launch Settings: Robert detailed that Trusted Launch includes settings such as Secure Boot, Virtualized TPM (vTPM), and Boot Monitoring (integrated with Microsoft Defender for Cloud). These can be toggled individually, with Secure Boot and vTPM recommended unless there are specific reasons not to enable them.
- Supported VM Types and Exceptions: Robert noted that while most Generation 2 VMs support Trusted Launch, there are exceptions, such as all M series VMs and VMs with GPUs, which do not support Trusted Launch. Most D and E series VMs for SAP workloads are supported.
- Trusted Launch Support for SAP Workloads:
- Robert, Goran, and Holger clarified that Trusted Launch is fully supported for SAP workloads on Azure, with explicit documentation and recommendations for its use, provided both the VM and operating system are compatible.
- SAP Node Documentation: Robert mentioned that SAP Node 3655202 and central note 1958533 have been updated to explicitly confirm Trusted Launch support for SAP workloads, giving customers clear guidance.
- No SAP Software Changes Required: Robert emphasized that SAP software, including the NetWeaver stack, does not require any changes or integration for Trusted Launch; customers should follow standard Azure documentation for enabling the feature.
- Recommendation for SAP Customers: The team recommended that SAP customers enable Trusted Launch for enhanced security, with further options like Secure Boot and vTPM depending on customer requirements and testing.
- Enabling and Migrating to Trusted Launch:
- Robert provided a detailed explanation of how SAP customers can enable Trusted Launch on existing Generation 2 VMs or migrate from Generation 1 to Generation 2 with Trusted Launch, outlining the technical steps, dependencies, and limitations.
- Enabling Trusted Launch on Gen 2 VMs: For existing Generation 2 VMs, Trusted Launch can be enabled by deallocating the VM and changing the security profile, provided the VM and OS are compatible. This process is straightforward and reversible.
- Migrating from Gen 1 to Gen 2: There is no direct upgrade path from Generation 1 to Generation 2 VMs; migration requires recreating the VM. For Linux, this is usually straightforward if the OS is up to date, while for Windows, an MBR-to-GPT conversion is necessary to support UEFI boot.
- OS Readiness and Dependencies: Customers must ensure OS readiness before migration, verifying UEFI boot support and, for Windows, performing MBR-to-GPT conversion. Microsoft provides scripts and documentation for these checks, but the responsibility lies with the customer.
- Rollback Limitations: Once a VM is migrated from Generation 1 to Generation 2 with Trusted Launch, rollback is not possible; reverting requires recreating the VM from backup. For Generation 2 VMs, reverting Trusted Launch is possible by changing the security profile.
- SAP Licensing Implications During Migration:
- Robert and Goran discussed the impact of migrating to Generation 2 VMs with Trusted Launch on SAP licensing, specifically the need for a new hardware key and license for Linux systems using the saplicense program.
- Hardware Key Changes: Migrating from Generation 1 to Generation 2 VMs changes the hardware key as detected by the saplicense program, requiring a new SAP license for Linux systems. This does not affect Windows systems or HANA workloads.
- Grace Periods: For SAP Java stack, the grace period after hardware key change is typically 30 minutes, while for ABAP systems, it is usually 30 days, after which the system may shut down if the license is not updated.
- Performance and Cost Considerations:
- Goran asked about potential performance or cost impacts of Trusted Launch, and Robert confirmed there are no performance drawbacks or additional costs associated with enabling Trusted Launch.
- No Performance Impact: Trusted Launch provides boot protection without ongoing encryption or performance overhead, so customers should not expect any performance degradation.
- No Additional Cost: Trusted Launch is a free feature on Azure, with no extra charges for enabling it on supported VMs.