This is part three of three in a series of how to add additional security to an Azure Reference Architecture for SharePoint 2016. The design principles apply to any Azure architecture where there are servers in Azure with data.
Part one I offered 35 specific recommendations for improving security.
Part three is going to demonstrate how to take the existing reference architecture and add the additional security, more specifically the DMZs and NVAs.
Here is the Visio diagram from the original reference architecture.
And, here is the Visio diagram with the additional security.
The difference is that the updated version has the two DMZs and two NVAs to monitor and control all traffic inbound and outbound.
If you haven’t read part one, where I list 35 specific recommendations or want to review why this design, then please go back to part one, in this post, I am only going to discuss adding the DMZs and NVAs, not the other aspects of securing the design covered previously.
The repository on GitHub for this reference architecture (RA) was built as part of a Visual Studio project and they have a single PowerShell script that is used for the deployment, “Deploy-ReferenceArchitecture.ps1”. Originally, this script is what I had modified to add our additions to the architecture making it one deployable architecture.
Why I went back and took another path I explain a bit later.
This script used for the deployment of SharePoint (Deploy-ReferenceArchitecture.ps1) uses building blocks and their corresponding parameters files to automate the deployment of the Azure and on-premise resources and to configure them.
I am going to add:
(2) Subnets – Our DMZs
(2) VMs – our NVAs
(2) Additional NICs, one in each VM
(1) Internal Load Balancer
Here is a view of the building blocks section of the PowerShell script.
The URI it is pointing to is on GitHub, I would include it but since V2 of the building blocks went live on GitHub last week I don’t want to make it confusing by posting a URI that may not still work at this point.
You can see each resource uses the $templateRootUri as a portion of the path for the .json file.
Which brings me to the reason this particular post wasn’t published last week.
As the Azure Building Blocks were being slowly updated on GitHub, the URI’s were no longer working for the building blocks, which the RA’s rely on. Causing the RAs not to work also. Nothing woud deploy.
I assume this is a temporary issue while v2 was being rolled out. But at this point, v2 has been published for several days and the v1 building block URIs are still failing.
So, I decided to work around it, which actually demonstrates how you could fork the repros and customize the building blocks and RAs to fit your own needs and is probably more valuable than just modifying the existing deployment script.
What I have done is to update my fork of the v1 building blocks on GitHub with my own URIs (use must use the Raw URI).
I can’t be certain I got every URI but I was able to use two of the building blocks to supplement this SharePoint design so that won’t bite us at this point at least.
I had originally planned to update the PowerShell script used in the RA to call the building blocks, but with the changes and the massive size of this RA and the time it would take to rerun test deployments, I decided to just create my own PowerShell script. This will be helpful if you are new to the building blocks and remove some of the confusion of the VS solution used for deploying the SharePoint RA.
Building Blocks Basics
The building blocks are just like the blocks your kids play with and you played with as a kid (if you are reading this). Our foundation, providing an easy to construct starting point, consistent, sturdy.
We can use the azuredeploy.json files already available, + combined with a .parameters.json file that we can optionally customize also, to quickly deploy / build VMs, Vnets, VPNs, etc. Making an RA like SharePoint much easier to create.
We can then use PowerShell, Azure CLI, or custom ARM templates to then deploy our building blocks. Within these azuredeploy.json files are sometimes URIs that point to other building block files.
In the DMZ scenario we need VMs, Vnets, subnet configs, gateway subnets, NSGs, so on, and if we can point to the VM building blocks URI in the DMZ azuredeploy.json file to include some of those items like the NSGs or VMs then we are using the building blocks exactly as they were intended. In a similar fashion you may have done with the old wooden building blocks we used as kids.
The URIs are specifically what is broken with the v1 building blocks on the MSPP repro, which is why I substituted my own URIs to make them usable again, at least from my repro.
In this example, you can see exactly what I have done.
New-AzureRmResourceGroupDeployment -ResourceGroupName bb-dev-rg `
-TemplateUri https://raw.githubusercontent.com/mspnp/template-building-blocks/v1.0.0/scenarios/dmz/azuredeploy.json `
New-AzureRmResourceGroupDeployment -ResourceGroupName $rg.ResourceGroupName `
-TemplateUri https://raw.githubusercontent.com/anthonyonazure/template-building-blocks/master/scenarios/dmz/azuredeploy.json `
Nothing all the fancy, the azuredeploy.json file does have a URI embedded in it so I had to edit the file also. Again, demonstrating how you could fork the repros and customize them to suit your needs.
Adding the DMZs
Finally, we get to actually demonstrate and discuss how to make this all happen. I am using the DMZ scenario based on the V1 building blocks. This gives us everything we need minus the NSG rules.
Below is my custom PowerShell script for this solution. You can download the PowerShell script from my GitHub repro here, the script is named “AddingDMZ-v1.3.ps1“.
# Deploying the DMZ building block requires a VNet deployment
# This includes the Vnet-n-subnet scenario using building blocks
# template to fill this requirement and demonstrate how to also use it.
# Notice all URI's point to my github repro, the mspp v1 repro is not working.
$rg = New-AzureRmResourceGroup -Location westus2 -Name bc-dev-rg
# Create new resource group variable in my selected region (westus2)
New-AzureRmResourceGroupDeployment -ResourceGroupName $rg.ResourceGroupName -TemplateUri https://raw.githubusercontent.com/anthonyonazure/template-building-blocks/master/scenarios/vnet-n-subnet/azuredeploy.json -templateParameterUriFromTemplate https://raw.githubusercontent.com/anthonyonazure/template-building-blocks/master/scenarios/vnet-n-subnet/parameters/vnet-multiple-subnet-dns.parameters.json
# Deploy Vnet-n-subnet scenario using building blocks
Note that this scenario requires an existing resource group named bb-dev-rg,
and a VNet named bb-dev-vnet with a 10.0.0.0/22 address space.
The VNet must have one subnet with a 10.0.1.0/24 address space,
one with a 10.0.2.0/24 address space,
and one named GatewaySubnet with any address space.
$frontendSubnet = New-AzureRmVirtualNetworkSubnetConfig -Name frontendSubnet -AddressPrefix "10.0.1.0/24"
$virtualNetwork = New-AzureRmVirtualNetwork -Name "bb-dev-vnet" -ResourceGroupName $rg.ResourceGroupName -Location westus2 -AddressPrefix "10.0.0.0/22" -Subnet $frontendSubnet -Force
Add-AzureRmVirtualNetworkSubnetConfig -Name "backendSubnet" -VirtualNetwork $virtualNetwork -AddressPrefix "10.0.2.0/24"
Add-AzureRMVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $virtualNetwork -AddressPrefix "10.0.3.0/24"
$virtualNetwork | Set-AzureRmVirtualNetwork
# Deploy a new VNet with three subnets based on the requirements listed above
New-AzureRmResourceGroupDeployment -ResourceGroupName $rg.ResourceGroupName -TemplateUri https://raw.githubusercontent.com/anthonyonazure/template-building-blocks/master/scenarios/dmz/azuredeploy.json -templateParameterUriFromTemplate https://raw.githubusercontent.com/anthonyonazure/template-building-blocks/master/scenarios/dmz/parameters/internal-dmz-new-subnets.parameters.json
# Deploy DMZ scenario template
IMPORTANT! The parameter files in the scenarios folder include hard-coded administrator usernames and passwords.
It is strongly recommended that you immediately change the administrator password on the NVA VMs when the deployment is complete.
Starting at line 9, very simple, I am creating the resource group to store all resources in for the DMZs.
Line 12, I am deploying a new group of resources using a building block. You can see in the -TemplateURI parameter I am deploying the “vnet-n-subnet” scenario, which includes three different parameter files (shown below) as part of the repro, again, you could modify these, use them as a starting point, or create your own altogether.
Based on the wiki for V1 I am using the vnet-multiple-subnet-dns parameters file which I specify by providing the URI in the parameter of the -templateParameterUriFromTemplate switch.
When this completes we have a new Vnet with three subnets and a custom DNS server for the Vnet. This is in a way broken but only slightly. As is, the Vnet created in line 25 already exists “bb-dev-vnet”. It is created during the building block deployment from line 12.
Fixing it would require creating a new parameters file and it is much easier to append -Force at the end of line 25, where it is re-creating the Vnet.
To demonstrate how you need to read and understand these json files to effectively use them, here is the parameters file using in line 12. The Vnet name is the same as line 25, the subnet address spaces are also the same as specified in wiki.
"addressPrefixes": [ "10.0.0.0/16" ],
Lines 24 through 28 creates a new (overwrites) Vnet “bb-dev-vnet”, adds three subnets with the required address spaces, and one of the subnets is named GatewaySubnet. Which covers all the requirements listed in the wiki as needed to properly deploy our DMZ scenario.
The final step in adding the DMZs and NVAs is line 33. Line 33 calls the DMZ building blocks base URI and then selects the internal-dmz-new-subnets parameter file.
This parameters file actually does a lot of work compared to the rest of the script. It will take a while to run, it is going to deploy your two NVAs among other things.
Within all of these parameter files, and when we create the Vnet bb-dev-vnet you will want to make sure that the address prefixes/spaces do not conflict with already existing Vnets in your subscription. They should also connect to your new shiny SharePoint 2016 deployment in Azure or be modified to connect. Remeber this statement? “how you need to read and understand these json files to effectively use them…”
Also, DO NOT forget to change the password on the NVAs immediately or even use a more secure method to add a real password to the parameters file.
If all goes well your resource group bb-dev-rg should have 13 items in it, all successfully deployed. And look similar to this.
Your Vnet bb-dev-vent should have one loadbalancer and four nics connected to it.
And if you click on your Vnets diagram option in the Azure portal you should see a graphical representation of the connected devices. Highlighting some things that could be cleaned up in the next version of the script.
We have now successfully deployed the additional infrastructure required to provide a more secure implementation. While I did not modify any of the network settings to match with the SharePoint RA, you should make those changes prior to deploying this solution when used with any other deployment.
If you have any questions or suggestions please let me know.