リソースを編成してアクセス権限を割り当てるためのベスト・プラクティス

IBM Cloud® アカウントをセットアップしたら、リソースをプロビジョニングまたは予約可能な物理的または論理的なインスタンス。リソースの例としては、ストレージ、プロセッサ、メモリ、データベース、クラスタ、VMなどがある。どのように整理し、アカウント内の ID にアクセス権を割り当てるかを計画する準備が整いました。これらのベスト・プラクティスは、IBM Cloud でセキュアなアプリ開発を正常に行えるようにするための基本的なビルディング・ブロックとなります。

以下のベスト・プラクティスは、IBM Cloud Identity and Access Management (IAM) に対応していてリソース・グループに割り当てられたリソースに焦点を当てています。古典的なインフラサービスはIAMに対応していないため、リソースグループに割り当てることができない。

優れたリソース・グループ戦略とは

アクセス制御および請求処理のために、リソース・グループを使用してアカウントのリソースを編成できます。

プロジェクト環境ごとに 1 つのリソース・グループが使用されると、管理者はプロジェクト環境レベルでリソース使用量をより簡単に制御できます。例えば、標準的なプロジェクトには、開発環境、テスト環境、および実稼働環境があります。例えば CustApp という名前のプロジェクトに、以下のリソース・グループがあるとします。

CustApp-Dev
CustApp-Test
CustApp-Prod

このシナリオでは、開発者に開発リソースグループへの広範囲なアクセス権を割り当て、本番リソースグループへのアクセス権はかなり厳しくするか、まったく割り当てないかもしれません。

リソース・グループ内のリソースの編成

IAM アクセス制御を使用して管理されるリソースはすべて、リソース・グループに属します。リソースをカタログから作成するときに、リソース・グループに割り当てます。リソースの割り当ては設定後は変更できないため、最初にリソース・グループを作成することが重要です。正しくないリソース・グループにリソースを割り当てた場合は、リソースを削除し、新しく作成してください。

アカウントに対して、デフォルトのリソース・グループが作成されます。ライト・アカウントを使用している場合、リソース・グループの使用は 1 つに制限されます。複数のリソース・グループを作成する場合は、従量課金アカウントまたはサブスクリプション・アカウントにアップグレードしてください。

リソースの検索

ユーザー・タグを使用して、アカウント内のリソースを簡単に編成したり検索したりできます。また、使用状況の詳細を CSV ファイルにエクスポートする際に、ユーザータグを使用して、特定のチームの使用状況やコスト配分を特定することもできます。

詳しくは、『タグの処理』を参照してください。

IAM アクセス権限の仕組み

アカウント内のリソース・グループをセットアップして編成した後、いくつかの戦略を利用してアクセス管理プロセスを簡素化することができます。

アクセス・グループ: 同じアクセス権限を個々のユーザー、サービス ID、トラステッド・プロファイルごとに何度も割り当てる代わりに、アクセス・グループ内のすべての ID に同じアクセス権限を付与することで、割り当てるポリシー数の管理を最小限に抑えることができます。ユーザーをアクセス・グループに追加するには、その前にそのユーザーを自分のアカウントに招待する必要があります。アクセス・グループのメンバーであるトラステッド・プロファイルの資格を満たしているユーザーは、アカウントに招待する必要はありません。
トラステッド・プロファイル: 組織でエンタープライズ・ディレクトリーを使用している場合、トラステッド・プロファイルを使用することによって、アクセス権限を管理するための時間と労力を削減することができます。また、会社のフェデレーテッド・ユーザーの IBM Cloud アカウントへのログイン・プロセスも簡素化されます。トラステッド・プロファイルを作成することによって、フェデレーテッド・ユーザーやコンピュート・リソースにアカウントへのアクセス権限を自動的に付与することができます。フェデレーテッド・ユーザーの場合は、SAML 属性に基づく条件を追加して、どのフェデレーテッド・ユーザーがプロファイルを適用できるかを定義します。コンピュート・リソースの場合は、特定のリソースを指定するか、またはリソース属性に基づく条件を追加して、どのコンピュート・リソースがプロファイルを適用できるかを定義します。どちらのエンティティー・タイプの場合も、付与されるアクセス・レベルは、各トラステッド・プロファイル内で指定されるアクセス・ポリシー、またはトラステッド・プロファイルが属するアクセス・グループによって決定されます。ただし、トラステッド・プロファイルを使用する場合フェデレーテッド・ユーザーをアカウントに招待する必要はなく、外部 ID プロバイダー (IdP) によって統合されたユーザーのみがトラステッド・プロファイルを適用できます。

複数のアクセス・グループに属するメンバーがアカウントにアクセスすると、同時にすべてのポリシーが適用されます。フェデレーテッド・ユーザーは、複数の異なるトラステッド・プロファイルを適用できる可能性がありますが、ログイン時は適用するプロファイルを 1 つだけ選択します。たとえば、開発者関連のタスクを完了したい場合は、ログイン時に Developer プロファイルを選択します。管理者関連のタスクを実行する場合は、特権許可を持つ Admin プロファイルを選択します。こうすることで、特権的なアクションを誤って実行してしまうリスクを減らすことができます。

ポリシーは、サブジェクト、ターゲット、および役割で構成されます。この場合のサブジェクトは、アクセス・グループまたはトラステッド・プロファイルです。ターゲットは、サブジェクトのアクセス先にするものです。例えば、リソース・グループ内のリソースの集合、1 つのサービス・インスタンス、アカウント内のすべてのサービス、1 つのサービスのすべてのインスタンスなどです。役割は、付与されるアクセス権限のレベルを定義します。

次の図は、アクセス・ポリシーがどのように機能するかを示しています。

最も一般的に使用される役割は、ビューアー、エディター、オペレーター、管理者の各プラットフォーム役割です。

ビューアー役割は、アカウント内のインスタンスおよびリソース・グループを表示するための最低限のアクセス権限を付与します。
オペレータの役割には、インスタンスの表示や認証情報の管理などのアクションが含まれる。
エディター役割にはオペレーター役割と同じアクションが含まれますが、サービス・インスタンスを作成、編集、削除、バインドするためのアクションも含まれます。
管理者役割には、サービス・インスタンスを扱うために必要なすべてと、ポリシーが適用されるそのサービスまたはインスタンスに対するアクセス権限を他のユーザーに割り当てるために必要なすべてが含まれています。

これらはプラットフォーム内のアクセス権限を割り当てる場合の最も一般的な役割ですが、サービス役割と呼ばれるもう 1 つの役割セットを考慮する必要があります。これらの役割にマップされるアクションは、サービスごとに定義されます。これらの役割にマップされるアクションは通常、サービスの API と UI を使用してできることに特に関連しています。

割り当てることのできる役割について詳しくは、『IAM 役割』を参照してください。

アクセス管理の時間と労力の削減

アカウントで許可されるポリシーの合計数には制限があります。この制限に達しないようにするため、また、アカウント内の ID (ユーザー、サービス ID、またはトラステッド・プロファイル) のアクセス管理に費やす時間を短縮するために、いくつかの戦略を使用できます。

最小限の特権を付与するという原則に従い、必要なアクセス権限のみを割り当てます。こうすることで、アカウント内の ID のアクションを、許可したアクションのみに制限することができます。例えば、アクセス・ポリシーの時間ベースの条件では、指定した時間フレーム内でのみアクセス権限が付与されるため、セキュリティー・ブリーチが発生した場合に攻撃を受ける機会が減少します。詳しくは、時間ベースの条件によるアクセスの制限を参照してください。
リソースをリソース・グループに追加することによって、必要なポリシーの数をさらに少なくすることができます。例えば、アカウント内の特定のリソースを使用するプロジェクトで作業するチームがあるとします。そのチームのメンバーを、特定のリソース・グループのリソースへのアクセス権限のみを割り当てるポリシーを設定したアクセス・グループまたはトラステッド・プロファイルに追加します。そのようにすれば、チーム・メンバーごとにそれぞれのリソースに対するポリシーを割り当てる必要はありません。
アクセス・グループを使用して、同じレベルのアクセス権限を必要とする ID のアクセス管理を合理化します。特定のポリシーを定義したアクセス・グループをセットアップし、そのグループに ID を追加します。後にグループ・メンバーにさらにアクセス権限が必要になった場合には、そのアクセス・グループに新しいポリシーを定義します。
アクセス管理タグを使用して、アカウント内のリソースとサービスIDへのアクセスを大規模に制御します。特定のタグが付けられたリソースやサービスIDにのみアクセスを割り当てることで、定義したポリシーを何度も更新する必要がなくなります。詳しくは、タグを使用したリソースに対するアクセス権限の制御を参照してください。
トラステッド・プロファイルを使用することによって、フェデレーテッド・ユーザーとコンピュート・リソースにアカウントへのアクセス権限を自動的に付与することができます。この方法では、ログイン時に SAML ベースの属性を評価してフェデレーテッド・ユーザーが適用できるプロファイルを判別することにより、1 つ以上のトラステッド・プロファイルにフェデレーテッド・ユーザーをマップすることができます。コンピュート・リソースにトラステッド・プロファイルを使用することによって、アプリケーションを実行するための資格情報の保管や、資格情報の管理とローテーションの操作を回避することができます。また、トラステッド・プロファイルをアクセス・グループに追加することで、既に作成したポリシーのセットを活用することもできます。

複数のサービスにアクセス権限を割り当てるために必要なポリシーが 1 つだけになるように、サービスのグループを使用してアクセス権限を割り当てます。このようにして、アカウント内のポリシーの数を減らし、アクセスを管理する時間と労力を削減します。

 * **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.

非アクティブな ID や非アクティブなポリシーのアクセスを削除することで、 IBM Cloud リソースへの不正アクセスのリスクを低減し、アクセス管理を効率化できます。詳しくは、「非アクティブ ID の識別」および「アクセス・ポリシーの監査」を参照してください。

優れたアクセス・グループ戦略とは

アクセス・グループとは、同じ IAM アクセス権限を付与できるユーザー、サービス ID、およびトラステッド・プロファイルをグループ化した組織です。 1 つのアクセス・グループ内の ID はすべて、同じアクセス権限を継承します。

リソース・グループとそれに含まれるリソースに対するアクセス権限を割り当てる論理的方法は、必要なアクセス権限レベルごとにアクセス・グループを 1 つ作成することです。その後、各アクセス・グループを、前に作成したリソース・グループにマップできます。例えば、CustApp プロジェクトへのアクセスを制御するために、以下のアクセス・グループを作成できます。

Auditor-Group
Developer-Group
Admin-Group

Auditor-Group には、CustApp-Test リソースおよびリソース・グループと CustApp-Prod リソースおよびリソース・グループに対するビューアー権限を付与する 2 つのアクセス・ポリシーを割り当てます。 Developer-Group には、CustApp-Dev リソースおよびリソース・グループと CustApp-Test リソースおよびリソース・グループに対するエディター権限を付与する 2 つのアクセス・ポリシーを割り当てます。 Admin-Group には、3 つの CustApp リソース・グループとそれらのリソースのすべてに対する管理者権限を付与する 3 つのアクセス・ポリシーを割り当てます。

アクセス・グループを作成してそれに 2 つのポリシーを割り当てることによって、アカウント内のすべてに対する管理者権限を割り当てることができます最初のポリシーを作成するには、Administrator プラットフォームロールと Manager サービスロールを使用して、「 All Identity and Access enabled services 」を選択する。 2つ目のポリシーを作成するには、管理者ロールが割り当てられているすべてのアカウント管理サービスを選択します。管理者役割を持つユーザーは、アクセス権限を変更したり、アクセス・グループを削除したり、アクセス・グループにユーザー (管理者役割を持つ他のユーザーを含む) を追加したり、アクセス・グループからユーザーを削除したりすることができます。

アクセス・グループに対する管理者役割を持つユーザーは、アクセス・グループに対してユーザーを追加または削除することで、アクセス権限を付与または取り消すことができます。管理者権限を持つアクセス・グループを作成することにより、アカウントの管理者権限の付与および取り消しを、アクセス・グループの追加された管理者に委任することになります。アカウント内のすべてのものに対する管理者権限には、管理者役割を持つ他のユーザーのアクセス権限を取り消す機能が含まれます。

次の図は、リソース・グループへのアクセス権限の割り当て方法を示しています。

IBM Garage for Cloud のベストプラクティスについては、 IBM Cloud のリソースへのアクセス管理を参照してください。

サンプル・アクセス・ポリシー

以下のサンプル・アクセス・ポリシーを確認して、リソース・グループとして編成されたリソースに対するアクセス権限をどのようにアクセス・グループに割り当てればよいかの判断に役立ててください。

アカウント全体にわたる IBM Cloud Kubernetes Service に対する管理者プラットフォーム役割をアクセス・グループに付与するポリシー。アクセス・グループ内のユーザーは、このサービスのすべてのインスタンスにアクセスでき、また、ビューアー以上の役割がユーザーに割り当てられているリソース・グループ内に、このサービスのインスタンスを作成することができます。いずれかのリソースに対する管理者役割が割り当てられたアクセス・グループ・メンバーは、そのリソースに対するアクセス権限を付与することもできます。
リソース・グループ (ただし、そのメンバー・リソースは除く) に対するビューアー・プラットフォーム役割をアクセス・グループに付与するポリシー。アクセス・グループ内のユーザーにリソース・グループが表示されます。これは、このリソース・グループ内にサービスのインスタンスを作成するために必要です。
リソース・グループ内のすべてのリソースに対するエディター・プラットフォーム役割をアクセス・グループに付与するポリシー。アクセス・グループ内のユーザーは、そのリソースを編集したり削除したりできます。
アカウント全体 (すべての IAM 対応サービス) に対する管理者プラットフォーム役割をアクセス・グループに付与するポリシー。アクセス・グループ内のユーザーは、アカウント全体内の任意のリソースに対して任意のプラットフォーム・アクションを実行でき、アカウント内のリソース・グループの管理などの管理アクションを実行できます。

優れたトラステッド・プロファイル戦略とは?

トラステッド・プロファイルとは、同じ IAM アクセス権限を付与できるフェデレーテッド・ユーザーまたはコンピュート・リソースのグループです。 1 つのプロファイルを適用できるすべての ID は、同じアクセス権限を継承します。アカウント内のポリシーの数を減らすため、コンピュート・リソースとフェデレーテッド・ユーザーのアクセス要件が同じである場合は、それらを同じトラステッド・プロファイルに追加することができます。

リソース・グループとそれに含まれるリソースに対するアクセス権限を割り当てる論理的な方法は、必要なアクセス・レベルごとにトラステッド・プロファイルを 1 つ作成する方法です。その後、それぞれのトラステッド・プロファイルを、前に作成したリソース・グループにマップすることができます。例えば、CustApp プロジェクトへのアクセスを制御するために、以下のトラステッド・プロファイルを作成するとします。

Auditor-Profile
Developer-Profile
Admin-Profile

Auditor-Profile では、このプロファイルを適用できるようにさせたいフェデレーテッド・ユーザーの SAML 属性に基づいて条件を指定します。これらの SAML 属性は、お客様の企業ユーザー・ディレクトリーで定義されています。したがって、フェデレーテッド・ユーザーの管理、アクセス権限の付与、およびアクセス権限の取り消しは、主に企業ユーザー・ディレクトリーで行われることになります。次に、CustApp-Test および CustApp-Prod のリソースとリソース・グループに対するビューアー権限を付与する、2 つのアクセス・ポリシーを割り当てます。

Developer-Profile では、このプロファイルを適用できるようにさせたいフェデレーテッド・ユーザーの SAML 属性に基づいて条件を指定します。 CustApp-Dev および CustApp-Test のリソースとリソース・グループに対するエディター権限を付与する、2 つのアクセス・ポリシーを割り当てます。 Admin-Profile では、このプロファイルを適用できるようにさせたいフェデレーテッド・ユーザーの SAML 属性に基づいて条件を指定します。その後、3 つのすべての CustApp リソース・グループとそれらのリソースに対する管理者権限を付与する、3 つのアクセス・ポリシーを割り当てます。

トラステッド・プロファイルには、他の IAM ID と同様に、ポリシーを使用するか、アクセス・グループに追加することによって、アクセス権限を付与することができます。トラステッド・プロファイルが必要とするのと同じレベルのアクセス権限を持つアクセス・グループがある場合、トラステッド・プロファイルをそのアクセス・グループに追加できます。

次の図は、トラステッド・プロファイルにアクセス権限を割り当てる方法を示しています。

トラステッド・プロファイルを最初に作成するときは、トラステッド・エンティティー・タイプを 1 つだけ選択できます。トラステッド・プロファイルを更新して、コンピュート・リソースとの信頼関係を追加することはいつでも可能です。

トラステッド・プロファイルを作成してそれに 2 つのポリシーを割り当てることによって、アカウント内のすべてのものに対する管理者権限を割り当てることができます。最初のポリシーを作成するには、Administrator プラットフォームロールと Manager サービスロールを使用して、「 All Identity and Access enabled services 」を選択する。 2つ目のポリシーでは、管理者ロールが割り当てられているすべてのアカウント管理サービスを選択します。管理者ロールを持つユーザーは、トラステッド・プロファイルのアクセス権限の更新と削除、およびトラステッド・プロファイルへのユーザーの追加と削除を行うことができます。これには、管理者ロールを持つ他のユーザーも含まれます。

トラステッド・プロファイルに対する管理者ロールを持つユーザーは、トラステッド・プロファイルに対してルールを追加または削除することにより、アクセス権限を付与または取り消すことができます。管理者権限を持つトラステッド・プロファイルを作成することにより、アカウントの管理者権限の付与および取り消しを、そのトラステッド・プロファイルの追加された管理者に委任することになります。アカウント内のすべてのものに対する管理者権限には、管理者役割を持つ他のユーザーのアクセス権限を取り消す機能が含まれます。

サンプル・アクセス・ポリシー

以下のサンプル・アクセス・ポリシーを確認して、リソース・グループとして編成されたリソースに対するアクセス権限をどのようにトラステッド・プロファイルに割り当てればよいかの判断に役立ててください。

アカウント全体にわたる IBM Cloud Kubernetes Service に対するプラットフォーム管理者役割をフェデレーテッド・ユーザーに付与するポリシー。フェデレーテッド・ユーザーは、フェデレーテッド・ユーザーの外部 IdP 属性が信頼関係の条件を満たす場合に、このプロファイルを適用できます。例えば、企業ユーザー・ディレクトリーに、jobrole という値で管理者を識別する admin という属性がある場合、その属性を持つフェデレーテッド・ユーザーをトラステッド・プロファイルに動的に追加する条件を、他の条件とともに作成することができます。トラステッド・プロファイルの適用が許可されているフェデレーテッド・ユーザーは、このサービスのすべてのインスタンスにアクセスすることができます。また、そのユーザーに少なくともビューアー役割が割り当てられているリソース・グループ内にサービスのインスタンスを作成することもできます。特定のリソースに対する管理者役割を持つトラステッド・プロファイルは、そのリソースに対するアクセス権限を付与することもできます。最高の特権を必要とするフェデレーテッド・ユーザーのみがこのトラステッド・プロファイルを適用できるように、条件を指定することができます。他のすべてのフェデレーテッド・ユーザーは、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 リソースへのアクセス権限を与えられます。フェデレーテッド・ユーザーが会社を退職する場合は、ディレクトリー内のそのユーザーの企業 ID を削除すれば、IBM Cloud に対するアクセス権限も削除されます。トラステッド・プロファイルを使用した時間ベースのアクセス権限を使用すると、セキュリティー・リスクの削減のための頻繁な認証検査が可能になります。

以下の表を使用して、アクセス・グループを使用する場合とトラステッド・プロファイルを使用する場合の違いを理解し、お客様のユース・ケースに最適な決定を行ってください。

アクセス・グループとトラステッド・プロファイルの比較
特長	アクセス・グループ	トラステッド・プロファイル
IAM アクセス制御	ある	ある
ユーザーを IBM Cloud アカウントに招待することが必要	ある	いいえ
ユーザーをアカウントに追加する前にアクセス権限を定義できる	はい (動的ルールを使用することにより可能)	ある
フェデレーテッド・ユーザー	ある	ある
非フェデレーテッド・ユーザー	ある	ある
サービス ID	ある	ある
コンピュート・リソース ID	いいえ	ある
ユーザー管理を行う主な場所	IBM Cloud アカウント	企業ユーザー・ディレクトリー

アクセス・グループおよびトラステッド・プロファイルは、ユーザー管理およびアクセス管理のために、組織のニーズに応じて個別に使用することも組み合わせて使用することもできます。

例えば、CustApp プロジェクトに対しては、以下のポリシーを使用して IAM Admin トラステッド・プロファイルを作成することができます。

アクセス・グループ CustApp-Dev/Test/Prod のAdministrator。これにより、管理者はユーザーをアクセス・グループに追加したり、そこから削除したりすることによって、アクセス権限をユーザーに付与したり、それを取り消したりすることができます。
IAM ID アカウント管理サービスのAdministrator。これにより、管理者はサービス ID、トラステッド・プロファイル、ルールなどを管理することができます。
「ユーザー管理」アカウント管理サービスのEditor。これにより、管理者はアカウントにユーザーを招待したり、アカウント内のユーザーを表示したりすることができます。

管理者は、このトラステッド・プロファイルを使用することで、開発環境とテスト環境で日常のアクションやタスクを実行するための多岐にわたるアクセス・ポリシーが設定されたアクセス・グループに開発者を追加することができます。実稼働環境での運用のためのアクセス権限は、Operator-Profile というトラステッド・プロファイルでセットアップできます。そうすれば、開発者は実稼働環境で Operator-Profile に対して操作アクションを実行する必要があるときに、ログインして CustApp を適用することによって職務役割を変更することができます。

リソースの編成とアクセス権限の割り当てのユース・ケース

以下のユース・ケースを確認して、組織に合った計画の準備に役立ててください。どのユース・ケースでも、アクセス・グループまたはトラステッド・プロファイルを使用して、最小限の数のアクセス・ポリシーを維持しながらユーザー・グループにアクセス権限を付与することをお勧めします。アクセス・グループを使用すると、アカウント内のユーザーをアクセス・グループに追加したりそこから削除したりするだけで、必要に応じてアクセス権限を割り当てたり取り消したりすることができます。トラステッド・プロファイルを使用すると、企業ユーザー・ディレクトリーに属するフェデレーテッド・ユーザーにトラステッド・プロファイルの適用を許可する条件を簡単に更新することができ、それらのユーザーをアカウントに招待したり、各ユーザーに個別のアクセス権限を割り当てたりする必要はありません。

アクセス・グループを使用して 1 つのプロジェクトで共同作業している複数のユーザー

アカウント内のユーザーの何人かは、アカウントを管理し、他のユーザーにアクセス権限を割り当てる必要があります。費用が発生するサービス・インスタンスを作成する必要があるユーザーもいます。その他のユーザーはアプリケーション開発者であり、必要なのは、それぞれのアプリケーション・コンポーネントからサービス・インスタンスを使用することだけです。

アカウントとデフォルト・リソース・グループのさまざまな役割をすべてのユーザーに付与します。さらにリソース・グループを作成してリソースを分けたり、ユーザーによって一部のリソースへのアクセスを制限したりする必要はありません。ユーザーのグループごとにアクセス・グループを作成することにより、ユーザーのニーズに合った役割をユーザーに付与できます。

アクセス・グループを作成し、アカウントを管理するとともに他のユーザーにアクセス権限を付与する必要があるユーザーをそのグループに割り当てます。次に、すべての IAM 対応サービスおよびすべてのアカウント管理サービスに対する管理者役割が設定されたポリシーを割り当てます。
アクセス・グループを作成し、サービス・インスタンスを作成する必要があるユーザーをそのグループに割り当てます。次に、デフォルト・リソース・グループに対するエディター役割が設定されたポリシーと、ユーザーが作成する必要のあるサービスに対するエディター役割が設定されたポリシーを割り当てます。
アクセス・グループを作成し、リソース・グループ内のサービス・インスタンスを使用する必要があるユーザーをそのグループに割り当てます。次に、リソース・グループ内に存在するサービス・インスタンスに対するライター役割またはリーダー役割が設定されたポリシーを割り当てます。

トラステッド・プロファイルを使用して 1 つのプロジェクトで共同作業している複数のユーザー

組織において、アクセス管理を大規模に行いたい場合、組織内の一部のメンバーが IBM Cloud アカウントを管理し、他のユーザーにアクセス権を割り当てる必要があります。あるメンバーは、費用が発生するサービス・インスタンスを作成する必要があります。他のメンバーはアプリケーション開発者であり、自分のアプリケーション・コンポーネントの中にあるサービス・インスタンスのみを使用する必要があります。

アカウントとデフォルト・リソース・グループのさまざまな役割をすべてのユーザーに付与します。さらにリソース・グループを作成してリソースを分けたり、ユーザーによって一部のリソースへのアクセスを制限したりする必要はありません。ユーザー・タイプごとにトラステッド・プロファイルを作成し、ユーザーを外部 IdP の属性に基づいて正しいプロファイルにマップすることによって、ユーザーのニーズに合った適切な役割をユーザーに付与することができます。

アカウントを管理し、他のユーザーにアクセス権限を付与する必要があるユーザーのためのトラステッド・プロファイルを作成します。外部 IdP との信頼関係を確立し、組織の適切なメンバーがプロファイルを適用できるように属性を定義します。次に、すべての IAM 対応サービスおよびすべてのアカウント管理サービスに対する管理者役割が設定されたポリシーを割り当てます。
サービス・インスタンスを作成する必要があるユーザーのためのトラステッド・プロファイルを作成します。外部 IdP との信頼関係を確立し、組織の適切なメンバーがプロファイルを適用できるように属性を定義します。次に、デフォルト・リソース・グループに対するエディター役割が設定されたポリシーと、ユーザーが作成する必要のあるサービスに対するエディター役割が設定されたポリシーを割り当てます。
リソース・グループ内のサービス・インスタンスを使用する必要があるユーザーのためのトラステッド・プロファイルを作成します。外部 IdP との信頼関係を確立し、組織の適切なメンバーがプロファイルを適用できるように属性を定義します。次に、リソース・グループ内に存在するサービス・インスタンスに対するライター役割またはリーダー役割が設定されたポリシーを割り当てます。

2 つのチームが、関連する 2 つのプロジェクトに携わっている

アカウントに 2 つの機能プロジェクトが存在します。プロジェクトで作業する開発者は、そのプロジェクトのすべてのリソースにアクセスする必要があります。アカウント管理者は、プロジェクトごとにアクセス・グループを作成し、各アクセス・グループのアクセス・ポリシーにアクセス管理タグを組み込むことで、アクセス権限を付与することができます。

柔軟性が重要です。IAM を利用して、さまざまなグループ間でリソースを共有させることができます。両方のプロジェクトに役立つリソースがあることに気付いたとします。リソースにタグを付け、既存の許可を利用して開発者にアクセス権限を付与することによって、2 つのプロジェクト間でリソースを共有させることができます。リソースがプロジェクトに必要なくなったら、該当のタグをサービス・インスタンスから外すだけで、開発者のアクセス権限を取り消すことができます。以下のビデオを確認し、アクセス管理タグを使用してアカウント内のリソースへのアクセスを管理する方法について、理解を深めてください。

動画の文字起こし

アカウント管理者は、タグを使用することで、アカウント内のリソースへのアクセスを大規模に集中管理できます。

例えば、2 つの機能プロジェクトがあるとします。1 つは、Watson 言語サービスおよびストレージで使用される soulmate というプロジェクトです。もう 1 つは、soulmate プロジェクトをサポートする Soul-FAQ というプロジェクトです。これは、Watson Assistant と Cloud Object Storage を使用します。

アカウント管理者としてアクセス管理タグを作成するには、IBM Cloud コンソールで「管理」、「アカウント」の順にクリックします。「タグ」ページで、「アクセス管理タグ」をクリックします。新規タグを作成するには、タグ名をコンマで区切って入力します。 soulmate プロジェクトのタグと soul-faq プロジェクトのタグの 2 つを作成しましょう。

リソース・リストに移動すると、アカウント上のすべてのリソースを参照できます。ここで、プロジェクトに関連するリソースにタグを付け、タグでフィルタリングして、アカウント全体にあるそれらのリソースを表示できます。

この時点では、開発者は、適切な許可がまだ割り当てられていないため、リソースを表示することができません。

アカウント管理者は、アクセス・グループとタグを組み合わせて使用することによって、プロジェクト・リソースにアクセスする許可を開発者に与えることができます。

アカウント管理者として、「管理」、「アクセス」の順にクリックし、「アクセス・グループ」を選択します。 soulmate プロジェクト用と FAQ 用の、2 つのアクセス・グループがセットアップされています。

soulmate 開発者のグループに、1 人の開発者がいます。ポリシーがセットアップされていないため、アカウント管理者がアクセス権限を割り当てる必要があります。そのためには、特定の属性に基づいてアカウント内のすべてのサービスを選択する必要があります。「アクセス管理タグ」を選択して、アカウント内で使用できるすべてのタグを表示します。 soulmate プロジェクト用のポリシーを作成するので、対応するタグを選択します。コンソールではプロジェクト soulmate タグが、3 つの別個のリソースにマップされています。

次に、いくつかの役割を選択します。グループ全体にビューアー役割を付与して、すべてのユーザーがリスト内のリソースを表示できるようにします。また、それらのサービスへのすべての機能アクセス権限も付与します。「割り当て」をクリックして、ポリシーを作成します。

開発者が 3 つのサービスを使用できるようになりました。 3 つのリソースすべてにアクセスでき、サブリソースがある場合はそれにもアクセスできます。

柔軟性が重要であるため、さまざまなグループ間でリソースを簡単に共有できるようにしました。例えば、IBM Cloud Object Storage がバックアップ用として有用で、FAQ プロジェクトに役立っていることに、アカウント管理者が気付いたとします。アカウント管理者は soulmate プロジェクトで IBM Cloud Object Storage を利用することにします。

アクセス管理タグを編集するだけです。プロジェクト soulmate タグを追加し、「保存」をクリックします。

リソース・リストで、Cloud Object Storage インスタンスに 2 つのアクセス管理タグが付加されていることを確認できます。

開発者は、元のリソースに加えて、Cloud Object Storage リソースも表示できるようになります。このインスタンスを、soulmate プロジェクトまたは FAQ プロジェクトにアクセスできるすべてのユーザーが使用できます。

Tone Analyzer サービスが soulmate プロジェクトで必要なくなったとします。 Tone Analyzer サービスからプロジェクト soulmate タグを外すと、そのサービス・インスタンスへの開発者のアクセス権限が取り消されます。アカウント管理者は「タグの編集」をクリックし、該当のタグをリストから削除することで、タグを取り外すことができます。

Tone Analyzer サービス・インスタンスが、開発者のリソースのリストに表示されなくなります。

アクセス管理タグを使用してアクセス権限を制御すれば、チームのプロジェクトが大きくなっても IAM ポリシーを更新する必要はありません。

3 つのチームが 3 つのプロジェクトに携わっている

アカウント内の何人かのユーザーは管理者です。管理者は新しいリソース・グループを作成し、それらに対するアクセス権限をユーザーに割り当てる必要があります。すべての IAM 対応サービスに対する管理者役割が設定されたポリシーを持つアクセス・グループにこれらのユーザーを割り当てます。

残りのユーザーには、それぞれのプロジェクトに関連付けられたリソース・グループのみに対するアクセス権限が必要です。アクセス・グループを使用して、それぞれのプロジェクトに関連付けられたリソース・グループとそのメンバーに対するさまざまな役割を割り当てます。つまり、インスタンスを作成する必要があるユーザーには、リソース・グループに対するエディター役割を割り当てます。さらに、それらのインスタンスを使用する必要があるユーザーには、リソース・グループ・メンバーに対するリーダー役割またはライター役割を割り当てます。

複数のリソース・グループがアカウント内に存在する

アカウント内のユーザーの何人かは、アカウント全体にわたるサービス Service A の管理者であり、そのサービスのすべてのインスタンスにアクセスするとともにインスタンスを作成する必要があります。これらのユーザーは、アカウント内の他のリソースに対するアクセス権限を必要としません。そこで、アクセス・グループを作成し、そこにアカウント・レベルで Service A に対する管理者役割を割り当て、さらに、アカウント内でこれらのユーザーによるインスタンスの作成先となるすべてのリソース・グループに対するビューアー役割を割り当てたポリシーを設定します。 リソースグループのみを選択し、リソースグループと、そのリソースグループの少なくともビューワロールを選択します。その後、それらのユーザーがアクセスする必要があるリソース・グループごとにこれを繰り返します。

特定のリソースに対するアクセス権限を 1 人のユーザーが必要としている

あるサービスの特定のリソースに対するアクセス権限 (例えば、IBM Cloud Object Storage 内のバケット Bucket A に書き込めること) のみを必要とする 1 人のユーザーがアカウントに含まれています。このユーザーは、アカウント内のリソース・グループを表示したり、他のサービスや Object Storage のこのインスタンス内の他のバケットにアクセスしたりする必要はありません。

Object Storage の特定のインスタンス内の Bucket A に対するライター役割をユーザーに割り当てます。役割の割り当てには、IAM UI を使用するか Object Storage UI を使用するかを選択できます。ここでは、サービス固有の UI を使用します。リソースのリストから選択できるからです。 IAM UI では、サービス・インスタンス・レベルを超えたリソースは表示されないため、それらのリソースにポリシーを割り当てるには、手動で CRN を入力する必要があります。

次のステップ

これで、リソース・グループのセットアップ方法、リソースの編成方法、アカウント内のアクセス・グループの作成方法が分かったので、アカウントへのユーザーの招待と、アクセス・グループに対するアクセス権限の割り当てを開始できるようになりました。既にアカウントにユーザーを招待している場合は、「ユーザー」ページに移動して、アクセス権限の割り当てを開始できます。

組織が企業ユーザー・ディレクトリーに基づいてユーザー・アクセスを管理することにした場合は、トラステッド・プロファイルを作成することから開始することができます。