Infrastructure vs application authorization

When a user or a machine entity logs into a system, it’s important that the system knows what resources the logged-in principal is permitted to have access to. Without an authorization mechanism in a system, anyone could have unrestricted access and permission to all resources in a system. Proper authorization improves the security of a system, whether it’s infrastructure or an application.

In this article, we will explore the distinct purposes and approaches of infrastructure and application authorization. We’ll dive into how each type functions, their common use cases, and why they are critical for securing your systems. We’ll also examine implementation strategies. By the end, you’ll have a clearer picture of how to effectively integrate authorization into both infrastructure and application layers.

Brief introduction

Infrastructure does have different authorization use cases than applications, given their different purposes. An application is a software package designed to perform specific functions for end users or other applications while infrastructure is the framework that supports that application. Infrastructure is hardware and software components, network components, operating systems, and data storage.

• Infrastructure authorization is used by administrators to grant permission and privileges to other users in the team, in order to access specific resources and perform particular actions on the infrastructure environment.
• Application authorization is developed into the app by creating privileges and permissions based on user roles in order to restrict or provide specific access to certain features in the application for end users.

Let’s dive a little deeper into the concepts of infrastructure and application authorization, so we can understand their similarities and differences.

Infrastructure authorization

Due to its cost-effectiveness, scaling, ability to store large data, and ease of management, cloud infrastructures are gaining favoritism to support applications and business solutions. The growth of cloud infrastructure has increased tremendously with more sophisticated tools; authorization is no longer a nice-to-have feature but a necessity.

Permissions for users must be carefully planned. You must ensure that sensitive permissions are not given to the wrong users, and that users are not being over-provisioned with permissions. If someone receives access to something they have insufficient knowledge about, or if they access it with malicious intentions, the result could be disastrous or irreversible.

Use cases of infrastructure authorization

So what scenarios should you be considering when it comes to determining permissions in your infrastructure?

• Restricting service accounts to specific permissions. Service accounts are used by system services such as web servers, mail servers, or another application to perform certain operations on the infrastructure.
• Implementing good security practices like the least-access principle. The principle of least-access states that you should only grant the required permissions needed for an entity to complete its task. For instance, if the task of an entity is to view actions performed on an infrastructure, such as spinning up a new instance of a computing engine, then it would be bad practice to grant the entity permission to be able to edit any action. If an attacker has access to the entity’s credentials, they will be unrestricted in performing malicious activities. Following the least-access principle reduces the spread of an attack.
• Implementing access-control lists, ACL. ACLs control access to a given resource. For example, if an entity is trying to access a file in a storage bucket, an ACL runs a check on the entity to ensure it has the required permission to access the file. If the entity doesn't have the required permission, access is declined.
• Implementing a resource-based policy. This ensures that an entity has access to a given resource and can perform specific actions under specific conditions. For instance, userA and userC are given access to a storage resource while userB is not given access. UserA is only allowed to read from storage at specific times, while userC is given permission to both read and write.
• Implementing role-based access control, RBAC. RBAC is an authorization mechanism that grants an entity permission to a resource based on the entity’s role. The role contains the required privileges needed to access certain resources on the infrastructure. When the role is assigned, that entity will have access to the resources permitted by the role. For example, an organization’s storage role can have access to only the infrastructure that allows access to uploading and downloading data. The hosting role can allow an entity to spin up a new computing instance to host a website

Application authorization

Planning authorizations is an important aspect of your application development. An application without a well-planned authorization mechanism is opened to attack and abuse. There are several use cases for implementing authorization in your application.

Use cases of application authorization

• Implementing role-based access control. Similar to RBAC in infrastructure authorization, this practice grants access to your application APIs based on user roles. Each role has its own required permissions; for instance, a blog could have three roles, such as admin, editor, and viewer. The viewer is only allowed to view content on the website; any attempt to edit or delete content will be blocked. The editor has permission to view and edit content, but is restricted from adding or deleting content, which can only be performed by the admin.
• Implementing attribute-based access control. ABAC is an authorization mechanism that grants privileges to the application based on the user, resource, or environment attributes. It provides a more sophisticated approach to authorization as compared to RBAC. ABAC can further reduce risk in larger applications, as well as integrate more fine-grained access control. For example, you could configure different roles like HR, DevOps, developer, and product manager to have access to certain resources based on their location, timezone, and their hierarchy in the organization.

Comparing infrastructure and application authorization

While infrastructure and application authorization have some differences, such as their method of implementation and integration, they also share some similarities, such as providing security and their implementation of role-based access control. Let’s take a moment to learn a bit more about their similarities and differences.

Key similarities

They both protect important resources. The main goal of authorization is to protect data and actions from unauthorized and unwarranted entities.

They both have the ability to implement common patterns. Some common patterns like RBAC can be implemented for both infrastructure and application authorization because of the basic concepts authorization is built upon.

They improve the security of the system. As mentioned earlier, authorization prevents unauthorized access to system resources, so it improves the security of the system. Both infrastructure and application systems contain important resources and actions that require the right entity to have the right permissions in order to gain access to the resources.

Key differences

One protects the infrastructure and the other protects the application. Infrastructure authorization ensures that the wrong entity doesn't have permission to perform sensitive actions on the infrastructure. You may perform more configurations on an infrastructure than any other action, so giving privilege to the wrong entity can cost your organization in numerous ways. On the other hand, application authorization prevents sensitive data access from the wrong user.

Infrastructure authorization is usually set in stone by the provider. Meanwhile, application authorization is up to the architects/engineers to choose and implement. You’re limited to the authorization mechanism provided by your infrastructure provider, but application authorization can be implemented based on the mechanism preferred by the architect or engineer.

How are infrastructure and application authorization implemented?

For most providers, infrastructure authorization is implemented via an identity and access management (IAM) tool - be it AWS, GCP, Azure or any of the other big clouds. The IAM system tells the infrastructure how to control access to different resources of your infrastructure. You can manage access by creating permission policies for different resources and entities on your infrastructure. Some components like databases might have their own inbuilt authorization controls, but on the whole for infrastructure level access management, you generally use what is provided.

When it comes to application level authorization things are not so clear cut. Many libraries and frameworks exist with permissioning models built in, such as Wordpress and Django, but these are tied into those stacks and can’t easily be used outside of that ecosystem.

If your application is made up of a number of services - typical of a microservices architecture - then managing authorization is more painful and you likely would need to decouple the logic out of the app and into a standalone service, which each part of the system can call upon when needed to make access management decisions. This is where a system like Cerbos can help and allow you to focus on the business value rather than foundational things such as authentication and authorization.

Conclusion

When developing an application, it’s important to choose the best authorization mechanism based on your application’s requirements. The same goes for infrastructure authorization—you must implement it based on the needs of your organization.

If you’re looking for an easy authorization solution for your application, check out Cerbos. A powerful authorization solution, Cerbos makes it easy to create custom RBAC and ABAC. It’s fast, scalable, and it saves developers from wasting precious time creating authorization from scratch.