Roles Based Access is not just for Warm Bums in Seats

 Roles Based Access Control has been around in various implementations since the introduction of multiuser computing. 

Whether you call it Roles Based Access, Security Groups, Security Profiles, or Access Control Lists, it all simply means the ability to restrict access to a particular set of compute resources.  Typically, these resources would be files/folders on a server, or tables/columns in a database.  It could also include more tangible access, such as printers/print queues, or physical badge access.

A "Role" would define a set of "things" that you can access based on your "position", "job function" or "location".   Any person (Warm Bum in a Seat) can belong to several roles. For instance:  I may belong to "Toronto Employees"  giving me limited access to buildings and printers in the Corporate Toronto Offices.   I may also belong to "Information Security Consultants"  which elevates my access to certain floors in the Toronto Office, as well as defining some filesystem and Intranet access. In addition, my membership in "Global Security Architecture"  would provide specific access to resources for that purpose. 

Certain roles require Privileged Access, such as Systems, Network, or Database administrators.

But none of this is new to you, right? 

So, where I'm going with this, is to extend the concept of who or what should have "Roles" applied to them.

The base Information Security requirement is to protect our data... The Corporate Crown Jewels.

Data, based on it's ownership and Clasification,  should be protected under a Role. (Nothing new here!)  The files/folders or tables/columns that represent that collection of data should ONLY be accessible by other entities that are members of that Role. (Also nothing new!) 
Applications that need to call that data must run under an account that is a member of that Role. (Again nothing new!) 

What *is* new, or at least rarely considered or implemented, is the removal of the above mentioned Privileged Users.

Systems Administrators and Database Administrators, by virtue of their job function have historically had full and complete access to everything on their systems.  To fully protect your Data, you Crown Jewels, this default access must be removed.  All current Operating Systems and Databases today provide for this ability.  Yes, you must make provisions for contingency, but we will get into that in a future discussion on Privileged Identity Management.


So lets assume that you have a collection of data for the function of "Payroll".  There may be files on a server that define the default configuration of the application that calls a database to retrieve payroll information for an end user.  All points of this operation should be controlled under the same Role or set of Roles. 

• A Role is created called "Payroll" to define Member Access
• The End User running a report against the payroll data must be in the Role "Payroll"
• The Application the End User logs into must run under an account in the "Payroll" Role
• Any critical file that configures how that application works must be a member of "Payroll" 
• The Database account that accesses these tables/columns must be a member of "Payroll"
• The tables/columns must be owned by a member of "Payroll".

If you can imaging, a Role or Security Profile extends from the Warm Bum in a Seat, through the application they are using to the service ID that calls the database tables...

Yes.... I understand that we may be traversing multiple discongruous systems here (ie: Operating System  permissions versus Database permissions, and potentially Network permissions if you add NAC to the mix), but if you are not a fan of manual provisioning processes...there are tools out there for this....  



Over the course of the next several blogs, I will posit that "Roles" will become much important as we move into a world of BYOD  (Bring Your Own Device),  Telecommuting, and Cloud Computing.