One of the great features of the cloud is that you can easily build totally isolated environments. What I mean by this is that different applications that don’t need to be able to talk to each other can be totally and completely isolated from each other. The biggest advantage of this is going to be from a security angle because if the web property is compromised via the Internet, there is going to be no way to move laterally from one environment to another.
Let me give you an example of this from DCACs lab environment. We have a large virtualized lab environment in Los Angeles, CA. We also have a lab environment in Azure. We also have our website (that you are probably reading this post on) in Azure as well. This is an Azure App Service as well as Azure SQL DB for MySQL hosting the database. This is all hosted in an environment which we call “Web” while the lab platform in Azure we call “Lab”.
The lab VMs are off in a Subnet in one Azure region, while the Web environment is in a couple of different Azure regions. All of the web resources are VNet-integrated or have Private Endpoints, so that everything is able to talk to each other privately without that traffic going over the public Internet. But the key here is that the Lab vNets and the Web vNets are totally cut off from each other. We aren’t using firewalls or NSGs to block the traffic; we don’t have these vNets peered to each other at all, giving us total isolation between the two environments. The advantage of this is that if the Web environment were to be compromised via the Internet, there’s no way to move laterally from the Web environment to the Lab environment (and then to the CoLo, which has a site-to-site VPN to the Lab environment) because there is no network connectivity at all between the two.
The next question is, how do we have access to the MySQL databases that are hosted in the Web environment? Well, that’s where the beauty of the cloud comes into play. Resources can have multiple private endpoints, with each private endpoint giving access from a vNet into that resource, with no ability for the resource to route traffic back across that private endpoint. So our Lab environment has a private endpoint to the Azure SQL DB for MySQL database server, but the database has no access to the Lab environment; it’s a one-way connection as shown in the diagram below.
There are other parts of the environment as well, such as Azure Storage accounts which also have private endpoints pointing to both environments, but again these are one way connections where the service isn’t able to talk back to the vNet that has the private endpoint.
The result of this is a two totally seperate environemnts allowing us to have total isolation of the enviroments while still allowing things like CI-CD deployments to be able to be made from the VMs to the Web Apps over the private endpoints. The database can be accessed from the VMs for things like Power BI data gateways (or direct database access if needed) without the possibility of the web environmnet having access to the lab environment or the on-premises environment.
If this were a larger corporate environment, I could scale this environment out as needed with multiple private environments, potentially one per application if needed to give me the scale out that I need to run all my applications, but with each one running in total isolcation from the others with the only access between the envrionments going over the private endpoints, which only allow for one way communications.
If you’d like to set up a secure computing platfom like this in your cloud environment, feel free to reach out. The team at DCAC is well versed in setting up these secure environments and we’d love to work with your team to help you design these sorts of solutions for your platforms and get your systems migrated into them.
Denny