WEBVTT

0:00:02.380000 --> 0:00:06.640000
 I want to take a couple of minutes and
 talk about storage account security

0:00:06.640000 --> 0:00:12.540000
 in this video. What we're going to do
 is we're going to talk about overall

0:00:12.540000 --> 0:00:14.540000
 storage security.

0:00:14.540000 --> 0:00:19.140000
 We'll look at traditional storage
 account authentication options.

0:00:19.140000 --> 0:00:22.340000
 We'll look at Azure AD
 authentication options.

0:00:22.340000 --> 0:00:25.640000
 Then I want to demonstrate Azure AD
 authentication for storage accounts

0:00:25.640000 --> 0:00:30.260000
 because, honestly, I really think it's
 the way to go if at all possible.

0:00:30.260000 --> 0:00:35.700000
 Clearly, there would be some reasons
 to go alternative to that.

0:00:35.700000 --> 0:00:40.100000
 Let's go ahead and let's start out
 talking about the storage security.

0:00:40.100000 --> 0:00:45.940000
 Now, there's a number of different elements
 of storage that really play

0:00:45.940000 --> 0:00:48.080000
 into the overall security.

0:00:48.080000 --> 0:00:53.060000
 First of all, we've got
 storage encryption.

0:00:53.060000 --> 0:01:01.260000
 You've got the option of encryption
 both for at rest and in transit.

0:01:01.260000 --> 0:01:04.180000
 Now, at rest, it's going
 to be encrypted.

0:01:04.180000 --> 0:01:09.020000
 In transit, we still have the option
 of allowing unencrypted transit.

0:01:09.020000 --> 0:01:12.480000
 In other words, unencrypted HTTP communications,
 but it's generally not

0:01:12.480000 --> 0:01:15.780000
 recommended. We also
 have access control.

0:01:15.780000 --> 0:01:18.760000
 I'm going to talk a bit about that in
 this video, but we also have many

0:01:18.760000 --> 0:01:25.100000
 other videos that go over access
 control within the INE platform.

0:01:25.100000 --> 0:01:26.960000
 Availability and durability.

0:01:26.960000 --> 0:01:29.880000
 Now, this is something you don't necessarily
 always think of when you're

0:01:29.880000 --> 0:01:35.000000
 thinking about the security, but it really
 is making sure you've got that

0:01:35.000000 --> 0:01:40.260000
 data. Now, you have at a minimum
 seven-nines durability.

0:01:40.260000 --> 0:01:45.200000
 In other words, you're probably not going
 to lose your data highly unlikely,

0:01:45.200000 --> 0:01:50.160000
 but you can improve availability by doing
 things like using geo-redundant

0:01:50.160000 --> 0:01:52.900000
 storage. Network access control.

0:01:52.900000 --> 0:01:58.980000
 This is, for me, one of the big ones
 there, being able to now set service

0:01:58.980000 --> 0:02:05.940000
 endpoints and firewall rules to control
 what gets into your storage account.

0:02:05.940000 --> 0:02:09.900000
 We also have cores, cross
-origin, resource sharing.

0:02:09.900000 --> 0:02:17.120000
 It's actually more of a browser capability,
 but it is still something

0:02:17.120000 --> 0:02:20.140000
 that is good to know it's there.

0:02:20.140000 --> 0:02:23.840000
 As I said, these are actually
 all covered in other areas.

0:02:23.840000 --> 0:02:28.100000
 What I wanted to do in other videos, what
 I really wanted to do is I wanted

0:02:28.100000 --> 0:02:32.980000
 to focus on the actual
 authentication.

0:02:32.980000 --> 0:02:37.560000
 How do we get into how do we really handle
 both authentication and authorization

0:02:37.560000 --> 0:02:42.040000
 within storage accounts, because that's
 something that has developed and

0:02:42.040000 --> 0:02:44.660000
 it has evolved, particularly over
 the last couple of years.

0:02:44.660000 --> 0:02:49.660000
 Let's go ahead and
 let's take a look.

0:02:49.660000 --> 0:03:02.620000
 Now, with traditional storage account
 security options, we've got a, let

0:03:02.620000 --> 0:03:04.840000
 me go all the way through this.

0:03:04.840000 --> 0:03:14.460000
 I've got my subscription, I've got a resource
 group, and I've got my storage

0:03:14.460000 --> 0:03:20.060000
 account. I'm just going to be lazy,
 we're just going to put SA for that.

0:03:20.060000 --> 0:03:26.960000
 This is RG, the SUV.

0:03:26.960000 --> 0:03:36.260000
 Now, we know that for resources at the
 control plane level, we have Azure

0:03:36.260000 --> 0:03:47.560000
 Active Directory, and that can get
 us via roles to the resource level.

0:03:47.560000 --> 0:03:53.320000
 We have roles like reader, we have
 roles like owner, contributor, etc.

0:03:53.320000 --> 0:04:00.120000
 But below the resource level, we
 actually have our data plane.

0:04:00.120000 --> 0:04:06.020000
 I'm going to draw this out
 in terms of blob storage.

0:04:06.020000 --> 0:04:10.960000
 So with blob storage,
 we've got a container.

0:04:10.960000 --> 0:04:13.080000
 So we've got our container here.

0:04:13.080000 --> 0:04:21.400000
 Whoa, that is really small.

0:04:21.400000 --> 0:04:26.540000
 I changed my pen, didn't think about
 the fact it would impact the actual

0:04:26.540000 --> 0:04:30.200000
 text as well. All right,
 so we'll draw that out.

0:04:30.200000 --> 0:04:39.020000
 Container. Hey, that's actually
 almost legible.

0:04:39.020000 --> 0:04:46.440000
 All right, and then underneath the container,
 of course, we have a blob.

0:04:46.440000 --> 0:04:51.780000
 Now, the AAD gets us to the storage account,
 but traditionally, and again,

0:04:51.780000 --> 0:04:55.380000
 this is shifting, and it actually
 gets a bit easier.

0:04:55.380000 --> 0:05:03.600000
 Traditionally, there was a hard separation
 between the management plane

0:05:03.600000 --> 0:05:05.660000
 and the data plane.

0:05:05.660000 --> 0:05:12.460000
 In other words, my Azure AD is going
 to get me into the management plane

0:05:12.460000 --> 0:05:15.000000
 and get me to the storage account,
 but that doesn't necessarily get me

0:05:15.000000 --> 0:05:19.880000
 to the data. So then how do we
 go about getting to the data?

0:05:19.880000 --> 0:05:26.440000
 That traditionally
 started with keys.

0:05:26.440000 --> 0:05:31.400000
 If you know storage accounts, you know
 storage accounts have two keys.

0:05:31.400000 --> 0:05:43.120000
 If I've got a user over here,
 that user can get a key.

0:05:43.120000 --> 0:05:45.100000
 It's happy user with a hat.

0:05:45.100000 --> 0:05:50.520000
 That user, if that user has a key, that
 key is going to give full unfettered

0:05:50.520000 --> 0:05:52.300000
 access to everything.

0:05:52.300000 --> 0:05:56.000000
 Right, if I have a storage account and
 a key, I can create what's called

0:05:56.000000 --> 0:06:02.140000
 a context, and this
 is very important.

0:06:02.140000 --> 0:06:06.180000
 Oh, that's supposed to be an X.

0:06:06.180000 --> 0:06:22.260000
 There we go. So we have an alternative,
 which is something called a shared

0:06:22.260000 --> 0:06:27.360000
 access signature, often
 referred to as a SAS.

0:06:27.360000 --> 0:06:39.540000
 Now, a SAS is generated, can be generated
 at the storage account.

0:06:39.540000 --> 0:06:43.880000
 It can also be generated at the container
 account, and it can be generated

0:06:43.880000 --> 0:06:50.400000
 at the individual blob account, or
 again, across the other services as

0:06:50.400000 --> 0:06:53.620000
 well, I just use blob
 as the simple example.

0:06:53.620000 --> 0:06:58.720000
 Now, there's a few advantages of
 using a shared access signature.

0:06:58.720000 --> 0:07:01.580000
 First is obviously
 the granularity.

0:07:01.580000 --> 0:07:06.300000
 So if I want somebody to access a particular
 blob, I don't need to give

0:07:06.300000 --> 0:07:10.120000
 them a key and thus grant
 them access to everything.

0:07:10.120000 --> 0:07:15.500000
 Kind of aligned with that is
 that I've got permissions.

0:07:15.500000 --> 0:07:20.500000
 I'm just going to say perm because
 you don't want to write me out the

0:07:20.500000 --> 0:07:23.200000
 whole, watch me write
 out permissions.

0:07:23.200000 --> 0:07:28.980000
 So with a shared access signature, I
 could give somebody read access only

0:07:28.980000 --> 0:07:35.240000
 to a container, or read and create access
 in a container, but not delete

0:07:35.240000 --> 0:07:43.900000
 access, etc. OK, and I also
 have, write dates down here.

0:07:43.900000 --> 0:07:50.300000
 All right, I can assign dates to a
 shared access signature as well, so

0:07:50.300000 --> 0:07:52.980000
 that it has a validity period.

0:07:52.980000 --> 0:07:59.940000
 And I can also constrain them further
 by using things like IP restrictions,

0:07:59.940000 --> 0:08:05.820000
 and I can also create shared access signature
 space on what's called access

0:08:05.820000 --> 0:08:10.000000
 policy. All of that's actually covered
 in other videos and demonstrated.

0:08:10.000000 --> 0:08:14.460000
 So I'm not going to go really any deeper
 than that into this, but that

0:08:14.460000 --> 0:08:19.640000
 is the traditional model kind of having
 this separation between the control

0:08:19.640000 --> 0:08:24.380000
 plane and the data plan, the management
 plane and the data plane.

0:08:24.380000 --> 0:08:37.020000
 Now, moving beyond that, we've got Azure
 AD authentication now for storage

0:08:37.020000 --> 0:08:42.820000
 accounts. OK, and we have really
 kind of the same configuration.

0:08:42.820000 --> 0:08:51.500000
 I've got AAD. I've got my subscription,
 my resource group, my resource,

0:08:51.500000 --> 0:08:53.800000
 and then the data plane.

0:08:53.800000 --> 0:09:00.640000
 I've got my container and my blob, just
 say, C and B here, because you've

0:09:00.640000 --> 0:09:02.940000
 seen me write enough.

0:09:02.940000 --> 0:09:12.040000
 Right? And so now, if I have a user
 over here, I can assign user roles,

0:09:12.040000 --> 0:09:18.080000
 not only down to the storage
 account level, right?

0:09:18.080000 --> 0:09:28.100000
 Down into the control plane, but I now
 have roles that I can assign granting

0:09:28.100000 --> 0:09:31.480000
 access down to the item level.

0:09:31.480000 --> 0:09:38.320000
 And so they've added really standard
 role-based security into the Azure

0:09:38.320000 --> 0:09:39.620000
 storage account, which
 is fantastic.

0:09:39.620000 --> 0:09:47.480000
 And what this means is that you've got
 a better control, and it also means

0:09:47.480000 --> 0:09:49.580000
 you have unified control, right?

0:09:49.580000 --> 0:09:53.300000
 And that it's, and frankly,
 easier, right?

0:09:53.300000 --> 0:09:57.700000
 I'm going to grant you roles to the
 data plane, really the exact same

0:09:57.700000 --> 0:10:02.040000
 way that I've grant you roles at
 the control or management plane.

0:10:02.040000 --> 0:10:07.580000
 And, you know, I've got that granularity,
 I still have that granularity,

0:10:07.580000 --> 0:10:08.820000
 which is fantastic.

0:10:08.820000 --> 0:10:13.940000
 All right? And what I'd like to do,
 really, is to go ahead and just show

0:10:13.940000 --> 0:10:24.220000
 you this. So what I'm going to do is
 I am going to demonstrate, simply,

0:10:24.220000 --> 0:10:30.240000
 storage authentication, Azure
 AD storage authentication.

0:10:30.240000 --> 0:10:35.340000
 Again, traditional means are still
 valid, and there are videos within

0:10:35.340000 --> 0:10:38.620000
 the I-NE collection that
 you can view to see that.

0:10:38.620000 --> 0:10:43.440000
 But what I thought would be more interesting
 would be to show you the

0:10:43.440000 --> 0:10:46.060000
 process. And it's a fairly
 straightforward process.

0:10:46.060000 --> 0:10:50.360000
 And so without further ado, let's just
 go ahead and jump right into this.

0:10:50.360000 --> 0:10:54.240000
 Now, I already have
 a storage account.

0:10:54.240000 --> 0:11:00.560000
 Okay. And if I look at the access control
 for the storage account, right

0:11:00.560000 --> 0:11:04.220000
 now, if I look at role assignments, they're
 pretty standard role assignments.

0:11:04.220000 --> 0:11:08.420000
 I've got a bunch of processes, background
 processes that have a contributor

0:11:08.420000 --> 0:11:11.000000
 at the subscription level.

0:11:11.000000 --> 0:11:14.640000
 Even if you can't see all these, you
 know, just it's all pretty standard.

0:11:14.640000 --> 0:11:18.240000
 I've got a few owners and I've got
 a user access administrator.

0:11:18.240000 --> 0:11:25.260000
 Okay. Now, if I go to containers, I see
 that I've got two different containers.

0:11:25.260000 --> 0:11:27.840000
 I've got development and
 I've got sensitive.

0:11:27.840000 --> 0:11:33.380000
 Now, what I want to do is I want to
 grant a user access, direct access

0:11:33.380000 --> 0:11:38.380000
 to development. And notice that
 there is a file in here.

0:11:38.380000 --> 0:11:40.340000
 And here I'll actually, whoops.

0:11:40.340000 --> 0:11:42.520000
 Useful if I click the
 right button there.

0:11:42.520000 --> 0:11:46.220000
 There we go. Okay.

0:11:46.220000 --> 0:11:47.880000
 So here I am. I'm in development.

0:11:47.880000 --> 0:11:50.580000
 I've got a single file in here.

0:11:50.580000 --> 0:11:55.580000
 And what I want to do is I'm going to
 give a user access to this container.

0:11:55.580000 --> 0:12:00.640000
 Okay. So to do that, I'm going to go
 to access control for the container.

0:12:00.640000 --> 0:12:04.120000
 And I can view my role assignments and
 I'm going to see exactly the same

0:12:04.120000 --> 0:12:07.220000
 role assignments that I have
 for the storage account.

0:12:07.220000 --> 0:12:12.080000
 But now I am going to
 add a role assignment.

0:12:12.080000 --> 0:12:21.840000
 Now, in particular, I'm going to come
 up here and and down here, I've

0:12:21.840000 --> 0:12:25.660000
 got storage blob data.

0:12:25.660000 --> 0:12:31.420000
 So I've got storage blob data contributor,
 data owner, data reader, data

0:12:31.420000 --> 0:12:35.440000
 delegator. That allows for generation
 of user delegation key, which can

0:12:35.440000 --> 0:12:37.260000
 be used to sign SaaS tokens.

0:12:37.260000 --> 0:12:46.480000
 So I could actually have a token signer
 that was that specific functionality.

0:12:46.480000 --> 0:12:48.940000
 So here are the different roles.

0:12:48.940000 --> 0:12:52.640000
 I'm going to go ahead and
 choose contributor.

0:12:52.640000 --> 0:12:55.460000
 And I've got a user task user.

0:12:55.460000 --> 0:13:04.120000
 And I am going to add that user.

0:13:04.120000 --> 0:13:06.920000
 All right. And so now, somewhere
 around there, there we go.

0:13:06.920000 --> 0:13:07.980000
 Storage blob container.

0:13:07.980000 --> 0:13:09.460000
 There's my task user.

0:13:09.460000 --> 0:13:13.400000
 Okay. At this point, what I'm going to
 do is I am going to log in as task

0:13:13.400000 --> 0:13:16.760000
 user. I'm going to open
 up an in private window.

0:13:16.760000 --> 0:13:19.180000
 And I'm going to first
 go to the portal.

0:13:19.180000 --> 0:13:33.880000
 Okay. And I'm going to go task user
 at marsup.com, fill in the password,

0:13:33.880000 --> 0:13:40.280000
 and sign in. All right.

0:13:40.280000 --> 0:13:42.440000
 All right. Now I know
 it's got some rights.

0:13:42.440000 --> 0:13:45.440000
 She's got some rights within
 storage account.

0:13:45.440000 --> 0:13:47.880000
 And I go to storage accounts.

0:13:47.880000 --> 0:13:51.140000
 Now I've got access to two storage accounts,
 but I don't have access to

0:13:51.140000 --> 0:13:54.740000
 the INE AAD. And I will tell you the
 only reason I have access to these

0:13:54.740000 --> 0:13:58.240000
 storage accounts is for what
 I'm about to do next.

0:13:58.240000 --> 0:14:02.780000
 Okay. What I want to do for this user
 is I actually want to see if I can

0:14:02.780000 --> 0:14:05.880000
 get to that date, even though I don't
 see the storage account itself,

0:14:05.880000 --> 0:14:10.700000
 I should have access to the
 container and its content.

0:14:10.700000 --> 0:14:16.600000
 So what I'm going to do is I'm
 going to open up a shell.

0:14:16.600000 --> 0:14:36.680000
 A cloud shell. It's coming in.

0:14:36.680000 --> 0:14:43.960000
 Now, while that's coming in, because I
 have no memory of pretty much anything

0:14:43.960000 --> 0:14:47.540000
 ever. But I want to do.

0:14:47.540000 --> 0:14:55.300000
 Go here and pull this up out of the way,
 because otherwise I will completely

0:14:55.300000 --> 0:15:02.300000
 forget the name of the storage account
 and the name of the resource group

0:15:02.300000 --> 0:15:07.520000
 it's in. Okay. Now, what I want to
 do is kind of a standard process.

0:15:07.520000 --> 0:15:09.380000
 I'm going to create a context.

0:15:09.380000 --> 0:15:11.140000
 Right. I talked about context.

0:15:11.140000 --> 0:15:24.120000
 So, dot sign context equals
 new az storage context.

0:15:24.120000 --> 0:15:33.760000
 And the storage account name.

0:15:33.760000 --> 0:15:37.960000
 Is going to be I and E A D.

0:15:37.960000 --> 0:15:45.520000
 And resource group name.

0:15:45.520000 --> 0:15:46.840000
 Oh, that's right.

0:15:46.840000 --> 0:15:48.680000
 20, the resource.

0:15:48.680000 --> 0:15:50.940000
 I guess I don't need the
 resource group name.

0:15:50.940000 --> 0:16:00.340000
 Okay. The other thing I need to do,
 however, is use connected account.

0:16:00.340000 --> 0:16:01.620000
 Okay. All right.

0:16:01.620000 --> 0:16:03.160000
 So now I have a context.

0:16:03.160000 --> 0:16:05.460000
 All right. And if I want to go.

0:16:05.460000 --> 0:16:10.760000
 Okay. So cool. We've
 got this context.

0:16:10.760000 --> 0:16:20.360000
 Now what I want to do is I want
 to get az storage blob.

0:16:20.360000 --> 0:16:22.540000
 That's right. Yes.

0:16:22.540000 --> 0:16:27.460000
 Okay. And I want the context.

0:16:27.460000 --> 0:16:32.560000
 I've gotten that wrong.

0:16:32.560000 --> 0:16:35.120000
 Yeah, az storage blob.

0:16:35.120000 --> 0:16:43.180000
 I want the context
 to be my context.

0:16:43.180000 --> 0:16:52.740000
 And I want the container
 to be development.

0:16:52.740000 --> 0:16:57.260000
 Okay. Again, let me off screen checking
 to make sure that is the name

0:16:57.260000 --> 0:17:00.020000
 of this. Very sad how
 bad my memory is.

0:17:00.020000 --> 0:17:05.540000
 All right. And this is going to
 be a little anti climactic.

0:17:05.540000 --> 0:17:08.640000
 Okay. So cool. What
 does that tell you?

0:17:08.640000 --> 0:17:12.600000
 Well, notice that I now have.

0:17:12.600000 --> 0:17:16.880000
 This reference right here.

0:17:16.880000 --> 0:17:19.980000
 Okay. I have my context.

0:17:19.980000 --> 0:17:23.480000
 And what my context is doing, and by
 the way, that's a context that's

0:17:23.480000 --> 0:17:25.260000
 based on the login, right?

0:17:25.260000 --> 0:17:26.460000
 I didn't use a key.

0:17:26.460000 --> 0:17:31.680000
 I have no access to the key, but I
 now do have access to in this case

0:17:31.680000 --> 0:17:36.580000
 the content that is underneath of the
 container that I was granted a role

0:17:36.580000 --> 0:17:41.340000
 on. And you know, for me, that's
 that's kind of a huge deal.

0:17:41.340000 --> 0:17:46.460000
 Right. Because now what we're looking
 at is this ability to really have

0:17:46.460000 --> 0:17:52.780000
 a completely rationalized approach to
 granting access to controlling access

0:17:52.780000 --> 0:17:54.620000
 to our storage account.

0:17:54.620000 --> 0:17:58.280000
 So we looked at kind of the big picture
 things in terms of, you know,

0:17:58.280000 --> 0:18:02.260000
 what are the various aspects of security
 architecture that are available.

0:18:02.260000 --> 0:18:03.680000
 Most of them are available.

0:18:03.680000 --> 0:18:09.280000
 Really everything I didn't cover right
 here is available in other videos.

0:18:09.280000 --> 0:18:11.740000
 Feel free and please
 do watch those.

0:18:11.740000 --> 0:18:15.660000
 But I wanted to give that kind of overarching
 approach and then also demonstrate

0:18:15.660000 --> 0:18:17.620000
 something I think is
 critically important.