组织资源和分配访问权的最佳实践

设置IBM Cloud®账户后，就可以开始规划如何组织资源可配置或预留的物理或逻辑实例。资源的例子包括存储、处理器、内存、数据库、集群和虚拟机。并为账户中的身份分配访问权限了。这些最佳实践为您提供了在IBM Cloud 中成功、安全地开发应用程序的基本构件。

以下最佳实践关注为 IBM Cloud Identity and Access Management (IAM) 启用并分配给资源组的资源。经典基础架构服务未启用 IAM-enabled，这意味着无法将其分配给资源组。

优秀资源组策略的要素是什么？

使用资源组来组织帐户资源，以进行访问控制和计费。

如果针对每个项目环境使用一个资源组，那么管理员可以更好地控制项目环境级别的资源使用情况。例如，一个典型的项目有开发、测试和生产环境。名为 CustApp 的项目可能有以下资源组：

CustApp-Dev
CustApp-Test
CustApp-Prod

在此场景中，您可以为开发者分配对开发资源组的广泛访问权，以及对生产资源组的更严格访问权或不访问权。

使用资源组来组织资源

使用 IAM 访问控制管理的所有资源都属于一个资源组。在从目录创建资源时，将资源分配给其资源组。首先创建资源组很重要，因为在设置资源后无法更改资源分配。如果您意外地将资源分配给了错误的资源组，请删除该资源并创建新资源。

将为您的帐户创建缺省资源组。如果您使用的是 Lite 账户，则只能使用一个资源组。如果要创建多个资源组，请升级到现收现付或预订帐户。

搜索资源

您可以使用用户标记来轻松组织和搜索帐户中的资源。在查看将使用详情导出到 CSV 文件时，您还可以使用用户标记来帮助识别特定团队的使用情况或成本分配。

有关更多信息，请参阅使用标记。

IAM 访问权的工作方式

在帐户中设置和组织资源组之后，您可以利用以下几个策略来简化访问管理过程:

访问组: 您可以通过授予对访问组中所有身份的相同访问权 (而不是针对单个用户，服务标识或可信概要文件多次分配相同的访问权) 来最小限度地管理分配的策略数。必须先邀请用户加入您的帐户，然后才能将其添加到访问组。如果用户有资格使用作为访问组成员的可信概要文件，那么您不需要邀请他们加入您的帐户。
可信概要文件: 如果您的组织具有企业目录，那么可信概要文件可以减少管理访问权的时间和工作量。它简化了企业中联合用户的 IBM Cloud 帐户的登录过程。您可以通过创建可信概要文件来自动授予联合用户或计算资源对帐户的访问权。对于联合用户，根据 SAML 属性添加条件以定义哪些联合用户可以应用概要文件。对于计算资源，请指定特定资源，或者根据资源属性添加条件以定义哪些计算资源可以应用概要文件。对于这两种实体类型，授予的访问级别由每个可信概要文件中指定的访问策略或可信概要文件所属的访问组确定。但是，可信概要文件不需要邀请联合用户加入帐户，只有由外部身份提供者 (IdP) 联合的用户才能应用可信概要文件。

当您是多个访问组的成员时，当您访问帐户时，将同时应用所有策略。作为联合用户，您可以选择应用不同的可信概要文件，但在登录时仅选择一个要应用的概要文件。例如，如果要完成与开发者相关的任务，请在登录时选择 Developer 概要文件。如果要完成与管理员相关的任务，请选择具有特权许可权的 Admin 概要文件。这样，您就可以减少错误地执行特权操作的风险。

策略由主体、目标和角色组成。这里的主体是访问组或受信任的配置文件。目标是指希望主体访问的内容，如资源组中的一组资源、服务实例、账户中的所有服务或服务的所有实例。角色定义了授予的访问权限级别。

下图显示了访问策略的工作方式:

最常用的角色是查看器、编辑器、操作员和管理员平台角色。

查看者角色提供最低的访问权，可查看帐户中的实例和资源组。
操作员角色包括查看实例和管理凭证等操作。
编辑者角色包含与操作员角色相同的操作，但也包含用于创建，编辑，删除和绑定服务实例的操作。
管理员角色包含用于处理服务实例以及为该策略所针对的服务或实例分配对其他人的访问权的所有内容。

虽然这些是在平台中分配访问权的最常用角色，但还有第二组角色要考虑称为服务角色。映射到这些角色的操作由每个服务定义。通常，映射到这些角色的操作与使用服务的 API 和 UI 的能力特别相关。

有关可分配角色的更多信息，请参阅 IAM 角色。

减少管理访问权的时间和精力

帐户中允许的策略总数存在限制。您可以使用一些策略来确保未达到限制，并减少用于管理帐户中身份 (用户，服务标识或可信概要文件) 的访问权的时间量:

使用最小特权原则并仅分配必需的访问权。这可帮助您确保帐户中的身份仅限于要允许的操作。例如，访问策略的基于时间的条件仅在您指定的时间范围内授予访问权，从而减少发生安全违规时的攻击机会。有关更多信息，请参阅使用基于时间的条件限制访问权。
向资源组添加资源以进一步最小化必需策略的数量。例如，您可能有一个团队在使用帐户中的特定资源的项目上工作。使用仅向特定资源组中的资源分配访问权的策略将团队成员添加到访问组或可信概要文件。这样，您就不需要为每个团队成员的每个资源分配策略。
使用访问组来简化对需要相同访问级别的身份的管理访问。您可以设置定义了特定策略的访问组，然后将这些身份添加到该组。如果组成员稍后需要更多访问权，那么只需为访问组定义新策略。
使用访问权管理标记可大规模控制对帐户中资源和服务标识的访问权。通过仅分配对具有附加特定标记的资源和服务标识的访问权，可以避免对定义的策略进行多次更新。有关更多信息，请参阅使用标记控制对资源的访问。
使用可信概要文件可自动授予联合用户和计算资源对您帐户的访问权。通过这种方式，可以在登录期间通过评估基于 SAML 的属性来将联合用户映射到一个或多个可信概要文件，以确定他们可以应用哪些概要文件。将可信概要文件用于计算资源可帮助您避免存储用于运行应用程序的凭证以及管理和轮换凭证。您还可以添加可信概要文件以访问组，从而利用已创建的策略集。

通过使用一组服务来分配访问权，以便仅需要单个策略来分配对多个服务的访问权。这样，您可以减少帐户中的策略数，减少管理访问权的时间和工作量。

 * **All Identity and Access enabled services**: All catalog services that use IAM for access management.
 * **All Account Management services**: Platform services, such as billing and usage, license and entitlements, enterprises, and more. For more information, see [Assigning access to account management services](https://cloud.ibm.com/docs/account?topic=account-account-services&interface=ui#account-management-actions-roles).
 * **All IAM Account Management services**: A subset of account management services that includes the IAM platform services IAM Identity, IAM Access Management, IAM Users, IAM Groups, and future IAM services.

除去不活动身份和不活动策略的访问权可以降低对 IBM Cloud 资源进行未经授权的访问的风险，并帮助您更高效地管理访问权。有关更多信息，请参阅标识不活动身份和审计访问策略。

怎样才能制定良好的访问小组战略？

访问组是可以授予同一 IAM 访问权的分组中用户，服务标识和可信概要文件的组织。单个访问组中的所有身份都继承相同的访问权。

分配对资源组和所包含资源的访问权的逻辑方法是创建一个访问组，每个访问级别都是必需的。然后可以将每个访问组映射到先前创建的资源组。例如，要控制对 CustApp 项目的访问权，可以创建下列访问组：

审计员组
开发者组
管理员组

为审计员组分配两个访问策略，授予查看器访问 CustApp-Test 和 CustApp-Prod 资源和资源组的权限。为开发人员组分配两个访问策略，授予编辑访问 CustApp-Dev 和 CustApp-Test 资源和资源组的权限。为管理员组分配三个访问策略，授予管理员访问所有三个 CustApp 资源组及其资源的权限。

通过创建访问组并为其分配两个策略，可以为账户中的所有内容分配管理员访问权限。要创建第一个策略，请选择具有管理员平台角色和管理员服务角色的 所有启用身份和访问权的服务。要创建第二个策略，请选择 所有帐户管理服务，并分配有管理员角色。具有管理员角色的用户可以更改访问权，除去访问组以及从访问组添加和除去用户，包括具有管理员角色的其他用户。

对访问组具有管理员角色的用户可以通过在访问组中添加或除去用户来授予或撤销访问权。通过创建具有管理员访问权的访问组，您将向访问组的已添加管理员授予和撤销帐户的管理员访问权。对帐户中所有内容的管理员访问权包括撤销具有管理员角色的其他用户的访问权。

下图显示了如何将访问权分配给资源组:

分配资源组的访问权限

有关 IBM Garage for Cloud 的更多最佳实践，请参阅管理对 IBM Cloud。

样本访问策略

查看以下样本访问策略，以帮助您确定如何将访问权分配给资源组中组织的资源的访问组。

在整个帐户中授予访问组对 IBM Cloud Kubernetes Service 的平台管理员角色的策略。访问组中的用户可以访问此服务的所有实例，并在至少分配有查看者角色的任何资源组中创建服务实例。具有对任何资源分配的管理员角色的访问组成员也可以授予对该资源的访问权。
授予访问组在资源组上的平台查看器角色，但不授予其成员资源的策略。访问组中的用户对资源组具有可视性，此资源组是创建此资源组中任何服务的实例所必需的。
向访问组授予对资源组中所有资源的平台编辑者角色的策略。访问组中的用户可以编辑或删除该资源。
授予访问组对整个帐户 (所有启用 IAM 的服务) 的平台管理员角色的策略。访问组中的用户可以对整个帐户和管理操作中的任何资源执行任何平台操作，例如管理帐户中的资源组。

什么是值得信赖的概要文件策略?

受信任配置文件是联合用户或计算资源的分组，可授予相同的 IAM 访问权限。允许应用单个概要文件的所有身份将继承相同的访问权。要减少帐户中的策略数，您可以将计算资源和联合用户添加到同一可信概要文件 (如果其访问需求相同)。

将访问权分配给资源组和包含的资源的逻辑方法是通过创建一个可信概要文件来实现每个必需的访问级别。然后，可以将每个受信任配置文件映射到先前创建的资源组。例如，为控制对 CustApp 项目的访问，可以创建以下受信任配置文件：

审计员-概要文件
开发者-概要文件
管理-概要文件

对于 Auditor-Profile，根据您希望能够应用此概要文件的联合用户的 SAML 属性来指定条件。这些 SAML 属性是在企业用户目录中定义的。这样，管理联合用户，授予访问权和撤销访问权主要在公司用户目录中完成。接下来，分配两个访问策略，以授予查看者对 CustApp-Test 以及 CustApp-Prod 资源和资源组的访问权。

对于 Developer-Profile，根据您希望能够应用此概要文件的联合用户的 SAML 属性来指定条件。分配两个访问策略，用于授予对 CustApp-Dev 和 CustApp-Test 资源和资源组的编辑者访问权。对于 Admin-Profile，根据您希望能够应用此概要文件的联合用户的 SAML 属性来指定条件。然后，分配三个访问策略，以授予管理员对所有三个 CustApp 资源组及其资源的访问权。

可信概要文件 (与其他 IAM 身份一样) 可以通过使用策略或通过将其添加到访问组来授予访问权。如果您具有与可信概要文件所需的访问级别相同的访问组，那么可以将可信概要文件添加到该访问组。

下图显示了如何将访问权分配给可信概要文件:

![分配对受信任配置文件的访问权限](images/trusted-profiles.svg ""分配对受信任配置文件的访问权限 "")

首次创建可信概要文件时，只能选择一个可信实体类型。您可以随时更新可信概要文件以添加与计算资源的信任关系。

您可以通过创建可信概要文件并为其分配两个策略，为管理员分配对帐户中所有内容的访问权。要创建第一个策略，请选择具有管理员平台角色和管理员服务角色的 所有启用身份和访问权的服务。对于第二个策略，选择 所有帐户管理服务，并分配管理员角色。具有管理员角色的用户可以更新和除去可信概要文件的访问权，以及在可信概要文件中添加和除去用户，包括具有管理员角色的其他用户。

对可信概要文件具有管理员角色的用户可以通过在可信概要文件中添加或除去规则来授予或撤销访问权。通过创建具有管理员访问权的可信概要文件，您将向添加的可信概要文件管理员授予和撤销帐户的管理员访问权。对帐户中所有内容的管理员访问权包括撤销具有管理员角色的其他用户的访问权。

样本访问策略

查看以下样本访问策略，以帮助您确定如何将可信概要文件访问权分配给资源组中组织的资源。

一种策略，用于在整个帐户中授予联合用户对 IBM Cloud Kubernetes Service 的平台管理员角色。当联合用户的外部 IdP 属性满足信任关系的条件时，允许联合用户应用此概要文件。例如，如果公司用户目录具有通过值 admin 标识管理员的 jobrole 属性，那么您可以创建一个条件，以动态将具有该属性的联合用户与其他条件一起添加到可信概要文件。允许应用可信概要文件的联合用户可以访问此服务的所有实例，并在至少分配有查看者角色的任何资源组中创建该服务的实例。具有资源管理员角色的可信概要文件还可以授予对该资源的访问权。可以指定条件，以便只有需要最高特权的联合用户才能应用此可信概要文件。可以根据所有其他联合用户的 SAML 属性对其进行过滤。
用于在资源组上授予计算资源 Reader 和 Writer 角色的策略。当计算资源认证并满足可信概要文件 (例如 location 或 resource type ) 中指定的条件时，将自动应用可信概要文件。这样，满足这些条件的任何现有或未来资源都可以具有在认证时自动应用的概要文件。
您还可以使用特定计算资源 (例如单个 Kubernetes 集群) 建立信任。例如，您可能有一个正在 Kubernetes Service 上运行的应用程序，其中该应用程序需要从 IBM Cloudant 读写并读写 Cloud Object Storage Dedicated IBM Managed 存储区。 IBM Cloudant 和 Cloud Object Storage Dedicated IBM Managed 实例将位于同一资源组中，并且将为可信概要文件分配 Reader 或 Writer 角色。

使用可信概要文件是在 IBM Cloud 计算资源上运行的应用程序获取对启用 IAM 的资源的访问权的最佳实践。

比较访问组和可信概要文件

访问组最适合用于授予用户日常工作的访问权，而可信概要文件适合授予联合用户所需的访问级别，以便在有限的时间段内完成一组专门的特定任务。这些通常是您希望避免在日常工作中无意中执行的关键任务。通过可信概要文件，联合用户无需加载到 IBM Cloud，即可通过信任关系授予他们对帐户中 IBM Cloud 资源的访问权。如果联合用户离开您的公司，那么您只需在目录中删除他们的公司身份，这也会除去对 IBM Cloud的访问权。使用可信概要文件的基于时间的访问允许频繁进行认证检查以降低安全风险。

使用下表来了解使用访问组和可信概要文件之间的差异，以便为您的用例做出最佳决策。

比较访问组和受信任配置文件
功能	访问组	可信个人档案
IAM 访问控制	是	是
需要邀请用户加入 IBM Cloud 帐户	是	否
可以在将用户添加到帐户之前定义访问权	是，通过使用动态规则	是
联合用户	是	是
非联合用户	是	是
服务标识	是	是
计算资源标识	否	是
用户管理主要在	IBM Cloud 帐户	公司用户目录

访问组和可信概要文件可以单独或直接用于用户和访问管理，具体取决于贵组织的需求。

例如，对于 CustApp 项目，您可以选择使用以下策略创建 IAM Admin 可信概要文件:

Administrator 用于访问组 CustApp-Dev/Test/Prod. 通过这种方式，管理员可以将用户添加到访问组并将其从访问组中除去，从而授予用户并撤销其访问权。
Administrator 用于 IAM 身份帐户管理服务。这样，管理员可以管理服务标识，可信概要文件和规则等。
Editor for User Management 帐户管理服务。这样，管理员可以邀请用户加入帐户，查看帐户中的用户等。

通过此可信概要文件，管理员可以将开发者添加到具有广泛访问策略的访问组，以完成开发和测试环境中的日常操作和任务。可以在名为 Operator-Profile 的可信概要文件中设置对生产环境的操作的访问权。通过这种方式，开发者可以在需要对生产中的 CustApp 执行任何操作时，通过登录并应用 Operator-Profile 来更改作业角色。

组织资源和分配访问权限的用例

查看以下用例，以帮助您准备适用于组织的计划。对于每个用例，建议使用访问组或可信概要文件来向一组用户提供访问权，同时维护最少数量的访问策略。通过使用访问组，您只需在访问组中添加或除去帐户中的用户，即可根据需要分配或撤销访问权。通过使用可信概要文件，您可以轻松更新允许企业用户目录中的联合用户应用可信概要文件的条件，而不必邀请他们加入帐户或向每个用户分配单独的访问权。

多个用户通过使用访问组在单个项目上共同工作

账户中的某些用户需要管理账户并为其他用户分配访问权限。某些用户需要创建产生费用的服务实例。其他用户是应用程序开发人员，他们只需要使用其应用程序组件中的服务实例。

您希望授予所有用户帐户和缺省资源组中的各种角色。您不需要创建更多资源组来分隔资源或限制某些用户访问某些资源。您可以通过为每组用户创建一个访问组，向用户授予适合其需求的角色:

创建访问组，并将需要管理帐户并授予他人访问权的用户分配给该组。然后，分配对所有启用 IAM 的服务和所有帐户管理服务具有管理员角色的策略。
创建访问组，并将用户分配给需要创建服务实例的组。然后，对缺省资源组分配具有编辑者角色的策略，并对用户需要创建的任何服务分配具有编辑者角色的策略。
创建访问组并将用户分配给需要在资源组中使用服务实例的组。然后，对资源组中存在的服务实例分配具有写程序或读者角色的策略。

多个用户通过使用可信概要文件在单个项目上协同工作

在一个组织中，当你想大规模管理访问权限时，组织中的一些成员需要管理 IBM Cloud 账户，并为其他用户分配访问权限。某些成员需要创建产生费用的服务实例。其他成员是应用程序开发人员，他们只需要使用其应用程序组件中的服务实例。

您希望授予所有用户帐户和缺省资源组中的各种角色。您不需要创建更多资源组来分隔资源或限制某些用户访问某些资源。您可以通过为每种类型的用户创建可信概要文件，并根据外部 IdP 属性将其映射到正确的概要文件，为用户授予适合其需求的角色:

为需要管理帐户并授予他人访问权的用户创建可信概要文件。与外部 IdP 建立信任关系，并定义允许组织的相应成员应用概要文件的属性。然后，分配对所有启用 IAM 的服务和所有帐户管理服务具有管理员角色的策略。
为需要创建服务实例的用户创建可信概要文件。与外部 IdP 建立信任关系，并定义允许组织的相应成员应用概要文件的属性。然后，对缺省资源组分配具有编辑者角色的策略，并对用户需要创建的任何服务分配具有编辑者角色的策略。
为需要在资源组中使用服务实例的用户创建可信概要文件。与外部 IdP 建立信任关系，并定义允许组织的相应成员应用概要文件的属性。然后，对资源组中存在的服务实例分配具有写程序或读者角色的策略。

两个团队负责两个相关项目

您的帐户中有两个功能项目。处理项目的开发人员需要访问其所有资源。作为帐户管理员，您可以通过为每个项目创建访问组并将访问管理标记合并到每个组的访问策略中来授予访问权。

灵活性非常重要，通过 IAM，您可以在各个组之间共享资源。假设您注意到资源可能适用于这两个项目。您可以通过标记资源并依赖现有许可权向开发者授予访问权，在两个项目之间共享资源。如果项目不再需要资源，那么只需通过从服务实例拆离相应的标记来撤销开发者的访问权。请查看以下视频，以更好地了解如何使用访问权管理标记来管理对帐户中资源的访问权。

视频文字记录

作为帐户管理员，您可以使用标记来大规模集中管理对帐户中资源的访问权。

例如，您有两个功能项目: 一个称为 soulmate，用于 Watson 语言服务和存储，另一个称为 Soul-FAQ，这是对项目 soulmate 的支持。它使用 Watson Assistant 和 Cloud Object Storage。

要以帐户管理员身份创建访问权管理标记，请在 IBM Cloud 控制台中单击“管理帐户”。在“标记”页面中，单击“访问管理标记”。要创建新标记，请输入以逗号分隔的标记名称。我们正在创建两个标记: 一个用于项目 soulmate，另一个用于项目灵魂-faq。

跳转到资源列表可以看到帐户上的所有资源。您可以在此处标记与项目相关的资源，并通过按标记进行过滤来在整个帐户中查看这些资源。

此时，开发者无法查看资源，因为他们还没有分配的正确许可权。

帐户管理员可以授予开发者许可权，以使用访问组和标记的组合来访问其项目上的资源。

作为帐户管理员，单击“管理”，然后单击“访问”并选择“访问组”。您设置了两个访问组: 一个用于 soulmate 项目，一个用于常见问题解答。

在 soulmate 开发团队中有一个开发人员。未设置任何策略，因此帐户管理员需要分配访问权。为此，请根据特定属性选择帐户中的所有服务。选择“访问管理标记”以查看帐户中可用的所有标记。由于要为项目 soulmate 创建策略，请选择相应的标记。控制台显示项目 soulmate 标记映射到三个不同的资源。

接下来，选择一些角色。为整个组提供查看者角色，以便每个人都可以查看列表中的资源以及对这些服务的所有功能访问权。单击“分配”创建策略。

现在有三种服务可供开发人员使用。他们可以访问所有三个资源以及可能存在的任何子资源。

灵活性非常重要，因此我们可以轻松地在各个群体之间共享资源。比方说，账户管理员注意到 IBM Cloud Object Storage 非常适合备份目的，并且与常见问题项目配合得很好。账户管理员希望在 soulmate 项目中使用 IBM Cloud Object Storage。

只需编辑访问权管理标记。添加项目 soulmate 标记，然后单击“保存”。

在资源列表中，您可以确认有两个访问管理标记附加到 Cloud Object Storage 实例。

除了原始资源外，开发者现在还可以查看 Cloud Object Storage 资源。该实例可供有权访问项目 soulmate 或项目常见问题的任何人使用。

假设您不再需要 soulmate 项目的 Tone Analyzer 服务。从 Tone Analyzer 服务拆离项目 soulmate 标记将撤销开发者对该服务实例的访问权。帐户管理员可以通过单击“编辑标记”并从列表中删除该标记来拆离该标记。

Tone Analyzer 服务实例不再包含在开发者的资源列表中。

当您使用访问权管理标记来控制访问权时，团队的项目可以在无需更新 IAM 策略的情况下增长。

三个团队负责三个项目

我的帐户中有几个用户是管理员。他们需要创建新的资源组并为用户分配对这些资源组的访问权。我将这些用户分配给具有策略的访问组，该策略具有在所有启用 IAM 的服务上分配的管理员角色。

其余用户只需访问与其项目相关联的资源组。我使用访问组并在资源组及其与其项目关联的成员上分配各种角色: 需要创建实例的人员的资源组上的编辑者角色，以及需要使用这些实例的人员的资源组成员上的读者或写程序角色。

我的帐户中有多个资源组

我的帐户中的某些用户是整个帐户中服务 Service A 的管理员，他们需要访问该服务的所有实例并创建实例。这些用户不需要访问帐户中的其他资源。我在帐户级别创建访问组并在服务 A 上分配管理员角色，并为帐户中需要能够在其中创建实例的任何资源组分配具有查看者角色的策略。您可以通过选择 仅资源组，然后选择资源组以及该资源组的至少查看者角色来执行此操作。然后，对需要访问的每个资源组重复此操作。

需要访问特定资源的用户

我的帐户包含只需要访问一个服务中特定资源的用户，例如，在 IBM Cloud Object Storage中写入存储区 Bucket A 的能力。此用户无需查看我的帐户中的资源组，也无需访问此 Object Storage实例中的其他服务或存储区。

我在 Object Storage的特定实例中为用户分配对存储区 A 的写程序角色。我可以选择使用 IAM UI 或 Object Storage UI 来分配角色。我使用特定于服务的 UI，因为我可以从资源列表中获取。 IAM UI 不会显示超过服务实例级别的资源，我需要手动输入 CRN 以将策略分配给这些资源。

后续步骤

现在，您知道了如何设置资源组，组织资源以及在帐户中创建访问组，您可以开始邀请用户加入帐户，并为他们分配对访问组的访问权。如果您已邀请用户加入帐户，那么可以转至“用户”页面并开始分配访问权。

如果您决定组织要根据公司用户目录来管理用户访问权，那么可以从创建可信概要文件开始。