{"id":23523,"date":"2023-05-11T09:00:00","date_gmt":"2023-05-11T16:00:00","guid":{"rendered":"https:\/\/azure.microsoft.com\/en-us\/blog\/?p=23523"},"modified":"2025-06-16T05:45:58","modified_gmt":"2025-06-16T12:45:58","slug":"microsoft-azure-security-evolution-embrace-secure-multitenancy-confidential-compute-and-rust","status":"publish","type":"post","link":"https:\/\/azure.microsoft.com\/en-us\/blog\/microsoft-azure-security-evolution-embrace-secure-multitenancy-confidential-compute-and-rust\/","title":{"rendered":"Microsoft Azure security evolution: Embrace secure multitenancy, Confidential Compute, and Rust"},"content":{"rendered":"\n

In the first blog<\/a> of our series on Azure Security<\/a>, we delved into our defense-in-depth approach for tackling cloud vulnerabilities. The second blog<\/a> highlighted our use of variant hunting to detect patterns of vulnerabilities across our services. In this installment, we will introduce our game-changing bets that will enable us to deliver industry-leading security architectures with built-in security<\/a> for years to come, ensuring a secure cloud experience for our customers. We will discuss our focus on secure multitenancy and share our vision for harnessing the power of Confidential Compute and the Rust programming language to protect our customers’ data from cyber threats. By investing in groundbreaking security strategies, such as Secure Multitenancy, Confidential Compute, and the Rust programming language, Azure provides customers with robust, built-in security measures that not only protect their data but also enhance the overall cloud experience, giving customers the confidence to innovate and grow their businesses securely.<\/p>\n\n\n\n

Secure multitenancy with robust compute, network, and credential isolation<\/h2>\n\n\n\n

In our first blog<\/a>, we touched on the benefits we\u2019ve seen from improvements in compute, network, and credential isolation. Now, we want to dive deeper into what this means. For compute isolation, we\u2019re investing heavily in hardware-based virtualization (HBV), the foundation of running untrusted code in Azure. Traditional Virtual Machines are at the core of many Azure Services hosting customer workloads. Our current bounty of up to USD250,000<\/a> on Microsoft Hyper-V vulnerabilities demonstrates our strong defense and highlights the importance of this boundary.<\/p>\n\n\n\n

Our innovations with HBV extends beyond traditional virtual machines (VMs). Azure Container Instances<\/a> (ACI) serve as our platform for running container workloads, utilizing HBV to isolate container groups<\/a> from each other. ACI container groups take advantage of the same HBV that powers Azure Virtual Machines, but they offer a platform tailored for modern container-based applications. Numerous new and existing services are moving to ACI as a simple, high-performance model for secure multitenancy. Building services atop secure foundations like ACI enables us to address many isolation problems centrally, allowing multiple services to benefit from fixes simultaneously. Furthermore, we’re excited to introduce HBV to Kubernetes workloads via industry-standard Kata Container support<\/a> in Azure Kubernetes Service<\/a>. Similar to ACI container groups, Kata Container pods utilize HBV for robust isolation of untrusted workloads. In the coming months, we’ll share more about our efforts to bring this approach to WebAssembly hosting, boasting single-millisecond overhead compared to hosting WebAssembly without HBV. For network isolation, we’re shifting services towards dedicated virtual networks per tenant and ensuring support for Private Links<\/a> which enable our services to communicate directly with customer-managed virtual networks. Shared networks have proven error-prone, with mistakes in network Access Control Lists or subnets leading to inadequate network isolation between tenants. Dedicated virtual networks make it difficult to accidentally enable connectivity between tenants that should remain separate.<\/p>\n\n\n\n

Credential isolation, on the other hand, involves using credentials scoped to the resources of a single tenant whenever possible. Employing credentials with minimal permissions ensures that even if vulnerabilities are discovered, credentials providing access to other tenants’ data aren’t readily available.<\/p>\n\n\n\n

Through significant investments in HBV and a focus on compute, network, and credential isolation, Azure is providing customers with enhanced security and isolation for their workloads. By developing innovative solutions such as Azure Container Instances, and bringing HBV to Kubernetes and WebAssembly hosting, we are creating a robust and secure multitenancy environment that protects data and improves the overall cloud experience. As we continue to strengthen Azure’s security foundation, we are also exploring new opportunities to further enhance our defense-in-depth approach. In the next section, we will discuss the role of Confidential Compute in adding an extra layer of protection to our customers’ data and workloads.  <\/p>\n\n\n\n

Confidential Compute: A new layer of defense<\/h2>\n\n\n\n

Since the dawn of cloud computing in Azure, we\u2019ve recognized the crucial role of HBV in running customer workloads on VMs. However, VMs only protect the host machine from malicious activity within the VM. In many cases, a vulnerability in the VM interface could allow a bad actor to escape to the host, and from there they could fully access other customers\u2019 VM. Confidential Compute presents a new layer of defense against these attacks by preventing bad actors with hosting environment access from accessing the content running in a VM. Our goal is to leverage Confidential VMs<\/a> and Confidential Containers<\/a> broadly across Azure Services, adding this extra layer of defense to VMs and containers utilized by our services. This has the potential to reduce the blast radius of a compromise at any level in Azure. While ambitious, one day using Confidential Compute should be as ubiquitous as other best practices have become such as encryption in transit or encryption at rest.<\/p>\n\n\n\n

Rust as the path forward over C\/C++<\/h2>\n\n\n\n

Decades of vulnerabilities have proven how difficult it is to prevent memory-corrupting bugs when using C\/C++. While garbage-collected languages like C# or Java have proven more resilient to these issues, there are scenarios where they cannot be used. For such cases, we\u2019re betting on Rust as the alternative to C\/C++. Rust is a modern language designed to compete with the performance C\/C++, but with memory safety and thread safety guarantees built into the language. While we are not able to rewrite everything in Rust overnight, we\u2019ve already adopted Rust in some of the most critical components of Azure\u2019s infrastructure. We expect our adoption of Rust to expand substantially over time.<\/p>\n\n\n\n

Our unwavering commitment<\/h2>\n\n\n\n

Our commitment to secure multitenancy, Confidential Compute, and Rust represents a major investment that we\u2019ll be making in the coming years. Fortunately, Microsoft\u2019s security culture is among the strongest in the industry, empowering us to deliver on these ambitious bets. By prioritizing security as an integral component of our services, we are helping our customers to build and maintain secure, reliable, and scalable applications in the cloud, while ensuring their trust in our platform remains steadfast. <\/p>\n\n\n\n

Learn more<\/h2>\n\n\n\n