Azure Stack– Secure by design

Leave a Comment / By / 28. July 2017

Previously I have blogged about the underlying architecture and features which is going to be part of Azure Stack → http://msandbu.org/what-is-azure-stack-and-want-is-the-architecture/ Microsoft recently announced the launch of Azure Stack as well → https://azure.microsoft.com/en-us/blog/microsoft-azure-stack-is-ready-to-order-now/

Responsibility model in Cloud

Now I want to focus a bit on one aspect that was not included in the previous blogpost, and that also has not been highlighted in Microsoft’s blog which is security in the platform.

In a Public Cloud scenario, there is a distinct line between what is the public cloud vendor’s responsibility and what is the customer’s responsibility. The area of responsibility changes when a customer goes from IaaS (Infrastructure as a service) to PaaS or SaaS model. In the shift from IaaS to PaaS more responsibility move to the cloud provider. As it would be if we were to go from a SQL server running inside a virtual machine to a Azure SQL Database where we as a customer have no control of the virtual instances that deliver the service.

Shared responsibility model between customer and cloud provider

In Azure there are numerous of security mechanisms in place to ensure that data is safeguarded, going from the physical aspect up to the different services running on top. So an example from a customer perspective. In public Azure a customer does not have access to the hypervisor layer, as we might be used to in a regular virtualization environment. We as a partner havethe same limitations, so therefore when managing customers we have to consider the same limitation. This means we have to do management and in a different manner.

Security on the platform layer

One of the design principles that Microsoft did with Azure Stack was that it should be a self-contained platform and be consistent with public Azure, which meant that management needed to have the same mechanisms in place.

With Azure Stack from a management perspective we only have access to the admin portal where we have no visibility into customer workloads. We can only use the admin portal to create tenant subscriptions, do Azure Stack infrastructure management and also get health status about the platform and audit information about administrator activities.

One of the security design principles that Microsoft used for Azure and Azure Stack is something called “Assume breach”. Assume breach is a philosophy where we already assume that my system is compromised or will be compromised. So how can the platform detect the breach and how to limit the effect of an attack. Microsoft therefore put in place numerous security mechanisms in Azure Stack such as

  • * Constrained Administration
    * Least privileged account – The platform itself has a set of service accounts used for different services which are running with least privilege
    * Administration of the platform can only happen via Admin portal or Admin API.
    * Locked down Infrastructure

    • * Application Whitelisting –  Used so only code that is digitally signed  Microsoft or signed by Azure Stack OEM will run on the system, any other executable by other non-signed or third party will not run.
      * Least-privileged communication – Means that internal components in Azure Stack can only talk with components that it is intended to.
      * Network ACLs – Everything is blocked by default using firewall rules.
      * Sealed hosts – No access to the underlying hosts directly

    • * Lifecycle management – Microsoft together with the OEM vendors will provide full lifecycle management using the lifecycle host to do uninterrupted system patching, such as firmware, drivers, OS patches and so on.

The Second security design principle that Microsoft used is hardened by default, which means that the underlying operating system has been fine tuned on security.

  • * Data at rest encryption – All storage is encrypted on disk using Bitlocker, unlike in Azure where you need to enable this on a tenant level. Azure Stack still provides the same level of data redundancy using three way copy of data.
    * Strong authentication between infrastructure components
    * Security OS baselines – Using Security Compliance Manager to apply predefined security templates on the underlying operating system
    * Disabled use of legacy protocols – Disabled old protocols in the underlying operating system such as SMB 1 also with new security features protocols such as NTLMv1, MS-CHAPv2, Digest, and CredSSP cannot be used.

  • Windows Server 2016 security features
    * Credential Guard – Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them.

    • * Code Integrity – A feature used in Credential Guard, Allows Only code that is verified by Code Integrity, usually through the digital signature that you have identified as being from a trusted signer, is allowed to run. This allows full control over allowed code in both kernel and user mode.

    • * Anti malware – Uses Windows Defender on the underlying virtual machines which make the platform and on the host operating system.

    • * Uses Server Core to reduce attack surface and restrict use of certain features.

Security at tenant layer

Now we have looked at the different aspects of security mechanisms which are operating at the platform layer which are invisible for the different tenants running on Azure Stack. So let us take a closer look at the security features we can use as a tenant in Azure Stack.

  • Azure Resource Manager – ARM by itself has a RBAC model which is used to determine what kind of resources a user has access to a subscription, resources group and then different objects. Access within ARM can be given either at a subscription level using the different built-in roles or a custom role. Users can also inside each tenant can be given access to a certain resource group which might contain one or multiple objects such as virtual machines. Here they might only be given access to do restarts of the virtual machine inside a certain resource group or we can create a custom role with specific permissions to certain objects.

Overview of the role based access control in Azure Stack and different levels of access

  • Azure Resource Policies – Can be used to enhance regular ARM access rules, such as allow a user to only provision virtual machines with a certain instance type or to enforce tags on objects.

  • Network Security Groups – Allows for five-tuple firewall access rules which can be defined on either for each network card or per subnet level. This means that we can define firewall rules regardless of which guest OS is running and can define rules before the traffic can leave the virtual NIC.

  • Virtualized networking layer – Azure Stack is using a software-defined networking solution which itself is being managed by the underlying network controller. This however is using a tunneling protocol called  VXLAN which is used to isolate each tenant into its own virtual network. Using VXLAN it does not make it to open to traditional layer 2 attacks which it would using regular VLAN.

  • TLS/SSL –  which uses symmetric cryptography based on a shared secret to encrypt communications as they travel over the network. This is enabled by default on all platform service and API’s which are available in Azure Stack.

  • IPsec – an industry-standard set of protocols used to provide authentication, integrity, and confidentiality of data at the IP packet level as it’s transferred across the network. This is used when setting up Site to Site VPN connection with a Gateway in Azure Stack.

  • Azure Key Vault – helps you easily manage and maintain control of the encryption keys used by cloud apps and services. Key Vault can for instance be used to store private keys of Digital Certificates used for App Service or virtual machines.

  • What do we still need to think about?
    Even if Microsoft comes with a lot of security enhancements and features in Azure Stack which are enabled by design, there are still alot of considerations we need to think about when moving workloads to Azure Stack.

  • * Azure Stack does not provide a solution to do management of virtual machines – This means that we still need to do patching, updates, monitoring and management of in-guest applications and services on virtual machines.

  • * Azure Stack does not provide a solution that does backup of data and virtual machines  – This mean that we still need to use some form of in-guest backup solution to maintain copies of our data.

  • * Azure Stack does not provide an antimalware solution for in-guest VM – This means that we still need to have some form of malware protection for  in-guest virtual machines.

  • * Azure Stack does not have Azure Security Center so if you open up the virtual firewall to your virtual machines you will not get notified.

Leave a Reply

Scroll to Top