コンテキスト・ベースの制限とは
コンテキスト・ベースの制限により、アカウント所有者および管理者は、ルールの基準に基づいて IBM Cloud® リソースに対するアクセス制限を定義し、適用することができます。 基準には、アクセス要求のネットワークロケーション、要求が送信されるエンドポイントタイプ、IDの多要素認証レベル、および場合によっては要求がアクセスしようとするAPIが含まれる。 これらの制限は、IDに基づく従来のIAMポリシーと連携し、もう1つの保護レイヤーを提供する。 IAM ポリシーとコンテキストベースの制限の両方がアクセスを強制するため、コンテキストベースの制限は、漏洩した、または誤管理された認証情報に直面しても保護を提供する。
コンテキスト・ベースの制限を作成するシナリオの例については、コンテキスト・ベースの制限を活用したリソースの保護のチュートリアルを参照してください。
セキュリティー戦略におけるコンテキスト・ベースの制限の実装について詳しくは、ソリューション・チュートリアル「 コンテキスト・ベースの制限の適用によるクラウド・セキュリティーの強化」を参照してください。
Rules
ルールは、 IBM Cloud リソースをコンテキストのセットに関連付ける:
- クラウド・リソースは、IAM アクセス・ポリシーと類似したリソース属性によって指定されます。
- コンテキストとは、ネットワーク・ゾーンとエンドポイント・タイプの組み合わせです。
設定したコンテキストは、関連するリソースの境界を定義する。
コンテキストベースの制限ルールで必要なリソース属性は accountId
と serviceName
である。 ルールの有効範囲として、アカウントと特定のサービスを設定する必要があります。
コンテキスト・ベースの制限のルールは以下のロジックによって適用されます。
- ルールによってアクセス権限が付与されるのは、少なくとも 1 つのルールのコンテキストがアクセスを許可している場合に限られます。
- 特定のリソースに対して複数のルールが適用可能である場合、アクセス権限が付与されるのは、適用可能なすべてのルールがアクセスを許可している場合に限られます。
- 特定のリソースに適用できるルールがない場合、アクセス権限は IAM ポリシーのみによって決まります。
IAM ポリシーとは異なり、コンテキスト・ベースの制限はアクセス権限を割り当てません。 コンテキスト・ベースの制限は、アクセス要求が、構成された許可されるコンテキストからのものであるかどうかを検査します。
コンソール、CLI、または API などのリソースにアクセスするために使用するインターフェースは、ルールがそのリソースにどのように適用されるかには影響しません。 この規則は、すべてのインターフェースにわたって同じ方法で適用され、クライアント IP アドレスに基づいています。
ルールの適用
作成時にルールを適用する方法を決定し、いつでもルール適用を更新することができます。
- 有効
- ルールを適用します。 選択したサービスによっては、 Activity Tracker Event Routing、拒否されたアクセスを監視できる。 各サービスの資料を参照して、コンテキスト・ベースの制限とどのように統合するかを確認してください。
- 無効
- アカウントリソースに制限はありません。 ルールを有効にする準備ができていない場合は、このオプションを選択します。
- レポートのみ
- 選択したサービスに応じて、ルールを適用せずにルールがアクセスに与える影響をモニターできます。 レポート専用モードでは、アカウント内のリソースへのアクセスはすべて Activity Tracker Event Routing に記録されます。 もし可能であれば、規則を施行する前に30日間モニタリングすることを推奨する。
レポート専用モードはすべてのサービスで使用できるわけではありません。コンテキスト・ベースの制限との統合方法については、各サービスの資料を参照してください。
有効化されたルールおよびレポート専用ルールの影響をモニターできます。 詳しくは、 コンテキスト・ベースの制約事項のモニター を参照してください。
ルールの範囲の定義
ルールの制限の有効範囲を絞り込むために保護する API を定義します。 このようにして、異なるアクセス要件を持つさまざまな API に対して細分化された保護を指定できます。
例えば、データ・プレーン API をターゲットにするルールを作成して、 Kubernetes クラスターからのみ、またはコンピュート・インフラストラクチャーが存在する場所からのみアクセスできるようにすることができます。 その後、組織の VPN の背後からのみアクセスできるように、クラウド・コンソールとの対話を保護するために、コントロール・プレーン API およびすべてのプラットフォーム API をターゲットとするルールを作成できます。
API によってルールのスコープを設定する機能をサポートするのは、一部のサービスのみです。
一部のサービスでは、リソース上のすべてのサービス API のアクションをデフォルトで制限できます。これには、サービスがサポートする可能性のある現在および将来のすべての API が含まれます。 または、特定の API を選択します。 例えば、 Kubernetes には、要求のコンテキストに基づいてアクセスを制限できるカスタム・サービス API があります。 各サービスの資料を参照して、それらがコンテキスト・ベースの制限とどのように統合されるかを確認してください。
選択されたサービスは、サービスがサポートする可能性がある現在および将来のすべてのプラットフォーム API を含む、すべてのプラットフォーム API を保護するためのルールのスコープ設定機能をサポートします。 ルールのスコープにプラットフォーム API を追加することで、リソース・プロビジョニング、サービス資格情報管理、アタッチ・タグなどのプラットフォーム操作が、定義したロケーションからのみアクセス可能になります。
ターゲット・サービスがサポートするすべてのサービスおよびプラットフォーム API を保護するために、コンテキスト・ベースの制限がデフォルトで設定されます。
コンテキスト
コンテキストは、リソースにアクセスできる場所を定義します。 コンテキストは、構成される許可されるエンドポイント・タイプとネットワーク・ゾーンからなります。
- コンテキストにネットワーク・ゾーンが含まれる場合、それらのいずれかのゾーン内から要求が作成された場合にのみ、アクセス権限が付与されます。
- コンテキストにサービス・エンドポイント・タイプが含まれる場合、それらのいずれかのタイプと一致する接続を介して要求が受信された場合にのみ、アクセス権限が付与されます。
- コンテキストに多要素認証(MFA)が含まれている場合、要求している ID が要求された MFA レベルと同じかそれ以上の MFA レベルを持つ場合にのみアクセスが許可される。
- コンテキストに複数の制限 (ゾーンとエンドポイント・タイプの両方など) が含まれている場合、アクセス権限が付与されるためには、すべての制限が満たされる必要があります。
ネットワーク・ゾーン
ネットワーク・ゾーンとは、アクセス要求が作成される場所の IP アドレスの許可リストを表します。 これは、以下の属性によって指定される 1 つ以上のネットワーク・ロケーションの集合を定義します。
- IP アドレス。これには、個々のアドレス、アドレス範囲、サブネットが含まれます。
- VPC
- サービス参照。これは、他の IBM Cloud® サービスからのアクセスを許可します。
IP アドレス
顧客は、トラフィックの送信元にできるようにする、既知の IP アドレスを指定できます。 指定された IP アドレス以外のものはすべて拒否されます。
VPC
コンテキスト・ベースの制限が課されたリソースにアクセスする必要がある VPC 内にデプロイされたアプリがある場合は、その VPC の IP アドレスをネットワーク・ゾーンに含めることができます。 そのためには、ネットワーク・ゾーンでターゲットVPCを選択し、そのネットワーク・ゾーンをルールに追加します。 こうすれば、VPCが使用するIPアドレスを見つける必要はない。 アクセスを受けるリソースは、要求が、許可された IP アドレスの集合からのものであることを確認します。
サービス参照
サービス参照は、サービスまたはサービスインスタンスのネットワーク上の位置を表す。 ネットワークゾーンにサービス参照を含めると、サービスの基礎となるIPアドレスを知らなくても、サービスに関連するIPアドレスが許可リストに追加されます。 クラウド・サービスのネットワーク・ロケーションは、コンテキスト・ベースの制限管理者にとっては未知であり、時間の経過とともに変化する可能性があるため、サービス・リファレンスは有用である。
サービス参照としてネットワーク・ゾーンに追加できるサービスのリストを以下に示します。
サービス | サービス・タイプ | service_name |
---|---|---|
すべてのアカウント管理サービス | アカウント管理 | iam-access-management |
IAM アクセス・グループ・サービス | アカウント管理 | iam-groups |
IAM ユーザー管理 | アカウント管理 | user-management |
Activity Tracker Event Routing | IAM有効| logdnaat | |
|
App Configuration | IAM有効| apprapp | |
|
カタログ管理サービス | IAM 対応 | globalcatalog-collection |
クラウド Block Storage for VPC IAM対応 | ||
クラウド Object Storage | IAM 対応 | cloud-object-storage |
Code Engine | IAM有効| codeengine | |
|
Databases for DataStax | IAM有効| databases-for-cassandra | |
|
Databases for EnterpriseDB | IAM有効| databases-for-enterprisedb | |
|
Databases for Elasticsearch | IAM有効| databases-for-elasticsearch | |
|
Databases for etcd | IAM有効| databases-for-etcd | |
|
Databases for MongoDB | IAM有効| databases-for-mongodb | |
|
Databases for MySQL | IAM有効| databases-for-mysql | |
|
Databases for PostgreSQL | IAM有効| databases-for-postgresql | |
|
Databases for Redis | IAM有効| databases-for-redis | |
|
Direct Link |IAM-enabled| directlink | |
||
Event Notifications | IAM有効| event-notifications | |
|
Event Streams | IAM有効| messagehub | |
|
Kubernetes Service / Red Hat OpenShift | IAM有効| containers-kubernetes | |
|
Messages for RabbitMQ | IAM有効| messages-for-rabbitmq | |
|
Secrets Manager |IAM-enabled| secrets-manager | |
||
VPC インフラストラクチャ サービス | IAM 対応 | |
Schematics | IAM有効| schematics | |
|
[ | ツールチェーン](/docs/ContinuousDelivery?topic=ContinuousDelivery-pipeline-subnet-ranges) |IAM対応| toolchain | |
表 1 では、 「すべてのアカウント管理サービス」 とは、表にリストされているアカウント管理タイプのサービスのグループ化を指します。 例えば、表1に記載されているアカウント管理サービスが2つある場合、 すべてのアカウント管理サービスにはそれらの2つのサービスが含まれます。 より多くのアカウント管理サービスがサービス参照として使用可能になると、 「すべてのアカウント管理サービス」 をサービス参照として指定するネットワーク・ゾーンには、新しく追加されたアカウント管理サービスが自動的に組み込まれます。
ルールでターゲットにするサービス・オファリングのサービス参照として追加するサービスについて詳しくは、各サービス・オファリングの資料を参照してください。
エンドポイント・タイプ
エンドポイント・タイプは、アクセス要求が受信される接続を表します。 これは、接続を受信するエンドポイントに対応します。 サービスでサポートされるすべてのエンドポイント・タイプからのアクセスか、特定のサービス・エンドポイント・タイプからのアクセスを許可することができます。
一般的な 3 つのエンドポイント・タイプは以下のとおりです。
- パブリック・エンドポイントは、どこからの要求でも受信できます。
- プライベート・エンドポイントは、 IBM Cloud® 内から発信されるほとんどのリクエストで利用可能です。
- ダイレクト・エンドポイントはBring-Your-Own-IPシナリオで使用され、一般にVPC内のリソースから発信されるリクエストに使用されます。
一部のエンドポイント・タイプは、選択したサービスでサポートされていない場合があります。
仮想プライベートエンドポイントにアクセスするには、CLIユーザーは ibmcloud login -a private.cloud.ibm.com --vpc
コマンドを使用してログインする必要があります。 詳細については 、「プライベートエンドポイントゲートウェイの作成(VPC使用時に必要 )」を参照してください。
多要素認証
多要素認証(MFA)は、ID とパスワード以外の別の認証要素を使用して ID を認証することを要求する。 MFAレベル要件を低く設定することで、その要件を満たす、または超えるユーザーに認証を許可することになります。 例えば、ルールでユーザーにMFAによる認証を要求している場合( LEVEL1 )、MFAを導入しているユーザー( LEVEL2 )は、 LEVEL2 が LEVEL1 のセキュリティ基準を上回っているため、依然として準拠していることになります。 以下のMFAレベルでは、各レベルの最低限必要なMFA要素が示されています。 詳細は 、 IBM Cloud の多要素認証 をご覧ください。
- LEVEL1: メールベースの多要素認証
- LEVEL2: TOTP MFA
- LEVEL3: U2F MFA
LEVEL1、 LEVEL2、 LEVEL3 のMFAに加えて、コンテキストベースの制限ルールでは、 IAM_ACCOUNT_SETTING
という値もサポートしています。これは、このルールのMFA値が、アカウントのMFA要件として定義したものすべてに一致することを意味します。 これにより、アカウントのMFA設定への変更は自動的にルールに適用されます。 詳細は、 MFAオプション を参照してください。
IAMの認証設定で IBMid セクションを持つユーザーに対してMFAからオプションが選択された場合、IAMからのMFA値はコンテキストベースの制限で LEVEL2 のMFAにマッピングされます。 非フェデレーション ユーザー が選択された場合でも、MFA はフェデレーション ユーザーと非フェデレーション ユーザーの両方に適用されます。
ルールでMFAを指定できるのは、一部のサービスのみである。
アクセス要件
ルール・アクションを実行するには、ターゲット・サービスで IAM ポリシーが割り当てられている必要があります。 ネットワーク・ゾーン・アクションを実行するには、コンテキスト・ベースの制限サービスに対する IAM ポリシーが割り当てられている必要があります。
サービスのコンテキスト・ベースの制限を作成するには、ルールを作成するサービスの管理者役割を持つ IAM ポリシーが割り当てられている必要があります。 例えば、インスタンスを保護するルールを作成する場合、そのインスタンスに管理者ロールが割り当てられている必要があります。 Key Protect インスタンスを保護するルールを作成する場合、そのサービスでは管理者ロールが割り当てられ Key Protect サービスではAdministrator ロール、コンテキストベースの制限サービスではViewer ロール以上が割り当てられている必要があります。
コンテキストベースの制限サービスのViewerロールは、ルールにネットワークゾーンを追加する権限を与える。
コンテキスト・ベースの制限の役割とアクション
ネットワークゾーンを管理するには、コンテキストベースの制限アカウント管理サービスの特定のロールを持つIAMポリシーを割り当てる必要があります。 以下の表に、アカウント管理に使用できるアクセス役割とアクションを示します。
役割 | アクション |
---|---|
ビューアー | ネットワーク・ゾーンの表示 |
エディター | ネットワーク・ゾーンの表示
ネットワーク・ゾーンの作成 ネットワーク・ゾーンの更新 ネットワーク・ゾーンの削除 |
管理者 | ネットワーク・ゾーンの表示
ネットワーク・ゾーンの作成 ネットワーク・ゾーンの更新 ネットワーク・ゾーンの削除 |
詳しくは、アカウント管理サービスのアクションおよび役割を参照してください。
ネットワーク・ゾーンを使用して、アカウント・レベルでアクセスを制限することもできます。 ネットワークゾーンを使用してアカウントレベルの制限を設定するには、 IBM Cloud コンソールで「 管理 」>「 IAM 」>「 設定 」と進み、ネットワークゾーンの名前を入力します。
対象サービスの役割と行動
ルールを管理するには、ルールを作成する対象のサービスの管理者役割を持つ IAM ポリシーが割り当てられている必要があります。 以下の表に、サービスに対して可能なアクセス役割とアクションを示します。
役割 | アクション |
---|---|
ビューアー | ルールを表示する |
エディター | ルールを表示する |
管理者 | 「ルールの表示」
「ルールの作成」 「ルールの更新」 「ルールの削除」 |
コンテキスト・ベースの制限と統合されたサービス
特定の IBM Cloud サービスは、コンテキスト・ベースの制限に統合されており、これらのサービスのみがそれらのリソースにルールを適用できます。 ルールが個々のサービスに適用される方法はサービスによって決定されるため、各サービスの資料を参照して、コンテキスト・ベースの制限がどのように適用されるかを理解してください。
サービス上で適切なアクセス権が付与されていれば、以下のサービスに対してコンテキスト・ベースの制限を作成できます:
サービス | サービス・タイプ | スコープを API に設定 | service_name |
---|---|---|---|
カタログ管理サービス | IAM対応 | ある | globalcatalog-collection |
コンテキストベース制限サービス | アカウント管理 | いいえ | context-based-restrictions |
IAM アクセス・グループ・サービス | アカウント管理 | いいえ | iam-groups |
IAM アクセス管理サービス | アカウント管理 | いいえ | iam-access-management |
IAM Identity Service | アカウント管理 | いいえ | iam-identity |
IAM ユーザー管理 | アカウント管理 | いいえ | user-management |
Activity Tracker Event Routing | IAM対応 | ある | logdnaat |
App Configuration | IAM対応 | いいえ | apprapp |
クラウド Object Storage | IAM対応 | いいえ | cloud-object-storage |
Code Engine | IAM対応 | いいえ | codeengine |
Container Registry | IAM対応 | いいえ | container-registry |
Databases for DataStax | IAM対応 | ある | databases-for-cassandra |
Databases for EnterpriseDB | IAM対応 | ある | databases-for-enterprisedb |
Databases for Elasticsearch | IAM対応 | ある | databases-for-elasticsearch |
Databases for etcd | IAM対応 | ある | databases-for-etcd |
Databases for MongoDB | IAM対応 | ある | databases-for-mongodb |
Databases for MySQL | IAM対応 | ある | databases-for-mysql |
Databases for PostgreSQL | IAM対応 | ある | databases-for-postgresql |
Databases for Redis | IAM対応 | ある | databases-for-redis |
Direct Link | IAM対応 | いいえ | directlink |
DNS Services | IAM対応 | いいえ | dns-svcs |
Event Notifications | IAM対応 | いいえ | event-notifications |
Event Streams | IAM対応 | いいえ | messagehub |
Key Protect | IAM対応 | いいえ | kms |
Kubernetes Service / Red Hat OpenShift | IAM対応 | ある | containers-kubernetes |
Messages for RabbitMQ | IAM対応 | ある | messages-for-rabbitmq |
Secrets Manager | IAM対応 | いいえ | secrets-manager |
Security and Compliance Center | IAM対応 | いいえ | compliance |
Transit Gateway | IAM対応 | いいえ | transit |
IBM Cloud® Virtual Private Cloud | IAM対応 | いいえ | is |
Schematics | IAM対応 | いいえ | schematics |
IAM 対応サービスに対して定義されているコンテキスト・ベースの制限は、作成や削除などのプラットフォーム・アクションには適用されません。 詳しくは、IAM の役割とアクションを参照してください。
より多くのサービスがコンテキスト・ベースの制限と統合されるにつれて、どのようなサービスが追加されるか、定期的にチェックしてください。
コンテキスト・ベースの制限
以下の表に、コンテキスト・ベースの制限の最大制限をリストします。 これらの制限は、コンテキスト・ベースの制限ルールまたはネットワーク・ゾーンを作成できるすべてのユーザーに適用されます。 詳しくは、コンテキスト・ベースの制限とは何ですか?を参照してください。
拡張された制限を必要とする特定のユース・ケースがある場合は、増加を要求できます。 詳しくは、アカウント制限の増加を参照してください。
リソース | 最大 |
---|---|
アカウント当たりのコンテキスト・ベースの制限ルール [1] | 4020 |
アカウント当たりのネットワーク・ゾーン | 500 |
ネットワーク・ゾーンごとの IP アドレス | 1000 |
規則ごとの IP アドレス | 1000 |
複数のネットワーク・ゾーンを含むコンテキスト・ベースの制限ルールには、最大 1000 個の IP アドレスを間接的に関連付けることができます。 例えば、2つのネットワークゾーンを含むルールでは、一方のゾーンには800個のIPアドレスがあり、もう一方には最大200個のIPアドレスがあるかもしれない。
アカウント内のルールの数を確認するには、 アカウントごとのルールの総数の表示 を参照してください。 アカウント制限の増加を要求するには、 ポリシーおよびルール共有制限の増加の要求 を参照してください。
結果整合性
コンテキストベースの制限は、多くのクラウドネイティブサービスに共通する、 最終的に一貫したパターンに従う。 その結果、コンテキスト・ベースの制限は、複数のグローバル・リージョンにわたって高可用性とパフォーマンスを維持します。 コンテキスト・ベースの制限ルールおよびネットワーク・ゾーンに対して行われた変更は、記録され、世界中に伝搬されます。 アクセス権限の変更は、伝搬プロセスが完了するまで (通常は数分以内) 有効にならない可能性があります。
-
IAMポリシーとコンテキストベースの制限ルールは、合わせて4020の制限を共有する。 ↩︎