Scenario :: we want to enable communication between on-premise SQL Server and Azure SQL MI which should be super secure and fast.
After researching a lot, we have found two solutions::
Public endpoint
Site to Site (VPN)
Question :: now we are confused about which way we should go-ahead and Why?
Requirement :: have connectivity between on-prem SQL server and Azure MI so that we can push data to Azure SQL MI via a custom-built application.
The VPN option is difficult to configure if you are not a network expert. You need to have good knowledge of VNet, ExpressRoute and VPN P2S and understand new notions of Azure networking. The VPN option does not provide separation of duties. The VPN option has also some known issues in terms of throughput so the endpoint gives you better performance.
The public endpoint option is easier to configure and allows for separation of duties. Your database administrator will enable the endpoint and the network administrator will make accesible the endpoint by opening port 3342 and provide a UDR route. Your DBA will need RBAC permissions on scope Microsoft.Sql/managedInstances/* while your administrator will need permissions on Microsoft.Network/*.
Related
I have an Azure SQL Managed instance with public endpoint disabled (we store sensitive data and do not want an exposed endpoint on the DB). We have a VNET and when we need to access our SQL managed instance from an administrator's machine, we use a VPN. How do I connect Power BI to my SQL Managed instance for reporting? I've been digging and am surprised that the only way I can see is to either:
Create a virtual machine and host a data gateway
Expose the public endpoint on the SQL Managed instance.
I may accept 2 if I can limit access to Power BI itself but I'm not convinced that's possible.
Any suggestions are welcome!
You can also secure the public endpoint allowing access to powerBI only using Azure Service Tags. Documentation can be found here https://learn.microsoft.com/en-us/power-bi/admin/service-premium-service-tags
I'm confused with some of these supposed solutions since I'm looking at PowerBI.com and it only has 4 options and managed instance is not one of them....
See: Create Dataset - Databases & More option and there's only 4 options for connecting to a database... That's it folks.
Sure you can connect from desktop but that won't do you any good once you publish it to powerbi.com unless that site supports connecting to the source.
Yes you can create a gateway which I believe is currently the only solution. Why oh why isn't Managed Instance one of the options for databases when you create a dataset on powerbi.com? That tells me they do not support it, regardless of whether you've enabled public endpoint. As far as I know you still would have to use a gateway to access it if it's not one of these options. Or...something silly like create Azure REST services just to talk to your database.
I have a Web App (Azure App Service) and I have an Azure SQL Database that this Web App talks to. I have two questions regarding communication between the two.
When connecting from the Web App to the Database (using the connection string), does the communication go out to the internet and then back into Azure or does Azure know to keep the traffic locally in Azure?
I have been looking into V-Net Service Endpoints as a possible way to improve speed of communication between the two. It is said that when connecting from a VM on V-Net with Service Endpoints enabled to a SQL Database, that Azure knows to keep the traffic internal to the Azure network and not go out to the internet, is this the same for Azure App Services?
Is it possible to keep traffic between an App Service and SQL Database internal to Azure? If so, how do I go about doing this? Any guidance on this is greatly appreciated.
It knows to keep it local on the "Azure backbone" (as per Azure doco). It doesn't go out to the public internet
Yes
Yes. It is already internal to the "Azure Backbone"
Having said that.... networks are really complicated.
As I understand it the main benefit of V-Net is that you can define your own network and add things to it like firewalls, security groups, subnets, peering between networks. Also it helps when setting up a hybrid network - i.e. connecting Azure resources to an on-premises network. When you can set up the same kind of structures as on premise, it's easier to 'transparently' make it part of the on-premises network. Lastly (rereading the doco), you can remove any incoming public IP firewall rules. These are "Azure backbone" IP addresses but they are also "public internet" addresses
There may be a performance improvement if the App Service and Azure SQL are on the same V-Net.
Azure SQL service endpoints are a bit mysterious. They "connect" to the VNET but you still need to connect to a public address. They don't actually take a up a local IP adress.
Depending on what you are really doing, you might want to look into private endpoint, which actually assigns a private IP to your Azure SQL.
Yes, communication between Azure App Service and Azure SQL Database is "local" within the Azure Virtual Network and does not go out to the public internet.
The problem I have is that we're trying to use our WebApp in Microsoft Azure to connect to an external SQL-database (not our own) through a VPN. The SQL-database is only allowing connections from our local IP-addresses that we put up as a Network (for example 176.0.0.0/24).
We are now connected to the same virtual private network, and through our Azure-VM we can now connect to the SQL-Server through SQL Server Management Studio.
Now we want to do the same with a WebApp, but we're not getting through to the server. It gets "Not authenticated" before reaching the SQL-Server (probably the server isn't accepting our IP from the WebApp).
The different problems I have tried to look through is:
Do we only try to connect through our Outbound IPs?
Is the WebApp not connected to the VPN?
I have unfortunatley not found any real answers, and neither any solutions to my problem. If you have any ideas of how to solve our problem, or maybe know how I could tunnel all of the SQL-calls through the VM, the help would be very much appreciated!
Hybrid connection is one option. What you can also do is enable point-to-site in your VPN. Once you do that, you can directly integrate your web app to the vnet and your connections will work. (Go to your web app -> Settings -> Networking -> VNet Integration)
If your Vnet is V1(older way of creating VNs) then enabling point to site is very straightforward. You can do it through portal. For V2 Vnets you have to do it through powershell commands.
Here is a link for the documentation which explains both the options.
https://azure.microsoft.com/en-in/documentation/articles/web-sites-integrate-with-vnet/
There's a way to "tunnel all of the SQL-calls through the VM". You may want to use hybrid connections (cf https://azure.microsoft.com/en-us/documentation/articles/integration-hybrid-connection-overview/).
The principle is to have an agent installed on the VM that can access the database with the correct IP address.
Suppose you can access the SQL DB as mysqldbsrv from the VM. You add an hybrid connection associated to your web app, you install the agent on the VM. Then, when you connect to mysqldbsrv from the Web App, you go through the VM.
We have developed a cloud based POS system which running on more that 75 outlets and all the transaction data need to be posted every 5 minutes to the relevant database which sits on our head office (POS System is connecting to its own local database). For this we are using windows application which is directly connecting to our head office database through a VPN. But recently one of our clients raised a concern that our head office database is exposed because if anyone sneak to the network (obviously inside the VPN) he could see all CRUD Operations. So by this way he could do anything to head office database.
So we have decided to go for a WCF solution with encrypted JSON Call. If we use a web service can we eliminate this issueccompletely. Is it the best practice? Please advice.
There are several aspects of security to consider in your situation. If your current network topology doesn't limit the VPN client's visibility to just your database server, then yes, I agree that moving to publishing a web service endpoint and using HTTPS would improve security by blocking clients access to other servers on your internal network. However, the web service solution introduces some other considerations. Will you use firewall rules to limit which clients can access the web service? How are you authenticating clients, and how are you protecting those credentials from unauthorized users?
I read somewhere:
Analysis services should run under
network account
Ensure SQL
Browser uses a domain account
Why is that?
I did not find documentation dictating those restrictions on those 2 services. These two articles seem to give some discretion to the user on how they want to set them up:
SQL Server Configuration - Service Accounts
http://msdn.microsoft.com/en-us/library/cc281953.aspx
SQL Server - Setting Up Windows Service Accounts
http://msdn.microsoft.com/en-us/library/ms143504.aspx
The only caveat I see is for the Analysis Services service in a failover cluster configuration, it says For failover cluster configurations, use the domain user account.