The course is part of these learning pathsSee 2 more
Azure Security Solutions
About This Course
Security is a critical concern for anyone who uses the cloud. Microsoft takes this seriously and built and operates the Azure Platform with security as a key principle. Microsoft secures data centers, and management applications; and provides pay-as-you-go security services. Learn how to take advantage of these security features and services to enable strong security practices in your organization and to protect and secure your own cloud applications.
This course is for security engineers, chief security officers, solution architects, information technologists or anyone wanting to understand security options within the Azure platform.
Viewers should have a basic understanding of cyber security, authentication and authorization best practices, and encryption. Some familiarity with the Azure platform will also be helpful but is not required.
Understand the shared responsibility model
Learn how to secure Azure resources such as virtual machines and storage accounts
Learn how to secure your Azure-based applications
Learn how to monitor your Azure resources with Azure Security Center
Welcome and Introduction: A brief introduction to the course and an overview of what Bill and Maura will be covering.
Shared Responsibility: In this lesson we'll cover Cyber Security, using CIA Principle: Confidentiality – Integrity. Availability; what security professionals do to ensure the parts of CIA: Prevent – Detect – Respond.
Microsoft’s responsibilities and their own security/compliance processes. What a customer is responsible for. And finally the tools that Azure provides, including AAD, Encryption, secure networking
Protecting Accounts: In this lesson we'll cover Azure Active Directory, and Mult-Factor Authorization.
Securing the Azure Portal: In this lesson we'll cover role-based access control.
Indentity Management for Apps: In this lesson we'll cover AAD protection and integration for business Apps.
Network Security: In this lesson we'll cover Virtual Private Networks and firewalls.
Data Security: In this lesson we'll cover Encryption and Masking.
Secrets Management: In this lesson we'll cover Key Vault and Shared Access Signatures.
Monitoring and Audting: In this lesson we'll discuss the Azure Security Center.
Course Conclusion: Course Wrap-Up
In this lecture we look at Azure features that support network security. We'll first look briefly at virtual private networks, then we'll look at firewalls in a little bit more detail. A VPN, or virtual private network, is a technology for securely extending a private network out over the public Internet. Azure offers two types of VPNs, one is a Point-to-Site VPN network, another is a Site-to-Site VPN network. A Point-to-Site, or P2S VPN network is a connection between an individual computer and an Azure virtual network connected over the public Internet. Point-to-Site uses SSTP, the Secure Socket Tunneling Protocol to secure the connection. Point-to-Site connections are very easy to setup. A Point-to-Site network would be a typical choice for an employee connecting from home. Azure also offers a Site-to-Site, or S2S VPN network. A Site-to-Site network connects an external network to an Azure network using a VPN tunnel that runs over the public Internet.
The connection on the non-Azure side requires a VPN device and a public IP address. A typical use of the Site-to-Site VPN would be to connect an on-premises network to an Azure network, or in certain hybrid cloud configurations. And finally, we have Azure ExpressRoute. ExpressRoute is not a VPN technology per se, but is mentioned here since it's commonly used alongside VPNs, or sometimes in lieu of a VPN.
Before using Azure ExpressRoute you would need to reach out to a network connectivity partner that has already established an ExpressRoute offering with Microsoft. You'd work with one of these vendors and arrange to physically hookup a private network between your non-Azure network, which maybe would be your old school data center, might be a colocation facility, could be any place where you have an existing network and the connectivity provider has a connection to, and then they would extend that to the Azure Datacenter region that you'd like to ultimately connect with.
Once this is arranged through the connectivity partner, so you have the physical network in place, you then can enable Azure ExpressRoute to link your datacenter or colo to your Azure virtual network. The network connection is private, meaning it doesn't traverse the public Internet, and it typically runs much faster and with lower latency than Internet connections. One common use is as a network pipe to speed up a Site-to-Site VPN. Azure also has a number of firewall options, let's talk about a few of them.
First of all, when you create a virtual machine with the Linux and Windows operating systems, the operating system itself comes with a firewall technology. Under Linux this would be iptables, and under Windows Server this would be typically be Windows Firewall. These are really features of the operating system itself, not really an Azure feature, but we mention it here because this is part of your Defense in depth strategy, and you don't wanna confuse the different layers of firewall. DocumentDB is a NoSQL document-oriented database that is run as a service by Azure.
This has its own firewall technology. We won't really talk any more about DocumentDB or the Windows and Linux virtual machine firewalls, but we're gonna dig in just a little bit into these other categories. We'll talk about Azure SQL DB Server firewalls, we'll talk about network security groups, we have the Application Gateway with the optional Web Application Firewall, and then we have the third-party firewall ecosystem visible through the Azure Marketplace. Let's talk about protecting your Azure SQL databases with a firewall.
Before we get into that, I wanna point out that there is an Azure SQL Database-specific firewall option, but we're not gonna talk about it in this lecture, we will instead focus on the Azure SQL Database Server level firewall, little different. The Azure SQL Database Server level firewall, of course would protect all SQL databases running on that server, and the firewall is pretty simple. It supports blocking based on IP addresses, or ranges of IP addresses, and with one exception, you can check a box to optionally allow IP addresses originating from within Azure to also be whitelisted. Let's have a look at Azure SQL Database firewalls in a quick demo.
So here we are back in the Azure portal. Let's set a firewall rule on the azurebookstore database so that I can remotely connect to it from my laptop. We have a convenient list of resources here, so I'm gonna choose azurebookstoredb, and note that this is a SQL database, not a SQL database server. So I'll choose that, it brings me to the SQL database blade.
As I mentioned earlier, the firewall rules are actually set at the SQL database server level, and there's a convenience function in the Azure SQL database blade here that is Set server firewall. If I click this it will bring up a user interface that will allow me to set firewall rules for the entire database server. Instead I'm going to navigate to the server itself, and we'll set the firewall rules over there. There's a tab on the left here called Firewall, I've chosen that, and you can see that there are no rules configured currently. So since I'm on my laptop, outside the Azure network, my IP address is not whitelisted to be allowed through this firewall, so I cannot access this Azure SQL database currently.
Let me prove that, gonna hop over to SQL Server Management Studio, it's already preset to go to the azurebookstoreserver.database.windows.net, which is the database that hosts the Azure SQL database that we're trying to reach. I'm gonna type in the password and try to connect. Since there's no firewall rule, my connection is denied. There's actually quite a nice interface here in the recent versions of Microsoft SQL Server Management Studio, because right from this experience I can actually set a firewall rule, but to make a more general point, 'cause you might be using different tools, I'm going to cancel out of this and we'll go back to the Azure portal and we will set the firewall rule manually.
So we could type in the rule here with a starting IP address and an ending IP address from the IP address that we're running from, which is hopefully posted here for us, and there's even another helpful function which is Add client IP that I'll simply click, and it populates an entire rule for me. Since I'm running from my office, I'll just say office, save that, Updating firewall rules, now it's been successfully updated. Now I'll go back to my SQL Server Management Studio window, and I'll attempt to connect again, and this time it looks like it's working. Here are my databases, here's my azurebookstore database, and my very simple schema... and I can select, so I'm in. So that demonstrates that with an Azure SQL database if I don't have a firewall rule I can't do maintenance in it and if I had an application attempting to access it, it also may not be able to access it. Let me talk a little bit more about that.
There's a special rule that says Allow access to Azure services, this is the rule that says that if the originator comes from within the Azure IP space, then you can allow it. So this is actually a convenient way to make sure that if you have say, a service running on a virtual machine, or in a WebJob, or in Service Fabric, anything like that that is programmatically trying to access your SQL database and you think that's okay, you can set this to ON, and if you wanna be very detailed and very specific about exactly which IP addresses are able to access your SQL database, you'd wanna turn this to OFF and you wanna add rules to allow the IP address from which your service is running to be whitelisted explicitly. Network security groups, or NSGs for short, are an Azure firewall technology that implements a stateful packet inspection with some simple inbound and outbound rules to deny or allow connections, based on a few properties. These include the source IP address and port, the destine IP address and port, and the protocol, whether it's TCP or UDP. The source IPs and destination IPs can either be individual IPs, or they can be ranges of IPs.
The network security groups work with both ARM resources and the classic Azure Service Manager resources, but we're gonna focus on the ARM resources, these are the Azure Resource Manager resources, the more modern approach, and the approach that you wanna use going forward, and the two in particular that are most interesting are that you can attach a network security group to a virtual network, or to a NIC card, a network interface card. Let's go have a look at using a network security group to lockdown a virtual network that's protecting a virtual machine. Here we are back in the Azure portal, let's start by going in to the Virtual machines list, let's simply select the first virtual machine listed which is called rdp, we'll use this for a quick RDP demo. There's a handy Connect option here on the top, I'm gonna click this, and what this does is creates a file with the extension .rdp, and in this file all the relevant connection information is already pre-populated, so if I simply open this RDP file it brings up my local RDP client, and it brings me directly to this virtual machine. I need to provide my password. The username rdp was pre-populated in the file because that's the username I provided when I created this virtual machine in the portal, and I can see that my password is accepted, and here I am in an RDP session for this virtual machine. We can close down this virtual machine, and let's go back to the Azure portal.
A quick glance at the properties of this virtual machine tells us that it's protected by a virtual network. This virtual network is called rdp-vnet, and let's go have a look. The most important part of the properties of this virtual network is the list of connected devices. There's only one connected device and it's a network interface. Let's drill into the network interface, rdp579. And finally, this network interface has one interesting property which, as you might be expecting, is a network security group. The network security group is called rdp-nsg, let's go in and take a look. Here in the network security group blade in the Azure portal we see a list of all the firewall rules configured for this network security group. There's one inbound rule, and there are zero outbound rules. Let's drill into the inbound rules to have a look.
There's only one rule here and before we examine it, let's go into the detail screen for that rule. This rule is called default-allow-rdp, its priority is 1000, its source is Any, the service that it supports is RDP, the protocol is TCP, and the port range is a single port, 3389, and the action is Allow. This collection of settings allows an RDP connection to be made through this network interface from any source IP address, public or private. We could make some changes however, we could change it to be any Internet address to being a CIDR block. This is a range of Internet addresses, but very specific ones. With CIDR addressing we can specify a contiguous block.
There are also some special tags that Azure recognizes to identify other kinds of source networks, so these tags are Internet, VirtualNetwork, and AzureLoadBalancer. So for example, Internet as a tag would mean that this would accept connections from the public Internet, and also there's a service dropdown, and this is a convenience function which gives you english names for the protocols, and it assigns ports accordingly. So if we change from RDP for example, to SSH, we can see that the port down here changed to 22, which is the SSH port, and if we go to, just as another example, we'll go to HTTP, we see port 80, and you can imagine HTTPS would be port 443, and so forth. We can also change the rule, of course, from Allow to Deny, to say that certain ports or certain IP address sources are not allowed. What we'll do here is I'd like to cancel out of this, and let's go back into this rule, leave it otherwise configured as-is, and we'll just change it from Allow to Deny.
Let's save, after a couple of seconds the firewall rule is updated, and let's go back over to our remote desktop client and we'll re-enter the virtual machine through RDP. This is running this exact same RDP file with the exact same connections as before, but as you can see, this time it timed out. The firewall has denied our connection, the firewall's doing its job. Another kind of firewall available through Azure is the Web Application Firewall, or WAF for short. WAF support is available along with the Azure Application Gateway. The Application Gateway is a network appliance you can put in front of your application to provide load balancing, SSL termination, cookie-based session affinity and some more features. If you use the version of the Application Gateway that comes with a WAF you get a layer 7 firewall designed to defend common web vulnerabilities and exploits such as SQL Injection and cross-site scripting. The particular WAF bundled with the Application Gateway has protections for vulnerabilities listed in the OWASP Core Rule Set, and is in particular an implementation of ModSecurity. OWASP is the Open Web Application Security Project and provides a wealth of resources for web application security. Here's a visual, requests coming in on the left, and if the request is, for example, a cross-site scripting attack or a SQL Injection attack, the idea is that the WAF rules running in the Application Gateway detect these patterns and deny them, and valid requests on the other hand, we'd like to go through successfully.
Finally, Azure offers a bunch of third-party firewalls through its Marketplace. Let's go have a quick look at that. To see the list of third-party firewall offerings in Azure, let's navigate to the Marketplace. We'll filter by the word firewall as a simple way to bring up a list of matching products. In the left-most column we see the name of the product, and in the second column we see the name of the publisher. The thing to notice about the publisher is the range of third-party offerings involved in the Azure Marketplace, and how most of them are not Microsoft. Microsoft has some in this list, but most of them are third-parties. So we see Cohesive, and Barracuda, and Palo Alto and Sophos... Imperva, Fortinet, F5, here's one from Microsoft, the network security group technology that we've already looked at, Check Point, and the list goes on and on.
The way this works is you can choose one of these from this gallery, you can add it to your Azure subscription, and they're typically deployed as an appliance on a virtual machine. Some of them are listed as BYOL, this means bring your own license, so you would have a separate business arrangement with the vendor where you would get a license key, and then you would apply that license key to the virtual machine.
Before we leave this lecture, let's point out a couple of additional resources. There's more information on SQL DB Server Firewall here (https://docs.microsoft.com/en-us/azure/sql-database/sql-database-firewall-configure, and on DocumentDB Firewall, and general security within DocumentDB (https://docs.microsoft.com/en-us/azure/cosmos-db/database-security). Virtual private networking with P2S, S2S and ExpressRoute are in the virtual networks section listed here (https://azure.microsoft.com/en-us/services/virtual-network/). More details on network security groups (https://docs.microsoft.com/en-us/azure/virtual-network/security-overview), and several different angles on WAF (https://docs.microsoft.com/en-us/azure/application-gateway/waf-overview) and Application Gateway (https://docs.microsoft.com/en-us/azure/application-gateway/overview, https://docs.microsoft.com/en-us/azure/application-gateway/create-ssl-portal.
About the Author
Bill Wilder is a hands-on architect currently focused on building cloud-native solutions on the Microsoft Azure cloud platform. Bill is CTO at Finomial which provides SaaS solutions to the global hedge fund industry from the cloud, co-founded Development Partners Software in 1999, and has broad industry experience with companies of all sizes – from modest startups to giant enterprises. Bill has been leading the Boston Azure group since founding it in 2009, has been recognized as a Microsoft MVP for Azure since 2010, and is author of Cloud Architecture Patterns (O’Reilly Media, 2012). He speaks frequently at community events, and occasionally at conferences, usually on topics relating to cloud, cybersecurity, and software architecture.