For example, in a payroll application, you might have the payroll data entry clerk, the accounting and general ledger associate, the check publisher, and the payroll manager. The application developer defines the various roles and ties each role to various tasks needed to perform the role (called transaction authorization in RBAC terminology).

When the application is installed, the application manager assigns the various users or groups to their needed roles (called role authorization). Then the end-user can perform only the tasks assigned to their role (rule assignment). 

A great benefit of role-based security is dynamic access control. When the end-user is not performing a particular task, they don't have any access permissions to the underlying resources. For example, when a payroll data entry clerk is logged into a RBAC application performing their normal duties, they have read and write access to the appropriate fields of the payroll database. When they come out of that particular task -- say, to a main menu -- their access to the database is removed altogether.

This is a great improvement over other access control implementations. Consider how access control works on most systems today. The payroll clerk is probably given read and write permissions to the entire database file in perpetuity until their user account is disabled or deleted. Unbeknown (hopefully) to the payroll clerk, they could probably delete or overwrite the entire database file if they accessed it directly using a file share instead of through the application view (called view-based access control). Our security is based on obscurity and the hope that our employees don't want to harm the company. What's to stop the employee from downloading the entire database to gazillion-gigabit USB drives and taking it to a competitor?

Time to start
If you don't have a role-based security model, you should start researching it and strive to move to RBAC, if only a tiny step at a time. You can start by defining your access control security groups by roles instead of departments. Don't designate HR, IT, and accounting security groups; instead, create security groups for each department based on their roles. Look to your company's organizational chart or job descriptions if you need a beginning point.

Start investigating software that uses an RBAC model. Look at the RBAC tools in your OS, whether it's Windows, Linux, Unix, OS X, Solaris, or something else. Investigate software that can bring role-based access control to your environment. Just use the keywords role-based access control or role-based management in your favorite Internet search engine.

Ask your software vendors what they are doing to facilitate RBAC in your environment with their products. Educate your vendors if they have never heard of it. When the vendor hears it enough or if you have enough dollar votes alone to make it happen, the vendor will become a RBAC proponent. Then everybody wins.

Implementing a RBAC model is a lot of work and a lot of groups, but anything less means you aren't truly implementing least privilege in your environment. Until you have RBAC, least privilege is just something you repeat over and over as a mantra, but can't really accomplish.