ユーザー、サービス、ワークロードのIDタイプ

IBM Cloud は、連携ユーザー、サービスID、信頼されたプロファイル、およびセキュアなワークロード認証のためのAPIキーなど、複数のIDタイプをサポートしています。

ID の概念は、ユーザー ID、サービス ID とアプリ ID、ユーザー ID とサービス ID の API キー、トラステッド・プロファイル、およびリソース ID で構成されます。ユーザーは、IBMid、SoftLayer ID、App ID ユーザー ID、またはフェデレーテッド・ユーザー属性によって識別されます。

IBM Cloud IAMは、ポリシーを使用して、個々のアイデンティティまたはアイデンティティのグループにアクセス権を付与する。このポリシーは、ロールとスコープ付きリソースを利用することで、最小特権の原則を守りながら、ユーザーにアクセスを許可することを可能にする。アカウント所有者を除き、ユーザーIDはデフォルトでアクセス権を持たない。各アクセス・グラントは他のアクセス・グラントとは独立しており、権限を持つユーザーはコンソールやAPIを使ってリソースにアクセスできる。許可されるアクションは、お客様ニーズに応じて、単一のAPIまたはAPIのグループに対して行うことができる。アクセスは、お客様ニーズに応じて、リソースのグループに対して高レベルで付与することも、単一のリソースにスコープして付与することもできる。

非アクティブ ID のアクセス権限を削除すると、IBM Cloud リソースへの不正アクセスのリスクが軽減され、より効率的にアクセスを管理できるようになります。詳しくは、非アクティブ ID の識別を参照してください。

ユーザー

ユーザー ID は、個人がアカウント内でデジタル ID を必要とする場合に最適です。ユーザーはアカウントに招待され、アカウント内のリソースへのアクセス権限を付与されます。ユーザーは、IBMid、SoftLayer ID、App ID ユーザー ID、またはフェデレーテッド・ユーザー ID を使用してログインします。各ユーザーは、生成された ID (IAM ID と呼ばれる) によっても識別されます。

IAM ID には、ユーザーのプロバイダーを識別するためのレルム (IBMid や外部 ID プロバイダーなど) が常に含まれます。 IAM ID では、レルムの後に、固有 ID である一連の数字が続きます。例えば、IBMid を持つユーザーの IAM ID は、IBMid-20000AB1C のようになります。

IAM ID が最もよく使用されるのは、API を使用して他のユーザーにアクセス権限を割り当てる場合です。これらは、ユーザー、サービス ID、トラステッド・プロファイル、またはリソースを識別するために使用されます。 IAM ID は、コンソール、CLI、または API で使用されるときにトークンに組み込まれます。アクセス・ポリシーは、IAM ID を使用して定義されます。これが IAM トークンで検証できる ID であるためです。

IAM ID を確認するには、「管理」>「アクセス (IAM)」に進みます。「マイ・ユーザーの詳細」セクションで IAM ID を確認できます。他のユーザーの IAM ID を表示するには、「管理」>「アクセス (IAM)」>**「ユーザー」に進み、リストからユーザーの名前を選択して、「詳細」**をクリックします。

ユーザー API キー

IBM Cloud API キーは、ユーザーの ID に関連付けられた資格情報です。対象ユーザーに割り当てられているアクセス権限は、そのユーザーがメンバーとなっている複数のアカウントのポリシーに基づいて設定することができます。ユーザー API キー資格情報を使用して、API 呼び出しおよび CLI 呼び出しを行うことができます。ユーザー API キーは直接使用したり、トークンを生成するために使用したりできます。

ユーザー ID に関連付けられた API キーの使用について詳しくは、ユーザー API キーの管理を参照してください。

ユーザーを IBM Cloud に統合

IBM Cloud は、従業員が会社の認証情報で IBM Cloud にアクセスできるようにする2つのフェデレーション・オプションを提供しています。 IBMid とフェデレーションするか、 IBM Cloud App ID サービス・インスタンスを作成します。詳しくは、外部 ID プロバイダーからの認証の有効化を参照してください。

どちらのオプションも、ユーザーがアカウントメンバーであるか、信頼されたプロファイルを通じてアクセスする必要があります。 IBMid フェデレーションでは、アカウント所有者または管理者はユーザーを招待する必要があり、招待されたユーザーは承諾後にアクティブ・メンバーとなる。 App ID を使えば、ユーザーは招待なしに自動的にオンボードされる。どちらの場合も、連携されたユーザーは、割り当てられたアクセス権に基づいて、IAM対応のリソースやクラシック・インフラストラクチャーアクセスできる。

信頼されたプロファイルは、フェデレートされたユーザーを異なる方法で扱います。ユーザーの SAML-based IdP 属性はログイン時に評価され、信頼されたプロファイルの条件を満たしている場合、ユーザーは1つ以上のプロファイルを適用するよう促される。信頼されたプロファイルは、特殊なタスクのための時間制限付きアクセス（通常1～4時間）を許可し、セキュリティリスクを低減するための頻繁な認証チェックを可能にする。ユーザーは、オンボーディングなしで信頼関係を通じて自動的に追加される。ユーザーが会社を退職する際、ディレクトリ内の企業 ID を削除すると、 IBM Cloud アクセス権が失効します。

機能 ID

機能IDは、アプリケーションまたはサービスがデジタルIDを必要とし、IAM対応リソースまたはクラシック・インフラストラクチャーアクセスが必要な場合に、最も一般的に使用される。一部のサービスでは、サービス・インスタンス (Kubernetes Service など) の作成時に機能 ID が必要です。

機能 ID とは、ID プロバイダー (IdP) のユーザー・ディレクトリーに存在するが、特定のユーザーに関連付けられていないユーザー ID の一種です。機能 ID を作成するには、ユーザー・ディレクトリーに新規ユーザーを作成し、そのユーザーを IBM Cloud アカウントに招待する必要があります。

機能 ID は、Kubernetes Service クラスターなどのサービス・インスタンスを作成するために使用されます。この方法では、インスタンスは特定の個人にリンクされません。個人は会社を退職する可能性があり、それによってインスタンスの所有者がいなくなります。一般に、機能 ID は、IBM Cloud でサービス ID よりも多くのことを行うことができます。例えば、機能 ID には、ユーザー ID と同様に、アクセス・ポリシーを使用してサービスおよびアプリケーションへのアクセス権限を付与できます。

ユーザーの IBM Cloud API キーを作成し、機能 ID と関連付けることができます。サービスが他のサービスまたはアプリケーションと対話するためにユーザー API キーを必要とする場合は、機能 ID API キーを使用します。機能 ID と関連付けられている API キーを使用することによって、対象サービスで必要となるアクセス権限のみを提供できます。

アカウントオーナーとしてファンクショナルIDを使用している場合は、代わりに代替アカウント所有者の設定を検討してください。これはクラシック・インフラストラクチャーアカウント利用可能です。

サービス ID

サービス ID は、アカウントで使用されるもう 1 つのタイプの ID です。サービス ID は、サービスおよびアプリケーションに別個の ID を指定するために使用されます。サービス ID は、アプリケーションまたはサービスがデジタル ID を必要とし、IAM 対応リソースのみにアクセスする必要がある場合に最適です。 IBM Cloud サービスへのアクセスが必要なアプリケーションで使用されるサービス ID を作成できます。これにより、個人ユーザーの資格情報を使用する必要がなくなります。

サービス ID の API キー

また、アプリケーションを特定のサービスIDとして認証するために、サービスIDに関連付けられたAPIキーを作成することもできる。こうすることで、アプリケーションは特定のサービスIDに割り当てられたリソースにアクセスできる。サービス ID API キー資格情報を使用して、API 呼び出しおよび CLI 呼び出しを行うことができます。サービス ID に関連付けられた API キーの作成について詳しくは、サービス ID の API キーの管理を参照してください。

トラステッド・プロファイル

IAM 内の他の ID と同様に、トラステッド・プロファイルは、IAM ポリシーでアクセス権限が付与されるサブジェクトとして扱われます。

通常は、ユーザーがアカウントのリソースに対して操作を実行するには、そのユーザーの ID をアカウントに明示的に追加する必要があります。トラステッド・プロファイルを使用すると、ユーザーはアカウントに招待されなくてもアクションを実行できます。代わりに、ユーザーがログイン時にトラステッド・プロファイル ID を適用したときに、リソースに対するアクセス権限が自動的にユーザーに付与されます。トラステッド・プロファイルにマップできるのは、外部 IdP から統合されたユーザーだけです。ログイン時に SAML ベースの属性を評価することで、ユーザー ID に適用できるプロファイルが判別されます。

同様に、サービス ID を作成し、API キーを生成し、そのキーを保管および検証するアプリケーションを取得する代わりに、コンピュート・リソースのトラステッド・プロファイルを作成して、コンピュート・リソースで実行されるすべてのアプリケーションに対してきめ細かい許可を定義することができます。コンピュート・リソースは、トラステッド・プロファイルの一部として使用される際には ID になります。コンピュート・リソースとの信頼関係は、リソース属性に基づく条件によって、または特定のリソースへの直接リンクを作成することによって確立されます。

また、あなたのアカウントオペレーションを実行する必要がある IBM Cloud サービスとの信頼関係を確立することもできる。または、Trusted Profielsを使用して、他のアカウントサービスIDにアクセスアカウント与えます。

リソース ID

IAM における ID コンセプトの最後のピースは、 IBM Cloud リソースである。リソースはクラウド・リソース名特定のクラウド・リソースのグローバル固有 ID。これは、バージョン、インスタンス、タイプ、ロケーション、スコープによって階層的にセグメント化された、コロン区切りの値です。（CRN）によって識別される。カタログから作成されるすべてのリソースは、CRN によって識別されます。これらの CRN は、IAM のサービス間許可に使用されます。さらに、API の使用時に CRN を使用して特定のリソースへのアクセス権限を割り当てます。詳細については、クラウド・リソース名と、サービス間のアクセスを許可する権限の使用を参照してください。