Halloween is over but the the world is still a scary place. In a continuation of a thought from an article I wrote a few weeks back for Auditing AzureSQL Firewall Policies, I thought I would also include a short function for auditing azure storage accounts that are currently configured for “public” access.
Why are public access containers such a big deal? Simply put, anyone that knows the URL to the container and file can download that file. This is perfectly fine for public sites and public data (albeit you are paying for all the egress bandwidth associated with those outbound transfers in Azure… which you may not want to do). Any container that is marked as public access should have a documented business reason for why it is configured that way and any container that holds even the most slightly sensitive data shouldn’t be marked as public. I would go so far as to say, if there isn’t a particularly good reason for a blob container to be public, it’s better to just play it safe and mark it private. At the very least, you should be aware of it and keep tabs on this on a regular basis.
I recently overhauled a script that I wrote to take advantage of the parallel processing functionality that is included in Microsoft Powershell 7. The results have been excellent with script runtimes being reduced from over an hour down to roughly 5 minutes. Learning the ins-and-outs of using parallel processing was a bit of a chore that I will discuss in a later article, however the first hurdle that had to be mounted was simply getting Powershell 7 installed and figuring out how to make use of it. Quickly getting up and running with Powershell 7 is what this article seeks to address.
Let me start by saying, I really love Microsoft Azure and my brain is currently flooded with plenty of Azure goodness after earning my Azure Admin certification. Therefore I was surprised to find myself working on the Oracle Cloud Infrastructure (OCI) platform less than a week after passing the AZ-104. I find that my professional life is focused on Microsoft, Windows Server, Hyper-V, Powershell, IIS, Storage Spaces, etc. but the technical tinkerer in me is always working in the world of Linux. Additionally, my personal pet projects have personal pet budgets. So that means Apache, MySQL, PHP, BASH, Drupal, and WordPress.
I periodically review Azure PaaS resource edge security. As a part of that process I examine and cleanup AzureSQL firewall rules. Once you have more than a handful of subscriptions and AzureSQL databases, doing this manually starts becoming unfeasible. To that end, Azure Powershell is your friend…
As is typical, you need to install the Powershell AZ module on your workstation, after that you need to run.
Then supply your Azure credentials (preferably creds that have the ability to view and manage all of your AzureSQL databases and firewall rules, otherwise the rest is moot.
When your business hinges upon remote workers and remote offices, secure connections, and lots of data manipulation… how do you deal with some of your folks being extra remote? Granted the internet in 2020 is very different from the internet in say 2008 and the world has grown ever smaller as a result… but distance and all of the congested, intervening, network hops that come with it are still a reality. Particularly for remote workers living on other continents that have to interface regularly with systems in the United States as a part of their job.
The two big headaches for remote workers in other countries connecting to offices in the US are latency and bandwidth. In the past there were only and handful of solutions, most involving long-term contracts with a telcom and lengthy, complicated setups. I would argue that MPLS still falls squarely in this camp. SD-WAN has certainly improved on all of the above but it’s still enough of a headache that it typically involves contract terms and conversations with sales “engineers.”
I would like to propose something different using Azure.