Chapter 10 Security

For Azure, the defense-in-depth principle is still as relevant as ever. There are seven general layers of security in cloud computing, and that goes for Azure, too, of course.

1. Physical: This is the actual data center. Only authorized personnel has access.

2. Identity and Access: Relates to the Azure Active Directory, which controls all access to Azure and the identity of all users, applications, and connections.

3. Perimeter: Is the protection against DDoS attacks, volumetric attacks, protocol attacks, and more. Don't worry about knowing the details of these types of attacks. Just know that Azure has your back.

4. Network: Is the filter of traffic to and from Azure using virtual networks and applying security standards. The compute component protects against intruders trying to get into your virtual machines or databases. Application gateways and firewalls provide security to your Azure applications. Check out the lectures on these features, too, in the network chapter.

5. Compute: Protects against intruders trying to get into your virtual machines or databases. Application gateways and firewalls provide security to your Azure applications. Check out the lectures on these features, too, in the network chapter.

6. Application: Gateways and firewalls provide security to your Azure applications. Check out the lectures on these features, too, in the network chapter.

7. Data: On Azure is encrypted and protected against anyone unauthorized reading it or making sense of it.

So there you have it. Defense in depth on Azure is how Microsoft has given you multiple layers of security for your cloud infrastructure. Like fancy cake. Layers. Delicious."

The networks on Azure is what gives access to everything. All your services on Azure are connected to a network in order to communicate with users, processors, and other Azure services. Which means we need to secure that network connectivity.

We'll start with the oldest and most common, the Azure firewall. To explain further, let's cross to my reporter on the scene. [zoom noise] I'm here at the world-famous Firewall Bridge! This is the only access to the city behind it. So if the bridge is closed, no one gets in. And this is the same idea with a computer firewall. Unless you can cross the bridge, get through the firewall successfully, you cannot get into the town, well, or the Azure resources.

So let's say this train here, or internet package, is trying to get into the town. Choo-choo! Oh, one of the road signs says that only black trains can get in. Now this train is obviously blue. It's the wrong color, so it is denied access. The rule in the firewall denies this traffic. However, if I take this other train and put that on there (my other internet package), and it's black and it wants to cross the bridge, well, it's let through. 'Cause it's a black train. It's the right color. The rule in the firewall allows this traffic. Whee! To ensure that only appropriate trains are allowed access to the town, certain rules for crossing the bridge are set up. And that's the same in a firewall for a network. Certain rules in the firewall protect the network from traffic that is not allowed. [whooshing Noise] A firewall is a dramatic name for a proven and crucial service. It is a set of rules that decide whether network traffic is allowed to access the service or device attached to the network. Firewalls come in many versions and sizes, both in software and hardware incarnations, and for small, big, and huge networks. A firewall is a must-have part of any network that takes security seriously.

1. Rules

   A firewall defines rules for what kind of traffic can and cannot access the device or service behind it.

2. Variations

   Firewalls comes as hardware and software versions. They can suit any type and size of network.

3. Critical Part

   Any network that take security serious will have a firewall.

Eine Firewall ist eine Netzwerksicherheitsvorrichtung, die eingehenden und ausgehenden Netzwerkverkehr überwacht und auf Grundlage einer Reihe von definierten Sicherheitsregeln entscheidet, ob bestimmter Datenverkehr zugelassen oder blockiert wird.

• U.S. Banks

  In 2012, 6 U.S. banks were flooded with 60Gb of traffic every second.

• CloudFlare

  In 2014, CloudFlare was attacked with 400Gb of traffic per second.

• GitHub

  In 2018 GitHub experienced 1.35Tb of traffic per second. A new record for DDoS attacks.

Next agenda on the network security menu is DDoS. But before we get into the details, let's take a look at history. Now, in 2012, not one, not two, but a whopping six U.S. banks were targeted by a string of DDos attacks. These are distributed denial-of-service attacks. The victims were no small-town banks either. They included Bank of America, JP Morgan Chase, US Bank Corp, Citigroup, and PNC Bank. The attack was carried out by hundreds of hijacked servers, which each created peak floods of more than 60 gigabits of traffic per second. Then in 2014, security provider and content delivery network CloudFlare was slammed - literally slammed - by approximately 400 gigabits per second of traffic. The attack was directed at a single CloudFlare customer and targeted service in Europe. And then finally, on February 28th, 2018, GitHub, a popular developer platform, was hit with a sudden onslaught of traffic that clocked in at 1.35 terabits per second. If that sounds like a lot that's because it is! That amount of traffic is not only massive, it's record-breaking.

Now all these attacks had severe consequences for the companies involved. They lost business, trust in their service, and had to spend millions of dollars to fix their systems. So, distributed denial of service. This is one of the most common attacks on services attached to the internet. But what actually happens? Imagine you have a website that is running on a server. This server can only serve, or handle, a certain number of requests every second. Let's say, 1,000 requests. If too many users come into the site at the same time (let's say 10,000), at some point, not everyone would get through. The server would try to serve all the requests for its content until it would fall over. At some point, the server hasn't got enough resources and it simply stops. If this is done on purpose to take the server out, it is called a denial-of-service attack. What often happens, though, is that the attack is distributed, meaning it comes from many different sources or computers. So a DDoS attack is lots of computers targeting a single server or website with the aim of making it stop.

A famous DDoS attack was, as I said before, against the developer website GitHub in 2018, where attackers sent 127 million requests per second. That is a lot! To protect against DDoS, Azure has the DDoS Protection service. This service has various levels of protection, depending on what your needs are for your application. At its core, Azure detects the DDoS attack and deflects it away from your service. And this is done without any interruption to your application due to Azure's global presence. They can simply catch and mitigate the attack from anywhere in the world.

1. Many Internet-Connected Devices

   A lot of computers and other connected devices target a single website to make it stop. GitHub had a 127M requests per second attack!

2. Protection

   Detects the DDoS attack and deflects it. Various levels of protection depending on scenario.

3. No Downtime

   There is no interruption to your service at all. Azure will mitigate the attack globally.

1. Resource Firewall

   Personal resource firewall. Attach to virtual network, subnet or network interface.

2. Rules

   A NSG determines who can access the resources attached to it, using rules for inbound and outbound traffic.

Finally, at least for this lecture, there are network security groups. Think of these as personal firewalls for your resources. You can attach an NSG to any virtual network, subnet, or network interface which is attached to a virtual machine. A network security group, often called NSG, is a set of rules for who and what can access any resource attached to the NSG. For example, if you have a virtual machine that is on a virtual network, the network can be behind a firewall protecting everything on the network, and then the VM can have its own network security group to define specific rules for just that machine. So everything is behind a firewall, but the VM has an extra layer of security, which is its own network security group.

1. Protects Application Infrastructure

   Focus the security on the application rather than the IP endpoint.

2. Natural Extension

   Group VMs and virtual networks into logical application groups and apply an application security group.

An extension of NSGs that can help you secure your Azure services is an application security group. Where an NSG, or network security group, will protect and monitor traffic to a specific network or virtual machine, an application security group will (well, as the name implies) protect an application. This could be your angry llama website or Azure function app. Application security groups let you configure your network security as a natural extension of an application's structure. You can group virtual machines and define network security policies based on your application and its components instead of using an explicit IP address.

Securing your Azure network is a first line of defense against any unwanted visitors. Using your firewall, DDoS protection, or network security groups are just a first but important step. Next, let's talk about making sense out of chaos.

Let's continue our discussions on securing network access to Azure by now focusing on how to properly secure access to our Azure managed services, specifically our Platform as a Service services by discussing public and private endpoints.

So when we are discussing public and private endpoints, what we are referring to specifically is our managed services or our Azure Platform as a Service services. What we're talking about is that by default when you create these public services, such as Azure Storage, Azure SQL, and others, these services are publicly reachable or publicly exposed over the public internet.

Now, there are a couple of different aspects with this we need to be familiar with. First of all, when accessing these public services over a virtual network, specifically a virtual machine inside of your virtual network, traffic from that virtual network to your managed service, in this case Azure Storage, actually traverses the public internet. Additionally, these managed services endpoints, which are again by default public endpoints, are also exposed to the general public. Now, keep in mind, this does not mean that the contents of those resources are accessible to the public. We still need proper authentication to grant access. However, these resources are still publicly exposed or publicly reachable, which in scenarios in which your services contain sensitive content, this could be a little bit of a problem.

So what then are we to do if we want to limit or remove that public exposure from our different Azure managed services? Well, fortunately we have 2 different native services to choose from, which I call a "good" and a "better" solution. The "good" solution that we are going to refer to is known as service endpoints, and the "better" solution, which from the lesson title is going to be our primary focus, is going to be that of private endpoints. So again, service endpoints is our good solution and private endpoints are our better solution.

DEFAULT:

Managed (PaaS) services reachable over the public internet

• Virtual network —> PaaS over public internet

• Also exposed to the public

• Problem with sensitive resources

What if we want to limit or remove public exposure?

SOLUTION:

Two available solutions: “Good” and “Better”

• “Good” = service endpoints

• “Better” = private endpoints

Privately connect VNet subnet to Azure PaaS services

• Direct connection from subnet to Azure PaaSservices

• Connects over Microsoft’s private backbone (not over public internet)

Configure service to only allow traffic from service endpoint-enabled subnet

• Can also restrict access to specific public IP addresses

Let's unpack those in a bit more detail starting with service endpoints, again our good solution. Not the best, but it is still good. How service endpoints work is that allows you to privately connect a virtual network subnet to different Azure Platform as a Service services. Specifically, it will enable a direct connection from that individual subnet to that managed service. What this means specifically is that resources inside of that subnet, like virtual machines, will connect over Microsoft's private backbone from that subnet to that managed service, as opposed to traversing the public internet to get to that managed service instead.

With service endpoints enabled you also have the optional yet highly recommended ability to also configure the managed service itself, in this example, Azure Storage, to only allow traffic from that service endpoint enabled subnet to that service, therefore cutting access off to everywhere else. And you also have the ability for on-premises or non-Azure locations to also optionally restrict access to specific public IP addresses. So in a scenario in which we have a home office which also needs to securely access this managed service, we have the ability to limit public exposure from specific public IP addresses only, which we can also combine with service endpoint access from our VNet subnets, as well.

Overall, this greatly limits the exposure of our managed service from the public internet. However, I did mention that service endpoints are only a good solution, therefore there are some limitations of service endpoints that you'd need to be familiar with. The first of which, from a private networking perspective, this provides secure access to only Azure virtual networks. There is no ability within service endpoints to provide private access not over the public internet to our different non-Azure or on-premises locations. As we mentioned in the previous slide, our only other option is to only allow on-premise access from public IP addresses. However, even though this is an improvement, it is still going over the public internet even though we are restricting access to a small portion of public IPs only.

With that in mind, our managed service still has a public endpoint that still exists. In other words, that connection is still not truly private, and there is still some public internet exposure. And then our last limitation of service endpoints is that service endpoints provide private access to the entirety of a managed service, not a specific instance of a managed service. For example, when we set up service endpoints with a VNet subnet, it provides private access to the entirety of the Azure Storage service, not just to a single individual storage account. So the scope could be a little bit too wide for some people's comfort.

Secure access to VNets only

• No private on-premises access

• Must allow on-premises access over public IP

PaaS public endpoint still exists

• Not truly private

Service endpoints provide access to an entire service

• For example, provides private access to all of Azure Storage, not just a single storage account

Managed network interface

• Private connection to specific instance of a service

• e.g., single storage account, SQL instance, etc.

Available over connected networks

• Hybrid/on-premises networks

• Peered virtual networks

Can completely disable public access to a connected service

• Truly private

• Public endpoint disabled

So, with these limitations in mind of our good solution, again it's not a bad solution, but it could be better. Let's now talk about private endpoints, which is the better solution which resolve these limitations of our previous good solution of service endpoints.

How private endpoints works as opposed to service endpoints that it acts as a managed network interface that sits inside of your virtual network subnet. This managed network interface will provide a private connection to a specific instance of the service. In other words, it provides private access to only a single storage account or only a single Azure SQLs instance and others, as well. Another advantage of private endpoints as opposed to service endpoints is that it provides truly private connectivity over other connected networks, such as hybrid or on-premises network connecting to our Azure virtual network over a VPN or express route connection, and it also provides add-on private connectivity to other virtual networks paired with our original Azure virtual network. In other words, that Azure virtual network can share its private connectivity over a private endpoint with other networks connected to it, as well, whether it is an on-premises connection, VPN connection or a peered connection, as well.

VPN connection from home office to an Azure VNet named ‘hub-vnet’

Must privately access sensitive Azure SQL database from home office

• Disable public internet exposure

Solution: A private endpoint

• Privately connects hub-vnet to Azure SQL database

• Private access from home office

• Can also disable public access for truly private connection

And then our final advantage of private endpoints as opposed to service endpoints is that you have the ability of completely disabling the public access or exposure to our connected service. In other words, a private endpoint allows you to make that managed service truly private with no public exposure whatsoever. In other words, that public endpoint is completely disabled as opposed to only limiting traffic from certain public IP ranges.

So again, there are a number of reasons why private endpoints are the better private managed service connectivity solution compared to service endpoints.

Finishing things up, let's go over a quick scenario that would call for implementing private endpoints that you may see on the exam. Let's say, for example, that we have an existing VPN connection from our home office in an on-premises location connected to an Azure virtual network, in this case named "hub-vnet." In this scenario, we must privately access sensitive Azure SQL databases from our home office, and we also have the requirement of completely disabling all public internet exposure allowing only truly private connections to our single instance of an Azure SQL database. In this scenario, the solution is, not surprisingly, to use a private endpoint, which is able to privately connect our hub-v

Defender for Cloud is a monitoring tool for security posture management and threat protection. It monitors your cloud, on-premises, hybrid, and multi-cloud environments to provide guidance and notifications aimed at strengthening your security posture.

• It provides threat alerts.

• It’s ready for hybrid architectures.

• Each VM has an agent installed that sends data.

• Azure analyzes the data and alerts you if necessary.

• Policy and compliance metrics

• A secure score to encourage great security hygiene

• Integrate with other cloud providers (requires Azure Arc)

• Alerts for resources that aren’t secure

1. Define Policies

   Set up policies for Azure to monitor resources from. A policy is a set of rules used to evaluate a resource. Use predefined policies or create your own.

2. Protect Resources

   Actively protect your resources through monitoring your policies and their outcomes.

3. Respond

   Respond to any security alerts. Investigate all of them, and then go back to step 1 to define new policies to account for the alert.

Azure Key Vault is a secure place to store passwords and other secrets. You can then share those secrets with others without revealing the actual secret. Let's say you have a database with some valuable business data in it. While you use the data successfully internally, you also want to share access to other trusted outside third parties. However, you don't want to just give them the username and password to access the database. Instead, you place the password in Azure Key Vault and then provide access to individual applications. The application can identify itself, and then Azure Key Vault grants access to the database. So the Key Vault has some key features. Even if someone could get access to the key vault on Azure, the storage is done on hardware that is secure as well. Not even Microsoft can see or extract your keys in the vault. The application can't pass on the access to any other application, and access can be removed very fast in Azure Key Vault without having to change passwords. Of course, Key Vault can scale globally, like any other managed Azure service, so you can get cryptographic high performance too. Next, we go from password protection to protection of email, documents, and other data.

"It is almost inevitable that any documents, emails, or other data that you have will need to be shared with someone outside your organization. In this lecture, you'll learn how to use Azure Information Protection and how this can make this much more secure. When data is stored on company servers and resources, how do you really know who has access to your data? What if an employee has gone rogue and has taken the data? Competitors will most likely want your information, but how do you prevent that? Any organization will have to share documents, emails, and other data outside of the relative safety of the company walls. That is just the nature of doing business. In order to help companies secure their data, regardless of where it is stored, Azure has the Information Protection Service, which works in conjunction with Office 365, Microsoft's online productivity suite. And this works in a number of ways. You can classify your data according to how sensitive it is. This can be done automatically according to policies, or manually by users themselves. You can track activities on the shared data, and, if you need to, you can even revoke the access to it. Sharing data with others becomes a safe exercise, and you are in control of who can edit, view, print, and forward which parts. Controls for protecting and classifying are integrated with Microsoft Office and other apps directly. That gives one-click securing of data and documents. For example, if Melanie has to send an email with a sensitive attachment to Tony, then she can use Azure Information Protection to secure that attachment. Melanie uses a label that is defined in Azure to tag the document and create a link to Information Protection. Every time a user opens it, the user is validated and the document is protected. Pretty neat. Next up, protecting against bad threats to users."

Secure documents, emails and data outside of the company network.

• Classify Data

  Azure Information Protection INFORMATION SHARING Classify data according to how sensitive it is either using policies, or manually.

• Track Activities

  Track what is happening with shared data and revoke access if needed.

• Share Data

  Safely share data as you can control who edits, views, prints and forwards it.

• Integration

  Controls for document access is integrated with common applications and tools, such as Microsoft Office.

"The last lecture in this chapter is for Microsoft Defender for Identity. Users in any organization are the heart of the business. The problem is that users are well, unreliable, whether they are internal employees or customers. And if these users have access to your organization's servers, documents, and other systems, then there might be a weak link for attackers. There's a constant threat to any infrastructure. If you have anything of value, someone will probably want to get their hands on it. Yep, even dolphins. One way could be to target users specifically. Users are often the weakest link in an organization, and they can be tricked, coerced, and manipulated to provide details to assist attackers and to get them access to the corporation. Microsoft Defender for Identity helps you monitor users in your on-premises environment and their behavior. Microsoft Defender for Identity analyzes user activity and information across your network, including permissions and membership for each user. IT uses this to create a baseline for each user on what their normal routine looks like. If any user does something that is not normal, it will log it as suspicious activity. Microsoft Defender for Identity will also suggest changes to meet security best practices where relevant. Profiling and analyzing users will help reduce the risk the user base poses, and you can make changes based on that. It will monitor several aspects of what is referred to the cyber attack kill chain. That is, the ways that attackers get into your systems. If a user is carrying out reconnaissance and searching for information about usernames, device IP addresses, and other activities that checks out the system. Identifying attempts to compromise user credentials using brute force, that is, trying various combinations of a username and password over and over again. Any attempts to gain access to users with access to more resources and areas within the network. Microsoft Defender for Identity is a non-intrusive tool that helps monitor your user base and alert you to any changes in their behavior. It gives you that extra layer of security and management of your users in order for your system to be a bit more secure. Next, let's look at a security summary.

Sentinel is a security information and event management (SIEM) tool.

Step 1: Data Collection

Step 2: Aggregation and Normalization

Step 3: Analysis and Threat Detection

Step 4: Things Happen (Mostly Magic)

Step 5: Take Action

"The last lecture in this chapter is for Microsoft Defender for Identity. Users in any organization are the heart of the business. The problem is that users are well, unreliable, whether they are internal employees or customers. And if these users have access to your organization's servers, documents, and other systems, then there might be a weak link for attackers. There's a constant threat to any infrastructure. If you have anything of value, someone will probably want to get their hands on it. Yep, even dolphins. One way could be to target users specifically. Users are often the weakest link in an organization, and they can be tricked, coerced, and manipulated to provide details to assist attackers and to get them access to the corporation. Microsoft Defender for Identity helps you monitor users in your on-premises environment and their behavior. Microsoft Defender for Identity analyzes user activity and information across your network, including permissions and membership for each user. IT uses this to create a baseline for each user on what their normal routine looks like. If any user does something that is not normal, it will log it as suspicious activity. Microsoft Defender for Identity will also suggest changes to meet security best practices where relevant. Profiling and analyzing users will help reduce the risk the user base poses, and you can make changes based on that. It will monitor several aspects of what is referred to the cyber attack kill chain. That is, the ways that attackers get into your systems. If a user is carrying out reconnaissance and searching for information about usernames, device IP addresses, and other activities that checks out the system. Identifying attempts to compromise user credentials using brute force, that is, trying various combinations of a username and password over and over again. Any attempts to gain access to users with access to more resources and areas within the network. Microsoft Defender for Identity is a non-intrusive tool that helps monitor your user base and alert you to any changes in their behavior. It gives you that extra layer of security and management of your users in order for your system to be a bit more secure. Next, let's look at a security summary."

• Behavioral Analytics

  Sentinel uses artificial intelligence to learn if any detected behavior is unusual.

• Cloud Scale

  Sentinel can take advantage of the Azure cloud scale and deliver more accurate results fast. Speeeeeeeeed!

• AWS Integration

  Data from AWS services can be fed directly into Sentinel. This gives you one approach for threat detection across your multi-cloud infrastructure.

• Free Netflix?

  No, not really. But many very large organizations use Sentinel to protect their Azure cloud infrastructure.

"Don't trust the hardware your virtual machines run on? Well, that's what Azure Dedicated Hosts are for. If you want the days of old or have actual compliance requirements that dictate you must run your VMs on dedicated hardware you control, then Azure has a solution for you. Azure Dedicated Hosts are a full physical server that you get full control over. You provision it just like a VM in Azure, but there are, of course, some significant differences and benefits. It's all yours. The hardware isolation is at the physical layer, so no one else can sneak onto your server. No other VMs will be placed on the hardware unless they're ones you choose and create. Control over the maintenance schedule. You'll have some choice in when sensitive workloads are updated, and this can reduce the impact on your service a lot. As I mentioned just before, you can meet more stringent compliance requirements when you're in charge of the hardware. You can still take advantage of cloud computing benefits like availability zones, fault isolation, high availability, and scale sets, and you can still use Windows, Linux, or SQL Server as your VM image. Save some coins as well by using existing software licenses that you might have, for example, Windows Server or SQL Server. Dedicated Hosts are a good alternative for the hardware-conscious cloud user, but it can also get expensive. Use it wisely."

Hardware Control

You get control of an entire physical server on Azure.

Yours and Yours Alone

Physical layer isolation means you won’t get any “foreign” VMs on your dedicated host.

Maintenance

Reduce impact on your system by choosing when to install updates to your dedicated host.

Compliance

Take advantage of the stringent Azure compliance in combination with managing your own hardware.

Global Infrastructure

Availability zones, fault isolation, high availability and scale sets come as standard. No optional extras here.

OS of Your Choice

Choose Windows, Linux or SQL Server on a range of VM sizes. Even save money by using your own licenses.

Defense in Depth

You need multiple layers of defense for your infrastructure. Azure has physical, identity, perimeter, network, compute, gateways and firewalls, and data as protection layers.

Securing Network Connectivity

A firewall controls the data coming in and out of a network based on rules. Azure protects against DDoS attack with no downtime to you. A network security group protects a subnet or virtual machine.

Public and Private Endpoints

Most Azure PaaS services are publicly reachable by default. Private endpoints enable private access to PaaS services. Can also disable public access for truly private services.

Microsoft Defender for Cloud

(formerly Azure Security Center) Monitor security hygiene for VMs. Define policies to protect your resources better and respond to incidents.

Azure Key Vault

A secure way to share access to applications and resources with third parties without ever revealing any credentials.

Azure Information Protection

Share files and data inside and outside of Azure and still maintain control over that data. You can control who views, edits, prints, and more.

Azure Sentinel

Collect, aggregate, analyze, and present security issues automatically for you to take action.

Azure Dedicated Hosts

Your own dedicated Azure hardware to install Windows, Linux, or SQL Server VMs on. Gives you control without losing cloud benefits like scaling, scale sets, fault isolation, and availability zones.

Microsoft Defender for Identity

(formerly Advanced Threat Protection) You secure and manage users of your organization. Monitor users’ behavior, create a baseline of this behavior, and report on any anomalies from it.