Press "Enter" to skip to content

Category: Security

Four Years of sp_CheckSecurity

Published 2026-11-11 by Kevin Feasel

Jeff Iannucci reflects on a tool:

In recent weeks I’ve been conducting a bit more of our own internal SQL Server Security Checks than usual for our clients. This shouldn’t be a surprise, what with all the stories about “rouge AI” breaches and with Microsoft releasing A LOT more security fixes in their recent Windows and SQL Server updates.

In all these Security Checks we use our sp_CheckSecurity stored procedure to collect a big chunk of the findings. I wrote the original version of this tool a while back, and out of curiosity I wanted to see how long ago that was. It turns out I created the first working version of the tool four years ago this week. Wow, four years! And the things that I have found using that tool could, as my late stepfather might say, make your eyes water.

Inspired by my colleague Andy Kelly’s post introducing the sp_CheckActivity tool that he’s been working on in various forms for years, I thought I would share a bit about the history and intention of sp_CheckSecurity in a similar manner.

Read on for its origin story. Between what Jeff has put together and what Andreas Wolter has created, there are two really good procedures for evaluating the security posture of a given SQL Server instance.

Leave a Comment

Reviewing the Always Encrypted Paper

Published 2026-11-10 by Kevin Feasel

Anna Hoffman continues a series on reviewing important academic papers in SQL Server’s history:

Encryption at rest solves one threat. It stops someone who walks off with the disk. It does nothing about someone with administrative access to the running server, because the database decrypts data into memory to do anything useful with it.

For a lot of workloads that gap doesn’t matter. For health records, financial data, or anything where the customer’s threat model includes the cloud operator, it matters a great deal.

Azure SQL Database Always Encrypted (SIGMOD 2020) describes how SQL Server runs real queries, including range comparisons and LIKE patterns, against data it never holds the keys to.

Read on for Anna’s thoughts about the paper, its claims at the time, and how Always Encrypted has changed (for the better) since the original paper.

Leave a Comment

Securing Microsoft Fabric Gen2 Dataflows API Keys

Published 2026-11-02 by Kevin Feasel

John Kerski saves some keys:

If you’ve ever developed a Gen1 dataflow to connect to an external API (Application Programming Interface), you know the awkward moment when you have to paste an API key into the Power Query script.

There it sits, in plain text, inside an artifact (the proper name for something like a semantic model, report or dataflow created in the service), with limited options for secret rotation or access control.

Thankfully, Gen2 dataflows improve the story considerably – especially when Azure Key Vault, Microsoft Fabric pipelines, and the newer parameters feature are combined.

In this guide, I’ll show you the pattern I now reach for when I need to pass API secrets into a Fabric Gen2 dataflow without leaving them in code or configuration.

Click through to see how.

Leave a Comment

Using Direct Lake across Public and Private Link Workspaces

Published 2026-10-29 by Kevin Feasel

Gilbert Quevauvilliers gets all of the data:

Currently in the Microsoft documentation it talks to not being able to connect from a Public Workspace to a Private Link workspace using DirectLake to a Semantic Model.

What this means in my mind is it is where it is a direct connection from a Public Workspace to a Private Link workspace

NOTE: A Private Link workspace is where inbound connectivity is blocked from the public internet.

In this blog post I am going to show you how to work around this, where at the end I will show you how you can still use DirectLake for a Semantic Model between a Public and Private Link Workspace.

Read on for the solution.

Leave a Comment

Using Managed Identities to Write Backups to Azure

Published 2026-10-16 by Kevin Feasel

Warwick Rudd continues a series:

In Part 1 we built somewhere safe to put the backups: a storage account with a delete lock and a container with a time-based retention policy.

The next problem is getting SQL Server to write to it without giving it a password. That’s what the Managed Identity is for. The VM gets an identity in Microsoft Entra ID, SQL Server uses it to authenticate to storage, and there’s no SAS token or storage key anywhere to steal, rotate or forget about.

There are a few moving parts to get there, and most of the time spent on this is in Entra ID and networking rather than SQL Server.

Read on to see what needs to happen.

Comments closed

The Power of Group Managed Service Accounts

Published 2026-10-14 by Kevin Feasel

John Sterrett gets rid of a password:

Somewhere in your environment, a SQL Server service account password hasn’t changed in years. Several people know it, and it’s probably in a script or a spreadsheet. I wouldn’t be surprised if someone hasn’t even put it in an AI chat.  Group managed service accounts (gMSAs) remove that problem.

This past weekend, during my Advanced Security Protection talk (online version you can watch) at Days of Data in Pittsburgh, someone asked: “What are the best practices for encrypting passwords in connection strings?” That reminded me I’m overdue to blog about Group Managed Service Accounts, so here we are, because the best way to encrypt them is to not need to encrypt them.

This does get a lot trickier if you’re not on Windows, and it does require Active Directory. But for most environments, gMSAs are an outstanding idea.

Comments closed

Securing Temporary Objects, Metadata Visibility, and Audit Assurance in SQL Server

Published 2026-10-12 by Kevin Feasel

Fabiano Amorim hits three topics:

Over the course of this series, I’ve challenged the common assumption that a SQL Server environment is safe simply because it’s patched, firewalled, and configured according to familiar defaults.

I’ve proven that this is not quite true, because real security is not a checkbox. It requires a verification mindset, especially in areas where SQL Server intentionally provides powerful operational features for DBAs, developers, monitoring tools, and application frameworks. 

In this guide, I’ll focus on three features that are easy to underestimate because they look like normal SQL Server behavior. They are global temporary objects, Dynamic Management Views (DMVs), and audit coverage – each a useful feature in their own right.

The other thing they all have in common? They can each become part of an attack chain if granted too broadly, used inside privileged workflows, or trusted without validation. 

Click through for Fabiano’s guidance.

Comments closed

SQL Copilot “Read-Only” Mode Wasn’t

Published 2026-10-08 by Kevin Feasel

Rebecca Lewis reads a CVE:

I was in Italy for a month. While I was gone, somebody got sysadmin out of SQL Copilot with a variable.

The vulnerability is CVE-2026-65669, the SSMS 22 Copilot bug I wrote about early September. The full write-up went public on September 30th, and the detail that stuck with me is how Copilot’s ‘read-only mode’ was enforced. It wasn’t a permission. It was a regex blocklist.

That blocklist is the same control we have watched fail against SQL injection for twenty years. Before I get to Copilot, let’s build one here and see it fail.

These sorts of blacklists almost never work against a committed attacker because, unless you fully enumerate the possible domain, there’s an opportunity for someone to slip through, and that’s exactly what happened here.

Comments closed

Securing MCP Servers Connected to a Database

Published 2026-10-06 by Kevin Feasel

Dejan Lukic shares some advice:

AI agents don’t ask permission before every query. Instead, they themselves decide which tools to call and chain together. That’s a fundamentally different risk model than traditional access control – and it’s exactly why MCP (Model Context Protocol) servers connected to databases need their own security playbook.

This guide covers the failure modes to watch for: confused deputy, token passthrough, prompt injection, over-scoped credentials, and session hijacking. Then, how to prevent those failure modes – using authentication, authorization, and least-privilege controls.

Treat them like any other often-confused employee. Which, in many environments, means making them sysadmins.

Comments closed

In-Memory DLLs and Digital Signatures

Published 2026-10-05 by Kevin Feasel

Emad Al-Mousa leaves a note:

While a valid cryptographic digital signature ensures the authenticity and integrity of a compiled binary, targeting dynamic database runtime components—such as In-Memory OLTP (XTP) directories—presents a severe attack vector if integrity controls are bypassed.

Because database services like SQL Server frequently operate under high-privilege service accounts (such as NT AUTHORITY\SYSTEM or a high-privileged virtual account), an adversary who achieves local administrative access could attempt to substitute or hijack dynamic runtime DLLs. A successful payload injection into the SQL Server process memory (sqlservr.exe) would inherit the service’s privileges, facilitating arbitrary code execution, local privilege escalation to SYSTEM, or the establishment of an outbound reverse shell.

Click through for a demonstration and Microsoft Security’s response.

Comments closed