IBM Cloud IAM の概念の他のクラウド・プロバイダーへのマッピング
ID およびアクセス管理 (IAM) は、ユーザーを安全に認証し、クラウド・リソースへのアクセスを提供する目的で使用します。 クラウド・プロバイダー間の IAM は、認証およびアクセスを保護するための一貫した方法ですが、各クラウド・プロバイダー内の概念とその適用方法は異なる場合があります。 以下の表の情報を参照すると、IBM Cloud IAM の概念と、他のクラウド・プロバイダーの概念の関連性または比較を確認できます。これにより IBM Cloud にスムーズにオンボーディングできます。
IAM の概念の比較
IBM Cloud IAM の概念と、Amazon Web Services (AWS)、Google Cloud Platform、Microsoft Azure などの他のクラウド・プロバイダーの概念をマッピングした次の表は、厳密な 1 対 1 の対応ではない場合があります。 ただし、別のプロバイダーの特定の概念に精通している場合は、このマッピングにより、IBM Cloud の最も近い関連概念を見つけることができます。
IBM Cloud での概念 | IBM Cloud の説明 | AWS | Azure | Google Cloud Platform |
---|---|---|---|---|
ID | ユーザーおよびサービス ID | ユーザー、グループ、およびロール | ユーザー、グループ、サービス・プリンシパル、管理対象 ID | ユーザー・アカウントおよびサービス・アカウント。 サポートされる ID タイプ: Google アカウント、サービス・アカウント、Google グループ、G Suite ドメイン、Cloud ID ドメイン |
ユーザー | IAM の外部で管理される。 ユーザーは、IBM Cloud で iam_id 値を使用して一意に識別されるが、IBMid、App ID、または SoftLayer から取得される可能性がある。 | IAM で管理される。 ID は外部 ID 管理システムに統合される。 | Active Directory で管理される | IAM の外部で管理される。 ID は外部 ID 管理システムに統合される。 |
サービス ID | アプリまたはサービスの ID。 | アプリに割り当てられる役割 | ユーザーが割り当てた ID | サービス・アカウント |
API キー | ユーザー ID またはサービス ID に使用される資格情報 | アクセス・キー | API キー | API キー |
アクセス・グループ | ユーザーとサービス ID の編成方法。グループのすべてのメンバーに同じアクセス権限が割り当てられる。 | グループ、役割 | Active Directory グループ | Google グループ |
トラステッド・プロファイル | SAML 属性に基づいてフェデレーテッド・ユーザーにアクセス権限を割り当てたり、コンピュート・リソースで実行されるすべてのアプリケーションにアクセス権限を割り当てたりする方法。資格情報の管理やローテーションが不要。 | 役割 | マネージド ID | ワークロード ID |
ポリシー | サブジェクト、ターゲット、および役割で構成されるアクセス権限の割り当て。 | ポリシー | 役割の割り当て | ポリシー |
ポリシー・サブジェクト | ユーザー、サービス ID、またはアクセス・グループ | IAM ユーザー、グループ、または役割 | セキュリティー・プリンシパル | リソース |
役割 | 役割は、アクセス・ポリシーを作成するためのビルディング・ブロックとして使用される、特定のリソースに対するアクションの集合である。 | AWS が管理するポリシー | 役割の定義 | 事前定義された役割 |
カスタム・ロール | ユーザーが選択したアクションのみを含む、ユーザー定義の名前付き役割。 | ユーザー管理のポリシー | カスタム・ロール | カスタム・ロール |
アクション | プラットフォームまたはサービスのコンテキスト内での実行が許可されているもの | アクション | 権限 | 権限 |
リソース | アクセス・ポリシーのターゲット | リソース | リソース | リソース |
リソース・グループ | IAM 対応サービスの論理組織コンテナー | タグ | リソース・グループ | プロジェクト |
パブリック・アクセス | 特定のリソースへのパブリック・アクセスが、「パブリック・アクセス」と呼ばれるデフォルトのアクセス・グループを介して有効になる。 この機能はアカウントごとに無効にできる。 | 特定のリソースに対して有効にでき、アカウント・レベルまたはバケット・レベルで無効にできる Amazon S3 の機能。 | パブリック読み取りアクセスを、特定のアカウント・タイプまたはリソースに対して有効にできる。 ストレージ・アカウント・レベルまたはコンテナー・レベルで無効にできる。 | Google には、すべてのサービス・アカウントと、Google アカウントで認証されたすべてのユーザーを表す allAuthenticatedUsers という ID があり、これに対してアクセス権限を付与することもできる。 |
監査 | 監査 IBM Cloud Activity Tracker Event Routing | AWS CloudTrail による監査 | Azure ロギングおよび監査アクティビティーのログ | 監査ロギングによる監査 |
エンタープライズ管理 IAM | IBM Cloud マルチアカウント環境のアクセスとセキュリティーの設定を一元的に管理します。 | AWS コントロール・タワー |
ユーザーを 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 へのアクセス権限が取り消されます。