2

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)

Jeff Hornby
  • 12,948
  • 4
  • 40
  • 61

2 Answers2

2

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.

Mihai Chelaru
  • 7,614
  • 14
  • 45
  • 51
user728584
  • 2,135
  • 2
  • 21
  • 24
  • I can see how using IPSec is going to protect the communication from my Azure web instances back to my database, thereby preventing, for example, man in the middle attacks. But how am I going to prevent a port scanner from seeing that port 1433 is open and using that as an attack vector? – Jeff Hornby May 21 '12 at 03:08
  • Your Enterprise Firewall will (should) block that, your DB will not have a NAT address so it won't be publicly accessible, port scanner from outside your LAN wont ever see the port open. (I'm not an expert on security but that's my basic understanding). Test it from home or 3G or speak to your security/firewall team for a deeper understanding of how your Enterprise Environment works e.g. F5's, Hardware Software Firewalls, Network Boundaries and DMZ's – user728584 May 21 '12 at 03:21
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.

David Makogon
  • 69,407
  • 21
  • 141
  • 189
  • Totally agree, I didn't go down the path of the whole agent process and the tunnel as I read it as Jeff thought opening port 1433 would publicly expose his DB to the entire world. Standard Enterprise security guidelines along with the secure VPN tunnel that the agents creates should make everything a secure setup, assuming existing security principles are in place outside of Azure Connect! – user728584 May 21 '12 at 03:54