Implement Security and Governance

0:00Welcome to the content on security and governance in Microsoft Fabric. Look, I wasn't born yesterday. I know there's a chance you looked at the exam blueprint and saw security and governance of Microsoft Fabric and thought that's not the sexiest topic on this exam. And I'd have a hard time disagreeing with you. It's definitely not as fun as building things like ETL pipelines and strong semantic models with all sorts of nasty queries that ultimately produce really cool results. But here's the kicker. A business's data is arguably their most important asset.

0:35It's what drives every decision from the top to the bottom about how to move this whole thing forward. It tells you where you've been and where you're going next. And that's why it's absolutely critical. So when you administer Microsoft Fabric, you're in charge of your enterprise's data. And Microsoft Fabric is really built for large enterprises with a lot of data. So chances are, this is a really critical piece and high value item that you're in charge of. So you really need to understand how to lock down certain parts of your data so that it's not just out there for anyone in your enterprise to come along and see and worse, potentially change.

1:17Microsoft gives you a broad spectrum from the broadest range of things that you could administer like a whole workspace down to the individual rows or columns of data themselves. So you get to pick everywhere in between. These people and that person in this group needs access to these things, but we always got to keep the principle of least privilege in mind here. We don't want to give away too much access rights, too many privileges over too broad of a spectrum. And the temptation can be to do that because you get busy and somebody needs data critically and they don't have access to it.

1:52So you just go, ah, global admin. That happens all the time. So what we're here to talk about is you understanding what are your options when it comes to administer the security and governance, not just to Microsoft Fabric, but your data itself. So that's what we're exploring in this set of videos. Without further ado, let's get started.

0:00So we are talking about security and governance in Microsoft Fabric. And as you can see, I'm here in my workspace. We're going to talk about workspaces a lot starting in the very next video. But first, we kind of need to talk about where we're going. There are two separate topics here, security and governance. Well, what's the difference between these? Security is who can access what? This is you as the administrator making a control, making a decision saying that so-and-so can access the workspace, or so-and-so can access the data flow, or so-and-so can access data in the lake house. Or maybe specifically, they can only access these columns in the lake house, or these rows in the lake house. Or maybe specifically, they can only perform these actions in the lake house. This is you tightening things up and locking down what it is that they're allowed to do. Governance, if I change colors here just a little bit, governance is all about sending a message to the people who consume the data. And it usually falls into one of two categories. There is usually an endorsement, which is where you as the owner of this data

1:25say it is good to go. So other people who use it can see, oh, Knox owns this data and he endorsed it. Therefore, I can trust the data that I'm connecting to, that it's accurate, that it's the latest version, that it has gone through this pipeline and this rigor and this standard that holds it up to a certain value. Simultaneously, governance also lets the end users know if the data is sensitive in nature. Does it control or contain personally identifiable information, or health information, or credit card information? So when they connect to it, they are seeing exactly what kind of data they're accessing. And importantly, if they should be aware that what they're accessing is sensitive by nature.

2:18You can see how these two, hang on, hang on, hang on, my paint. There we go. I had to fix my paintbrush here. You can see how these two could be used together. Because we might be in a situation where John does need access to the lake house, but John also needs to know that they trust the source of the data, that it is the latest version published by the correct team who created the data, and that sensitivity may be involved in the mix here. We're just picking on John there for instance. We might simultaneously say Jane over here needs to be able to administer things like this data flow because she is an ETL engineer, but she does not have any need to see the underlying data at all. So Jane, we might restrict her access to what the resulting data set in the lake house or the warehouse looks like, or the semantic model. Usually in large enterprises, things are broken down by teams, teams over a certain app or teams over a certain task like

3:36ETL versus semantic modeling. And this kind of makes the talk a little bit bigger here. When you're a fabric administrator here, let me get this out of the way. When you're a fabric administrator, you're sitting over the top of your enterprise's entire data ecosystem, their entire data library. That involves the data source, the ETL pipeline, the bronze, silver, and gold data stages. We're going to talk about those later. The data warehouse where the data lives in, the semantic model after it's been modeling. So you have a very large responsibility in a large enterprise where you then have to keep up with what app creates the data or consumes data and what task happens as it's moving through this and what teams are attached or responsible for each of these. So you end up getting a lot of levers and knobs to pull in the form of role based access control. You'll be able to say at this tier, these groups can perform these actions because they belong to a specific role. So as we progress through this set of videos,

4:55we're going to focus first and primarily on security and understanding where security happens. And then at each one of these layers, what roles or permissions do you have to set for other people? How can you tighten up or expand their permissions at this given level? And we'll walk through configuration examples on how to pull this off. First, we needed to set up the stage of what is security versus what is governance. Again, security is controlling access and permissions.

5:31Governance is how we label data so the consumers know what it is that they're actually working with. On to the next video where we begin security at the workspace level.

0:00The first thing we're gonna talk about is workspace permissions. And as we can see here, I am in my DP 600 workspace. Now, here's the thing. What we're gonna do is we're gonna look at how we can manage access to this workspace. Because by default, I am the creator of this workspace and I've created everything in this workspace. All the content you're about to watch if you're following this playlist in order. Things like the pipelines, the semantic model, the lake house, the data flows, all of these things are things that I created.

0:33And all of these things, I am the only person who knows that they exist. Nobody else in my enterprise or organization can even see this workspace, let alone any of the contents or the data inside of it. So that's a pretty big burden for little old Knox to handle in a large enterprise, right? So when we give access to the workspace, here's the first thing that you understand. This is different from almost every other security posture in all of technology and IT and systems today.

1:08Take everything that you've learned about security and just throw it out the window. Because it's just gone when it comes to Fabric. If I make someone an administrator over this DP 600 workspace, they then can see and control everything underneath it. And you might then be thinking, okay, but what if I don't want them to see this semantic model?

1:39Can I deny them permissions to this very specific object? Because in security, the most specific thing wins. And the answer in Fabric is no. In Fabric, every one of these objects gets inheritance from above. And you cannot supersede it with a specific deny. So if I make John a workspace administrator and he gets to control everything in the workspace, that's it, that's what John gets.

2:17So we gotta be really, really careful when we give permissions to the workspace level. So the workspace sits over everything. Above the workspace, we then have objects. This could be like a semantic model. This could be like the lake house. And within those, we then have row-level security and column-level security.

2:51We also have a subset of object-level security, which can be things like individual files or individual tables inside of Direct Lake, Data Lake, and the warehouse itself. But when you start at the workspace and you're like, this person has access to the workspace, they get everything underneath it. Now, the good news is, is at the workspace level, there are roles. We don't just grant everyone administrator privileges to the workspace and they can control everything.

3:24So we're talking about the workspace now. And at this point, we're thinking, someone who genuinely does need to help manage the entire workspace. Within the workspace, I'm gonna put WKSPC for workspace, there are four roles, admin, member, contributor, and viewer. The admin is the owner.

3:55They have access to connect to and change everything in the entire workspace. And the biggest thing about here is they can change security settings. They can give people different permissions. When you think admin, think security, think security changes. It's not just about the data. It's really about changing the security posture of itself. When you think member, you start to think data owner.

4:27They can create, edit, which includes delete, and importantly, share data. That's what the member of the workspace does. And again, they're doing it for every piece of where data lives inside a workspace, because all of this is scoped to the workspace. The contributor can create and edit data, but not share data.

4:58They can't invite people, they can't share data. And viewer, you guessed it, is read only. So if we go into manage access, and I wanna add someone in here, and I may, let's go ahead and add Jacques Boudreau into the mix here, and I make them a contributor. Click add, and it's done. Jacques is now in this workspace right there as a contributor, and notice I can change their permissions anytime.

5:32Can I then go into this semantic model right here and say Jacques can't access this? No, Jacques is a contributor. As a contributor, he can create and edit data wherever it lives in this workspace. So that is really important for you to understand. He can't share, and he can't change the security privileges, but he can create or edit data anywhere it lives in this workspace. But for the workspace itself, it's relatively simple.

6:05Encompasses everything underneath the workspace, four roles, and you can manage the access right here on the manage access button. It's as simple as finding someone in their intra ID and setting a role that they can use right there.

0:00So let's pick on this semantic model because the semantic model really is like the end state of your data. This is ultimately the shape of the data that we want our report analysts and report creators to connect to and build visualizations and dashboards. This is after ETL has happened. This is after it's loaded in the warehouse. Then we've created the complex calculations and aggregations needed to answer questions like what is the year over year sales percentage growth?

0:32That's what is in a semantic model, that number, that math, given whatever years you're looking at. That's what the model does. So if I have people where their whole job is either creating models or editing models or connecting to models, do I want to give them access to the workspace? No, even with a view only or read only, even as a viewer role, I don't want them to be able to look at the lake house, the data flow, the pipeline, the warehouse.

1:07I don't, they don't need to see that. They only need to see what's inside the model. So how do we go about getting, say, Alice permissions to just the model such that Alice doesn't get access to the workspace? Well, what I'll do is I'll go into the model itself and it will load after a minute. Here it comes. Great. And what I'll then do is I'll go to file and I'll go to share.

1:40And from here, we just type in the name of the person that we want to share this to. Now, I actually don't have an Alice in my environment and I'm trying to think about all the names that I do have in my environment. I think I have a Simon, Simon Simenow. Yeah, there you go. There's Simon Simenow right there. So what do we then allow Simon to do? This is where we scope the permissions. Allow recipients to modify this semantic model. Are they a editor, a contributor, or are they read only?

2:11We'll give them that. Allow recipients to share this semantic model. Are they maybe the manager of a team and then they can then distribute it and fan it out down to their team from there? Or are they kind of an end user and they never need to be able to control who gets access from there? Allow recipients to build content with the data associated with this semantic model. Maybe they're a report creator and they are gonna use Power BI to build visualizations and dashboards on top of it.

2:43That's where we're up to this. Now, I'm gonna tell you right now, the average end user who's connecting to a semantic model, they will probably build dashboards and reports, but it's also good for them to be able to create their own measures and their own aggregations and their own calculation groups. It is not uncommon. It is in fact common for a Power BI user to also be good at modeling data. So in my head, I'm gonna tell you, I think it's gonna be most common that you allow recipients to modify the semantic model because they'll be creating or changing measures, calculation groups, and so on, time intelligence analytics, and they're gonna wanna build reports on top of it as well.

3:31It will be much less common for them to need to be able to invite other people to this semantic model. Unless they are a manager of a team, then they, he or she will then be like, okay, I've got control of this model. I'll then fan it out to the rest of the team. And the cool thing about that is let's say Alice is the manager, and she has five people reporting to her. Well, because we're scoping Alice's permissions to just this model, she can only invite people to just this model.

4:04They don't get a backdoor access into the workspace itself. They're not getting access to the lake house or the warehouse or the data flows or the pipeline or anything like that. We're really just talking about the model. So here we've gone from workspace level permissions to item, that way I did a capital I, a capital T, and then a lowercase e, item level permissions. In this case, the model is an item.

4:36Now, again, the interesting thing here is the workspace contain roles. The model doesn't. The model just has check boxes with what they're allowed to do. So when I click grant access there, we've just granted Simon access to the semantic model. Does it have to in there? No, he may also need access to another thing in the environment like the lake house where the model is coming from. So when I go into the lake house here, and then from here we think, okay, well, I probably wanna manage control and access to this via security.

5:14Well, guess what? Security to a lake house or a warehouse works exactly like it's always worked with SQL, where we actually have SQL-based roles and we'll grant them access to SQL-based schemas. So what I'm trying to show you here is that you're gonna shift out of the fabric administrator for a second and become a database administrator when you wanna grant access to a lake house or a warehouse.

5:48And you've got a lot of common things like the database owner, the security admin who can only control access rights and can't read the data itself. You've got a data writer, a data reader role and someone who can actually just handle backups. The point, the real big takeaway here isn't so much that you need to know that lake house has built-in database roles and you grant roles to certain schemas. It's that when you get to item level access, it is different from one item to the next.

6:19You've seen how we granted access to a semantic model. It was just type their name and click a couple check boxes. When we get into a SQL analytics lake house, guess what? We're actually using T-SQL to grant permissions to certain tables, schemas and so on. One more for good measure, let's take a look at a Dataflow Gen 2. This is actually kind of a gotcha because there's not really a place where you can invite someone to collaborate on a Dataflow Gen 2.

6:51In fact, a lot of Microsoft documentation will tell you you just need to give them contributor access to the workspace itself. Now, that being said, connections are a little squirrely because the user will also have to have permissions to the underlying data source too, to build a connection or connect to the source data as well. So that's another thing you'll have to keep in mind is that what kind of connection permissions and who is connecting in can also alter what's going on with the Dataflow.

7:25So all of that is to say for item level permissions, instead of granting someone access at the whole workspace level, it's kind of a, you need to look at it and make sure that they can actually have permissions to the underlying items first. A lot of times when it comes to ETL jobs like Dataflows, pipelines or copy jobs, there is no invite them to this one specific item and they will start looking at workspace permissions to get to that point.

0:00Now we're talking about row-level security. And when we talk about row-level security, we're talking about inside the data itself. If you're thinking about an Excel file and there are rows of data, you know, containing records of whatever transactions took place, and you're thinking to yourself, I want some of my employees or consumers to be able to see some of these records, but not all of them, that's where row-level security comes into play. Example, let's say we have a sales territory.

0:33Some people are in Texas, some people are in Louisiana, some people are in Mississippi. I may only want my Texas team to see Texas records. I don't want them to see Louisiana or Mississippi records. That's the idea here. We can actually say this user belongs to the Texas group, therefore make sure that whatever visualizations they interact with are only specific to Texas. That's what row-level security is all about.

1:04So we don't have to make some magical filter query in the Power BI report itself. We can actually do it in the model, in DAX, and that's what we're gonna work through in this video. This is really important in semantic modeling. Now, I am in view-only mode right now. You can see that we're in viewing mode. If I change this to editing mode, that will unlock all of the things that we see right here in the security section with manage roles and manage permissions. But what you need to see first is the semantic model tells you the direction that filters occur.

1:41So if I say I have a salesperson that's assigned to only one huge enterprise, and they should only ever be able to see this one company's sales, we can see that by selecting a company, it will then filter out the resulting sales in this direction. That is what this arrow means, is the customer can filter the resulting sales in the sales table. So when we understand that direction, I can then say, okay, John, or let's actually, let's do this, let's say Simon, because I actually have a Simon.

2:18Simon is assigned to this customer. Therefore, Simon should be in that customer's role where these permissions filter out and only show them that customer's sales. That is row level security. So now that we understand the relationship going from the customer table to the fact table, we can build a filter on the customer table, and it will result in a filter of the fact table, the sales table, where all the sales records are. So the first thing we need to do is manage roles.

2:49We need to create a role for this specific filter. And what we'll do is we'll create a new role, we'll filter it on the customer table, and we'll say, what is this new rule? Well, if the company name equals something, we got to actually get a company name here. I'll just run a query real quick and see what the result is here. And we'll just grab a company name like A Bike Store. How simple is that? A Bike Store. All right, so with that, we'll say if the company name equals A Bike Store, then that is our security role.

3:27Notice you can look at this in DAX by switching this to the DAX editor, and if the company name is A Bike Store, that is the role itself. Switch it back to the default editor, and it looks good. Check this box, and we can see kind of how we're managing this. I'll click Save, and that'll create the role. It hasn't created an assignment yet. In fact, what we might want to do is we might actually want to rename this and say A Bike Store role, and just save it to give it an updated name.

4:00There we go. So now that I've got this role, I need to assign it to an end user, and this is where we'll type in Simon Simino's role again, or user group. We'll say we'll add that particular user, and click Save. And now Simon, when they access this, they will only see the Bike Store role. But again, this is a really important thing to say. We have answered the question, what can Simon see inside of this data?

4:34And that is A Bike Store's data inside the semantic model. But don't forget, we still have to give Simon access to the semantic model in the first place so that they can see it. So if I close this and you go to Manage Permissions, make sure that Simon has access to this. In this case, he has read, write, and build access to it. You can choose which one of these to remove right here.

5:07Now, what is build versus write versus access? Remember those three checkboxes. Access is view, read only. They can see that the semantic model exists and they can see what's inside of it. Now, scope to that role. Write is they can edit the semantic model itself. Build, reports, and dashboards, built on top of the semantic model in Power BI.

5:45That's really what we're talking about here when we think about build. Dashboards, reports, Excel workbooks, which can also be built off of this semantic model. So now we understand row-level security and how we can say this specific user should only be able to see this data inside of this semantic model and subsequently reports and dashboards.

0:00Row-level data filtered out what rows a user is supposed to see so that they only see data that's relevant to them or their job or their purpose. Like we said, if you work in Texas, you may only need to see Texas data. There's no reason for you to see Louisiana data. Just focus on your state and your territory. Column-level data goes, it kind of asks a different question. What attributes of this data, of this record, are relevant to you? And lots of times you see this filtering out things like PII.

0:35Maybe we want them to see sales numbers. We don't want them to see, say, customer email addresses or phone numbers. So we can remove the phone column or the email column from what a report analyst might be able to see. So we'll go ahead and jump into something like my lake house and start to look at how to configure this. We'll jump into the lake house first. Then from here, we're gonna look for Manage OneLake Security. So I'll jump into Manage OneLake Security and we can see we've got a default access role.

1:09There is a default reader who is granted the read permission. Let's create a new role and call it Sales Analyst because they wanna analyze sales, but we don't necessarily want them to be able to see customer-specific details. So saying this is Sales Analyst, we're gonna give them read permissions. They don't need to edit data. So we'll leave the read checkbox selected and click Next. Now what? The next question is what data can this role access?

1:40Not necessarily specific person. We'll give the role to a person later. Do they need to see all data or maybe just a subset of this data? Yeah, subset. We're gonna do selected data right here and we don't have any selected data yet. So we'll click Edit and we'll start browsing for the data that we want to look for. Let's make our way to that customer table. We'll go into Sales LT and I'll grab the customer delta table that lives right there. Maybe we'll take a look at customer address too and see if there's anything we want them to have or lock down.

2:13So I'll click Add Data right here and it brings them in and you can expand it out and see what all did we choose. We see the table and the data permissions are set to read. But that just gives them full access to these full tables. No, we need to go back in and edit this, make our way back. Hang on, don't check the whole tables. Go back into the schema and let's grab say this customer table for a second. With the customer table, give it a click and now we can kind of see a group of files that exist related to this customer table but then go to data access.

2:50Here we can say row level security or column level security. And from here we can start to specify the things that we want to take out. For instance, I don't want them to have read access. We're gonna hide the email address and the phone number. We should probably also hide anything related to their passwords too, shouldn't we? So having hidden the email address, the phone number, the password hash and the password salt, I'll click add data now.

3:22And when we expand this and look at the customer, we see there are some data access permissions, one or more CLS constraints, column level security constraints are applied to this table. So click next and then we add members to this specific role. So I'll add Simon in here. They can now work with this table but they won't be able to see those specific columns.

0:00The next thing we're talking about is object level security. And here I've got something on the screen. It's an application called Tabular Editor. You haven't seen this application or work with this application yet. This actually comes at the very end of this course when we start using an external third-party tool to edit the underlying semantic model. Now, here's the thing. In Fabric, you get to work with the data in the semantic model. And you get to build aggregations and build relationships, but you don't get to work with every single thing that the model exposes in Fabric, in the website.

0:41To get to the underlying properties of the semantic model itself and the metadata that's stored in the semantic model itself, that's when you need a tool like Tabular Editor. And Tabular Editor is where object level security right there lives. The idea with object level security, we enforced row level security in our semantic model, but we might want to enforce things like column level security or remove tables entirely from the view of someone in this role.

1:18And that is what object level security is all about. All of these things, all of these tables are objects. So sure, we can write a query, a DAX query that filters out rows, but we can't really do anything that stops them from seeing tables. So from here with Tabular Editor open, and again, you're gonna learn more about Tabular Editor at the end of this series. We're just talking about object level security here. I can choose my role. So look, if I click on each one of these things, you can see Tabular Editor shows me all sorts of properties here.

1:52And I can say things like, no one should ever need to see the customer ID column. And I can change that to be a hidden column by changing this dropdown to true. And then when I click the save button right here, that ships this change from this local computer up to Fabric. But if I want to get into this role right here where I can see I've got some row level security enabled on one of these six tables. If I want to add some object level security on these tables, I'll expand this and I can say, you know what?

2:27They don't really need to see the sales channel either. So I can change this to be none. And now I've created a hidden sales channel table rule for that specific role. When I click the save button again, there it goes. So a very quick video on what object level security is here when we can change what a role sees as a table as a whole is altering the object and not just the individual roles.

2:58But again, this is something that really needs to be done in a tool like Tabular Editor. It's challenging or tricky to get to the TM. Let me get the TMDL. It's basically a metadata data language file, a tabular metadata data language, say that three times fast, file where you can edit the underlying metadata in these objects to secure it by hiding specific objects.

0:00Within a Lakehouse, we not only have tables that we query like a SQL Analytics endpoint, we also have data lake storage where we can store files of all sorts, not just CSVs, but JSON, Parquet, whatever it is. It's very likely that we can store it, query it, and process it here. And as such, we can create roles around these data files and folders on top of that. So back in manage one lake security, we have our sales analyst item right here.

0:34And of course, we granted permissions to specific tables with column level security from here. But we can also hit edit data and take a look at what we can do with files too. So maybe I want them to see the business data file. Great. So what I'll do is I will check off the files button here and then hit add data. And now we've given them the ability to explore certain files in the file structure. Now, the kicker here is it doesn't work at the individual file level.

1:08It works at a folder level. So if we wanted to try and grant them permissions in one folder, but not the other, we'd have to restructure well in one file, but not the other. We'd have to restructure this to actually be in folders. So first, let's create a new subfolder and we'll call it public. And then we'll create another new subfolder and we'll call it private, like so. So to clean this up, what I'll do is I'll delete both of these files, get rid of them entirely.

1:44And then in the private folder, we'll upload the raw source that I was working with. I'll just do upload files and we can see I've already seen where a recent upload was. I'll grab the file from the folder, hit upload, and there it goes. Now we've got this item in the private folder. Simultaneously, I'll go back to the copy job where I got that data and I'll put this copy job landing in the public folder.

2:14So what I'll do is I'll wait for the resolution on the screen to adjust itself, because that's what happens in Safari sometimes when working with fabric. Here it comes. Maybe. Maybe what I'll do is I'll just click on the edit mapping button and then wait for that resolution to adjust here. There we go. Now I've got the edit mapping button brought up. We'll change the data destination to be in the public folder. And it's clicking OK. It's got it saved. Now we've got the file name and everything else is ready to rock and roll.

2:45I'll just make sure I edit the map. Mapping looks good. We've got all the columns and I'll run the job to make sure the copy takes place. We see it's in the queued state after about 10 to 15 seconds. We'll see it actually be successfully completed and we'll then have the data cleaned up where we'll have the folders and the files and we'll have the original source as well as potentially let's pretend it was a cleaned up one that went through an ETL pipeline. So there it goes. It succeeded.

3:17So now when I jump back to my lake house, we'll wait again for the resolution to adjust. I'll hit public and now I see the data is in the public folder, but I can't really do much until the resolution adjusts. So we'll just wait. There we go. After about 30 seconds, it's back. So now when I manage my one lake security, because I've got a folder structure in place, I'll go into sales data analyst. I'll edit the data and instead of granting access to all files, I'll grant access to only public. We'll say add here.

3:50And now that role has access to the public folder and not the private one. So it's another way to do file level security and file level object storage selection.

0:00You as an administrator have the ability to allow people to attach their own security sensitivity settings or labels. You can kind of think about them as really nothing more than a label or a tag to a data set like a lake house or a semantic model or a Power BI report. But first, you have to actually enable this feature. Well, let's start from the very beginning. First of all, you don't get a pre-built set of sensitivity labels for data. You have to create them yourself in Purview. So you might create something like private or internal. You might create something like PII to label it with. You might create something as PHI. You might create something as PCI. Whatever compliance thing that you're trying to identify here, you'll go into Purview and create these data labels. And then once you enable the ability for Fabric users to attach a sensitivity label to data or Power BI content or downstream content, notice you'll see all of

1:16these things are disabled by default. So that's what you need to know is that nobody can do this to begin with. So you have to create your own labels in Purview. Then you have to go into your global administration settings. Let me show you how to get here. Gear again, admin portal, then on tenant settings, scroll all the way down until you get to information protection. Then you'll want to flip these on and we'll say apply. And well, we can't do this right now because it'll also be applied. Something went wrong. Okay. Oh yeah. It tells you that you have to have sensitivity labels already created in Purview. I don't have the licensing to do that.

2:02I don't have the security licensing to do Purview, but like I say, it's relatively simple. You will just create internal private, whatever labels you want, and then come here and turn it on. Once you've got those created, let me hit discard all and show you, you'll come into something like your lake house right here. And in your lake house, right at the top in this section, there will be a fan out button with a dropdown where you can set a sensitivity label at this point.

2:35That way it alerts people who are working with this data. They then know, oh, this has a sensitivity classification attached to it. So I shouldn't just download it as a CSV and put it on a thumb drive and take it home. Now it doesn't just stop there within Purview. They do have something called fabric protection policies. This is outside the scope of the DP 600, but I want you to know that it exists. If you go into Purview and create a fabric protection policy, you can then say, if this label like sensitive, PHI, PII, then these users don't get access to it.

3:23You can restrict access based on a Purview label in fabric, but this is configurable in the Purview side of things. Now, that's the first thing I want you to know about governance, of course, is sensitivity labeling and just signaling to end users what kind of data they're working with. There's another thing that's also kind of a complex one to wrap your head around, unless you work for a very large environment. And that is endorsements. If you work with a very, very large enterprise and they have lots of data and you may have report writers on one team, semantic modelers on another team, ETL pipeliners on another team, or maybe there's even multiple teams within these sections because they're app specific.

4:13How do you connect these people together? How does the modeler say, hey, I've just created this new model that's really good. You report writers should know about it and you ETL people should build to help me flow into this model and keep that pipeline going. This is where endorsements come into play. And it's not just you, the creator, who gets to endorse your own work. Team members who also have write permissions can also endorse your work and help your other teams discover your data or your product, the thing that you created, and by signaling the degree of which you endorse it. Now on almost every single one of these resulting data things, like a lake house, a warehouse, a model, if we go into the settings, eventually somewhere in here, you will find an endorsement and discovery button. And it tells you, help coworkers find your quality content by endorsing this semantic model and making it discoverable. By default, none is selected everywhere. This semantic model will appear in search results, but it won't show up as endorsed. Promoted is when you're ready to distribute the semantic model to your coworkers, promote it to let them know. Basically let them

5:30know it's done. It's production. We can just feed into it now. It's not a work in progress. Then you have a layer above this where you have certified. This is where we're really saying like the whole organization has put their stamp on this product and you should know about it. Now, master data is grayed out and it even comes with a link. How do I get my semantic model endorsed as master data? Are you ready to see the funniest thing? If it says the link here is how do I get my semantic model endorsed as master data? I give it a click and the link tells you if you click this link, you'll find out how to get your item endorsed. Even though it takes you to this page where I go to learn about it. It's like a loop. You could click this link forever and maybe one day it'll get. The idea here is ultimately, this is actually a global tenant wide setting that is disabled by default. The actual tenant administrator has to enable the master data feature and then assign a master data certifier, a person that they will say, this person is the master data certifier. This becomes like the whole enterprise runs on this data. When you select one of these, it then signals it to the rest of the users. This product is

6:50endorsed and is good to go in your environment. This is what governance is all about. It's about signaling what kinds of data lives underneath and whether or not you can trust it, as well as if it's sensitive to begin with. Now we've talked about security and governance in Microsoft Fabric. I hope this has been informative for you and I'd like to thank you for viewing.

0:00Let's refresh what we've learned about security and governance with Microsoft Fabric. A company uses row-level security to ensure regional managers only see sales for their assigned state. A manager is currently a contributor in the workspace. What should you change so row-level security is in force? Change them to a viewer. Here's one of the catches in Microsoft Fabric and you might see this on the DP 600. The moment somebody has right-level access to the underlying data, row-level security is tossed out. You have to have a read-only access, view-only access to a semantic model in order for row-level security to be enforced. So contributor, member, or admin, row-level security is not enforced. They get to see all the data because they're in there editing it. A semantic model contains an employee salary table.

1:04Regular report users should not be able to see the table or discover that it even exists. What should you implement? Column-level security, object-level security, right there. We saw this with Tabular Editor, where we can not only hide columns, which is clever and useful, but we can also hide whole tables or objects themselves in the metadata. Your organization has several sales semantic models, but one has been formally reviewed and approved as the trusted model for corporate sales reporting. Which endorsement should it receive? A little tricky because it could be different from one organization to the other. But the idea here is if it's gone through a formal review and approval process to be used for reporting, then the answer here is certified.

1:57Master data is where it is not necessarily used for reporting, but it is the golden standard of the data itself that report models can be derived from. It can be forked and derived. Promoted means someone is endorsing it to be used publicly, but it hasn't been formally reviewed and approved. Certified is where the company itself is saying this is the one that we want to use for internal reporting. So that's been refreshing what we know about security and governance in Fabric.