There are four basic strategies towards controlling what access a user has while signed into a privileged account login session. In the following, we'll use Unix/Linux examples, but the same principles apply to all types of systems:

  • Coarse-grained: (root, Administrator, etc.)

    Grant authorized users full administrative access, through a request/approval or pre-authorized mechanism. Log metadata about the session and optionally capture video, keylogs, etc. of the session itself. Do not limit what commands users can execute while connected.

    This is by far the easiest to manage approach to securing elevated rights and is usually the most popular with IT users, as they are accustomed to having full access.

  • Medium-grained: (functional accounts)

    Create a series of functional accounts on each system. For example, one is a DBA, another is a user manager, another can just view logs, etc. Give the accounts descriptive names and assign them privileges via a native mechanism such as sudo on Unix/Linux, group policy objects on Windows or roles on Oracle.

    Enable groups of (human) users access to different functional accounts based on their job function.

    This is a reasonable compromise -- not as coarse grained as the above, so users get a fair approximation of the rights they actually need for their work -- and not as fine grained as below, which means much less work required to define and maintain access control rules.

  • Fine-grained: (command-level control)

    Either replace the native access control mechanism on the target system with a custom one (e.g., provide an alternative to sudo) or extend it (sudo supports plug-ins). Externalize access control decisions at runtime to a central policy system. This means many real-time queries that ask whether user X may run command Y on system Z.

    This approach is the most invasive (code on every managed endpoint) and the most complex to manage (very detailed policy definitions).

    There are platform-specific products that do this on Unix/Linux and (separately) on Windows.

  • Fine-grained via requests:

    The same as the coarse grained mechanism, but instead of allowing users to launch interactive login sessions, requires requesters to specify what commands they wish to run, and runs those commands on behalf of the authorized user. This approach can replace tedious policy definition with (still tedious) review/approval processes.

Hitachi ID Systems recommends the medium-grained approach above. It strikes a balance between fine-grained control and manageability and does not introduce too many fault-prone architectural elements.

Some Hitachi ID customers prefer the coarse-grained approach, primarily because it is less work to configure and maintain and better accepted by IT staff.