Voice of the DBA

Tag: encryption

  • Badly Encrypted Databases

    I ran across a blog about encrypted databases linked from Bruce Schneier’s blog. I follow his musings and writings on security ,and he recommended we read it with this sentence: “Even the summary is too much to summarize, so read it.” Good enough for me, so I clicked the link and read about encrypted databases.

    I like the idea of stronger encryption in databases, and I’ve given a few talks on the subject. At times there are attendees that will debate that encryption in the database doesn’t do a lot of good. Often they dismiss the idea of TDE, since administrators can still read the data and break the encryption, and normal users aren’t affected. Many also note that database encryption does nothing for data on the wire, which is true. Most people want to do the encryption and decryption on the client, which has other challenges and is fairly hard to do well.

    I think that security a series of layers, and as noted by the author of the blog, most criminals are lazy. If they can copy a backup file or data file, they’ll just do that and read the data. TDE isn’t perfect, but it does limit these simple attacks. Always Encrypted was developed to try and make it easy to include encryption from the client side, but in SQL Server 2016, it has lots of limitations. In SQL Server 2019, we get secure enclaves, which should help adoption somewhat, but we will see once developers start to experiment with the feature.

    The blog talks about problems with encryption, spending quite a bit of time on approximate database reconstruction, which is essentially guessing data values with some information and by watching queries and results. It’s somewhat fascinating, and also scary, but complex and likely requiring lots of queries. To me, this is an area we ought to focus, and really an area that all our protocol libraries and possibly database firewalls (or built in limits) ought to focus efforts. We shouldn’t be most clients to make large queries of all data in a table. Really at this point, we ought to have build in limitations of queries to ensure that users are exporting all data from a table. I’d like some throttle that might prevent the return of very large result sets to clients.

    At the same time, there ought to be some way to analyze the queries coming in and see if an attacker is “guessing” values. I won’t pretend to know how we might do this, but it would seem that in the same way we detect lots of login attempts, we could have some alert being raised when we had xxx of the same type of query in yyy time. That might alert us to potential problems.

    Or users running lots of searches.

    I don’t know the best way to protect data, but I do know that too many of us aren’t doing a good job of this. We need to get better, both in production and development environments. We need to be better at protecting databases and the data within them.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 5.0MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • The Worst Data Breech

    I noticed this week that Australia passed a law that requires companies to hand over user information, even if encrypted. Quite a few articles that point out this might require backdoors to be created in communication systems to comply with the law. Companies are required to provide plain text user communication if they can, or build tools to allow this if they do not have the capability. The proponents of the bill argue this is necessary for criminal prosecution.

    Perhaps they are right, but if this capability is required, this means that either companies will have backdoors built into their products that allow them to decrypt things you might have expected to remain encrypted. That’s disconcerting to me, not because Apple, Google, or someone else might read my communications, but because no company has really proven they can protect all the data they store.

    Can you imagine how many malicious actors might spent their efforts trying to find those backdoor encryption keys? What if there aren’t backdoor keys, but companies decide to build some sort of key logger into software that copies data before it’s encrypted. Can you imagine how problematic it might be to secure that data?

    I’m also concerned because this would mean that there could be a few keys that can be used to get access to encrypted data, something like “master keys” in door locks. In this case, the loss of a key might mean problems for huge numbers of people. The other option would be lots of backdoor keys, potentially a different one for each customer/device, in which case we have a large data set that I’m sure will get leaked. At that time, how likely will it be that we’ll be able to implement new keys for large numbers of people?

    I sympathize with law enforcement. In some ways, their jobs are much harder. In others, however, I think they have many more tools, and the need to weaken encryption doesn’t seem to be necessary. Many of us have a need to secure data, to protect it from unauthorized access. At a time when security is proving to be a challenge and record numbers of data breeches are occurring, do we really want tech companies to start building products with less security? I don’t.

    Steve Jones

     

  • TDE and DDM

    Someone asked a question about TDE (Transparent Data Encryption) and DDM (Dynamic Data Masking), which are two different technologies that are in the security area. As I’ve mentioned in the Stairway to Dynamic Data Masking, DDM is not a security technology. It makes programming some obfuscation easy, but it’s not really security. It can be easily bypassed.

    In any case, how do these work together? Or do they work together? Good questions, and I’ll answer them.

    First, TDE is a technology that encrypts your data at rest, meaning when on storage devices. This handles the encryption and decryption as data is read or written from storage, without coding for it or the user having to do anything.

    DDM is a technology that takes results from a query and replaces some of the data with masked values. This works in memory, after a query runs. Query processing, with WHERE, GROUP BY, etc. clauses is not affected by DDM.

    These work together since data is encrypted on disk. It is read into RAM and decrypted. The query processor then assembles some of this data into a result set. Once this is done, before the results are sent to the client, DDM will make data.

    Demo

    I’ll setup TDE and then add DDM and run a query. Here’s a quick table and enabling TDE:

    CREATE DATABASE TDE_Primer;
    
GO
    
-- create and populate a table
    
USE TDE_Primer
    
go
    
CREATE TABLE MyTable
    
( myid INT
    
, myname VARCHAR(20)
    
, mychar VARCHAR(200)  
    
)
;
    
go
    
DECLARE @i INT = 65;
    
WHILE @i < 92
      begin
       INSERT mytable SELECT @i, 'Steve Jones', REPLICATE(CHAR(@i), 200);
       SELECT @i = @i + 1;
      END;
    
GO

    From here, let’s enable TDE. If you have a master key in the master database, you’ll get an error, but it won’t really affect things.

    CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'AlwaysU$eaStr0ngP@ssword4This';
    
go

    -- create certificate to secure TDE
    
CREATE CERTIFICATE TDEPRimer_CertSecurity WITH SUBJECT = 'TDE_Primer DEK Certificate';
    
go
    

    
USE TDE_Primer;
    
GO
    
-- Create DEK
    
CREATE DATABASE ENCRYPTION KEY
    
WITH ALGORITHM = AES_128
    
ENCRYPTION BY SERVER CERTIFICATE TDEPRimer_CertSecurity;
    
GO
    ALTER DATABASE TDE_Primer
       SET ENCRYPTION ON;
    
GO

    Once this is done, let’s alter our table. We also need a user that isn’t privileged.

    ALTER TABLE dbo.MyTable ALTER COLUMN myname ADD MASKED WITH (FUNCTION = 'partial(1,"XXX",0)')
    
GO
    CREATE USER JoeDBA FROM LOGIN JoeDBA
    

    GRANT SELECT ON dbo.mytable TO JoeDBA

    Now we can check the execution of a query.

    2018-11-14 10_37_40-Microsoft Edge

    Masked data with TDE.

  • A Tour of SQL Server Security Features

    Abstract

    Protecting data from unauthorized access becomes more important all the time. SQL Server includes a number of features that make data protection and security easier for developers and DBAs with a framework for protecting data. Come learn how Always Encrypted, TDE, Row Level Security, Dynamic Data Masking, and column level encryption can protect your systems.

    You will learn:

    • About the different encryption and security features in SQL Server
    • Understand the code changes required for encryption mechanisms
    • Gain a basic understanding of RLS and DDM, which do not require code changes to help protect data

    Level: 100

    Demos

    This talk includes the following demos

    • Always Encrypted setup and data access
    • Row Level Security setup and use
    • Dynamic Data Masking for users
    • Column Level Encryption implementation
    • TDE setup and verification