WEBVTT

0:00:02.600000 --> 0:00:08.240000
 In this video, we're going to take a
 look at data encryption at rest and

0:00:08.240000 --> 0:00:11.180000
 in transit in Azure.

0:00:11.180000 --> 0:00:15.280000
 The topics that we're going to
 cover, pretty straightforward.

0:00:15.280000 --> 0:00:18.080000
 We're going to talk about encrypting
 data at rest with Azure.

0:00:18.080000 --> 0:00:22.360000
 We're going to talk about encrypting
 data in transit with Azure.

0:00:22.360000 --> 0:00:27.080000
 I'm going to take you through a quick
 tour of some of the data encryption

0:00:27.080000 --> 0:00:31.140000
 options, both for at
 rest and in transit.

0:00:31.140000 --> 0:00:35.180000
 What's interesting to me is that over
 the last several years, when I say

0:00:35.180000 --> 0:00:38.980000
 options, actually a lot of this
 is no longer an option.

0:00:38.980000 --> 0:00:40.800000
 You have to use encryption.

0:00:40.800000 --> 0:00:43.100000
 I'll talk about that
 and we'll see that.

0:00:43.100000 --> 0:00:49.740000
 But I want to start out by looking at
 what we mean by encryption at rest

0:00:49.740000 --> 0:00:52.040000
 and encryption in transit.

0:00:52.040000 --> 0:00:55.960000
 Let's take a look at
 the whiteboard here.

0:00:55.960000 --> 0:01:00.300000
 Let's say that I've got
 a storage account.

0:01:00.300000 --> 0:01:03.740000
 The storage account
 is this concept.

0:01:03.740000 --> 0:01:05.940000
 I've got this storage account.

0:01:05.940000 --> 0:01:11.200000
 It's a resource.

0:01:11.200000 --> 0:01:14.360000
 I can of course drop things
 into the storage account.

0:01:14.360000 --> 0:01:20.440000
 Somewhere however, in the actual data
 center, there's physical disks.

0:01:20.440000 --> 0:01:26.080000
 As I upload, let's say a binary
 large object or a blob file.

0:01:26.080000 --> 0:01:33.280000
 This is data.txt because who doesn't
 put their data in clear text files?

0:01:33.280000 --> 0:01:38.940000
 That is at some point being
 stored in a physical disk.

0:01:38.940000 --> 0:01:43.860000
 Now, I've got all kinds of locks
 on the front door, if you will.

0:01:43.860000 --> 0:01:48.600000
 The storage account is controlled access
 and I can use shared access signatures

0:01:48.600000 --> 0:01:51.720000
 or key access and control
 the way people get in.

0:01:51.720000 --> 0:01:54.520000
 But at some point, I still
 have this physical disk.

0:01:54.520000 --> 0:01:57.160000
 And I have to tell you, I was thinking
 about making this really clever

0:01:57.160000 --> 0:02:03.360000
 slide with a thief coming in and stealing
 the disk and kind of animated

0:02:03.360000 --> 0:02:05.480000
 away. But that was just
 a waste of time.

0:02:05.480000 --> 0:02:06.720000
 It would have been a
 waste of your time.

0:02:06.720000 --> 0:02:11.000000
 But the idea is that somebody, here
 we'll put in somebody of ill intent

0:02:11.000000 --> 0:02:16.260000
 here. You can tell
 he's of ill intent.

0:02:16.260000 --> 0:02:18.520000
 He's not smiling.

0:02:18.520000 --> 0:02:25.720000
 And that person could make
 off, abscond with the disk.

0:02:25.720000 --> 0:02:29.620000
 Now, that's a pretty improbable
 scenario, right?

0:02:29.620000 --> 0:02:33.140000
 Because in order for somebody to actually
 make off with your physical

0:02:33.140000 --> 0:02:38.860000
 disks, that means that they have penetrated
 the actual Azure data center.

0:02:38.860000 --> 0:02:43.580000
 They've somehow identified the disk
 that has your information on it.

0:02:43.580000 --> 0:02:48.140000
 And they've been able to copy it or
 make it out of the data center with

0:02:48.140000 --> 0:02:53.120000
 that. Again, fairly improbable,
 but there is that capability.

0:02:53.120000 --> 0:02:57.720000
 So what you typically have with what's
 called encryption at rest is that

0:02:57.720000 --> 0:03:04.220000
 that data file, when it's physically
 stored in the actual disk over here.

0:03:04.220000 --> 0:03:10.860000
 So this is my data.txt,
 but it's encrypted.

0:03:10.860000 --> 0:03:16.820000
 And that, of course, is just either
 random typing on my part or standard

0:03:16.820000 --> 0:03:19.380000
 representation of encrypted data.

0:03:19.380000 --> 0:03:26.100000
 So that even if that bad actor were
 to abscond with the physical data,

0:03:26.100000 --> 0:03:28.100000
 that doesn't really help that.

0:03:28.100000 --> 0:03:34.920000
 And you see this encryption at rest across
 a wide range of services within

0:03:34.920000 --> 0:03:38.540000
 Azure. Storage accounts, for example,
 when I first started using storage

0:03:38.540000 --> 0:03:42.400000
 accounts, there was not the concept
 of encryption at rest.

0:03:42.400000 --> 0:03:44.920000
 And then it became kind of
 a hard to find option.

0:03:44.920000 --> 0:03:46.780000
 And then it became
 the default option.

0:03:46.780000 --> 0:03:48.620000
 And then finally, it's
 not even an option.

0:03:48.620000 --> 0:03:51.500000
 It's just the way storage
 accounts work, right?

0:03:51.500000 --> 0:03:56.400000
 But in addition to that, we've got storage
 at rest for Azure SQL Server

0:03:56.400000 --> 0:04:02.260000
 databases for MySQL,
 for Postgres SQL.

0:04:02.260000 --> 0:04:07.980000
 So pretty much all your
 SQL data for Cosmos DB.

0:04:07.980000 --> 0:04:11.100000
 And really pretty much there's more
 of a list, but those are kind of I

0:04:11.100000 --> 0:04:13.860000
 would say the big ones that
 you might run into.

0:04:13.860000 --> 0:04:17.660000
 But pretty much if you're storing information
 in Azure now, it will typically

0:04:17.660000 --> 0:04:18.860000
 be encrypted at rest.

0:04:18.860000 --> 0:04:23.080000
 And of course, what's key to that, no
 pun intended, is that separate from

0:04:23.080000 --> 0:04:29.880000
 the data itself, not never stored with
 the data, is a secure key, right?

0:04:29.880000 --> 0:04:36.440000
 So that key, and this of course is
 foundational to data protection and

0:04:36.440000 --> 0:04:39.520000
 encryption key is separate from
 the data itself, right?

0:04:39.520000 --> 0:04:42.300000
 And so that's encryption
 at rest, right?

0:04:42.300000 --> 0:04:46.320000
 And then of course though at some point
 that data is going to be transferred.

0:04:46.320000 --> 0:04:51.300000
 Now one thing to keep in mind, and
 this plays into this next phase, is

0:04:51.300000 --> 0:04:55.680000
 that that encryption at rest is
 transparent to a client, right?

0:04:55.680000 --> 0:05:01.660000
 If I've got a client and that client is
 accessing, let's say they're accessing

0:05:01.660000 --> 0:05:05.600000
 that data in the storage
 account, right?

0:05:05.600000 --> 0:05:09.020000
 I can't have the client be required
 to change the way they write their

0:05:09.020000 --> 0:05:12.800000
 code, depending on whether or not that
 data is encrypted on the back end,

0:05:12.800000 --> 0:05:15.740000
 right? So I've got the locks on the front
 door, if somebody's going through,

0:05:15.740000 --> 0:05:18.980000
 I'm going to assume, right, if they're
 getting through my security and

0:05:18.980000 --> 0:05:23.280000
 they've got a valid key or a valid shared
 access signature that they can

0:05:23.280000 --> 0:05:25.700000
 access at, and then they can pull it
 back and what they're going to pull

0:05:25.700000 --> 0:05:28.200000
 back, right, is the actual file.

0:05:28.200000 --> 0:05:32.520000
 However, there's this, right,
 that communication.

0:05:32.520000 --> 0:05:36.220000
 And typically that communication is
 going over this thing you may have

0:05:36.220000 --> 0:05:40.760000
 heard of, called the
 internet, right?

0:05:40.760000 --> 0:05:43.600000
 And if you haven't heard of that, that's
 really odd, seeing as that's

0:05:43.600000 --> 0:05:44.980000
 probably how you're watching this.


0:05:44.980000 --> 0:05:50.000000
 But in any case, right, the internet
 has, as it turns out, a fair number

0:05:50.000000 --> 0:05:55.320000
 of people that may have nefarious intent
 that may be listening, right?

0:05:55.320000 --> 0:05:59.120000
 And so what you want to do of course,
 is you want to say, all right, that

0:05:59.120000 --> 0:06:03.720000
 data is safe over on the storage side
 and it's safe over on my side, but

0:06:03.720000 --> 0:06:12.980000
 I also need to facilitate some way of
 encrypting that data as it crosses

0:06:12.980000 --> 0:06:19.500000
 between the source, as your storage
 account, SQL Server, MySQL, Cosmos

0:06:19.500000 --> 0:06:24.880000
 DB, etc. And my end where I'm actually
 going to work with this, right?

0:06:24.880000 --> 0:06:29.060000
 And of course, that has to be a way
 that somebody intercepting that data

0:06:29.060000 --> 0:06:33.560000
 cannot or certainly cannot with any
 reasonable level of effort, decrypt

0:06:33.560000 --> 0:06:41.400000
 the data, steal it, or otherwise change
 it or damage that data, okay?

0:06:41.400000 --> 0:06:42.680000
 And that's pretty standard, right?


0:06:42.680000 --> 0:06:46.080000
 Except that's encrypted, I thought
 I missed the T there, right?

0:06:46.080000 --> 0:06:52.980000
 In any case, most of your systems in Azure,
 most of your services in Azure,

0:06:52.980000 --> 0:06:57.780000
 now actually require encrypted communication,
 so encryption and transit.

0:06:57.780000 --> 0:07:02.040000
 SQL Server, just like with the storage
 account, where initially encryption

0:07:02.040000 --> 0:07:06.160000
 wasn't an option and then it became an
 option, then it became the default,

0:07:06.160000 --> 0:07:08.480000
 and then it became
 the only option.

0:07:08.480000 --> 0:07:13.200000
 With SQL Server, there was initially an
 option to choose encrypted transmission.

0:07:13.200000 --> 0:07:18.320000
 Now, with communication to an Azure SQL
 database, you have to communicate

0:07:18.320000 --> 0:07:21.200000
 with encrypted transmission.

0:07:21.200000 --> 0:07:25.860000
 And you'll find that I believe it's
 still an option for MySQL, but it's

0:07:25.860000 --> 0:07:26.940000
 the default option.

0:07:26.940000 --> 0:07:31.160000
 Cosmos DB, the only communication
 with Cosmos DB, is encrypted.

0:07:31.160000 --> 0:07:33.400000
 It's an option for
 a storage account.

0:07:33.400000 --> 0:07:36.520000
 So one of the things that you'll go through
 as you go through these different

0:07:36.520000 --> 0:07:41.460000
 services is you kind of want to look
 at the ones that have options and

0:07:41.460000 --> 0:07:43.760000
 make sure that you do have
 the most secure option.

0:07:43.760000 --> 0:07:46.460000
 But when you do that, you're also going
 to need to make sure that you

0:07:46.460000 --> 0:07:50.820000
 work with your developers and make
 sure that they can in fact use that

0:07:50.820000 --> 0:07:54.880000
 secure option. For SQL Server, for example,
 if you're using older drivers,

0:07:54.880000 --> 0:08:02.100000
 they may not support the encrypted
 messaging syntax or format.

0:08:02.100000 --> 0:08:06.100000
 And a lot of these, like Cosmos DB and
 storage, they use a REST API, so

0:08:06.100000 --> 0:08:09.220000
 they use HTTP or HTTPS.

0:08:09.220000 --> 0:08:16.920000
 But you've got SQL Server has its own TDI
 protocol that it uses for communication,

0:08:16.920000 --> 0:08:21.200000
 Cosmos DB, or excuse me,
 MySQL has its own, etc.

0:08:21.200000 --> 0:08:23.220000
 So you always want the encryption.


0:08:23.220000 --> 0:08:26.460000
 The encryption at REST
 should be a no-brainer.

0:08:26.460000 --> 0:08:30.120000
 The encryption in Translate, at a minimum,
 you should make sure whatever

0:08:30.120000 --> 0:08:34.400000
 applications are integrating with
 your data can handle that.

0:08:34.400000 --> 0:08:39.920000
 Let's take a quick tour of some of the
 encryption options for a few different

0:08:39.920000 --> 0:08:42.560000
 services within Azure.

0:08:42.560000 --> 0:08:51.220000
 Now, to take a look at these, we are going
 to go over to my Azure environment

0:08:51.220000 --> 0:08:53.540000
 and we're going to go
 to a resource group.

0:08:53.540000 --> 0:09:03.400000
 And in this resource group, I have
 a few different databases.

0:09:03.400000 --> 0:09:06.720000
 I've got a Cosmos DB account.

0:09:06.720000 --> 0:09:11.120000
 I've got a MySQL database and
 I have a storage account.

0:09:11.120000 --> 0:09:16.960000
 And if I go to the Cosmos DB, what
 you're going to find with Cosmos DB

0:09:16.960000 --> 0:09:21.780000
 is that there actually aren't any settings
 on Cosmos DB that are going

0:09:21.780000 --> 0:09:27.260000
 to allow me to change
 the encryption.

0:09:27.260000 --> 0:09:31.700000
 So Cosmos DB is encrypted at REST by
 definition, and your communication

0:09:31.700000 --> 0:09:38.780000
 with Cosmos DB is going
 to be through HTTPS.

0:09:38.780000 --> 0:09:43.220000
 For MySQL, I went to MySQL here.

0:09:43.220000 --> 0:09:47.960000
 And if I take a look, I believe this used
 to be an option here and I believe

0:09:47.960000 --> 0:09:50.560000
 that is no longer an option.

0:09:50.560000 --> 0:09:53.320000
 Oh, no, there we go,
 connection security.

0:09:53.320000 --> 0:09:59.340000
 That is the option I wanted.

0:09:59.340000 --> 0:10:02.860000
 There we go, enforce
 SSL connections.

0:10:02.860000 --> 0:10:04.960000
 So by default, you are enforcing.

0:10:04.960000 --> 0:10:10.760000
 You still do have the option with
 a MySQL database to disable that.

0:10:10.760000 --> 0:10:16.260000
 There's no option for the
 encryption at REST.

0:10:16.260000 --> 0:10:22.700000
 For a storage account, I'll go to configuration
 for my storage account.

0:10:22.700000 --> 0:10:25.480000
 I do have the option
 for secure transfer.

0:10:25.480000 --> 0:10:26.400000
 Now, I just created this.

0:10:26.400000 --> 0:10:28.060000
 You'll notice the default
 is enabled.

0:10:28.060000 --> 0:10:29.360000
 I can disable that.

0:10:29.360000 --> 0:10:38.240000
 Now, through the portal interface, there's
 no way to turn off the encryption

0:10:38.240000 --> 0:10:41.600000
 at REST. You might still be able
 to do that through the API.

0:10:41.600000 --> 0:10:46.500000
 I don't think you can even do it
 through the command line anymore.

0:10:46.500000 --> 0:10:52.400000
 Again, there may be some kind of really
 obscure switch that you could

0:10:52.400000 --> 0:10:59.080000
 use. But generally speaking,
 there's no reason to.

0:10:59.080000 --> 0:10:59.260000
 So that's not going
 to be a good option.

0:10:59.260000 --> 0:11:01.360000
 So I'll go ahead and click on the terminal
 overhead impact of the encryption

0:11:01.360000 --> 0:11:06.260000
 and decryption. But there's a good chance
 that's not going to really be

0:11:06.260000 --> 0:11:08.800000
 a major impact on
 your performance.

0:11:08.800000 --> 0:11:10.000000
 So there you go.

0:11:10.000000 --> 0:11:11.980000
 A few different options.

0:11:11.980000 --> 0:11:20.360000
 Now, if I go to SQL databases and if
 I go to, I'll say the demos database.

0:11:20.360000 --> 0:11:24.600000
 Now, within this, I do have,
 it looks like an option here.

0:11:24.600000 --> 0:11:27.300000
 I've got transparent
 data encryption.

0:11:27.300000 --> 0:11:32.800000
 I still have the option of turning off
 encryption at REST for a SQL database.

0:11:32.800000 --> 0:11:37.200000
 Now, in all honesty, by the time that
 you get to this video, if you go

0:11:37.200000 --> 0:11:39.760000
 and check this out, this may be
 an option that is taken away.

0:11:39.760000 --> 0:11:43.640000
 And it's something that, though I have
 no inside information on this,

0:11:43.640000 --> 0:11:47.220000
 I would expect eventually, based on the
 way Microsoft has been going with

0:11:47.220000 --> 0:11:49.740000
 Azure, that they're not even going to
 let this be an option, or at least

0:11:49.740000 --> 0:11:53.960000
 certainly not be something that's going
 to be obvious, or even in the

0:11:53.960000 --> 0:11:57.460000
 portal. So again, maybe some kind of
 obscure switch if you really want

0:11:57.460000 --> 0:12:01.920000
 to turn it off for maybe some weird
 compatibility, you could do that.

0:12:01.920000 --> 0:12:05.680000
 But so the encryption at REST is still
 an option, but you won't see the

0:12:05.680000 --> 0:12:11.200000
 encryption in transit as an option
 anymore for an Azure SQL database.

0:12:11.200000 --> 0:12:12.700000
 So what is the takeaway from this?


0:12:12.700000 --> 0:12:14.200000
 Pretty straightforward.

0:12:14.200000 --> 0:12:18.060000
 First of all, across pretty much anything
 where you're going to be storing

0:12:18.060000 --> 0:12:22.520000
 data. And that, by the way, also includes
 the ability to encrypt managed

0:12:22.520000 --> 0:12:26.560000
 disks for virtual machines that are not
 being stored in a storage account.

0:12:26.560000 --> 0:12:28.780000
 Although that's a little
 bit different.

0:12:28.780000 --> 0:12:31.120000
 You have to kind of go through a little
 bit of a process, not a big deal,

0:12:31.120000 --> 0:12:34.280000
 but you do to encrypt those.

0:12:34.280000 --> 0:12:38.000000
 But pretty much any data that you're
 going to store in Azure is going

0:12:38.000000 --> 0:12:40.820000
 to give you the encryption
 at REST capability.

0:12:40.820000 --> 0:12:45.160000
 And your services are going to give
 you the, at a minimum, they'll give

0:12:45.160000 --> 0:12:48.180000
 you the option for encrypted
 communication.

0:12:48.180000 --> 0:12:49.740000
 Encryption in transit.

0:12:49.740000 --> 0:12:53.360000
 And in many cases, in a growing number
 of cases, it won't even be an option.

0:12:53.360000 --> 0:12:58.920000
 You have to use encrypted communications
 such as with Cosmos DB and now

0:12:58.920000 --> 0:13:00.080000
 with Azure SQL databases.