Centralized Access Policy

(Click on images for higher definition view)

PUM architecture - physicalLarge users of UNIX and Linux based computer systems are typically aware of the requirement to manage, monitor and audit privileged access.  If you have many tens, hundreds, thousands, or even tens of thousands of computer systems, the problem of setting privileged access policy is a time-consuming and difficult one; if each system has to be treated as a separate entity.

To that end PUM provides for the definition of centralized access policy.  Users do not directly log into the Managed Servers on which the privileged Account resides, but log in as themselves through a PUM Access Server.  The User requests access to a particular PUM Session, each Session being an instance of Access Policy that defines who may access which Accounts on which Managed Servers, when they may do so, and what commands they may invoke.   The Access Server compares the request to centralized Access Policy and if the User's request matches policy then the Access Server will create a connection between itself and the selected Managed Server(s).   The User is connected to the Access Server, the Access Server is connected to the Managed Server; all communication between the User and the Managed Server goes through the Access Server so that all communication can be filtered and audited. 

The definition of centralized Access Policy using PUM is a simple task.  PUM is written entirely in Java so is object oriented.  Each Session is defined by combining those objects that make up that instance of Access Policy.  For example, PUM provides for Role Based Access Control so defining who may access a Session just involves assigning the appropriate Roles.  In the same way, reusable Calendars and Schedules can be used to define when a Session may be accessed.

Access Policy ERDThe diagram on the left illustrates how a Session is defined.   

Each Session has exactly one Shell attached to it which defines which commands, combined into Command Sets may be invoked, the user Account on the Managed Server that those commands will run as, and the environment in which they will run.  Most users of PUM grant their in-house systems administrators unrestricted command access via PUM (at least to non-critical systems) but the granularity may be as finite as you wish.

One or more Schedules attached to a Session define when it may be invoked.  A Schedule may be unrestricted, in which case it will allow the Session to which it is attached to be invoked at any time, or be made up of one or more Calendars.  Calendars are simple definitions of times and dates which are concatenated via a Schedule to define all allowable dates and times.

Both the Managed Servers on which the privileged Accounts reside and the Access Servers through which you want your privileged Users to access PUM may also be defined on a Session by Session basis.

Sessions may be as unrestricted as you want them to be for your in-house Users, and as restrictive as you want to make them for your external contractors.  No matter how you define the Sessions, all traffic will be audited.