Category: Security

Jeff Iannucci continues a series on security in SQL Server:

SQL Server logins are often necessary, like the sa login, but be aware they present a particular set of vulnerability issues. Their lack of multifactor authentication, their susceptibility to brute force attacks, and the dumb passwords folks give SQL Server logins make them a prime target for hackers.

Read on to learn more about these three issues. Jeff also includes a note about a built-in function that lets you compare the hashed passwords in your systems versus a specific password, with the idea that you can at least find if people are using some of the most common passwords.

Comments closed

David Seis has some advice:

Roles play a crucial part in managing permissions and access control. One such role that often gets overlooked is the public role. This role, by default, has minimal permissions and every database user is a member. Sometimes, however, there are permissions granted to the public role which puts your data at risk.

David’s focus is not adding new permissions to the public role. I also recommend not taking permissions away. Some security tools will gripe that the public role has CONNECT access. I was foolish enough to follow those tools’ recommendations once and removed CONNECT from public. Then I got a bunch of calls about people not being able to log in… I suppose you can spin a yarn about how there are logins that a person should not be able to use for connections, but how often is that really the case?

Comments closed

Pieter Vanhove explains what secure enclaves are and why they’re useful:

Encryption is a vital technique for protecting sensitive data from unauthorized access or modification. SQL Server and Azure SQL Database offer two encryption technologies that allow you to encrypt data in use: Always Encrypted and Always Encrypted with secure enclaves. In this blog post, we will compare these two technologies and highlight their benefits and limitations.

Read on to learn more.

Comments closed

Jeff Iannucci talks about a role that might as well be sysadmin:

Based on the name, you probably can guess that members of the securityadmin role can make dangerous changes to the permissions of other server principals. What many folks don’t realize is that this role is simultaneously less dangerous and more dangerous than you might think.

Allow me to explain, or better yet show you what that means.

Click through for the explanation.

Comments closed

Jeff Iannucci has a series on security in SQL Server:

The CONTROL SERVER permission has been around since SQL Server 2005, and is the most powerful permission granted as part of membership in the sysadmin role. What many folks don’t realize is that this permission can be granted to a login or group without including them in the sysadmin role. And that can become problematic if, as an administrator, you aren’t aware of logins or groups that don’t have this permission.

Jeff points out how CONTROL SERVER isn’t quite the same as sysadmin, but why you should still treat it that way.

Comments closed

Umair Shahid goes through the list:

For any financial company that handles sensitive data as part of its operations, the protection of personally identifiable information (PII) is paramount. With the increasing frequency and sophistication of cyberattacks, it is crucial for these companies to implement robust security measures to safeguard PII.

This includes ensuring that even in the event of a breach, unauthorized individuals cannot read or misuse the data. One of the most effective ways to achieve this is through the encryption of data both in motion and at rest.

This blog will delve into the importance of encryption, the methods used to secure data in PostgreSQL databases, and the compliance regulations that mandate these practices.

Click through for the article. The set of capabilities are rather similar to what we have in SQL Server as well.

Comments closed