I've been playing with RDS recently and wondering if it's possible to get table level encryption on RDS instances?
I can see that there's support for encryption in SQL Server before data is written to storage and decryption when it's being read from storage, but is it possible to have encryption down to tables?
Any ideas anyone?
Related
I am going to store sensitive data like SSN and bank account numbers in my SQL Server database. The database is located on a server separate from where the application code is run, and I have Security Groups set up to only allow inbound access to the db server from my app server IP. I have already implemented the IDataProtector API and am using it to store encrypted passwords in my db, so I was going to use this to store the SSN and bank info as well.
But I read about Always Encrypted today, which is a SQL Server-based method you can use to encrypt specific columns. From the Microsoft page: "Always Encrypted allows clients to encrypt sensitive data inside client applications and never reveal the encryption keys to the Database Engine (SQL Database or SQL Server). As a result, Always Encrypted provides a separation between those who own the data and can view it, and those who manage the data but should have no access."
If I'm mostly concerned with hackers getting into my db and stealing data, which one of these methods is more secure? The master key for Always Encrypted would be stored in the Windows Certificate Store on the app server. I honestly don't know where the keys for IDataProtection are stored since it's been awhile since I set it up. I don't have anything explicit in Startup in services.AddDataProtection().
After much research, I think I'll go with Data Protector for now. The main decision point was that I don't want to use Azure Key Vault for centralized key storage, and Always Encrypted does not offer many alternatives.
I found that I can't use Windows Certificate Store for the column master keys because my EC2 instances are on a load balancer/auto-scaler, and so the Windows environment could be rebuilt at any time and lose the keys.
This is my first ever post so I'll be brief.
I have two SQL 2014 Enterprise servers; one primary and one secondary replica. This is a multi-tenancy deployment with separate databases per tenant. (No shared databases or shared schema). I currently have one AlwaysOn Availability Group up and running (more to follow). I have a TDE requirement. I have an SSL certificate issued by our CA. It is installed on bother SQL servers. I have converted it to .PVK format. I'm ready to implement database encryption using the same .PVK on both servers
Areas of confusion:
Do I have to export the SSL certificate thumbnail to the secondary servers registry the same way I do in a normal quorum-based fail-over cluster?
I have to create a master key on the primary SQL server before I can create a new TDE certificate from file. I don't understand how the secondary replica server factors into this case. I need the encrypted databases to be accessible on the secondary server. Since I'm dealing with different master databases, do I have to create another master key on the secondary server? Can I still use the same .PVK certificate on the secondary server for TDE?
I would appreciate any insights or guidance. Thanks a lot.
DC
So, it helps to know what's going on with TDE and where all the moving parts live. Let's start at the bottom and work our way up.
The database encryption key lives in the user database. It will fail over with the database when the AG moves to another node.
The encryption key is encrypted by the server certificate that lives in the master database. In order for it to be decrypted after a failover, the certificate that protects it needs to be available on any node that attempts to decrypt it.
Certificates in general are protected by the database master key (DMK). Since master is just another database (albeit a special one), it just needs a DMK in order to protect the certificate.
Though not relevant for this discussion, the DMK is protected by the service master key (SMK). The SMK is generated for you when the instance is installed. If you're ever in a situation where you have a DMK that will need to be decrypted somewhere other than the server where the database was created, make sure you have that SMK handy. One thing that I've done recently is make sure that the SMKs match on all nodes in an AG (using backup service master key and restore service master key). That way, when a user database fails between nodes, the DMK can be decrypted automatically by the SMK on the new node (since it's the same SMK). As to why it's not relevant for this discussion, your master databases won't be failing between nodes.
And as far as needing to import the cert into the registry, I haven't had to do that in my experience.
I can't answer part one, but the answer to part two is basically what you already guessed. Create a new master key on the secondary server using the same specification as the primary, then use the same cert. I found a Microsoft support blog which may help you: https://blogs.msdn.microsoft.com/sqlserverfaq/2013/11/22/how-to-configure-always-on-for-a-tde-database/
I need to store sensitive data in SQL server and need this encrypting. This ideally needs encryping and descrypting within SQL server and not in the code of the application(s). The reason being, the application to add the data to the database will be written by someone else in ASP and I will be pulling out this data and using this within my application which is written in PHP and will therefore need this decryping.
MySQL has a nice little function AES_ENCRYPT but I cannot find anythign similar for MSSQL and I am very unfamiliar with MSSQL, so any help would be much appreciated.
Summary: With the introduction of transparent data encryption (TDE) in
SQL Server 2008, users now have the choice between cell-level
encryption as in SQL Server 2005, full database-level encryption by
using TDE, or the file-level encryption options provided by Windows.
TDE is the optimal choice for bulk encryption to meet regulatory
compliance or corporate data security standards. TDE works at the file
level, which is similar to two Windows® features: the Encrypting File
System (EFS) and BitLocker™ Drive Encryption, the new volume-level
encryption introduced in Windows Vista®, both of which also encrypt
data on the hard drive. TDE does not replace cell-level encryption,
EFS, or BitLocker. This white paper compares TDE with these other
encryption methods for application developers and database
administrators. While this is not a technical, in-depth review of TDE,
technical implementations are explored and a familiarity with concepts
such as virtual log files and the buffer pool are assumed. The user is
assumed to be familiar with cell-level encryption and cryptography in
general. Implementing database encryption is covered, but not the
rationale for encrypting a database.
Reference
Security has become extremely important in today’s fiercely completive
business environment. Industry standards require you to implement firm
techniques to secure your data. In SQL Server 2005, security has
improved for authentication, authorization, and encryption. Encryption
is so much improved that it is almost a new feature in SQL Server
2005.
Encryption is the last barrier against a hacker. Technically,
authentication and authorization methods should be strong enough to
stop hackers before they can view data. But if they do get through,
the last trump card for system designers is data encryption. You will
not encrypt you all of your data, only very important data like
passwords, credit card number, etc.
In the days of SQL Server 2000, you had two options: find third party
tools to handle data encryption, if available, or use the built-in
encryption, which was very limited. and this might help
Reference
I've stumbled upon a great read on SQL Server Cryptographic features. It describes utilizing Transparent Data Encryption (TDE), Encrypted backup feature (introduced in SQL Server 2014), Symmetric and Asymmetric encryption, and Hashing.
All these features differ in implementation, and I strongly suggest reading this article to find out what solution is the best for your needs: http://www.sqlshack.com/sql-server-confidential-part-ii-sql-server-cryptographic-features/
What is the best way to encrypt a SQL 2005 database?
I have found things about the with SQL 2008, and I've seen how to do column encryption in SQL 2005 - but it seems more difficult to access the table values then because you need to create a function or a view/stored procedure.
I also tried doing the file level security by using windows encryption (via a certificate) to encrypt the folder which held the database files, but then SQL Server Management Studio gave me errors on permissions (even after I gave it permissions).
I need to secure client data on our servers and I need to do it in a way that will not slow down our server too much, though I know it's inevitable due to the extra layer that encryption poses.
Am I missing something, or am I wrong? Please advise.
Upgrade to SQL Server 2008 and use Transparent Database Encryption. Unlike column level encryption of SQL Server 2005, the 2008 TDE is, as the name implies, transparent. Requires no application changes. Also, the data is searchable, something which is always desirable but very difficult to achieve with column encryption or with client side encryption.
File level encryption does not really work with SQL Server. However, BitLocker does work with SQL Server so encrypting the entire volume with BitLocker is another viable alternative.
If you don't want to slow down the server, you could encrypt and decrypt data on the fly using the client side to process it. Store data in the database in a serialized and/or encrypted fashion. There are many examples of this kind of thing on the net.
Create a wrapper for your data , like so :
Wrap(
Zip (
Base64 Encode (
Encrypt (
Serialize(
DATA
)
)
)
)
)
Then,
StoreInDB(
WrappedData
)
I don't want customers to be able to make backups of my sql server database and access the tables data etc.
I know there are some products that will encrypt the data in the tables, and their product will decrypt it when displaying in my application.
What products do you guys know of? What options do I have?
(This is a business requirement, however silly it might seem to some hehe).
Update
This is for sql server 2008 express
The problem with encrypting data inside the database is that as long as the database lives on the client's machine (as you indicated, they're running SQL 2008 Express, so I'm betting it lives on the client's desktops or laptops) then they can get into the data. They can set up security on the instance so that they have SA privileges, and from there, they can get the data, period. There's no way around that.
What you have to do is encrypt the data before it hits the database: encrypt it in your application. Inside the app, encrypt the data that you want to store in each sensitive field. As another poster indicated, you don't want to encrypt ID fields because those are used for indexing.
There is the 3rd party xp_crypt. It's been around for years.
It's an extended stored proc (that is, DLL)
SQL Server 2008 supports database encryption natively. Check the documentation for Transparent Data Encryption (TDE).
You can encrypt stored procedures, which can protect your logic.
TDE is available only Enterprise edition.
I can't find if it supports native sql encryption - but you could find this out with a little searching. But if it did you could probably set the database master key with your application and keep all of the decryption/encryption code in your application.
If it doesn't support native encryption, you might want to creat/find your own encryption functions in your application language and lock away the keys in your code.
Transparent Data Encryption will encrypt the database on disk, but is unencrypted in memory, so appropriate security would also be necessary to ensure unauthorised users cannot access the table. As it's an Enterprise-only feature, you can safely move away from it.
SQL Server 2005 and above have built-in encryption features - have a look at Books Online, and especially Chapter 5 - Encryption of Adam Machanic's Expert SQL Server 2005 Development book (technically, Lara Rubbelke wrote chapter 5 though).
Note that you'll only want to encrypt some columns - those that you'll never try to look up, as encrypted columns are pretty much useless for indexing. Adam Machanic's book suggests ways to solve this problem.
Another solution for transparent SQL Server encryption is DbDefence
Free for databases less than 77 MBs.