A Practical Introductory Guide to Cloud Application Security

Moving software to the cloud unlocks a lot of benefits. It enables the application to scale in ways that aren’t possible with on-premise infrastructure. What’s more, renting time in a data center that someone else sets up is a lot cheaper than building your own data center. Want to set up some servers that are closer to customers on another continent? The cloud’s got you covered.

Many organizations worry about application security when moving to the cloud. The truth is, cloud application security is no different from any other kind of application security. The way that you secure applications—in the cloud, and on-premise—is by understanding your threats and how to mitigate them.

There are many things that are easier to secure on the cloud. In this post, we’ll talk about the most common security decisions teams make to secure cloud applications. By themselves, they won’t make your application secure. But they will give you a pretty good start.

clouds under lock signifying cloud application security

Manage Application Access

The single easiest way to make sure that nobody ever uses an application improperly is to make sure that nobody can ever access it. I’m guessing that’s not an option for your application. Instead, you need to ensure that only the correct people access your application. Thankfully, cloud platforms have a number of options to empower you to do just that.

Two Factor Authentication

Every cloud computing provider exposes capability to enforce multi-factor authentication. Multi-factor authentication (MFA or 2FA) requires that a user requesting access prove their identity in a multitude of ways. Single-factor authentication only requires that someone know a user’s password to log in. As you know, people forget passwords, or write them down, or share them with coworkers when they shouldn’t. MFA means that the person logging in needs to know more than just a password. Usually, this is accomplished by the presence of a physical key or app on a company-issued smartphone. When the user tries to log in, they also need to enter a one-time password provided by the application that authenticates that they also have possession of something which belongs to the user.

Account takeover attacks enable attackers to do significant amounts of damage to any application exposed to the internet. By enforcing MFA requirements on your accounts, you mitigate the risk that any of your users will ever be the victim of an account takeover attack. It’s a good idea no matter where your application lives.

Single Sign On

Many people don’t think of single sign on (SSO) functionality as a security measure, but it is. It’s especially valuable for both security teams and application users on cloud applications. Because of the ease of setting up independent systems in the cloud, many organizations split their applications across multiple systems in the cloud. For a user, this is annoying. Moving between systems or applications means needing to remember yet another password. If you’re securing your system with MFA as well, that means typing in a login token every time, too.

Each of those points of ingress is another point for a potential attack. When you have 15 login forms, it’s quite likely that they’ll all be driven by slightly different technology. That explodes the list of libraries and applications the security team needs to keep an eye on. It’s much easier to miss a critical security vulnerability in a library that backs one signing flow out of a dozen different options than it is when you just have one. By consolidating all sign on points into a single service, the security team is able to harden that one service. They can focus on keeping that single point of ingress more secure. As a bonus, your users also experience an improvement in their overall experience. Everyone wins.

User Permissions Management

When securing cloud applications, we often think of the malicious attacker as our primary adversary. In reality, the greatest danger to many of your applications is your own users. I don’t mean to say that your users are going to intentionally sabotage your application. Quite the opposite. Users will often accidentally take actions that cause long-term data to organization security or data. Thankfully, this is a problem we can solve before it ever crops up. Instead of allowing many users to take actions on our applications, we should naturally limit who can take which actions. Best practices say that we should only grant permissions to users who need that permission to do their job.

The same is true for our cloud platforms themselves. Your applications are naturally less secure when a dozen people in your company can turn off your database server. Make good use of tools like AWS or Azure Identity and Access Management (IAM) to ensure that users have the correct rights and permissions.

Monitor Your Applications

Much of the conversation about application security focuses on intrusion prevention. This is for good reason! We don’t want our applications damaged by attackers. However, even the most secure organizations still suffer intrusions from time to time. That’s when intrusion detection tools play an important role in organizational security. When you detect that your application has suffered an intrusion, you can learn from what went wrong. You can plug that hole to ensure that nobody ever compromises your security in that way again. Detecting intrusions also means that you’re able to respond appropriately when the attacker does something like access sensitive data.

All major cloud providers have their own systems that enable you to monitor your systems on their cloud. For instance, Amazon CloudWatch provides a singular source to collect logs from all sorts of applications running on AWS. Azure Monitor does the same on the Microsoft side. One benefit of these applications is that they’re directly integrated with your cloud provider. Usually, sending logs to these locations is as simple as can be. However, they do come with some downsides. Often times, setting them up to show actually useful data can be a challenge. I can say from personal experience that it takes a lot of time and effort to grow to proficiency with CloudWatch.

Another shortcoming of integrated log management platforms is that they only work on one cloud. If you’re one of the growing number of organizations that hosts applications on more than one cloud, something like Azure Monitor isn’t a good fit for you. Instead, you’ll need a dedicated log collection and analytics platform. This is where a tool like  Scalyr Log Management really shines. You’re able to plug all your log sources into a single location and analyze the data they provide quickly and simply.

Don’t Overthink Cloud Application Security

Like we said at the start, many organizations think that cloud application security is a different ballgame from their normal security. That couldn’t be further from the truth. Securing cloud applications is still about the basics of all application security. Understand your risks. Know which ones you can mitigate, and which ones you can accept. Then work with your team to build cost-effective mitigations.

Just because your applications don’t live in an on-premise facility doesn’t mean you need to change your approach. In fact, cloud application security can often reduce some security overhead from your team. Just keep building on the fundamentals your team already brings to the table. Your cloud applications will be just as secure as every other application you support—if not more so!

This post was written by Eric Boersma. Eric is a software developer and development manager who’s done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he’s learned along the way, and he enjoys listening to and learning from others as well.