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.
Related
My question is as follows: I have local servers with SQL Server database and I have a server in google cloud also with SQL Server database.
I link these servers through the Linked Server functionality of SQL Server itself, where one server can see the other.
This link is OK and working.
My big question is regarding security, when making this link between my local servers and the google-cloud server, how vulnerable am I to the network?
What is my security risk in doing this?
The Linked Servers function uses a driver named OLE DB to connect. How vulnerable you're really depends on the version of said driver, if you're using the last version it supports TLS 1.2 which ensures that the information is private and secured.
The most notable risk resides on how secure your Google Cloud SQL account, besides that the GCP is a secure environment for your DB, as mentioned in the FAQ:
Cloud SQL customer data is encrypted when stored in database tables, temporary files, and backups. External connections can be encrypted by using SSL, or by using the Cloud SQL Proxy.
Google encrypts and authenticates all data in transit at one or more network layers when data moves outside physical boundaries not controlled by Google or on behalf of Google.
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.
If I only have one VM in Azure I can get outtages at any time when Azure decides to reboot/reprovision my server. Therefor I have to at least two servers in an availability group to get a stable environment.
This is used by a web app (web roles) and an important aspect is that the databases are used for reading. They will get their data from sql replication from an on-premises database. The replication can be done separately to each database. Additionally using Azure Sql Database is not an option because we have not be able to implement a durable data sync solution (using Microsoft Sync Framework), Sql Database does not support sql replication, and constantly uploading the complete database would be too slow.
How should the database VMs be hosted and accessed to able to use Sql Server VMs?
One alternative is to use AlwaysOn Availability Groups. This however requires Sql Server Enterprise edition and the price is very high considering I need to have at least two servers. In this scenario I at least get one connection point behind which a sql server always should be answering. This is however beyond our reach because of the cost.
One alternative could be to use Traffic manager to round robin the connections. When the database server goes down we have to wait for TTL to expire before the webrole would refresh the ip address so that seems a big problem.
How should one host Sql Server VMs in Azure?
You can use FailoverPartner parameter in the connection string to specify the secondary replica address. You can see more in this article.
we're close to migrating our legacy MS Access app to SQL Server for our internal warehouse management system. Our customers are often asking us for access to the data for e-commerce integration and general reporting. Once the migration is complete I would like to provide open access to the data via web services and odata. However I don't want to host these services as we are on a slow ADSL connection which won't cope with the traffic.
My question is, can I replicate (one-way) to a remote DB hosted by shared-hosting companies such as Hostgator? I see they have shared windows hosting with unlimited MS SQL DBs. Are there any special requirements on the hosted-side? For instance do I need to explicitly set-up replication on hosting db or is it managed on the client-side?
If this is possible then I might be able to run all our web services and reporting apps on the host's servers, and only the replicated data need travel over WAN. What sort of control is there over replication? Such as bandwidth throttling, replication periods etc? For instance when & how often does replication take place?
I'm new to SQL Server in general and some of the topics are a little overwhelming.
Thanks for your help.
You could try setting up transactional replication with a push subscription with the distributor on your side. The relevant bit is how the distribution agent connects to the subscriber. distrib.exe supports both trusted and SQL authentication, so you should be good to go either way.
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.