身份和访问管理策略

---

审核通过：2024年4月28日（由CSIS治理）

本政策取代之前的1.2.C版本“访问管理和认证要求”和“帐户维护和安全”。

概述

本策略描述了用于系统和应用程序的数字身份类型；创建、维护和取消配置身份和帐户的标准；身份应该如何认证；应如何管理授权；以及如何审计账户和访问权限。

范围

第一部分适用于所有个人帐户持有人。它定义了帐户持有人保护其帐户和正确使用其授权的责任。

第II部适用于有权访问或决定访问共享/部门帐户的任何人

第三部分适用于任何负责为任何系统或应用程序配置身份和访问管理功能的个人。

第四部分为身份和访问管理服务的运作设定标准，以确保服务的顺利运作和支持互操作性。

第五部分授予对信息安全和内部审计与咨询服务的身份访问管理控制进行审计的权限。

定义

 

账户

帐户是与信息系统交互的基础。它们使用一种或多种身份验证方法将数字标识链接到登录名，并启用对信息资源的访问权限分配（授权）。

企业账户

企业帐户允许全校访问信息资源。它们是由IS&T的身份和访问管理团队监督的既定标准流程提供、维护和解除配置的。

本地账户

当应用程序和操作系统需要本地帐户时，或者当企业帐户不能使用时，在应用程序和操作系统中创建本地帐户。

联系

从属关系是指个人与大学的联系。这些人包括教职员工、学生、校友、申请人、爱玛客员工、访问澳门威尼斯人注册网站研究员、志愿者等等。与每个角色相关联的完整从属关系列表由信息服务和技术中的身份和访问管理团队维护。

授权

授权是使用与帐户关联的信息资源的隐式或显式许可。

波士顿大学身份证号码（BUID）

一个人的主要标识符是Boston University ID （BUID）号，它是一个字母后面跟着八个数字。确定唯一性的过程在此策略的Identity部分中定义。

信息资源

包含需要管理访问的数据的任何系统、应用程序或信息存储库。这可能是一个企业应用程序，如学生信息系统或BU Works，较小的部门应用程序，包括web应用程序，端点设备，如个人的笔记本电脑和台式机，文件共享服务，如OneDrive，谷歌，或其他形式的共享存储，或协作服务，如Teams或SharePoint。

人的身份

波士顿大学ID号的权威存储库，这是与波士顿大学有关联的每个人的唯一标识符。

人注册

包含来自大学记录系统的所有角色的附加属性的存储库。此外，Person Registry是用于确认性别属性的记录系统。

角色

角色用于将关联组合在一起。我们有三个角色：学生、人力资源和会员。

学生的角色

在波士顿大学注册处积极注册并保持学术记录的个人。例子：学生、申请人、校友

人力资源的角色

波士顿大学的积极的、有报酬的雇员；这包括教职员工、退休人员、退休人员。例如：教员、职员、退休人员

附属的角色

没有从波士顿大学获得报酬，但需要访问我们的系统或有业务需要BU登录名的客人。例如：爱玛客员工、访问澳门威尼斯人注册网站研究员、志愿者、供应商

特权帐户

某些帐户可能具有与设备或应用程序管理相关的额外特权。这通常被认为是一种帐户类型，但更准确地说，它是具有特权授权的帐户。

特权访问管理（PAM）系统

特权帐户管理是指管理和审计具有超出默认帐户访问权限的帐户的机制。特权帐户管理指的是一种技术，它存储凭据，并在个人对自己进行身份验证并确认个人应该有权访问这些凭据之后提供对这些凭据的访问。最好的系统不允许个人直接访问身份验证凭据，而是代表他们执行身份验证。

记录制度

记录系统是一个企业应用程序，它具有请求创建或保留帐户的权限，作为大学范围内业务流程的一部分。这些系统还可以在个人身份或个人注册记录中维护某些元素。有四种记录系统：

• 学生信息系统（校园解决方案或主机）
• 事业部工程（SAP）
• 会员系统（会员资料库）
• 澳门威尼斯人注册网站研究计算
  • Research Computing可以为澳门威尼斯人注册网站研究人员保留现有帐户，但不能请求创建帐户或更新Person Identity或Person Registry信息。这条道路的存在是为了使离开大学的个人能够顺利过渡到澳门威尼斯人注册网站研究领域。

由于记录系统具有特殊权限，这些系统必须与IAM密切合作，开发流程，以确保提供给身份系统的数据的准确性和完整性。不准确或不完整的信息可能会影响个人访问和或导致数据泄露。

第一部分：个人的责任

每个访问波士顿大学系统的人都有责任选择强密码，保持密码安全，保护他们的多因素身份验证令牌和应用程序，并报告任何未经授权的帐户使用。个人必须:

1. 创建符合选择密码的最佳实践的密码，地址长度和复杂性。
2. 除获授权的共享/部门帐户外，不得与任何人共用任何大学帐户的密码。
3. 非大学帐户不要使用与任何大学帐户相关的密码。
4. 如果有理由认为密码已被未经授权的人不当披露、访问或使用，应立即更改密码，并通知相应的系统管理员和/或信息安全部门。
5. 通过以下方式保护多因素身份验证令牌和应用程序：不共享代码、批准与自己的身份验证尝试无关的身份验证请求、将属于其他人的设备添加到自己的帐户中，或尝试绕过多因素身份验证。
6. 与帐户关联的特权只能用于授权的目的，而不能用于其他目的。
7. 只有在需要特权来完成某个功能时才使用特权帐户和授权。
8. 避免将密码保存在脚本和配置文件中，以免被其他人读取。这并不是要禁止正确使用密码管理工具。
9. 离开无人值守的设备时，注销或使用需要身份验证的屏幕锁定技术。

第二部分：与共享/部门帐户有关的责任

系统或应用程序共享或使用的帐户凭据必须小心处理。本节适用于有权访问此类帐户或监督与此类帐户相关的授权的任何人。

1. 确保只有需要知道密码的人才能访问它。除非得到明确授权，否则不要与任何人共享密码。
2. 任何时候，当一个知道该账户的人结束与学校的关系时，请更改与该账户相关的密码。
3. 对这些帐户使用多因素身份验证，或从信息安全处获得豁免。这对于访问Restricted Use数据或对系统或应用程序具有特权访问的帐户尤其重要。
4. 取消任何已结束与大学关系的人的共享/部门帐户的多因素认证权限。
5. 在合理和可能的情况下，要求个人首先以个人身份进行身份验证，然后使用特权帐户管理等工具或sudo实用程序提供的功能切换到特权帐户。
6. 在可能的情况下，对如何使用这些帐户应用辅助控制，例如通过控制从何处使用帐户（例如，仅在校园内）或何时使用帐户（仅在工作时间）。

第三部分：应用程序及系统管理员的责任

负责对一般用途的应用程序和系统（包括云（软件即服务）应用程序）进行认证和授权控制配置的个人必须：

1. 尽可能合理地使用企业认证，而不是本地认证。
2. 限制使用部门/共享帐户访问数据。
3. 确保只将特权访问授予需要这种访问的适当帐户。理想情况下，具有特权的帐户的密码应该存储在特权访问管理系统中（见下文）。
4. 确保在适当的时间撤销本地定义的访问。a.本地管理访问时，系统或应用程序必须考虑当个人所属关系发生变化时终止访问的原因。有些人将保留访问他们的帐户基于从属关系，即使一个角色可能已经结束（如校友，退休人员）。
5. 确保创建、删除、移除或更改的任何帐户或授权都经过审核并可用于审核。该日志将包含创建、删除、删除或更改的批准证明，以及修改帐户或授权的系统和任何系统或应用程序级日志（如果可以记录的话）。
6. 确保非特权帐户不能访问特权功能，并审计特权的任何使用。
7. 确保任何对帐户进行身份验证或授权的系统或应用程序都将成功和失败的活动记录到标准位置和格式。
8. 对账户和授权活动进行例行审计，以确保只进行授权使用，并相应地维护审计文件。作为审计的一部分：a.提供一份有权访问适当管理审批人的账户清单，以供审查。b.支持和鼓励数据受托人定期审查受托人职责范围内的信息。

与这些要求的差异必须得到信息安全部门的批准。

第四部分：身份和访问管理标准

该政策的这一部分适用于为大学配置和/或维护设备和应用程序的所有大学社区成员。这部分也适用于如何配置已出售的解决方案（例如云应用程序、软件即服务）。

A.数字身份

所有与学校有关的人都应该有一个永远不会被撤销的唯一数字标识符。这个唯一标识符是波士顿大学的ID号（BUID）。将身份与其build配对的权威来源是由IS&T运行的Person identity系统。

当记录系统请求新的标识时，将评估以下标识元素，以确保每个人只接收一个标识。使用称为四点匹配的匹配例程来确定唯一性。Duplicate Identity （dup-id）流程的存在是为了解决个人被分配多个build的情况。

识别要素

收集以下数据元素以唯一地识别每个人：

• 法定名
• 法定姓氏
• 出生日期
• 个人非bu电子邮件地址
• 社会安全号码（可选）
• 护照(可选)

非人类的身份

需要支持创建与个人没有直接关联的帐户，例如共享帐户或组帐户。当这些帐户需要一个唯一标识符时，它们将获得一个以字母“G”开头的BUID号，也称为“GID”。具有GID的帐户记录在我们的遗留目录系统中。

人注册

身份服务维护一个Person Registry，其中包含有关个人的其他可选信息，包括显示姓名、代词、性别身份和性取向。

有关此信息的治理（收集和使用）的其他信息可以在/asir/data-use/data-standards/bu-governed-identity-data-diversity-inclusion/上找到。

身份服务应为个人提供和维护该信息提供机制。个人登记处是大学的这些属性记录系统。其他系统不应收集或维护此信息，而应引用Person Registry中保存的数据。

b .账户

帐户是与信息系统交互的基础。它们使用一种或多种身份验证方法将数字标识链接到登录名，并支持对信息资源分配访问权限（授权）。

企业账户

企业帐户允许全校访问信息资源。它们是由IS&T的身份和访问管理团队监督的既定标准流程提供、维护和解除配置的。

企业帐户要求

1. 个人必须与大学有批准的从属关系才能拥有企业帐户。
2. 个人与学校的从属关系必须至少每年进行一次验证。如果从属关系到期，该帐户应及时解除配置。
3. 没有活动关联的企业帐户将立即被禁用。

企业账户类型

企业帐户是根据System of Record定义的关联关系或某些帐户类型的手动请求策略进行配置和解除配置的。应该尽可能使用企业帐户来授权访问。这些帐户按表中所示的分类，并在下文作进一步定义。

帐户类型	子类型	请求过程
人账户	BU登录帐号	记录制度
	网络账号	记录制度
	角色账户	手动过程
非人类的账户	共享/部门的账户	手动过程
	学生团体帐户	手动过程
	服务帐户	手动过程

人账户

与个人关联的帐户有三种类型：BU登录帐户、Web帐户和角色帐户。它们具有以下属性：

BU登录帐号

BU登录帐户是所有与大学有持续关系的个人最常用的帐户，包括学生，澳门威尼斯人注册网站，员工和附属机构。与帐户关联的登录名是在创建帐户时分配或选择的，并用作大学的电子邮件地址，例如loginname@bu.edu。

网络账号

网络帐户用于与大学有临时关系的个人，例如申请人和家长。这些帐户通常不需要广泛的访问权限。与帐户关联的登录名是在创建帐户时根据非bu个人电子邮件分配的，例如loginname@gmail.com。

角色账户

角色帐户类似于BU登录帐户，用于为指定的个人提供对系统的特权访问，而无需将这些特权分配给他们每天使用的帐户。这些帐户包括Active Directory管理帐户，例如loginname-adm@bu.edu。角色帐户名称可以由个人帐户名称派生，长度可以超过8个字符，但其他方面遵循BU登录帐户命名规则。

非人类的账户

非人类账户有三种类型。这些帐户可以在多个个人之间共享，例如共享/部门帐户或学生组帐户，或者用于系统对系统通信，例如服务帐户。

共享/部门的账户

创建共享/部门帐户是为了支持多个个人共享相同的身份。不鼓励直接使用共享账户，因为它缺乏问责制。在许多情况下，这些帐户是接收大学部门或职能部门的电子邮件所必需的。访问这些帐户应该通过授权访问而不是密码共享来实现。这些帐户遵循BU登录帐户命名规则。

学生团体帐户

这些账户由学生活动办公室批准的正式大学学生团体使用。预计这些帐户将由该小组的多名官员共享。这些帐户遵循BU登录帐户命名规则。

服务帐户

当系统或应用程序需要对其他系统或应用程序进行身份验证而无需与任何人员关联时，使用服务帐户。这些帐户应谨慎设立，并应保留其用途的文件。除了初始测试之外，人们不能使用服务帐户进行身份验证。必须密切监视具有提升权限的服务帐户，以防滥用。这些帐户遵循BU登录帐户命名规则。

企业帐号命名规则

企业账号除Web账号外，包括人类账号和非人类账号

• 长度为2 ~ 8个字符。
• 可以包含字母和数字，但不能以数字作为首字符。
• 不能包含任何标点符号。
• 帐户名不能重复使用。

企业Web账户

• 帐户名称以个人邮箱地址为准。

本地账户

当应用程序和操作系统需要本地帐户时，或者当企业帐户不能使用时，在应用程序和操作系统中创建本地帐户。

创建本地帐户时，系统或应用程序管理员必须定义批准、创建、维护和解除配置本地帐户的过程。该程序必须与企业帐户的准则一致。必须及时执行解除配置。

具有特权的本地帐户必须小心保护，最好将其存储在特权访问管理系统中。

特权帐户

某些帐户可能具有与设备或应用程序管理相关的额外特权。这通常被认为是一种帐户类型，但更准确地说，它是具有特权授权的帐户。管理员权限只能添加给BU登录帐户、角色帐户、业务帐户或本地帐户。特权的使用应该限制在必要的范围内。这些帐户必须小心保护，最好存储在特权帐户管理系统中。

C.目录服务

大学提供了一个机制来查询社区成员的帐户信息，以促进协作。默认情况下，以下属性可用：

• 显示名称
• 电子邮件地址
• 基层（教职员工）
• 办公室信息（供教职员工使用）
• 学校或学院（学生）
• 代词(如果由个人配置，请参见人注册）

有一些选项可以限制目录中个人的显示。可用的选项取决于个人的隶属关系。个人应联系招生服务或人力资源部讨论他们的选择。

d .身份验证

身份验证是系统或应用程序确认一个人或设备确实是它所声称的人或物的过程。强认证协议有助于保护个人和大学的信息，并防止滥用信息资源。

所有企业帐户都是根据信息服务与技术提供的服务进行认证的。

认证类型

身份验证可以采取多种形式。身份验证通常分为三种类型：

• 你知道的一些东西：最常见的形式是密码、别针或图案。
• 您拥有的东西：最常见的形式是硬件令牌、证书或软件身份验证器（如Duo或谷歌authenticator）。
• 你的身份：这个类别通常被称为生物识别身份验证。最常见的形式是指纹识别器和面部识别。

多因素身份验证

多因素身份验证（MFA）涉及组合多种身份验证类型，通常对个人身份提供更强的保证。仅组合两种类型有时称为双因素身份验证（2FA）。

身份验证策略

这些策略应该应用于所有系统和应用程序。企业帐户遵守所有这些政策。

身份验证策略

1. 所有帐户在使用前必须进行身份验证。未经身份验证的访问只能用于分类为公共的数据（参见数据分类）。
2. 认证凭据应由帐户持有人在创建帐户时设置，或可使用临时密码，但登录时应立即更改临时密码。临时密码必须符合所有其他密码要求。
3. 任何应用程序或系统，无论是在本地还是在云中，都应该尽可能合理地使用企业身份验证服务，而不是本地帐户和密码。
4. 密码在任何网络上传输时都必须加密。
5. 密码存储时必须加密。

密码策略

1. 密码的最小长度为16个字符。
2. 密码必须至少5年修改一次。
3. 密码必须很复杂。密码必须包含以下四种字符中的至少三种：小写字母、大写字母、数字、特殊字符。

多因素认证策略

1. 尽可能合理地对所有应用程序和系统使用多因素身份验证。使用多因素认证进行本地认证时，可能会考虑到设备的物理安全性。
2. 对所有BU登录帐户、角色帐户、共享/部门帐户和学生组帐户使用多因素身份验证。
3. 为了防止重放攻击，基于网络的访问的多因素身份验证应该使用在短时间内过期的令牌，或者将当前时间合并到身份验证过程中。
4. 如果包含限制使用信息的应用程序或系统不能支持多因素身份验证，则必须使用补偿控制，并且该计划必须得到信息安全部门的批准。

其他建议和合规特定要求

1. 考虑一个防止个人重复使用相同密码的策略。这是根据PCI-DSS规定包含信用卡数据的系统所必需的。
2. 身份验证失败不应该向客户端提供澳门威尼斯人注册身份验证失败原因的反馈，而应该只提供它确实失败的反馈。
3. 考虑在一段时间内多次失败的身份验证尝试（例如5分钟内30次失败尝试）后锁定对帐户的访问。a.被锁定的帐户至少在30分钟内不可使用，直到系统或应用管理员解除锁定。b.根据PCI-DSS规定，包含信用卡数据的系统需要在尝试6次后锁定账户。

e .授权

授权是使用与帐户关联的资源的隐式或显式权限。一旦对帐户的使用进行了身份验证，系统或资源就可以确定请求访问的人或软件是否被授权使用该帐户。授权的管理和维护是信息服务和技术以及本地系统和应用程序管理员的共同责任。

鼓励所有进行授权的单位制订符合授权政策中下列要求的程序。

授权类型

有几种类型的授权需要考虑。

与生俱来的特权

当在大学的中央身份管理系统中创建一个帐户时，它立即创建了某些授权，例如针对我们的企业认证系统进行身份验证的能力，访问我们的网络和企业远程访问服务，以及一些在线资源。在IS&T管理的帐户创建过程中，帐户会自动地被隐式或显式地授予这些授权，这些授权与个人与大学的隶属关系有关。对于某些类型的附属公司，可以定制这些与生俱来的特权是什么。

应用程序和系统管理员不得通过以下方式规避与生俱来的权限所包含的授权，例如，鼓励共享帐户，创建代理身份验证服务以使个人能够使用其他帐户的权限发出请求，或创建旨在绕过这些控制的辅助身份验证和授权系统。

系统和应用程序级授权

在某些情况下，可能需要在应用程序或系统中显式地定义帐户。当在本地系统或应用程序中定义帐户时，可能会隐式授予某些授权，例如使用应用程序或系统的部分或全部功能的能力。

享有特权的授权

某些授权授予管理系统或应用程序和/或查看由其他人创建或维护的数据的访问权限。特权访问应该基于特定人员的工作职责，而不是该人员所在组织单位的职责。系统或应用程序应该记录特权的使用。

授权原则

最小特权

授权应该只提供要执行的功能所需的特权，而不是其他特权。遵循这一原则有助于确保遵循适当的工作流程，并限制对数据的访问。

职责分离

当授予帐户非出生权授权时，必须经过多个个人的批准。多审批者确保从技术和流程的角度都遵循最小特权原则，减少利益冲突或欺诈的机会，并降低出错的风险。当应用于授权时，职责分离要求管理审批人和技术审批人不是同一个人，或者如果必须是，则数据管理员不担任任何一个角色。

授权中的角色

授权帐户使用系统或应用程序是由信息服务与技术、我们的IT合作伙伴以及有时可能根据我们的指示创建授权的外部合作伙伴共同承担的分布式责任。

数据管理者

一般来说，这些授权是由“数据保管人”实施的，他们被委托维护数据。这些管理员通常是系统管理员、数据库管理员或应用程序管理员。有关此角色的详细信息，请参见数据访问管理策略。这些个人负责在确认已授予适当的批准后执行已批准的授权更改。

数据受托人和数据管理员

数据受托人是负责确保大学数据被适当使用的领导者。它们的角色在数据访问管理策略中定义。在授权范围内，它们在批准对数据类型的访问方面发挥作用。数据受托人可以指定额外的个人，称为数据管理员，代表他们进行批准。

行政和技术审批人

所有非出生权授权的请求必须得到行政和技术审批人的批准。这些审批人必须是两个不同的人，以确保职责分离。这些审批者负责确保从他们各自的角度应用最小特权原则。

行政审批：行政审批确认所请求的授权需要执行所需的功能。审批者在做出决定之前应该充分了解要授予的授权的全部范围，并确保应用了最小特权。

技术审批：技术审批确认所请求的权限是实现已批准的管理需求所必需的。审批者在做出决定之前应该充分了解要授予的授权的全部范围，并确保应用了最小特权。

应用程序和系统授权

授权访问可以根据个人在特定组中的成员身份或手动过程自动进行。当授权某人使用应用程序或系统时，数据管理员必须遵循以下授权策略。

授权策略

资料保管人在准许访问系统或应用程序前，必须确保遵守以下政策：

1. 在实际情况下使用基于角色的授权方案，而不是单独的授权。
2. 在授权中要尽可能地细化。
3. 确保授权获得适当的批准：a.始终需要行政和技术批准。这些批准人必须：

• • 确保“最小特权”和“职责分离”原则得到应用。
  • 在批准对共享帐户的权限时，要考虑对该帐户具有访问权限的每个人，以及该权限是否适合每个人。

b.所有访问有数据受托人的数据的请求必须得到数据受托人或其数据管家的批准。有关详细信息，请参阅数据访问管理策略。

4. 只有当该特定人员的工作职责经常需要该级别的访问权限时，才能永久授予特权访问权限，否则，访问权限必须是临时的。
5. 所有授权请求必须记录，包括请求的性质、批准的期限、获得的所有相关批准以及审批人的姓名。

Pre-authorized请求

酌情，数据受托人或数据管家可以预先批准始终需要此类授权的角色的授权。有关详细信息，请参阅数据访问管理策略。

可以考虑对特权帐户授权进行预授权，但通常不鼓励这样做。注意：依赖集中帐户解除配置作为终止本地部署授权的方法是不够的，因为帐户解除配置的及时性取决于本地系统和应用程序管理员无法控制的几个因素。

第五部分：审核

信息安全和/或内部审计和咨询服务部门可以对任何大学信息系统的账户和授权进行常规或特别的审计，并提供相关的审计跟踪。这些审核将确保账目和授权与本文件一致，包括：

1. 每个具有提升权限的帐户、共享帐户或服务/进程帐户都有一个请求；
2. 请求得到所有适用方的批准；
3. 请求符合适用的法规、政策和最佳实践；
4. 批准的行政用途需要获得授予的特权；
5. 临时特权的请求在约定的到期日被撤销；
6. 每一个活跃账户都是由一个在该机构有积极联系的人持有的；和
7. 帐户持有人的工作功能仍然需要授予的特权。

异常

信息安全部门被授权对本文件中规定的要求给予例外。批准的任何例外情况都需要对情况进行彻底审查并实施适当的补偿控制。

此外，信息安全可以发布旨在澄清标准意图的指令，以帮助解释本政策。

重要的

不遵守数据保护标准可能会对个人、组织或波士顿大学造成伤害。未经授权或不可接受地使用大学数据，包括未能遵守这些标准，构成违反大学政策，并可能使个人撤销使用大学数据或信息技术的特权或纪律处分，直至并包括终止雇用。

附录A: NIST网络安全框架和SP 800.171映射

下表将美国国家科学技术澳门威尼斯人注册网站研究院（NIST, NIST .gov）网络安全框架（CSF）和特别出版物（SP） 800.171控制与本文档中表达的策略进行了映射。充分执行这一政策，并有相关程序和遵守这些程序的证据，可能表明这里列出的所有控制措施都得到满足。但是，必须始终根据所讨论的信息系统的范围评估遵从性，并且仅具有策略本身并不能保证遵从性。

脑脊液 控制	800.171控制	控制	本保单何处
PR.AC-1		对授权的设备、用户和流程发布、管理、验证、撤销和审核身份和凭据	第三部分：应用程序及系统管理员的责任 第四部分，A部分，数字身份 第四部分，B节，账户 第四部分，E节，授权
PR.AC-1	3.5.1	识别系统用户、代表用户的进程和设备。	第四部分，D节，认证策略
PR.AC-1	3.5.2	验证（或验证）用户、流程或设备的身份，作为允许访问组织系统的先决条件。	第四部分，D节，认证策略
PR.AC-1	3.5.5	防止标识符在指定的时间段内重复使用。	第四部分，B部分，企业帐户的帐户命名规则
PR.AC-1	3.5.6	在定义的不活动期间后禁用标识符。	对于企业帐户，波士顿大学根据隶属关系禁用帐户，而不是使用情况。
PR.AC-1	3.5.7	在创建新密码时，强制执行最小密码复杂度和字符更改。	第四部分，D节，密码策略
PR.AC-1	3.5.8	禁止在指定的代数内重复使用密码。	第四部分，D节，认证策略
PR.AC-1	3.5.9	允许对系统登录使用临时密码，并立即更改为永久密码。	第四部分，D节，认证策略
PR.AC-1	3.5.10	仅存储和传输受加密保护的密码。	第四部分，D节，认证策略
PR.AC-1	3.5.11	认证信息反馈模糊	第四部分，D节，认证策略
PR.AC-3		远程访问被管理	第四部分，E节，与生俱来的特权
PR.AC-3	3.1.1	限制对授权用户、代表授权用户的进程和设备（包括其他系统）的系统访问。	第四部分，D节，认证策略
PR.AC-3	3.1.2	限制系统对授权用户可以执行的事务和功能类型的访问。	第四部分E节授权原则
PR.AC-4		通过结合最小特权和职责分离原则，对访问权限和授权进行管理	第四部分E节授权原则
PR.AC-4	3.1.4	将个人的职责分开，以减少恶意活动的风险，而不是相互勾结。	第四部分E节授权原则
PR.AC-4	3.1.5	采用最小权限原则，包括特定的安全功能和特权帐户。	第四部分E节授权原则
PR.AC-4	3.1.6	在访问非安全功能时使用非特权帐户或角色	第一部分，个人的责任 第四部分，E节，授权类型
PR.AC-4	3.1.7	防止非特权用户执行特权功能，并在审计日志中记录这些功能的执行情况。	第三部分：应用程序及系统管理员的责任 第四部分，E节，授权类型
PR.AC-4	3.1.8中	限制不成功的登录尝试。	第四部分，D节，认证策略
PR.AC-4	3.1.10	使用会话锁和模式隐藏显示来防止在一段时间不活动后访问和查看数据	看到最低保安标准．
PR.AC-4	3.1.11	在满足定义的条件后（自动）终止用户会话。	看到最低保安标准．
PR.AC-4	3.5.3	对特权帐户的本地和网络访问以及对非特权帐户的网络访问使用多因素身份验证。[24][25]。	第四部分，D节，认证策略
PR.AC-4	3.5.4	对特权帐户和非特权帐户的网络访问采用防重放身份验证机制。	第四部分，D节，认证策略
PR.AC-4	3.13.3	将用户功能与系统管理功能分开。	第三部分：应用程序及系统管理员的责任 第四部分，E节，授权类型
PR.AC-4	3.13.4	防止未经授权和无意的信息通过共享系统资源传输。	第四部分，D节，认证策略
PR.AC-6		身份被证明并绑定到凭证，并在交互中断言	第四部分，D节，认证策略
PR.AC-7		用户、设备和其他资产的身份验证（例如，单因素、多因素）与交易风险（例如，个人安全和隐私风险以及其他组织风险）相匹配。	第四部分，D节，认证策略
PR.DS-5	3.1.4	将个人的职责分开，以减少恶意活动的风险，而不是相互勾结。	第四部分E节授权原则
PR.DS-5	3.9.2	确保包含CUI的组织系统在人员澳门威尼斯人注册行动期间和之后受到保护，例如解雇和调动	第四部分，B部分，企业账户
PR.IP-11	3.9.2	确保包含CUI的组织系统在人员澳门威尼斯人注册行动期间和之后受到保护，例如解雇和调动	第四部分，B部分，企业账户

---