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.
Related
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
I have a scheduling software that has a database of clients, client pets, pets grooming styles, appointments and invoices.
The generic reports that are given with the software are not giving me the information that I need to go. Support from the software company is telling me to use Access to build the reports that I require.
I am not seeing how to connect to the software's DB to use in Access to generate my custom reports.
Any help or links to the information for this would be greatly appreciated.
Thanks in advance everybody
One of MS Access' unique features is connecting to external RDBMs' ( SQL Server, Oracle, Postgres, MySQL, SQLite) in complement to its default Jet/ACE SQL Engine. In fact, Access can connect to any other ODBC-compliant system even Quickbooks or your software assuming it has an ODBC API.
An .MDF is a SQL Server main database file but usually you do not connect directly to the file but the server instance. Most likely, you are required to connect Access to the SQL Server database the software sits on. In fact, you will be doing what the software does: connect to a backend database. No software or web/mobile app is without a database or data store of some kind.
MS Access backend setup is very easy with many online tutorials:
Find the SQL Server instance and all needed credentials (server address or host, port, schema, user, password).
Be sure to have an installed ODBC Driver (usually already available if SQL Server is installed) or check if software has a pre-defined DSN. Free MSSQL ODBC downloads are available online. Open odbcad32.exe to see current computer driver/DSN installs.
In a saved Access .accdb/.mdb database, under External Data tab in MSAccess.exe, click ODBC database (globe icon) where you walk through a wizard to connect to aforementioned Driver or DSN (machine or user). You can either import tables or link live tables which upon successful connection will prompt you to select the database tables.
From there you can use linked tables like any other local table within MS Access including forms, reports, macros, and modules.
In fact, knowing the ODBC connection you can work in most programming languages that maintain database APIs including Python, PHP, R, Perl, Java, C#, VB, even your everyday MS Excel to interact with scheduling software's data.
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 am getting the following error when trying to deploy my SSRS reports on our SQL 2008 R2 Server "The report server cannot decrypt the symmetric key used to access sensitive or encrypted data in a report server database...". Most of the solutions on the Web suggest to delete the encryption keys, then reconfigure the datasources. I am still a beginner in SSRS, Is there another solution to fix this issue, Thanks
After checking this link Microsoft support link, it seems that this is a know issue in SSRS reports. And it seems the only way to fix it is to delete the Encryption keys.
Open Reporting Services Configuration Tool ( Programs->Microsoft SQL
Server 2008 R2 -> Configuration tools -> Reporting Services
Configuration Manager)
Go to Encryption Keys
Click Delete.
This solved my problem
I ran into this with a Microsoft Dynamics CRM 2016 Reporting Extensions Setup after changing the SQL Server Reporting Services account from services.msc. This is because the Microsoft Dynamics CRM 2016 Reporting Extensions Setup requires a non-local service account. https://technet.microsoft.com/en-us/library/hh699754.aspx The key trigger here that is likely the root cause seen in the Haasan's question was the changing of the SQL Server Reporting Services service account without backing up the encryption key. While what he did with deleting encryption keys worked, it has drawbacks of losing that encryption information and if possible, you should use the steps below to revert back to the original service account user and then change the service account using the steps documented below and in the reference article.
The identity account running the instance of Microsoft SQL Server Reporting Services where the Microsoft Dynamics CRM Reporting Extensions are running can’t be the local system or a virtual account. This is required for Microsoft Dynamics CRM reporting to work because the identity account must be added to the PrivReportingGroup Active Directory security group that is used by Microsoft Dynamics CRM.
The long story here is that when changing the SQL Server Reporting Services account, you need to do that from the SQL Server Services Reporting Manager as that will prompt you to back up the Symmetric encryption key that SQL Server Reporting Services uses and restore it with the new service account user.
The Report Server service uses the symmetric key to access the encrypted data in a report server database. This symmetric key is encrypted by using an asymmetric public key that corresponds to the computer and the user account that is used to run the Report Server service. When you change the user account that is used to run the Report Server service, the report server cannot use the asymmetric public key to decrypt the symmetric key. Therefore, the Report Server service cannot use the symmetric key to access the data from the report server database.
This will be doing the following when changing the service account from the SQL Server Reporting Services Reporting Manager:
Automatically adds the new account to the report server group created on the local computer. This group is specified in the access control lists (ACLs) that secure Reporting Services files.
Automatically updates the login permissions on the SQL Server Database Engine instance used to host the report server database. The new account will be added to the RSExecRole.
The database login for the old account will not be removed automatically. Be sure to remove accounts that are no longer in use. For more information, see Administer a Report Server Database (SSRS Native Mode) in SQL Server Books Online.
Granting database permissions to new service account only occurs if you configured the report server database connection to use the service account in the first place. If you configured the report server database connection to use a domain user account or a SQL Server database login, the connection information is not affected by the service account update.
Automatically updates the encryption key to include the profile information of the new account.
If like in my scenario, you happen to know what the previous service account user was, the fix is to change the SQL Server Report Service account user back to the originally specified account and then to use the SQL Server Reporting Services Reporting Manager to change the account and to ensure that you backup the encryption key as that process automates the restore of the encryption key when the new service account user is set.
References: https://msdn.microsoft.com/en-us/library/ms160340.aspx - Configure the Report Server Service Account (SSRS Configuration Manager)
https://support.microsoft.com/en-us/kb/842421 - You receive an error message in the Reporting Services trace log when you restart the Report Server service after you change the user account that is used to run the Report Server service (This is an old KB article, but the general problem and resolution still applies with newer versions of SQL Reporting Services)
Hopefully this might save someone some time if deleting the key is not an option.
I ran into this issue after moving the ReportServer and ReportServerTempDB from a working server to a different environment running Reporting Services. Deleting the encryption keys was not an option and I knew the password used to create the encryption key, so I took a backup of the key from the working server and restored it using Reporting Services Configuration Manager on the new environment. Refreshed the page and the error went away.