ベスト・プラクティス

アカウントで許可されるポリシーの合計数には制限があります。 この制限に達しないようにするため、また、アカウント内の ID (ユーザー、サービス ID、またはトラステッド・プロファイル) のアクセス管理に費やす時間を短縮するために、いくつかの戦略を使用できます。

• 最小限の特権を付与するという原則に従い、必要なアクセス権限のみを割り当てます。 こうすることで、アカウント内の ID のアクションを、許可したアクションのみに制限することができます。 例えば、アカウント所有者が資格情報を共有するのではなく、アカウントの下のすべてのリソースに対する_管理者_と_マネージャー_のアクセス権限をアカウント所有者にデフォルトで付与し、アカウントと各サービス・インスタンス (および関連する鍵) へのアクセス権限を必要とするユーザーに新しいポリシーを作成します。
• リソースをリソース・グループに追加することによって、必要なポリシーの数をさらに少なくすることができます。 例えば、アカウント内の特定のリソースを使用するプロジェクトで作業するチームがあるとします。 そのチームのメンバーを、特定のリソース・グループのリソースへのアクセス権限のみを割り当てるポリシーを設定したアクセス・グループまたはトラステッド・プロファイルに追加します。 そのようにすれば、チーム・メンバーごとにそれぞれのリソースに対するポリシーを割り当てる必要はありません。 きめ細かくアクセス権限を割り当てる方法について詳しくは、単一の鍵に対するきめ細かいアクセス権限の割り当てを確認してください。
• アクセス・グループを使用して、同じレベルのアクセス権限を必要とする ID のアクセス管理を合理化します。 特定のポリシーを定義したアクセス・グループをセットアップし、そのグループに ID を追加します。 後にグループ・メンバーにさらにアクセス権限が必要になった場合には、そのアクセス・グループに新しいポリシーを定義します。
• アクセス管理タグを使用して、アカウント内のリソースに対するアクセス権限を大きな規模で制御します。 特定のタグが付いているリソースに対するアクセス権限のみを割り当てることによって、定義したポリシーを何度も更新する手間を省くことができます。 詳しくは、タグを使用したリソースに対するアクセス権限の制御を参照してください。
• トラステッド・プロファイルを使用することによって、フェデレーテッド・ユーザーとコンピュート・リソースにアカウントへのアクセス権限を自動的に付与することができます。 この方法では、ログイン時に SAML ベースの属性を評価してフェデレーテッド・ユーザーが適用できるプロファイルを判別することにより、1 つ以上のトラステッド・プロファイルにフェデレーテッド・ユーザーをマップすることができます。 コンピュート・リソースにトラステッド・プロファイルを使用することによって、アプリケーションを実行するための資格情報の保管や、資格情報の管理とローテーションの操作を回避することができます。 また、トラステッド・プロファイルをアクセス・グループに追加することで、既に作成したポリシーのセットを活用することもできます。
• アクセス制御を管理し、鍵リソースを削除できるユーザーを定期的に監査します。 高いレベルの権限を持つユーザーによる誤操作や悪用でアカウント、サービス・インスタンス、サービス・インスタンスの鍵で保護されているデータが被害を受ける可能性があるので、そのような役割を持つユーザーを監査して、適切なアクセス権限を維持してください。 新規作成した鍵、鍵リング、またはサービス・インスタンスは、デフォルトで、既存の役割の定義の対象になることに留意してください。 インスタンスの_マネージャー_として割り当てられている新しいユーザーが新しい鍵にアクセスしたり変更したりしてはならない場合は、その制限を具体的に割り当てる必要があります。これは、インスタンス・マネージャーがデフォルトでインスタンス内のすべての鍵 (鍵を削除する機能を含む) にアクセスできるためです。

優れたアクセス・グループ戦略とは

アクセス・グループとは、同じ IAM アクセス権限を付与できるユーザー、サービス ID、およびトラステッド・プロファイルをグループ化した組織です。 1 つのアクセス・グループ内の ID はすべて、同じアクセス権限を継承します。

リソース・グループとそれに含まれるリソースに対するアクセス権限を割り当てる論理的方法は、必要なアクセス権限レベルごとにアクセス・グループを 1 つ作成することです。 その後、各アクセス・グループを、前に作成したリソース・グループにマップできます。 例えば、CustApp プロジェクトへのアクセスを制御するために、以下のアクセス・グループを作成できます。

• Auditor-Group
• Developer-Group
• Admin-Group

Auditor-Group には、CustApp-Test リソースおよびリソース・グループと CustApp-Prod リソースおよびリソース・グループに対するビューアー権限を付与する 2 つのアクセス・ポリシーを割り当てます。 Developer-Group には、CustApp-Dev リソースおよびリソース・グループと CustApp-Test リソースおよびリソース・グループに対するエディター権限を付与する 2 つのアクセス・ポリシーを割り当てます。 Admin-Group には、3 つの CustApp リソース・グループとそれらのリソースのすべてに対する管理者権限を付与する 3 つのアクセス・ポリシーを割り当てます。

アクセス・グループを作成してそれに 2 つのポリシーを割り当てることによって、アカウント内のすべてに対する管理者権限を割り当てることができます 最初のポリシーを作成するには、管理者プラットフォーム役割とマネージャー・サービス役割を持つアカウントで、**「すべての ID およびアクセス対応サービス」**を選択します。 2 番目のポリシーを作成するには、管理者の役割が割り当てられた 「すべてのアカウント管理サービス」 を選択します。

プラットフォーム・ロール

• 管理者: 特定のオブジェクトとその「子」オブジェクト (例えば、鍵はインスタンスの子オブジェクト) に対するすべての権限を持ちます。これには、新しいユーザーを招待し、オブジェクトに対する役割を割り当てる権限が含まれます (管理者のみが役割を割り当てることができます)。 デフォルトでは管理者にサービス役割はないことに注意してください。 ただし、管理者は自分自身に役割を割り当てることができます。
• エディター: アカウント・レベルでインスタンスを表示、作成、および削除できますが、新しいユーザーを招待することはできません。 サービス・インスタンス内のオブジェクト (鍵など) については、表示する以外の使用は制限されています。
• オペレーター: アカウント・レベルでインスタンスを表示できますが、編集することはできません。 サービス・インスタンス内のオブジェクト (鍵など) については、表示する以外の使用は制限されています。
• ビューアー: アカウント・レベルでインスタンスを表示できますが、編集することはできません。 サービス・インスタンス内のオブジェクト (鍵など) については、表示する以外の使用は制限されています。

プラットフォーム役割は、アカウント全体に対して、特定のサービス・インスタンスに対して、またはサービス・インスタンスの内部にあるオブジェクト内で割り当てることができます。

以下の対象に適用されるプラットフォーム管理の役割を列挙しています Key Protect

アクション	ビューアー	エディター	オペレーター	管理者
Key Protect インスタンスの表示
Key Protect インスタンスの作成
Key Protect インスタンスの削除
新規ユーザーの招待およびアクセス・ポリシーの管理

アカウント・レベルの役割は、デフォルトでは全サービス・インスタンスに対する特定の権限をユーザーに付与しますが、特定の 1 つのサービス・インスタンスに対する役割を割り当てることもできます。 例えば、アカウント・エディター (インスタンスを表示、作成、および削除する権限はあるが、役割を割り当てる権限はありません) は、特定のサービス・インスタンスの_管理者_にすることができます。これにより、そのサービス・インスタンス内で役割を割り当てることができます。

サービス役割は、サービス・インスタンス内の 3 つの重要なオブジェクトである、インスタンス全体、特定の鍵、および鍵リングに対して適用できます。 アカウント役割の権限の対象がデフォルトでは全インスタンスであるように、インスタンス管理者の権限の対象もデフォルトではすべての鍵と鍵リングです。 ただし、これらの権限は必要に応じてより詳細に割り当てることができます。例えば、特定の鍵または鍵リングに対してのみ_マネージャー_の役割をユーザーに付与し、インスタンス全体に対していくつかのより低いレベルの権限を付与することができます。

サービス役割は、インスタンス単位で割り当てることも、アカウントの全インスタンスについて割り当てることもできます。

サービスインスタンスのロール

役割に含まれる権限は追加的である点に留意してください。 例えば、_マネージャー_には、_リーダー_が持つすべての権限とそれ以上の権限がありま。 例外は KeyPurge の役割です。この役割には、他の役割の一部ではないために明示的に設定する必要があるkms.secrets.purgeアクションが含まれています。

• マネージャー: 特定のオブジェクトに対するすべての権限を持ちます (例えば、鍵のマネージャーは、鍵のラップ、アンラップ、および削除を行うことができます。また、dualAuthDelete、allowedNetwork、allowedIPなどの Key Protect ポリシーの読み取りおよび更新を行う排他的な権限を持ちます)。
• ライター: オブジェクトの使用 (鍵とそのメタデータを取得する機能を含む) に関してマネージャーが実行するのとほとんど同じ権限を持っていますが、通常はオブジェクトを削除したり無効にしたりすることはできません。
• リーダー: オブジェクトを使用できます (例えば、鍵リーダーは鍵をラップおよびアンラップできます) が、オブジェクトを作成、削除、または変更することはできません。
• ReaderPlus: リーダーと同じ権限を持ち、標準鍵のペイロードを取得する機能を追加します。
• KeyPurge: 4 時間後に鍵をパージする 機能があります。
• KmipAdapterManager：KMIP プロトコル で管理されるリソースへのアクセスを管理するために必要なすべての権限を持つ

サービス・アクセス役割と Key Protect 許可の対応関係を以下の表に示します。

Key Protect の主要リソースに適用されるサービスアクセスロールを一覧表示します

アクション	リーダー	ReaderPlus	ライター	マネージャー	KeyPurge	KmipAdapterManager
鍵の作成
鍵のインポート
鍵の取得
鍵メタデータの取得
鍵合計の取得
鍵のリスト
鍵のバージョンのリスト
鍵のラップ
鍵のアンラップ
鍵の再ラップ
鍵のローテート
鍵を無効にします
鍵を有効にします
鍵の削除をスケジュールします
鍵の削除をキャンセルします
鍵の削除
鍵の復元
鍵のパッチ
鍵を同期します
4 時間後に鍵をパージします

Key Protect のキーリングリソースに適用されるサービスアクセスロールを一覧表示します

アクション	リーダー	ReaderPlus	ライター	マネージャー	KeyPurge	KmipAdapterManager
鍵リングの作成
鍵リングをリストします
鍵リングの削除

Key Protect のポリシーリソースに適用されるサービスアクセスロールを一覧表示します

アクション	リーダー	ReaderPlus	ライター	マネージャー	KeyPurge	KmipAdapterManager
鍵ポリシーの設定
鍵ポリシーのリスト
インスタンス・ポリシーの設定
インスタンス・ポリシーのリスト

トークンリソースのインポートに適用されるサービスアクセスロールを一覧表示します

アクション	リーダー	ReaderPlus	ライター	マネージャー	KeyPurge	KmipAdapterManager
インポート・トークンを作成します。
インポート・トークンをリトリーブします。

Key Protect の登録リソースに適用されるサービスアクセスロールを一覧表示します

アクション	リーダー	ReaderPlus	ライター	マネージャー	KeyPurge	KmipAdapterManager
登録の作成[^services-1]
鍵の登録のリスト
任意の鍵の登録のリスト
登録の更[^services-2]
登録の置換[^services-3]
登録の削除[^services-4]

KeyPurge 役割は、鍵をパージする機能のみを提供するため、_マネージャー_などの他のサービス・アクセス役割に追加するものと見なす必要があります。

Key Protect の主要リソースに適用されるサービスアクセスロールを一覧表示します

アクション	リーダー	ReaderPlus	ライター	マネージャー	KeyPurge	KmipAdapterManager
KMIPアダプタのリスト
KMIPアダプターの作成
KMIP アダプタの取得
KMIPアダプタの削除
KMIP アダプタの KMIP オブジェクトを一覧表示します
KMIP アダプタから KMIP オブジェクトを取得する
KMIP アダプタから KMIP オブジェクトを削除する
KMIP アダプタのクライアント証明書のリスト
KMIPアダプタへのクライアント証明書の追加
KMIP アダプタからのクライアント証明書の取得
KMIP アダプタからクライアント証明書を削除する

ライター、 リーダー、および ReaderPlus ロールはKMIPプロトコルにアクセスできません。

役割と Cloud Identity and Access Management ポリシー

Key Protect コンソールでは、上記の役割を使用してユーザーのアクセスをきめ細かく制御できますが、次のように、それらの役割が Cloud Identity and Access Management ポリシーに関連付けられることを覚えておくと役に立ちます。

• サービス名 (Key Protect の場合、常に kms)
• サービス・インスタンス ID
• 鍵リング ID
• リソース・タイプ (サポートされるのは key だけです)
• リソース ID
• アカウント ID (ポリシーには必ず指定されます)

IAM API から返されるポリシーの例を以下に示します。

"resources": [
    {
        "attributes": [
            {
                "name": "accountId",
                "value": "$ACCOUNT_ID",
            },
            {
                "name": "serviceName",
                "value": "kms",
            },
            {
                "name": "resourceType",
                "value": "key",
            },
            {
                "name": "resource",
                "value": "$KEY_ID",
            },
            {
                "name": "keyRing",
                "value": "$KEY_RING_ID",
            }
        ]
    }
]

1 つのポリシーでこれらの属性を任意に組み合わせて適用することができます。 ポリシーに管理者の役割を関連付けた場合、そのポリシーを適用されたuser/service id/access groupは、許可されたリソースの下位リソースに適用されるポリシーを作成できます。 言い換えると、下位のすべての管理者ユーザーは、親の管理者と同じアクセス権限 (ポリシーに指定されたとおりの属性) か、またはそれより低いアクセス権限 (ポリシーに指定されたとおりの属性に加えて、追加で指定された属性) のみを持つことができます。