マルチアカウント構成では、アカウント A で暗号化したデータをアカウント B のロールに読ませる場面が出ます。バケットポリシーも IAM ポリシーも許可したのに B のロールが AccessDenied になるとき、見落とされがちなのが KMS の許可です。KMS は、リソース側と呼び出し側の両方が許可して初めて通る作りです。
この記事の結論
- 別アカウントのキーは、持ち主側のキーポリシーと、使う側の IAM ポリシーの両方で許可して初めて使えます。どちらか一方では足りません。
- キーポリシーは「使える範囲の上限」、IAM ポリシーは「その範囲から実際に誰に渡すか」を決めます。
- キーポリシーの Principal にアカウントを書くと、委任先の管理を相手の IAM に任せられます。ロールを個別に書くと上限を絞れますが、2か所の管理が増えます。
- 別アカウントから効くのは暗号操作・グラント関連などの限られた操作で、キーの管理操作は書いても効きません。
- 別アカウントのキーはキー ARN（またはエイリアス ARN）で指定します。キー ID だけでは自分のアカウントのキーと解釈されます。
- 使われ方は、呼び出し側と持ち主側の両方の CloudTrail に残ります。
別アカウントの KMS キーを使うとは何か｜「二重の許可」の全体像
同じアカウント内なら、IAM ポリシーかキーポリシーのどちらかで許可すれば足りる場面があります。ところが別アカウントのキーを使うときは、AWS の公式ドキュメントが「キーポリシーと IAM ポリシーのどちらか一方では足りず、両方を変える」と明記しています。
役割は次のように分かれます。
- キーポリシー（キーを持つアカウント側）：外部のアカウント、またはそのロールに、キーを使う許可を与える。「誰が使えるか（can）」の上限を決める。
- IAM ポリシー（使うアカウント側）：キーポリシーで開けた範囲を、自アカウントのユーザーやロールに委任する。「誰が実際に使うか（does）」を決める。
TWO PERMISSIONS4 つの関所
別アカウントのキーは両側の許可がそろって初めて通る
-
B のロールが呼ぶ
キー ARN で指定
-
B の IAM ポリシー
実際に誰が使うか
-
A のキーポリシー
使える範囲の上限
-
暗号操作が通る
両方の CloudTrail に残る
たとえるなら、金庫の持ち主が「あの会社の人なら開けてよい」と書き、相手の会社が「うちの誰に鍵を渡すか」を決める、という分担です。正確な用語に戻すと、前者がキーポリシー、後者が IAM ポリシーです。
なお、キーポリシーは既定のままでは IAM ポリシーを効かせません。既定のキーポリシーに入っている「アカウントの root を許可する」文が、IAM ポリシーでの許可を有効にする役目を持っています。この文が無いキーでは、IAM ポリシーで許可しても効かず、拒否だけが効きます。同じアカウント内の話ですが、「KMS はキーポリシーが基本で、そこで開けた範囲でだけ IAM が働く」という性質は、別アカウントでも同じ土台です。
別アカウントで効く操作は限られる
別アカウントのプリンシパルに許可しても効くのは、次の操作だけです。
| 区分 | 操作の例 |
|---|---|
| 暗号操作 | Encrypt / Decrypt / ReEncrypt / GenerateDataKey など |
| グラント関連 | CreateGrant / ListGrants / RetireGrant / RevokeGrant |
| 参照 | DescribeKey / GetKeyRotationStatus / GetPublicKey |
これ以外、たとえば ListKeys や ScheduleKeyDeletion は、別アカウントに許可を書いても効きません。キーの削除や設定変更は、持ち主のアカウントの中でしかできないということです。グラントは「キーポリシーを書き換えずに、限定した操作を一時的に委任する」仕組みで、ここでは「別アカウントでも使える操作に含まれる」ことだけ押さえておけば十分です。
CHECK 1ここまでの確認
アカウント A のキーポリシーでアカウント B を許可した。B のロールに IAM ポリシーの許可が無いとき、そのロールはキーを使えるか?
答えと解説
答え: 2. 使えない。実際に使う主体への許可は B の IAM ポリシーが担うから
別アカウントのキーは、持ち主側のキーポリシーと使う側の IAM ポリシーの両方が要ります。「二重の許可」の章に戻って確認してください。
キーポリシーに何を書くか｜アカウント指定とロール指定の違い
キーポリシーの Principal には、二通りの書き方があります。
- アカウントを指定する：相手アカウントの ARN（
arn:aws:iam::<アカウント ID>:rootの形）を書く。相手の IAM 管理者が、IAM ポリシーでどのユーザー・ロールに、どの操作を渡すかを決められる。 - ロールやユーザーを個別に指定する：相手のロールの ARN を書く。持ち主側で渡す相手を絞れる。ただし、そのロールが使えるようになるのは、相手側で適切な IAM ポリシーが付いてから。
ACCOUNT OR ROLEPrincipal の書き方
アカウント指定は任せる、ロール指定は絞る
アカウント指定
相手の IAM に委任する
- 相手を増やしても相手側の IAM だけで済む
- 上限は相手アカウント全体
- 相手の管理を信頼できる場面向き
ロール指定
持ち主側で絞る
- 使えるロールを持ち主側で固定できる
- 相手が増えるたび2か所を直す
- 外部の相手に厳密に渡す場面向き
どちらも、キーポリシーで許可していない操作は、IAM ポリシーに書いても効きません。ロールを個別に書いた場合は、そこに載っていないロールに IAM ポリシーで許可しても効きません。キーポリシーが「上限」だと言われる理由です。
注意したいのが Principal を * にする書き方です。公式ドキュメントは、条件で絞らない限り * を使わないよう警告しています。全アカウントの全主体に、キーを使う許可が開いてしまうためです。
CHECK 2ここまでの確認
キーポリシーの Principal に相手の「アカウント」を書く利点は?
答えと解説
答え: 1. 相手アカウントのどのロールに渡すかを、相手の IAM 側で決められる
アカウントを書くと、委任先の管理を相手の IAM 管理者に任せられます。IAM ポリシー自体は引き続き必要です。「キーポリシーに何を書くか」の章を読み直してください。
使う側の IAM ポリシーに何を書くか｜委任の範囲とキー ARN の指定
使う側の IAM ポリシーには、次の点を書きます。
- Action：キーポリシーで許可された範囲の全部か一部。たとえば復号だけ渡す、といった絞り方ができる。
- Resource：使いたいキーのキー ARN。IAM ポリシーには Principal が無く、付けた先のユーザーやロールが主体になる。Resource を広く書くと、意図せず多くのキーに許可が及ぶので、必要なキーだけを挙げる。
コード・CLI・サービスの設定でキーを指定するときも、別アカウントのキーはキー ARN かエイリアス ARN で書きます。キー ID やエイリアス名だけを渡すと、AWS は自分のアカウントのキーだと解釈します。そのため、キーはあるのに「見つからない」「アクセスできない」という失敗になります。KMS のコンソールの一覧にも他アカウントのキーは出ないので、ARN を直接入れる必要があります。
CHECK 3ここまでの確認
別アカウントのキーで復号しようとして、キー ID だけを指定すると失敗するのはなぜ?
答えと解説
答え: 2. 自分のアカウントのキーだと解釈されるから
別アカウントのキーはキー ARN（またはエイリアス ARN）で指定します。「使う側の IAM ポリシー」と「どこで拒否されるか」の章を確認してください。
サービス経由で使うときの仕組み｜S3・Secrets Manager・スナップショット共有で何が必要になるか
S3 や Secrets Manager のようなサービス経由でも、考え方は同じです。公式ドキュメントも、別アカウントの利用者が、持ち主のキーで S3 のオブジェクトを暗号化したり、Secrets Manager のシークレットを暗号化したりできる、と説明しています。条件は、キーポリシーが外部のアカウントや主体を許可していること、そして使う側の主体に、そのサービスを使う IAM ポリシーが付いていることです。
| 場面 | 必要になる許可 |
|---|---|
| SSE-KMS の S3 オブジェクトを別アカウントが読む | バケットポリシー（または ACL 等の S3 側）に加えて、キーポリシーと、読む側ロールの IAM ポリシー |
| 別アカウントの Lambda などがシークレットを読む | シークレットのリソースポリシーとキーポリシーの両方で相手を許可し、読む側にも IAM の許可 |
| パイプラインの成果物を別アカウントのロールが受け取る | 成果物を暗号化するキーのキーポリシーと、バケットポリシーの両方で相手のロールを許可 |
| EBS などのスナップショットを別アカウントに共有する | 共有先がキーを使えるよう許可する。キーは AWS マネージドキーではなくカスタマーマネージドキーにする |
サービスによっては、グラントの作成など追加の権限を要求することがあります。必要な権限は、各サービスのドキュメント（保存時の暗号化・データ保護の章）で確認します。
AWS マネージドキーは別アカウントに許可できない
AWS が作る aws/s3 のような AWS マネージドキーは、利用者がキーポリシーを変更できません。公式ドキュメントも、AWS マネージドキーは「そのキーがあるアカウントの主体だけが、サービスを通じて使える」ものであり、そのキーで暗号化したリソースを他のアカウントと共有することはできない、と説明しています。
そのため、別アカウントに渡す予定のデータは、最初からカスタマーマネージドキーで暗号化します。すでに AWS マネージドキーで暗号化してしまったデータは、カスタマーマネージドキーで暗号化し直したコピーを作り、そちらを共有します。これは後から気づくと手戻りが大きい点なので、設計の段階でキー種別を決めておきます。
どこで拒否されるか｜原因の切り分けの順番
AccessDenied が出たとき、次の順に確かめます。
WHERE DENIED切り分けの 4 項目
拒否されたらこの順に確かめる
-
1.キーポリシー
相手と操作が許可されているか
-
2.IAM ポリシー
キー ARN を Resource にしているか
-
3.キーの種類と ARN
カスタマーマネージドキーか・ARN 指定か
-
4.リージョン
外部アカウントが有効か
- キーポリシー：相手のアカウント（またはロール）を許可しているか。必要な操作（復号なら Decrypt など）が含まれているか。ロール指定なら、実際に使うロールの ARN と一致しているか。
- IAM ポリシー：使う側のロールに、そのキーの ARN を Resource にした許可が付いているか。キーポリシーに無い操作を書いていないか。
- キーの種類と指定の仕方：キーは AWS マネージドキーではないか。キーを ARN で指定しているか。
- リージョン：キーのあるリージョンで、外部アカウントが有効になっているか。公式ドキュメントによると、外部アカウントへの許可は、そのアカウントがキーのあるリージョンで有効な場合にだけ効きます。既定で無効なリージョン（オプトインリージョン）を使うときは特に確認します。
サービス経由の場合は、S3 のバケットポリシーなど、サービス側の許可も別に確認します。調査には CloudTrail が使えます。別アカウントのキーの使用は、呼び出した側と、キーを持つ側の両方のアカウントのログに残るためです。
CHECK 4ここまでの確認
別アカウントのプリンシパルに、キーの削除予約の権限をキーポリシーで書いた。どうなる?
答えと解説
答え: 2. 効かない。別アカウントで効くのは暗号操作などの限られた操作だけ
クロスアカウントで効く操作は決まっています。キーの管理操作は書いても効きません。「二重の許可」の章の表を読み直してください。
設計の判断軸｜アカウント指定かロール指定か、どの条件で絞るか
判断軸は二つです。管理の手間と、上限の絞りやすさです。
| 観点 | アカウント指定 | ロール指定 |
|---|---|---|
| 渡す相手を増やすとき | 相手側の IAM だけで済む | 持ち主のキーポリシーと相手の IAM の両方を直す |
| 上限の絞りやすさ | 相手アカウントの IAM 管理者を信頼する前提 | 持ち主側で、使えるロールを固定できる |
| 向く場面 | 同じ組織内で、相手アカウントの管理が信頼できる | 相手が外部で、使えるロールを厳密に決めたい |
どちらを選んでも、さらに条件で絞れます。たとえば kms:ViaService の条件を使うと、特定のサービス経由のリクエストだけを許可でき、KMS の API を直接呼ぶ使い方を防げます。条件の細かい設計は、権限設計全般の話になるので、マルチアカウント設計で扱う SCP や権限境界と合わせて考えます。
最小権限の原則は、公式ドキュメントも強調しています。必要なキーに、必要な操作だけを渡します。
まとめ
- 別アカウントのキーを使うには、キーポリシー（上限）と IAM ポリシー（実際の割り当て）の両方が要ります。
- 効く操作は暗号操作・グラント関連・一部の参照に限られ、管理操作は効きません。
- キーは ARN で指定し、AWS マネージドキーは使わずカスタマーマネージドキーにします。
- 拒否されたら、キーポリシー、IAM ポリシー、キー種別と ARN、リージョンの順に確かめます。
キーの種類などの基本は KMS とは で、アカウント設計全体は マルチアカウント設計 で確認できます。
参照ソース
- Allowing users in other accounts to use a KMS key（AWS KMS Developer Guide） — 二重の許可、効く操作の一覧、Principal の書き方、キー ARN での指定、リージョンの条件、CloudTrail が両方に残ることの根拠
- Default key policy（AWS KMS Developer Guide） — 既定キーポリシーの root の文が IAM ポリシーの許可を有効にする、という点の根拠
- AWS KMS keys（AWS KMS Developer Guide） — AWS マネージドキーは他アカウントと共有できないこと、キー ARN とキー ID の違いの根拠
