Manage permissions to keep applications safe and secure in the cloud

In March 2020, Marriott, one of the largest hotel chains in the world, announced that a serious security breach had exposed the personal information of 5.2 million guests. The problem? The login credentials of two employees were compromised.

In November 2019, Alibaba exposed over 1.1 billion pieces of user data, by a rogue developer working for an affiliate marketer.

In April 2019, Facebook accidentally exposed the data of 530 million Facebook users to the internet. Two years later, the data was posted, for free, showing a criminal intent in using the exposed data.

Keeping applications safe and secure in the cloud is hard. Very hard. In fact, cloud security is often cited as a reason why companies can't migrate their data to the cloud.

Yet, when set up properly, no application environment can be made safer than that of a public cloud provider. Often, when there is a security breach such as these, the problem was improper use of credentials — an employee had more access than they needed to do their job, an overzealous engineer took advantage of their access to scrape customer data, a file was accidentally exposed publicly.

But how do enterprises keep cloud permissions intact and keep their applications safe and secure? Creating a strategy for managing these permissions that is both safe and secure is an essential aspect of keeping a modern digital application operational and valuable.

There are three principles that can guide IT decision makers in understanding the proper permissions their applications require. Together, these are best practices for keeping modern applications safe and secure, and reduce vulnerability to bad actors and other attacks.

1. Principle of least privilege

The Principle of Least Privilege is an industry-standard security principle that grants an entity only the minimum permission necessary for it to perform its responsibilities, and no more.

This principle is best described by an example. Let's assume you have a service that needs to read files out of an S3 bucket named ‘datasrc'.

In this example, what permissions do you need to give the service to access S3? You need to give it read access to the bucket named ‘datasrc', but that's it. Specifically, you do not need to give it:

• Access to write to the bucket ‘datasrc'.
• Access to read contents of any other bucket other than ‘datasrc'.
• Access to create, delete, or modify any objects in any bucket.
• Access to any other services or systems, other than S3.

By limiting access to only the bare minimum access required for a service, you limit the blast radius of the service. The blast radius is the amount of damage a compromised service can do to other services and systems as the result of either a programming mistake, or in the hands of a bad actor.

2. Principle of shared responsibility

The Principle of Shared Responsibility clarifies what aspects of application security are the enterprise's responsibility, and what aspects of the application's security are the cloud provider's responsibility. It's a principle championed by AWS, but applies to all cloud providers.

In the case of AWS, each service has a documented policy specifying which aspects of security are the enterprise's responsibility, and which are provided by the cloud provider. For example, EC2 specifies the things that are AWS' responsibility include the physical data center security, networking security, and underlying hardware security. Meanwhile, the enterprise's responsibility includes the security of the operating system running on EC2, any running software, and the application itself. Additionally, AWS provides a set of tools to aid enterprises in fulfilling their side of the responsibility model, including IAM, and network firewall management.

Every cloud provider has a similar policy, either explicitly or implicitly, and understanding what the enterprise needs to do and what it can depend on the service provider to do are an important aspect of keeping an application safe and secure.

3. Principle of separation of duties

In many companies, there is a set of 'special' people — people who have extra access to the core operations infrastructure of the production applications. They have these permissions so they can perform special actions needed to keep production operating.

However, this is a bad practice. What happens if one of these people who has extra permissions loses their credentials or their credentials are compromised? Or what happens if one of these people leaves the company in a bad way? In either case, the entire application stack is compromised suddenly to a bad actor who can bring the application down, delete business-critical data, or even worse, steal customer data.

The Principle of Separation of Duties says that there should be no such 'special' people with special permissions. No one person should have a level of access that allows them to perform activities that could endanger the business. Instead, the permissions required to perform these activities should be divided across multiple people, so that more than one person is required in order to perform critical activities that require special access. This provides a check-and-balance for any actions that are required, and prevents either a disgruntled employee or the compromised credentials of a single employee from causing a serious security exploit.

Designing permission models

By following these three principles, an IT organization can create a permissions model that is both safe and efficient. The Principle of Least Privilege keeps compromised people and systems from giving too much access to other secure systems, the Principle of Shared Responsibility clarifies the line between the enterprise's responsibility and the cloud provider's, and the Principle of Separation of Duties specifies that no one person should have magical powers.

Together, these security principles will improve the safety and security of an organization's applications and reduce its vulnerability to bad actors and other attacks.