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/
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.
In our electronic criminal law, customer-sensitive data must be encrypted at rest and all admins working on servers and DBs must not be able to access this information clearly.
Microsoft provides three methods to encrypt sensitive information.
1- TDE[Transperant Data Encryption].
2- Always Encryption.
3- Always encrypted Enclave. not supported in our platform.
TDE by documentation it encrypts data at rest [the files [mdf,ldf,bak] are encrypted].
but once you accessed the instance you can see all data in cleartext.
Always encrypted can encrypt data inside instance to prevent authorized users from accessing data in clear text unless the have different certificates. which could be deployed in the IIS server or development server. specifically in the window's store of the azure vault.
anyhow, by mixing both methods together so that data is encrypted at rest and encrypted to everyone cannot access the master certificate.
In a given structure that is managed by many teams:
1- DBA
2- DB backup
3- Domain Admin
4- local admin
Also in two tires system, that uses different two servers, one for IIS and the other for MSSL server.
By applying the up-mentioned mixeture, the admins of both machines can access the split password of always encrypted and then access the information.
My question:
How available it be, to prevent those admins from accessing info?
do i have to secure the column master encryption key at client side, so that nobody can read it?
Is it correct that when somebody has the column and master encryption key data can be decrypted by an attacker?
Regards
do i have to secure ... so that nobody can read it
This statement can never be true. If the application needs to read a secret (the key), then so can an administrator on the site. If you have an application running at a client side, there is nothing you can do to prevent a determined client from finding the key. Ditto for an attacker that has compromised the location.
Always Encrypted scenario is for applications that do not trust their service hosting (think Azure SQL Database). The application has the key and can manipulate the data, and the data travels to the hosting service and is stored encrypted. The hosting service cannot decrypt your data. All this is the starting paragraph describing the feature:
Always Encrypted is a feature designed to protect sensitive data, such as credit card numbers or national identification numbers (e.g. U.S. social security numbers), stored in Azure SQL Database or SQL Server databases. 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). By ensuring on-premises database administrators, cloud database operators, or other high-privileged, but unauthorized users, cannot access the encrypted data, Always Encrypted enables customers to confidently store sensitive data outside of their direct control. This allows organizations to encrypt data at rest and in use for storage in Azure, to enable delegation of on-premises database administration to third parties, or to reduce security clearance requirements for their own DBA staff.
Your understanding is correct, roughly speaking, Always Encrypted provides the following security guarantee, Plaintext data will only be visible to entities that have access to the ColumnMasterKey (Certificate). So you would have to ensure that your CMK is only accessible by trusted entities. Also, the best practice is to have the client application and database on separate machines.
I have provided a short detailed explanation regarding the security guarantee provided by Always Encrypted here. You might find this useful. If you have additional questions, please leave a comment and I will try by best to help
Hey guys i am learning about MS SQL-Server clustering instances. I am wondering if you could add a cluster on a existing instance of SQL server 2012.
I mean is it the whole point of clustered instances: to create a new instance that supports disaster recovery?
I have no experience in clustering a SQL Server (I'm no DBA) so all I can give is a link (brentozar.com - An Introduction to SQL Server Clusters) with a good read.
The main things to take away from this excellent post, written by Kendra Little, and I quote:
Key Concept: A Windows Failover Cluster uses shared storage– typically, this shared storage is on a SAN. When a SQL Server instance is installed on the cluster, system and user databases are required to be on the shared storage. That allows the cluster to move the SQL instance to any server (or “node”) in the cluster whenever you request, or if one of the nodes is having a problem. There is only one copy of the data, but the network name and SQL Server service for the instance can be made active from any cluster node.
Translation: A failover cluster basically gives you the ability to have all the data for a SQL Server instance installed in something like a share that can be accessed from different servers. It will always have the same instance name, SQL Agent jobs, Linked Servers and Logins wherever you bring it up. You can even make it always use the same IPAddress and port– so no users of the SQL Server have to know where it is at any given time.
The link has a beautiful description of a use-case with 2 simple images but I don't want to incorporate the whole post in here. If the quote doesn't make things clear, surf to the link.
We are working on a licensing system for a client-server application where the only server component is a database (no application server). We would like to issue licenses to a particular server that cannot be installed on any other server or transferred via backup/restore. The idea is to generate a unqiue identifier via a T-SQL query and then use public/private signing to return an activation token that works only for that identifier.
Is there a way to uniquely identify a SQL Server, in a repeatable way, using only T-SQL (without a CLR stored proc or function)? For example, is there some retrievable, unique value that is created when the instance is installed?
Edit: Maybe the MAC part of NEWSEQUENTIALID() would work (see this method). If the system fails over in a cluster/failover setup, or if the primary LAN adapter is changed, it could enter a "grace period" during which it will continue to operate until re-activated on the new hardware. The question is whether this is "unique enough."
Even if you get a unique ID a potential problem is validation at T-SQL. The database is not validated. What if they hack the T-SQL and remove the activation part. Does the customer use T-SQL directly or do you have a client application. If you have a client application then why is CLR not an option. It was crack-able but I worked with an application that generated a hash of server name on the install and stored it in the database. Then the client would compare the stored hash to the dynamic hash to determine if it was on another server. Problem was if the server name was the same then it could be beat and the hash algorithm was on the client application so with effort it could be exposed.
Adian I wish I could thank you for answering my questions.
If you look in sysObjects and other systems tables/views I think you can find something to uniquely identify a server and database. Like on a restore to another server you have to delete the user and and recreate the user even though the name is the same the internal id is different. If they restored the master and application database they might be able to make everything identical but they would have to know to do that. On the base install SQL may generate a unique id somewhere as it makes sense Microsoft would want a unique id for replication, other features, and licensing.