Learning Objectives

• Configure security policies to classify, protect, and manage data
• Configure data retention for storage and databases
• Set up Azure SQL security features and auditing
• Learn how to configure storage account security and access
• Learn how to secure HDInsight clusters
• Configure Cosmos DB security
• Configure Data Lake security
• Learn good design features of an Azure application
• See how Azure App Services can secure your app
• See how a governance policy can help formalize security requirements

Intended Audience

• People preparing for Microsoft’s AZ-500 exam
• System administrators
• App developers

Prerequisites

• Experience with Microsoft Azure
• Experience with Office 365
• Basic knowledge of computer security principles
• Basic networking knowledge

Azure App Services provide a number of ways to secure your applications. Your app is automatically secured with HTTPS and a certificate related to the Azure website's .net domain. As we have previously talked about, you can also secure your app with a custom certificate related to a custom domain name. You can enforce HTTPS and TLS 1.2 at the click of a button or two. You can restrict app usage to specific IP addresses.

Azure App Service supports authentication and authorization using tokens, more specifically, JSON web tokens and identity providers. This architecture has been around for some time now and basically involves a trusted identity provider issuing a token, usually with a limited lifetime, to a user, with which they're authorized access to web services or app. The cornerstone of this design pattern is the identity provider. They are called trusted because we trust that they have correctly identified the user as who they say they are. There are five default identity providers: Azure Active Directory, Microsoft Account, Facebook, Google, and Twitter.

In addition to users authenticating, you might want to authenticate one service to be able to use another service. As we saw with HDInsight Security, we can use a managed identity to make this task easier. In the HDInsight section, we created a user-managed identity which exists independently of other services. You can use one of these, or you can create a system-assigned identity within your app service. One key difference is that a system-assigned identity only exists in the context of your app service and will be deleted if your app service is deleted.

One thing to bear in mind when using resources within the Azure network is that it is a shared space, so you should still encrypt your communications. This is analogous to driving on a racetrack as opposed to the public road. There will be other cars on the track, not as many as on the public road, and you hope they will all be well behaved, but accidents can still happen. Another option is integrating with an Azure virtual network, as we saw with data lakes. However, this virtual network still uses the Azure shared network infrastructure. To achieve full isolation for your app, you can deploy your app to an App Service Environment (ASE). An App Service Environment is designed for high performance, and is a fully isolated environment that is dedicated to running the app. As an ASE is deployed to a virtual network, you have all the options of IP address filtering and connecting it to your on-premise network.