When cloud computing first became popular, it was seen as a way of reducing both friction and costs. It was much faster and cheaper to spin up a virtual machine in the cloud than to wait for a physical server to be approved, ordered, delivered and set up.

SEE: Use this access management policy template from TechRepublic Premium to build secure policies around user access.

Now, cloud computing is powerful and robust enough to run mission critical workloads — as long as you know how to design applications to scale, configure cloud services to support them and handle the failures inevitable in any complex system.

Jump to:

Avoid security flaws when building apps on Azure

If you’re building applications on Azure, Microsoft has a Well-Architected Framework to help you design and run your app for reliability, security, performance efficiency and effective operations. It even offers a quiz to help you assess if you’ve covered everything.

There’s also a growing number of tools and services to help make the applications you run on Azure more reliable and secure. These tools range from the Azure Chaos Studio service, which helps you test how your app will cope with failure, to the open-source OneFuzz project, which will look for flaws in your code.

If you use containers, the default configuration for .NET 8 Linux containers is now “rootless,” and it takes only one line of code to have your app run as a standard user rather than one with root access. This is to ensure attackers can’t modify files or install and run their own code if they are able to get into your app.

Lock down your apps

In addition to avoiding security flaws when you write your application, you need to make sure you’re only giving access to the right people.

You can apply locks to any Azure resource or even an entire Azure subscription, making sure they can’t be deleted or even modified. But because locks affect the Azure control plane rather than the Azure data plane, a database that’s locked against modification can still create, update and delete data, so your application will carry on working correctly.

For older applications that don’t have fine-grained options for managing how credentials are used, Azure Active Directory has a new option to help you secure those credentials. This way, an attacker can’t make changes that might let them take control of a key enterprise application and get credentials to move across your network and attack other systems.

Around 70% of all data breaches start with an attack on web applications, so you need to make sure attackers can’t use them as a stepping stone to other resources.

SEE: Discover how BYOD and personal applications can lead to data breaches.

The new app instance property lock feature covers credential signing with SAML and OpenID Connect, which means you can offer single sign-on that lets users sign in with Azure AD and get access to multiple applications.

It  also encrypts the tokens created using a public key, so apps that want to use those tokens have to have the correct private key before they can use those tokens for the user who’s currently signed in. That makes it harder to steal and replay tokens to get access.

Modern applications will usually have those kinds of protections available already. If you’re running a legacy application that wasn’t built to protect these sign-on flows, you can use Azure AD to stop the credentials used for signing tokens, encrypting tokens or verifying tokens from being changed. So even if an attacker does get access to the application, they can’t block legitimate admins and take over.

You might also want to look at the permissions users have to applications they install or register on your Azure AD tenant and what anyone with guest access will see.

Check out your network

If your cloud app has a problem, sometimes it’s a network problem, and sometimes it’s how you’ve configured the network options.

Azure Virtual Network Manager is a new tool for grouping network resources, configuring the connectivity and security for those resources and deploying those configurations to the right network groups automatically. At the same time it allows for exceptions for resources that need something like inbound Secure Shell traffic, which you’d normally block.

You can use this to create common network topologies like a hub and spoke that connects multiple virtual networks to the hub virtual network that contains your Azure Firewall or ExpressRoute connection. The Azure Virtual Network Manager also automatically adds new virtual networks that need to connect to that resource or (soon) a mesh that lets your virtual networks communicate with each other.

Azure Network Watcher already has a mix of tools to help you monitor your network and track down problems that might affect your VMs or virtual network. It can draw a live topology map that covers multiple Azure subscriptions, regions and resource groups as well as monitor connectivity, packet loss, and latency for VMs in the cloud and on your own infrastructure.

But, having multiple tools for finding specific problems means you have to know what you’re looking for. The new connection troubleshooting tool in Network Watcher runs those tools and reports back on network hops, latency, memory and CPU utilization as well as whether it could make a connection and, if not, whether that’s because of DNS, network routing rules, network security rules or the firewall configuration.

You can also use Network Watcher to run other tools like a packet capture session or Azure Traffic Analytics, which helps you visualize the network flow in your application. Azure Traffic Analytics can even map the topology of the network, so you can see which resources are in which subnet and which virtual network each subnet is part of.

If you use Network Watcher’s network security groups, you can use Traffic Analytics to make sense of the flow logs, which track ingress and egress traffic to look for traffic hotspots or just see where in the world your network traffic is coming from and if that matches what you expect.

You can also use this to check that you’re using private links rather than public IP connections to reach sensitive resources like Azure Key Vault — a mistake that’s surprisingly easy to make if you use a public DNS server rather than the Azure DNS server. Getting the network configuration right is an important part of keeping your apps secure in the cloud.