ASP.NET Applications get many configuration settings from their web.config or app.config file. Being able to run the same application across multiple environments used to mean keeping control of different copies of the config file to deploy or even worse manually editing the settings after deploying to each new environment. In recent years it has become possible to do transformations of the web.config files at deploy time using Visual Studio. No matter which method you use, deploying to a new environment and detecting drifting config settings has always been a problem. UpGuard helps to quickly and easily detect these sorts of problemsand make configuration management a breeze.
Method 1: Scan & Compare
I have two load-balanced web servers. The configuration for these two machines should be identical. When I compare them using UpGuard though it picks up a few differences.
The missing hotfix is a bit of a worry, but a quick click on the link tells me it's nothing to worry about immediately. What's more of a concern is when I zoom in on the web.config of my app.
Sure enough, UpGuard has picked up that somehow my QA connection string has made it into my Production web.config.
As well as using this method to compare two machines I could also compare the scan to previous versions of the same server to detect when the change occurred. These types of changes will also appear in a daily report that I receive via email.
Method 2: Policies
The Scan & Compare method was great for helping me troubleshoot and notify me of changes, however I want to lock down my web.config even more. I'm going to use a UpGuard policy to do so.
Going back to the scan I'm going to right-click on the web.config item and choose to build a policy from it.
This will allow me to make automatic checks for any of the properties of that file that I'm interested in.
In my case I know the WEB01 version of the file is exactly what I want so I'm going to create a check for everything including the raw file contents. I can also add more checks to the policy while I'm here like services I expect to be running, ports I expect to be open, even database queries I expect to work.
My web.config check isn't finished however because I want it to run across all my environments and they obviously aren't going to have exactly the same contents as my production version. The database connection string is going to be different, as is the debug="true" flag that we allow only in our first test environment. This is where policy variables come in. I'm going to replace those parts of the web.config in my file check with variables that I can override at the environment level.
I could now schedule this policy to be run across all servers running my web app every 15 minutes and notify me immediately if anything fails.
Misconfigurations are an internal problem that emanate from within the IT infrastructure of any enterprise; no hacker is necessary for massive damage to occur to digital systems and stored data. And the problem is pervasive, with Gartner estimating anywhere from 70% to 99% of data breaches result not from external, concerted attacks, but from internal misconfiguration of the affected IT systems.