Secure transfer of data from SQL server to SQL server over the Internet - sql-server

I need to transfer data daily from SQL Server (2008) to SQL Server (2005). One of the servers is located at our web host so the data will be transferred over the Internet. On the same network I would use SSIS to transfer the data, but over the Internet this is not a secure option. Is there a secure way of achieving this?

You can use SSL with SQL Server (2000/2005 Instructions / 2008 Instructions) and then force protocol encryption on the connection between both machines. You don't have to use a purchased SSL certificate either, you can use Windows Server Certificate Services to generate one - however if you do so then the CRL must be on a machine that both servers can connect to. An easy way to do this is install Certificate Services on a stand alone machine, perhaps just a VM and the configure it to embed a public DNS name for it's CRL. This doesn't have to be a machine running Certificate Services, just something you own and can upload to. Then you can generate the certificates and publish the CRL and tada, all done.
You will need to ensure the service account SQL is running as has access to the private key of the certificate it is using.

Generally it isn't recommended to have your SQL Servers exposed to the Internet, although that may be out of your control in this case. In your position I would investigate developing some separate Web Services that would perform the transfer of the data. These can then be secured using a variety of methods, such as SSL and WS-Security and other custom user permissions. If that isn't possible then blowdart's answer seems like the way to go.

You can use Service Broker:
Built into SLQ Server engine itself, no need for external process to drive communication.
Compatible protocol SQL 2005 and SQL 2008 communicate over Service Broker out-of-the box.
No need to expose either server to the internet. Through Message Forwarding you can expose
just a SQL Express, with no data on it, to the internet to act as a gateway that lets messages into the back end target.
Communication is encrypted.
Speed, the sample in the link shows how you can exchange over 5000 1k payload messages per second between commodity machines.
Unlike SSIS or replication Service Broker is a general communication framework so it won't provide support to extract the changes and to apply the changes, with conflict resolution and the like. You would have to code that part yourself.

Related

Transactional Replication to Azure SQL DB - How to Encrypt 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.

Access SQL Server via StaticIP( from outside and access it locally(Intranet) as well

I want to access SQL server via an application (it is a desktop application) which is installed on remote location, where as SQL server installed in Main Office, where other applications are also accessing same SQL server on LAN.
Is it possible to do it?
Yes, technically this is not problem. Once installed, SQL Server will react both on the internal IP and external - if the Firewall is configured to forward SQL-Server Traffic (TCP 1433).
BUT - from security point it's not a good idea to expose your SQL Server directly to the internet. In the past there have been several security problems that would have exposed more than you wanted to expose. I would suggest external users, not inside your LAN use a VPN Connection to get inside your internal Network. I work every day over VPN with SQL Server and it's stable and secure.

How to secure a database using web services?

Now an application is connected to a database server in the same LAN and performs selects and inserts.
The database will be moved to a remote location accessible throughout internet. Performance degradation will be addressed reducing the number of operations to the db. It is not possible to use vpn or configure access-in rules based on client IP on the firewall of the net where the database server will be moved. So it seems to me it is necessary to create a database front end in order to protect it. I suppose one way to achieve this goal is to create a web service.
Are there easier alternatives?
I'm new to web services: it should run into Glassfish server while the client would be a c# application.
I read a bit about securing a web service but I'm a confused.
One method I found in internet is to use Glassfish built-in authentication mechanism and configure web.xml limiting the access to the web service URL to a group of users.
It seems an easy approach, are there any drawbacks?
Is it easy to use this type of authentication in the C# client?
Other existing web services wants a parameter key in the request. Then this key is compared with valid ones and if the check is successful the request will be accepted.
Is this approach more secure than the previous one?
Another alternative is to use WSIT but at a first glance it seems over-complicated and all the security mechanisms need a server certificate.
Anyway it looks more secure; does it fit well with JAX-RS and restful web services?
You can use L2TP or PPTP VPN in this case.
Let me show you first Network topology.
Client (accessing firewall with L2TP or PPTP )-----> Firewall (L2TP or PPTP VPN Server)---> Firewall LAN where your Server placed.
In above case all Client come from VPN so its secure and On firewall you have to Configure VPN to LAN rule with client base rule.

Communication of VB6 application outside client network with SQL server inside network

Is there way to make the vb6 desktop application which is not on client network to communicate with sql server which is in the client premises?
A far better option (a necessity if the app is for general distribution) is to use an intermediary service, either over web/HTTP or some other (possibly custom) protocol.
If you app is specific to your company/employer for their internal use, then you will need to use a VPN or similar to allow it to work as if it was on the same internal network.
Note that opening up a database server to the wider internet is asking for trouble and should be avoided at all costs.
Easiest would be to use port forwarding on border router to SQL server.
Better would be to encrypt traffic to/from SQL Server like this: IPSec through NAT: Securing SQL Server remote connections

What services are required by SQL Express/SQL Server?

One of our partners recently reported that our software could not contact a remote instance of SQL Express until they started the RPC Locator and SQL Server Browser services. Where would I find a list of services that must be running, on both server and client, to enable remote access to SQL Express and/or SQL Server?
Sadly, the SQL Express documentation does not appear to include this detail.
SQL Express always installs as a named instance (servername\sqlexpress) and hence has a dynamic port assigned to it. The SQL Browser service is required for clients to locate the instance. Without the SQL browser, a client won't know what port the service is listening on.
Looking at my current installation of SQL Server, I have remote connections enabled and working and both RPC Locator and SQL Server Browser services are disabled on the machine.
The key is that you have to enable remote connections properly in the Surface Area Configuration Wizard.
I've experienced problems in the past running linked server queries if the MS DTC (Distributed Transaction Co-ordinator) service was not running
I don't know of any services that need to running on the client (unless they're application dependencies), but for the server, this KB article explains how to enable remote connections to SQL Server: http://support.microsoft.com/kb/914277.
By default, SQL Express is configured to only allow local connections. The gist of the article is: use the Surface Area Configuration tool to tell the SQL service to listen on tcp/ip and/or named pipes; then enable the SQL Browser service (or don't, and use a specific port in your client connection); and finally, poke a hole in your firewall. Anecdotally, I think most people have the most trouble with the firewall exceptions.
I think the RPC Locator service is more of a general windows service for handling COM calls, so I'm not sure it's fair to characterize it as a SQL-specific requirement; your app may require it to connect, but I don't know that every app would (e.g. Mitchel says that his installation works fine w/out it).

Resources