Press "Enter" to skip to content

Category: Security

PostgreSQL Sans Superuser in v16

Robert Haas doesn’t wear a cape:

As I’ve written about before, a PostgreSQL superuser always has the ability to take over the operating system account in which PostgreSQL is running, but sometimes you’d like to have a role that can administer the database but not break out of it. In existing releases, there’s no good way to accomplish that. You can either make a new role so weak that it can’t perform ordinary administration tasks, or you can make it so strong that it can easily break into the operating system account and thus take over the superuser role as well. Unless you hack the source code, which some people have done, there’s no real way to set up an account that has enough power to usefully administer the database in meaningful ways but yet not enough power to take over everything. I’ve committed a number of patches to v16 to try to improve the situation, and I think that we can look forward to big improvements in this area once it is released.

Read on for some of the implications of this change.

Comments closed

Roles and Privileges in Postgres

Ryan Booz gives us an introduction to Postgres security:

Recall that in PostgreSQL both users and groups are technically roles. These are always created at the cluster level and granted privileges to databases and other objects therein. Depending on your database background it may surprise you that roles aren’t created as a principal inside of each database. For now, just remember that roles (users and groups) are created as a cluster principal that (may) own objects in a database, and owning an object provides additional privileges, something we’ll explore later in the article.

For the purposes of this article, all example user roles will be created with password authentication. Other authentication methods are available, including GSSPI, SSPI, Kerberos, Certificate, and others. However, setting up these alternative methods is beyond what we need to discuss object ownership and privileges.

Read the whole thing if you’re doing anything with Postgres.

Comments closed

Securing Temporal Tables

Daniel Hutmacher does a little locking down:

You may have already discovered a relatively new feature in SQL Server called system-versioned temporal tables. You can have SQL Server set up a history table that keeps track of all the changes made to a table, a bit similar to what business intelligence people would call a “slowly changing dimension”.

What happens behind the scenes is that SQL Server creates a separate table that keeps track of previous versions of row changes, along with “from” and “to” timestamps. That way, you can view the contents of the table as it was at any given point in time.

But how to you version the contents of a table, while hiding things like deleted records from prying eyes?

There’s not a whole lot we can do, but Daniel shows what we are able to do.

Comments closed

Networking Options with Azure SQL DB

Deepthi Goguri looks at four options:

Securing data in Azure is an important part and there are different security layers available in Azure. Below diagram shows you the different layers of Security we have in Azure to reach the customer data.

In this post, let’s focus on the Network security.

Click through for a table covering the four options in the columns list and a quick comparison of the highlights in the rows. Private link is definitely the best corporate option, though it also requires a fair amount of preparatory work.

Comments closed

Comparing Encryption Options in SQL Server

David Fowler has a table for us:

The question of encryption seems to be coming up a lot recently. I’ve had a number of people asking me about how to go about encrypting SQL Server.

SQL can encrypt our data at a number of different levels and gives us a quite a few options when doing so. I want to use this post to put together a matrix so you can easily see which method of encryption suits your purpose. I’ll look in to each method in more detail in a future series of posts.

Click through for a rather comprehensive table and remember that “several of these all at once” is usually the correct answer for which to choose.

Comments closed

The Cost of Ignoring GDPR

Matthew McGiffen looks at the fines:

The biggest fines (both individually and in total) have been levied for improper use of data, with Amazon, WhatsApp, Google and Facebook topping the list. After that though we have fines for insufficient protection of data. In most cases this is where companies have had some form of data breach and the safeguards in place weren’t deemed sufficient. The largest fine in this case was against British Airways who were hacked in 2018 and they received a fine of over 22 million euros for the lack of safeguards. That was calculated as 1.5% of the company’s turnover in 2017.

Read on for a summary of fines by violation type, more detail, and a link to the core data.

Comments closed

Securing the Root Keys when using TDE

Matthew McGiffen puts the keys behind lock and key:

In this quick post we’re going to look at an additional step you should take to secure your TDE databases. This is a step you won’t find in any other documentation on setting up TDE in SQL Server that I’ve seen, so it probably bears a little explaining.

Matthew has solid advice, though if someone does get the Local Admin credentials (e.g., through a spearphishing attack), that person could still eventually gain access to the underlying data. I get that at some point, things will break, so it’s mostly a matter of being aware what can cause that break and minimizing the likelihood of it occurring.

Comments closed

Setting Up Transparent Data Encryption

Matthew McGiffen enables transparent data encryption on a database:

Transparent Data Encryption (TDE) is one of the easiest ways of encrypting your data at rest. In the previous posts we looked at what TDE is and how it works.

In this post we go through the steps of setting TDE up. You can set up TDE when you first create a database (which we will look at in this post), or you can apply it to an existing database (which we’ll cover in posts I’ve got coming up). In the latter case, once TDE has been enabled it will encrypt your existing data in the background. In either case the steps are the same.

Read on to see what you need to do.

Comments closed

Using Managed Identities with Azure Functions

Dennes Torres takes us through the proper use of managed identities:

Let’s talk about authentication between Azure Functions and resources used by Azure Functions and conclude with many poorly documented secrets about how to use User Assigned Managed Identity. When we build Azure functions, they usually need to authenticate against other Azure resources: Azure SQL DatabaseStorage AccountsService Bus and many more.

Each of these services have an authentication that we can call “Meh!”: Azure SQL has SQL Standard Logins, storage accounts have SAS tokens, service bus, shared access keys and so on. These are not the safest methods possible. If the key leaks, you will have a security problem because anyone with the key will be able to access the resource.

There are multiple solutions for this problem, some of them would pass through Key Vault, used to store secrets, keys and passwords. But let’s go directly to the best one: Remove the usage of keys at all. 

Read on to learn how.

Comments closed