Press "Enter" to skip to content

Category: Security

Security Replication in Power BI

Published 2023-04-13 by Kevin Feasel

Marc Lelijveld and Vytautas Kraujalis lock things down, over and over and over:

Imagine, you have everything setup and well secured in your data lakehouse, or data warehouse if you will. Then a user starts consuming the data in Power BI and imports all data according to the security applied to that users’ permissions. Once the data is imported, all data can easily be shared to others who might have other permissions on the same dataset. Potentially, this leads to a breach of data to people who should not have accessed this data at all. Ideally, you replicate the security from the source into Power BI, but without setting up everything by hand.

In this blog post, you will learn how you can automate the replication of security from source to your Power BI data model in just a few steps. A blog post based on an actual client case and written by Vytautas Kraujalis and myself.

Click through for an explanation and a link to the GitHub repo containing all of the scripts.

Comments closed

Row-Level Security in Power BI

Published 2023-04-12 by Kevin Feasel

Reza Rad continues a series on data security in Power BI with two posts. The first covers row-level security:

There are multiple levels in which you can secure the data in a Power BI Dataset. Row Level Security is about applying security on a data row level. For example, sales managers in the united states should only see data for the United States, not Europe. The sales Manager in Europe won’t be able to see sales in Australia or the United States. And someone from the board of directors can see everything. The reason was that Row Level Security wasn’t part of the Power BI model. Now in the new version of Power BI Desktop, the security configuration is part of the model and will be deployed with the model.

The second looks at dynamic row-level security:

The most important question is, why dynamic row-level security? To answer this question, you must consider the limitation of static row-level security. Static row-level security is simple to implement. However, if you have thousands of roles, then it would be a nightmare to maintain. For example, if you want to create a payroll Power BI report in a company with ten thousand users, you want every user to have his/her role. Dynamic row-level security is the answer for such scenarios.

Check out both posts for more info.

Comments closed

Data-Level Security in Power BI

Published 2023-04-11 by Kevin Feasel

Reza Rad explains different ways to secure data in Power BI:

Power BI supports the security of the data at the dataset level. This security means everyone can see the data they are authorized to see. There are different levels of that in Power BI, including Row-Level Security, Column-Level Security, and Object-Level Security. All these help Power BI Developers create one dataset but give users different views of the data from the same report. In this article, I’ll explain each of those methods and give some guidance on how to use them.

This serves as the opener to a series of articles on Power BI data security.

Comments closed

Provisioning an Azure Key Vault

Published 2023-04-07 by Kevin Feasel

Andy Leonard takes us through building an Azure Key Vault:

One way to keep confidential information confidential is to store confidential values in Azure Key Vault.

This post describes one way to provision an Azure Key Vault.

In addition to other values, I use key vault to store login usernames – as well as passwords – in key vault. Why? I don’t like storing half of the login information – the username – in plain text. In case I haven’t shared this with you, you should know I use a password generator to create usernames and passwords. In Azure, it’s common to use the same username and password in multiple locations, so when I change access credentials (You are regularly changing passwords, at least, right?), I can update both values in a central location.

One nice thing about most Azure services is that they make Key Vault access fairly easy, especially if you use the managed identity account to grant vault access.

Comments closed

TDE with Customer-Managed Keys in Azure SQL Database

Published 2023-04-05 by Kevin Feasel

Mirek Sztajno announces a public preview:

In this scenario, a key that is stored in a customer-owned and customer-managed Azure Key Vault (AKV) can be used for each database within a server to encrypt the database encryption key (DEK), called the TDE protector. The feature provides the ability to add keys, remove keys, and change the user-assigned managed identity (UMI) for each database. For more information on identity management, see Managed identity types in Azure.

Click through for more details on how it works and what’s currently not supported in the public preview.

Comments closed

Hiding Power BI Pages Is Not for Security

Published 2023-04-05 by Kevin Feasel

Marc Lelijveld points out that, just because the kitten covered its eyes and can’t see you don’t mean that you can’t see it:

Most of us probably know, but every now and then, I still run into cases where hiding pages in a Power BI report is used for security purposes. Although hiding pages might seem like a security feature, it is not intended to be used as one since it can be easily bypassed. Users can find hidden pages by simple URL tweaking or right-clicking on the tabs. The article provides an example of how users can use the Reports-Get Pages API to get all report pages and report sections without having to write a single line of code. The default page when publishing a report is the one that is open, even if it is hidden.

Yeah, hiding pages is really more of a convenience thing, especially if you’re making heavy use of drillthrough and other cross-page functionality.

Comments closed

SQL Alerts on Potential Attacks

Published 2023-03-31 by Kevin Feasel

David Fowler keeps his head on a swivel:

But let’s be honest, the above attacks are just going to be opportunistic hackers probably using an automated tool to hunt out open servers and try to exploit them, a bit like the guy walking down the road and trying all the car doors in the hope that someone will have left their unlocked. It someone’s specifically targeting your servers, the chances are that they’ll be a bit more sophisticated.

This is where things get a little more troublesome and where SQL doesn’t really give us any tools to help.

But there are warning signs that we can look out for and these can be certain error messages in the logs. There are three in particular that I see as red flags that something amiss may be going on.

Click through for those three warning signs and how you an create SQL Server alerts upon logging these messages. The errors aren’t guaranteed to be an attacker, though in reading them, I’d expect a high signal to noise ratio on them.

Comments closed

Enabling Powershell Constrained Mode

Published 2023-03-24 by Kevin Feasel

Patrick Gruenauer slips on the straightjacket:

In this blog post I am going to show you how to enable the PowerShell Constrained Mode. What is the Constrained Mode? Microsoft explains this as follows:

Click through for that definition, as well as a demonstration and bit more explanation. It seems that there’s a specific use case for constrained mode, and it’s not one most of us are likely to work with.

Comments closed

An Overview of SQL Server Security Options

Published 2023-03-22 by Kevin Feasel

Ben DeBow gives us a once-over of things you can do to harden a SQL Server instance:

Microsoft SQL Server is one of the most secure platforms available, but companies need to deploy, configure, and implement it correctly – along with implementing its built-in security features – in order to ensure their systems are fully protected. Here, we’ll explore six of the most important security features and how to implement them to enhance your SQL Server security.

This isn’t a how-to guide so much as it is a what-you-can-do guide.

Comments closed

Pro Encryption in SQL Server Errata

Published 2023-03-22 by Kevin Feasel

Matthew McGiffen made the first mistake—admitting fault for anything, ever:

My biggest fear when my book went into production was that any factual errors had slipped through my checks and the various reviews. I had a lot of reviewer support from Apress, but at the end of the day any issues are my responsibility.

So far I’m not aware of any factual errors but one kind reader (Ekrem Önsoy) has shared with me a few typos they have found. I’m going to document them here and will keep this post up to date as I’m made aware of any others:

Mistakes in 300 pages of text will happen, no matter how many times you go through your magnum opus. For example, I hate the fact that I went through every chapter of PolyBase Revealed 8 or 9 times to weed out any little typo. Then, as soon as I got my copies of the print edition in, I flipped open to a random page and immediately spotted a typo.

Comments closed