OCI IAM 是一项原生 OCI 服务,可为企业级应用提供企业级身份和访问管理功能,如强大的自适应身份验证、用户生命周期管理 (LCM) 和单点登录 (SSO)。OCI IAM 以身份域的形式部署在 OCI 中。企业可通过这些域管理对 Oracle Cloud 服务(网络、计算、存储等)和 Oracle SaaS 应用的访问。客户也可以选择升级或创建额外的身份域来应对其他使用场景,如管理员工对非 Oracle 应用的访问,支持消费者访问面向客户的应用,或将 IAM 嵌入到定制开发应用中。
每个 OCI IAM 身份域都是一个独立的身份与访问管理解决方案,可用于应对多种 IAM 使用场景。例如,您可以使用 OCI IAM 身份域来管理员工对各种云端和本地部署应用的访问,启用安全身份验证、轻松管理权限以及为最终用户提供无缝 SSO。您还可以建立一个身份域,以支持业务合作伙伴访问供应链或订购系统,或使用身份域为面向消费者的应用启用 IAM,让消费者用户完成自行注册、使用社交登录和/或签署使用条款同意书。身份域是一种全面的身份即服务 (IDaaS) 解决方案,适用于多种 IAM 使用场景。
否。出于许可目的,OCI IAM 将它们分别视为单独的用户群体。但您可以在同一 OCI IAM 服务中部署两个及两个以上的域来应对员工和非员工(合作伙伴、附属公司、消费者等)使用场景。您可以使用多个域来访问相同的应用,但非员工使用场景与员工使用场景的规则和安全策略通常有所差异。每个域都有自己的一组设置、配置和安全策略,这些设置、配置和安全策略对于该用户群体都是唯一的。这种设计可满足不同用户群的各种不同需求。
每个 OCI 租户中都有一个管理员组,该组可对所有 OCI 资源授予完全访问权限。您必须了解,OCI 管理员组的所有成员均具备完全访问权限,负责管理 OCI IAM 身份域。因此,Oracle 建议您谨慎使用管理员组。管理员角色可以在每个域内授予管理权限,从而在各组之间实现职责分离。有关更多详细信息,请参阅了解管理员角色。
每个 OCI 区域中都有多个可用性域 (AD) 或故障域 (FD)(在 AD 域中)。AD 和 FD 的功能相似,但 FD 的物理距离要比 AD 更加接近。为了提高可用性,身份域在每个区域 (AD/FD) 中部署了冗余安装。OCI IAM 身份域还通过利用高性能数据复制的主动-被动方法提供跨区域灾难恢复 (DR)。若出现整个 OCI 区域不可用的极端情况,这可以为身份域提供可靠的数据恢复。DR 通过单一 URL 提供,对应用保持透明。
IAM 的关键概念包括:
OCI IAM 支持您利用统一模型,对所有 Oracle Cloud 和 Cloud Application 服务进行身份验证和授权。从单人处理单一项目到多个小组同时处理多个项目的大型企业,无论企业规模大小,您都可以通过一个账户,以简化方式进行访问管理,在账户层面或隔间层面进行资源管理和授权,同时实施集中式审计和计费。全新构建的 OCI IAM 支持您实施最小特权安全原则,即默认禁止新用户对任何资源执行任何操作,由管理员按需要为每位用户仅授予相应的访问权限。
除了管理 OCI 资源,OCI IAM 还可为用户提供现成的企业级 IDaaS 解决方案。只需点击按钮,您即可部署强大的 IAM 解决方案,满足员工/劳动力、合作伙伴或消费者使用场景中的许多 IAM 要求。
OCI IAM 广泛支持多因素身份验证 (MFA),包括提供推送或一次性验证码选项的移动 MFA 应用,支持 FIDO2 验证器、SMS、电子邮件和电话等。OCI IAM 还提供情境感知自适应安全性,在降低风险的同时确保最终用户体验。自适应安全功能可评估用户的设备、网络、位置和历史行为,为用户会话创建风险评分。管理员可为特定应用或用户组配置不同的 MFA 策略。
可以,为满足企业审计和合规性要求,Oracle IAM 将记录所有变更,而且您无需额外付费即可访问这些记录。
OCI IAM 默认启用,无需额外付费,账户下的第一位用户即为默认管理员。您可以通过 IAM 服务创建所有后续用户,并明确授予他们与指定云技术资源进行交互的权限。
您可以通过控制台、Rest API 或 SDK 访问 Oracle IAM。
重置 Oracle Cloud Infrastructure 访问密码前,请首先将您的账户关联至一个电子邮件地址。请访问您 Oracle Cloud Infrastructure 账户的用户资料页面,添加只有您拥有访问权限的电子邮件地址。然后,您将收到一封电子邮件,请您确认将该地址关联到您的账户。随后,您就可以使用该电子邮件账户重置密码 — 除非账户已被租户管理员禁用。
隔间是账户下用于托管基础设施资源(例如计算、存储和网络)以及针对基础设施资源的一组访问管理策略的安全逻辑容器,支持您逻辑有序地组织云技术资源,以为各种用例提供支持。
以下是隔间的一些常见用法:
可以,隔间是一种与可用性域在物理结构上完全不同的资源逻辑分组,一个隔间可以托管多个可用性域中的资源。
所有策略都会关联到根隔间或一个子隔间,而每个策略都包含符合一个或多个符合以下基本语法的策略声明:
Allow group to in compartment
您可以利用策略声明,使用隔间来简化权限管理,例如写入一个策略声明,允许 HRAdministrators 组管理 HRCompartment 隔间中的所有资源。
是,您可以按需要删除隔间。
是,您可以将整个隔间树及其包含的资源移至其他父隔间。
是,您可以在不同隔间之间移动资源。
是,您可以通过嵌套来创建隔间层级结构。利用层级或嵌套隔间,系统管理员可以组织资源,允许低层级的管理员进行同样的操作,同时获得全面的可见性和策略控制力。
隔间最多可嵌套 6 层。
是,子隔间将继承更高层级隔间的策略。
是,您可以在 My Services 中按隔间来跟踪成本和用量。
对于每个账户,Oracle Cloud Infrastructure 将自动创建一个最高层级的隔间,即根隔间。与文件系统中的根文件夹非常类似,根隔间的工作方式与子隔间完全相同,但又具有一定的特殊性:
注意:目前,您只能在根隔间中创建新隔间,而不能在其他隔间中创建。
通常情况下,请在根隔间以外的其他隔间中创建资源。按照优秀实践,请在创建隔间和资源前首先设计隔间层级结构。
通过 OCI IAM 身份验证后,用户可获得足够的权限来使用或管理您账户中的资源。管理员可以在账户下创建一个或多个用户,然后将用户分配特定到组中,以便为他们授予访问特定隔间中资源的权限。
您的账户供应有一个用户(即默认管理员),和一个组(Administrators 组),默认管理员用户是该组成员。Administrators 组拥有完全访问权限,默认管理员则可以按需创建新用户,或通过为其他用户授予权限来创建新用户。
默认情况下,新用户在被明确授予权限前,无权使用您账户下的任何资源或服务。这让您能够遵循最小特权安全原则,即仅向每个用户授予该用户所需的访问权限。您必须明确将用户添加到一个现有组中,或为用户创建一个新组,然后通过策略为该组分配适当的权限。
管理员可以停用或锁定用户以临时禁用其访问权限,也可以重置用户密码或删除密钥。
是的。您可以使用密码策略为密码设置到期时间,还可以通过 REST API 和 SDK 自动重置密码、更改秘钥或编辑用户和组成员。
策略是一种由描述性策略声明组成的文档。其中,描述性策略声明采用易于理解的类似 SQL 的语法编写,可向用户组授予特定权限。使用策略,您可以为各类用户赋予相应权限(示例):
策略允许组以特定方式使用特定隔间中特定类型的资源,可以包含条件子句 ("where ..."),进一步对策略声明加以限制。如需添加条件语句,请遵循以下语法:
Allow group to in compartment [where]
例如,以下策略声明将为用户/用户组授予计算实例使用权限:
Allow group Developers to use instances in compartment ProjectA
有关更多信息,请参阅 Oracle Cloud Infrastructure 文档 OCI IAM 部分。
可以,根隔间的策略将自动为其下所有子隔间授予相同的权限。例如,以下策略将为“InstanceAdmins”组中的所有用户授予根隔间及其下所有子隔间中的实例的管理权限:
Allow Group InstanceAdmins to manage instances in tenancy
可以,每个策略均与一个隔间“关联”,控制那些用户可以进行修改或删除操作。如果一个策略关联至根隔间,则任何有权管理根隔间策略的用户都可以更改或删除该策略,如果关联至其他隔间,则任何有权管理该隔间策略的用户都可以更改或删除该策略。在实际应用中,这意味着可以轻松为隔间管理员(即有权管理隔间中的所有资源的组)授予管理其隔间策略的权限,有效避免了过度授权。
有关策略和策略声明的更多信息,请参阅 Oracle Cloud Infrastructure 文档“策略快速入门”和“常用策略”部分。
本常见问题解答指导用户使用 Oracle Cloud Infrastructure (OCI) Identity and Access Management 拒绝策略,该策略允许具备策略管理权限的用户明确阻止操作,从而增强 OCI租户的安全性并简化访问控制。有关更多详细信息,请参阅 OCI Identity and Access Management 文档。
IAM Deny 是一项选择加入功能,必须由租户管理员通过 OCI 控制台依次进入策略、操作和策略设置明确启用该功能。普通用户或策略作者无法启用。启用后,该功能将成为租户 IAM 框架的永久组成部分,无法通过 UI 禁用。但是,具备编写拒绝策略权限的租户管理员可通过编写根级拒绝策略来有效管控拒绝策略的使用,该根级拒绝策略可阻止除默认管理员组外的所有用户创建或修改拒绝策略。示例:拒绝任何用户管理租户中的策略,其中 target.policy.type='DENY'。
启用 IAM Deny 后
借助 OCI Identity and Access Management 拒绝语句,您可以编写显式拒绝策略来阻止 OCI 租户中的特定操作,配合 OCI Identity and Access Management 允许语句进行精确访问控制。例如,您可以使用“拒绝任何用户检查租户中的所有资源,其中 request.service='streaming'”来设置防护栏,阻止全租户对 OCI Streaming 服务的访问,同时通过允许语句获得其他权限。
IAM 拒绝策略与允许策略具有相同的限制。一个租户最多可拥有 100 个 IAM 策略对象,每个对象最多包含 50 条策略语句(拒绝或允许),但租户内所有对象的策略语句总数上限为 100 条。
IAM 拒绝策略使用现有元动词:管理、使用、读取和检查。未引入新的元动词。与累加授予权限的允许语句(例如“管理”包含所有低级权限)不同,拒绝语句采用减法机制,仅阻止指定权限及层级中所有更高权限。
例如,策略“拒绝‘DevOps’组管理隔间 Prod 中的实例”仅阻止管理权限,允许 DevOps 执行使用、读取和检查操作。但是,拒绝检查权限会阻止所有权限,因其属于基础层级权限。
拒绝策略与允许策略在同一 OCI Console 界面创建。导航到身份和安全,然后导航到策略,选择隔间后使用策略编辑器在允许权限旁添加拒绝关键词。该过程不需要单独的界面。
否,拒绝策略使用与允许策略相同的策略对象。两者均在同一策略对象内进行管理,从而简化运维。
是,您可在单个策略对象中组合拒绝和允许语句以实现灵活访问控制。
例如,单个策略可包含如下允许与拒绝语句:
拒绝“实习生”组使用隔间“财务”中的实例
允许“管理员”组管理隔间“财务”中的所有资源
利用这些策略,管理员可以管理隔间“财务”中的所有资源,同时防止实习生对实例执行任何写入操作,实现访问控制的精简化。
要防止具有策略管理权限的用户编写拒绝策略,请在根级别创建拒绝策略以阻止拒绝策略的创建。
示例:拒绝“PolicyAdmins”组管理租户中的策略,其他 target.policy.type='DENY'
此策略可确保 PolicyAdmins 无法创建或修改拒绝策略,同时仍允许他们管理允许策略。默认管理员组仍不受该策略约束,必要时可编写拒绝策略。
要阻止整个 OCI 服务,请在根隔间中创建拒绝策略,以使用 request.service.name 等条件针对服务的资源或操作。
例如,要全租户禁止访问 OCI Streaming 服务
拒绝任何用户检查租户中的所有资源,其中 request.service.name='streaming'
此策略可阻止对 OCI Streaming 服务的所有访问,适用于医疗等行业的合规性需求。将策略放置在根隔间可确保策略覆盖所有隔间,从而减少策略蔓延。
要阻止某个组管理特定区域中的资源,请将拒绝策略与 request.region condition 一起使用。
例如,如要阻止某个组在特定区域执行超出只读访问权限的任何操作,则可以编写如下拒绝策略:
拒绝 RegionalAdmins 组使用租户中的所有资源,其中 request.region='sa-saopaulo-1'
此策略阻止 RegionalAdmins 组使用圣保罗区域中的资源,但允许使用、读取和检查权限。该策略特别适用于金融机构应对区域数据驻留法规的合规要求。
要拒绝某个组访问特定隔间中的计算实例,请使用
拒绝 DevTeam 组检查隔间 ProjectX 中的实例
此策略将阻止对 ProjectX 隔间中计算实例的所有权限(检查、读取、使用和管理)。例如,科技公司可通过此策略阻止 DevTeam 访问生产实例,实现开发与生产环境隔离以增强安全性。
要拒绝某个组管理特定隔间中的对象存储资源,请使用
拒绝 StorageUsers 组检查隔间 DataLake 中的对象系列
此策略将阻止对 DataLake 隔间中对象存储资源的所有权限(检查、读取、使用和管理)。例如,医疗机构可应用此策略防止 StorageUsers 访问敏感患者数据,从而确保遵守隐私法规。
要安全地将任务委派给子隔间策略管理用户,可通过以下方式实现
例如,要允许子隔间策略管理用户管理隔间的计算资源,同时限制网络变更和拒绝策略创建,可采用以下策略:
拒绝 ProjectAdmins 组管理隔间 ProjectX 中的网络系列ProjectAdmins 组管理隔间 ProjectX 中的策略,其中 target.policy.type='DENY'
允许 ProjectAdmins 组管理隔间 ProjectX 中的实例系列
这些策略使 ProjectAdmins 能够管理 ProjectX 中的实例,阻止其修改网络,并禁止其编写拒绝策略,从而实现安全委托管理。金融机构可采用此方法,允许子管理员管理计算资源,同时对网络配置和策略管理保持严格控制。
是。OCI Identiy and Access Management 采用拒绝优先评估模型,在隔间层级中拒绝策略优先于允许策略进行评估。若请求与拒绝策略匹配,则无论允许策略如何,都会阻止访问。默认管理员组不受拒绝策略约束,以防止锁定。
例如,Prod 隔间可能存在以下策略:
拒绝 Devs 组管理隔间 Prod 中的实例系列
允许 Devs 组管理隔间 Prod 中的所有资源
拒绝策略阻止 Devs 组管理实例,但默认管理员仍可管理实例。
默认管理员组不受拒绝策略的约束,因此其成员可以登录、查看和编辑策略以解除锁定。此机制可有效防止全租户中断。
示例:如果应用“拒绝任何用户检查租户中的所有资源”策略,则默认管理员组用户仍可登录并访问策略编辑器进行删除或调整。
全租户拒绝策略(例如拒绝任何用户检查租户中的所有资源)可能会阻止所有用户访问,从而导致中断。恢复步骤:
1. 以默认管理员组的成员身份登录(不受拒绝策略约束)。
2。在 OCI 控制台中,依次转至身份和安全和策略。
3。在根隔间中找到有问题的策略。
4。编辑或删除策略(例如将“拒绝任何用户检查租户中的所有资源”修改为“拒绝‘实习生’组检查租户中的所有资源”)。
5。或者,使用以下 OCI 命令行界面:OCI iam 策略更新 --policy-id '["拒绝实习生组检查租户中的所有资源"]
例如,若子隔间中具备策略管理权限的用户误将“拒绝任何用户检查租户中的所有资源”策略应用,默认管理员组用户可登录修改为仅针对“访客组”,从而避免后续锁定。为规避此类问题,请彻底测试策略并限制拒绝策略的创建权限。
拒绝管理权限仅会阻止管理操作,使用、读取和检查权限保持有效。
示例:拒绝“DevOps”组管理生产隔间中的实例,可阻止 DevOps 管理实例,但允许其使用、读取或检查实例。
拒绝使用权限将同时阻止使用和管理权限,但仍允许读取和检查。
示例:拒绝“测试人员”组在隔间 QA 中使用存储桶,会阻止测试人员使用或管理存储桶,但会允许读取或检查存储桶。
拒绝读取权限将同时阻止读取、使用和管理权限,但仍会允许检查。
示例:拒绝“审计员”组读取“日志记录”隔间中的日志,会阻止审计员读取、使用或管理日志,但仍会允许进行检查。
拒绝检查权限会阻止所有权限(检查、读取、使用和管理),因为检查是基本级别的权限。
示例:拒绝“查看者”组检查隔间“公共”中的实例,会完全阻止查看者访问实例。
查看 OCI 审计日志以跟踪被拒绝策略所阻止的操作。若策略(如“拒绝任何用户在租户内检查 cloud-shell”)引发问题,可优化为“拒绝实习生组在租户内检查 cloud-shell”。为策略变更设置警报以主动应对。
示例:监控日志以调整“拒绝‘驾驶员’组在隔间‘车队’管理实例系列”策略(若其阻碍合法任务执行)。
OCI 的“拒绝优先”模型使拒绝策略优先于允许策略,若策略范围过广可能导致服务中断。常见误区包括:应用租户级或隔间级锁定策略,或使用过于宽泛的标签条件。
例如“拒绝任何用户检查租户中的所有资源”的策略可能阻断所有访问,导致全租户锁定。建议采用具有针对性的策略,例如:
Deny group Interns to inspect all-resources in compartment Public
此策略仅限制实习生组访问权限,避免意外中断科技公司可通过此方法限制访客访问,同时保障其他用户功能正常。为防止出现问题,请在沙盒环境中测试策略,保持策略简洁,并限制拒绝策略的创建权限。
是。拒绝语句支持跨租户场景。单个拒绝授权或拒绝接纳语句可阻止跨租户请求,与需同时满足的授权/接纳配对要求不同。
以下是源租户示例:
授权 Devs 组使用租户 PartnerTenancy 中的对象系列拒绝 Devs 组管理租户 PartnerTenancy 中的对象系列
这允许 Devs 使用 PartnerTenancy 中的对象存储,但会阻止管理操作。合作伙伴组织可借此实现数据共享的同时保持资源控制权。
OCI Zero Trust Packet Routing 在开放系统互连模型的第 4 层(网络级别)运行,而 IAM 拒绝策略在第 7 层(应用级别)执行访问。即使 OCI Zero Trust Packet Routing 允许通信,IAM 拒绝策略仍可以阻止操作。
例如:
dynamic-group FrontEnd 连接到 VCN vcn:server 中的 backend:server-instance,从而允许网络流量。FrontEnd 管理隔间 ProjectA 中的实例系列,即使 OCI Zero Trust Packet Routing 允许,仍会阻止实例管理操作。OCI Zero Trust Packet Routing 和 IAM 策略将按顺序评估,IAM 将最终把关。
标准系统策略始终覆盖用户定义的拒绝策略,以确保关键服务正常运行(例如,允许任何用户读取租户中的域,其中 target.domain.id='request.domain.id')。
示例:拒绝策略(如拒绝“用户”组读取租户中的域)不会阻止允许域访问的标准系统策略。
OCI Identity and Access Management 采用“拒绝优先”评估模型,在隔间层级中拒绝策略优先于允许策略进行评估。若请求与拒绝策略匹配,则无论允许策略如何,都会阻止访问。系统定义的策略可覆盖用户定义的拒绝策略(参见问题 27)。默认管理员组不受拒绝策略约束,因此可在锁定期间管理策略。
示例:如果“拒绝‘用户’组管理隔间 Prod 中的实例系列”与“允许‘用户’组管理隔间 Prod 中的所有资源”同时存在,则拒绝策略将阻止实例管理。
在当前版本中,IAM Deny 策略不会覆盖 Oracle Identity Cloud Service 管理角色(例如,身份域管理员、安全管理员和用户管理员)。这是一种限制。在下一版本中,IAM Deny 将优先于 Oracle Identity Cloud Service 管理角色,以实现一致的访问控制。
OCI Private Service Access 允许通过专用网络路径(而非公共互联网)访问 Oracle 服务。OCI Private Service Access 专为希望在工作负载与 Oracle 服务之间建立专用连接的客户而设计,以满足合规性、性能或安全性要求。
如果您要使用 OCI Private Service Access 安全访问服务(例如 OCI Object Storage 或 OCI Streaming),则可能需要强制所有访问都必须通过 OCI Private Service Access 进行。使用 IAM Deny,即使存在允许策略,您也可以明确阻止所有非 OCI Private Service Access 流量访问某项服务。
例如,要仅允许通过 OCI Private Service Access 访问 OCI Object Storage,请使用
拒绝任何用户访问租户中的对象系列,其中任何 {not request.gateway.id, request.gateway.type !='privateserviceaccess'}
此策略可防止用户通过非 OCI Private Service Access 端点访问 OCI Object Storage。这对已为敏感数据配置 OCI Private Service Access 的场景尤为有效,可消除通过非预期公共路径进行访问的风险。
OCI 通过 IAM 拒绝策略和 Oracle Security Zones 来防止不安全操作,从而保障租户安全。两者均能增强安全性,但工作机制和灵活性存在差异。
environment:production),则可以阻止特定用户组删除关键资源。如需进一步帮助,请访问 OCI Identity and Access Management 文档或与 OCI 客户团队联系。
组是多个需要类似的访问权限以使用或管理您账户下特定资源的用户的集合。其中,一个用户可以同时隶属于多个组,并获得累加权限。例如,如果一个用户同时隶属于两个组,在第一个组中有权使用计算实例,在第二组中有权管理块存储卷,则该用户同时拥有实例和块存储卷管理权限。
管理员可以写入策略,为组(而不是单个用户)赋予对特定隔间或账户的必要访问权限,然后按需将用户添加到适当的组中。
可以,在供应时,您的账户拥有一个默认管理员,隶属于根隔间中的 Administrators 组。Administrators 组不仅拥有创建和管理您账户下所有 Oracle Cloud Infrastructure 资源(包括用户、组、策略和隔间,以及任意隔间中的所有其他基础设施资源)的所有权限,还支持您添加其他用户。
您可以使用密码策略为密码设置到期时间。默认密码策略的密码到期时间为 120 天。该选项是可配置的,您可对用户子集应用不同的策略。
使用动态资源组为组分配一组计算资源,然后利用策略分配该组权限。这可以让计算实例安全访问其他 OCI 资源,而无需将凭证嵌入到脚本中。
身份联合是一种用于 Oracle Cloud Infrastructure 的租用的,将用户管理委派给其他身份提供程序 (IdP) 的机制,它支持企业使用其现有的身份系统,而不必另外创建和维护一组新用户。您只需在 Oracle Cloud Infrastructure 和身份提供程序之间进行一次配置(即联合信任),即可启用身份联合。
联合用户(外部身份)指在 Oracle Cloud Infrastructure 外部(例如在您企业目录中)管理,但获得了您 Oracle Cloud Infrastructure 账户访问权限的用户,与您在 Oracle Cloud Infrastructure 账户中创建和维护的 Oracle Cloud Infrastructure 用户不同。
可以,联合用户可以访问 Oracle Cloud Infrastructure 控制台。
可以,联合用户可以访问 Oracle Cloud Infrastructure SDK 和 CLI。
联合用户无法在 Oracle Cloud Infrastructure 控制台中更改或重置密码。
您可以使用与管理本地用户相同的 Oracle Cloud Infrastructure 策略来管理联合用户,将身份提供程序中的角色和组映射至 Oracle Cloud Infrastructure 中的组。与本机用户一样,联合用户登录后,Oracle Cloud Infrastructure 控制台即根据其拥有的 Oracle Cloud Infrastructure 组成员身份来应用策略。更多信息,请参阅文档示例。
身份提供程序中的一个角色或组可以映射至多个 Oracle Cloud Infrastructure 组,多个角色或组也可以映射至一个 Oracle Cloud Infrastructure 组。
您可以为任意数量的联合用户授予控制台访问权限。
OCI IAM 支持任何符合 SAML 2.0、Open ID Connect 或 OAuth 标准的身份提供程序,包括 Oracle Access Manager、Microsoft Active Directory Federation Services (AD FS) 和 Okta 等主流解决方案。
过去,人们使用简单的用户名和密码来保护账户,但密码可能很难记住,而且相对容易遭受常见的网络攻击技术(如网络嗅探、网络钓鱼和暴力破解攻击)的攻击。如果有人窃取您的凭据,他们就可以冒充您并访问您的所有账户和资源。
多因素身份验证 (MFA) 是一项常用的安全功能,通过加强对应用程序用户身份的保护来帮助降低账户被盗的风险。MFA 要求用户提供多个验证因素。身份验证因素分为三类:您知道的(例如密码或 PIN)、您拥有的(例如安全令牌或手机)以及您当前的情况(例如指纹或面部扫描等生物识别数据)。启用 MFA 后,即使攻击者设法获得了您的密码,如果不提供 MFA 要求的其他证据,他们也无法以您的身份进行身份验证。这有助于防止未经授权的访问,并防止敏感信息被泄露或遭受不当操作。启用 MFA 还有助于满足监管合规要求并遵守行业标准,如美国国家标准与技术研究院 (NIST) 的标准。
Oracle 建议为所有用户启用 MFA。您至少应该为具有管理权限(例如能够创建和管理 OCI 资源)的用户启用 MFA。您还应该要求启用 MFA 才能访问托管敏感信息或允许任何含高风险操作的应用。
当管理员首次启用 MFA 时,系统将提示用户在下次登录时注册 MFA。首次注册后,用户将在随后每次访问的登录时收到 MFA 要求。如果管理员启用了可信设备,则用户可以选择“信任此设备”;如果用户再次使用同一设备,则不再需要 MFA。
如需了解更多信息,用户可以参考以下指南:
不是,MFA 并非在所有情况下都是严格强制执行的。例如,如果您授予对公共网站的访问权限,则通常不需要任何验证。如果您希望用户在购买时登录,以便您了解要向哪个账户收费以及将产品交付到哪里,那么也许用户名和密码就足够了。但是,如果同一用户要更改付款方式或交付地址,或者如果应用程序允许可能影响企业的操作,则建议使用 MFA。
Oracle 强烈建议您为所有云技术和应用管理员启用 MFA。最终,您应该根据企业的内部安全策略和风险评估来评估是否强制实施 MFA。但最好的做法是首先强制执行 MFA,并要求对任何希望将 MFA 设为可选的应用进行行政审批。
要充分了解可用因素和费用,首先必须了解您的 OCI 租户类型。要确定您的租户是否具有带或不带身份域的 OCI Identity and Access Management (IAM),请查看此文档。
实施 MFA 的具体说明因您拥有的 OCI 租户类型而异。要确定您的租户是否具有带或不带身份域的 OCI IAM,请查看此文档。
如果您不实施 MFA,则目标账户被盗的风险会增加。反之,如果实施了 MFA,您的租户和/或其他身份验证流程将继续正常运行。
注:为免疑义,本网页所用以下术语专指以下含义: