We need to migrate our SQL Server DBs on Windows 2003 to new environments with Windows 2008 or above.
The users access the current DB mainly via Excel from their desktop PC.
I have considered Azure as one of the alternatives, but as far as I've studied, it's difficult for us to adopt it as there are security concerns as below.
SQL Server authentication is the only alternative and anyone can access the DBs once they come to know the username and the password.
The communication of data can't be encrypted though the stored data can.
Could anyone point out if my understanding is wrong or advise me if you know any ways to untangle my concerns?
SQL Server authentication is not your only option. If you create a site-to-site VPN tunnel between your organization's network and the virtual network in Azure, you can join the VMs into your AD domain. Here's an answer on ServerFault for how to do that.
By using site-to-site or point-to-site VPN your users are connecting through an encrypted tunnel so the data is encrypted in transit.
The other advantage of VPN is that you can setup your Network Security Group rules such that the SQL servers can only be accessed from within the virtual network or through the VPN.
Related
The basic question is this, if our Windows service uses Windows Authentication for connections to SQL Server, and then because of a network disconnect, SQL server and/or the client machine cannot reach AD to authorize or authenticate, will our service still be able to connect to SQL Server and operate?
I’ve tried it and it seems to work, but we are concerned if it will work even after a few days of being disconnected or after server reboots and the like.
The alternative would be to use SQL Server Authentication, but we would rather not have to deal with potentially exposing and having to protect the password on the client computer. This computer may be in a remote location with little supervision. SQL Server would typically be running on this same remote computer.
And for the follow up questions, does it matter which edition of SQL Server we use? Does it matter that both SQL Server and the service are running on the same computer?
If AD connection is lost, existing SQL connections will keep working (at least for some time), and connection pools will be still available (again, for some time). However, I wouldn't get too comfortable with this, because these time spans might depend on settings outside of a typical DBA' reach.
Alternatives are:
Use an AD proxy. Depends on circumstances, might not be always viable;
Use local user accounts instead of AD. Works always.
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.
The solution consists of an SQL Database and desktop application working hard with that DB. DB Deployed as Azure SQL Database, application running on Azure Virtual Machine with Windows Server onboard. What is the deployment guidelines for this two services in Azure? I want to achieve max performance. Should they both be located in same resource group?
You will need to get your app and the database located as close as possible so yes the same resource group.
Make sure you do not have Mars enabled (MultipleActiveResultSets in connection string).
Make sure you do use connection pooling.
Read this to understand what you are dealing with:
https://www.simple-talk.com/sql/learn-sql-server/improving-the-quality-of-sql-server-database-connections-in-the-cloud/
Ed
Currently our windows desktop applications run against a SQL Server instance that resides on our network. I'd like to remove the local instance and seamlessly assess the data from a remote SQL Server instance such as Azure. I could write a middle tier, such as WCF, but I'd rather not. It would be easiest just gain direct access to the SQL server. Can this be done?
Thanks.
Yes. - http://msdn.microsoft.com/en-us/library/windowsazure/ee336282.aspx
You'll need to ensure that the Azure SQL Database firewall rules are set up to allow traffic from your IP.
If you are running full SQL Server on a Windows Azure Virtual Machine you can open the port to the SQL Server. Be aware that you'd likely want to ACL the endpoints on a VM to restrict access to your IPs.
Remote SQL Server and Azure could be very different things.
First difference that you will found is the Connection String form. Azure SQL connection strings looks like:
Server=tcp:xxxxxxxx.database.windows.net;Database=xxxxxxxx;User ID=xxxxxxx#xxxxxxxxx;Password=xxxxxxxxxx;Trusted_Connection=False;Encrypt=True;
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)
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.
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.