This course covers the Secure Resources part of the 70-534 exam, which is worth 20-25% of the exam. The intent of the course is to help fill in an knowledge gaps that you might have, and help to prepare you for the exam.
Welcome back. In this lesson we'll be covering data security.
Data lives everywhere and we need to secure all of it, and that's not a simple task. Let's start with talking about Azure stored service. Stored service is a single service with different types of storage including options for object, table, disk and queue storage.
Currently, Azure allows the encryption of blogs using a managed form of encryption. Azure will seamlessly encrypt the data before persisting it and decrypt is before reading it.
And you can enable this feature with the toggle switch. And then, anything that's newly added is going to be encrypted. And if you were to disable encryption, then similarly to before, anything newly added won't be encrypted.
And it's important to note, this functionality is only for the resource manager storage accounts, not the classic. So, that toggle is going to handle data at rest for blog storage. For data in transit, you can use HTTPS. For the other storage options, you'll wanna use the HTTPS option for in transit.
However, for data at rest, you're going to have to bring your own solution. Azure storage library for .net provides encryption and it will allow you to handle encryption client-side. This approach works well because it allows you to control it in code.
And it can even integrate with Azure Key Vault, which is something we'll talk about in a later lesson. If you want to learn more about the ways you can handle encryption on the client side, with the Azure storage library, then check out https://goo.gl/gt1bLj. Next up let's talk about SQL server.
It's not uncommon for solutions architects who are building out HIPAA compliant applications, or apps that are similar with their security requirements, to require encryption for the data that's in transit and at rest. So, to facilitate that SQL server has a feature called Transparent Data Encryption, abbreviated T-D-E. What it does is it encrypts the database, associated back-ups and transaction log files behind the scenes and allows us as developers to query the database without any changes to our code.
So, TDE is gonna cover data at rest for SQL. And for in transit you'll want to use SSL with whatever libraries the developers are actually using. For SQL, there's another option that will be useful in some scenarios and that's column level encryption.
This is a great way to handle the individual columns where you would never want to filter on the data that's in that column. This is a credit card or something like that. A column level option has a bit of a performance hit because you'll be decrypting the data before fetching it. So, depending on the size of the results that returned, you could see performance degrade over time.
Column level encryption does require a code change to use it, though it is worthwhile for some scenarios. When it comes to hosting SQL server, you can go the platform-as-a-service route and use Azure SQL and in that case it's going to easily allow you to enable TDE via the portal, powershell or T-SQL.
Or you can host it yourself, either on-prem or IaaS VMs and in that case you can enable TDE; however, you also have more responsibility for securing the server, back-ups and everything else. Alright, let's talk about Azure disk encryption.
Azure disk encryption allows you to encrypt your Windows and Linux IaaS virtual machine disks. It uses BitLocker for Windows and DM-Crypt for Linux. It's integrated with Azure Key Vault, so you can easily manage the disk encryption keys.
What this means is that Azure disk encryption will provide encryption at rest and this is important for many companies because they need to adhere to strict compliance regulations. In order to get all this working, all of the resources that you need have to be in the same region.
That includes things like VMs, storage accounts, Key Vault, etc. I mentioned previously that Linux and Windows are both supported and while that's true, the support is only for some versions of each. Server 2008 R2, Windows server 2012 and 2012 R2, as well as Windows 8 Client and Windows 10 Client. And for Linux we can use Ubuntu, CentOS, SUSE and RedHat.
Roughly how this works is that we create an active directory application and that application will have the permission to access the keys in our key vault.
And then, the application becomes the end point that our IaaS VMs talk to so that they can fetch the encryption keys. The set-up process for this, currently, is a bit cumbersome. You bounce between the classic portal, the new portal and the powershell command line.
Microsoft does an article that contains the steps to set this up and I'm gonna link it here because it covers a lot of the scenarios for why you'd use this and how you'd configure things. The URL again is a Google-shortened URL, so it's case-sensitive, it's gonna be https://goo.gl/2ebneR.
Alright, let's wrap up here. In our next lesson we'll be talking about role-based access control. So if you're ready to keep going, then let's get started.
About the Author
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.