SQL Server secure connection using Windows Azure Connect

Question

I am setting up a system that runs on Azure but needs to access an on-premises SQL Server. I've built it out as detailed in this article. This calls for me opening port 1433 to the world which looks like a serious security problem. Is there any way to open that port and still have it secure (I know that I can have complex user ids and passwords and everything, but is there a better way to secure SQL Server)

Answer 1

The connection between your on-premises DB and Windows Azure Connect will be secure by default via the IPSEC protocol

"Windows Azure Connect uses industry-standard end-to-end IPSEC protocol to establish secure connections between on-premise machines and roles in the cloud. Unlike a traditional Virtual Private Network (VPN), which establishes secure connectivity at gateway level, Windows Azure Connect offers more granular control by establishing secure connections at a machine and role level."

http://blogs.msdn.com/b/usisvde/archive/2012/03/14/windows-azure-security-best-practices-part-6-how-azure-services-extends-your-app-security.aspx

Your DB won't be publicly available, only VM's on the Azure Connect will be able to see it.

Your traditional firewall and on-premises security policies and procedures will still hide your DB in your Enterprise Environment, all you are doing is giving Windows Azure VM (Roles) the ability to see it.

Answer 2

I saw the comment discussion on @user728584's answer about opening port 1433. Port 1433 has nothing to do with Azure Connect, which is essentially a VPN tunnel between on-prem boxes and a collection of Windows Azure role instances. Azure Connect requires an agent to be installed on any on-prem server you're adding to the Connect Group and doesn't require an inbound port to be opened. In your case, you'd add the agent to your SQL Server box, which would then be part of the connect group and accessible directly from your Windows Azure Role instances (for the roles you add to the group). The Connect Agent then establishes the tunnel.

The Connect Agent has a special key baked in, generated for you, making it unique. But even if someone somehow obtained the installer for your specific Connect Agent, it wouldn't help at all, as you still need to add that node to the Connect Group. So, this is a secure setup.