Creating Secure Azure Cloud Applications

Solution design is the foundation of secure applications. Solutions must balance often competing requirements for features, cost, and security. Perfect security may not be possible. Solution designers must decide the required security level. And the threats to defend against.

Confidentiality. Integrity. Availability.

Three desirable properties of secure applications are that the data remains confidential, has integrity and is available ("CIA").

The "STRIDE" model is a slightly more detailed approach to categorising threats. STRIDE refers to various threats: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.

Secure design should evaluate these threats and seek to build systems that defend against them.

Azure offers resources to defend against these attack vectors and mitigate the risks of compromise.

On-premises ≠ Cloud

The traditional approach to security for on-premises applications was to view the network as the perimeter. Physical access, physical firewalls and gateways were the first points of defence.

Cloud applications live outside the company network, so a different strategy is required.

With cloud deployments, identity becomes central to security. Identity refers to the end-users, administrators and even the resources themselves. Users should only have access to the information they need. Password policies (including multi-factor authentication) should be enforced to verify users’ identities. Managed identities for applications can remove the need for shared and long-lived secrets.

Identity is central to trust.

Cloud deployments are multi-tenanted at some level. On-premises resources are usually dedicated to an organisation or even an application. Cloud resources are inherently shared. The level to which resources are shared can vary, but many of the benefits of cloud deployments stem from this sharing. Scalability, cost savings and speed of deployment are directly due to this shared model.

Cloud solutions can be designed to minimise the risks of shared infrastructure. Data can be encrypted. Applications can fail safely. Attack surfaces can be reduced.

Secure architecture and resource design

The data flows into, within and out of the application are critical to security.

Confidentiality of the data requires thinking about data security at rest (when it is stored), in transit (to and from Azure, and between Azure resources) and while in use (while it is being processed).

Integrity covers a range of security practices. Data should be backed up. Changes should be logged (to prevent repudiation and to assist with incident response). Some data changes may need to retain versions to provide the ability to be rolled back. Azure provides resources with service levels that correspond to different access strategies. This helps deliver security features within a reasonable budget. For example, Azure SQL might be used to store the most recent data, with Cosmos DB used to store historical data.

High availability might require redundant resources within a data centre, or even across separate data centres in different regions. For the most critical systems, multi-cloud deployments with different providers (e.g. Azure and AWS) could be considered. High availability design patterns can be adopted, such as CQRS to separate the data updates from the queries.

Developers often have very highly privileged access to resources. This access is a valuable prize for attackers and must be managed carefully.

Secure development practices should be adopted through the software development lifecycle. Developers should be aware of the most important and most common threats to the applications they build. The OWASP top 10 is a great starting point. This top 10 list helps developers to understand (and defend against) threats from attackers such as broken access controls, security misconfiguration and outdated component libraries.

Peer code reviews are a great tool for delivering bug-free code. They’re also useful for helping developers communicate secure coding practices and learning techniques from other developers. Code reviews are often a governance requirement for auditing.

In addition to human code reviews, automated static code analysis can help detect coding errors and vulnerabilities. Various tools are available that can run automatically when code is checked in. Deployments can be blocked if serious threats are detected.

User data should be assumed not to be trusted. In this sense, user data is any data that is (or could be) external. Data entered by end users, uploaded images, imported files or remote data are all potential sources of attack. Data could be malicious and intended to compromise a system. Data could simply be unsuitable for the target system and cause availability issues if not sanitised.

Cloud applications often have more than one entry point. For example, the user interface might be the most obvious gateway to an application. The application might also include an API that the user interface connects to. Direct database access might also be required. The solution design should minimise the attack surface. However, the developers usually need to ensure that the different endpoints of a solution are equally protected from threats.

Developers must ensure secrets provided to them remain confidential. Solution design can minimise the risks of compromise by removing the need for these secrets. If they are required, developers must ensure that secrets do not leak (for example by including them in source control or front-end code).

Similarly, developers should not generally work with live customer data. Artificial (or synthetic) data can have several benefits. Most importantly, it protects personal customer information. Synthetic data can also be useful for testing. It can help expose different types of bugs where the live data might be incomplete.

A secure application needs ongoing support to remain secure.

Secure applications can become insecure for a variety of reasons. Microsoft makes efforts to notify their users (tenants) of changes that might affect their applications. Changes can still have an impact, though it’s reasonable to expect that security levels are only increased or improved. These changes can sometimes impact availability though.

New threats might also be discovered that need to be mitigated. Sometimes this will require a configuration change. In other cases, libraries that the application code depends on need to be updated and the application redeployed.

Many Azure applications will require penetration testing. We often work with independent teams that effectively act as ethical hackers to help identify any weaknesses. Regular audits and pen tests are essential

Ongoing dynamic testing can help identify vulnerable parts of an application. Dynamic application security testing (DAST) can be used to test an application as it runs. These tools can detect a different class of issues than other types of analysis.

Other types of security tests are also possible.

Periodic reviews can help identify threats before an attacker does.