What is an Access Control List?
An Access Control List (ACL) provides a security mechanism to define who or what has access to your assets, buckets, network, storage, file, etc. ACLs represent a permissions model for the object to allow, block, and conditionally grey list access to an asset.
Organizations apply access control lists across their networked infrastructure—both on-premise and in the cloud. This blog will focus on how to use ACLs in the cloud to apply the principle of least privilege and segmentation. They are also an important tool for enabling a zero trust security posture for cloud, hybrid, and on premise installations.
How to use Access Control Lists to Enforce Least Privilege in the Cloud
In the cloud, an ACL consists of one or more entries that explicitly allows or denies access based on a specific account, IP address, port, or other attribute. An entry gives a specified entity the ability to perform specific actions and even govern basic communications.
Each entry consists of two pieces of information:
- Permission: which defines what actions can be performed (for example, read, write, create, delete).
- Scope: which defines what can perform the specified actions (for example, a specific IP address or account).
As an example, suppose you have an AWS S3 storage bucket for which you need to restrict access. For the S3 bucket to operate correctly, your business needs multiple identities with various levels of security for appropriate access. While one identity may be granted read access, another may only have maintenance functions. For such a scenario, your ACL would potentially consist of two entries:
- Entry 1 gets “Read” permission to a scope of authorized accounts that can view the data.
- Entry 2 gets “Write” and/or “Delete” permissions to the scope of accounts responsible for maintenance. The files themselves would not be available to open, just maintain.
This process results in a list of ACLs used to restrict access on a “need to know” basis for the data contained in the storage bucket. While my above example is simplistic for an enterprise cloud-based application, it sets the foundation for our discussion around ACLs, the protection of assets in the cloud, and application intercommunications.
Cloud Security Benefits of ACLs
Consider the sample network architecture below for a multi-tier enterprise web application:
In every connection between tiers, and within every Availability Group, Access Control Lists should be present to prevent inappropriate network and access communications. This includes ACLs for preventing:
- Network traffic from jumping over tiers, without communicating through the appropriate assets
- Connections from the Internet from directly communicating with any layer directly, besides the load balancer
- Inappropriate nations or known hostile IP addresses from accessing the application by adding geolocation (IP and geolocation services) ACLs to the load balancer itself
- Inappropriate communications within a tier to prevent lateral movement or inappropriate application-to-application access.
- Communications from any layer attempting to communicate with the virtual environment management resources or virtual network.
With these in mind, all network traffic should always follow a predictable route. Cloud operations teams and security professionals should monitor any inappropriate activity via alerts, logs, and events for potential indicators of compromise. If any asset is compromised, a threat actor will typically attempt to deviate from the established architecture and acceptable network traffic to compromise the cloud environment. However, sometimes flaws in the web application itself are responsible for disclosing or leaking data that must be remediated.
Comparing ACLs vs RBAC
While this discussion primarily focuses on Access Control Lists, Role-Based Access Controls (RBAC) often create confusion during a typical implementation. Conceptually, ACLs and RBACs are similar, but there are fundamental differences important to understand.
RBAC is an approach to restricting system access to authorized users based on an identity, account, or groups of accounts--typically represented together as a role. This approach applies policy-neutral access-control, defined around roles and privileges.
The components of RBAC, such as role-permissions, account-role, and role-role relationships, make it easier to perform identity assignments in comparison to ACL’s, which might be assigned access based on something granular, like an IP address or a single account.
When to use RBAC versus ACLs?
Any well-developed cloud application needs both ACLs and RBAC. ACLs will help protect and define appropriate intercommunications, whereas RBAC can define identity access to the system and its data. To employ a simple analogy, one is the plumbing (ACLs) and the RBAC represents the user experience (shower faucet). However, let’s look at the difference in specific use cases for each.
Identities and applications are instantiated at a conceptually higher level than ACLs. Thus, access control lists are primarily indexed at the asset, trait, setting, and attribute layer. An ACL is usually associated with a single entry—not groups. When access and network traffic should always follow a predefined route and originate only from specific sources, access control lists are your first and best security tool for restricting access in the cloud. If you consider the cloud has no true perimeter, only certain TCP/IP addresses are exposed to the Internet, and traditional network architectures are virtualized, ACLs help maintain these conceptual boundaries and allow complex architectures far beyond what was ever possible on-premise to maintain security.
Organizations typically rely on RBACs to implement access control when a group of identities and their associated accounts are the primary method of defining access. RBAC is therefore associated with support and maintenance teams, or even end users, when access is need at various levels in an architecture. As a security best practice, these should be ephemeral, monitored, and may just in time characteristics to adhere to the tenants of zero trust.
Resources on Implementing Least Privilege Access & Zero Trust in the Cloud
Morey J. Haber, Chief Security Advisor
Morey J. Haber is the Chief Security Advisor at BeyondTrust. As the Chief Security Advisor, Morey is the lead identity and technical evangelist at BeyondTrust. He has more than 25 years of IT industry experience and has authored four books: Privileged Attack Vectors, Asset Attack Vectors, Identity Attack Vectors, and Cloud Attack Vectors. Morey has previously served as BeyondTrust’s Chief Security Officer, Chief Technology, and Vice President of Product Management during his nearly 12 year tenure. In 2020, Morey was elected to the Identity Defined Security Alliance (IDSA) Executive Advisory Board, assisting the corporate community with identity security best practices. He originally joined BeyondTrust in 2012 as a part of the acquisition of eEye Digital Security, where he served as a Product Owner and Solutions Engineer, since 2004. Prior to eEye, he was Beta Development Manager for Computer Associates, Inc. He began his career as Reliability and Maintainability Engineer for a government contractor building flight and training simulators. Morey earned a Bachelor of Science degree in Electrical Engineering from the State University of New York at Stony Brook.