IBM Cloud における ID
IBM Cloud® IAM の 2 つの主要な概念は、ID およびアクセス管理です。 詳しくは、以下のセクションとアクセス管理の概念を参照してください。
ID の概念は、ユーザー ID、サービス ID とアプリ ID、ユーザー ID とサービス ID の API キー、トラステッド・プロファイル、およびリソース ID で構成されます。 ユーザーは、IBMid、SoftLayer ID、App ID ユーザー ID、またはフェデレーテッド・ユーザー属性によって識別されます。
IBM Cloud IAM は、ポリシーを使用して個々の ID または ID のグループにアクセス権限を付与します。 これらのポリシーにより、ユーザーは、役割および有効範囲が設定されたリソースを使用することで、最小特権の原則に従いながらアクセス権限を付与することができます。 アカウント所有者を除き、ユーザー 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 には、企業 ID プロバイダー (IdP) を統合するための方法が 2 つあります。これらの方法により、従業員が会社のユーザー名とパスワードを使用して IBM Cloud にアクセスできるようになり、ログインが簡素化されます。 IBMidとの統合を行うことも、 IBM Cloud App ID サービス・インスタンスを作成してユーザーを IBM Cloud アカウントに統合する方法として使用することもできます。 詳しくは、外部 ID プロバイダーからの認証の有効化を参照してください。
どちらの統合オプションでも、操作を実行するには、ユーザーがアカウントのメンバーであるか、トラステッド・プロファイルによってアカウントにアクセスできる必要があります。 トラステッド・プロファイルを構成しない場合は、アカウントの所有者または管理者が、個々の IBMid を IBM Cloud アカウントに招待する必要があります。 招待された IBMid が招待を受け入れた場合にのみ、そのユーザーがアクティブ・ユーザーとしてアカウントに追加されます。 App ID の場合は、各ユーザーをアカウントに招待しなくても、ユーザーが自動的に IBM Cloud にオンボーディングされます。 どちらのタイプの連携でも、IAM 対応リソースやクラシック・インフラストラクチャーなど、プラットフォームにアクセスできるアクティブな IBM Cloud アカウント・ユーザーは、割り当てられているアクセス権限に応じてすべて異なります。
トラステッド・プロファイルでは、異なる方法でフェデレーテッド・ユーザーが扱われます。 お客様が企業 IdP を統合した場合、その IdP のユーザーは、標準的なユーザーと見なされるアカウントには追加されません。 そうではなく、SAML ベースのユーザーの IdP 属性がログイン時に評価され、トラステッド・プロファイルのすべての条件を満たしていれば、1 つ以上のトラステッド・プロファイルの適用を求めるプロンプトがユーザーに表示されます。 トラステッド・プロファイルは、限定された期間 (例えば、1 時間から 4 時間) だけ、特殊な特定のタスクを実行するために必要なアクセス・レベルをユーザーに付与します。 時間ベースのアクセス権限によって頻繁に認証検査が行われるので、セキュリティー・リスクを軽減できます。 これらのタスクは普通、日常業務で意図せずに行うことがないようにすべき重要なタスクです。 ユーザーは IBM Cloud にオンボードする必要はなく、信頼関係を介して自動的に追加されます。 ユーザーが退職した場合は、そのユーザーの企業 ID をディレクトリーから削除できます。これにより、IBM Cloud へのアクセス権限が取り消されます。
機能 ID
アプリケーションやサービスがデジタルIDとIAM対応リソースまたはクラシックインフラストラクチャリソースへのアクセスを必要とする場合、機能IDが最も一般的に使用されます。 一部のサービスでは、サービス・インスタンス (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 に関連付けられた API キーを作成して、特定のサービス ID としてアプリケーションを認証することもできます。 これにより、アプリケーションは、その特定のサービス ID に割り当てられたリソースにアクセスできます。 サービス ID API キー資格情報を使用して、API 呼び出しおよび CLI 呼び出しを行うことができます。 サービス ID に関連付けられた API キーの作成について詳しくは、サービス ID の API キーの管理を参照してください。
トラステッド・プロファイル
IAM 内の他の ID と同様に、トラステッド・プロファイルは、IAM ポリシーでアクセス権限が付与されるサブジェクトとして扱われます。
通常は、ユーザーがアカウントのリソースに対して操作を実行するには、そのユーザーの ID をアカウントに明示的に追加する必要があります。 トラステッド・プロファイルを使用すると、ユーザーはアカウントに招待されなくてもアクションを実行できます。 代わりに、ユーザーがログイン時にトラステッド・プロファイル ID を適用したときに、リソースに対するアクセス権限が自動的にユーザーに付与されます。 トラステッド・プロファイルにマップできるのは、外部 IdP から統合されたユーザーだけです。ログイン時に SAML ベースの属性を評価することで、ユーザー ID に適用できるプロファイルが判別されます。
同様に、サービス ID を作成し、API キーを生成し、そのキーを保管および検証するアプリケーションを取得する代わりに、コンピュート・リソースのトラステッド・プロファイルを作成して、コンピュート・リソースで実行されるすべてのアプリケーションに対してきめ細かい許可を定義することができます。 コンピュート・リソースは、トラステッド・プロファイルの一部として使用される際には ID になります。 コンピュート・リソースとの信頼関係は、リソース属性に基づく条件によって、または特定のリソースへの直接リンクを作成することによって確立されます。
また、アカウントで操作を実行する必要がある IBM Cloud サービスとの信頼を確立 することもできます。 または、信頼できるプロファイルを使用して、アカウント内の別のアカウントからの サービス ID にアクセス権限を付与します。
リソース ID
IAMにおけるアイデンティティコンセプトの最終的な要素は、 IBM Cloud リソースであり、 クラウドリソース名特定のクラウド・リソースのグローバル固有 ID。 これは、バージョン、インスタンス、タイプ、ロケーション、スコープによって階層的にセグメント化された、コロン区切りの値です。 （CRN）によって識別されます。 カタログから作成されるすべてのリソースは、CRN によって識別されます。 これらの CRN は、IAM のサービス間許可に使用されます。 さらに、API の使用時に CRN を使用して特定のリソースへのアクセス権限を割り当てます。 詳しくは、 クラウド・リソース名 および 許可を使用したサービス間のアクセス権限の付与 を参照してください。
詳しくは、クラウド・リソース名および 許可を使用したサービス間のアクセス権限の付与を参照してください。