Indexes and unique constraints on encrypted columns.

  • I've been searching around for a few weeks seeking information about how to handle protecting SSN data fields while still ensuring that they are unique and I haven't found anything that seems close.
    This seems like it should be a common issue with many DBAs who have SSN or similarly sensitive data items that need to be protected.  In our environment, developers have chosen to encrypt SSN columns in various tables where they are stored.  Previously, we had a clustered index built over the SSN column, but that turned out to be a bad choice once the SSN columns were encrypted.  We've also found that we cannot place a unique constraint on the SSN column in one table because the encryption always seems to generate a unique encrypted value in that column.  It was discovered this week that the unique constraint was in fact allowing duplicate SSNs to be entered into the table.

    So now I'm back at my starting point trying to figure out how we can ensure that duplicate un-encrypted values aren't getting placed in the table.

    Has anyone solved this issue yet?  Can you share what you did?

    Many thanks in advance!

    Larry

  • You have posted in a SQL Server 2016 forum, so I would suggest looking at Always Encrypted.  I am currently working on a POC that will explore this technology.  Just waiting for the developer to get to a point where she can participate.

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply