WEBVTT

0:00:02.200000 --> 0:00:06.240000
 When you talk about data security, frankly,
 whether it's an Azure or anywhere

0:00:06.240000 --> 0:00:09.780000
 else, that is an absolutely
 massive topic.

0:00:09.780000 --> 0:00:13.200000
 We are not going to cover that
 entire topic in this video.

0:00:13.200000 --> 0:00:18.080000
 INE has many videos on security and
 specifically various data security

0:00:18.080000 --> 0:00:19.620000
 elements in Azure.

0:00:19.620000 --> 0:00:22.460000
 What we're going to do in this video
 is we're going to concentrate on

0:00:22.460000 --> 0:00:25.760000
 three aspects of data security.

0:00:25.760000 --> 0:00:30.100000
 We're going to talk about data classification
 within the Azure environment,

0:00:30.100000 --> 0:00:31.540000
 demonstrate that.

0:00:31.540000 --> 0:00:36.400000
 We're going to talk about long-term
 data retention, demonstrate that,

0:00:36.400000 --> 0:00:38.720000
 and then we're going to talk about data
 sovereignty and just a few things

0:00:38.720000 --> 0:00:41.780000
 that you should know there are some terminology
 and just some basics that

0:00:41.780000 --> 0:00:44.500000
 hopefully will be relatively
 straightforward.

0:00:44.500000 --> 0:00:48.240000
 So let's go ahead and
 let's dive into this.

0:00:48.240000 --> 0:00:52.080000
 We're going to start out by talking
 about data classification.

0:00:52.080000 --> 0:00:57.680000
 When we talk about data classification,
 we're talking about looking at

0:00:57.680000 --> 0:01:02.120000
 data risk. What is the impact
 of a data breach?

0:01:02.120000 --> 0:01:05.480000
 If somebody gets to something,
 what is the problem?

0:01:05.480000 --> 0:01:11.840000
 And the key elements that define the
 data risk, the type of data, the

0:01:11.840000 --> 0:01:16.800000
 business criticality of the data, and
 your financial responsibility, and

0:01:16.800000 --> 0:01:21.720000
 part of that financial responsibility, be
 things such as regulatory compliance.

0:01:21.720000 --> 0:01:26.020000
 Because if you are subject to regulatory
 compliance and your data falls

0:01:26.020000 --> 0:01:31.060000
 outside of that or if there is a breach,
 then beyond whatever the direct

0:01:31.060000 --> 0:01:35.260000
 impact to your business is, you
 may also have regulatory fines.

0:01:35.260000 --> 0:01:41.720000
 Now Microsoft, not surprisingly, takes this
 data classification very seriously.

0:01:41.720000 --> 0:01:45.480000
 And in fact, internally you see that Microsoft
 actually uses five different

0:01:45.480000 --> 0:01:50.800000
 levels of classification for every
 bit of data that they have.

0:01:50.800000 --> 0:01:54.920000
 And this is just an example of how
 you might classify your data.

0:01:54.920000 --> 0:01:58.900000
 So you have non-business data that is
 things that are held, but they really

0:01:58.900000 --> 0:02:00.920000
 don't have anything to
 do with Microsoft.

0:02:00.920000 --> 0:02:04.720000
 Public, these are things that involve
 Microsoft, and again, that's just

0:02:04.720000 --> 0:02:07.560000
 a proxy for involve
 your organization.

0:02:07.560000 --> 0:02:12.980000
 And they relate to the organization
 itself, but they're public access.

0:02:12.980000 --> 0:02:17.460000
 And then you've got general, that would
 be things that are not for public

0:02:17.460000 --> 0:02:20.940000
 access, but are generally available
 within the organization.

0:02:20.940000 --> 0:02:23.040000
 And you have confidential
 and highly confidential.

0:02:23.040000 --> 0:02:27.600000
 Now, there are meanings associated with
 this for Microsoft, and you can

0:02:27.600000 --> 0:02:29.300000
 go and look at that, but that's
 their internal meanings.

0:02:29.300000 --> 0:02:31.140000
 I don't think it's that critical.

0:02:31.140000 --> 0:02:34.360000
 What is important is that you think
 about the classification for your

0:02:34.360000 --> 0:02:36.220000
 organization, all right?

0:02:36.220000 --> 0:02:41.520000
 And how do you actually enforce classification
 when you think about Azure?

0:02:41.520000 --> 0:02:49.180000
 Well, Azure has this really great metadata
 system called tags, and tags

0:02:49.180000 --> 0:02:53.240000
 allow you to add whatever metadata
 you want, including classification.

0:02:53.240000 --> 0:03:00.960000
 Now, I will tell you with the exception
 of SQL Server, there's not anything

0:03:00.960000 --> 0:03:05.440000
 right now that actively does anything
 with these tags, but it's a way

0:03:05.440000 --> 0:03:10.620000
 for you to monitor and audit and really
 just classify your resources,

0:03:10.620000 --> 0:03:16.980000
 right? So, if for example, I have a storage
 account that contains thousands

0:03:16.980000 --> 0:03:20.680000
 of images for my website, okay?

0:03:20.680000 --> 0:03:24.480000
 Somebody getting access to that, read
 access to that, probably not going

0:03:24.480000 --> 0:03:26.260000
 to be that critical, right?

0:03:26.260000 --> 0:03:31.300000
 But if I have a storage account that
 holds our financial documents, and

0:03:31.300000 --> 0:03:35.220000
 it holds our business strategy for the
 coming two years, that's probably

0:03:35.220000 --> 0:03:39.460000
 something that's going to be, you know,
 needs to be maintained with higher

0:03:39.460000 --> 0:03:42.260000
 standards. It should always use the
 highest standards possible, but, you

0:03:42.260000 --> 0:03:45.560000
 know, there's highest and
 there's higher than that.

0:03:45.560000 --> 0:03:48.380000
 In any case, that's kind of what
 you want to think about.

0:03:48.380000 --> 0:03:52.580000
 And there are guidelines available if
 you go to Microsoft Cloud Adoption

0:03:52.580000 --> 0:03:56.140000
 Framework. You can just look up Microsoft
 Cloud Adoption Framework on

0:03:56.140000 --> 0:03:59.200000
 your favorite search engine, and they've
 got guidance for different ways

0:03:59.200000 --> 0:04:01.580000
 of classifying your data.

0:04:01.580000 --> 0:04:05.280000
 Now, what I'm going to do is I'm going
 to go ahead and demonstrate, and

0:04:05.280000 --> 0:04:08.060000
 there's two things that
 I want to demonstrate.

0:04:08.060000 --> 0:04:12.260000
 I'm going to demonstrate tagging policy
 and show you how you could set

0:04:12.260000 --> 0:04:15.180000
 up generic tagging policy, but I also
 have a custom policy associated

0:04:15.180000 --> 0:04:17.820000
 with tagging, and I'm
 going to set that up.

0:04:17.820000 --> 0:04:22.480000
 And then I also want to show you how
 SQL Server can actually integrate

0:04:22.480000 --> 0:04:25.660000
 tagging as well, and what you
 get out of that, all right?

0:04:25.660000 --> 0:04:29.880000
 So let's go ahead and
 let's jump into this.

0:04:29.880000 --> 0:04:38.340000
 I am in Azure, and what I'm going to
 do is I am going to go to policies.

0:04:38.340000 --> 0:04:41.620000
 So we just want to go
 straight to policies.

0:04:41.620000 --> 0:04:50.520000
 And let's say that I have a resource
 group, or a subscription, that I

0:04:50.520000 --> 0:04:54.280000
 want to make sure that tags
 are properly applied.

0:04:54.280000 --> 0:04:59.060000
 Well, I could go, and I could set up
 an assignment, and there actually

0:04:59.060000 --> 0:05:03.920000
 is a policy, I can go and assign a
 policy, and I could set a scope for

0:05:03.920000 --> 0:05:13.360000
 that policy. And just so I don't forget
 what I'm doing, I'm going to go

0:05:13.360000 --> 0:05:16.580000
 ahead and set it up
 in a resource group.

0:05:16.580000 --> 0:05:24.600000
 And I can go to my policy definition,
 and I want to build 10 policies

0:05:24.600000 --> 0:05:31.500000
 right now, tag. Okay, so I can require
 a tag and its value on resources.

0:05:31.500000 --> 0:05:40.720000
 Okay, cool. I can also add a tag to
 resource groups, require a tag on

0:05:40.720000 --> 0:05:43.620000
 resources. That's actually
 what I want.

0:05:43.620000 --> 0:05:48.560000
 Okay, great. Next, parameters,
 what is the name of the tag?

0:05:48.560000 --> 0:05:52.060000
 Now, I could, with this, for example,
 go and say, you know what I want,

0:05:52.060000 --> 0:05:56.340000
 I want classification.

0:05:56.340000 --> 0:06:00.540000
 And that's it. And I could set that policy
 and assign that policy so that

0:06:00.540000 --> 0:06:04.900000
 every new resource would need
 the classification tag.

0:06:04.900000 --> 0:06:07.640000
 However, that's not actually
 what I want to do.

0:06:07.640000 --> 0:06:15.340000
 Because not only do I want the tag to
 be classification, or I do I want

0:06:15.340000 --> 0:06:25.660000
 a classification tag, but I actually
 want to specify what those possible

0:06:25.660000 --> 0:06:28.960000
 values are. And it's not classification
 sensitivity.

0:06:28.960000 --> 0:06:33.280000
 Now, I have already created
 a custom policy.

0:06:33.280000 --> 0:06:35.620000
 So here I have a custom policy.

0:06:35.620000 --> 0:06:37.800000
 And what it's doing
 is a couple things.

0:06:37.800000 --> 0:06:43.440000
 It's looking, first of all, to make sure
 that the sensitivity tag exists.

0:06:43.440000 --> 0:06:48.340000
 And then it's making sure that the
 sensitivity tag has a value that is

0:06:48.340000 --> 0:06:52.280000
 either public, general, confidential,
 or highly confidential.

0:06:52.280000 --> 0:06:56.180000
 And if that's not the case,
 it's going to deny it.

0:06:56.180000 --> 0:06:58.240000
 Okay, so that is the definition.

0:06:58.240000 --> 0:07:01.620000
 Now, what I want to do
 is assign that policy.

0:07:01.620000 --> 0:07:14.200000
 I should go through
 the same scope.

0:07:14.200000 --> 0:07:17.060000
 Policy definition.

0:07:17.060000 --> 0:07:25.480000
 Sensitivity tag.

0:07:25.480000 --> 0:07:28.940000
 Some really terrible
 description there.

0:07:28.940000 --> 0:07:31.340000
 Okay, policy enforcement
 assignment.

0:07:31.340000 --> 0:07:33.620000
 I should give it a description,
 but I'm not.

0:07:33.620000 --> 0:07:36.700000
 The policy itself does not
 have any parameters.

0:07:36.700000 --> 0:07:39.680000
 There is no remediation for it.

0:07:39.680000 --> 0:07:43.680000
 So I'm going to go ahead and
 create the assignment.

0:07:43.680000 --> 0:07:50.540000
 All right, so I now have made an assignment
 to that resource group.

0:07:50.540000 --> 0:07:58.880000
 So let's go to, oh,
 it doesn't see it.

0:07:58.880000 --> 0:08:02.280000
 Demo tags. There we go.

0:08:02.280000 --> 0:08:05.520000
 Okay, so now I want to try
 and create a resource.

0:08:05.520000 --> 0:08:10.440000
 Easy enough. Let's create the handy dandy
 route table because that creates

0:08:10.440000 --> 0:08:14.280000
 pretty quickly. I'm going
 to create that.

0:08:14.280000 --> 0:08:17.860000
 Awesome. In fact, we'll
 call it awesome.

0:08:17.860000 --> 0:08:24.720000
 Fantastic. Create.

0:08:24.720000 --> 0:08:26.240000
 And it's deploying.

0:08:26.240000 --> 0:08:29.740000
 Everything is great.

0:08:29.740000 --> 0:08:35.380000
 And it failed. And it failed because,
 look over here, it's going to tell

0:08:35.380000 --> 0:08:38.280000
 me that it failed because of
 the policy sensitivity tag.

0:08:38.280000 --> 0:08:41.080000
 Okay, that's pretty much
 what I would expect.

0:08:41.080000 --> 0:08:47.140000
 So now, let's go ahead and
 create a virtual network.

0:08:47.140000 --> 0:08:50.660000
 It doesn't take too
 long to create.

0:08:50.660000 --> 0:08:52.880000
 Look at my virtual network.

0:08:52.880000 --> 0:08:55.520000
 Create my virtual network.

0:08:55.520000 --> 0:08:59.480000
 I'm going to put it
 in my demo tags.

0:08:59.480000 --> 0:09:03.800000
 Give this a name of awesome vnet.

0:09:03.800000 --> 0:09:08.260000
 Put it in West US too
 because why not?

0:09:08.260000 --> 0:09:10.020000
 Find there, find there.

0:09:10.020000 --> 0:09:11.660000
 And we'll come over here.

0:09:11.660000 --> 0:09:20.520000
 Let's go to a value of test.

0:09:20.520000 --> 0:09:26.860000
 Okay. Go to review and create.

0:09:26.860000 --> 0:09:31.420000
 It tells me it validated.

0:09:31.420000 --> 0:09:35.460000
 I'm going to go ahead and create
 and let's see what happens.

0:09:35.460000 --> 0:09:40.140000
 And right away, it's telling
 me that it actually failed.

0:09:40.140000 --> 0:09:42.140000
 It's so many it failed
 for the same reason.

0:09:42.140000 --> 0:09:44.600000
 Policy definition sensitivity tag.


0:09:44.600000 --> 0:09:47.180000
 Let's try it one more time.

0:09:47.180000 --> 0:09:49.460000
 Again, with a virtual network.

0:09:49.460000 --> 0:10:04.520000
 This time it will succeed, hopefully,
 or I'm just going to look very silly.

0:10:04.520000 --> 0:10:08.840000
 Go with the standard IHTW
 for I hope this works.

0:10:08.840000 --> 0:10:12.840000
 Let's get right over to tags.

0:10:12.840000 --> 0:10:20.060000
 The sensitivity tag and give
 it a value of public.

0:10:20.060000 --> 0:10:25.880000
 I mean, that's kind of a weird thing
 to add to a virtual network, but

0:10:25.880000 --> 0:10:31.500000
 here we go. It would be more important
 for things like databases and virtual

0:10:31.500000 --> 0:10:34.420000
 machines, but I mean, the reality is
 I could say, look, anything that's

0:10:34.420000 --> 0:10:37.180000
 on this virtual network
 better be public.

0:10:37.180000 --> 0:10:37.880000
 And there we go.

0:10:37.880000 --> 0:10:39.880000
 It deployed. Okay.

0:10:39.880000 --> 0:10:44.060000
 So that is how we can use tagging policy
 to control and enforce tagging

0:10:44.060000 --> 0:10:45.700000
 on our resources.

0:10:45.700000 --> 0:10:48.380000
 Next thing I want to show you is
 actually, I think, pretty cool.

0:10:48.380000 --> 0:10:50.480000
 I'm going to go to
 my SQL databases.

0:10:50.480000 --> 0:10:58.900000
 And I've got this database I just
 created literally for this video.

0:10:58.900000 --> 0:11:02.500000
 And what I want to do is I actually want
 to create some data classification

0:11:02.500000 --> 0:11:04.120000
 within this database.

0:11:04.120000 --> 0:11:08.380000
 Now, this database is created based
 off the sample database, which is

0:11:08.380000 --> 0:11:11.640000
 a adventure works light.

0:11:11.640000 --> 0:11:14.440000
 It's just got some data,
 it's got some columns.

0:11:14.440000 --> 0:11:16.580000
 What it has doesn't really matter.


0:11:16.580000 --> 0:11:21.500000
 But what it does here and what my advanced
 threat detection advanced security

0:11:21.500000 --> 0:11:23.360000
 does is very cool.

0:11:23.360000 --> 0:11:29.220000
 Now, I've got advanced data security
 set up on the server that this was

0:11:29.220000 --> 0:11:35.120000
 deployed to. And if I go to advanced data
 security, I've got data discovery

0:11:35.120000 --> 0:11:40.060000
 and classification, advanced threat
 protection vulnerability assessment.

0:11:40.060000 --> 0:11:43.220000
 Go to data discovery
 and classification.

0:11:43.220000 --> 0:11:48.860000
 Okay. What it's going to do, it's going
 to say, okay, right now you do

0:11:48.860000 --> 0:11:51.620000
 not have any classified columns.

0:11:51.620000 --> 0:11:52.760000
 And you don't have any tables.

0:11:52.760000 --> 0:11:58.740000
 We found 109 columns, we beam Azure
 that are across 12 tables.

0:11:58.740000 --> 0:12:02.500000
 Okay. Now I could go and I could add
 my own classifications if I wanted

0:12:02.500000 --> 0:12:03.560000
 to. And I'll show you
 that in a minute.

0:12:03.560000 --> 0:12:08.640000
 But if I look up here, it actually analyzes
 the data and it found 15 columns

0:12:08.640000 --> 0:12:11.060000
 with classified classifications
 recommendations.

0:12:11.060000 --> 0:12:14.560000
 And I'll show you the different classifications,
 but here are all of the

0:12:14.560000 --> 0:12:19.080000
 different columns that it found a couple
 that were confidential GDPR,

0:12:19.080000 --> 0:12:22.980000
 couple that were just generic
 confidential several.

0:12:22.980000 --> 0:12:25.120000
 And some of us say,
 okay, that's great.

0:12:25.120000 --> 0:12:30.120000
 I'm going to go ahead and accept
 these selected recommendations.

0:12:30.120000 --> 0:12:33.580000
 There we go. Now I've got
 these recommendations.

0:12:33.580000 --> 0:12:37.840000
 Cool. Okay. And with the recommendation,
 I've got an information type

0:12:37.840000 --> 0:12:41.200000
 and a sensitivity level.

0:12:41.200000 --> 0:12:45.160000
 Notice the sensitivity levels in a public
 general confidential confidential

0:12:45.160000 --> 0:12:51.640000
 GDPR, highly confidential and highly
 confidential GDPR information types,

0:12:51.640000 --> 0:12:54.360000
 a number of different
 information types.

0:12:54.360000 --> 0:13:01.820000
 Okay. Now if I've got a column I know
 should be classified and it's not

0:13:01.820000 --> 0:13:06.860000
 classified that way, I can actually
 go ahead and pick that column up.

0:13:06.860000 --> 0:13:11.500000
 So let's say product and I don't know
 if list prices, I should have looked

0:13:11.500000 --> 0:13:13.000000
 to see if list price was in there.


0:13:13.000000 --> 0:13:20.820000
 It probably is. Say size, information
 type, other sensitivity is highly

0:13:20.820000 --> 0:13:24.160000
 confidential. All right.

0:13:24.160000 --> 0:13:28.140000
 That would be a really dumb sensitivity,
 but that's okay.

0:13:28.140000 --> 0:13:33.740000
 All right. And there we go.

0:13:33.740000 --> 0:13:40.320000
 The resources at a general level using
 tagging as well as your classification

0:13:40.320000 --> 0:13:43.240000
 within Azure SQL database.

0:13:43.240000 --> 0:13:46.180000
 So it's just a little bit
 of extra capability.

0:13:46.180000 --> 0:13:50.600000
 Now what I want to do is I want
 to talk about data retention.

0:13:50.600000 --> 0:13:57.140000
 And really one of the keys to data retention
 is long-term data retention.

0:13:57.140000 --> 0:14:02.780000
 Okay. And SQL Server has, Azure SQL database
 has long-term data retention

0:14:02.780000 --> 0:14:04.260000
 that you can set up.

0:14:04.260000 --> 0:14:07.700000
 In fact, you can set it up
 up to a matter of years.

0:14:07.700000 --> 0:14:11.000000
 And the list I'm about to show you
 goes to, we've got SQL Server here

0:14:11.000000 --> 0:14:15.800000
 and it's important to know it does
 have long-term data retention.

0:14:15.800000 --> 0:14:20.140000
 Now Cosmos DB, surprisingly, not so
 much surprisingly if you understand

0:14:20.140000 --> 0:14:21.860000
 what Cosmos DB is designed for.

0:14:21.860000 --> 0:14:27.620000
 It's a highly transactional scaled
 out data system, non-relational.

0:14:27.620000 --> 0:14:32.540000
 And it is actually backed up every four
 hours and two backups are retained.

0:14:32.540000 --> 0:14:38.600000
 So the longest term retention you
 have for Cosmos DB is eight hours.

0:14:38.600000 --> 0:14:49.960000
 MySQL and Postgres SQL, both of those
 can be retained up to 35 days.

0:14:49.960000 --> 0:14:54.780000
 With the Azure site recovery, backup
 and site recovery or site recovery

0:14:54.780000 --> 0:15:01.420000
 vault, you set up backup policy which
 can retain backups of data for up

0:15:01.420000 --> 0:15:04.840000
 to several years.

0:15:04.840000 --> 0:15:09.220000
 And the last item, not quite the last
 item, the next to the last item

0:15:09.220000 --> 0:15:13.200000
 that has backup settings
 is log analytics.

0:15:13.200000 --> 0:15:18.100000
 Log analytics will allow you to
 save data for up to two years.

0:15:18.100000 --> 0:15:23.380000
 So if you are auditing or if you're
 just logging diagnostic data and you

0:15:23.380000 --> 0:15:28.800000
 need to keep it for a log time, make sure
 that you are sending that diagnostic

0:15:28.800000 --> 0:15:33.100000
 data, that audit data
 to log analytics.

0:15:33.100000 --> 0:15:37.380000
 And this isn't exactly data retention
 per se, but it is something to keep

0:15:37.380000 --> 0:15:47.120000
 in mind. The blob storage
 archive tier.

0:15:47.120000 --> 0:15:50.800000
 And what that does is that takes whatever
 data you mark and you can do

0:15:50.800000 --> 0:15:56.240000
 this actually on a file by file basis,
 you mark it as archive and its

0:15:56.240000 --> 0:16:00.160000
 cost goes significantly down.

0:16:00.160000 --> 0:16:02.040000
 But it's not always available.

0:16:02.040000 --> 0:16:03.800000
 It's actually taken offline.

0:16:03.800000 --> 0:16:06.440000
 And if you need to get it, you
 need to put in a request.

0:16:06.440000 --> 0:16:08.720000
 And the last time I checked, I have no
 reason to believe this has changed,

0:16:08.720000 --> 0:16:09.840000
 but you never know.

0:16:09.840000 --> 0:16:15.060000
 It was 16 hours was the
 SLA on the turnaround.

0:16:15.060000 --> 0:16:19.660000
 So if I have something in storage, if
 I've archived it and I need to get

0:16:19.660000 --> 0:16:22.140000
 it back, understand it's not
 going to be immediate.

0:16:22.140000 --> 0:16:26.320000
 But that's I think an important aspect
 and important capability when it

0:16:26.320000 --> 0:16:31.580000
 comes to long-term data retention because
 that can significantly impact

0:16:31.580000 --> 0:16:34.680000
 the cost factor of saving
 things for a long time.

0:16:34.680000 --> 0:16:40.020000
 This is very cheap to store things
 with the archived here.

0:16:40.020000 --> 0:16:43.980000
 Okay, that being said, let's take
 a look at data retention.

0:16:43.980000 --> 0:16:48.160000
 And I'm really just going to go through
 two examples for data retention.

0:16:48.160000 --> 0:16:54.160000
 We're going to take a look at our backup
 data retention, look at a backup

0:16:54.160000 --> 0:16:56.400000
 policy and how we can set
 retention for that.

0:16:56.400000 --> 0:17:00.740000
 And I'm going to take a look at
 SQL long-term data retention.

0:17:00.740000 --> 0:17:03.760000
 So let's go ahead
 and pull that up.

0:17:03.760000 --> 0:17:08.700000
 Now I'm still in my previous
 demo, but that's okay.

0:17:08.700000 --> 0:17:10.060000
 It's the same slide.

0:17:10.060000 --> 0:17:17.420000
 And what I'm going to do is let's go
 to, I remember where I put this,

0:17:17.420000 --> 0:17:20.980000
 demo LTR. What do you know?

0:17:20.980000 --> 0:17:22.740000
 It was very good of me.

0:17:22.740000 --> 0:17:26.820000
 All right, here I've got a
 recovery services fault.

0:17:26.820000 --> 0:17:30.020000
 So this is going to be for
 my backup and restore.

0:17:30.020000 --> 0:17:33.340000
 And what I want to do is I'm going
 to come down here very directly and

0:17:33.340000 --> 0:17:34.240000
 set backup policies.

0:17:34.240000 --> 0:17:36.800000
 Now I'm not actually going to back
 anything up, but I want to show you

0:17:36.800000 --> 0:17:38.340000
 what the options are.

0:17:38.340000 --> 0:17:43.780000
 And this can be applied to, in this
 case, Azure virtual machines.

0:17:43.780000 --> 0:17:51.080000
 So I'm going to create a policy and
 the policy name is going to be demo,

0:17:51.080000 --> 0:17:53.000000
 not surprisingly.

0:17:53.000000 --> 0:17:55.080000
 Now, first of all, I set
 the backup schedule.

0:17:55.080000 --> 0:17:56.840000
 Okay, daily or weekly.

0:17:56.840000 --> 0:18:00.880000
 All right, now instant recovery
 snapshots to that's fine.

0:18:00.880000 --> 0:18:03.540000
 Daily and it's just going
 down through here.

0:18:03.540000 --> 0:18:07.840000
 So I'm taking and holding daily
 snapshots for 180 days.

0:18:07.840000 --> 0:18:10.260000
 I can also have weekly backups.

0:18:10.260000 --> 0:18:13.780000
 And let's say for weekly, I want to
 store 52 weekly backups of whatever

0:18:13.780000 --> 0:18:16.500000
 it is that it will apply
 this policy to.

0:18:16.500000 --> 0:18:19.260000
 And then I've got retention
 and monthly backup.

0:18:19.260000 --> 0:18:22.060000
 I'm going to store 60 months.

0:18:22.060000 --> 0:18:24.060000
 So it's five years.

0:18:24.060000 --> 0:18:27.780000
 And then yearly backup, I'm going
 to store 10 years of yearly.

0:18:27.780000 --> 0:18:29.760000
 Now looking at this past
 the daily, right?

0:18:29.760000 --> 0:18:32.300000
 So if I'm going to do weekly,
 which one do I want to say?

0:18:32.300000 --> 0:18:36.320000
 If I'm going to say every week, I'm
 going to store the Sunday backup for

0:18:36.320000 --> 0:18:41.340000
 every week. And then if I'm doing monthly,
 I can either do that based

0:18:41.340000 --> 0:18:43.880000
 on week or day, but since already doing
 the week, I'm going to say, look,

0:18:43.880000 --> 0:18:48.420000
 I'm going to take the first Sunday of
 every month and keep those for 60.

0:18:48.420000 --> 0:18:51.540000
 And then for annual, I'm going to take,
 again, week based, I'm going to

0:18:51.540000 --> 0:18:57.100000
 take the first Sunday of January
 and store that for 10 years.

0:18:57.100000 --> 0:19:01.840000
 All right. And then we
 go ahead and create.

0:19:01.840000 --> 0:19:10.660000
 That's it. That gives me a backup policy
 for back-end virtual machines.

0:19:10.660000 --> 0:19:13.500000
 So at this point, if I wanted to backup
 a virtual machine, I go to the

0:19:13.500000 --> 0:19:17.220000
 virtual machine, I set backup, and I
 assign this policy, and then I would

0:19:17.220000 --> 0:19:19.840000
 have that long-term retention.

0:19:19.840000 --> 0:19:24.040000
 Now if I go to my SQL server, and this
 is kind of interesting because

0:19:24.040000 --> 0:19:27.960000
 it applies to the database, but
 you set it at the server.

0:19:27.960000 --> 0:19:33.420000
 If I go to my server, under the server,
 I've got managed backups.

0:19:33.420000 --> 0:19:35.860000
 This is, again, for SQL Server.

0:19:35.860000 --> 0:19:41.700000
 Okay. And then here I've got
 the two different databases.

0:19:41.700000 --> 0:19:45.220000
 And when I'm doing this, okay, I want
 to select classify, and I want to

0:19:45.220000 --> 0:19:48.240000
 go ahead and configure retention.

0:19:48.240000 --> 0:19:51.380000
 And this will probably
 look pretty familiar.

0:19:51.380000 --> 0:19:55.200000
 Now one thing I've got is how long do
 I want to keep point in time recovery?

0:19:55.200000 --> 0:19:58.400000
 I can keep that up to 35 days.

0:19:58.400000 --> 0:20:04.760000
 Okay. Then I've got the ability to go to
 long-term weekly, long-term monthly,

0:20:04.760000 --> 0:20:09.600000
 long-term yearly.

0:20:09.600000 --> 0:20:14.340000
 And of course, how long would
 you like your weekly backups?

0:20:14.340000 --> 0:20:23.480000
 We'll say 52 weeks, monthly backups,
 set that to months, and first backup

0:20:23.480000 --> 0:20:27.160000
 of each month. And it doesn't give
 me as many options, which is fine.

0:20:27.160000 --> 0:20:30.920000
 So the weekly backup, first backup of
 the week, first backup of the month,

0:20:30.920000 --> 0:20:33.360000
 I want for 60 months.

0:20:33.360000 --> 0:20:37.380000
 And then yearly, what week, first week
 of the year, I'm going to store

0:20:37.380000 --> 0:20:38.320000
 that for 10 years.

0:20:38.320000 --> 0:20:46.320000
 Now one thing to keep in mind, of course,
 is the longer that you set up

0:20:46.320000 --> 0:20:49.820000
 your backup, you are going to
 be paying for that, right?

0:20:49.820000 --> 0:20:51.960000
 Because you're going to be paying for
 the storage that's used, in this

0:20:51.960000 --> 0:20:54.900000
 case, by your SQL backups.

0:20:54.900000 --> 0:20:59.080000
 All right. That is long
-term retention.

0:20:59.080000 --> 0:21:01.660000
 All right. And those were just two examples
 of long-term retention, but

0:21:01.660000 --> 0:21:06.060000
 they are indicative of the options that
 you have for long-term retention.

0:21:06.060000 --> 0:21:10.580000
 You can see a very consistent set of
 options for those resources that,

0:21:10.580000 --> 0:21:12.780000
 in fact, give you long
-term retention.

0:21:12.780000 --> 0:21:17.120000
 Last topic that I want to talk
 about is data sovereignty.

0:21:17.120000 --> 0:21:18.540000
 This obviously is very important.

0:21:18.540000 --> 0:21:22.480000
 You want to make sure that your data
 stays in your region, particularly

0:21:22.480000 --> 0:21:28.160000
 anything that is really
 specific and critical.

0:21:28.160000 --> 0:21:29.460000
 So a couple of things.

0:21:29.460000 --> 0:21:33.140000
 First of all, we have
 sovereign clouds.

0:21:33.140000 --> 0:21:40.580000
 When most people think about Azure, you
 think about the Azure public cloud,

0:21:40.580000 --> 0:21:42.920000
 right? What I work in is
 the Azure public cloud.

0:21:42.920000 --> 0:21:47.380000
 However, there are several
 sovereign clouds.

0:21:47.380000 --> 0:21:50.860000
 And off the top of my head, in addition
 to the Azure public cloud, there

0:21:50.860000 --> 0:21:55.800000
 is the Azure China cloud, there is the
 Azure Germany cloud, there is the

0:21:55.800000 --> 0:22:00.980000
 Azure US government and the Azure
 US government DoD clouds.

0:22:00.980000 --> 0:22:04.520000
 So each one of those are completely
 separate and sovereign.

0:22:04.520000 --> 0:22:13.520000
 So if I have a subscription in the
 Azure US government cloud, I can't

0:22:13.520000 --> 0:22:16.820000
 go and interact with
 that directly.

0:22:16.820000 --> 0:22:20.960000
 I can't move a resource from that subscription
 to a subscription that's

0:22:20.960000 --> 0:22:21.760000
 in the public cloud.

0:22:21.760000 --> 0:22:23.500000
 So they're completely separate.

0:22:23.500000 --> 0:22:27.640000
 Okay. Now, what's also very important,
 and this is pretty key here, is

0:22:27.640000 --> 0:22:32.060000
 we have the concept of GEOs.

0:22:32.060000 --> 0:22:38.960000
 Okay. Azure GEOs represent regions
 within geopolitical boundaries.

0:22:38.960000 --> 0:22:43.320000
 Okay. These GEOs meet EU standard
 contractual clauses.

0:22:43.320000 --> 0:22:47.220000
 You can find additional information
 on, but that is important.

0:22:47.220000 --> 0:22:51.180000
 Data may be replicated between
 regions in a GEO.

0:22:51.180000 --> 0:22:57.040000
 So if I have data that's in East US,
 that may be replicated to West US.

0:22:57.040000 --> 0:23:01.640000
 Okay. Same thing if I'm in Europe, right,
 between let's say North Europe

0:23:01.640000 --> 0:23:05.760000
 and West Europe or East
 Europe, West Europe.

0:23:05.760000 --> 0:23:10.380000
 All right. So in any case, if I've got
 different, different regions within

0:23:10.380000 --> 0:23:12.720000
 the GEO data may be replicated
 between them.

0:23:12.720000 --> 0:23:15.040000
 Brazil is an exception.

0:23:15.040000 --> 0:23:19.740000
 There is, you're not guaranteed if
 your data is in Brazil that it will

0:23:19.740000 --> 0:23:21.520000
 stay in Brazil right now.

0:23:21.520000 --> 0:23:25.100000
 Now, there are exceptions
 to the GEO rules.

0:23:25.100000 --> 0:23:26.400000
 And these are important.

0:23:26.400000 --> 0:23:29.980000
 I mean, it's all important, hopefully,
 but particular here, right, because

0:23:29.980000 --> 0:23:34.900000
 if data sovereignty is important to
 you, then frankly, these are things

0:23:34.900000 --> 0:23:40.440000
 that may, you may need to
 take a special look at.

0:23:40.440000 --> 0:23:43.340000
 Okay. Cloud services, those
 don't really matter.

0:23:43.340000 --> 0:23:44.000000
 You're not going to use those.

0:23:44.000000 --> 0:23:48.620000
 Those are actually from the original
 Azure Azure service management model.

0:23:48.620000 --> 0:23:50.080000
 Highly unlikely you're
 going to use them.

0:23:50.080000 --> 0:23:55.640000
 Now, if you are using language understanding,
 that actually you are not

0:23:55.640000 --> 0:23:58.860000
 guaranteed that that's going
 to stay in region.

0:23:58.860000 --> 0:24:02.740000
 Azure Sentinel also
 not guaranteed.

0:24:02.740000 --> 0:24:06.540000
 And anything that is in preview.

0:24:06.540000 --> 0:24:10.840000
 All right. If you're using a resource
 that is in preview, there is no

0:24:10.840000 --> 0:24:12.900000
 GEO guarantee on that.

0:24:12.900000 --> 0:24:18.500000
 Okay. Also, if you're using and one
 of these is a pretty major stumbling

0:24:18.500000 --> 0:24:23.920000
 block, I think for some folks, but if you
 are using specific global services,

0:24:23.920000 --> 0:24:28.540000
 then the data in those services is not
 guaranteed to stay in a particular

0:24:28.540000 --> 0:24:35.440000
 GEO. And you can see those and I would
 say of those, this guy right here,

0:24:35.440000 --> 0:24:38.940000
 Azure AD, that's kind
 of the important one.

0:24:38.940000 --> 0:24:45.180000
 And so that doesn't mean that you can't
 use Azure AD if you have, you

0:24:45.180000 --> 0:24:49.420000
 know, sovereignty issues,
 sovereignty concerns.

0:24:49.420000 --> 0:24:51.500000
 What it does mean is that you're
 going to have to be very careful.

0:24:51.500000 --> 0:24:57.020000
 For example, what data are you
 storing in your identity?

0:24:57.020000 --> 0:24:59.460000
 Okay. What data is being
 replicated from on-prem.

0:24:59.460000 --> 0:25:02.140000
 Okay. And so those are just things
 you need to be aware of.

0:25:02.140000 --> 0:25:05.980000
 And let me erase that
 because I wrote over.

0:25:05.980000 --> 0:25:08.340000
 Just take all that off.

0:25:08.340000 --> 0:25:11.300000
 Okay. But you also have CDN, which
 is, of course, by definition global

0:25:11.300000 --> 0:25:15.140000
 and multi-factor authentication,
 MFA.

0:25:15.140000 --> 0:25:18.520000
 That's another one kind of like Azure
 AD, where you're just going to have

0:25:18.520000 --> 0:25:21.280000
 to be careful about that, you know, what
 settings you have for that, understand

0:25:21.280000 --> 0:25:23.300000
 that they're not necessarily
 going to stay local.

0:25:23.300000 --> 0:25:26.380000
 And then another one that I think is
 pretty big, you need to understand

0:25:26.380000 --> 0:25:27.640000
 is that security centers.

0:25:27.640000 --> 0:25:30.900000
 So the data that's collected by security
 center is not guaranteed to stay

0:25:30.900000 --> 0:25:34.420000
 within a GEO. Those are,
 again, very important.

0:25:34.420000 --> 0:25:39.500000
 Azure security policy, that's going
 to control, you know, you can use

0:25:39.500000 --> 0:25:41.820000
 Azure security policy
 to control the region.

0:25:41.820000 --> 0:25:42.700000
 That's really what that's saying.

0:25:42.700000 --> 0:25:48.420000
 So in other words, if you are in a particular
 region, even beyond a GEO,

0:25:48.420000 --> 0:25:52.280000
 and you need to make sure that all of
 your resources are provisioned within

0:25:52.280000 --> 0:25:55.960000
 that region or a set of regions, there's
 actually a policy that you can

0:25:55.960000 --> 0:26:01.380000
 apply at the subscription level that
 would make sure that you are limiting

0:26:01.380000 --> 0:26:05.420000
 the regions to whatever would
 be, in this case, whitelisted.

0:26:05.420000 --> 0:26:09.900000
 There is no intrinsic limit
 to access location, right?

0:26:09.900000 --> 0:26:13.200000
 And so what that means is I could have
 a storage account that has sensitive

0:26:13.200000 --> 0:26:19.600000
 data, and I can make sure that that storage
 account is located in a particular

0:26:19.600000 --> 0:26:24.480000
 GEO, let's say, in the U.S., in
 the United States of America.

0:26:24.480000 --> 0:26:28.240000
 But that doesn't guarantee that
 someone from outside of the U.S.

0:26:28.240000 --> 0:26:30.000000
 may not access that, right?

0:26:30.000000 --> 0:26:33.800000
 And so that's where if you have that
 level of sensitivity, that's where

0:26:33.800000 --> 0:26:37.980000
 things like service endpoints
 become very important, right?

0:26:37.980000 --> 0:26:43.000000
 Because you may want to limit the access
 to your data to a very specific

0:26:43.000000 --> 0:26:49.260000
 set of IP addresses, or maybe even just
 limit it to direct private access.

0:26:49.260000 --> 0:26:51.220000
 So that's data sovereignty.

0:26:51.220000 --> 0:26:55.980000
 Again, I think there's a number of interesting
 concepts within data sovereignty.

0:26:55.980000 --> 0:26:59.220000
 I think there are a few gotchas that
 you definitely need to be aware of

0:26:59.220000 --> 0:27:00.480000
 that we've called out here.

0:27:00.480000 --> 0:27:06.460000
 All right, so there we go.

0:27:06.460000 --> 0:27:11.640000
 But we're talking about data classification,
 both from tagging and also

0:27:11.640000 --> 0:27:14.280000
 showed you SQL Server,
 which you can do there.

0:27:14.280000 --> 0:27:19.100000
 All right, and we've got data sovereignty,
 all right, and we looked at

0:27:19.100000 --> 0:27:24.120000
 what you can do with data sovereignty
 and also data retention sandwiched

0:27:24.120000 --> 0:27:24.740000
 there in the middle.