きめ細かな資源ターゲティング

IAMポリシーを使えば、複数の粒度でリソースをターゲットにできる：

アカウントアクセス

アカウント全体にわたって、特定のタイプのすべてのリソースへのアクセスを許可します。

リソース・グループ・アクセス権限

特定のリソースグループ内のリソースへのアクセスを制限する。

サービスインスタンスへのアクセス

特定のサービスインスタンスへのアクセスを制限する。

リソースレベルのアクセス

特定の Object Storage バケットや特定のデータベースなど、サービス内の個々のリソースへのアクセスを制御する。

この柔軟性により、権限を過剰に割り当てることなく、必要なレベルのアクセス権を正確に付与することができます。

正確な役割分担

IBM Cloud IAMは、きめ細かなアクセスを可能にする2種類の 定義済みロールを 提供する：

また、組織独自の要件に合わせて特定のアクションを組み合わせた カスタムロールを作成し、ユーザーが必要な権限だけを持つようにすることもできます。

属性ベースの条件

IAMは、時間ベースとコンテキストベースの条件をサポートし、制御のレイヤーをもう1つ追加する：

• 営業時間のみなど、特定の時間帯に アクセスを制限するための時間ベースの条件
• IPアドレス範囲またはネットワークゾーンに基づいて アクセスを制限するネットワークベースの条件
• アクセス制御のためのリソース属性 リソースタグ、ロケーション、その他の属性に基づく

これらの条件により、最小特権の原則を維持しながら、さまざまなシナリオに適応する動的なアクセスポリシーを実装することができます。

ゼロアクセスから始める

IBM Cloud では、アクセス・ポリシーで明示的に付与するまで、ユーザーとサービスIDはデフォルトでパーミッションを持たない。 このデフォルト拒否のアプローチは、アクセスが偶発的にではなく、意図的に許可されることを保証する。 新規ユーザーをオンボーディングする際には、アクセスする必要のある特定のリソースを特定し、実行する必要のある最小限のアクションを決定し、それらの特定の権限を提供するロールとポリシーのみを割り当てます。

役割ベースのアクセスにはアクセスグループを使用

アクセス・グループは、最小特権を大規模に実装する強力な方法を提供する。 個々のユーザーにポリシーを割り当てるのではなく、特定の職務や責任を表す アクセスグループを作成 し、そのグループに適切なポリシーを割り当てます。

例えば、次のようなアクセスグループを作成することができる：

データベース管理者

特定のリソースグループのデータベースインスタンスを管理するためのアクセス。

アプリケーション開発者

開発環境におけるアプリケーションのデプロイと管理へのアクセス。

セキュリティ監査員

セキュリティおよびコンプライアンスリソースへの読み取り専用アクセス。

請求管理者

請求情報の閲覧・管理へのアクセス

このアプローチは、属性ベースのポリシーの柔軟性を維持しながら、ロールベースのアクセス制御のシンプルさを提供します。 ユーザーの役割が変更された場合、個々のポリシーを修正するのではなく、適切なアクセス・グループに追加または削除するだけです。

リソース・グループ・セグメンテーションの実装

環境、アプリケーション、チーム、またはその他の論理的な境界に基づいて、リソースをリソースグループに編成します。 このセグメンテーションによって、必要以上に広い権限を与えることなく、適切なアクセスを割り当てることが容易になる。

例えば、次のような個別のリソースグループを作成することができる：

• 開発環境、ステージング環境、本番環境
• さまざまなアプリケーションやプロジェクト
• 異なるチームまたは部門
• 共有サービスとインフラ

アクセス・ポリシーをリソース・グループに合わせることで、開発者は開発リソースにフル・アクセスできるが、本番用リソースには読み取りアクセスしかできないようにしたり、あるチームが別のチームのリソースを誤って変更できないようにすることができます。

職務分掌の原則を適用する

重要な機能をユーザーや役割ごとに分け、一人のユーザーが機密業務を完全にコントロールできないようにする。 たとえば、リソースを作成する能力と削除する能力を分けたり、 アカウント管理サービスの管理者アクセス権を持つユーザー数を制限したりします。

アクセスを定期的に見直し、監査する

IBM Cloud には、アクセスを定期的に見直し、監査するのに役立つツールがいくつか用意されています：

アクセスレポート

各ユーザがアカウント全体でどのようなアクセス権を持っているかを示すレポートを作成できます。 詳しくは、 リソースへのアクセスを監査するを 参照のこと。

非アクティブ・ポリシーの識別

最近使われておらず、もはや不要かもしれないポリシーを特定する。 詳しくは、非アクティブ ID の識別を参照してください。

アクティビティー・トラッキング

誰がリソースにアクセスし、どのようなアクションを実行しているかを監視する。 IAMとコンテキストベースの制限のためのイベントのトラッキングの詳細については、 Observabilityセクションを 参照のこと。

ポリシー監査ログ

アクセスポリシーの経時的な変更を追跡する。 詳細については、 IAMのアクティビティ追跡 イベントを参照してください。

定期的なアクセス・レビューのスケジュールを組み、ユーザーが現在使用しているアクセス権をまだ必要としていることを確認し、役割を変更したユーザーや組織を離れたユーザーのアクセス権を削除し、使用されていないポリシーや過度に広範なポリシーを特定して削除し、職務の変更を反映してポリシーを更新する。

コンピュート・リソースに信頼されたプロファイルを使用する

コンピュート・リソース上で実行されるアプリケーションとワークロードについては、APIキーでサービスIDを作成する代わりに、信頼されたプロファイルを使用する。 信頼されたプロファイルは、クレデンシャルを管理することなく、きめ細かな認可を提供し、コンピュート・リソースが削除されると自動的にアクセスを取り消します。 詳細については、「 連携ユーザーおよびワークロードの信頼済みプロファイル 」を参照してください。

コンテキストに基づく制限の実装

IAMポリシーとコンテキストベースの制限を組み合わせて、ネットワークレベルの制御を追加する。 コンテキストベースの制限では、ネットワークゾーンを定義し、特定のIPアドレスへの管理アクセスを制限したり、パブリックネットワークからの機密データへのアクセスを防止するなど、リクエストのネットワークコンテキストに基づいてアクセスを制限することができます。 詳しくは、 コンテキストベースの制限を 参照のこと。

企業管理型IAMテンプレートの作成

IBM Cloud エンタープライズを使用している組織では、 エンタープライズ管理 IAM テンプレートを 使用して、複数のアカウントまたがるアクセス管理を標準化する。 テンプレートを使用すると、アクセスグループ、信頼済みプロファイル、およびセキュリティ設定を一元的に定義し、 アカウント間で一貫して適用できます。

このアプローチを使用することで、最小特権アクセス戦略が企業内のすべてのアカウント一貫して適用されるようにすることができます：

• セキュリティ・ポリシーは企業全体で一律に適用される。
• コンプライアンス要件は一貫して満たされている。
• アクセス管理は一元化により簡素化される。
• 変更は複数のアカウント効率的に展開できる。
• テンプレートを使用して適用されたリソースは、 アカウントユーザーによって不変であるため、アクセスやセキュリティ設定のドリフトを防ぐことができます。