I have question around DLP (data leakage prevention) from a corporate network.
I have a Virtual Machine on a corporate network. The VM can access an Azure SQL DB in the cloud: aaa.database.windows.net through a connection over port 1433.
However, I don't want that same VM to connect to bbb.database.windows.net.
Azure offers no guarantees on the public IP (both servers could appear as the same IP) - what technology can I use on the corporate's perimeter network/firewall to permit access to aaa but disallow access to bbb?
The attack I am concerned about is someone internal to the company querying data out of aaa and inserting it in to bbb. For example, if the one server is ourcorporatedate.database.windows.net and the other is somerandom.database.windows.net the someone internal to the company could take corporate data and write it to some random database.
Thanks
You can use Virtual Network service endpoints and rules. Virtual network rules are one firewall security feature that controls whether your Azure SQL Database or SQL Data Warehouse server accepts communications that are sent from particular subnets in virtual networks. Learn how to use it and benefits/limitations on this documentation.
If database aaa and bbb have the same public IP address. I think there is not a good way to set in the on-premise firewall to permit access to aaa but deny access to bbb. From the same client, the firewall rule will have the same source IP, protocol, port, and destination IP for outbound traffic.
If you want to selectively grant access to just one of the databases in your Azure SQL server, you can only create a database-level rule for the required database. Also, Specify an IP address range for the database firewall rule that is beyond the IP address range specified in the server-level firewall rule, and ensure that the IP address of the client falls in the range specified in the database-level rule. Server level rules allow access to the Azure SQL Server. Which means that the client will have access to all the databases stored on that SQL Server. Refer to this doc.
The current VPN feature in SQL Azure does not directly prevent this (but please look for future updates where this is planned for the service endpoints feature for SQL Azure). However, there are various mitigations you can use to detect or reduce the ability to do this:
You can enable auditing on the aaa database. This can detect all logins and major state changes to the DB. (Detect)
You can reduce the permissions for various kinds of users on the database to the bare minimum and use features which further reduce the size of the data that a customer can copy out of the database at all. This includes row-level security, data masking, always encrypted (which you would lock down to a specific app/user to be able to decrypt sensitive data in the client - other clients without the key just get cypertext), etc.
Use firewall rules (as stated in the other answers) to restrict which clients can connect to the database at all - then you can restrict where they can connect with permissions.
Please note that SQL Azure's logical servers do not generally imply that every customer database in that server has the same IP. Currently there is a knob in service endpoints (docs page is currently down so I can't get you a link atm) to configure whether you go through the per-region gateway or not. If you don't (recommended), you would see the IP of the hosting node and this can change over time. The Service endpoints feature will give VPN users more control for network-level rules going forward, but some of these features have not yet landed in production. I encourage you to mitigate with other steps (above) until that is available to you.
Related
I have a logical Azure SQL Server (Paas), this server hosts dbs for an in-house desktop app for people in multiple countries. I want to be able to geofence access to the server only to those countries where I know my clients are.
Using the firewall rules on the server doesn't work because not all my clients have static IP addresses, so I need to be able to accept connections from any IP originating in those countries, which are far more than the 128-entries cap on Azure, even mixing database-level rules with server-level rules isn't enough because that only gives me 256 entries (not to mention the headache it would be to keep that updated).
So, how do I limit access to the server to only those specific countries where my clients are?
I have a non-azure, non-Windows, non-microsoft site-to-site tunnel set up between an Azure cloud environment and an on-premise LAN; at the azure end, the proprietary (non-microsoft) S2S host sits behind an Azure load balancer.
The proprietary tunnel is route-based and as such, I'd like to route connections all the way from our on-premise network to various resources in Azure.
e.g.
OnPrem Server -> OnPremFw -> (tunnel) -> CloudFW -> LB -> vNET1 -> vNET2 -> VMtarget
When packets hit the CloudFW, they are being "Hidden NAT'd", so the source IP address is translated from its On-premise IP address to an IP address recognised by Azure as directly associated with an Azure subnet range. In this case, things work as expected.
However, if I turn off the H-NAT, so that packets carry their original on-prem source IP address in to Azure, then no matter what security or routing rules I apply, nothing works.
Is it plausible that Azure is passively dropping these packets, or is silently screening them out, something like address spoofing?
I can't find any Azure documentation confirming this, but the behaviour I am seeing strongly implies this must be the case. Could anyone confirm?
I would like to know if essentially, it isn't possible to use "non-Azure" IP addresses in Azure routing and security configurations.
thanks
The answer to this question is No.
It is possible to use non-Azure-defined IP addresses in Azure route table rules and in Azure nsg rules.
I've been reading about how you should set specific service accounts to each sql service, but from what i've read, none have been detailed enough on how to properly create one, would anyone mind explaining what would be the steps on how to create a local, low permission account for the sql service on windows?
Some basic information is available at http://msdn.microsoft.com/en-us/library/cc281953.aspx
I tend to make domain user accounts with no particular rights on the network apart from what the account would normally receive (eg domain users). During SQL Server installation you provide these accoounts to the SQL installer - it will correctly configure the accounts for you (adding them to certain groups, etc).
If you're doing it after SQL installation the correct way to change the service account is to use the SQL Server Configuration Manager (in your start menu) as it will ensure the accounts are, once again, correctly configured.
Using domain accounts is great as you can then grant the service accounts access to particular network shares (backups) and other database servers (linked servers, etc).
As an additional measure if your network resources (file shares, etc) are secured using custom made security groups, rather than "domain users", your SQL Server services won't have access to these areas of the network they shouldn't be able to reach. I personally haven't tried removing the "domain users" membership - you can't break anything by giving it a go on a VM? :)
This site describes the different options to use the least privileges and the danger of the other options:
WHEN TO USE DOMAIN USER ACCOUNT?
WHEN TO USE NETWORK SERVICE ACCOUNT?
WHEN TO USE LOCAL USER ACCOUNT?
WHEN TO USE LOCAL SYSTEM ACCOUNT?
-
-
http://goo.gl/vG55n
I'm now thinking about moving to s3, but I'm still concern about the restriction policy in my country in the future, so I'm wondering if I can use some DNS service or some other way to solve this problem.
It's doubtful that DNS can help with this issue.
In general, it's quite difficult to bypass such restrictions if there is an entity that has complete control over the borders of its network. It could be anything - from a government blocking opposition sites for political reasons to a company blocking access to insecure web mail providers for security reasons.
If an entity wants to block a specific service provider, it's easier, more effective and far more efficient to simply block all IP address blocks that belong to that provider. DNS is at a higher level and will not help with this issue.
What would help is an unblocked proxy (relay) or VPN service. You connect to that service and tunnel any connection to your intended service provider through that connection. It could be:
A proxy server abroad that is not blocked. There are commercial proxy/anonymizer services that may be able to help here, although the most known ones are bound to be blocked too.
A VPN connection to an unblocked network e.g. a business partner.
An application such as Tor. This option usually implies a very significant performance drop and should not be used for high data rates (anything above a few KB/sec).
If you use a remote proxy or VPN server you should contact the owners and find out their policy for something like this.
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.