We are going to use Always Encryption on few of the columns in our database tables. I gone through some of the articles on this subject and stuck on two points.
Say I am going to use same server for my database and my web application. Now I can save the Column Master Key(CMK) in the Windows certificate store of the current machine. How can I ensure that except Administrator no other database user can access the plain text data from SSMS?
I have separate servers for database and web application. In the time of encryption, the CMK certificate get created in the database server. Now I can export the certificate and install it in web application server. Can I remove the certificate from the database server so that nobody can see the plain text data?
Thanks in advance
Related
I created SQL account for an application but how do I restrict or deny the same account not to connect the database using SSMS or Azure data studio by the developers since the developers can view the user information in web.config file.
Thanks,
Sandeep
You can use Azure Active Directory to authenticate your app, so that you don't need to write the username and password in config file.
With Azure AD authentication, you can centrally manage the identities of database users and other Microsoft services in one central location.
Benefits:
It provides an alternative to SQL Server authentication.
It helps stop the proliferation of user identities across servers.
It allows password rotation in a single place.
You can read more details from this document.
Basically the answer to your question is... You can't...
There is no way to identify the client of a certain connection in Azure SQL. What you can do, for example, is restrict access to a certain server using s firewall. But if your dev env is on the same machine as your SSMS that won't work because you're then blocking the dev env as well.
In that case, the best practice is to create a dev database to which all devs have access. In that case, it doesn't matter for you everyone knows the password because it's the dev database.
For production environments, you need to treat database credentials as secrets and thus make sure they are stored in a safe place. When you're using Azure, the KeyVault may be a good place to store the password. This KeyVault has a fine grained way of allowing access to secrets for individuals as well as IT systems.
I am working on a prototype for an upcoming big solution and wish to use Always Encrypted to encrypt certain sensitive database columns.
My setup is a follows:
Database Server: SQL Server 2016 installed
Application Server: Reporting Server 2016 installed pointing to the Database Server engine. IIS, .Net 4.6.2 etc. all setup as well.
The environment is also setup in a way that the DBA can't read the encrypted data even if from Management Studio he will add the 'Column Encryption Setting = Enabled' in the connection. So my certificate is installed on the Application Server while the CMK and CEK are installed on the Database Server database.
I can view the encrypted data from my Web App installed on the Application Server with no problem, and the DBA can't read the encrypted data directly from the database, so I am assuming that my environment is well set up.
As explained I have SSRS 2016 installed on the Application Server but pointing to the database with encrypted columns on the database server. I have done a basic dump report (for testing purposes) using Report Builder of course and all works well EXCEPT that the encrypted data is not displayed - it is remaining blank in the SSRS Table! The encrypted column is just a basic nvarchar(200)
In the datasource connection string I have added 'Column Encryption Setting = Enabled'. Without it the report display #Error as expected. So I am assuming that this is needed as well.
Something also that I noticed is that from the Query Designer I can read the encrypted column. if I remove 'Column Encryption Setting = Enabled' from the datasource the Query Designer displays VarBinary if I remember correctly. I am working with Report Builder and Query Designer directly on the Application server of course.
I tried to search for any tutorials on how to use SSRS with Always Encrypted but I couldn't find anything. All I found is a comment in a post that SSRS supports Always Encrypted.
Can someone please enlighten what I am doing wrong or what I am missing?
Thanks in advance.
Disclaimer: I am a Program Manager at Microsoft.
To troubleshoot your issue, please try to run the problematic query (the one that returns no data in Report Builder) from SQL Server Management Studio on the same machine (that you run Report Builder from) and as the same user, over a connection with 'Column Encryption Setting = Enabled' and see, if you get any error message.
I have seen a query against encrypted columns returning no results in Report Builder, if the certificate is not deployed on the machine, hosting Report Builder, or the user does not have a permission to access the certificate. Do you store the certificate (used as a column master key) in the Current User or Local Machine store? If it is in the Local Machine store, you need to ensure that you (the user who runs Report Builder) have the permissions to access the certificate (you can configure permissions on a certificate using Management Console).
The account that is running the SSRS service needs to have read permission on the Always Encrypted certificate in the Local Machine store. Right click the certificate, select All Tasks – Manage Private Keys and then provide the SSRS service account read permissions on the certificate.
I'm connecting to a SQL Server instance in a shared environment using SQL Server Management Studio. I don't want to take the hosting service's word so I'd like to find a way to discover whether all communications are encrypted. Especially the password, since it seems from this answer that sometimes it's sent in plaintext and sometimes not (I've been trying to use Microsoft Network Monitor to find out if it's encrypted but haven't been successful yet.)
Even if the password is encrypted, what if someone uses the connection (as a man-in-the-middle) to enter his own data into the database? (I'm more worried about that, though reading from the database is also a problem, of course.)
So, to sum up, how can I force a secure connection or at least discover whether one is present, when I don't have administrator's privileges on the database?
SQL Server client drivers offer the ability to require encryption and also verify that the certificate on the SQL Server comes from a trusted provider. Most drivers for SQL Server (JDBC, ODBC, .NET client, etc) have these settings.
More information can be found here: https://technet.microsoft.com/en-us/library/ms189067(v=sql.105).aspx
Public Domino server has a publicly available Lotus Notes database. That database has a form that an unauthenticated user can fill out and submit using his/her browser.
This publicly available form is only used for the post request and data must not be stored on that publicly available server. Instead, I need to connect to a database on an internal server and create the document there.
Obvious solution is a Lotus Script agent but when I worked on Notes, I remember non-user agents were prevented from opening databases on another server for security reasons. I certainly cannot introduce secure server setup. I need to find a way to do this that fits current setup. The servers are in two different Notes networks but mail is routed between them, so if I don't find a better solution, I will probably mail the document.
Any ideas? I have not worked with latest Notes servers. Anything in 8.5 that can help here?
In the server document on the security tab there is an Option called "Trusted Servers" if you could put the external server into that field, then the agent would be allowed to dirctly write into databases on the internal server.
If you are not able / allowed to do this, then you have to write to a "local" database (on external server) and replicate this database to internal server either by using a console command (NotesSession.SendConsoleCommand) or with the replicate method of the NotesDatabase class (not sure, if this will work due to the same security restrictions) or via scheduled replication.
If the database itself cannot be replicated on the external server, then you should use a container database and let an agent on the internal server copy the data to the internal database.
And the last possibility you already mentioned: compose the document and send it via mail. Make the target database a mailin- database and simply send you data there with NotesDocument.Send...
One of these options should solve your problem.
I copied a SQL Server database from one system to the next, identical setup, but completely different physical machine. I used Norton Ghost and recoverd files manually, for example, the entire SQL Server 2008 folder found in c:\Program Files after re-installing SQL Server 2008 Express.
One of my databases has AES_256 encryption enabled on a number of one of its tables, columns. I resetup my IIS7 and tried to run the app that access the database, upon retrieving the data, I get this error:
Server Error in '/' Application.
Please create a master key in the
database or open the master key in the
session before performing this
operation. Description: An unhandled
exception occurred during the
execution of the current web request.
Please review the stack trace for more
information about the error and where
it originated in the code.
Exception Details:
System.Data.SqlClient.SqlException:
Please create a master key in the
database or open the master key in the
session before performing this
operation.
Source Error:
An unhandled exception was generated
during the execution of the current
web request. Information regarding the
origin and location of the exception
can be identified using the exception
stack trace below.
I've done some reading and found some links about how the AES encryption is linked with the machine key, but am at a loss as to how to copy it over to the new system. Or perhaps this even isn't the case.
NOTE: I've tried dropping the symmetric key, certificate and the master key and re-creating them. This gets rid of the error, but than the data that in encrypted via AES_256 does not show up. The columns that are NOT encrypted do, however.
Any help would be much appreciated. Thanks in advance!
The database master key is encrypted using the server master key, which is specific to the machine where SQL Server is installed. When you move the database to another server, you lose the ability to automatically decrypt and open the database master key because the local server key will most likely be different. If you can't decrypt the database master key, you can't decrypt anything else that depends on it (certificates, symmetric keys, etc).
Basically, you want to re-encrypt the database master key against the new server key, which can be done with this script (using admin privileges):
-- Reset database master key for server (if database was restored from backups on another server)
OPEN MASTER KEY DECRYPTION BY PASSWORD = '---your database master key password---'
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY
GO
Note that when you create a database master key, you should always provide a password as well so that you can open the key using the password in the scenario where the service master key cannot be used - hopefully you've got that password stored somewhere!
Alternatively, you can restore a backup of the database master key - but you need one that was created for the target server, not the source server.
If you haven't got either a backup or a password, then I'm not sure you will be able to recover the encrypted data on the new server, as you will have to drop and recreate the database master key with a new password, which will kill any dependent keys and data.
I just had a similar situation, an server rebuild after the OS drives died. I reinstalled SQL and reconnected it to all my old databases on the untouched data drives. Everything worked except for my encrypted columns. But my issue was that the master service key was hosed. I was able to repair my master service key by going back to the same domain credential that had been my SQL server service account before the move.
This article gave me the fix (kudos to Matt Bowler for his excellent article). I knew the local machine key had changed, but my salvation was that I could use the same service account.
Service Master Key: At the top of the key hierarchy is the Service Master Key. There is one per SQL Server instance, it is a symmetric key, and it is stored in the master database. Used to encrypt Database Master Keys, Linked Server passwords and Credentials it is generated at first SQL Server startup.
There are no user configurable passwords associated with this key – it is encrypted by the SQL Server service account and the local machine key. On startup SQL Server can open the Service Master Key with either of these decryptions. If one of them fails – SQL Server will use the other one and ‘fix’ the failed decryption (if both fail – SQL Server will error). This is to account for situations like clusters where the local machine key will be different after a failover. This is also one reason why service accounts should be changed using SQL Server Configuration Manager – because then the Service Master Key encryption is regenerated correctly.
http://mattsql.wordpress.com/2012/11/13/migrating-sql-server-databases-that-use-database-master-keys/