The Principal of Least Privlege

So in my previous post we talked about some low hanging fruit in terms of securing your web applications MySQL server. Many of the items we discussed are based on the Principal of Least Privilege.  This principal guides us as we secure out applications.  Quite simply it means to restrict functionality, users and programs to fit the task that they are supposed to do.  For example in our previous post we discussed creating an application db user that the application will use to access the app data in the schema.  This user is limited in to only have access to the web app schema.  In addition, we restrict this ID to only have CREATE, UPDATE, and DELETE on the tables in this schema.  This is the Principal of Least Privilege in action.

This Principal can be applied across IT and business in many different ways.  Users within this application should be restricted to be able to perform only the functions we want to allow and no more.  The security officer that rekeys the application encryption should have an id that will only be able to do that specific task.  The UNIX permission system is a another example if configured correctly.  A user has read, write execute over his files and can set others so they only have read.  UNIX sudo is really a violation of this principal, however, it's usage is logged so that is a mitigating control.