Previous month:
May 2017
Next month:
November 2017

June 2017

Access Controls, User Permissions and Privileges

In my last post, What is Authorization and Access Control, I explained that we use authentication to verify identity – to prove you are whom you claim to be – and also to enable an authorization policy, i.e., 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, but are also known as user permissions or user privileges. User access control is commonly used terminology in the Windows operating system, router or firewall documentation. 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.

 

16037463716_bf35c6b7ff_m
Image by Thomas Hawk

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…}.

A database is only an example of a resource for which you can write an authorization policy. You can define policies that permit or prohibit access to a network, IP address, or service. You can define policies that permit or prohibit installation or execution of software. You can even define policies that constrain access to times of day or location. These granularities give administrators considerable flexibility in managing resources or protecting them against threats.

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.

 

An earlier version of this post originally appeared at ICANN blog on 19 January 2016.