View source for Access Control List (ACL)

'''Access control list (ACL)''' refers to the permissions attached to an object that specifies which users are granted access to that object and the operations it is allowed to perform. Each entry in an access control list specifies the subject and an associated operation that is permitted.<ref>[https://www.techopedia.com/definition/24766/access-control-list-acl Definition - What does Access Control List (ACL) mean?]</ref>

The most common privileges include the ability to read a file (or all the files in a directory), to write to the file or files, and to execute the file (if it is an executable file or program). Microsoft Windows NT/2000, Novell's NetWare, Digital's OpenVMS, and UNIX-based systems are among the operating systems that use access control lists. The list is implemented differently by each operating system. In Windows NT/2000, an access control list (ACL) is associated with each system object. Each ACL has one or more access control entries (ACEs) consisting of the name of a user or group of users. The user can also be a role name, such as "programmer," or "tester." For each of these users, groups, or roles, the access privileges are stated in a string of bits called an access mask. Generally, the system administrator or the object owner creates the access control list for an object.<ref>[https://searchsoftwarequality.techtarget.com/definition/access-control-list What is Access Control List (ACL)?]</ref>

An Access Control List (ACL) is a set of rules that are usually used to filter network traffic. ACLs can be configured on network devices with packet-filtering capabilities, such as routers and firewalls. ACLs contain a list of conditions that categorize packets and help you determine when to allow or deny network traffic. They are applied on an interface basis to packets leaving or entering an interface. Two types of ACLs are available on a Cisco device:
*standard access lists – allow you to evaluate only the source IP address of a packet. Standard ACLs are not as powerful as extended access lists, but they are less CPU-intensive for the device.
*extended access lists – allow you to evaluate the source and destination IP addresses, the type of Layer 3 protocol, source, and destination port, and other parameters. Extended ACLs are more complex to configure and require more CPU time than standard ACLs, but they allow a more granular level of control.<ref>[http://geek-university.com/ccna/what-is-acl-access-control-list/ Explaining Access Control List (ACL)]</ref>


'''Access Control List (ACL) Rules'''<ref>[https://www.alliedtelesis.com/sites/default/files/acl_feature_overview_guide.pdf Access Control List (ACL) Rules]</ref>
*The source or destination address or the protocol of each packet being filtered is tested against the filters in the ACL, one condition at a time (for a permit or a deny filter).
*If a packet does not match a filter then the packet is checked against the next filter in the ACL.
*If a packet and a filter match, the subsequent filters in the ACL are not checked and the packet is permitted or denied as specified in the matched filter.
*The first filter that the packet matches determine whether the packet is permitted or denied. After the first match, no subsequent filters are considered.
*If the ACL denies the address or protocol then the software discards the packet.
*For hardware ACLs, if no filters match then the packet is forwarded.
*Checking stops after the first match, so the order of the filters in the ACL is critical. The same permit or deny filter specified in a different order could result in a packet being passed in one situation and denied in another situation.
*Multiple ACLs per interface, per protocol (i.e. IPv4 and IPv6), per direction are allowed.
*For inbound ACLs, a permit filter continues to process the packet after receiving it on an inbound interface, and a deny filter discards the packet.


'''The Need to Configure Access Lists'''<ref>[https://www.cisco.com/c/en/us/td/docs/ios/12_2/security/configuration/guide/fsecur_c/scfacls.html Why You Should Configure Access Lists?]</ref>

There are many reasons to configure access lists; for example, you can use access lists to restrict the contents of routing updates or to provide traffic flow control. One of the most important reasons to configure access lists is to provide security for your network. You should use access lists to provide a basic level of security for accessing your network. If you do not configure access lists on your router, all packets passing through the router could be allowed onto all parts of your network. Access lists can allow one host to access a part of your network and prevent another host from accessing the same area. In Figure 1, host A is allowed to access the Human Resources network, and host B is prevented from accessing the Human Resources network. You can also use access lists to decide which types of traffic are forwarded or blocked at the router interfaces. For example, you can permit e-mail traffic to be routed, but at the same time block all Telnet traffic. 


[[File: Access Control List.jpg|300px|Access Control List]]<br />
'''Figure 1.''' source: Cisco


Access lists should be used in "firewall" routers, which are often positioned between your internal network and an external network such as the Internet. You can also use access lists on a router positioned between two parts of your network, to control traffic entering or exiting a specific part of your internal network. To provide the security benefits of access lists, you should at a minimum configure access lists on border routers—routers situated at the edges of your networks. This provides a basic buffer from the outside network, or from a less controlled area of your own network into a more sensitive area of your network. On these routers, you should configure access lists for each network protocol configured on the router interfaces. You can configure access lists so that inbound traffic or outbound traffic or both are filtered on an interface. Access lists must be defined on a per-protocol basis. In other words, you should define access lists for every protocol enabled on an interface if you want to control traffic flow for that protocol.


'''Types of Access Control Lists (ACL)'''<ref>[https://msdn.microsoft.com/en-us/library/windows/desktop/aa374872(v=vs.85).aspx What are the Different Types of Access Control Lists (ACL)?]</ref>

An access control list (ACL) is a list of access control entries (ACE). Each ACE in an ACL identifies a trustee and specifies the access rights allowed, denied, or audited for that trustee. The security descriptor for a securable object can contain two types of ACLs: a DACL and a SACL.
*A discretionary access control list (DACL) identifies the trustees that are allowed or denied access to a securable object. When a process tries to access a securable object, the system checks the ACEs in the object's DACL to determine whether to grant access to it. If the object does not have a DACL, the system grants full access to everyone. If the object's DACL has no ACEs, the system denies all attempts to access the object because the DACL does not allow any access rights. The system checks the ACEs in sequence until it finds one or more ACEs that allow all the requested access rights, or until any of the requested access rights are denied. For more information, see How DACLs Control Access to an Object. 
*A system access control list (SACL) enables administrators to log attempts to access a secured object. Each ACE specifies the types of access attempts by a specified trustee that cause the system to generate a record in the security event log. An ACE in a SACL can generate audit records when an access attempt fails, when it succeeds, or both. 


'''What Does an Access Control List Consist Of?'''<ref>[https://www.pluralsight.com/blog/it-ops/access-control-list-conceptsWhat Does an Access Control List Consist Of?]</ref>
Regardless of what routing platform you utilize, all have a similar profile for defining an access control list. More advanced lists have more distinct control, but the general guidelines are as follows:
*Access control list name (depending on the router it could be numeric or a combination of letters and numbers)
*A sequence number or term name for each entry
*A statement of permission or denial for that entry
*A network protocol and associated function or ports
**Examples include IP, IPX, ICMP, TCP, UDP, NETBIOS, and many others
*Destination and Source targets
**These are typically addresses and can be defined as a single discrete address, a range or subnet, or all addresses
*Additional flags or identifiers
**These additional statements request additional functions when a match is found for the statement. These flags vary for each protocol but a common flag added to statements is the log feature that records any match to the statement into the router log


'''When are Access Control Lists Used'''<ref>[https://www.pluralsight.com/blog/it-ops/access-control-list-concepts When do we use Access Control Lists?]</ref>
ACLs for routers are not as complex or robust as stateful firewalls, but they do offer a significant amount of firewall capability. As an IT network or security professional, the placement of your defenses is critical to protecting the network, its assets, and data. ACLs should be placed on external routers to filter traffic against less desirable networks and known vulnerable protocols. One of the most common methods, in this case, is to set up a DMZ, or de-militarized buffer zone in your network. This architecture is normally implemented with two separate network devices. An example of this configuration is given in Figure 2. below:


[[File: Access Control List1.png|300px|ACL Configuration]]<br />
'''Figure 2.''' source: Tracey Wilson


Most exterior routers provide access to all outside network connections. This router usually has less restrictive ACLs but provides larger protection access blocks to areas of the global routing tables that you wish to restrict. This router should also protect against well-known protocols that you absolutely do not plan to allow access into or out of your network. In addition, ACLs here should be configured to restrict network peer access and can be used in conjunction with the routing protocols to restrict updates and the extent of routes received from or sent to network peers. The DMZ is where most IT professionals place systems that need access from the outside. The most common examples of these are web servers, DNS servers, and remote access or VPN systems. The internal router of a DMZ contains more restrictive ACLs designed to protect the internal network from more defined threats. ACLs here are often configured with an explicit permit and deny statements for specific addresses and protocol services.


'''ACL Implementations'''<ref>[https://en.wikipedia.org/wiki/Access_control_list ACL Implementations]</ref>

Many kinds of systems implement ACLs or have a historical implementation.
*Filesystem ACLs: A filesystem ACL is a data structure (usually a table) containing entries that specify individual user or group rights to specific system objects such as programs, processes, or files. These entries are known as access-control entries (ACEs) in the Microsoft Windows NT,[2] OpenVMS, Unix-like, and Mac OS X operating systems. Each accessible object contains an identifier to its ACL. The privileges or permissions determine specific access rights, such as whether a user can read from, write to, or execute an object. In some implementations, an ACE can control whether or not a user, or group of users, may alter the ACL on an object. Most of the Unix and Unix-like operating systems (e.g. Linux, BSD, or Solaris) support POSIX.1e ACLs, based on an early POSIX draft that was withdrawn in 1997. Many of them, for example, AIX, FreeBSD, Mac OS X beginning with version 10.4 ("Tiger"), or Solaris with ZFS filesystem, support NFSv4 ACLs, which are part of the NFSv4 standard. There are two experimental implementations of NFSv4 ACLs for Linux: NFSv4 ACLs support for Ext3 filesystem and the more recent Richacls, which brings NFSv4 ACLs support for Ext4 filesystem. PRIMOS featured ACLs at least as early as 1984. In the 1990s the ACL and RBAC models were extensively tested and used to administer file permissions.
*Networking ACLs: On some types of proprietary computer hardware (in particular routers and switches), an access control list provides rules that are applied to port numbers or IP addresses that are available on a host or other layer 3, each with a list of hosts and/or networks permitted to use the service. Although it is additionally possible to configure access control lists based on network domain names, this is a questionable idea because individual TCP, UDP, and ICMP headers do not contain domain names. Consequently, the device enforcing the access control list must separately resolve names to numeric addresses. This presents an additional attack surface for an attacker who is seeking to compromise the security of the system which the access control list is protecting. Both individual servers as well as routers can have network ACLs. Access control lists can generally be configured to control both inbound and outbound traffic, and in this context, they are similar to firewalls. Like firewalls, ACLs could be subject to security regulations and standards such as PCI DSS.
*SQL implementations: ACL algorithms have been ported to SQL and to relational database systems. Many "modern" (the 2000s and 2010s) SQL-based systems, like enterprise resource planning and content management systems, have used ACL models in their administration modules.


'''ACL Limitations'''<ref>[https://docs.oracle.com/cd/E19859-01/820-3252-11/FP44ucgACL.html ACL Limitations]</ref>

The following limitations apply to ACLs. These limitations are platform dependent.
*Maximum of 100 ACLs.
*Maximum rules per ACL is 8-10.
*The system supports ACLs set up for inbound traffic only.
*You can configure mirror or redirect attributes for a given ACL rule, but not both.
*The system does not support MAC ACLs and IP ACLs on the same interface.
*A hardware platform may support a limited number of counter resources, so it may not be possible to log every ACL rule. You can define an ACL with any number of logging rules, but the number of rules that are actually logged cannot be determined until the ACL is applied to an interface. Furthermore, hardware counters that become available after an ACL is applied are not retroactively assigned to rules that were unable to be logged (the ACL must be unapplied and then re-applied). Rules that are unable to be logged are still active in the ACL for purposes of permitting or denying a matching packet.
*The order of the rules is important: when a packet matches multiple rules, the first rule takes precedence. Also, once you define an ACL for a given port, all traffic not specifically permitted by the ACL is denied access.


'''ACL Best Practices'''<ref>[https://cloud.google.com/storage/docs/access-control/lists ACL Best Practices]</ref>

ACLs, like any other administrative setting, require active management to be effective. Before you make a bucket or object accessible to other users, be sure you know who you want to share the bucket or object with and what roles you want each of those people to play. Over time, changes in project management, usage patterns, and organizational ownership may require you to modify ACL settings on buckets and objects, especially if you manage buckets and objects in a large organization or for a large group of users. As you evaluate and plan your access control settings, keep the following best practices in mind:
*Use the principle of least privilege when granting access to your buckets and objects: The principle of least privilege is a security guideline for granting privileges or rights. When you grant access based on the principle of least privilege, you grant the minimum privilege that's necessary for a user to accomplish their assigned task. For example, if you want to share a file with someone, grant them READER permission and not OWNER permission.
*Avoid granting OWNER permission to people you do not know: Granting OWNER permission allows a user to change ACLs and take control of data. You should use the OWNER permission only when you want to delegate administrative control over objects and buckets.
*Be careful how you grant permissions to anonymous users: The allUsers and allAuthenticatedUsers scopes should only be used when it is acceptable for anyone on the Internet to read and analyze your data. While these scopes are useful for some applications and scenarios, it is usually not a good idea to grant all users OWNER permission.
*Avoid setting ACLs that result in inaccessible objects: An inaccessible object is an object that cannot be downloaded (read) and can only be deleted. This can happen when the owner of an object leaves a project without granting anyone else OWNER or READER permission on the object. To avoid this problem, you can use the bucket-owner-read or bucket-owner-full control predefined ACLs when you or anyone else uploads objects to your buckets.
*Be sure you delegate administrative control of your buckets: By default, the project owners group is the only entity that has OWNER permission on a bucket when it is created. You should have at least two members in the project owners group at any given time so that if a team member leaves the group, your buckets can still be managed by the other project owners.
*Be aware of Cloud Storage's interoperable behavior: When using the XML API for interoperable access with other storage services, such as Amazon S3, the signature identifier determines the ACL syntax. For example, if the tool or library you are using makes a request to Cloud Storage to retrieve ACLs and the request uses another storage provider's signature identifier, then Cloud Storage returns an XML document that uses the corresponding storage provider's ACL syntax. If the tool or library you are using makes a request to Cloud Storage to apply ACLs and the request uses another storage provider's signature identifier, then Cloud Storage expects to receive an XML document that uses the corresponding storage provider's ACL syntax.


== See Also ==
[[Operating System (OS)]]


== References ==
<references/>


== Further Reading ==
*[https://www.alliedtelesis.com/sites/default/files/acl_feature_overview_guide.pdf Access Control Lists (ACLs) - Feature Overview and Configuration Guide]
*[https://cloud.google.com/storage/docs/access-control/create-manage-lists Creating and Managing Access Control Lists (ACLs)]
__NOTOC__