I work for a company which, as most companies around the world, is forced by Government regulations to do remote working. We have an office downtown with a pretty-less-than-adequate fiber connection to the network.
We have all environments on MS Azure. In the office-working era, Azure firewall was configured so that services which did not require public internet access, e.g. SQL databases and key vaults, were accessible only by the fixed IP of the office, which worked great.
One could set up a development environment pointing to dev instance of SQL Azure and authenticating using SQL authentication (see note 1). SSMS uses AAD identity directly. All connections came from office, so Azure is configured with defense-in-depth in mind.
Now that developers work from home, and exit with dynamic IPs, troubles have started to come. What we are doing since a few months, being the dev team made of 2 people (long story in note 2), is to manually enter IP addresses in Azure Portal as displayed by whatsmyip.org in the morning.
In the middle-term, we want to expand our SW development team and the "change-your-ip-address-in-the-morning" policy is not good at scaling and requires too many people accessing Azure Portal with proper permissions to set firewalls.
Here is the options I have considered and why they are not applicable or did not work
Solution 1: change your IP address in the morning
Not scalable. As the dev team grows, confusion can be made on the whitelists of IP addresses to enable in Azure firewall. The dev needs to enable their own IP address in both SQL instances and Key Vaults for the project they need to work, and it is realistic that they may need to access multiple projects during the same day.
Solution 2: VPN into office
Not practical at this time. At the time the office was full of people, the bandwidth usage was high enough for some to complain. VPNing, and routing all traffic via VPN, requires double the bandwidth.
It's not easy, cheap and timely to buy additional transfer capacity. I mean, the problem may not be price but the technical availability of additional Gbps: you can't just call your business ISP and ask for an additional Gbps to be enabled overnight.
This will be our preferred solution when we will get a faster link in the future.
>>>> Solution 3: Azure VPN <<<<
This is my theoretical preference, and is the subject of the question. The developer would just need to VPN into Azure every time they need to run the application, so that connections to Azure resources come from a well-known whitelisted network.
This is very ideal, but unfortunately when we configure example.database.windows.net, the traffic is routed via public internet (i.e. via home link) and then the exiting IP is not whitelisted.
I have examined the routing tables of a client connected to Azure VPN and in fact only the private subnet 192.168.13.0/24 is routed via the VPN tunnel. This because the SQL host resolves to a public IP address.
Solution 4: RD-development
Where RD stands for "remote desktop". IMO this is a suicide because even clicking on widgets is fully affected by the employee's home bandwidth and not everyone can use a fiber channel home (FTTH). The only advantage is that the RD machines would be already in a known whitelisted network. I know that a lot of companies use this, but we are talking about "work from home" in a country where, despite the good intentions of an employer to pay internet to employees, fibers are just unavailable at the employee's location.
To be more clear, one thing is to run SQL queries against a cloud SQL Server, another thing is to have to transfer amounts of data to render the 1920x1080 window of Visual Studio displaying the value of a particular record during a debug session (included stepping keystrokes).
[edit: summarizing comments as an edit]
I am discarding this solution both because of opinion/experience. Both the CTO and I had an awful working experience in the past when we worked as consultants. A that time, I worked in a company with a 100Mbps DSL link and 30+ coders working in RDP. It was absolutely awful and slow. The company I worked for struggled to upgrade link speed but I left long before they switched to a faster ISP.
So I must accommodate for developers who don't necessarily live in the centre of a big city, who normally have to commute from a small town. Small towns/villages don't have access to fiber links and the scenarios, from middle to worst, range from the availability of 4G connection (which the employer could decide to supply) to the availability of only 3G/HSDPA. Some places are just not reached by cables or antennas, and at that point the only hypothetical solution would be the employer offering some kind of relocation ("we rent you a small flat somewhere closer"). Not feasible.
Mobile links are a risk as well. It could be that the mobile link works, and the employer can rely the employee will work using mobile link. But with the increased use of videoconferencing and remote schooling, there is a chance that the remote link will be unavailable.
Of course, an intermittent or slow link prevents access to Azure SQL in the first place, and supposedly the developer can't work when they can't reliably connect to Azure because of the above.
The point why we are against this solution is that during normal development experience (✋ I have been a coder for years!) you don't necessarily require continuous and reliable connection, as you can type and read docs without a stable link. But coding in RDP requires that every keystroke and page refresh is transmitted correctly.
[edit: anectodal seasonal example]
The following is of course just an anectode from Summer 2020, and does not want to make any kind of statistics or rule. This August I was working all month, on a totally different environment where I could (ab)use Docker and work 100% offline. That saved me, because I spent the entire summer on a summer location, ie. a small village that became crowded just for two hot weeks.
It was so hot for the place, in the sense of tourism, that the 4G network mostly collapsed for those two hot weeks. I could work only because of Docker, and I couldn't watch online videos in my personal time. Before most people came to spend holidays, and after they left, I experienced an excellent 4G link with my own SIM card. Of course, network providers do not provision faster links for remote locations, and throttle bandwidth in the seasons where the locations are mostly crowded. Just for two, damn, weeks.
And yet again, the above is just one, personal, experience with networking.
Question
How can we allow remote developers to access Azure resources in a secure way? We can't just disable IP whitelisting. Yes, authentication and TLS are in place, but it's a company requirement (and I also think a best practice).
We must preserve the ability for the developer to work. In case the connection is slow or intermittent, the requirement to access remote resources is obviously the bottleneck.
I think, according to solution 3, that we should somehow tell the VPN to route the Azure traffic via itself. I don't know if it's possible or not, but the VPN would need to know Azure IPs in advance.
I am confused about this topic. I'd like to ask if other companies have found an elegant solution to this kind of problem.
[Note 1]: actually, the connection string is protected in Azure Key Vault which is configured for AAD identity, so developers don't share the connection string for their EF Core applications
[Note 2]: we currently hire consultants from an external factory that VPN into their office (solution 2), but we intend to hire internal developers in the future
