As businesses move to the cloud, one of the most important concerns is the security of applications and data in the cloud. The term security, however, is a broad term with many meanings. Businesses want to be sure that someone with malicious intentions can’t impact an application’s availability or access application data, but they also want to ensure that their own employees’ access to cloud resources is controlled. In addition, businesses also have many legal standards and policies they must comply with, and there must be trust that a cloud provider meets those standards.
Azure has services and features that focus on all of these concerns. Applications that are exposed to the public Internet are protected by network features such as Azure Firewall, Network Security Groups, and DDoS Protection. Your Azure account is protected with identity offerings such as Azure Active Directory and multi-factor authentication. Data and other assets, such as documents and emails, are protected by features such as Azure Key Vault and Azure Information Protection.
Even with these protections in place, Azure can constantly monitor your cloud resources for signs of attack using Azure Advanced Threat Protection. Azure Security Center provides recommendations based on your resources, and how they’re configured, so that you can proactively prevent threats in the first place.
Features like Azure Policies and Role-Based Access Control ensure that users with legitimate access to your subscription are able to access only those resources you desire, and you can even lock resources so they can’t be reconfigured or deleted by mistake. Azure Monitor and Azure Service Health ensure you always know what’s happening with your Azure resources.
Finally, Azure has many services and features that focus on compliance and data protection standards. Microsoft Trust Center is a website that teaches you how Azure secures and protects your data in the cloud, and the Service Trust Portal is a website offering tools such as Azure Compliance Manager that helps ensure you’re compliant with standards that are important to you.
With that as your framework, here are the skills that we’ll cover in this chapter.
Skills covered in this chapter:
Understand securing network connectivity in Azure
Describe core Azure Identity services
Describe security tools and features of Azure
Describe Azure governance methodologies
Understand monitoring and reporting options in Azure
Understand privacy, compliance, and data protection standards in Azure
The primary attack vector for applications and data in the cloud is the network, and if your application is exposed to the public Internet, the threat is much greater. Web applications are often the target of attacks that are intended to either bring an application down or to obtain unauthorized access to data. Threats from the outside, however, aren’t the only source of vulnerabilities. In order to keep your application and data secure, it’s also important that you control the traffic inside your virtual network in Azure. In this skill section, you’ll learn about several Azure services and features designed to address these security concerns.
In computing parlance, a firewall is an appliance through which network traffic into and out of a particular network travels. The purpose of a firewall is to allow only desired traffic on the network, and to reject any traffic that might be malicious or that comes from an unknown origin. A firewall imposes control on the network using rules that specify a source and destination IP address range and port combination.
In a typical firewall configuration, all traffic is denied by default. In order for the firewall to allow traffic to pass through it, a rule must match that traffic. For example, if you want to allow someone on the public Internet to access a web application you have running on a particular server, create a firewall rule that allows communication to ports 80 and 443 (the ports for HTTP and HTTPS traffic).You then configure the rule to send that traffic to your web server.
There are several firewalls available from third-parties in the Azure Marketplace, but Microsoft also offers its own firewall called Azure Firewall. Azure Firewall is a PaaS offering in Azure, and it’s easily managed and offers a 99.95% SLA. Azure Firewall scales according to your networking needs, so you don’t have to worry about traffic spikes causing latency or downtime for your applications.
Azure Firewall is a stateful firewall. That means that it stores data in its memory about the state of network connections that flow through it. When new network packets for an existing connection hit the firewall, it’s able to tell if the state of that connection represents a security threat.
For example, if someone spoofs your IP address and attempts to gain access to your virtual network in Azure, the firewall would recognize that the hardware address of the computer being used has changed and reject the connection.
A typical setup for Azure Firewall consists of the following:
A centralized hub network that contains the Azure Firewall and a VM that operates as a jumpbox. The firewall exposes a public IP address, but the jumpbox VM does not.
One or more additional networks (called spoke networks) that don’t expose a public IP address. These networks contain your various Azure resources.
The jumpbox is a VM that you can remote into in order to manage other VMs in your networks. All other VMs are configured to only allow remote access from the jumpbox VM’s IP address. If you want to access a VM in a spoke network, you first remote into the jumpbox VM, and then you remote into the spoke network VM from the jumpbox. This setup is referred to as a hub and spoke configuration, and it provides additional security for your network resources.
A hub and spoke configuration isn’t the only configuration where Azure Firewall can be used. For example, you might have a single virtual network and Azure Firewall in that network to filter traffic from the Internet. A hub and spoke network configuration is the most common in real-world business applications.
Figure 3-1 is an illustration of a typical hub and spoke configuration that also includes Azure Firewall. Traffic that comes from the Internet over port 443 (HTTPS traffic) is directed by the firewall to a web server running in Spoke VNet 1. Traffic that comes in over the remote desktop port is directed to the jumpbox VM, and users can then RDP from the jumpbox VM to a VM in Spoke VNet 2.
Before you can configure a firewall to handle network traffic, you’ll need to create an instance of Azure Firewall. You can choose to include Azure Firewall when you create your virtual network in Azure, or you can create a firewall and add it to an existing virtual network. Figure 3-2 shows Azure Firewall being created during the creation of a new virtual network.
When you create a firewall during the creation of a virtual network, Azure creates a subnet in the virtual network called AzureFirewallSubnet, and it uses the address space you specify for that subnet. A public IP address is also created for the firewall so that it can be accessed from the Internet.
While the PaaS nature of Azure Firewall does remove much of the complexity, using a firewall isn’t as simple as enabling it in your virtual network. You will also need to tell Azure to send traffic to the firewall, and then you’ll need to configure rules in the firewall so that it knows what to do with that traffic.
To send traffic to your firewall, you need to create a route table. A route table is an Azure resource that is associated with a subnet, and it contains rules (called routes) that define how network traffic in the subnet is handled.
A route table is created using the Route Table item in the Azure Marketplace. Once you create a new route table, you must associate it with one or more subnets. To do that, click on Subnet and then click Associate as shown in Figure 3-3.
After you click Associate, select the virtual network and the subnet as shown in Figure 3-4.
In our particular setup, we want to associate both the JumpboxSubnet and the ServerSubnet with the route table. This will ensure that the firewall will handle all network traffic to the jumpbox VM and all traffic out of the ServerSubnet.
It’s important to understand that a firewall can (and should) be used to filter traffic flowing into and out of a network. For example, you want the firewall to handle traffic into your jumpbox, but you also want to ensure that traffic flowing from the subnet where other servers are located is secure and not inappropriately sending data out of your network.
Once we’ve associated the route table with the subnets, we create a user-defined route so that traffic is directed through Azure Firewall. To do that, click on Routes and then click Add as shown in Figure 3-5.
Figure 3-6 shows the configuration of a new user-defined route named ToFirewall. This route is configured for 0.0.0.0/0, the notation for all traffic. It’s then sending that traffic to a virtual appliance (Azure Firewall in this case) located at IP address 10.1.1.4, which is the internal IP address of this firewall. Once this route is configured, it will immediately apply to all devices on the subnets associated with the route table.
Remember that Azure Firewall blocks all traffic by default, so at this point, there’s no way to reach the jumpbox VM that’s in the JumpboxSubnet. In order to access that VM, you must configure a firewall rule in Azure Firewall that will forward the appropriate traffic to the jumpbox VM.
To add a firewall rule, open Azure Firewall in the Azure portal and click on Rules, select the type of rule, and click the Add button to add a new rule collection as shown in Figure 3-7.
There are three types of rule collections available in Azure Firewall.
Network address translation (NAT) rules These rules are used to forward traffic from the firewall to another device on the network.
Network rules These are rules that allow traffic on specific IP address ranges and ports that you specify.
Application rules Application rules are used to allow applications such as Windows Update to communicate across your network. They can also be used to allow particular domain names such as azure.com and microsoft.com.
Azure Firewall combines all of the rules of a specific type and priority into a rule collection. The priority is a number between 100 and 65,000. Lower numbers represent a higher rule priority and are processed first. In other words, if you want to ensure that a rule is always applied before all other rules, include that rule in a rule collection with a priority of 100.
When network traffic enters the firewall, NAT rules are applied first. If the traffic matches a NAT rule, Azure Firewall applies an implicit network rule so that the traffic can be routed appropriately, and all further rule processing stops.
If there isn’t a NAT rule that matches the traffic, network rules are applied. If a network rule matches the traffic, all further rule processing is stopped. If there isn’t a network rule that applies to the traffic, the application rules are applied. If none of the application rules match the traffic, the traffic is rejected by the firewall.
To allow access to remote into the jumpbox VM, you might configure a NAT rule that forwards any traffic on port 55000 to port 3389 (the port for remote desktop) on the internal IP of the jumpbox VM as shown in Figure 3-8. Because port 55000 is a general port that wouldn’t normally be used for remote desktop, someone with malicious intent would likely never discover that it’s being used for that purpose.
In addition to rules that you configure, the threat intelligence feature (currently in preview) in Azure Firewall can protect you from known malicious IP addresses and domain names. Microsoft constantly updates their list of known bad actors, and the data collected is provided in the Microsoft Threat Intelligence feed.
When you enable threat intelligence, you can choose to have Azure alert you if traffic from a known malicious IP address or domain name attempts to enter your network. You can also choose to have the traffic denied by the firewall automatically as shown in Figure 3-9.
For every hour that you have an Azure Firewall deployed, Microsoft will bill you $1.25. You are also billed $0.03 for every gigabyte of data processed by the firewall.
Cloud applications that are accessible from the Internet over a public IP address are susceptible to distributed denial of service (DDoS) attacks. DDoS attacks can overwhelm an application’s resources and can often make the application completely unavailable until the attack is mitigated. DDoS attacks can also be used to exploit security flaws in an application and attack systems that an application connects to.
Azure can help protect against DDoS attacks with DDoS protection. DDoS protection is a feature of Azure Virtual Networks. There are two tiers of DDoS protection; Basic and Standard. Basic protects you from volume-based DDoS attacks by distributing large amounts of volume across all of Azure’s network infrastructure. Basic DDoS protection applies to both IPv4 and IPv6 public IP addresses. With the Basic tier, you have no logging or reporting of any DDoS mitigation, and there’s no way to configure alerts, so that you’re notified if a problem is detected. However, the Basic tier is free and provides basic protection.
The DDoS Standard tier offers protection not only from volume-based DDoS attacks, but when used in combination with Azure Application Gateway, it also protects from attacks designed to target the security of your applications. It offers logging and alerting of DDoS events and mitigations, and if you need help during a DDoS attack, Microsoft provides access to experts who can help you. The DDoS Standard tier applies only to IPv6 public IP addresses.
The Standard tier is targeted at enterprise customers and is billed at $2,994.00 per month, plus a small fee per gigabyte for data that is processed. The fixed monthly price covers up to 100 resources. If you need to cover additional resources, you pay an additional $30.00 per resource per month.
To enable the DDoS Standard tier, click DDoS Protection in your virtual network in the Azure portal and select Standard as shown in Figure 3-10.
To enable Standard tier, you’ll need a DDoS protection plan. If you don’t currently have one, click Create A DDoS Protection Plan to create one in the Azure portal. You can then apply that DDoS protection plan to your virtual network and to other virtual networks that you have access to in Azure. Virtual networks that use the DDoS protection plan aren’t required to be in the same subscription, so in most cases, an organization will only need a single DDoS protection plan to protect all of their virtual networks.
The fact that you can add virtual networks from multiple Azure subscriptions to the same DDoS protection plan is an important concept. You are billed a large monthly charge for the DDoS protection plan, and if you create two DDoS protection plans, you have just doubled your costs.
DDoS protection Standard tier monitors your network traffic 24/7, and it uses machine learning to profile your traffic over time and adjust itself to accommodate your network’s traffic profile. During a DDoS event, Standard tier allows you to stream logs to a security information and event management (SIEM) system. SIEM systems are designed to allow for the aggregation of data from a large number of sources for the purpose of analysis, and to comply with data retention policies and standards.
Once you’ve configured any alerts and monitoring for DDoS protection, you can simulate a DDoS event using a BreakingPoint Cloud account available at: https://www.ixiacom.com/products/breakingpoint-cloud. This allows you to ensure that your DDoS protection is protecting you from DDoS attacks.
A Network Security Group (NSG) allows you to filter traffic on your network and apply rules on that traffic. An NSG contains several built-in rules provided by Azure that are designed to allow your resources in the virtual network to communicate with each other. You can then add your own rules to the NSG to control traffic into and out of the network, and also between resources in the network.
Figure 3-11 shows the multi-tier application first shown in Chapter 2, Understanding core Azure services.
Here’s the traffic flow of this application.
Subnet 1 receives data from another virtual network running Azure Firewall.
Subnet 1 communicates with Subnet 2 to process requests.
Subnet 2 communicates with a database server in Subnet 3 in order to access data.
If you want to ensure a secure environment, Subnet 1 should not be able to directly communicate with resources in Subnet 3. Likewise, Subnet 3 should not be able to directly communicate with resources in Subnet 1. Finally, only Subnet 1 should be able to communicate with the other virtual network running Azure Firewall. You can use NSGs to implement rules that will enforce these policies.
NSGs can be associated with a subnet or to a network interface attached to a VM. Each network interface or subnet can only have one NSG associated with it, but you can create up to 1,000 rules in a single NSG, so you should be able to easily apply all of the rule logic necessary for any task. If you associate an NSG to both a subnet and to one or more network interfaces inside of that subnet, the rules for the NSG associated with the network interfaces are first applied, and then the subnet’s NSG’s rules are applied.
An NSG that’s associated with a subnet impacts all VMs inside of that subnet, as well as traffic to and from the subnet. For example, if you configure an NSG to prevent all traffic except traffic from the Internet, and you then associate that NSG with a subnet containing two VMs, those two VMs will no longer be able to communicate with each other because only traffic from the Internet is allowed by the NSG.
To prevent rules from interfering with each other, each rule you create in an NSG has a priority between 100 and 4,096. Rules with a lower priority take precedence over rules with a higher priority. Network traffic is applied against the rule with the lowest priority number first. If the traffic matches that rule, the rule is applied, and processing of the rule stops. If the traffic doesn’t match the rule, it is evaluated against the next lowest priority rule. This continues until the traffic has either matched a rule, or there are no additional rules.
The default rules that Azure applies to all NSGs have a priority in the 65,000 range. This prevents the default rules from ever overriding an explicit rule that you create, and it makes it easier for you to override the default rules if needed.
To create an NSG, search for Network Security Group in the Azure Marketplace. When you create an NSG, give it a name, choose or create a resource group, and specify the location for the NSG, as shown in Figure 3-12.
After you create an NSG, you can then add inbound and outbound rules for the NSG. Once you open the NSG in the Azure portal, click Inbound Security Rules to add new inbound rules, and Outbound Security Rules to add outbound rules.
In Figure 3-13, we click on Inbound security rules to add a new rule that allows traffic from the virtual network running Azure Firewall. After that, the NSG will be associated with Subnet-1. Note that you can associate the NSG with a subnet or network interface before adding rules.
Click Add to add a new NSG rule. Figure 3-14 shows a new rule being added that allows traffic into this subnet from the address space of another virtual network that’s running Azure Firewall.
The rule being configured in Figure 3-14 uses CIDR notation for the source IP addresses, but you can also enter a specific IP address or change the Source dropdown to Any if you want the rule to apply to all IP addresses.
Click Subnets to associate an NSG with a subnet, or Network Interfaces to associate it with a network interface used by a VM. Then click Associate, as shown in Figure 3-15.
Figure 3-16 shows the blade where an NSG is associated with a subnet.
Outbound security rules are created in the same way that inbound rules are created. You aren’t required, however, to create a corresponding outbound rule for every inbound rule. NSGs maintain what’s called a flow record that stores the state of a connection, and the NSG will allow traffic that corresponds to that flow record without an explicit rule. If a security rule allows inbound traffic to port 80 from IP addresses in the range of 10.1.0.0/16, such as the rule configured in Figure 3-14, the NSG will also allow outbound traffic on port 80 to addresses in that same range using the flow record. Only once traffic stops flowing for a few minutes, will the flow record no longer be in effect.
There are some cases where you won’t know the specific IP address range. For example, if you want to configure an NSG rule on a virtual network that allows all traffic from the Internet, you wouldn’t specify an exact address range. To deal with that, NSGs allow you to use service tags when configuring rules.
A service tag is a special identifier created by Microsoft that applies to the Internet or to a specific service type within Azure. For example, if you have some web apps running in Azure App Service, and you want to allow them to communicate with your subnet, you can use the AppService service tag in your inbound rule to allow that. Azure services also have region-specific service tags so that you can allow or deny traffic only from specific regions.
To use a service tag, set the Source of your rule to Service Tag. You can then select a service tag from the Source service tag dropdown. In Figure 3-17, the AppService.CentralUS service tag is being used to allow traffic from Azure App Service resources in the Central US region.
Depending on your application and its configuration, you may or may not need all of the security solutions we’ve discussed. NSGs should be considered in almost all scenarios to ensure that only the desired network traffic flows between your resources. If your application is exposed to the Internet, NSGs can ensure that traffic from the Internet is only allowed into specific subnets or VMs. Even if you aren’t using a public-facing IP address, NSGs can help you enforce secure communication between layers of an application.
Azure Firewall is a powerful way to ensure that traffic into your virtual networks is tightly controlled. Unlike an NSG, Azure Firewall is a stateful solution that understands the makeup of a network connection and can identify if an attack is being attempted on your network. Azure Firewall is not necessary, however, If your application doesn’t expose a public IP address.
DDoS protection is an effective means of protecting your network from attacks designed to impact your applications with a large volume of seemingly legitimate traffic. You can add another layer of protection by using Application Gateway alongside of DDoS protection Standard tier to protect against security threats to the application.
Security isn’t only about controlling network traffic. In order to provide a secure environment, you must have some means of identifying who’s accessing your application. Once you know the identity of a user, you need to ensure that they aren’t allowed access to data or other resources that they shouldn’t access.
Authentication is the process by which a user’s identity is confirmed. Once a user is authenticated and begins interacting with an application, additional checks may take place to confirm which actions the user is and isn’t allowed to perform. That process is called authorization, and authorization checks are performed against a user who is already authenticated.
Azure offers a service called Azure Active Directory that provides both authentication and authorization capabilities for resources and applications, both in the cloud and on-premises.
If you have any experience with on-premises Windows Active Directory, you might find understanding Azure Active Directory (Azure AD) to be a challenge. That’s because Azure AD isn’t the cloud-equivalent of Windows Active Directory. It’s entirely different.
Azure AD is a cloud-based identity service in Azure that can help you to authenticate and authorize users. You can use Azure AD to give users access to Azure resources. You can also give users access to third-party resources used by your company and on-premises resources, all using the same username and password.
You’ll learn about how you can give other users access to your Azure resources when we cover role-based access control in Skill 3.4, “Describe Azure governance methodologies.”
The core of Azure AD is a directory of users. Each user has an identity that’s comprised of a user ID, a password, and other properties. Users also have one or more directory roles assigned to them. The user ID and password are used to authenticate the user, and the roles are used for authorization to perform certain activities in Azure AD.
When you sign up for an Azure subscription, an Azure AD resource is automatically created for you, and it’s used to control access to Azure resources you create under your subscription. Figure 3-18 shows Azure AD in the Azure portal.
To view or manage users in Azure AD, click on Users in the menu on the left side of the page. This opens the All Users blade shown in Figure 3-19.
The Azure AD shown in Figure 3-19 contains two users. The first user’s source is Microsoft Account, meaning this user is tied to a Microsoft Account email address. The other user is an Azure Active Directory user that was manually added.
To add a new user from your company to your Azure AD, click on New User to display the blade shown in Figure 3-20.
The specified user name is used to log into Azure AD. The domain name you use must be one that you own and that is associated with your Azure AD. You can also click on Groups to pick a group for this user. Groups makes it easier to manage larger groups of similar users.
Azure AD offers a feature called Azure AD B2B (business-to-business) collaboration that allows you to add users who don’t belong to your company. So, you can invite other users from outside of your company to be members of your Azure AD. Those users can then be given access to your resources. Users who are not part of your company are called guest users. To add a guest user, click New Guest User shown in Figure 3-19. This will open the New Guest User blade shown in Figure 3-21.
When you invite a guest user, an invitation to join your Azure AD is sent to the email address you specify. In order to accept the invite, the user’s email address must be associated with a Microsoft Account. If the user doesn’t have a Microsoft Account, they’ll be given the option to create one so they can join your Azure AD.
The user in Figure 3-21 can be given access to the corporate social media accounts by adding those applications to Azure AD. Applications to add include, not only social media applications such as Facebook and Twitter, but also thousands of others. To add an application, open Azure AD in the Azure portal, click Enterprise Applications, and click New Application, as shown in Figure 3-22.
After you click on New Application, you can choose from a list of included applications, as shown in Figure 3-23. You can also add your own application, add an application that exists in your on-premises environment, or integrate any other application. The application that you add needs to expose a login page that you can point Azure AD to in order to integrate it.
After you add an application, you can configure Azure AD so that users with access to that application can authenticate to it using the same credentials they use to log into Azure AD. This kind of authentication is known as single sign-on (or SSO), and it’s one of the key benefits to using Azure AD.
Azure AD B2B allows you to invite guest users to your Azure AD from other businesses. Another AD feature called Azure AD B2C allows you to give users access to Azure AD applications by signing in with existing accounts such as a Facebook or Google account.
Another important benefit to using Azure AD for managing user access to other applications is that you can easily revoke that access from a single interface. For example, if you give a user the username and password of your social media account so they can post to your account, when you no longer want that user to have access, you’d have to change the username and password on your social media account. If, however, you grant them access using Azure AD with SSO configured, you can remove that access easily within the Azure portal. The user never has to know the username and password you use for the social media account.
All the Azure AD features we’ve covered so far are included in the free version of Azure AD that everyone with an Azure subscription gets. Azure AD has three other pricing tiers that aren’t free: Basic, Premium P1, and Premium P2. If you upgrade to one of the Premium plans, you have the ability to enable multi-factor authentication for your users.
If you’re using the free Azure AD plan, you have a subset of MFA features for global administrators only. These features allow you to enable MFA for global administrators when accessing the Azure portal and the Microsoft 365 admin center.
For more information on Azure AD pricing plans and what’s included in each of them, see: https://aka.ms/aadpricing.
By default, users are able to log into your Azure AD using only a username and password. Even if you require your users to use strong passwords, allowing access to your resources with only a username and password is risky. If a hacker obtains the password by using software that guesses passwords, or by stealing if through phishing or some other means, your resources are no longer secure.
Multi-factor authentication solves this problem. The concept behind multi-factor authentication is that you must authenticate using a combination of:
Something you know, such as a username and password.
Something you have, such as a phone or mobile device.
Something you are, such as facial recognition or a fingerprint.
If multi-factor authentication requires all three of these, it’s referred to as three-factor authentication, or sometimes 3FA. If only the first two are required, it’s referred to as two-factor authentication, or sometimes 2FA. (Microsoft actually calls it two-step verification.) Azure multi-factor authentication is two-factor authentication.
Even though Azure multi-factor authentication is two-factor, if you are using a mobile device that includes biometric features, you may be authenticating using three-factor authentication. However, the third factor is enforced by your mobile device and not by Azure. Azure multi-factor authentication doesn’t require three-factor authentication.
To enable multi-factor authentication for one or more users of your Azure AD, open the All Users blade and click on Multi-Factor Authentication as shown in Figure 3-24.
When you click on Multi-Factor Authentication, a new browser window opens and displays the Azure AD user management site. Select one or more users you want to enable multi-factor authentication for and click Enable as shown in Figure 3-25.
You can’t enable multi-factor authentication for guest users using this method. If you want to enforce multi-factor authentication for guest users, you will need to set up conditional access to your Azure AD. To do that, open your Azure AD in the Azure portal and click on Conditional Access as shown in Figure 3-26.
In the Conditional Access blade, click New Policy as shown in Figure 3-27.
Enter a name for the new policy and click Users and Groups under Assignments. Click the Select Users and Groups radio button and check the All Guest Users checkbox. Then click Done as shown in Figure 3-28.
You now need to configure which app this policy applies to. To do that, follow these steps as shown in Figure 3-29.
Click Cloud Apps.
Click the Select Apps radio button.
Select the Microsoft Azure Management app.
Conditional access requires a Premium plan for Azure AD.
To add a multi-factor authentication requirement to the policy, click on Grant under Access Controls as shown in Figure 3-30. Click Grant Access and check the Require Multi-Factor Authentication checkbox. You’ll then need to click Select to add the access control. Finally, enable the policy and click Create to finish the process.
Threats to your data and resources can originate from anywhere. Some threats are external, such as hackers attempting to remote into your virtual machines by guessing administrator passwords. Other threats, such as employees not abiding by security best-practices, can come from within. Ensuring the security of your cloud resources can be challenging, and as the number of Azure resources you have deployed grows over time, that challenge can grow exponentially.
Azure Security Center is a service in Azure that offers you a single portal for monitoring and managing the security of your Azure resources. You can also add on-premises resources to Security Center by installing a Security Center agent on your on-premises resources.
Security Center offers two tiers of service. The free tier provides general assessment and recommendations for securing your Azure resources and covers only Azure virtual machines and Azure App Service. The Standard tier adds coverage of your Azure SQL Databases, MySQL databases, PostgreSQL, and Azure blob storage, as well as additional features such as advanced threat detection, analysis from Microsoft Threat Intelligence, and the ability to manage the regulatory compliance of your Azure resources. The Standard tier is billed by the hour, and full details on pricing can be found at https://azure.microsoft.com/en-us/pricing/details/security-center.
To get started with Security Center, click Security Center in the menu in the Azure portal. This will take you to the Overview blade where you can see an overview of all your resources being protected by Security Center as shown in Figure 3-31.
There are three primary areas of coverage in Security Center.
Policy & Compliance Provides a secure and overall score of how secure your resources are. This area also covers your compliance with regulatory standards.
Resource Security Hygiene Provides a high-level overview of the health of your resources from a security perspective. Security issues are categorized as high, medium, or low severity.
Threat protection Shows you any active or past attacks or threats on your resources.
Information for the first two areas is provided by the service being protected. This information is often related to best-practices. Threat protection, on the other hand, is specifically targeted at analyzing both the network traffic and the behavior of users of your resources. If anything looks suspicious, it’s reported by Security Center.
Microsoft Threat Intelligence is used to identify security threats. Threat Intelligence uses Microsoft’s historical data and machine learning to identify possible threats. These threats could be a hacker attempting to gain access to a resource, or they could be related to suspicious activity performed by a user. For example, if a user elevates his privileges on a VM and runs an unknown process, that would likely be flagged as an incident that should be investigated.
Threat protection information is obtained using Azure Advanced Threat Protection. You’ll learn more about Advanced Threat Protection later in this skill.
By clicking on an item in the Overview blade, you can drill down into more details. In Figure 3-32, we’ve clicked on Compute & Apps in the Overview blade. You can can see all of the recommendations for the VMs, App Service, cloud services, and container resources. You can also see how much your secure score will improve if you address each recommendation.
Clicking on one of the recommendations will provide additional information. In most cases, you’ll see a link to instructions on how you can address the recommendation, but Security Center has the ability to automatically take care of recommendations. For example, clicking on the recommendation to Install Endpoint Protection On My VMs, takes you to the screen shown in Figure 3-33.
From here, you can click Install On 1 VMs to automatically install endpoint protection right from inside Security Center. In this scenario we only have one VM, but you can imagine how helpful this capability would be if you had hundreds of VMs running in Azure. With the single click of a button, you can install endpoint protection on them all.
One of the greatest security threats to your cloud resources is open network ports on your VMs. Accessing your VMs using the remote desktop for Windows VMs, or SSH for Linux VMs, is a necessary part of managing those resources, but hackers commonly use the network ports used for remote management to break into VMs. Security Center provides a feature called just-in-time (JIT) access that helps to protect your VMs from attacks on management ports.
When JIT access is enabled, users must request access to a VM in order to remote into it. Until someone is given JIT access, management ports on the VM are closed so they can’t be accessed. Once JIT access is given to a user, the ports are open for a specific period of time as requested by the user. Once that time period has elapsed, the management ports are closed again.
To enable JIT access on a VM, click on Just In Time VM Access in Security Center, as shown in Figure 3-34. Click on the Recommended tab to see VMs that are currently not configured for JIT access. Select one or more VMs and click Enable JIT to turn on the feature.
When enabling JIT access, you can choose which ports you want to protect as shown in Figure 3-35. The recommended ports for management are listed, but you can add your own ports. For example, if you’ve changed your VM configuration so that management happens on a non-typical port, you can add that port for JIT access.
In addition to specifying the port, you can also control which protocols are allowed over the port and which IP addresses are allowed. If the allowed IPs are set to Per Request, the user who requests access will have the option of specifying an IP address or a CIDR block. Otherwise, you can specify a CIDR block yourself in order to allow access only from a specific IP address range.
When a user requests access, the number of hours that access is given can be specified up to the maximum number of hours you specify in the port configuration. Maximum request time can be configured anywhere from 1 to 24 hours.
Once a VM is configured for JIT access, users request access from inside of Security Center. After clicking on Just in Time VM Access, select the VM and click Request Access as shown in Figure 3-36.
As shown in Figure 3-37, users requesting access must specify which ports to open, the IP addresses that are allowed (assuming they weren’t specified when JIT access was enabled for the VM), and how long access is needed, up to the maximum time configured. Once Open Ports is clicked, the requested ports will remain open for the period specified.
Most applications use sensitive or secret information. For example, an application that uses a database needs to know how to connect to that database, and that connection information is stored in a connection string. The connection string may contain a username and password that protects the database, and storing that username and password in a clear text file would be an obvious security risk.
Azure Key Vault provides a secure way to store secrets, keys, and certificates. Once an item is stored in Key Vault, you can apply security policies that define which users and applications can access it. Key Vault is encrypted using encryption keys, but Microsoft has no visibility into the encryption keys or the encrypted data.
Key Vaults are created in the Azure portal as shown in Figure 3-38.
There are two pricing tiers available in Key Vault: Standard and Premium. The only difference between the two is that keys are stored in hardware security modules (HSMs) in the Premium tier. An HSM is a separate piece of hardware that is designed for securely storing encrypted content, and it’s also specialized for processing cryptographic data.
Keeping encryption keys in an HSM boundary is required for Federal Information Processing Standard (FIPS) 140-2, so companies that need to maintain compliance with FIPS 140-2 can do so by using the Premium tier of Key Vault.
You can import a key, secret, or certificate into Key Vault, but Key Vault can also generate security keys and certificates for you. For example, you may want to generate a security key that your company can use to sign certificates. If you want to generate a 4,096-bit security key for this purpose and store it in Key Vault, click on Keys and then click Generate/Import as shown in Figure 3-39.
In Figure 3-40, a 4,096-bit RSA key is being generated and stored in Key Vault.
As shown in Figure 3-41, once the key has been stored, you can view the entry to get the key identifier, a URL that can be used to retrieve the key by users or applications that are authorized. However, you cannot view the key because it’s encrypted and not available except through the key identifier.
A key stored in Azure Key Vault would typically be accessed programmatically by an application. To protect the key, the application developers can retrieve the key each time it’s needed instead of retrieving it once and storing it in memory. This ensures that the key remains secure.
Another common use scenario for Key Vault is to store encryption keys for Azure VMs. One of the security recommendations offered by Security Center is to encrypt VM disks. A VM disk is stored as a VHD file, and when it’s encrypted, the host operating system that runs the VM must be able to access the security key in order to decrypt the VHD and run the VM. Key Vault offers capabilities that are specifically targeted at this kind of scenario.
In order to use Key Vault for disk encryption keys, the access policies must be configured to allow the vault for disk encryption. If this wasn’t done when the vault was created, you can change it by clicking Access Policies, and checking the option to enable access to Azure Disk Encryption as shown in Figure 3-42.
Azure Disk Encryption is enabled on your VMs using either Azure PowerShell or the Azure command-line interface (CLI).
In order to enable encryption and store the keys in Key Vault, your VMs and Key Vault must be in the same Azure subscription, and they must be in the same Azure region. For more details on disk encryption requirements and steps to enable encryption, see: https://docs.microsoft.com/en-us/azure/security/azure-security-disk-encryption-prerequisites.
Solutions such as Azure Key Vault are effective at ensuring that information that never leaves your control is safe and secure. There are often situations where sensitive or confidential information is shared outside of your company. For those situations, Azure Information Protection (or AIP) can help you to keep information within your control.
AIP protects emails and Microsoft Office documents from reaching the wrong hands. By configuring different classifications for emails and other documents, and then specifying restrictions that apply to each classification, a company can ensure that information isn’t over-shared or that sensitive information doesn’t leave the company.
In Figure 3-43, an email is being sent that contains a credit card number. In order to prevent my credit card from being used by someone inappropriately, you can use AIP to classify the email so that only the recipient you specified can read it.
The Protect button in Microsoft Outlook allows you to easily categorize and protect your email. By clicking on the Protect button, as shown in Figure 3-44, you can mark this email so that it can only be read by the recipient that it’s addressed to.
This message can be read by a recipient who’s using Microsoft Outlook. If the recipient isn’t using Microsoft Outlook, a link to read the message will be available, as shown in Figure 3-45. Clicking that link will send the user a single-use passcode that they can enter to read the email message in Office 365 in a web browser. This passcode will work even if the user isn’t an Office 365 subscriber.
As previously mentioned, AIP can also be used to protect Office documents in the same way. You can even control whether users can edit the document or just read its contents. If a user doesn’t have the Office app used to create the document, it will open in Office Online in a web browser.
You’ve learned about some of the Azure services designed to protect your Azure resources from network attacks, and those that are designed to protect against attacks on your VMs and applications running in the cloud. One of the most common attack vectors (and one that is often most difficult to detect), however, is an attack on a user’s identity within your on-premises environment, or via other devices employees use to connect to your network. Attacks on your cloud resources are often begun on-premises, or on mobile devices where the target may not be as hardened.
These types of attacks are difficult to detect because they often look like legitimate traffic. Hackers will enter your environment on one machine using stolen credentials, and they’ll move laterally through your infrastructure attempting to gain access to additional systems and sensitive data. Mobile devices are also a common attack vector because they can connect to insecure networks.
Azure Advanced Threat Protection (or ATP) is available as part of the Enterprise Mobility + Security 5 suite from Microsoft. You can also purchase it using a standalone license. ATP is designed to identify and mitigate identity threats in your on-premises environment and on devices that connect to your environment.
Deploying ATP in your environment is a multi-step process.
ATP collects information on your network, servers, and environment using software that you install called an ATP sensor. In order to plan your ATP capacity, you need to determine how many sensors you need and what size those sensors should be. (Sensor size is based on the volume of network traffic in your environment.)
Microsoft has a guide on planning your ATP capacity at: https://docs.microsoft.com/azure-advanced-threat-protection/atp-capacity-planning.
The ATP sensors that you install on-premises will connect to an Azure ATP instance in the cloud. That’s where they will store all the data that’s collected in order to do threat analysis and detection.
Your Azure ATP instance is created by browsing to the Azure ATP portal at https://portal.atp.azure.com. You’ll need an Azure ATP license in order to access this site.
Azure ATP connects to your on-premises Active Directory in order to get information about your environment and your users. You can also connect to a multi-forest Active Directory.
Full details on how to connect ATP to your Active Directory are available at: https://docs.microsoft.com/en-us/azure-advanced-threat-protection/install-atp-step2.
The ATP sensors are available in a package from Microsoft. Once you download and install the ATP sensor, you’ll need to configure it before you’ll start seeing data.
You can find details on the ATP sensor installation and configuration at: https://docs.microsoft.com/en-us/azure-advanced-threat-protection/install-atp-step3.
Once installed and configured, ATP is able to use its analytics and machine learning to identify what’s normal and what’s not, and it does this in real-time. If an attack occurs, ATP can provide tools to your IT department to investigate the nature of the attack and take appropriate actions.
ATP represents an entire ecosystem at Microsoft across various offerings. Office 365 ATP is designed to offer Office 365 users with protection from threats related to email and Office documents. Windows Defender ATP helps protect Windows computers from threats and attacks. Azure ATP protects your on-premises identities and servers. It also protects mobile devices that are used to connect to your on-premises environment.
As your cloud presence grows, you’ll likely end up with a large number of Azure resources that span many different Azure services. Unless you have some control over how those resources are created and managed, costs can spiral out of control. In addition to cost control, you may have other restrictions you’d like in place as well, such as which regions certain resources should be created in, or how certain resources are tagged, and so on.
The traditional way of handling such governance issues would be to send out a memo to everyone explaining what the requirements were, and then crossing your fingers that people adhere to them. Fortunately, Azure Policy can ensure your requirements and policies are adhered to.
Azure Policy allows you to define rules that are applied when Azure resources are created and managed. For example, you can create a policy that specifies that only a certain size VM can be created and that the VMs must be created in the South Central US region. Azure will take care of enforcing this policy so you remain in accordance with your corporate policies.
To access Azure Policy, type policy in the search box in the Azure portal and click on Policy. Alternatively, you can click on All Services and search for “policy” in the list. This will display the Policy blade as shown in Figure 3-46.
By default, Azure Policy shows your compliance with policies defined on an Azure subscription. If you want to, you can scope this view to a different subscription or to a resource group by clicking the ... button next to scope, and selecting the new scope as shown in Figure 3-47.
The non-compliance shown in Figure 3-46 is based on policies implemented by Azure Security Center. By clicking on the non-compliant item, you can see the full details of what is and isn’t within policy as shown in Figure 3-48.
Notice that the title of this item is ASC Default followed by a subscription ID. ASC Default is actually a collection of multiple policies that are defined by Azure Security Center. Azure Policy makes it easy to impose a full suite of policies by combining them into a group called an initiative. By defining an initiative, you can easily define complex rules that ensure governance of your company’s policies.
You can assign a new policy either by selecting a policy from a list of included policies, or by creating your own policy. To assign a policy from the list of included policies, click on Assignments and then click Assign Policy, as shown in Figure 3-49.
Click the ellipses next to Policy Definition as shown in Figure 3-50 to select a policy.
In this case, you apply a policy that will ensure that any App Service app that gets created has diagnostic logging enabled. You can do that by entering app service in the search box, and selecting the built-in policy that applies to that policy, as shown in Figure 3-51.
As shown in Figure 3-52, the effect of this particular policy is Audit, meaning that if the policy isn’t in compliance, a warning will appear in the portal, but it will still allow the resource to be created.
There are six different effects supported in Azure policy. Not all effects, however, are available for built-in policies. The effects are:
Append Adds additional properties to a resource. It can be used to add a tag with a specific value to resources.
Audit Logs a warning if the policy is not complied with.
AuditIfNotExists Allows you to specify an additional resource type that must exist along with the resource being created or updated. If that resource type does not exist, a warning is logged.
Deny Denies the create or update operation.
DeployIfNotExists Allows you to specify an additional resource type that you want deployed, along with the resource being created or updated. If that resource type is not included, it is automatically deployed.
Disabled The policy is not in effect.
For more information on policy effects, including examples of each, see:https://docs.microsoft.com/en-us/azure/governance/policy/concepts/effects.
In addition to using the built-in policies, you can also define your own policies by creating a custom policy definition. Custom policy definitions are ARM templates that define the policy. For more information on creating a custom policy definition, see: https://docs.microsoft.com/en-us/azure/governance/policy/tutorials/create-custom-policy-definition.
Role-based access control (RBAC) is a generic term that refers to the concept of authorizing users to a system based on defined roles to which the user belongs. Azure implements RBAC across all Azure resources so that you can control how users and applications can interact with your Azure resources.
You might want to allow users who administer your databases to have access to databases in a particular resource group, but you don’t want to allow those people to create new databases or delete existing databases. You might also want some web developers to be able to deploy new code to your web applications, but you don’t want them to be able to scale the app to a higher-priced plan. These are just two examples of what you can do with RBAC in Azure.
There are four elements to RBAC.
Security principal The security principal represents an identity. It can be a user, a group, an application (which is called a service principal), or a special AAD entity called a managed identity. A managed identity is how you authorize another Azure service to access your Azure resource.
Role A role (sometimes called a role definition) is what defines how the security principal can interact with an Azure resource. For example a role might define that a security principal can read the properties of a resource but cannot create new resources or delete existing resources.
Scope The scope defines the level at which the role is applied, and it controls how much control the security principal has. For example, if the scope is to a resource group, the role defines activities that can be performed on all matching resources in the resource group.
Role assignments Roles are assigned to a security principal at a particular scope, and that’s what ultimately defines the level of access for the security principal.
RBAC includes many built-in roles. Three of these built-in roles apply to all Azure resources.
Owner Members of this role have full access to the resources.
Contributor Members of this role can create resources and manage resources, but they cannot delegate that right to anyone else.
Reader Members of this role can see Azure resources, but they cannot create, delete, or manage those resources.
All of the other built-in roles are specific to certain types of Azure resources.
To give someone access to a resource using RBAC, open the resource you want to give access to in the Azure portal. Click on Access Control (IAM) in the portal to configure RBAC. In Figure 3-53, RBAC is being configured for a web app hosted in Azure App Service. Clicking on Add in the Add a Role Assignment box allows you to add a role.
The scope of RBAC is defined by where the RBAC role is assigned. For example, if you open a resource group in the portal and assign an RBAC role to a user, the scope is at the resource group level. On the other hand, if you open a web app within that resource group and assign the role, the scope is to that web app only. That user will not have access to other apps in the resource group unless you apply other role assignments to the user.
RBAC roles can be scoped to the management group, subscription, resource group, or resource level.
After clicking Add, choose the role you want to assign. The list of roles will differ depending on what type of resource this is. Choose who or what you want to assign the role to, and then click on Save, as shown in Figure 3-54.
Figure 3-54 shows a list of users in the AAD, because the Assign Access To dropdown is set to AAD objects. You can see a list of other types of objects by selecting a different type. For example, in Figure 3-55, we are selecting a built-in managed identity type that will add Azure VMs to the Website Contributor role for this web app.
It’s important to understand that role assignments are additive. Your RBAC abilities at any particular scope are the result of all role assignment up to that level. In other words, if I have the Owner role on a resource group and you assign me the Website Contributor role on a web app within that resource group, the Website Contributor assignment will have no effect because I already have the Owner role on the entire resource group.
RBAC is enforced by Azure Resource Manager (ARM). When you attempt to interact with an Azure resource, whether in the Azure portal or by using a command line tool, you are authenticated by ARM and a token is generated for you. That token is a representation of your identity and all of your role assignments, and it’s included with all operations you perform on the resource. ARM is able to determine if the action you are performing is allowed by the roles to which you are assigned. If it is, the call succeeds. If not, you are denied access.
You can ensure that someone has the rights you desire by checking access in the Azure portal. Open the resource and click on Access Control (IAM). Click the Check Access tab and search for the user or resource you’ve granted access to as shown in Figure 3-56.
Click on the user or other object and the access to the resource will be displayed as shown in Figure 3-57.
For a greater level of detail on what exact operations are and aren’t allowed, click on the role that’s displayed. This will allow you to see a detailed list of operations and the combination of read, write, delete, and other actions that a security principal can perform as shown in Figure 3-58.
RBAC is a great way to control access to an Azure resource, but in cases where you just want to prevent changes to a resource, or prevent that resource from being deleted, locks are a simpler solution. Unlike RBAC, locks apply to everyone with access to the resource.
In order to create a lock, you must either be in the Owner or the User Access Administrator role in RBAC. Alternatively, an administrator can create a custom role that grants the right to create a lock.
Locks can be applied at the resource level, the resource group level, or at the subscription level. To apply a lock to a resource, open the resource in the Azure portal and click Locks in the Settings section of the menu on the left, as shown in Figure 3-59.
To add a lock to the resource, click Add. (You can also review and add Locks to the resource group by clicking on Resource Group, or to the subscription by clicking on Subscription.) Provide a name for the lock, set the lock type, and add an optional note as shown in Figure 3-60.
A read-only lock is the most restrictive lock. It prevents changing properties of the resource or deleting the resource. A delete lock prevents the resource from being deleted, but properties can still be changed. The result of a read-only lock is often unpredictable, because of the way that locks are handled by Azure.
Locks only apply to operations that are handled by ARM, and some operations specific to a resource are handled internally by the resource instead of being handled by ARM. For example, the read-only lock applied to the Azure Key Vault in Figure 3-60 will prevent a user from changing the access policies on the vault, but users can still add and delete keys, secrets, and certificates because those operations are handled internally by Key Vault.
There are other situations where a read-only lock can prevent operations that occur unexpectedly. For example, if you place a read-only lock on a storage account, it will prevent all users from listing the access keys for the storage account, because the operation to list keys makes the keys available for write access.
If a lock is applied to a resource group, all resources in that resource group inherit the lock. Similarly, if a lock is applied at the subscription level, all resources in the subscription inherit the lock. It is possible to nest locks, and in such situations, the most restrictive lock is the effective lock. For example, if you have a read-only lock on a resource group and a delete lock on a resource in that resource group, the resource will actually have a read-only lock applied to it. The explicit delete lock is ineffective.
Locks are also inherited by newly-created resources. If you apply a delete lock to a resource group, and add a new resource to the resource group at a later time, the new resource will automatically inherit the delete lock.
When an operation is attempted in the portal and denied because of a lock, an error will display as shown in Figure 3-61. Notice that there isn’t any information about why the operation failed, so unless you know that a lock is applied on a resource, you might find this failure confusing.
Attempting to delete the Key Vault from the Azure command-line interface (CLI), however, clearly shows that the delete failed because of a lock as shown in Figure 3-62.
Some resource types are better about displaying detailed errors in the portal, but if you’re using locks on resources, and you experience an unexpected error when working with a resource, it’s always a good idea to try the operation in PowerShell or the Azure CLI to see if a lock might be impacting you.
Azure Advisor is a best-practices analyzer for Azure resources. The goal of Azure Advisor is to help you ensure high-availability and performance, control costs, and to secure your Azure resources. Security assistance in Azure Advisor is fed directly from Azure Security Center, but Azure Advisor provides a single view of all recommendations, including the ability to take action on recommendation directly in the Azure Advisor blade.
To access Azure Advisor, click Advisor in the menu in the Azure portal, as shown inFigure 3-63.
Clicking on the Security tile takes you to a view of all security recommendations as shown in Figure 3-64.
From this blade, I can open Security Center to view details on these recommendations, but I can also click on Follow Security Center Recommendations to view and take action directly from within Azure Advisor. When this is clicked, you are taken to a comprehensive list, as shown in Figure 3-65. Click on any of these recommendations for more details and to take action on the recommendation.
In Figure 3-66, an individual recommendation is shown. You can also see the steps to take to address the recommendation, and a list of Azure resources affected by the recommendation.
Whether you have a thousand Azure resources or just a few, being able to monitor resource usage in Azure is important. It’s also important to understand the health of your Azure resources and whether a problem in your configuration or a problem in Azure itself is impacting the health of your cloud applications. Azure Monitor and Azure Service Health are two Azure services that provide these features.
Azure Monitor aggregates metrics for Azure services and exposes them in a single interface. You can also create alerts that will notify you, or someone else, when there are concerns you might want to address.
To access Azure Monitor, click on Monitor in the Azure portal to display the Azure Monitor blade, as shown in Figure 3-67. Azure Monitor is customizable, so you can see exactly what interests you the most. For that reason, it doesn’t show any metrics until you configure them. To view metrics, click on Metrics and then Select A Resource.
In Figure 3-68, we’ve selected a VM in the SecurityRG resource group so that you can view metrics from this VM in Monitor.
Once you select a resource, you are presented with a list of metrics related to that resource. Resources for VMs are shown in Figure 3-69.
As soon as you select a metric, the chart updates to show a graph of that metric. You can add additional metrics to your chart by clicking on Add Metric, as shown in Figure 3-70.
When adding multiple metrics, you’ll want to include only those metrics that share a common metric. For example, if you were to add the Disk Read Bytes metric to the chart shown in Figure 3-70, it wouldn’t make a lot of sense because Disk Read Bytes is measured in bytes, and Percentage CPU is measured as a percentage.
In Figure 3-71, we’ve added Disk Read Bytes and Disk Write Bytes to a chart. Azure Monitor color codes each metric automatically to distinguish between them. We’ve also selected Area Chart as the type of chart to more clearly see the patterns.
By default, charts are shown for the past 24-hour period, and the real-time value is shown at the right edge of the chart. However, you can customize the timeframe that is shown by clicking on the timeframe and adjusting it to what you want to see, as shown in Figure 3-72.
Once you have a chart that you find useful, you can pin that chart to the portal dashboard by clicking on Pin To Dashboard. As shown in Figure 3-73, you can pin it to the current dashboard, or you can pin it to a specific dashboard to create a monitoring dashboard in the portal customized for a specific use.
Azure Monitor Alerts can notify you or others with email or SMS text message, run a Logic App flow, call a Function App, make a request to a webhook, and more, when a certain condition is met. Alerts are based on rules that you define, and when a rule’s condition is met, an alert performs the action you specify.
You can create an alert rule that is automatically configured for the metrics you’ve selected in your chart by clicking on New Alert Rule at the top of your chart. You can also start from scratch by clicking on Alerts in the menu for Azure Monitor, as shown in Figure 3-74, and then clicking on New Alert Rule.
To start your rule, click on Select and select the resource you want to configure an alert for. In Figure 3-75, we’ve selected my VM for a new alert rule.
Next, you’ll need to specify the condition for your alert. Click on Add Condition, and then select the signal you want to monitor for your alert. In Figure 3-76, we configure an alert based on the Percentage CPU signal of the VM.
Once you select a signal, the logic for the signal is configured. As shown in Figure 3-77, Monitor displays an interactive graph of the signal you’ve chosen, so you can get a feel for how your resource has been performing historically. This shows the last four hours by default, although you can adjust the chart period. You can specify an operator, aggregation type, threshold, and click Done to create the logic for the alert.
An alert rule can consist of multiple conditions. For example, you can have a rule that only triggers if CPU averages above 70% and disk usage is also high. The choice is yours.
When an alert is triggered, it performs an action that you specify using an action group. An action group contains a list of actions to take when an alert is triggered. To create a new action group, click on Create New, as shown in Figure 3-78.
In Figure 3-79, we are creating an action to notify the IT director. In this case, the action will send a text message to the IT director, and it will also send a push notification using the Azure Mobile app.
Action groups are designed to contain several actions that are executed by an alert being triggered. In Figure 3-80, we’ve edded an additional action to the action group. This action calls a Function App that runs some code to reboot the VM.
Microsoft operates an Azure Status web page where you can view the current status of Azure services in all regions where Azure operates. While it is a helpful view of overall Azure health, the enormous scope of the web page doesn’t make it the most effective way to get an overview of the health of your specific services. Azure Service Health can provide you with a view specific to your resources.
To access Service Health, click All Services, and then click on Service Health as shown in Figure 3-81.
Figure 3-82 shows the Service Health blade showing the health and status of my resources. The map shown has two green dots on it representing the health of the two Azure regions where resources are deployed. This map is specific, and by clicking on Pin Filtered World Map to Dashboard, you can have a quick reference of Azure health for just the regions where you have resources.
You can also view any upcoming planned maintenance that might impact you by clicking on Planned Maintenance. By clicking on Health Advisories, you can see health information that might be related to your own configuration and not a problem somewhere in Azure.
When a service issue is impacting you, you’ll see details on the issue as shown in Figure 3-83. In addition to full details on the incident, you also have a link that refers to details on the incident. You can also download a PDF that contains an official Microsoft notice of the incident.
Both Azure Monitor and Azure Service Health are critical to the overall view of your Azure resources. Azure Monitor is geared toward monitoring the cost and performance of your resources and alerting you and others when conditions warrant. Azure Service Health, on the other hand, is the single-point-of-truth for information on the health of Azure itself and how Azure incidents are impacting your resources. The combination of these two services provides you with all of the tools you need to keep up with your Azure resources and how well they’re performing.
As you move to the cloud, you offload some of the responsibility for your services and data to your cloud provider. This includes some of the responsibility for compliance with data protection standards. Even though the cloud provider takes care of some of that burden for you, it’s still vital that you have confidence in the cloud provider and that you trust them to maintain compliance.
There are many standards that business must comply with. For example, in 2016 the European Union passed the General Data Protection Regulation, or GDPR. GDPR regulates the way personal data is handled for individuals with the EU, but it also controls any personal data that is exported out of the EU. Companies doing business in EU countries are legally required to abide by the GDPR.
One way that organizations can ensure they are abiding by the GDPR and other regulations that regulate data, is to maintain compliance with industry-wide standards focused on helping organizations keep information secure. One of those standards is the International Organization of Standards (ISO) 27001 standard. Companies that comply with the ISO 27001 standard can be confident that they are maintaining the best practices necessary to keep information secure. In fact, many companies won’t do business with a cloud provider unless they can prove ISO 27001 compliance.
Systems that deal with governmental data must maintain compliance with standards that are maintained by the National Institute of Standards and Technology, or NIST. The NIST SP 800-53 is a publication by NIST that outlines all the requirements for information systems dealing with government data. In order for any government agency to use a service, it must first prove compliance with NIST SP 800-53.
Microsoft addresses these compliance requirements across its infrastructure in many different ways.
The Microsoft privacy statement is a comprehensive statement from Microsoft that outlines the following as it relates to handling data and your personal information.
Personal data Microsoft collects
How Microsoft uses personal data
Reasons Microsoft shares personal data
How to access and control your personal data collected by Microsoft
What organizations providing Microsoft software to you can do with your data
What data is shared when you use a Microsoft Account with a third-party
Specifics about how Microsoft secures data, where it’s processed, and retention policies
Microsoft links to the privacy statement in all official communications, and you can access the privacy statement online at: https://aka.ms/privacystatement.
The Trust Center is a web portal where you can learn all about Microsoft’s approach to security, privacy, and compliance. You can access Trust Center by browsing to: https://www.microsoft.com/en-us/trustcenter/default.aspx.
Explore the Trust Center using the dropdown menus at the top of the page as shown in Figure 3-84. As standards and compliance evolve, you can always find the latest information on the Trust Center website.
The Service Trust Portal (STP) is a portal that provides access to various compliance tools Microsoft provides for you to track compliance in your applications running on Microsoft’s various platforms. You can access the STP by browsing to: https://aka.ms/STP. Figure 3-85 shows the STP home page.
The STP is a launching point for the following resources.
Compliance Manager A tool for managing your regulatory compliance in the cloud.
Audit Reports Comprehensive reports and resources that allow you to see details on how Microsoft maintains compliance.
Data Protection Information Full details on how Microsoft designs its cloud offerings to ensure that customer data is protected.
Privacy Information related to how Microsoft helps you maintain compliance with GDPR.
Compliance Manager is a tool within the STP that makes it easy to visualize your compliance with industry standards. Compliance Manager also provides details on how you can improve compliance, and for those areas where compliance is Microsoft’s responsibility, it provides full details on how Microsoft maintains compliance.
To access Compliance Manager, click Compliance Manager at the top of the STP page. Compliance Manager allows you to track your compliance with related applications by grouping them into groups that you can give a name of your choice. Each group you create is represented by a tile in Compliance Manager, and you can see at a glance how far you’ve progressed at compliance in each group as shown in Figure 3-86.
You can add a new assessment by clicking on Add Assessment. You can add an assessment to an existing group or you can create a new group as shown in Figure 3-87.
You can choose to assess Azure, Office 365, Microsoft Dynamics, and more. You can also choose the standard you want to evaluate against. In Figure 3-88, weve chosen to evaluate Azure resources against GDPR.
Based on the products we’re evaluating, Compliance Manager knows which parts of compliance are Microsoft’s responsibility, and which are the customer’s responsibility. In Figure 3-89, a newly-created assessment is shown in Compliance Manager. Microsoft’s responsibilities are displayed at the top of the list, and they are already completed. My responsibilities appear in the list as well, and they outline all the requirements we must meet in order to be compliant with GDPR.
If you click on one of the Microsoft controls, you’ll see details on what Microsoft has done to ensure compliance. In the control shown in Figure 3-90, you can see how Microsoft complied with specific GDPR articles, when it was tested, and how it was tested.
If you click on a customer managed control, you can see details on what you need to do to comply. In Figure 3-91, details are shown regarding what you need to do to comply with GDPR Article (5)(1)(b). You have the option of assigning this task to a specific user if you want to, and you can click on Manage Documents to upload supporting documents to Compliance Manager.
Using this method of assessment, you can always determine if your applications are compliant. The burden of understanding certain standards and regulations is removed because Compliance Manager manages that for you.
Compliance with GDPR and the other standards mentioned relates to the privacy of an individual’s data. Some US government compliance scenarios require that data stays within the United States of America and that only citizens of the United States have any access to systems used to store that data. Complying with these requirements is impossible with the public cloud, so Microsoft has developed completely isolated Azure data centers that make up the Azure Government cloud.
Azure Government data centers are separate from public data centers. All employees working in Azure Government are screened and are citizens of the US. Even Microsoft employees who provide technical support to Azure Government customers are required to be US citizens.
Because Microsoft also wanted to allow for compliant communication between the Azure Government cloud and on-premises government systems, they also developed dedicated Microsoft ExpressRoute locations that are completely isolated from other Azure networks and that use their own dedicated fiber optic components.
Azure Government isn’t only for federal government agencies. Cities and municipalities also take advantage of Azure Government for compliance. When a customer signs up for Azure Government, Microsoft vets that user to ensure they are representative of a government agency. Only then are they given a subscription to Azure Government.
The Azure Government cloud has all of the same features and services as the public cloud, but there are small differences. For example, the portal for Azure Government is located at https://portal.azure.us instead of https://portal.azure.com. URLs for Azure services also use the .us top-level domain, so if you create an App Service web app in Azure Government, your default domain name is https://webapp.azurewebsites.us. However, outside of that difference, everything else is the same, so developers who have a skill set in cloud development in Azure will find that their skills transfer directly to Azure Government.
The United States Department of Defense has additional compliance requirements called DoD Impact Level 5 Provisional Authorization. Compliance with this relates to controlled unclassified information that requires additional levels of protection. These additional DoD requirements are met by a subset of data centers within Azure Government that are approved for DoD usage.
Much like Azure Government, Azure Germany is a distinct cloud system that’s designed to meet specific compliance needs. In the case of Azure Germany, those needs relate to the strict requirements imposed by the EU. Azure Germany is available to customers doing business in the EU, the European Free Trade Association, and the UK.
Azure Germany datacenters are physically located in Germany and are operated under strict security measures by a local company named T-Systems International (a subsidiary of Deutsche Telekom) that operates as a data trustee. The data trustee has full control over all data stored in Azure Germany and all of the infrastructure used to house that data. Microsoft is involved in managing only those systems that have no access at all to customer data.
Let’s apply the concepts related to security, privacy, compliance, and trust that you’ve learned in this chapter to a thought experiment. You can find the answer to this thought experiment in the section that follows it.
ContosoPharm has secured a contract to do some pharmaceutical development for the US Department of Defense. Because this work will be extremely sensitive in nature, there are several requirements they must meet before the DoD will sign off on the project.
Access to the application from DoD personnel will be via a web interface over devices that are connected to the Internet in the field. The DoS requires strict security controls for any access to the application, and it’s important that the application be protected from malicious attacks that might look like legitimate traffic. This requirement applies to both cloud and on-premises VMs.
It’s also required that the application configuration protects against situations where someone’s password is stolen. If someone outside of the DoD attempts to log into the application using a stolen password, that login must be denied.
The application heavily uses Azure SQL Database, and users of the application should be able to create their own database tables. They should not, however, be able to give anyone access to the database that isn’t explicitly given permission by the administrator. In addition to that, users of the database portion of the application are on a rotational schedule, so it must be very easy to revoke the access without having to change any database passwords.
Some of the systems will run on-premises because of access to confidential information. The administrator of the system would like a single interface where the security status of all cloud resources and on-premises resources can be monitored. As new systems are brought online, the administrator must be able to ensure that DoD requirements for antivirus software are met.
One VM in the application will need to be remotely managed, but a requirement of the DoD is that remote management ports on the machine cannot be left open. Therefore, they need you to suggest a way they can securely remotely manage the VM.
The caching component in the application contains sensitive data that is protected by an encrypted RSA key. The DoD requires that the key necessary to access the cached data not be stored anywhere within the application. It’s required that access to the key be given to the app when necessary, but only when necessary.
During the development of the application, information will be shared in Office documents and in emails. Some of the people who will receive this information aren’t DoD employees, so some of this information will be sent outside of the DoD. Even so, it’s a requirement that no one other than the recipient of the data be able to read it, and they shouldn’t be able to share it with others.
The DoD IT department has operational parameters that all VMs must meet for availability. These metrics revolve around disk usage, CPU utilization, and memory usage. When metrics fall outside of normal operation, it’s critical that actions be taken immediately, so the IT department has developed some scripts that they can run quickly to address that. If possible, they would like to automate this process so that the system will take care of itself if no one is available to address a problem immediately.
Finally, the application must comply with DoD Impact Level 5 standards, and privacy of each individual’s data must also be maintained.
This section covers the answers to the thought experiment.
To protect the VMs in the cloud from malicious traffic, Azure Firewall can be deployed on the network. This can help to protect from traffic that otherwise looks legitimate because of Azure Firewall’s ability to remember the state of a connection. To apply that same level of protection to on-premises machines, the DoD can use Advanced Threat Protection. By installing ATP sensors on-premises, the DoD can ensure that these on-premises resources are protected.
In order to prevent someone from logging into the system with a stolen password, the DoD should implement multi-factor authentication. MFA will require that users not only have a password, but also that they have access to an approved device associated with them.
In order to give users the ability to create database tables, but not give anyone else access, DoD should create users in their Azure Active Directory and assign RBAC roles to the SQL databases. Because users with RBAC access aren’t using a password associated with the database to read data, access can quickly be revoked when necessary without having to change a password in the database.
Azure Security Center can provide insight into the security state of resources in a single interface. Security Center will also show non-compliance for VMs where endpoint protection is not installed, and the DoD will be able to easily install anti-virus on one or more VMs with the click of a button.
For the one VM that must be remotely managed, DoD can enable JIT access in Security Center. This allows them to leave the management ports closed until a user requests access, and the user can even specify their specific IP address for access which will further protect the VM. Once the access time is elapsed, the management ports are closed.
To protect the RSA key used with their caching component, the DoD can use Azure Key Vault. They can use Key Vault to generate the key as well if they want to. When they key is needed by the application, it can access it via a secure URL.
To protect information in emails and documents, including those sent outside of the DoD, Azure Information Protection can be used. By classifying emails as Confidential and for recipients only, access to the information in the mail will be protected. These same protections can be applied to their Office documents.
Azure Monitor can be used to monitor VMs and ensure they are operating within operational parameters. An alert group can be created that will trigger when desired, and because an alert can call a webhook, a Function App, or start a Logic App flow, there are many options for automating the scripts they use to address problems, even if no one’s around to see the problem immediately.
To comply with DoD Impact Level 5 standards, the application will need to be hosted in a DoD-approved datacenter within Azure Government. The DoD can also use Compliance Manager to ensure data privacy standards are met for the application.
Security, compliance, privacy, and trust are cornerstones of Microsoft Azure, and Microsoft has proven their commitment to these principles by providing industry-leading tools and services to help you. In this chapter, you’ve learned about many of these tools and services.
Here’s a summary of what was covered in this chapter:
The primary attack vector for cloud applications is the network, and Azure Firewall is a stateful firewall that can protect your network from attacks.
All traffic to the firewall is blocked by default and rules are configured to allow certain traffic to pass.
A route table is used to direct traffic into your firewall’s subnet.
DDoS Basic protection in Azure Firewall protects from common network attacks.
DDoS Standard protection is available for an extra charge and it will protect from additional attacks using Advanced Threat Protection.
Network Security Groups (NSGs) can be used to control which subnets and resources can talk to each other in a virtual network.
Service tags can be used to allow Azure services or the Internet by a NSG.
Azure Active Directory is a cloud-based identify service in Azure that authenticate and authorizes users.
Enterprise applications in Azure AD allow you to integrate third-parties with Azure AD so users can experience a single-sign-on experience.
Multi-factor authentication in Azure AD requires that users have both a password and an owned device in order to log in.
Azure Security Center provides a single portal for monitoring and managing the security of Azure resources and on-premises resources.
Just in time VM access in Security Center makes it easy to control when and for how long management ports are open on VMs.
Azure Key Vault provides a secure way to store secrets, keys, and certificates.
Azure Information Protection helps you to categorize emails and documents and protect them from being accessed by unauthorized people.
Advanced Threat Protection makes it possible to protect on-premises domain controllers and servers from attacks.
Azure Policy allows you to define rules that are applied with Azure resources are created and managed.
Role-based access control makes it possible to give users and applications access to your Azure resources and to control what they can and can’t do.
Locks allow you to lock down properties that go through ARM from being changed on a resource or to prevent a resource from being deleted.
Azure Advisor provides a portal for analyzing and reporting on best-practices related to your Azure resources.
Azure Monitor can display charts with data metrics for your Azure resources.
Azure Monitor alerts can notify you based on conditions. They can also call a webhook, run a Function App, start a Logic App flow, and more.
Azure Service Health provides an overview of the health of Azure and your Azure resources that is scoped to only those regions where you have resources.
The Microsoft Privacy Statement is Micrsosoft’s promise to customers related to how it will protect personal data.
Trust Center is a portal where you can learn about Microsoft’s approach to security, privacy, and compliance.
The Service Trust Portal provides access to compliance tools and information on compliance.
Compliance Manager is part of Service Trust Portal and makes it easy to manage compliance with industry standard regulations using assessments.
Azure Government is a private cloud for governments that is operated with distinct datacenters within the United States. All employees are screened and are US citizens.
Azure Government is aimed at ensuring compliancy with government standards.
DoD datacenters within Azure Government provide stricter control to comply with DoD standards.
Azure Germany is a private cloud operated out of Germany that is designed to comply with strict EU guidelines.
Individual data in Azure Germany is controlled and accessible only by a data trustee. Microsoft has no access to any system that touches customer data.