ICANN Blogs

Read ICANN Blogs to stay informed of the latest policymaking activities, regional events, and more.

Access Controls, User Permissions and Privileges

19 January 2016
By Dave Piscitello

In addition to the U.N. six languages, this content is also available in

null

In my last post, What is Authorization and Access Control, I explained that we use authentication to verify identity – to prove you are who you claim to be – and also to enable an authorization policy, to define what your identity is allowed to "see and do". We then implement these authorization policies using security measures to grant or deny access to resources we want to control or protect.

The measures we use to implement authorization policies are called user access controls, user permissions or user privileges. User access control is commonly used in the Windows operating system, router or firewall documentation, but user privilege or user permission is more common to Linux documentation. You may find entire threads that discuss differences among these terms, but for introductory purposes, treat the terms as if they are interchangeable. Use the term you're most comfortable with or that you encounter most frequently in the literature that's most relevant for you.

When you define an authorization policy, you define individual or sets of users, applications or processes that can perform actions on a resource such as a database. You can be very granular with an authorization policy. You can control actions - whether individuals or groups of individuals can read, create or modify (write), delete – on individual database entries, or even individual elements (fields) of a database entry.

An Example Authorization Policy

Let's imagine a merchant database of records where each record contains a name, home address, telephone and credit card information. The merchant's IT staff defines an authorization policy that organizes access for the merchant's employees into three classes of privilege:

  1. Database administrators, Joe and Terry, can perform any action on any customer record in the database. For example, they can create a record, modify any element of any record and delete any record.

    This is an example of full access.

  2. Accounting staff, Charlotte and Bert, can read any field of any customer record including the credit card information, but they may not create, modify, or delete records or fields within records.

    Here, we allow access to the full set of records but we deny the ability to create, alter, or delete any records or fields within records.

  3. Marketing staff, Ahmed and Carlo, can read any customer record but they cannot read the credit card information, and they are not permitted to create, modify, or delete any record or field.

    Here, we allow access to the full set of records, but we deny access to specific data within each record.

These examples illustrate an important security concept, the principle of least privilege (POLP), where an organization grants users only those privileges they need to do the work they've been assigned. For example, our fictitious company has decided that marketing staff do not need to access credit cards. Our examples also illustrate role based access control (RBAC). In the examples, the company has set privileges based on the set of roles {database administrator, accounting staff, marketing staff…}.

Setting the Stage

Consider the access controls in our example, and ask, "If you're an attacker and you want to steal information you can use to fraudulently use credit card information, which user accounts would you want to gain access to?"

We'll look at how attackers try to gain access and escalate privileges in our next post.

Authors

Dave Piscitello