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 discuss data encryption and data masking. Let's start with features in Azure SQL Database. Azure SQL DB supports what is known as Transparent Data Encryption, or TDE for short. TDE provides at rest encryption of data across the primary database, log files, and backup files. TDE applies symmetric encryption of all data as it is written to or read from disk. All done transparent to application code, thus the name. The key is stored on the Azure SQL Database server.
At rest encryption is important, should someone gain unauthorized access to any of the primary database logs or backup files. A malicious user would not be able to decrypt and thus would not be able to read these files without access to the key. SQL Database also supports column level encryption. With T-SQL commands, you can create symmetric keys within the database and use these to encrypt and decrypt data on the fly. This is best seen with a bit of SQL code. The key aspects are shown here. A table is created that includes a VARBINARY column that is to hold the encrypted version of the data. T
he OPEN SYMMETRIC KEY instruction references the certificate that's generated for us in the key that we've provided, and we use that information to insert a credit card and apply a cryptographic operation as the credit card is inserted. The inverse of this operation is a decrypt. Similarly, we use OPEN SYMMETRIC KEY to access the encryption key and certificate, then the SELECT statement uses that same information to retrieve the credit card information in the clear. At the bottom of this slide, you can see encrypted version of the credit card and the decrypted version. Azure SQL Database also supports dynamic data masking. Dynamic data masking is a column-level function in which the database designer can choose to apply a mask to the data in that column, such as changing the first 12 digits of a 16-digit credit card number to some other character as the data is returned from the database. If the data is stored unmasked, but unless otherwise configured, accounts selecting data from this column would see only the masked value. Seeing the unmasked value is a privileged operation, and any individual user account can have this privilege added or removed.
The slide on screen shows how you would realize that with SQL code. As you can see, the CREATE TABLE statement looks very similar to a normal CREATE statement, except there's an addendum to the column definition for CreditCardNumber. It specifies a mask. A mask can also be specified after the fact, and you can even do this through the Azure portal. The syntax of the INSERT statement, however, is normal. The INSERT statement does not distinguish between columns that will be masked and columns that will not be masked. Then we have GRANT UNMASK and REVOKE UNMASK.
Those show how we would add or remove the unmasking privilege for a particular account. If you look at the table at the bottom, on the left-hand side, you see what a credit card number would look like for a user who did not have the unmask privilege, whereas on the right, you see the credit card number as it would appear to a user who did have the unmask privilege. Let's move on to Azure Storage. Storage has built-in support for encryption. This is service side encryption, similar to the TDE or Transparent Data Encryption feature we covered for Azure SQL Database. It is supported as two way encryption using symmetric keys, and these are managed directly and transparently by Microsoft. All we need to do is turn on the feature, and our data is encrypted at rest. Now let's go back into the portal and demo a few of the features that we just talked about.
Let's start by encrypting a storage account. We have two storage accounts created. This bottom one is actually the storage account backing the disk for one of our virtual machines. We could choose to use full disk encryption on the virtual machine itself. That would be a bit longer, as this would say Windows Virtual Machine, and there's an equivalent for Linux. But that's not what we're doing here. This is a different layer of encryption. This is a transparent encryption option available through Azure Storage, which is the backing data store behind the VHD. We see there's an encryption tab here, and all we need to do is enable and save. There's one small caveat here.
Currently, this feature only works on new data written to this storage account. Any data that's already been written will remain unencrypted. So, if you wanna use this feature, where sensitive data will be stored, you wanna turn it on early. Let's move on to SQL Database. Let's choose azurebookstoredb, and similar to the storage option, with a tab here that allows us to simply turn on data encryption at rest. Change it to on and we hit save. Says, encryption in progress, because it's going back to encrypt all the data that's already in the database.
So, with a couple of mouse clicks, we've turned on encryption for a storage account, and we've turned on encryption for an Azure SQL Database. Let's look at a couple of other features. Before we demo dynamic data masking within Azure SQL Database, let's first take a look at using an Azure Active Directory account to log into SQL Database itself. To do this, we wanna switch over to the database server hosting this database. Here's the server. Click over there, and the server has an active directory admin option. We'll choose that. You can see, we've already configured this, but if we hadn't, we would do the following: we would choose Set Admin, then we would choose the user that we wanted to have as the active directory administrator for this database. We could also use a group here, so you could have multiple AAD users within that group who would all also become admins. Since we've previously configured an Azure directory admin, let's just close.
Now we're back at the database level, and there's some tools here. One of these tools is a query editor. Gonna open this query editor for the Azure Bookstore Database. I'm already logged in as the admin user, so I'll take the opportunity to make a few changes to the database. If you read along here, you could see that we're creating a table. The table is a simple database table with four columns. It's called Account. Has an ID column, a Name column, an Email column, and a Credit Card column. Then we insert four rows into it, and there are a couple of SELECT statements at the bottom, so we can see what we've done, and then an additional couple of STATEMENTS. This one adds a user to this database. This is what's known as a contained user. This means that this user's account is only in this physical database. For example, if we had a geo-replica of this database and we wanted the same user, we would create that user in that geo-replica. The FROM EXTERNAL PROVIDER aspect of the CREATE USER means that we're getting them from outside of the database and that external provider in this case is Azure Active Directory. Once we've created the user, we'd like to give this user permission to SELECT on the account table that we're creating. This means they can execute a SELECT statement, but not an UPDATE or DELETE, for example. Let's run these commands.
Looks like the table was created correctly. Our four rows were successfully inserted. And as you can see, some data was returned. Let's capture the SELECT * FROM account statement, copy that to the clipboard. Take note of the fact that the data we view here shows everything in the clear, including the credit card information. We see the full credit card. Let's log out of this user, and again, remember that this is the most privileged user, and we'll log back in with a different user, and we'll use the database user that we just added. So this is email@example.com. So now we're authenticated as a new user as firstname.lastname@example.org. We run this as the db user and we see the same information. We can see that the db user has access to the database, this account is able to log in, and it can see all the data. Let's close out of here for now.
We'll come back shortly. Let's go to the Dynamic Data Masking tab, and Azure has scanned our database, and noticed two columns that we might wanna add data masking to. Let's add masking to the credit card column. Save, and let's go back to the tools. Back to the Query editor. We'll re-log in as our db user, and let's re-run our SELECT statement. And as you can see, the credit card column comes back masked. We can only see part of the credit card number. And before we leave this lecture, let's point out a couple of additional resources. There are more SQL DB Encryption Options. Check this link for more information (https://docs.microsoft.com/en-us/azure/sql-database/sql-database-security-overview). One of those is called SQL DB "Always Encrypted," and this is a feature that happens on the client (https://docs.microsoft.com/en-us/azure/sql-database/sql-database-always-encrypted-azure-key-vault). So data is encrypted before it's sent to Azure SQL Database, and it's decrypted when it's returned from Azure SQL Database. This isn't really an Azure feature, but it's a valuable one to know about. You can store the encryption keys within Azure Key Vaults.
This article shows how the user also encrypted while storing your encryption keys in Azure Key Vaults. Similar to "Always Encrypted" for SQL Database, Azure Storage also has a client side encryption option, and you can also store your encryption keys in Azure Key Vaults (https://docs.microsoft.com/en-us/azure/storage/common/storage-client-side-encryption). Service Fabric security features are worth mentioning, and this article talks more about those, including their node-to-node encryption (https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-security). You can use Azure Active Directory Accounts within Azure SQL Database, a capability we just demonstrated. There's more information here (https://docs.microsoft.com/en-us/azure/sql-database/sql-database-aad-authentication), and we also showed how to use Azure SQL Database's Dynamic Data Masking feature (https://docs.microsoft.com/en-us/azure/sql-database/sql-database-dynamic-data-masking-get-started).
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.