IBM Cloud IAM の仕組み

ユーザー管理

一元化されたユーザー管理により、プラットフォーム・サービスおよびクラシック・インフラストラクチャー・サービスの両方に関して、アカウント内のユーザーを追加したり削除したりすることができます。 一度に複数のユーザーまたはサービス ID のアクセス権限を割り当てるタスクを素早く簡単に行えるようにするために、アクセス・グループ内のユーザーのグループを編成することができます。

微細化されたアクセス制御

ユーザー、サービス ID、アクセス・グループ、トラステッド・プロファイルのアクセス権限は、ポリシーによって定義されます。 ポリシー内で、アクセス権限の有効範囲は、リソース・グループ内の一連のリソース、単一リソース、アカウント管理サービスに割り当てることができます。 ターゲットが設定された後、アクセス役割を選択することによって、ポリシーの対象に許可されるアクションを定義できます。 役割は、アカウント内のプラットフォーム管理タスクか、サービスの UI へのアクセスか、API 呼び出しの実行かにかかわらず、ポリシーのサブジェクトがポリシーのターゲットに対してアクションを実行するために付与されるアクセス・レベルを調整する方法を提供します。

また、時間ベースの条件をポリシーに追加することもできます。時間ベースの条件は、ポリシーがいつアクセス権限を付与するか、アカウント内のリソースへの一時アクセス権限を付与するかどうか、または繰り返し時間枠内でアクセス権限を許可するかどうかを定義します。 詳しくは、 時間ベースの条件によるアクセスの制限 を参照してください。

アクセス・グループでアクセス管理を合理化

グループへのアクセス権限を割り当てることにより、アクセス・グループに編成されているユーザー、サービス ID、またはトラステッド・プロファイルのグループに対してアクセス権限を素早く簡単に割り当てます。また、アカウント・リソースへのアクセス権限を付与または拒否するために、必要に応じて ID を追加または削除します。 アクセス・グループを使用すると、アカウント内で最小限の数のポリシーを管理するだけで済みます。 詳細については、アクセス・グループのセットアップを参照してください。

資格情報の管理が不要になるトラステッド・プロファイル

企業ディレクトリーからの SAML 属性に基づく条件を使用して、フェデレーテッド・ユーザーにアカウントへのアクセス権限を自動的に付与します。 また、トラステッド・プロファイルを使用して、計算リソースで実行されているアプリケーションに対して微細化された許可をセットアップすることもできます。 この方法では、計算リソースのサービス ID や API キーを作成する必要はありません。 プロファイルをアクセス・グループに追加するか、個々のポリシーを割り当てることによって、そのプロファイルへのアクセス権限を割り当てます。また、必要に応じて条件を追加または削除して、アカウント・リソースへのアクセス権限を付与または拒否します。 トラステッド・プロファイルを使用すると、複数の IBM Cloud 資産に対するアクセス権限のライフサイクルを一元的に管理できます。 詳しくは、トラステッド・プロファイルの作成を参照してください。

エンタープライズ内のアクセスを一元的に管理するためのエンタープライズ管理 IAM テンプレート

企業は、エンタープライズ管理の IAM テンプレートを使用することで、アクセス管理を容易に拡張し、組織全体で一貫性のあるアカウント・セキュリティー設定を確保できます。 企業全体で割り当てるアクセス・グループ、トラステッド・プロファイル、アカウント・セキュリティー設定などの IAM リソースのテンプレートを作成できます。 IAM テンプレートを子アカウントに割り当てると、選択した子アカウントにエンタープライズ管理の IAM リソースが作成されます。

例えば、同じ権限を必要とするすべての子アカウントに特定のジョブ・ロールが存在する場合があります。 必要なアクセス・ポリシーを使用してアクセス・グループ・テンプレートを作成し、そのテンプレートをエンタープライズ内のすべての子アカウントに割り当てることができます。 これにより、ポリシーのドリフトが削減され、そのジョブ・ロールを持つユーザーは、各アカウントで必要なアクセス権限のみを持つことが確実になります。

詳しくは、 エンタープライズ管理 IAM の仕組み を参照してください。

ユーザー認証のための API キー

鍵のローテーション・シナリオをサポートするためにユーザー用に複数の API 鍵を作成できます。また、複数のサービスにアクセスするために同じ鍵を使用できます。IBM Cloud API キーを使用すると、2 要素認証またはフェデレーテッド ID を使用するユーザーは、コマンド・ラインからコンソールへの認証を自動化できます。 クラシック・インフラストラクチャー API へのアクセスに使用できるクラシック・インフラストラクチャー API キーをユーザー当たり 1 つ持つこともできますが、IBM Cloud API キーを使用することで同じ API にアクセスできるため、これは必須ではありません。 詳しくは、『API キーについて』を参照してください。

サービス ID

ユーザー ID がユーザーを識別するのと同様の方法で、サービス ID はサービスまたはアプリケーションを識別します。 これは、IBM Cloud サービスでの認証のためにアプリケーションで使用できる ID です。 アプリケーションで許可されるアクセス・レベルをサービス ID を使用して制御できるように各サービス ID にポリシーを割り当てることができ、認証を有効にするために API キーを作成することができます。 詳しくは、サービス ID の作成と処理を参照してください。

Infrastructure-as-a-Service (IaaS) は、サービス ID によって行われる操作をサポートしません。 アカウントに IaaS および PaaS が含まれている場合、操作が IaaS への API 呼び出しに依存していると、サービス ID によって作成された管理機能が意図したとおりに機能しない可能性があります。 IaaS を含むアカウントでは、アカウント管理者が管理機能を完了していることを確認してください。 例えば、機能 ID は管理機能に使用できます。 場合によっては、IBM サポートが、IaaS と PaaS の両方にまたがるいくつかの管理機能を支援できることがあります。

多要素認証

アカウント内のすべてのユーザーまたは SSO を使用しない非フェデレーテッド ID を持つユーザーのみに対して、多要素認証 (MFA) を要求できます。 IBMid を持つユーザーはすべて時間ベースのワンタイム・パスコード (TOTP) MFA 要素を使用します。別のタイプの ID を使用するユーザーは、個々に TOTP、セキュリティーのための質問、または外部認証要素を使用できるように構成する必要があります。 詳しくは、『多要素認証のタイプ』を参照してください。

サービス間の許可

あるサービスに別のサービスへのアクセス権限を提供する必要があるシナリオでは、サービス間の許可を使用してポリシーを作成します。 詳しくは、許可を使用した、サービス間のアクセス権限の付与を参照してください。

関連するアクセス管理制御

IAM は、 IBM Cloudでの ID およびアクセス管理の基盤ですが、コンテキスト・ベースの制限付きで IAM アクセス制御を構築することで、セキュリティー戦略を拡張できます。 これらの制限は、ID に基づく従来の IAM ポリシーと連携して、追加の保護レイヤーを提供します。 詳しくは、コンテキスト・ベースの制限とは何ですか?を参照してください。