Always Encrypted and Dynamic data masking are two important security features available in SQL Server 2016. Can both of these features co-exist on single database table.
If yes, what should be the order? Shall we perform masking on encrypted columns or shall we perform encryption on masked columns?
Using Always Encrypted with Dynamic Data Masking is currently not supported.
Always Encrypted does not support encrypting a masked column.
Always Encrypted encrypts the data on the client and sever never has access to the keys. hence, the server only has access to ciphertext for an encrypted. Hence for an encrypted column, the server will be unable to generated the masked values.
Related
My project has a requirement to encrypt a sensitive field column in SQL server table but the encryption/decryption key shall be kept outside SQL environment to ensure maximum data security.
Thycotic server is one secret server to store and secure passwords. I am trying a POC to check if encryption key can be generated via Secret server and can be used to encrypt table column in SQL server.
I haven't found much related to this on the Thycotic website or on google.
How can this be achieved if feasible?
I am undecided on two methods to hide data in a single column in SQL Server DB.
1. SQL Always Encrypted
2. SQL Dynamic Data Masking
After reading articles for both, my understanding is that Always Encrypted may be more secure than Dynamic Data Masking as the data stored is encrypted instead of the putting a mask on top of the password.
However, what are the impacts when it comes to daily usage in this scenario if the user simply wants to hide the password field from database administrators?
Data to be hidden: Password
Functions using Password column: Reset password, change password, insert new password row when creating new user
Any advice would be appreciated.
P.S. My initial plan was to use SHA1+Salt hashing to password fields and storing hash values instead of password. However, if the requirements are simply to hide the field in DB, I find that the other 2 methods above may be sufficient.
If you want to hide the PW from the DB administrator, then dynamic data masking is off the table. This simply masks it at the presentation layer.
AlwaysEncrypted moves the responsibility of encryption to the client application, meaning the encryption and decryption is handled outside of the application, leaving the data unreadable to the database administrator generally speaking.
So, it depends on your definition of hiding. If you want it hidden from administrators... Always Encrypted is where you need to focus.
EDIT
Always Encrypted is only available in 2016 for starters, but column level encryption has been available since 2005. But to answer your question, no, the DBA doesn't have to have the keys to the kingdom. AE was designed to handle the encryption and decryption at the driver level. The information below is from the official 70-764 exam reference by Victor Isakov:
At a high level the AE architecture works as shown in Figure 1-5:
The client application issues a parameterized query. It uses the new Column Encryption Setting=Enabled; option in the connection string
The enhanced ADO.NET driver interrogates the database engine using the [sp_describe_parameter_encryption] system stored procedure to determine which parameters target encrypted columns. For each parameter that will require encrypting the driver retrieves the encryption algorithm and other information that will be used during the encryption phase
The driver uses the Column Master Key (CMK) to encrypt the parameter values before sending the ciphertext to the database engine.
The database engine retrieves the result set, attaching the appropriate encryption metadata to any encrypted columns, and sends it back to the client application. The data is encrypted both at rest within the database and in flight from the database engine to the client application.
The client application’s driver decrypts any encrypted
Under no circumstances should the password ever be stored on a database table, or anywhere for that matter, period.
You should hash the password and store the hashed value. Consider using SHA 2, or higher, with salting.
See NIST for more details: https://csrc.nist.gov/Projects/Hash-Functions
SQL Server 2008+ supports up to SHA2-512:
https://learn.microsoft.com/en-us/sql/t-sql/functions/hashbytes-transact-sql?view=sql-server-2017
DECLARE #HashThis NVARCHAR(4000)
SET #HashThis = CONVERT(NVARCHAR(4000),'dslfdkjLK85kldhnv$n000#knf');
SELECT HASHBYTES('SHA2_512', #HashThis);
To see how the password can be salted, see the article below. It is worth pointing out that hashing and salting should be handled at the application layer because the DBA can see the password that is being salted in SQL Profiler. Be very careful.
https://www.mssqltips.com/sqlservertip/3293/add-a-salt-with-the-sql-server-hashbytes-function/
Additional Info:
https://www.mssqltips.com/sqlservertip/4037/storing-passwords-in-a-secure-way-in-a-sql-server-database/
Final point: If, by any chance, you are performing this exercise as a means to authenticate users in a web application, then you should look for authentication modules for the specified application framework. For example, ASP.NET comes with Microsoft's Identity 2.0 system, which handles the authentication process end-to-end.
https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-2.1&tabs=visual-studio
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 am using ACCDB with SQL Server linked tables.
I have a table with a Numeric column, primary key and an identity column.
But when I link it to Access database, it is getting converted as Number and not Auto Number.
Any thoughts how to correct this?
An autonumber in Access is actually a long integer (int in SQL Server), with an additional property creating an autonumber. If your SQL Server data type is actually numeric, I don't see how Access can recognize it as an autonumber. When using Access as a front end to SQL Server, it is best to use data types that Access easily recognizes.
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