Does anyone know if a field encrypted with an Symmetric key would be the exact same output on different servers given the same cert master key and key credentials?
I want to do a bulk copy from dev to test servers and want to know if the encryption would carry over.
Create Symmetric Key on MSDN
Thanks!
For those that can't see I forgot a comma, to clear it up, a MASTER KEY, a CERTIFICATE and a KEY
given the same cert master key and key credentials
There is no such concept as 'cert master key'. Do not invent your own terms, stick to the existing nomenclature so everyone understands what you're saying. There is a master key, there are certificates.
If you followed good practices and you deployed a correct encryption hierarchy then your data should be encrypted with one or more symmetric keys and these in turn would be encrypted with a certificate that is either encrypted with the database master key or a password.
Copying data encrypted with a symmetric key between databases is possible. In order to succeed you need to follow exactly the steps described in Create Identical Symmetric Keys on Two Servers which will result in a pair of keys that have the same identity and the same key material. Data encrypted with either one of the two servers can be decrypted on the other server.
That being said, any organization that is serious enough about data as to encrypt it in production and at the same time is willing to create a copy of the encryption key on dev machines, not to mention copy actual sensitive data to the dev boxes, is a joke imho. Technology is never the weak link.
Related
This is me learning using encrypt/decrypt in SQL Server and doing some testing to know what I can and can't do in some cases.
The case I am about to ask is about when I accidentally drop the symmetric key and no backup has been created or already lost.
I have tried to drop the certificate and master key, and both tests failed because some data are encrypted by them.
When I try to drop the symmetric key, I got no error, and the key was dropped successfully.
I have some data in a column with Column Level Encryption that is encrypted by the key that was dropped.
My question is, does SQL Server really not give out any error though I have data encrypted by the key?
And if for some reason I don't have the key's backup or lost the backup, is there any other way to decrypt the data encrypted by the dropped key, maybe using the certificate or the master key?
Any answer is appreciated.
Thanks.
I have a lack of understanding regarding a particular area of TDE within Microsoft SQL Server (in my case, SQL Server 2016). Specifically what certificates/keys are required to restore an encrypted database on another server.
Microsoft Docs highlight the encryption hierarchy, running from service master key, database master key, certificate and database encryption key. It highlights the necessity of creating backups of the certificate to prevent data loss. It doesn't really mention anything of backing up anything above the certificate in the hierarchy.
However a Redgate article describes backing up the service master key and database master key in addition to the certificate.
In practice I am able to restore an encrypted database on another server using only the saved certificate/private key.. so what am I missing? If the certificate is protected by a master key that is not available, how does it work? Is that part of the encryption 'internal-only' - if so is there any instance where I would need to restore the service master key or database master key from a backup? I suppose keeping a backup of those wouldn't hurt anyway?
Many thanks
I've successfully restored a TDE-encrypted database onto a server that has only the certificate that was used for TDE. Said another way, the destination server had neither matching a matching database master key (DMK) on the master database nor a matching service master key (SMK). So long as the DMK for the master database is encrypted with the SMK on the target and the TDE certificate's private key is loaded into master and encrypted with that DMK, you should be good to go.
But! For something like this, you shouldn't take my (a random guy on the internet) word for it. This fundamentally affects your ability to restore your database. Restore-ability is Job One™ for a DBA, you should try it and convince yourself that not only what I'm saying is true but also that you can do it.
Also, as part of that restore plan, take that certificate (along with its private key), back it up to disconnected media, and put it somewhere for safe keeping (I like to give it to the legal department).
What is the difference between using SQL Server SSL (Encrypted=true in the connection string) + TDE, vs using SQL Server Always Encrypted?
With regards to RGPD, is one more adapted than the other?
Always Encrypted exists to solve more than just the issue of making sure data is encrypted in-transit. In fact, that's not even the primary concern that Always Encrypted solves.
The big issue that Always Encrypted solves is that with Transparent Data Encryption (TDE), the keys and certificates which secure the encrypted data are themselves stored in the database. This could be a concern for someone considering putting their SQL Server database in the cloud, because the cloud provider then ultimately has the secrets for decrypting the data.
With Always Encrypted, the Column Encryption Key (CEK), which is used to encrypt/decrypt column data, is stored in the database in its encrypted form. But here's the kicker - the key used to encrypt/decrypt the CEK is stored outside the database, leaving the database unable to decrypt the data on its own.
All the database can do is
Provide the encrypted CEK,
provide the location of the CMK, and
serve/store pre-encrypted data.
It's up to the client to get the Column Master Key (CMK) from the key/certificate store wherever that's located, then use the CMK to decrypt the CEK, and use the decrypted CEK to encrypt/decrypt data.
So that's the conceptual difference. Here are a couple pages that go into the details of it:
Overview of Key Management for Always Encrypted (Microsoft docs)
SQL Server Encryption: Always Encrypted (Redgate article)
Be aware that Always Encrypted comes with some hefty drawbacks with regard to querying data and other things. This article gives a pretty good list of limitations. Some of these drawbacks can be mitigated using Always Encrypted with secure enclaves.
I would be using shared hosting for my SQL Server. I wanted to encrypt the primary key column(auto generated ID) and a varchar column. I searched around and came across TDE. But, being a shared hosting, i cannot use it. So, was looking for any alternatives. The data is already there in the tables, so encrypting from application is not possible now. And there are many SQL statements that search using the above said varchar column. So, performance is also a concern.
Thanks,
Dev
encrypt the primary key column(auto generated ID)
And how will you be able to find a record if its ID is encrypted?? Answering 'I serach by encrypted ID' disqualifies you for not salting the key...
And now for the real issue. You said that you'll be deploying on shared hosting, but you do not mention what kind of protection are you expcecting that ecnryption will provide. The problem is key management. Data will be encrypted with a key and the server will need to decrypt that dtaa somehow. No matter how you turn the problem arround, the root key used to decrypt all the other keys will be also on shared hosting, and hence you will not achieve anything but a slight bump on the road to your data. To put up a fence, the key must be retrieved somewhere from ouside the scope of the shared hosting, eg. your applicaiton will ask for the password to decrypt the root key when interacting with the users, which is by all practical means impossible. Note that
TDE would had solved nothing since the root of trust has the very same problem in TDE or in columnar encryption. If you need privacy, use private hosting.
And to answer the question:
to encrypt data you use ENCRYPTBYKEY.
to decrypt data use DECRYPTBYKEY
the encryption key should be encrypted with a certificate and the certificate should be encrypted with a password, or with the database master key. See Encryption Hierarchy.
you open the encryption key in the session using OPEN SYMMETRIC KEY
you open the master key in the session using OPEN MASTER KEY
you search encrypted dtaa by creating a hash and searching the hash, see Indexing encrypted data
And if you use columnar encryption you never encrypt the primary key. Doing so is completely non-sensical. And claiming any sort of privacy in shared hosting environment is a pipe dream. The only thing you could protect agfainst, at best, is accidental media loss (the hosting HDD turning up at a flea market).
Dev,
I think in your case the only choice is to encrypt from application.
Alternatively you can rename your table, substitute the VIEW instead of renamed table. Encrypt all existing data:
update real_table set field1 = call_encrypt_function(field1), field2 = call_encrypt_function(field2)
In that view you can do select call_decrypt_function(field1),call_decrypt_function(field2) from real_table. For insert and updates you need to master INSTEAD OF INSERT and INSTEAD OF UPDATE triggers. Of course you need to use WITH ENCRYPTION for that objects. I saw that approach in XP_CRYPT, however I prefer free solutions. SQL Server provides basic encryption functions for free.
I need to encrypt several columns in a database.
Do I create one certificate and a symmetric key for each column or one certificate and one symmetric key per column.
What is the best practice?
Where is the data coming from? If you have an application, especially a web based application you should encrypt the data prior to transmitting it.
Have you thought about using SQL Server's Transparent Data Encryption (TDE)?
In my experience with MS SQL 2008 cell level encryption, you need to set up a master key for your database, create a certificate for your database, and based on that certificate a symmetric key that you will use to encrypt cell level data.
Columns for which you want to encrypt the data on have to be of one of type VARBINARY (or two others: I believe VARCHAR, and NVARCHAR, but I'm not certain). There is also a specific method of inserting/updating data in these columns, as well as reading data from these columns.
We're currently storing a few selected columns of sensitive information encrypted in this manner in VARBINARY(256) columns, along with TDE on top of our database.
More information and helpful tutorials can be found here:
http://www.sqlservergeeks.com/articles/sql-server-bi/19/cell-level-encryption-in-sql-server
http://blogs.technet.com/b/keithcombs/archive/2005/11/24/415079.aspx