Azure public DNS zones – Network Connectivity and Security
If you own your domain, bigcorp.com, you can create a zone in Azure and then configure your domain to use the Azure name servers. Once set up, you can then use Azure to create, edit, and maintain the records for that domain.
You cannot purchase domain names through Azure DNS, and Azure does not become the registrar. However, using Azure DNS to manage your domain, you can use RBAC roles to control which users can manage DNS, Azure logs to track change, and resource locking to prevent the accidental deletion of records.
We have looked at the different options for setting up VNETs with IP addressing and name resolution; we will now investigate to ensure secure communications to and between our services.
Implementing network security
Ensuring secure traffic flow to and between services is a core requirement for many solutions. An example is an external communication to a VM running a website – you may only want to allow traffic to the server in a particular port such as HTTPS over port 443. All other traffic, such as SMTP, FTP, or file share protocols, need to be blocked.
It isn’t just inbound traffic that needs to be controlled; blocking outbound traffic can be just as important. For many organizations today, ensuring you are protected from insider threats is just as crucial, if not more so, than external threats. For this reason, we may want to block all but specific outbound access so that if a service is infected by malware, it cannot send traffic out – known as data exfiltration.
Important Note
Data exfiltration is a growing technique for stealing data. Either by manually logging on to a server or through malware infection, data is copied from an internal system to an external system.
As solutions become more distributed, the ability to control data between components has also become a key design element and can often work to our advantage. A typical and well-used architectural pattern is an n-tier architecture. The services in a solution are hosted on different layers – a User Interface (UI) at the front, a data processing tier in the middle, and a database at the back. Each tier could be hosted on its subnet with security controls between them. In this way, we can tightly control who and what has access to each tier individually, which helps prevent any attacker from gaining direct access to the data, as we can see in the following example:
Figure 8.4 – N-tier architecture helps protect resources
In the example, in the preceding figure, the UI tier only allows traffic from the user over HTTP (port 443), and as the UI only contains frontend logic and no data, should an attacker compromise the service, they can only access that code.
The next tier only allows traffic from the UI tier; in other words, an external attacker has no direct access. If the frontend tier was compromised, an attacker could access the business logic tier, but this doesn’t contain any actual data.
The final tier only accepts SQL traffic (port 1433) from the business tier; therefore, a hacker would need to get past the first two tiers to gain access to it.
Of course, other security mechanisms such as authentication and authorization would be employed over these systems, but access by the network is often considered the first line of defense.
Firewalls are often employed to provide security at the network level. Although Azure provides discrete firewall services, another option is often used to provide simpler management and security – Network Security Groups (NSGs).