Privileged Account Management

Introduction

  1. Privileged Accounts provide a very high degree of access to UBC Electronic Information and Systems and therefore pose a significant risk if used in an unauthorized manner.
  2. This standard establishes requirements for the management and use of Privileged Accounts. Unless otherwise stated, Privileged Accounts are subject to the same requirements as User Accounts, as set out in the User Account Management standard. The purpose of this standard is to highlight the different or enhanced security controls that must be in place to protect Privileged Accounts.
  3. The Information Steward/Owner is responsible for compliance with this standard.
  4. The Chief Information Officer has issued this document under the authority of Policy 104, Acceptable Use and Security of UBC Electronic Information and Systems. Questions about this standard may be referred to information.security@ubc.ca.

Types of Privileged Accounts

  1. Privileged Accounts are usually categorized into the following types:
Privileged Account Type

Description
Privileged Personal Accounts Privileged Accounts assigned to individual Users (usually University IT Support Staff). Examples include the following privileged groups which Users are added to in order to elevate their privileges to the associated group access levels: DBA user, Exchange Admins, Domain Admins.
Generic/Shared Administrative Accounts Privileged Accounts that exist in virtually every device or software application; these accounts hold "super user" privileges and are often shared among University IT Support Staff. These accounts may be used by multiple Users. Examples: Windows Administrator, UNIX root, Oracle SYS, SA.
Emergency Accounts Generic Privileged Accounts used by the enterprise when elevated privileges are required for business continuity, disaster recovery, or to fix urgent problems. These accounts may be used by multiple Users. Also called: break-glass accounts, fire-call IDs.
Service Accounts Privileged Accounts that provide a security context to a running service, daemon or process, such as a file server, web server, e-mail server, etc., or are used by applications to access databases and other applications; these accounts typically have broad access to underlying business information in databases. Also called: app2app accounts, as they are used by one application to sign into another.

Creating Privileged Accounts

  1. Privileged Accounts may be shared between multiple Users (except for Privileged Personal Accounts, which must be assigned to unique individuals). However, for all account types, a single individual must be assigned with accountability for the security of the account.
  2. Approval procedures for granting access to Privileged Accounts are set out in Authorization for Privileged Account Access procedure.

Protecting Privileged Account Passwords

  1. Service Accounts must not be shared between applications or services, i.e. a separate account must be created for each application/service.
  2. Passwords for Privileged Personal Accounts must be changed regularly, in compliance with the Password and Passphrase Protection standard, or at an interval stipulated by the Information Steward/Owner.
  3. Passwords for Generic/Shared Administrative Accounts and Emergency Accounts should be machine generated and held in a secure place, available to system administrators in the case of an emergency through a Break Glass Procedure created by the Information Steward/Owner.
  4. A Break Glass Procedure (which draws its name from breaking the glass to pull a fire alarm) refers to a quick means for a person who does not have access to a Privileged Account to gain access in an emergency. When a Break Glass Procedure is used, access to the Privileged Account must be:
    1. limited to the minimum amount of time necessary;
    2. associated to a change, problem or incident number/ticket;
    3. recorded by the specific database, system, or application; and
    4. logged in an auditable record (which identifies the individual User who 'broke the glass') for later review.
  5. After a Break Glass Procedure has been completed, the password for the Privileged Account must be changed.

Logging Privileged Accounts

  1. There are special requirements for logging Privileged Account activity, which are set out in the Logging and Monitoring of UBC Systems standard.

Reviewing Privileged Accounts

  1. Access to Privileged Accounts must be reviewed at an interval stipulated by the Information Steward/Owner, or at a minimum annually, to validate that they remain restricted to authorized personnel. Discrepancies must be reported in a in a timely manner to the Information Steward/Owner for resolution.

Responsibilities of Users with Access to Privileged Accounts

  1. As Privileged Accounts provide a significant level of control over UBC Electronic Information and Systems, individuals with access to these accounts are expected to exercise a higher degree of caution than for User Accounts.
  2. All Users with access to Privileged Accounts must maintain the confidentiality of any information that they have access to both during, and after, their employment with UBC.
  3. All Users with access to Privileged Accounts:
    1. must not use Privileged Accounts for day-to-day activities, such as email and web browsing;
    2. wherever possible, must not use Privileged Accounts (except Service Accounts) to run daemons, services or applications.
  4. University IT Support Staff with access to Privileged Accounts must also comply with the System Administrators' Code of Ethics.

Related Documents