This article describes a number of best practices for managing access routes when implementing BoKS in your organization.

Setting up access routes

Access to UNIX accounts should be granted following the principle of least privilege. BoKS allows you to do this by defining access routes for accounts. For access control purposes, accounts in BoKS can be categorized into the following four types, each of which has different recommendations:

  • root
  • OS system accounts
  • application/functional/service accounts
  • human end users

Access routes for root

The root accounts should generally not allow direct access. Direct access should require the administrators to log in as themselves and then escalate privilege with SU or SUEXEC. This includes LOGIN on the console, as the console is usually reachable from the network. However if the console is only reachable by access to a location with physical security controls (badge or biometric access and active video cameras), this may be enough mitigation to relax this part.

If there are automated processes that require root access, grant the specific access required limiting access method, source, destination, and time of day/ day of week to be only what is required. For instance, allowing SSH,SSH_SCP:hosta->hostb on Tuesday 1:00 AM to 2:00 is better than SSH*:ANY/*->HOSTGROUP on any day 24 hours. Routes should generally be assigned directly to the root user, but User Classes can be used where there is benefit.

Access routes for OS system accounts

These are accounts like “bin”, “lp” and “sys” that are part of the operating system. They must exist on the system and will own files and processes. There will generally never be any access allowed to these accounts. They technically do not need to exist in BoKS, but they usually are defined via Operating System specific Host Groups.

Access routes for application/functional/service accounts

These are accounts that own application files and processes. These have similar needs to root. These should not be used for interactive access. Application administrators should log in first with their own personal end user account and then switch to the application account with SU or SUEXEC.

It is likely that there will be automated processes that require access routes. Similar to the situation for root, grant the specific access required limiting access method, source, destination, and time of day/ day of week to be only what is required. For instance, allowing SSH,SSH_SCP:hosta->hostb on Tuesday 1:00 AM to 2:00 is better than SSH*:ANY/*->HOSTGROUP on any day 24 hours. These routes will most commonly be assigned directly to the user, but there are some applications that have groups of accounts with similar access needs. In this case, it often makes sense to assign the routes to a User Class.

Access routes for human end users

Commonly, the access routes that should be granted to an individual user are determined by the user's role in the organization. Create User Classes to group users by these roles in the organization. Then add access routes to these classes. If a user has several roles, the user can be added to several User Classes. Using User Classes in this way makes an environment that is much easier to maintain and audit.

If a role requires an additonal access route, it can be added to the User Class. If a user changes role, they can be assigned to another User Class. Each User Class should have a person (or sometimes department) to own the class. This owner should be responsible for approving these changes to access routes or user membership in the User Class.

There may be a few times when it makes sense to assign access routes directly to an end user. Examples are when there is an exception to policy or for a temporary access. In both cases, there should be a process in place to monitor and remove them when no longer required.


Still have questions? We can help. Submit a case to Technical Support.

Last Modified On: May 25, 2018