Press "Enter" to skip to content

Category: Security

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.

Leave a Comment

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

OneLake Security and the Fabric SQL Analytics Endpoint

Freddy Santos takes us through the latest with respect to security in OneLake:

OneLake Security centralizes fine-grained data access for Microsoft Fabric data items and enforces it consistently across engines.
Currently in Preview and opt-in per item, it lets you define roles over tables or folders and optionally add Row-Level Security (RLS) and Column-Level Security (CLS) policies. These definitions govern what users can see across Fabric experiences.

Read on to see what you can do.

Comments closed

Updates to sp_CheckSecurity

Jeff Iannucci has been busy:

It’s been a while since we made some improvements to the public version of sp_CheckSecurity, but internally we’ve been busy fine tuning checks and adding even more to discover potential vulnerabilities in your SQL Server instances.

Today we’re announcing a new version that includes additions, corrections, and a few other adjustments that should be helpful. Here’s what new!

Read on to see what has changed.

Comments closed