Press "Enter" to skip to content

Category: Security

Workspace Identity Authentication in Power BI

Teo Lachev looks at a new way of authenticating:

What credentials do you use to refresh your Power BI semantic models from Azure SQL SKUs, such as Azure SQL Database. Probably your credentials or a designated Entra account? Both are not ideal for a variety of reasons, including requiring a password. More advanced users might be using service principals, which are more secure but require secret renewal after a maximum of 24 months, which is a hustle.

Read on to learn about a new alternative in workspace identities.

Leave a Comment

OneLake Security ReadWrite Access

Kiefer Sheldon practices least privilege:

Many data teams face the same challenge: balancing the need for open collaboration with the responsibility of protecting sensitive information. As organizations grow, data often lives across multiple domains—some containing critical or confidential datasets—while partner teams may only need access to a subset of that information.

Until recently, maintaining this balance often meant trade-offs. Teams had to choose between a fragmented storage setup or overexposing data just to keep their workflows running smoothly.

Read on to see how this works.

Leave a Comment

Thoughts on Renaming sa

Andreas Wolter asks, what is in a name?

This is another one of those subjects that keep circulating: should you rename your sa account?

Plenty of “security check” scripts swear you should. Meanwhile, when you talk to actual humans in the real world, you’ll notice that almost nobody does it. (Funny how that works.)

So what does Sarpedon Quality Lab® recommend – and why? Our answer (read to the end) may surprise you.

Before reading Andreas’s post, I wanted to note that, when I was a DBA and had control of such things, I would actually rename the sa account and then create a separate account called “sa” with zero permissions, not even the ability to connect. I never considered it a critical part of a security posture, but knowing how many scripts try to brute-force an account called sa, I figured setting up a false front like that would add some protection on the margin.

After reading Andreas’s post, I wasn’t aware that doing so would break replication, though it makes sense because I wasn’t using replication at that time. Making sa’s password extremely long is also a good idea.

Leave a Comment

Access S3 Buckets in VPCs in Fabric via Entra Integration

Premal Shah announces new functionality in preview:

When we first introduced Amazon S3 shortcut integration with Microsoft Entra ID, customers gained a powerful new way to connect S3 data to Microsoft Fabric — without storing or rotating AWS access keys. Using OpenID Connect (OIDC), Fabric authenticates directly with AWS Identity and Access Management (IAM), enabling secure, identity-based access to cloud storage.

However, many enterprises keep their S3 buckets locked down inside Virtual Private Clouds (VPCs) or behind corporate firewalls. In these environments, Entra OIDC can authenticate identities, but it cannot provide network access — so Fabric still cannot reach the S3 endpoint. That changes today.

Read on to see what has changed, how you can enable this functionality, and current limitations.

Leave a Comment

Column-Level Encryption in SQL Server

Greg Low provides a primer:

Way back in SQL Server 2005, Microsoft introduced an amazing array of technologies. I suspect that many SQL Server professionals aren’t aware of just how many technologies were introduced in that release. It’s not surprising that professionals are still learning about a number of these technologies, even 20 years later. In particular, questions regarding certificates, keys, and column-based encryption still draw blank responses from most SQL Server professionals.

What’s interesting is that, as far as technologies like Always Encrypted have taken us, one of the first things to get support in new twists on SQL Server (e.g., Synapse, Fabric) is column-level security.

Leave a Comment

Power BI Build Permissions

Chris Webb explains what the Build permission actually does:

If there is sensitive data in your Power BI semantic model that you don’t want some users to see then you need to use row-level security or object-level security to control access to that data. You’re an experienced Power BI developer – you know that, right? But what about Build permissions? If an end-user only has access to a report you’ve built and doesn’t have Build permissions on the underlying semantic model, and if there’s no other security on the semantic model, can they access data in the semantic model that isn’t visible in the report? The answer is potentially yes: you can’t rely on Build permissions for security.

I’ve found that the best method of security is never deploying products to begin with. Also, never using a computer.

Leave a Comment

What’s New in OneLake

Kim Manis shares an update:

In this blog post, I’ll highlight the new zero-ETL, zero-copy sources in OneLake, deeper interoperability between OneLake and Microsoft Foundry, and new tools to help admins manage capacity, security, and governance at scale. Together, these updates further cement Fabric as the ideal data platform for your mission-critical workloads—open, integrated, secure, and built to connect every part of your data estate to the intelligence your business needs. 

Read on to see some of the latest from Ignite.

Comments closed

Thoughts on OneLake Security

Reitse Eskens troubleshoots an issue:

Today was a very interesting day at a customer’s site, where I had some trouble determining why the OneLake security wasn’t functioning as I expected. Spoiler alert: a part was me, and a part had to do with setting up my testing account.

Click through to see what happened and for two Fabric Ideas to improve how column-level and row-level security work.

Comments closed

Exploiting Database as a Service SQL Server

Fabiano Amorim has a post-mortem of a nasty privilege escalation bug in SQL Server:

This article explores a serious flaw in this security model – a SQL Injection vulnerability in sys.sp_help_spatial_geography_histogram that allowed a standard user on managed SQL Server instances (AWS, GCP, Alibaba, Azure) to completely bypass these restrictions, gain access to privileged user data, and decrypt the source code of internal management stored procedures.

It was fixed in SQL Server 2022 CU20 (KB5063814), but this article explains how the exploit worked and the process of eliminating it.

Click through for the details and make sure your on-premises SQL Server instances are patched.

Comments closed