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
Related
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.
Is it unsafe to open the mysql server port to allow remote connections?
If it is unsafe, what is a better solution?
EDIT:
-I need read and write rights.
-Each user has a password to connect. That means that not any user can connect to the database.
What security problems does this enviroment have?
Is there a better solution?
In principle, MySQL has a rigorous permissions system which could be set up to allow remote users minimal levels of access to the tables they would need to do their job.
In practice, MySQL has had many exploits in the past, both in applying those permissions and in preventing access to the host server. It is reasonable to expect more in future; since very few admins allow untrusted access to a MySQL server, it is not strongly locked down against attacks (unlike, say, a web server like Apache).
MySQL's authentication model is also weak: passwords are stored in a table as unsalted hashes and there is no protection against brute-force password attacks. For communication between a trusted server app and the DB, you can get away with that; for authentication of not-wholly-trusted third parties it's not good enough.
If your “users” are database administrators, it's plausible to give them remote access, with access locked down by IP address/firewall or SSH tunnel. If the “users” are not-fully-trusted third parties you expect to be using the database as part of a client application, I wouldn't. And definitely don't open access to the whole public internet.
In any case, if we are talking about application users, your business rules are going to need more granularity in access rights than you can manage with table- or column-level controls. For example rules like “reviewer-class users may set article.state to 3 but only if article.state was previously 1 or 2”, or “setting article.state to 4 always causes the associated articlecontent to be deleted” cannot be reproduced in table permissions.
For that, you almost always need some component between the raw table storage and the remote client/application to manage the requests. That layer is traditionally a separate server application which is the only thing talking to the database. You could in theory write that component in database stored procedures, and give users access only to the procs not the tables. But doing anything complicated in stored procs is a super pain to write and maintain compared to a general-purpose programming language.
I have read a lot of things in SO but I still cannot figure out the whole mechanism of the encryption thing...
I want my site to write data in an SQL Server. Where should the encryption function be? What does my database need?
I want a webservice of mine to get that data, process them and insert them to another SQL Server decrypted. Should I declar the same protocols there as well? How will know the encryption, keys in order to decrypt? What is the circuit like?
Sorry for being SO FADE (mods you can reject the post) but I cannot follow the logic behing the SQL encryption/decryption mechanism...
There are different points at which you need to encrypt data.
The first is "in motion". Meaning you encrypt the data while it is in transit between two machines. The common points include between the browser and web server (typically using SSL) and between the web server and database server (Kerberos is the common one for Windows machines). The purpose is to prevent someone from eavesdropping on the wire.
The second is "at rest". This means the data should be encrypted while it is in the storage facility: namely SQL server. The purpose here is to prevent the data from being decrypted should a hacker obtain a copy of the database file. The easiest mechanism by far is to utilize SQL Servers built in encryption mechanisms.
Another option for "at rest" encryption that is sometimes employed is to have the web server encrypt the data prior to sending it to the SQL server. Generally speaking this is no more effective than simply allowing the database server handle the encryption/decryption itself. However it does have several drawbacks such as making it near impossible to query the data from SQL servers tools. Further the keys have a wider distribution as every application that needs to touch the data must have access to the keys in order to work. This can be somewhat limited by using a service layer on top of SQL server to handle data management.. but, again, this doesn't provide any more security than what you have right out of the box.
If I use MS Access in the back-end of a client-server type software and the database file is sent from client to server, will it create any problems in further database handling, transfer speed, or performance compared to SQL Server?
In my experience there are 4 major differences between MS Access MDB files and SQL Server performance in a small LAN based environment (where small means 20 users or less with no more than 10 concurrent user sessions)
Security. Use of an access MDB file requires that the client have direct access to the MDB file. This architecture can't be truly secure if you need to limit data access for some users. Access user level security can be cracked. You can use file level or file share level security in the OS if that satisfies your security requirements.
MDB files are subject to corruption as a result of network errors. The only time I've seen a SQL Server database become corrupted was as a result of hardware failure on the server.
The upper limit for an MDB file is around 25 users, and Access is sensitive to high transaction volume for inserts, updates, and deletes.
In most cases with Access you'll need to have all users sign out of the database to make any changes to the structure of the tables. This is much less convenient than using DDL scripts in SQL Server. If you decide to go with Access, I'd recommend getting a copy of LDBView so you can tell who you'll have to kick out of the database each time you make a routine change to the data structure.
There is a case to be made for a back end MDB file if the user audience is small and the simplicity of deployment is appealling to the client organization. But if you are starting a new project, the advantages of a SQL Server backend should be carefully considered. If you have a large user audience then SQL Server is strongly recommended.
It is unlikely that you will have a problem with transfer speed when using an MDB file with an up-to-date version of MS Access and well configured LAN.
If you use MS Access as your back-end database it isn't a client-server solution. Jet Databases (The kind MS Access creates) are file based, not client-server.
If the bandwidth between the client and the DB is high (like another server on the same network) then it shouldn't pose any major performance problems related to transfer speed. However, if you were connecting over a slow WAN link to the DB from the client, it definitely could introduce a performance bottleneck.
I have a article on using access over a network, and especially that of a WAN here:
http://www.kallal.ca/Wan/Wans.html
Some good answers here, already. But something that is often overlooked is that there are scenarios where using a lightweight mdb gives you much more performance than a heavy-weighted SQL server. For example, if multi-user access is not so important, but you have to do a lot of batch processing on your data, using mdb files can be much faster. On the other hand, if you have a lot of classical OLTP processing with many users, you can benefit from a real client/server database.
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.