1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Microsoft Azure Security Solutions

Securing the Azure Portal

Contents

keyboard_tab
Course Introduction
1
Introduction
PREVIEW3m 20s
Course Conclusion
10

The course is part of these learning paths

AZ-500 Exam Preparation: Microsoft Azure Security Technologies
course-steps 11 certification 1 lab-steps 3
AZ-900 Exam Preparation: Microsoft Azure Fundamentals
course-steps 9 certification 1 lab-steps 3
Architecting Microsoft Azure Solutions
course-steps 10 certification 6 lab-steps 5
Azure Services for Security Engineers
course-steps 8 certification 4 lab-steps 3
Developing, Implementing and Managing Azure Infrastructure
course-steps 10 certification 7 lab-steps 2
more_horiz See 2 more
play-arrow
Start course
Overview
DifficultyIntermediate
Duration1h 32m
Students2426
Ratings
4.7/5
star star star star star-half

Description

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.

Learning Objectives:

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

Lessons:

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

Transcript

In this lecture, we look at securing the Azure Portal through role-based access control. Azure allows you to control access to subscriptions, resource groups, and individual resources. This can be done at an individual user level or through groups of users. Typically this is organized by users who have a particular role in the organization. The bigger the company or the more complex the system, the more roles they're likely to have.

An example of such a role might be deployment engineer. Suppose you have an Azure subscription which includes a storage account and a website. Deployment engineers might be allowed to deploy the web application which accesses the storage account, but they should never need to look at or access any of the data in the storage account itself. We could give access to the deployment engineer to deploy the web application but not give them access to the storage account. And suppose we have a business analytics team with members who need to view the data stored in the storage account, but should never need to have anything to do with deploying or maintaining the application itself. We could create a second role for BI, for Business Intelligence, with read access to the storage account and no access to the web application. And for a final example, consider someone in the role of analyzing Azure SQL database performance.

They would need some access to SQL database tables, but not complete access. We'll begin to model this role in an example shortly. The Azure portal helps us manage these roles and who has access to which type of resource. A useful concept to understand is the idea of the control plane, sometimes also called the management plane. The Azure portal is mostly at least, concerned with the control plane. Control plane operations are CRUD operations on Azure resources. Some examples of control plane operations might be creating a new SQL database server, configuring a network security group firewall to allow access to say port 443 from some specific range of IP addresses, deleting an Azure storage account, modifying the identity and access management permissions on an Azure resource group, or auditing control plane operations, perhaps to see the recent permission changes on Azure resource groups.

Those are all examples of control plane operations and they can all be performed through the portal. Let's distinguish these from data plane operations. Data plane operations happen within the resources we've created from the control plane. For example, connecting to an Azure SQL database and executing the select statement are both examples of data plane operations. Shelling into a virtual machine, uploading files to blob storage, interacting with the user interface of your business application; these are all examples of operations happening in the data plane.

In the shared responsibility model for cloud security, you are responsible for the security of your application logic, and in the terminology we're discussing right here, this is data plane, because from Azure's point of view, your deployed application code is just data. Azure doesn't know what's inside of it, so you need to secure it. The important thing to realize is that the Azure portal is primarily about governing access to control plane operations. We log into the Azure portal with our Azure Active Directory credentials, but AAD is only about the authentication, determining who has logged into the portal. Now it becomes up to the portal to decide what this authenticated user is authorized to do within the portal. Azure implements a model to manage user entitlements based on assigned roles. The industry calls this model Role Based Access Control or RBAC for short.

The examples we walk through in this lecture we'll use the Azure portal, but it is important to realize that this is just one interface. Azure resources can be created, modified, deleted, viewed, and audited through the portal yes, but also by a REST API's, PowerShell, and the command-line, not to mention assorted language software developer kits. All these access methods share a common backend and all of these access methods are protected by the same RBAC controls. It is also worth noting that Azure records control plane changes and provides a strong auditing capability of these changes. Now let's go over to the portal to see how RBAC controls are managed.

Here we are in the Azure Active Directory blade looking at the users and groups management screen. We'll walk through configuring RBAC controls using users, but you should also realize that you could do similar operations with groups. Let's go take a look at which resources I have access to. We'll choose Azure resources here. As you can see, the AAD Global Admin user has access to only one resource, and that's the azurebookstore.com subscription and the role is owner. So I have complete control over every single resource in this entire subscription. That's not normally what you'll wanna do to control access using RBAC. You'll usually want something more fine-grained. Let's go see what that would look like.

Go back out here and let's take look at the db@azurebookstore.com user. Look at the resources they currently have access to and there are none listed. To demonstrate what this looks like, let's hop over to another browser with this user as already logged in. You can see that this is the db@azurebookstore.com user and the list of resources that this user can see is empty. Let's hop back over to the admin user's view and of course the fact that the DB user couldn't see any resources is consistent with the fact that they are not permissioned to access any resources. Let's give them access to a resource. Let's go to Resource Groups, and let's look at the Azure bookstore resource group. We can see that it contains a SQL database server and a SQL database.

Let's give them access to everything in here. So we'll go to the Access Control tab and we'll do Add. Let's choose our DB user and we'll choose a role. You can see there are many roles. Owner is the role I gave the admin user to the entire subscription; that's too powerful generally. So I'm gonna scroll down here, glancing at many of the roles. There's a role here that is appropriate for our DB user; this is the SQL DB Contributor. This will give us some control over managing databases but not too much power. We'll choose this role and we'll hit save. And let's hop over to another web browser to log in again with our DB user, and see if our permissions have changed. Here we are back in the portal and the user interface is telling us that this DB user now has access to the Azure bookstore server, and Azure bookstore DB resources.

Before we leave this section, let's point out a couple of other resources. Here are some additional resources to dig deeper into RBAC management in Azure (https://docs.microsoft.com/en-us/azure/role-based-access-control/overview, https://docs.microsoft.com/en-us/azure/role-based-access-control/role-assignments-portal, https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles), and the RBAC roles we looked at are standard ones within Azure; you could see that the list is quick large. But you could also create custom roles (https://docs.microsoft.com/en-us/azure/role-based-access-control/custom-roles). Today you need to do that through PowerShell or the CLI, but eventually you'll be able to do so through the portal. Similarly, changes can be audited by a PowerShell or CLI, and eventually again, those will be available through the portal (https://docs.microsoft.com/en-us/azure/role-based-access-control/change-history-report).

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.