Skip to main content
Man and H2

Cloud based access control explained: Part 2

Cloud based access control systems – what are they and how do we know they’re secure? In this series we take a deep dive into Microsoft’s Azure cybersecurity frameworks and how they ensure their cloud solution is secure.

In part 1 of “Cloud based access control explained” we went over the basics of the cloud and how Microsoft secures the datacenters and servers that keep Protege X running.

For a quick refresher or if you missed the first part, check it out now:

Secure network infrastructure: Software and data

Now that we’ve looked at how the datacenters and servers are physically secured, let’s turn our attention to how Microsoft ensures that Azure keeps their software and customer data protected.

Azure Security Policy

Any access control requirements for Azure are vetted against the Azure Security Policy:

  • By default, Microsoft operations and support personnel are denied access
  • Grant the least privilege required to complete task
  • Log and audit access requests

For any Microsoft operations and support personnel, multifactor authentication (MFA) is required, and access is only granted from secure consoles.

Azure Front Door

Azure Front Door sits between the end-user and the application’s content – in this case, Protege X.

Azure Front Door provides a secure entry point for content delivery, with built-in web application firewall (WAF), bot protection, and distributed-denial-of-service (DDoS) protection. This stops malicious actors from flooding the application causing the system to crash.


Multi-factor authentication

Protege X is secured following the best practices in cybersecurity with multi-factor authentication (MFA).

MFA requires that a user take multiple steps to login to their account, such as using a password and a PIN generated by an authentication app on their smartphone.

MFA is used to log into any applications connected to the Protege X system to mitigate malicious actors gaining access to the system and is managed by Azure Active Directory B2C.

Data encryption

Whether it’s in transit or at rest, all customer data is encrypted.

Data encryption in transit

Microsoft follows international standards enabling ‘encryption by default’ for all data in transit between Azure datacenters. Further, Protege X uses Transport Layer Security (TLS) for encryption in transit. TLS is a cryptographic protocol for communications security that uses session-specific asymmetric and symmetric ciphers to encrypt the connection.

TLS provides a secure, reliable, and confidential connection between two applications, while ensuring that the connection is authentic, meaning you’re connecting to a legitimate site and not a malicious actor.

It may surprise you, but you already use TLS every day. It’s an integral part of the internet, as it’s foundational to HTTPS. You may recognize these as that appear at the front of web pages which tell you that your connection is trustworthy and secure, such as:

Data encryption at rest

When your data is at rest, it’s stored in an Azure SQL Database. The SQL Database has built in encryption at rest with symmetric encryption.

Further, Azure uses best practices like Trusted Execution Environments (TEEs) to store customer data. TEEs are separated from the system's main operating system, creating a secure environment that can only be accessed by systems. Malicious actors cannot gain access to customer data as it’s invisible to external parties.

Encryption at rest is a further mitigation step to stop malicious actors from accessing unencrypted data – if the actor gains access to the hard drive they will be unable to access the data without the key.

Data segregation

When any data is at rest, Azure uses segregated networks.

Managed and customer networks are segregated from each other in Azure, with Microsoft managed networks only available for administrators to connect to Azure. When administrators do want to connect, just-in-time-access and privileged access workstations limit accessibility. Just-in-time-access is a foundational aspect of Microsoft’s cybersecurity, ensuring that staff are only able to access the system for a predetermined period. Having segregated networks ensures customer networks are protected against attacks targeting managed networks.

To ensure customers can’t access each other’s networks, they’re further segregated using network virtualization methods. Network virtualization consists of separating the software from the hardware so that the network can run independently from the physical equipment supporting them. Each virtual network exists independently while still able to be managed from a centralized point.

By virtualizing the network, Microsoft can ensure that a breach or incident with one customers’ network doesn’t impact the rest of the server, as well as dynamically balance network capacities to ensure more efficient and resilient networks that are easier and faster to deploy functions to.



  • The cloud is a global network of servers that allow you to access the internet
  • Microsoft has an entire division dedicated to designing, building, and operating the Azure data centers
  • Your data has built-in disaster recovery in case of outages or failures as your database backups are stored in at least two geographically dispersed data centers
  • Protege X, ICT’s cloud system, is built using best practices like Zero Trust to verify who is accessing systems
  • All data is encrypted both in transit and at rest, mitigating any attacks by malicious actors
  • All data at rest is segregated using network virtualization


In the second part of this series on Azure cloud cybersecurity, we’ve gone over the Azure security policy, Azure Front Door and how the Zero Trust model sits in that, as well as how Azure ensures their data in transit and at rest is protected and segregated.

Keep an eye on your inbox for the third and final part, where we look at how Microsoft tests and monitors the Azure cloud servers.

Want to learn more about Protege X?