in my database i used database column encryption using symmetric key. I followed this tutorial http://blog.sqlauthority.com/2009/04/28/sql-server-introduction-to-sql-server-encryption-and-symmetric-key-encryption-tutorial-with-script/ . it uses symmetric key and it is not visible to others. But a database admin can see the encrypted column by executing query that calling symmetric key.
USE EncryptTest
GO
OPEN SYMMETRIC KEY TestTableKey DECRYPTION
BY CERTIFICATE EncryptTestCert
SELECT CONVERT(VARCHAR(50),DECRYPTBYKEY(EncryptSecondCol)) AS DecryptSecondCol
FROM TestTable
GO
I need a encryption in database level and database admin also should not able decrypt the column. is it possible in database level encryption?
If you don't want a DBA who is a member of the sysadmin role on that instance to have any access to the keys, then you cannot allow the database to do the encryption.
Even if you try using the PASSWORD option of CREATE SYMMETRIC KEY, the DBA can use Profiler to see the password inside of the SQL statements. The DBA certainly has access to the Master Key (and may already have a backup of it).
You will need to have your application do the encryption if you want to hide data from DBA's.
Or you can trust your DBA's with the data they're protecting.
Since this question was asked, SQL Server 2016 has been released and the Enterprise Edition contains a feature called Always Encrypted, which is design with a certificate in a client driver encrypting a column encryption key on the server that performs the encryption. I would recommend putting the "client" on a middleware server like IIS for websites and web services where the certificate can be better protected.
A second solution to encryption beyond the reach of the DBA is to introduce an Extensible Key Management system. Support for this is also an Enterprise only feature. An Extensible Key Management system is a separate expansion board or system interfaced with SQL Server to offload all key management and encryption processing that can be put under the administration of a different team than the DBA.
Third, you can design a solution which includes dropping the private key of the certificate and having it in a location that is not accessible to the DBA. When the private key is dropped from a certificate in an encryption hierarchy, then the data can only be encrypted.
Related
Edited based on comments.
My company is developing a system and is in the early design stages. I am the lead on the project. Some of the information to be stored in the system is highly confidential. The system must protect this information such that only authorized users have the ability to see this information. In fact, it is such that we want to protect it from ourselves even. The database to be used will probably be mySQL but does not have to be. I am aware that the data can be encrypted in the database. I am also aware that the software will have to be able to retrieve this data from the database for authorized users. I do not want any developers, including myself, to be able to decrypt and view this information -- in production -- but they do need to be able to view it during development(we will disable encryption during development).
The software will be a cloud based offering but will have an in house hosting option as well.
We can have a software based encryption and I realize that if software can get at the data then it's accessible - but I want this as tight as possible so that a developer cannot (including myself) view this data, but signed in, authorized users, can view it.
I'm stuck in my own thinking box about how to do this so I'm seeking advice as to how to secure this.
The client side will need a decryption key to decrypt the data. The software will have to allow access to this key for authorized users. The users cannot hold this key as the "client" devices could be virtually anything. Now I know I have no control over what the end users who have access do with the data, and that's not by concern. I want them to be able to store this information and have it secure in such a way that I cannot see it! I also do not want to have the ability to make myself authorized to see it - but to have that ability rest in the hands of a user side trusted administrator.
The data can be binary data. I do not want to encrypt the entire database, nor do I want to ever need to re-encrypt data because it can be huge amounts of data.
I have read posts about using GnuPG to handle this with public key for encryption and decryption via any one of a set of multiple private keys. This might be feasable for this but I'm looking for multiple solutions. My "issue" with this is the pass phrase protecting the private key and issueance of these private keys. I really don't want to user having to key in the passphrase associated with the private key every time that they login to the system or try to view the encrypted/protected data, but I don't want to store this passphrase anywhere a developer can see it either!
I understand about PKI but it doesn't offer protection from developers who can access the master decryption key which is shared using a public/private keypair.
I've edited the question with a proposed solution, please punch holes in it.
Development Language is C#. Microsoft supports asymetric keys which is what we want to use.
An X509 Certificate will be utilzied for the encryption keys. The public key will be stored in the database and used for all encryption. The private key will be stored in the database as well but encrypted using a passphrase entered by a trusted administrator. (This is the weak link in my mind, more on this later).
The administrator will create users who have access to the encrypted data. The users will be issued a copy of the private decryption key via the administrator and this key will be associated with their user account and encrypted in the system using their initial pass phrase.
When the user first logs in and is prompted to change their pass phrase, the private key will be re-encrypted using their new pass phrase. Their pass phrase is not stored in the database, only a hash for validation. Their keyed pass phrase will be encrypted using a timestamp or other data and will be stored on their local computer not on the server or in the servers identifable memory except when it is used for decryption of the private key. A software algorithm will be created to retrieve the decryption key for the encrypted master decryption key associated with this user.
Thus users can be created and revoked at the will of the administrator. Users can have their pas phrases reset - but in that case a new decryption key would need to be issued because the old one would not be decryptable any longer.
The one flaw I see, and I'm open to input, is if the administrator forgets their pass phrase and can no longer issue private keys. We could write code that given a users password, recovers the private key and encrypts it using the administrators new password when they enter it.
Another weak link is user pass phrase. If that becomes compromised then a developer could use that to obtain a copy of the private decription key and decrypt data.
Also - if for some reason an administrator needs to be let go we have the same issue as above where we don't have a copy of the private key accessible to share but we could get one using a users pass phrase.
Any advice on overcoming the perceived weaknesses?
We cannot tolerate exposure of the master decryption private key - if it is exposed then the entire database needs to be re-encrypted using a new keypair.
Thank you for your comments.
If you need to protect the data from yourselves, the only option is end-to-end encryption. User has a private key and it never leaves their computer. Devs/sysadmins never have private keys and can never decrypt.
This would require you make your client software source available to users so they can see that you are not leaking their info.
Use USB smart cards for easier/safer key management. They key is generated on the smart card and never leaves it. The smart card does the decryption on your apps behalf.
This make searching harder, but you can fix some of this by storing hashes along w the encrypted values, and searching on them.
Update, answering your questions in your comment:
Web based is not an option. You need a thick client
There is no "master key"
Please clarify "authorized user". Authorized by whom? Please provide an example.
Another option would be to skip encryption entirely and rely solely on access control. Use a db like postgresql, ms sql, or oracle that does row-level security. Don't give access to any one DBA. Give part of password to one dba, another part to another. DBA's need to be in same room to access the server.
Either way, you should be familiar with https://en.wikipedia.org/wiki/Secret_sharing
If you were to condider SQL Server instead of mysql, then the most secure design I can think of that meets your requirements is to require SQL Server Enterprise Edition an Extensible Key Management system that uses a Hardware Security Module. SQL Server Extensible Key Management enables the encryption keys that protect the database files to be stored in an off-box device such as a smartcard, USB device, or EKM/HSM module. EKMs are only supported in Enterprise edition. An HSM will allow for the delegation and isolation of managing the encryption keys and functions under a group other than both developers and DBAs, if that is your intent. Other features I would suggest in the design include the following options to complete end to end transport\session encryption:
Installing a domain or CA certificate on the SQL Server and enabling Force Protocol Encryption or enabling IPSec on the host of the instance
Installing a domain or CA certificate on all IIS websites or web services and forcing encryption in the connection strings and https
The benefits of this design over SQL Server Always Encrypted are that the encryption is protected by a single system that can be monitored and defended with more focus as opposed to numerous clients that increase exposure to theft of the private key from one of the users key stores. Also, key rotation for EKMs should be easy for those who are managing the system. It is also possible with an EKM to require that more than one person be involved in generating keys.
I need some way to encrypt all customer data into mysql. If my server is hacked they will never decrypt data.
More detail would make it easier to help. Are you accessing the data regularly? If which server is hacked? The database? Or the application server? What data are you trying to encrypt?
In general you have a few options. You can encrypt at the data storage level with something like dm-crypt. Or you can encrypt at the MySQL level by using the the internal encryption functions. Either way your primary issue is that of key management.
You can go for a robust key management option such as HashiCorp's Vault. Or you can do something as simple as storing the decryption key on your application server. That way your application can decrypt any necessary data, but in order for an attacker to access decrypted data they would have to gain access to both your database and application servers. Not a great solution, but better than nothing.
This answer also has some great advice: https://security.stackexchange.com/a/12334
I have a security issue with one of our distributors. I need to prevent them from accessing certain data in our database. Because they administer the database I can't use password controls on the database itself to protect the data. I'm thinking that I need to encrypt the sensitive data in the database and have the encryption key embedded in software that we create. That way the distributor can poke around in the database all they want but the sensitive data will be unintelligible to them. I see how this might be done in MYSQL. There is are ENCODE and DECODE functions that allow me to pass a key in as a parameter. I can embed these keys in a piece of software, lock the software down, and this will allow me to insert and retrieve information. But what about MS SQL. How can I encrypt data so that even someone who is an administrator of the database cannot read that data?
Thank you,
Elliott
For MS SQL there is tons of documentation on encryption, and based on what you said about MYSQL I think you will be most interested in the Cryptographic Functions.
Note that I would be careful on which methods you encrypt with your own key, as a trace on the database or other means could be used to still obtain the key by inspecting the SQL commands you are sending.
There is definitely encrypt/decrypt functionality in MSSQL:
http://blogs.msdn.com/b/lcris/archive/2007/10/03/sql-server-2008-transparent-data-encryption-feature-a-quick-overview.aspx
http://blog.sqlauthority.com/2009/04/28/sql-server-introduction-to-sql-server-encryption-and-symmetric-key-encryption-tutorial-with-script/ [this one is a tutorial]
You probably want the code based one, as opposed to file encryption...
From this article: http://www.sql-server-performance.com/articles/dev/encryption_2005_2_p1.aspx
(Which BTW is the first result for a google search of encrypt data sql server)
Symmetric Keys
A Symmetric Key is a one key that is used for both encryption and decryption. This is a fast, commonly used method for encryption. As with a certificate, many parameters are available when creating Symmetric Keys. In most cases, we only need a limited set of parameters. You can refer to Books Online for all the parameters.
CREATE SYMMETRIC KEY TestSymKey
WITH ALGORITHM = TRIPLE_DES
ENCRYPTION BY CERTIFICATE CertificateTest2
You can specify an encryption algorithm for a symmetric key. DES, TRIPLE_DES, RC2, RC4, DESX, AES_128, AES_192, and AES_256 are the encryption algorithms available for SQL Server data encryption. AES encryption algorithms are currently supported only on Windows 2003. If you are using Windows 2000 or Windows XP, you do not have access to AES encryption algorithms from SQL Server. If you try to use an AES encryption algorithm, you will get an error:
Either no algorithm has been specified or the bit length and the algorithm specified for the key are not available in this installation of Windows.
You can encrypt a Symmetric Key using PASSWORD, SYMMETRIC KEY, ASYMMETRIC KEY, or CERTIFICATE.
The ALTER SYMMETRIC KEY and DROP SYMMETRIC KEY commands are also available to improve maintenance.
After the creation of a Symmetric Key, it is just a matter of using it. There are three functions you can use with Symmetric Keys: Key_GUID, EncryptByKey, and DecryptByKey.
OPEN SYMMETRIC KEY TestSymKey
DECRYPTION BY CERTIFICATE CertificateTest2;
DECLARE #Encryptvalsym varbinary(MAX)
SET #Encryptvalsym = EncryptByKey( key_guid('TestSymKey'),'scott')
SELECT convert(varchar(max),DecryptByKey(#Encryptvalsym))
Before using SYMMETRIC KEY, you need to open it by using the OPEN SYMMETRIC KEY command. To encrypt data you need to pass the GUID of the Symmetric Key. However, to decrypt it you don't have to pass the GUID. Instead, you have to open the encrypted Symmetric Key using the correct decryption method and value.
To increase the security of Symmetric Keys, you can add an authenticator during encryption. You have to use the same value during decryption.
OPEN SYMMETRIC KEY TestSymKey
DECRYPTION BY CERTIFICATE CertificateTest2;
DECLARE #Encryptvalsym1 varbinary(MAX)
SET #Encryptvalsym1 = EncryptByKey(key_guid('TestSymKey'),'scott',1,'SQL Server')
-- Decryption with Symmetric Keys
SELECT convert(varchar(max),DecryptByKey(#Encryptvalsym1,1,'SQL Server'))
I would skip the database centric algorithms and move it to a software managed solution. That way you can completely avoid the key ever being sent over the wire and compromised by a packet sniffing admin. (This is of course assuming you are using default transports for your database connection)
I've used this link as a reference for creating my DataSecurity library. I prefer the software managed scenario because it allows you to go as heavy or as lightweight as the solution requires, and it allows you to manage the keys in a way that compromising your database does not mean that your data gets compromised as well.
My question is a duplicate of - Oracle Transparent Data Encryption undecrypted access - but for SQL Server 2008.
Can I set up a SQL Server 2008 database in a way that all of the following statements are true?
a) certain columns, potentially all columns are encrypted, so that direct file access to the database file wouldn't allow an attacker to retrieve any records
b) the encrypted columns are transparently decrypted for authorized user, where authorization happens e.g. by having a certain role or privilege
c) an admin who has suiteable privileges for doing 'normal' admin tasks (tuning, creating/droping schema objects, restarting database, selecting from data dictionary) can select the tables but will see only encrypted data in the encrypted columns.
If this is possible, how do I do it. If it is not possible, what are the options I have to at least get 'close' to these requirements?
I know a) is possible but I'm not sure about b) and c).
Thanks.
No, because you cannot perform Transparent Data Encryption on selected columns only:
Transparent data encryption (TDE)
performs real-time I/O encryption and
decryption of the data and log files.
The encryption uses a database
encryption key (DEK), which is stored
in the database boot record for
availability during recovery. The DEK
is a symmetric key secured by using a
certificate stored in the master
database of the server or an
asymmetric key protected by an EKM
module. TDE protects data "at rest",
meaning the data and log files. It
provides the ability to comply with
many laws, regulations, and guidelines
established in various industries.
This enables software developers to
encrypt data by using AES and 3DES
encryption algorithms without changing
existing applications.
Ref.
Here are some things you should consider about TDE (courtesy of Brad McGehee's blog):
TDE does not protect data in memory, so sensitive data can be seen by anyone who has DBO rights to a database, or SA rights to the SQL Server instance. In other words, TDE cannot prevent DBAs from viewing any data they want to see.
TDE is not granular. Then entire database in encrypted.
TDE does not protect communications between client applications and SQL Server, so other encryption methods must be used to protect data flowing over the network.
FILESTREAM data is not encrypted.
When any one database on a SQL Server instance has TDE turned on, then the tempdb database is automatically encrypted, which can contribute to poor performance for both encrypted and non-encrypted databases running on the same instance.
Although fewer resources are required to implement TDE than column-level encryption, it still incurs some overhead, which may prevent it from being used on SQL Servers that are experiencing CPU bottlenecks.
Databases encrypted with TDE can’t take advantage of SQL Server 2008’s new backup compression. If you want to take advantage of both backup compression and encryption, you will have to use a third-party application, such as SQL Backup, which allows you to perform both of these tasks without penalty.
This might be of interest: How to: Encrypt a Column of Data
We have recently implemented Transparent Data Encryption in SQL Server 2008 for local databases on our developers laptops to keep them protected in the case a laptop is stolen or lost. This works fine.
Now we are trying to figure out a way to have the certificate expire everyday, forcing an automated process (a script at logon maybe) to go out to a network path and grab a new certificate with an expiration for a day later. This would ensure that if something unforeseen happened, the data would not be usable the next day.
I also looked into using a Cryptographic provider but there doesn't appear to be any "providers" out there. Maybe I'm wrong.
I am open to suggestions. If there is a better way please let me know. Thanks!
Short answer: No
Long answer: Once a message (piece of data) is encrypted, that same key will decrypt the same encrypted message, regardless of what time the decryption algorithm is applied. If the key is changed every day, the data must be decrypted with the old key and re-encrypted with the new. If this process doesn't occur (i.e. someone stops the piece of code that performs the re encryption from running), the old key will still work. Even if you do create a cryptographic provider to check the date, someone else can create a new provider to perform the decryption without first checking the date.
T address the question rather than the motivation. If you set up a Microsoft CA with a derived template (Set to expire for a day) and also allow autoenrollment on that certificate template. You could then set your SQL machine to be part of a OU within the Directory that uses autoenrolment (Technet will give you resources on this requires the use of goup policy). That way when the certificate expires the machine will automagically request a new one.
http://windowsitpro.com/article/articleid/40948/windows-server-2003-pki-certificate-autoenrollment.html
Mark
Not true! There are options available for SQL Server 2008 encryption. Check out the database encryption solutions here at TownsendSecurity.com. Townsend's Alliance AES Encryption is a NIST-certified solution that would put you into compliance with the regulations around health care, credit cards, and banking. Also see the white paper on Alliance AES Encryption.
Businesses with sensitive data in database applications
want to encrypt the data in order to secure it from loss.
Protecting sensitive data increases customer trust and
loyalty, reduces legal liability, and helps meet regulatory
requirements for data security. Examples of databases
that might contain sensitive information are Oracle
Database, IBM DB2, Microsoft SQL Server, MySQL,
and Microsoft Access. Regardless of the disk or folder
encryption technology that might be used, the actual
data should be encrypted to prevent loss
Full disclosure: I'm an intern at Townsend Security.
Without additional detail I fail to understand how your TDE setup will protect data in case it is lost or stolen.
If you are not using full disk encryption (via Bitlocker, Truecrypt, etc) then I as an attacker in physical possession of your hardware can easily reset the local admin password, boot up the laptop and access the SQL Server instance with the local admin credentials. At that point I am a sysadmin on the database server and am able to extract any data I want or to turn off TDE.
In addition since all of the encryption keys and certificates are stored locally it is relatively easy for an attacker in physical possession of the device to gain access to them. TDE is only meaningful for data protection when you physically separate the Database Encryption Key protectors (stored in the master database) from the encrypted database.
If you are using full disk encryption than the usage of TDE is not providing any additional deterrent to an attacker and is only adversely affecting system performance of your developers laptops.
You're right - what you want is a cryptographic provider, and you're right that there's none out there yet.
If you're going to the PASS Summit in November, talk to JC Cannon from Microsoft. He's doing a session on compliance, and he's the head of the SQL Server Compliance group. He's tied into the vendors that are currently working on building cryptographic providers, and he may be able to talk to you about vendor names. Right now they haven't come out publicly to announce who's doing it yet.