Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Encryption: Going from appliance to native Expand / Collapse
Author
Message
Posted Thursday, August 21, 2014 2:58 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Yesterday @ 2:33 PM
Points: 3, Visits: 142
Hello All,

I have been tasked with getting a number of databases off a SafeNet appliance and use native SQL Server for encryption on a few columns. The applications for these databases currently use a view to access the data. In order for me to make this as seamless as possible I would need to replace the view with some kind of auto decryption for specific users only. I've kicked around some ideas such as using DECRYPTBYKEYAUTOCERT in the view and having the password parameter call a function that validates the user and returns the password but even encrypting the view/function is vulnerable as local encryption of these objects is weak. I'm guessing I will need to implement some outside code, perhaps via CLR. I suppose I could delve into the route of locking down the view/function to everyone else but that doesn't stop someone from just adding a new account with access.

Here are a few details:
1. The applications will continue to access the data from a view as they do today. No changes to the application, such as opening keys, will be made.
2. Only users configured by the DBA can decrypt the data automatically. There are also a number of accounts that are sysadmins on the instance that I would need to block.
3. Nobody outside of the DBA team will know the passwords to any certificates/keys.
4. We need to be able to rotate the certificates/keys.

Current process used by the SafeNet appliance:
1. Application uses a view that references the SafeNet view.
2. The SafeNet view pulls the same data but for the columns to decrypt it calls a function that receives user/database info along with the encrypted data.
3. The function called by the SafeNet view passes the user/database info with encrypted data to a CLR.

In all, the goal is to get off the appliance with as little effort/impact outside of the DBA group and without spending money on some other solution. Personally I haven't done any development in Visual Studio since college but if I have to go that route then so be it.

Any help/tips/advice will be greatly appreciated.
Post #1606025
Posted Thursday, August 21, 2014 7:48 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 8:07 AM
Points: 35,272, Visits: 31,764
jiffy_79 (8/21/2014)
2. Only users configured by the DBA can decrypt the data automatically. There are also a number of accounts that are sysadmins on the instance that I would need to block.


Not possible without taking the "SA" priv away from them. In the same vein, you need to fix that problem even if you don't do the migration. No one outside of the DBA group should have any higher than "DBO" and you should be ultra stingy even with that priv. NO public facing application should have any higher than Read/Write/Execute privs.

Unrealistic in most shops but certainly attainable, my personal Nirvana would be that no application would ever have more than PUBLIC privs with exec privs on the stored procedures that the app needs to execute. Of course, that also means no ORMs or embedded SQL.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1606088
Posted Friday, August 22, 2014 3:34 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 6:36 AM
Points: 6,423, Visits: 13,818
the users should just require the relevant permission on the cert itself

-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs"
Post #1606163
Posted Friday, August 22, 2014 6:50 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Yesterday @ 2:33 PM
Points: 3, Visits: 142
The applications themselves or their accounts only go as high as dbo in the databases. However, for other reasons there are accounts that have sysadmin access that are not tied to the applications at all.

So if I were to create the certs/keys/views and explicitly deny access it would have the desired result. My only concern is that someone at the sysadmin level could create another sysadmin account which by default would have access. Is there a way to make the default permssion for an object 'deny'?
Post #1606253
Posted Friday, August 22, 2014 7:12 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Yesterday @ 2:33 PM
Points: 3, Visits: 142
I'm thinking my two best option are:

Remove sysadmin access and lock down the views/functions/certs/keys
or
Get some kind of external solution programmed

As you mentioned I'd rather get the sysadmin access toned down, time to do some digging on why there are in there to begin with....
Post #1606273
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse