I've got on the same computer (Win server 2012 R2 Datacenter) a web app being built on ASP.NET and a SQL Server 2017. Goal is to secure sensitive data on the database in case someone gains access to this computer. I've used Always Encrypted feature to encrypt columns with sensitive data and the according certificate is being stored to the \Certificates(Local Computer)\Personal\Certificates location.
Is there a way to prevent (password protect for example) an active windows user to access this certificate and export it?
To achieve your goal "to secure sensitive data on the database in case someone gains access to this computer" you should not consider keeping your certificate in the same machine (or) server.
You need to maintain the certificate in a Centralized Key Stores like Azure Key Vault
Please see my detailed answer here
Related
We are investigating using native encryption with our DB2 v11.1 instance. I have read the documentation available but have been advised by a team member that once native encryption is enabled on a database, when the database instance is restarted the DBAs would need to re-enter the password for the encryption key before any application could access the database. We are not planning to stash the password.
Can anyone advise if this is the case? The reference I have found is here on this IBM KB article and says:
However, this additional security must be weighed against any requirements that the DB2 instance can start without human intervention. If the password is not stashed, you cannot access an encrypted database until you provide the keystore password.
Does that include a web application that connects to the DB2 instance to access the encrypted database? Or is this just for DBAs connecting to maintain/run queries?
Thanks in advance!
Without stashing you can use
db2start open keystore using <Keystore-Passwort>
or
db2start open keystore passarg filename:<file>
My organisation is considering using Transactional Replication to Azure SQL DB but unsure where encryption and security fits in to this new capability. We are looking for documentation on how to configure security for replication to Azure SQL, perhaps with encryption and other steps to help mitigate vulnerabilities.
This resource has some details but does it also apply to Azure scenaio?
See this article especially part about creating subscription using transact-SQL. Also see this about connection encryption. So I think that when you add a subscriber all you have to do is to make sure that connection encryption is enabled. Below is a brief description how to achieve this while connecting to Azure SQL. Since when you add a subscriber you have to connect to Azure SQL database then the process is similar:
Open SQL Server Management Studio.
From Object Explorer, click Connect, then click Database Engine.
From Connect to Server, click Connection Properties.
Select Encrypt connection
Also you could consider a VPN connection between on-prem and Azure as mentioned here.
Protecting data in transit should be essential part of your data protection strategy. Since data will be moving back and forth from
many locations, the general recommendation is that you always use
SSL/TLS protocols to exchange data across different locations. In some
circumstances, you may want to isolate the entire communication
channel between your on-premises and cloud infrastructure by using a
virtual private network (VPN).
For data moving between your on-premises infrastructure and Azure, you
should consider appropriate safeguards such as HTTPS or VPN.
For organizations that need to secure access from multiple
workstations located on-premises to Azure, use Azure site-to-site VPN.
For organizations that need to secure access from one workstation
located on-premises to Azure, use Point-to-Site VPN.
Larger data sets can be moved over a dedicated high-speed WAN link
such as ExpressRoute. If you choose to use ExpressRoute, you can also
encrypt the data at the application-level using SSL/TLS or other
protocols for added protection.
I have a SQL Server 2012 Standard hosted on a WIN 2008 R2 DataCenter 64 bit. I have a requirement to set the Force Encryption on the SQL Server to Yes, which is easy to do.
What I am needing help with is for the DoD Certificate requirement, where do I get the DoD Certificate from? and Do I just install it on the server where SQL Server resides?
I found this link , I wonder if I can use this:
http://dodpki.c3pki.chamb.disa.mil/rootca.html
Your hyperlink is not publicly available, however, since the name on the file is rootca.html it may contain information about how to get a root CA Certificate provisioned. When you use SQL Server Configuration Manager to set force encryption to true, you must either configure a certificate to use or the server will used a self signed certificate. The security concern with only setting this option and using a self signed certificate is that it leaves your server vulnerable to a man in the middle attack. The requirements for creating the certificate to be used for encrypting connections are on MSDN. I would recommend at least using a domain certificate generated by the domain certificate authority. You probably need to adhere to standards if this is for the DOD. Once the certificate and related private key are generated, they need to be added to the certificate store of the service account running the SQL Server database engine. After that, it can be selected for use in the configuration manager in the same dialog box as the force encryption option under a different tab. Once this is configured and the service is restarted, you can verify that the connections are encrypted by using the sql statement below:
select * from sys.dm_exec_connections
I have a requirement to prevent DBAs in ops team from looking at cell level encrypted data.
Is it possible in SQL Server to do this:
a. Delegate cryptographic key management functionality to one person (security PM) and revoke all access to data for him.
b. Remove cryptographic key management & access functionality from system administrator.
By doing this, unless the two colluded they cannot see the data.
If you are using Enterprise Edition that is 2008R2 or above, then what you need is an Extensible Key Management system. The exact function of an EKM is that which you described. The Hardware Security Module of the EKM will contain keys and algorithms and will perform the encryption and decryption functions. The SQL Server will only contain the encrypted data. Management of the EKM can be delegated to your Security PM. An EKM should be transparent to the application.
SQL Server 2016 also has a feature called Always Encrypted. This puts the encryption key in the client driver and separates it from the server.
Just a model case. Provided the SQL Server 2008 R2 Enterprise database is encrypted with the TDE. Someone starts the machine from Linux live CD, resets the local user/admin password and boot into Windows 8.1. Will this allow them to access the database data, to encrypt them?
If it is possible to get the access like that for a local account could it somehow help to start using Microsoft Account? Or the local administrator account will be still the risk for Linux access, even if disabled? And the only option how to protect the database data on "workstation/laptop" is to encrypt the whole drive?
TDE only protects the databases from being attached to another server (i.e., the hard drive gets stolen, the files get detached and mounted on another server). In the scenario you describe, TDE will NOT prevent access to the data.