Engineering IT User Maintenance

Scope

The management and maintenance of accounts at the College of Engineering is an important task that is shared by the administrators of the various systems, by the business and technical owners of the various processes and by BU Information Security. This procedure describes the request and approval process for obtaining privileges for a user account, an administrative account, a role-based account, or access to a service or process account. This procedure applies to all Engineering IT managed systems. Note that the requirements and provisions of this document apply immediately for all accounts created from this point on any Engineering IT systems and/or any hosted client systems. Accounts on systems currently in existence do not immediately fall under these requirements but should comply by (Jan 1, 2018).

Philosophy and Principles

  • The principle of least privileges applies: To the extent possible, accounts should be granted sufficient privileges to perform the approved business function and no more.
    • Where a person has multiple accounts or has the ability switch to a privileged account, the least privileged account will be used for the normal day to day non-privileged activities. The privileged account should only be used when the elevated privilege is required.
  • Personal accounts and the passwords to those accounts may not be shared.
  • Role-based accounts may be used sparingly as appropriate and only for executing functions of the particular role. In this context, a role-based account is an account that performs a given function required for a given role, but is not associated with a particular individual.
  • All requests must be reviewed and approved from both a business and a technical perspective. The business approval confirms that the account requested is needed to perform a require business function and the technical approval confirms that the privilege requested is required to achieve the approved business need.
  • Both the business and technical approvers should be managers as close to their respective areas of approval as practical to ensure that they have the requisite business and technical knowledge required to properly perform their duties.
  • Separation of duties must be maintained: The person with the authority to approve a request should not be the person that fulfills the request.
  • Data Custodians (Typically Systems Administrators, Database Administrators, Application Administrators for Engineering IT) are responsible for:
    • Executing the approved account definition/modification/removal request , after validating that appropriate approvals have been granted
    • Conduct quarterly internal system audits of system accounts and maintain documentation accordingly
    • Defining the general account management processes (this document)
    • Consulting with system owners on system-specific account management processes
    • Working with system owners to define and document appropriate audit procedures
    • Conducting appropriate periodic audits of system accounts and the account management process

Account request and provisioning

  • New account/privilege request is made using the institution’s ticketing system (ServiceNow)
  • Request is sent to requestor’s manager for business approval
  • Request is sent to the appropriate Engineering IT Administrator
  • Request is sent to the technical manager of the system in question for technical approval
  • Request will be forwarded to IS&T in cases where Engineering IT does not have appropriate access to account memberships
  • Final approval is sent to Engineering IT system administrators for implementation or IS&T Data Custodians

Account de-provisioning

  • Account/privilege removal request is made using the institution’s ticketing system (ServiceNow) by the person’s manager or designee or automated process.
  • Request is sent to Engineering IT System Administrators for information and routing as well as implementation
  • Such accounts or privileges must be removed in a timely fashion following notification; generally, within a few business days unless a specific timeframe is requested.

Account Request and Provisioning

  • Making the request
    Requests will be made, recorded, processed and archived using the institution’s service management solution, currently ServiceNow. Privileged access may be granted permanently only if that specific person’s job duties routinely require that level of access, otherwise, the access will be temporary. Privileged access is dependent on the specific person’s job duties, not the duties of the person’s group. Temporary accounts and privileges must expire within 45 days or less; if more time is required, an extension may be requested on the original ticket.
  • Request Approval
    Prior to creation of the account or granting of new privileges, the request must be approved from both a business and a technical perspective. Approvers should be managers as close to their respective areas of approval as practical to ensure that they have the requisite business and technical knowledge required to properly perform their duties. Engineering IT System Administrators will approve/implement all privileged accounts based on role and system.
  • Implementation
    Approved requests are forwarded to the appropriate Engineering IT System Administrator who verifies that the request has been properly approved, and creates the requested account and/or grants the approved privilege. Accounts intended for individuals should be part of the Global UID system and should use Kerberos authentication, if possible. Service/Process accounts may be defined locally. If the account is to be accessed via a password, the password should follow University password guideline.

Root access and the sudoers file

Administrative privilege (root, e.g.) to Engineering IT servers is restricted to Engineering IT System Administrators unless special permission is granted by Engineering IT System Aministrators. If Administrator privilege is needed by anyone else, the request is made using the process described in this procedure, and an end date must be provided. The sudoers file grants a given account or group the ability to run programs as another user. For example, a user account may be granted the ability to run programs as the root user when needed. Such activities must be logged and the logs reviewed on a routine basis.

Account De-provisioning & Privilege De-escalation

Managers are responsible for submitting a ticket requesting an appropriate change in account or privilege status when a person’s job function changes, they transfer to another department or the leave the university. To ensure the security of our systems, this process must be accomplished in a timely fashion. Temporary accounts must be expired by the requested date or within 45 days, whichever is sooner

Changing Passwords for Service/Process/Root/Administrator

Accounts When a person that has a password or authentication token (ssh key, e.g.) for a service/process account no longer requires access, such as might result from changing positions or terminating employment, his or her manager is responsible for submitting a ticket requesting the password or token be changed. Due to the potential sensitivity of such accounts, it is preferred that the request be made in advance of change in responsibility (provide the effective date). If this is not possible, the request must be made within 1 business day following the change.

Password Policy

See Boston University Policy ID: BU 000-005C