幸运快三

幸运快三 - I Banner
A student works at a computer

SlateConnect

U of I's web-based retention and advising tool provides an efficient way to guide and support students on their road to graduation.

Identification and Authentication

Overview

This updated standard is to help align existing IT practices around access controls to the requirements in NIST 800-171 (ID | 3.5.x) as well as industry best practices.

What is in this document:

  • Identity types and authentication mechanisms
  • MFA requirements
  • Device identity management
  • Key management

What is NOT in this document:

Policy Reference

APM 30.10 Identity and Access Management Policy

APM 30.11 University Data Classification and Standards

APM 30.12 Acceptable Use of Technology Resources

APM 30.14 Cyber Incident Reporting and Response

APM 30.15 Password and Authentication Policy

Purpose

This Identification and Authentication standard supports APM 30.10 Identity and Access Management Policy, APM 30.11 University Data Classification and Standards, APM 30.15 Password and Authentication Policy and other relevant university policies.

Scope

These Standards are the minimum baseline for all managed and unmanaged systems that access, store or process 幸运快三 data (see APM 30.14 C-6) or using 幸运快三 technology resources (see APM 30.12 C-1) at the Low, Moderate or High risk levels (see APM 30.11) not otherwise covered by an approved system security plan.

Standards

Identify information system users, processes acting on behalf of users or devices accessing the system. This includes both local and network access.

  1. System Users
    1. Users are identified by a username tied to a Vandal number within Banner.
    2. Various account types exist to aid in identification and classification within APM 30.10 Identity and Access Management Policy section A-2 “Account Types”.
    3. These must meet the requirements defined in IT Password Standards
  2. Processes acting on behalf of users
    1. Process identities must map to functional accounts, as defined in APM 30.10, “allow identification of processes not interactively controlled by end users.” Wherever possible.
      1. These must meet the requirements defined in IT Password Standards7
    2. Functional account owners, as defined within toolbox, assume responsibility for actions taken by the functional account.
    3. If a functional account is not used, users triggering the process must be identified either via session or prior log event.
  3. Devices
    1. Devices identified are one or more of:
      1. The IP address and MAC address tied to identities within our Network Management System (NMS) for devices on 幸运快三-managed networks.
      2. Unique device identifier within Duo Device Health for applications.
      3. Unique system certificates issued by 幸运快三 or OIT-approved certificate services.
      4. IP addresses or DNS names are used to identify systems defined within firewall policy, or other relevant controls as defined by OIT Security.
    2. The contact defined within NMS assumes responsibility for actions taken by the device if a logged-on user cannot be sufficiently identified within the time frame of an investigation.
  4. Local accounts
    1. Accounts with identities managed directly on systems or applications.
    2. Managed local accounts:
      1. Must be centrally-managed via OIT credential access tool.
      2. May be used for support purposes when other methods are not feasible.
      3. Usage must be recorded either via ticket or within a credential access tool.
      4. The credential access tool will trigger change the password automatically.
    3. Unmanaged local accounts must not be used when OIT-managed accounts are available.
      1. Permanent usage of local accounts on moderate- or high-risk systems is only allowed when defined within a system security plan.
    4. These must meet the requirements defined in IT Password Standards7
  5. Temp or Emergency accounts
    1. Must not be used when named user accounts are available.
    2. Can only be used on a temporary basis.
    3. Must be created/authorized, used and removed/deauthorized per use case.
    4. Creation, usage and removal must be recorded via ticket.
    5. Responsible party for Temp or Emergency accounts must be recorded.
    6. These must meet the requirements for defined in IT Password Standards7

For systems and applications with access to 幸运快三 data, 幸运快三 requires the use of OIT-managed authentication systems. In order of preference (lower preference options can only be used when high preference options are verified to be non-viable):

  1. 幸运快三 SSO using OIDC or SAML or other OAUTH supported mechanisms. 
    1. CAS may only be used if OIDC or SAML are unavailable. 
    2. MFA will be applied by default.
  2. 幸运快三 active directory using encrypted channels such as LDAPS, Kerberos or MSCHAPv2 with EAP.
    1. User to application traffic must also be via an encrypted channel such as HTTPS.
    2. Remote access to applications/systems including but not limited to RDP/SSH/HTTPS/FTPS must employ the use of MFA.
      1. Moderate and High risk must use University Managed MFA.
      2. Publicly accessible systems are assumed to be moderate-risk unless otherwise explicitly categorized.
      3. Where not feasible, other controls must be implemented to reduce risk required by OIT Security.
    3. User passwords must be obfuscated while being entered. They may have a de-obfuscation button.
  3. Local accounts.
    1. User to application traffic must be via an encrypted channel such as HTTPS.
    2. Application must employ the use of MFA if possible.
      1. Where not feasible, other controls must be implemented to reduce risk as required by OIT Security.
    3. User passwords must be obfuscated while entering.
    4. Login failures must not leak information regarding the user or their credentials.

For network access to 幸运快三 data, 幸运快三 requires the direct connection to OIT-managed Network:

  1. Wired networks
    1. MAC address must be registered within NMS as per APM 30.14.
    2. Authorization for specific networks defined within its NMS record.
  2. Employee wireless
    1. Users are authenticated via WPA2 Enterprise occurs via MSCHAPv2 authentication to Active Directory protected by EAP.
    2. Devices may be authenticated via OIT-managed device certificates.
    3. Authorization for specific networks from account type and status, or certificate used.
    4. Employee or department devices unable to support network requirements such as WPA2 Enterprise, may use long term guest access.
    5. Network examples include: AirVandalGold, and eduroam.
  3. Student wireless
    1. Users are authenticated via WPA2 Enterprise occurs via MSCHAPv2 authentication to Active Directory protected by EAP.
    2. Authorization for specific networks from account type and status.
    3. Student devices unable to support network requirements such as WPA2 Enterprise, may use long-term guest access.
    4. Network examples include: AirVandalGold, AirVandalHome, and eduroam.
  4. Remote access VPN
    1. User and/or device are authenticated and verified against OIT-managed identity source.
    2. Devices may be authenticated via OIT-managed device certificates.
    3. Authorization for specific networks from account type, affiliation and group membership and or certificate used.
  5. Event networks
    1. May be tailored to the event requirements.
    2. Must be granted the level of network access required only for the purpose of the event.