In order to keep all services safe from outside threats, MobileTrack has decided to implement a Zero Trust security model on Azure. This model is based on the principle of "never trust, always verify,"
and it requires strict identity verification and access controls for all users and devices attempting to connect to the network. By implementing Zero Trust on Azure, MobileTrack can better protect its data, applications,
and infrastructure from cyberattacks and other security threats.
Required services to implement Zero Trust on Azure
1. Identity and Access Management:
Microsoft Entra ID: Centralized identity management with multi-factor authentication (MFA) and identity protection.
Role-Based Access control: All resources are only allowed to access resources they need to function, and have the least-privileged access to said resources.
On the testing environment, the software engineers of MobileTrack have access to the testing resources from their own laptops,
using their Microsoft Entra ID account to authenticate.
On production, only 3 managers have access to the production environment, but only when logged in from the office. All resources are locked to prevent accidental deletions/editing, and the database is read-only for these administrators.
Whenever any administrator needs access to the resource group for maintenance or inspection, all actions will have to be manually logged and approved by another administrator.
Azure policies: as a default, all services can only be instantiated on the West Europe region. This is to prevent data from being stored in regions that are not GDPR-compliant.
Backups (West Europe's partner Geography is Ireland) are only allowed to be stored in these regions, and only the necessary 3 production administrators have access to these backups for disaster recovery.
2. Network Security:
Azure Firewall: Provides traffic filtering to enforce security policies. Only valid traffic towards the Portal Website, the API and the device receivers will be allowed.
Virtual Network (VNet) Segmentation: Divides networks into smaller segments to reduce the risk of lateral movement.
Network Security Group: Filters network traffic to and from Azure resources in an Azure virtual network. NSGs can contain multiple inbound and outbound security rules that enable you to filter traffic to and from resources by source and destination IP address, port, and protocol.
ín this way, traffic designated for the Web Portal, the API or TCP connections for the device receivers will be allowed and properly directed, while all other traffic will be blocked.
Application Gateway: Azure Application Gateway is a web traffic (OSI layer 7) load balancer that enables you to manage traffic to your web applications. Traditional load balancers operate at the transport layer (OSI layer 4 - TCP and UDP) and route traffic based on source IP address and port, to a destination IP address and port.
For our purposes, this means routing the proper API/Web use of Portal and the device receivers to the correct (micro)services.
Azure DDoS Protection: The free default version is sufficient for our needs - the paid one is very expensive.
Azure Security Center: Monitors and provides security recommendations for devices connected to Azure.
3. Data Protection:
Azure KeyVault: Encrypts data at rest and in transit using Azure Key Vault for key management. In this way, if our codebase was ever leaked, there would be no way to access the services like the Azure Cosmos Database without the proper keys.
Restricted backups: In order to follow laws and regulations, we have to keep backups of our data. However, we have to make sure that these backups are only stored at appropriate locations and that only the necessary people have access to them.
That is why the Azure Cosmos Database itself is stored on Europe West (Schiphol), while the backup will be stored on France Central (Paris) or Germany West Central (Frankfurt). (Pending management/customer decisions)
4. Monitoring and Analytics:
Application Insights: Azure Application Insights is an extensible Application Performance Management (APM) service for web developers on multiple platforms, used to track the performance of life services. It will automatically detect performance anomalies, and includes powerful analytics tools to help you diagnose issues and to understand what users actually do with the applications.
For our purposes, this data is parsed daily by the Performance Monitor app, which will alert the DevOps team if any anomalies are detected. All recent data will also be available to MobileTrack support on the Portal Website.
Alert rules: if anomalies are detected in performance optimization, security, or availability, the DevOps team will be alerted by Azure.
Benefits of Zero Trust on Azure
Enhanced Security By continuously verifying and applying the principle of the least privilege, Zero Trust helps protect against both external and internal threats.
Reduced Risk of Data Breaches: Micro-segmentation and rigorous access controls reduce the potential impact of compromised credentials or devices.
Improved Compliance Helps meet regulatory requirements by ensuring robust security practices and comprehensive logging and monitoring. (NIS2, AVG/GDPR, etc.)
Scalability: Azure's cloud-native tools allow for scalable security measures that can grow with the organization.
By leveraging these Azure services and adhering to Zero Trust principles, organizations can significantly enhance their security posture and better protect their assets in a dynamic threat landscape.
Implementing the Virtual Network (overview)
For information how to implement each specific resource, you must refer to the individual documentation pages of each service. We'll be going in order of ingress, starting with the firewall and ending with the last service on the stack.
All resources (except for the Azure Communication Service) reside on a singular Virtual Network which is segmented into subnets for the sake of following "assume breach" principles.
This is how these services are linked together:
subnet-firewall
This subnet is the ingress point for all traffic, for the Portal portal, the API and all device receivers. All traffic enters the Azure Firewall first to block harmful content and DDoS attacks.
Then it is sent to the Network Security Group, which uses an Azure Route Table to determine to which subnet the traffic should be sent.
subnet-Portal
The traffic, having arrived at the subnet, enters the local Network Security Group which directs it to the Application Gateway.
This then sends it to either the Portal or the API; we use this Application Gateway not just for security, but also for load balancing in case of high traffic, so Portal can scale horizontally and deploy more instances if need be.
subnet-receivers
All traffic for the device receivers is sent to the Containers subnet, where the Network Security Group will direct it to the proper receiver (microservice in the form of a container instance).
The Azure Container Registry is also placed on this subnet, as only receivers from this subnet are allowed to pull images from it.
subnet-background-services
Certain tasks like scheduled tasks, requests to generate reports or handle messages from device receivers are handled by the Azure Functions in the Background Services subnet.
This subnet is only accessible from the Containers and Portal subnets because those are the only subnets that need to access these services.
Application Insights and the Performance Monitor apps are placed in the Monitoring subnet. This is a closed off subnet that only reads out data from Application Insights and turns it into a usable format on the Portal Website.
The subnet cannot be accessed through the internet, although it is allowed to call third party API services if need be. Each specific third party service address must be given specific access rights in the Network Security Group.
subnet-storage
The storage subnets contains the Azure Cosmos DB, the Azure File Storage and the Replication Layer (in the form of Azure Cache with Redis). This subnet can be accessed by the Portal subnet and the Background Services subnet.
Caution
This means the Containers subnet resources don't get access to the storage subnet, as the device receivers only 'translate' the device message into a workable format and submit those to the message handler in the Background Services,
which returns a message for them to return to the device. (Which can be turned into a 'conversation' with the device if need be.)
Note
The storage subnet does not interact with the outside world, except to submit backups to the backup storage in Frankfurt and/or Paris.
subnet-keyvault
The KeyVault subnet contains the Azure KeyVault, which is used contain access keys for the API Secrets and the connection strings between services. This subnet is only from within the virtual network (except the firewall subnet) and doesn't talk to the internet either way.
Azure Communication Services
The Azure Communication Services is the only service that is not placed on the Virtual Network; we don't run it, we simply ask Microsoft to provide its functionality for us.
Only the Background Services and the Portal Website are allowed to call on it to send emails, SMS messages, WhatsApp messages and perform (video)calls.