© Julian Soh, Marshall Copeland, Anthony Puca, and Micheleen Harris 2020
J. Soh et al.Microsoft Azurehttps://doi.org/10.1007/978-1-4842-5958-0_7

7. Designing a Hybrid Datacenter

Julian Soh1 , Marshall Copeland2, Anthony Puca3 and Micheleen Harris1
(1)
Washington, WA, USA
(2)
Texas, TX, USA
(3)
Colorado, CO, USA
 

To understand what goes into a hybrid datacenter, you must first have a clear understanding of both public and private clouds. Both cloud types provide a variety of benefits over the traditional datacenter virtualization model. Cloud computing, in its most basic form, is the separation of the workload from the hardware (which virtualization does) and the operating systems and applications. This separation can exist on a single server at various levels—such as websites, SQL Server database instances, or the network layer—by using software-defined networking (SDN). Connecting to a cloud service provider (CSP) allows an organization to use the geographic distribution of cloud services to their advantage, without having to invest in real estate or the back-end processes associated with the acquisition, deployment, depreciation, updating, and retirement of the physical assets that make up the CSP infrastructure.

The term hybrid datacenter is the evolution of marketing terms. When the cloud was first discussed by various service providers, they were speaking of public clouds , where customers could go to consume their services over the Internet, or in some cases, over dedicated network connections. These public clouds were based on a shared, multicustomer, multitenant model. While these public clouds offered great economies of scale and low price points to customers, they were simply too constrained for certain workloads. Applications with multiple systems feeding into (or off of) them had too much complexity to move to public clouds. This created one of the varieties of private clouds, where the infrastructure was left on-premises.

Private clouds are frequently incorrectly referred to as such because of their virtual infrastructure. Private clouds are very similar to public clouds. IT clouds should provide the users high availability, disaster recovery, various levels of storage resiliency and performance, and workload elasticity where workloads can scale up and down or in and out. PaaS services may also be included, which allows multiple customers to use the same service without each requiring its own implementation. Yet, their data is logically segmented from each other to satisfy various security and regulatory compliance requirements.

Hyperconverged infrastructure (HCI) enabled hardware vendors to offer their customers software-defined compute, storage, and networking in a single platform. This is the first architecture from OEM vendors that truly allowed a private cloud as a turn-key solution. Prior to HCI, setting up a private cloud required very complex workflows to be manually coded, which allowed provisioning of storage, compute, and networking. HCI is ideal for customers whose workloads cannot move to the cloud, or the desire is to keep the workload local for performance reasons.

Air gapping is an example of regulatory compliance that drives HCI over a public cloud. The workload is not allowed to connect to another network, like the Internet or a LAN/WAN. Ultimately, connectivity, which we imply as bandwidth and latency, to the CSP is usually the bottleneck and key driver to keep a workload local to an organization. If the rate of change to the workload is too high, a given connection may not be able to keep up.

Globally, latency is the biggest connectivity challenge we face today from a networking perspective. The other key reason that a workload may need a private vs. a public cloud is when there are too many dependencies on other systems, where the overall effort to move a monolithic app and all of its dependent apps is too high or risky.

Networking Considerations

Networking is the foundation of cloud computing. In this section, we review the different methods of connecting to Microsoft Azure. While connecting to Azure over the Internet is a viable approach for certain workloads, the purpose of this chapter is to discuss networking in a hybrid model, so we’ll review the methods to connect on-premises to Azure. Each of the connectivity methods described in this section is available in all regions in all Azure clouds.

Depending upon where in the world your connectivity requirements exist, you may have different product options and pricing from your telco partners. Network connectivity to Microsoft Azure usually has several components that make up the connection, and hence the pricing. In this book, we’ll only be discussing the Microsoft part of the connectivity. Understanding your throughput requirements for both storage and networking is paramount to successfully architect a cloud solution.

Let’s use a high-performance computing (HPC) workload as an example. If you have terabytes (TB) or petabytes (PB) of data that you need to move into the cloud to perform analytics against, and there’s little time to do it, you may be better off performing the workload on-premises, or you may want to change the business process flow and have the data shipped to the cloud initially, instead of on-premises. An inverse example is if the data can be copied to the cloud from on-premises, the processing power of the cloud may be able to complete the workload so quickly that the timeframe consumed copying the data to the cloud may be negated.

Azure’s connectivity options consist of VPN, including Point-to-Site (P2S), Site-to-Site (S2S), VNet-to-VNet, ExpressRoute through a cloud exchange co-location, ExpressRoute through a Point-to-Point Ethernet connection, or ExpressRoute through an Any-to-Any (IPVPN) connection. For a detailed breakdown of the various Microsoft Azure connectivity services, please refer to Chapter 9 of this book.

If you’re interested in testing the latency to any Azure Datacenter, visit www.azurespeed.com/Azure/Latency. On this site, you can select whatever Azure region you desire, and test the latency in milliseconds (ms), as shown in Figure 7-1. It is important to note that you are testing from where you are running this web page, which means that any infrastructure you traverse is part of the test and adds to the latency. Your corporate office will likely test differently from a café or home. Figure 7-1 illustrates a test from an Xfinity home network to each of the USA Azure regions.
../images/336094_2_En_7_Chapter/336094_2_En_7_Fig1_HTML.jpg
Figure 7-1

Azure latency benchmarking

In 2020, Azure’s global network was the second-largest network in the world, with 58 regions across six continents and 140 countries. Azure has 130 points of presence (POP) across 80 metropolitan areas, and that does not include any of the POP city locations for Azure’s content delivery network (CDN) from Akamai. Akamai is a Microsoft partner that has more 150,000 servers across the world, acting as the Internet’s “edge.” This partnership is a significant part of Azure’s CDN.

PaaS Considerations

Azure PaaS services are exposed to the public via public IP addresses. These services can be accessed over the Internet or connected to over an ExpressRoute circuit. Due to the nature of the services using public IP addresses, many customers have concerns around security and privacy when traversing the Internet, regardless of the services using end to end encryption. ExpressRoute, which is a private, dedicated circuit, can have Microsoft peering enabled to connect to Azure PaaS services. Two new, completely different, services now exist within Azure that allows different methods of connecting to Azure PaaS services to private IP addresses; Azure Private Link and Azure service endpoints. These new connectivity methods provide a manner to connect to Azure PaaS services over private IPs, satisfying many of the security concerns.

Azure Private Link

This process of mapping Azure PaaS services to private IP addresses is called Azure Private Link. Azure Private Link allows customers to map specific Azure PaaS resources to a private IP address on one of their VNets. This allows all the traffic to flow over customer ExpressRoute circuits with private peering, or customers can use Azure VPN services to access the VNet where the PaaS Private Link workloads exist. The key feature distinction of Azure Private Link is that it is mapping a single Azure PaaS resource, not the entire Azure PaaS service, as shown in Figure 7-2, to a customer VNet over the Microsoft Azure backbone network. Any network security group (NSG) rules apply to the VNet the PaaS service is mapped to. This solution provides the desirable data exfiltration protection on PaaS services. Figure 7-2 depicts how an Azure Private Link works.
../images/336094_2_En_7_Chapter/336094_2_En_7_Fig2_HTML.jpg
Figure 7-2

Azure Private Link traffic flow

A list of the PaaS services supporting Azure Private Link is at https://docs.microsoft.com/en-us/azure/private-link/private-link-overview.

Azure Virtual Network Service Endpoints

Azure Virtual Network service endpoints extend your VNet to the Azure PaaS services over the Microsoft Azure backbone network. This means that your VNet traffic does not go out over the Internet; it stays internal to Microsoft’s network. This also means that the traffic to your PaaS service must go over the private connection, not the Internet. Traffic going out a VNet to an Azure PaaS service needs to go through a Network Virtual Appliance (NVA) or firewall to prevent data exfiltration. Azure Virtual Network service endpoints can only be used from IaaS workloads to PaaS workloads, not for on-premises to PaaS.

Force-tunneling lets organizations “force” all Internet traffic back to on-premises. This is a common architecture when there is a desire to log or monitor inbound or outbound Internet traffic. Force tunneling is common across many enterprises for this reason and required for most governments’ networks. Since Internet-bound traffic must return to on-premise, workloads in Azure IaaS, such as VMs, need to traverse down to on-premise over VPN or ExpressRoute, then out the organization’s Internet connection to get to the service. This is undesirable due to the long trip and latency associated with the large number of hops required to get from a VM in IaaS to a PaaS server, such as a SQL database.

Azure Virtual Network service endpoints allow you to get directly to the PaaS service from IaaS workloads, even when force-tunneling is enabled, providing the most optional traffic flow. Figure 7-3 illustrates how Azure service endpoints traffic flows with force-tunneling routes enabled.
../images/336094_2_En_7_Chapter/336094_2_En_7_Fig3_HTML.jpg
Figure 7-3

Azure Virtual Network service endpoint traffic flow

A list of the PaaS services supporting Azure Virtual Network service endpoints is at https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview. For a detailed breakdown of the various Microsoft Azure connectivity services, please refer to Chapter 9 of this book.

Identity and Access Management

Identity is the foundation of all security. Microsoft Azure Active Directory is a highly secure cloud extension of Microsoft Active Directory and is Microsoft’s identity and access management as a service (IDaaS) solution. Azure Active Directory (AAD) is Microsoft’s hybrid identity utilizing conditional access (CA) and multifactor authentication (MFA) with a variety of MFA options, including smart cards, certificates, biometrics such as fingerprint and facial recognition with Windows Hello.

The Microsoft Azure Active Directory platform is an extension of on-premises user accounts, which authorizes (AuthZ) and authenticate (AuthN) users against a variety of Microsoft workloads (such as Office 365) and non-Microsoft workloads, including more than 2800 SaaS applications available in the Azure Active Directory Marketplace (https://azuremarketplace.microsoft.com/en-us/marketplace/apps/category/azure-active-directory-apps).

Azure Active Directory comes in several versions, including Free, Office 365, Premium 1 (P1), and Premium 2 (P2). Each of these versions builds upon the previous and total represent 49 distinct features. For a full list of these features and pricing, refer to https://azure.microsoft.com/en-us/pricing/details/active-directory/. Some of the more significant features include single sign-on (SSO), MFA, Self-Service Password Reset (SSPR), and Azure AD Join, mobile device management (MDM) autoenrollment, and privileged identity management (PIM).

Hybrid Identity is the creation of the cloud identity from some of the attributes of the on-premises identity. These attributes are synchronized via the Azure AD Connect sync process. Administrators can choose which attributes to synchronize via Azure AD Connect; for example, if some AD attributes contain PII, the administrators can choose not to sync those to AAD. There are approximately 200 attributes synchronized per use object for Office 365 Pro Plus, SharePoint Online, Exchange Online, Teams, Azure RMS, Intune, Dynamics, Windows 10, third-party apps, and a few other categories. For a detailed list, please refer to https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-sync-attributes-synchronized#attributes-to-synchronize. Figure 7-4 depicts how Microsoft Azure Cloud Services are layered on top of Azure Active Directory, which is usually synchronized for enterprise-size customers.
../images/336094_2_En_7_Chapter/336094_2_En_7_Fig4_HTML.jpg
Figure 7-4

Azure AD Hybrid ID cloud service in a hybrid datacenter

Azure AD also includes Azure Domain Services (AAD DS), which allows administrators to join computers directly to the Azure AD domain, apply group policies (GPO), and use Kerberos/NTLM authentication without having to deploy domain controllers. Azure AD authenticates the systems and users with their corporate domain credentials.

Azure AD Domain Services is a highly available LDAP solution that works with cloud-only AAD and AAD that has been replicated from on-premises.

As shown in Figure 7-5, Azure AD includes a B2C offering that allows AAD Identity and Access Management (IAM) to customer-facing apps. Customers can use their existing corporate credentials, their preferred accounts in social media platforms (including Twitter, Facebook, Microsoft, Google, Amazon, LinkedIn, or local identities) to get single sign-on to the applications you have published. AAD B2C also supports third-party verification. Since the use of social media platform accounts can be enabled, a verification process is supported to validate the user is who they say they are. Figure 7-5 depicts the workflow for third-party verification.
../images/336094_2_En_7_Chapter/336094_2_En_7_Fig5_HTML.jpg
Figure 7-5

Third-party verification of AAD B2C account

For a thorough description of the Azure Active Directory B2C feature, please refer to https://docs.microsoft.com/en-us/azure/active-directory-b2c/technical-overview.

Security and Monitoring

Security is paramount for Microsoft Azure. Security in Azure is a partnership between you, the customer, and Microsoft, the CSP. Microsoft can only secure so much of the infrastructure. If you set up a web server that sends passwords in clear text, that’s outside the realm of Microsoft’s responsibilities. The responsibilities and controls for Azure services and application security vary depending upon which Azure cloud services you’re consuming. Most organizations are completely responsible for their on-premises datacenter, or it may be shared with a managed service partner.

Figure 7-6 illustrates how as you move from IaaS to PaaS to SaaS, the amount of responsibility for the security and availability of the workload moves more toward the CSP. IaaS has Microsoft managing the Azure compute, networking, and storage “fabric.” In contrast, the customer manages everything from the networking to the operating system environments (OSE) in the VMs up to the data layer. PaaS services allow Microsoft to manage more of the stack, including the operating systems and platforms hosting the services.

SaaS allows Microsoft to manage infrastructure, OS, applications, and data storage. Figure 7-6 shows how as you move from on-premises to SaaS cloud services, the management responsibility moves toward the CSP, and the cost drops due to economies of scale.
../images/336094_2_En_7_Chapter/336094_2_En_7_Fig6_HTML.jpg
Figure 7-6

Azure cloud service responsibility matrix

At the time of publishing, Microsoft has approximately 800 NIST (National Institute of Standards and Technology) security controls across 262 Azure cloud services. Fifty of these services are IaaS, and 212 are PaaS services. Across these 262 Azure services, Microsoft maintains approximately 92 regulatory compliances, which include global, government, industry, and regional certifications. A full list of Microsoft regulatory compliance is at https://docs.microsoft.com/en-us/microsoft-365/compliance/offering-home?view=o365-worldwide.

The Microsoft Trust Center (www.microsoft.com/en-us/trust-center) should be your primary page for learning anything about Microsoft security, privacy, and compliance. This site is the home for where Microsoft details how we handle customer data, operations, and tools, including compliance offerings and audit reports of the Microsoft Azure clouds. If you’re a US governmental entity and the Microsoft Azure SSP is required, please contact your Microsoft Account team.

Microsoft’s commitment to security and privacy of customer data in the cloud is exemplified through industry-leading practices matured on some of the world’s largest datacenters and cloud services. Hotmail has been a SaaS service for more than 20 years.

The following list outlines just some of the security principles implemented in each of Microsoft’s cloud services.
  • Customers own their data. It’s yours; you can take it out of Azure whenever you want and have it permanently erased from all Azure servers/services.

  • Customers control where their data resides, where it is copied to, and how it is secured

  • Microsoft does not use customer data for anything. Microsoft does not even have access to customer data unless it is initiated via the Customer Lockbox for Microsoft Azure solution. For more information, refer to https://docs.microsoft.com/en-us/azure/security/fundamentals/customer-lockbox-overview.

  • Privacy reviews are performed to verify requirements are being met.

  • Microsoft directs data access requests from governments to the end customer whenever possible. Microsoft will go to court to challenge any invalid legal demands for data.

  • Data is encrypted at rest by default at no charge. Customers can choose to encrypt again at the OS or service level, such as Transparent Data Encryption (TDE) in Microsoft SQL Server.

  • Best-in-class data encryption is used for data in transit whenever the service allows. FTP is an example of a workload that can put a customer at risk. Transport Layer Security (TLS), the successor to SSL, is an example of communication encryption available between individual Azure deployments between Azure and on-premises workloads, and for Azure administrators and users.

  • Azure Information Protection uses encryption, identity, and authorization policies to secure your data. You can see where your data went in the world, who viewed it, from where you can set expiration dates on your data, and you can revoke access to it if needed.

  • Azure Key Vault allows customers to secure cryptography keys used by cloud services so that even Microsoft cannot access or see the keys.

  • Earlier in this chapter, we briefly reviewed the ability of Azure AD to use conditional access policies, multifactor authentication, and managed access to third-party SaaS applications.

  • Microsoft has been developing its Secure Development Lifecycle (SDL) since 2008. All Microsoft cloud services use SDL, which has evolved to include
    • Risk assessments

    • Attack surface analysis and reduction

    • Threat modeling

    • Incident response

    • Release review and certification

  • The Microsoft Digital Crimes Unit (DCU) is part of the Microsoft Cyber Defense Operations Center (CDOC). The CDOC And DCU work with governments and law enforcement agencies globally to fight malware and go after “bad actors” on the web. Microsoft collects telemetry from the Windows OS, Azure AD, Office 365, and other cloud services. This data feeds the Microsoft Intelligent Security Graph, which is a data lake of billions of endpoints worldwide telling Microsoft where bad actors are operating from and letting Microsoft treat traffic from them accordingly.

  • Microsoft operates under an Assume Breach methodology, in which teams are always trying to penetrate Microsoft’s defenses, and other teams are always looking for them. When vulnerabilities are proactively found, they’re escalated and remediated.

  • Microsoft Azure supports multiple types of private connectivity to the customers’ resources.

  • Microsoft follows regulatory standards for overwriting storage before reuse or the physical destruction of decommissioned hardware. Faulty drives, both spinning and solid-state, and hardware are demagnetized and shredded.

  • 24/7/365 physical security at datacenter locations.

For more information on Microsoft’s security offering, please refer to www.microsoft.com/en-us/security/business/explore/cybersecurity and www.microsoft.com/en-us/cybersecurity/content-hub.

Summary

Microsoft has invested more than $1 billion annually in cybersecurity for over a decade. While most people may not think of Microsoft as a cybersecurity company, Microsoft has more than 3500 full-time employees working around the clock to secure their cloud services and technology down to the desktop and device. We hope that this chapter provided some insight into how these Azure services can be extensions of your on-premises IT infrastructure and enable hybrid cloud computing for your organization.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset