AWSにおけるクロスアカウントアクセスの方法

1.　 ポリシーとアクセス制御のおさらい

前回の記事ではポリシーの種類やアクセス制限の設定値、その評価論理についてまとめました。クロスアカウントアクセスに際して特に重要になるのが、前回記事で登場した以下の表です。Table 1. 同一アカウント内アクセスにおけるポリシーとアクセス制御の組み合わせ

同一アカウント内のアクセスであればリソースベースポリシー・アイデンティティベースポリシー（IDベースポリシー）のいずれかで明示的許可を設定すれば問題なかったのですが、クロスアカウントアクセスではリソースベース・アイデンティティベースの両方で明示的許可を設定する必要があります。Table 2. クロスアカウントアクセスにおけるポリシーとアクセス制御の組み合わせ

両ポリシーで明示的許可が設定されている部分、つまり表の赤枠で囲まれた部分でのみクロスアカウントアクセスが可能です。

前回記事のポリシーの説明で、” 貴族の晩餐会 ”の例がありましたが、今回もそのイメージを持っていただけるとクロスアカウントアクセスがイメージしやすいと思います。招待状であるアイデンティティベースポリシーとガードマンであるリソースベースポリシーの両条件をクリアして、初めてクロスアカウントアクセスできるイメージですね。

ちなみにAWS公式では、S3バケットへのクロスアカウントアクセスのベストプラクティスは今回検証した方法を含め、次の3つの手法が紹介されています。（参考：Simple Storage Service (Amazon S3) バケット内のオブジェクトへのクロスアカウントアクセスを許可する）

1.　IAMポリシーとリソースベースのバケットポリシーの設定
2.　IAMポリシーとリソースベースのアクセスコントロールリストの使用
3.　クロスアカウントIAMロールの設定

今回は、比較的簡単な方法である1番目の方法でのクロスアカウントアクセスを検証します。

ここまでは、前回のおさらいをかねて、クロスアカウントアクセスにおける重要なポイントについて確認しました。続いて、クロスアカウントアクセスの評価論理について、具体的に見ていきたいと思います。

2.　クロスアカウントアクセスの全体像と評価論理

クロスアカウントアクセスの前提条件を抑えつつ、もう少し具体的に考えてみます。
公式ドキュメントを参考に、アカウントAのUserからアカウントBにあるS3へのクロスアカウントアクセスを考えてみましょう（Fig1）。この時、アクセスする側のアカウントを信頼されるアカウント（trusted account）、アクセスされる側のアカウントを信頼するアカウント（trusting account）と呼びます。また、クロスアカウントアクセスには双方のポリシーの明示的許可が必要なため、それぞれ、UserにはIAMポリシー、S3にはバケットポリシーを設定して明示的許可を与えます。

上図を見ながら、クロスアカウントポリシーの評価論理について確認してみましょう。

1）　プリンシパルがクロスアカウントアクセスを要求（クロスアカウントリクエスト）
2）　プリンシパルの存在する、信頼されるアカウント(A)を評価する際にアイデンティティベースのポリシーを確認
3）　リソースの存在する、信頼するアカウント(B)を評価する際にリソースベースのポリシーを確認
4）　両方のポリシーで明示的許可が設定されている場合にのみクロスアカウントアクセスを許可

評価論理自体は結構シンプルですが、4番目が非常に重要です。前項でも確認したとおり、いずれかのポリシーの明示的許可だけではクロスアカウントアクセスはできないんですね。

では、次はいよいよ実際にクロスアカウントアクセスを試してみます。

3.　実践

3.1.　検証環境の全体像

クロスアカウントアクセスの検証環境として、以下のような環境を準備しました。
（わかりやすさのため、IAMロールやバケットポリシーを付与した後の構成図となります）

アカウントAにあるEC2インスタンスからアカウントBにあるS3に対して、アクセスを行うのが目標です。また、以下の条件で両ポリシーの明示的許可を設定します。

• アカウントAのEC2に、IAMロールをアタッチしてアカウントBのS3バケットへのアクセス権限を与える（アイデンティティベースポリシーの設定）
• アカウントBのS3バケットポリシーで、アカウントAのEC2からのアクセスを許可する（リソースベースポリシーの設定）

3.2.　ポリシー設定前のアクセス検証

まず、なにもポリシーを付与していない状態で、クロスアカウントアクセスを試してみましょう。

S3バケットにはテスト用のテキストファイルを置いておきます。今回はクロスアカウントアクセスで、この中身が見れることを目標とします。
次にアカウントAでEC2インスタンスを起動し、TeraTermでSSH接続後にアカウントBのバケットにアクセスできるか試してみます。

当たり前ですが、アクセスできません。次は評価論理に沿って、アイデンティティベースのポリシーを設定してみます。今回の環境では、まずIAMポリシーで明示的許可を設定し、EC2と信頼関係をもつIAMロールに付与します。その後、そのIAMロールを対象のEC2インスタンスに付与する、という流れになります。少しややこしいですが、実際の流れを確認していきましょう！

3.3.　 IAMポリシーの設定

今回はクロスアカウントアクセスを実現したいので、明示的許可を設定します。以下のように、Resourceの要素にアクセス対象のS3バケットを指定したIAMポリシーを作成します。

上記のポリシーを付与したIAMロールをEC2インスタンスにアタッチして、アイデンティティベースポリシーの設定は完了です！

アイデンティティベースポリシーのみ設定が終わった今の状態では、S3バケットに対してはアクセスはできません。（下図のようにアクセスが拒否されます。）

続いて、リソースベースのポリシーを設定してみます。

3.4.　 バケットポリシーの設定

バケットポリシーは、上記のように設定しました。今回は、Gateway型のVPCエンドポイントを経由してS3にアクセスするようにポリシーを設定しています。ここでもプリンシパルとリソースに対して明示的許可を設定することが重要です。

これでアイデンティティベース・リソースベース両方のポリシー設定が、終了しました。両ポリシーで明示的許可を設定したため、クロスアカウントアクセスが成功するはずです！やってみましょう！

3.5.　 クロスアカウントアクセスの検証

アクセスできました！クロスアカウントアクセスに成功して、他アカウントに存在するS3バケットにアクセスができました！バケットに置いたテキストファイルの中身を見ることもできます。

なお、実際の環境でクロスアカウントアクセスを試みる場合には、よりセキュリティ面を考慮する必要があります。
（e.g. 特定VPCエンドポイント経由以外のアクセスは明示的に拒否する、S3バケットに対して実行可能なアクションを制限する、MFA認証を使用する…etc）

4.　 まとめ

今回はAWSにおけるクロスアカウントアクセスの方法について、ポリシーの設定やアクセス制御に触れながらまとめてみました。くどいようですが、今回の方法では、両方のポリシーで明示的許可を設定するのが最も重要なポイントです。
次回は、セキュリティを意識したポリシーの作成についての記事を予定しています！今回のクロスアカウントアクセスとも関わりのある内容ですね。どうぞお楽しみに！

最後まで記事を読んでいただきありがとうございました！