Access Control

Mechanisms, processes, and procedures must be in place to control access to university information systems, data, and resources. Those who have been authorized to use systems, data, and resources should be given access when needed. That access should be removed when no longer needed or authorized. (See Physical Security for guidance related to access control to U-M facilities in which IT systems process or store sensitive institutional data.)

Access for automated processes, applications, and non-person accounts should be reviewed on a regular basis and removed when no longer needed.

Use Role-Based Access When Possible

Access control should be role-based whenever possible, with access changing as an individual's role at U-M changes over time. An individual's affiliation with U-M, for example, determines their eligibility for standard U-M computing services:

  • New U-M employees automatically receive the standard computing services on their first day of work when their MCommunity Directory entry is updated to include their active university employment affiliation (see Uniqnames & Accounts).
  • MCommunity is also used to de-provision those services when people are no longer eligible for them (see Leaving U-M).

Access to administrative data in systems maintained by Information and Technology Services (ITS) is managed in the Online Access Request System (OARS):

  • Managers can request administrative and other access for new employees whose job duties require it.
  • When a U-M employee moves from one unit to another, the Unit Liaison for the new unit is expected to review the person's administrative access and remove access that is no longer needed.
  • ITS automatically removes a terminated employee's administrative access within two weeks of the employee's termination date as recorded in the M-Pathways Human Resource Management System.

ITS has begun to introduce a new tool, Identity Governance, for automatically granting and revoking access across systems based on criteria such as department and title. Units interested in making use of this tool can work with ITS to determine and set up rules within the tool to automate the appropriate permissions and access. If your unit is interested in learning more about implementing IG, send email to [email protected].

Access to departmental or unit-provided services is generally managed by the department or unit, which is responsible for ensuring that individual requests for unit access are limited to systems and access levels required for the individual’s role and specific job responsibilities—and for meeting the access control requirements below.

Access Control Requirements

Access control at U-M, whether managed at the central or unit level, must adhere to the following requirements from Access, Authorization, and Authentication Management (DS-22):

  • Access Only If Authorized. Users must not attempt to gain access to university information systems or databases for which they have not been given proper authorization.
  • Access Review. User, privileged, and shared accounts should be reviewed on a regular basis and at least annually.
  • Access Revocation or Termination. The authorized access of faculty, staff, and other affiliates to systems that maintain data classified as Restricted or High data, to regulated data (for example, PHI, export control), or to privileged accounts should be revoked within 72 hours or as soon after as possible when:
    • The individual leaves U-M (that is, their employment or affiliate status is terminated).
    • The individual transfers from one position or role to another where different levels of access are required or appropriate.
  • Additional Access Controls for Data Classified as Restricted or High. Additional role-based access enforcement mechanisms should be employed at the application level for access to data classified as Restricted or High wherever possible.
  • Lock Screen or Log Off. Users are required to lock their screen or log off of IT systems when they are finished with their current session or expect to be away from their workstation.
  • Principle of Least Privilege. Individuals should be granted the minimum access sufficient to complete their U-M responsibilities. Individuals who are granted privileged access should use the least privileged account for their day-to-day activities; privileged accounts should only be used when the elevated privilege is required by the system or application.
  • Responsible Use Notification and User Acceptance Login Banner. U-M Weblogin and Active Directory login must include notification of user requirement to abide by Responsible Use of Information Resources (SPG 601.07) and provide for one-time user acknowledgment of such requirement.
  • Separation of Duties. No one person should have responsibility for more than one related function. Authority to grant access, fulfill requests for access, administer access, and audit access should not be performed by the same individual. At no time should any person fulfill and grant access to themselves.
  • Training and Compliance. Before being granted access to any enterprise administrative or clinical system, or U-M or unit-specific application or database, users must complete the appropriate required institutional or unit-specific training. See specifics in Information Assurance Awareness, Training, and Education (DS-16).
  • User Identification. Each user should have a unique ID. Eligible university users are granted one unique user ID (uniqname). The uniqname and UMICH password are used for access to university systems, data, and resources. Units should make use of uniqnames when providing access to unit systems, data, and resources whenever possible. Faculty, staff, students, and alumni receive, or can obtain, a uniqname and UMICH password by virtue of their university affiliation. Units can sponsor people who otherwise have no university affiliation to obtain a uniqname and UMICH password for them. Other options include U-M Friend accounts, federated identities, social login, or documented trusted relationships. Individual user IDs may never be used by more than one individual for system access.
  • Privileged Credentials and Shared Accounts. Owners of privileged and shared accounts, as well as as well as individuals granted elevated access to such accounts, need to be especially diligent to reduce the risk of threats to institutional data from misuse, including credentials theft, inappropriate disclosure of sensitive data whether intentional or accidental, data tampering, and unauthorized access to administrative interfaces and configuration stores.