In addition to applying access controls to end users and objects, you can apply them to applications as well. This takes two forms—internal to the application and through the operating system.

You can assign an application its own user ID and directories. From there, you can grant the application rights only to the files and directories it needs to run and explicitly deny access to the rest of the system. This gives the application a sandbox to work in. If the application is compromised through an exploit in its code, the malicious user will only have access to the information that the application had access to. This type of access control is common on web servers and application servers, which are highly accessible to the general public. Database servers typically operate behind a firewall and have little direct exposure to the public, but web servers are public by design. This accessibility requires additional security measures that are not necessary on more protected servers, such as a database server.

Certain executables have their own internal access controls as well. Internal access controls are necessary where the application holds sensitive information in a format that is not accessible to the general file system. This situation is common in database management systems, where data are stored in raw form in tables or in binary large objects (BLOBs). In these cases, information must still be secured but is inaccessible to the file system ACLs.

Let’s take a look at an example of internal access controls. Suppose a homeowners’ insurance company needs a way of controlling access to claims data—not only information on individual customer claims but also sensitive pricing information. The pricing information is especially critical. The price lists give the company a competitive advantage because its estimates are more accurate than its competitors’. The accuracy is due to the extensive real-time pricing data in the price lists. The information is also legally protected. Due to recent lawsuits in the industry, the insurance company has to show that the price lists cannot be modified at will.

The claims files and the pricing information are stored in a relational database management system (RDBMS) as binary large object (BLOB) data and inaccessible to the file system. The only way to access the data is with an estimating tool, but that doesn’t guarantee data privacy or integrity as most of the company has the tool. In fact, it is an off-the-shelf application that other insurance companies and independent contractors have access to as well.

To secure the information, the insurance company works with the application vendor to develop an RBAC system built into the application. This involves roles like claim representative, who has the rights to create and modify estimates; pricing specialist, who can create and modify price lists; and super user, to handle administrative and support aspects of the application.

Adding the roles takes care of data privacy but not necessarily data integrity. To handle that, an auditing log and rollback functionality is added to the application. A user can see who has made changes to a file, when, and what changes were made. This includes claims files and price lists. If a file is changed incorrectly, a user with super rights can restore the file to a previous version.

All of this is done inside the application. The file system is unaware of any of the roles or protected data that resides inside the RDBMS.