はじめに
こんにちは！パナソニックコネクト株式会社の岡本です。
クラウドシステムにおける、異なるアカウント間でのファイル連携は、多くの企業で検討される重要なテーマです。特に、いかに「安全に」連携を実現するかは、システム設計における最重要課題の一つと言えるでしょう。
 |
本記事では、「異なるAWSアカウント同士で EC2 → S3バケット のファイルコピー」を安全に行うシステム構成について解説します。
そもそも「安全にファイルを連携する」とは
「安全なファイル連携」と一言で言っても、その定義は多岐にわたります。
転送用の認証パスワードを複雑にすることや、転送データ自体を暗号化することなど、一概に決められるものではないと思いますが、本記事では例として、次のような仕組みを 安全なデータのやり取り と定義してみます。
- 必要最低限のリソース同士 でのみデータ連携を許可する
- インターネットを経由せず、 閉域な通信 でデータをやり取りする
- 万が一の流出に備え、 恒久的な認証情報の発行を避け、一時的なセッションを利用する
これらの要件をAWSサービスで実現するためのアクションを具体的に考えてみましょう。
- アクセス制御: IAMロールとバケットポリシーによる厳格な制御
- 通信経路の確保: VPCエンドポイントを経由した閉域通信
- 認証情報の管理: 一時的なセッションを活用し、恒久的な認証情報の発行を避ける
 |
上記のような方針を採用することで、アクセス元とアクセス先のリソースを限定し、ファイルの誤送信や意図しないバケットへの配置を防ぐことができます。また、外部に晒されない通信経路と、期限付きの認証トークンを利用することで、万が一権限が流出した際も二次被害を最小限に抑えることが可能です。
これは、システムインテグレーションにおいて「ある一定レベルで安全な仕組み」と評価できるでしょう。
ここからは、この安全な仕組みをAWS上で実装するための具体的な設定例を解説していきます。
今回の記事は、以下のAWS公式のドキュメントを参考にしております。より詳細な情報が必要な場合は、合わせてご確認ください。
【AWS公式ドキュメント】
Amazon EC2 インスタンスに別の AWS アカウントの Amazon S3 バケットへのアクセス権を付与する方法を教えてください。
https://repost.aws/ja/knowledge-center/s3-instance-access-bucket
具体的な設定
一つ一つ見ていきます。
IAMロールとバケットポリシー
これはアクセス元のEC2、アクセス先のS3バケット、そしてEC2のアクセスを許可するIAMロール（アカウント②管理）の３つを設定する必要があります。
アクセス元EC2
EC2インスタンスには、後述する「許可用のIAMロール」を引き受けられる最小限の権限のみをアタッチします。アクセス先のS3バケットに対する直接的なIAM権限は 不要 です。以下にポリシーの例を示します。
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "許可用のIAMロールのARN"
}
}
このポリシーにより、EC2インスタンスは指定されたIAMロール（Resourceで指定）を一時的に引き受ける（AssumeRoleする）権限を得ます。これにより、EC2インスタンス自身が持つ権限は最小限に保たれ、権限の分離と管理がシンプルになります。
アクセス先S3バケット
S3バケットには、以下の条件でアクセスを許可するポリシーを設定します。
- 通過したエンドポイントIDからのアクセスを許可
- 特定のフォルダに対するS3アクション（今回はPutObject）のみ許可
例として、バケット名がec2-s3-secure-architectureで、/exampleフォルダ配下の任意のディレクトリへのファイルコピーのみを許可する場合のポリシーは以下のようになります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "xxxxxxxx",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::ec2-s3-secure-architecture/example/*"
],
"Condition": {
"StringNotEquals": {
"aws:SourceVpce": "<通過したVPCエンドポイントID>"
}
}
}
]
}
このポリシーの重要な点は、Condition句で指定されたVPCエンドポイント以外からのアクセスを 明示的に拒否（Deny） していることです。これにより、例え強力なIAMロールを持つEC2インスタンスがアクセスしてきた場合でも、指定のVPCエンドポイントを経由しない限り、このバケットへのPutObjectアクションは拒否されます。これはホワイトリスト的なセキュリティ制御を実現し、意図しないアクセスからデータを保護するために非常に有効です。
EC2のアクセスを許可するIAMロール（アカウント②管理）
このIAMロールは、実際にS3バケットへのアクセス権限を定義するものです。例えば、exampleフォルダ配下へのファイルコピーのみを許可したい場合は、以下のポリシーを設定します。
例えば、exampleフォルダ配下へのファイルコピーだけ許可したい場合は以下です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::ec2-s3-secure-architecture/example/*"
]
}
]
}
さらに、このロールはAssumeRoleされることを前提とするため、 信頼ポリシー でアクセス元のEC2インスタンスに付与されているIAMロールを指定する必要があります。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"<アクセス元のEC2に付与されているIAMロールのARN>"
]
},
"Action": "sts:AssumeRole"
}
]
}
この信頼ポリシーにより、アクセス元のEC2インスタンスが持つIAMロールが、このIAMロールを一時的に引き受けることを許可できます。これにより、EC2インスタンスはaccount2_iam_policy.jsonで定義された権限を一時的に借用し、S3へのファイル転送を実行できるようになります。
実際にファイルのコピーを実行する場合は、sts assume-roleコマンドによって認証情報を取得し、その情報をシェル内（windowsであればpowerShell）の環境変数に指定後、aws s3 cpコマンドにてファイル転送を行います。
詳細な利用方法については、以下のAWS公式ドキュメントが非常に参考になります。
様々なケースが紹介されていますので、ぜひご一読ください。
https://repost.aws/ja/knowledge-center/iam-assume-role-cli
VPCエンドポイントを経由した通信
VPCエンドポイントは、AWSのサービスにインターネットを経由せずにアクセスするためのプライベートな接続を提供します。これにより、トラフィックがAWSネットワーク内に閉じたセキュアな通信経路を確立できます。
今回は、S3エンドポイント（ゲートウェイ型）とSTSエンドポイント（インターフェース型）の2種類のエンドポイントを作成し、閉域通信を実現します。VPCエンドポイントには「エンドポイントポリシー」を設定でき、これによりエンドポイントを通過できるリソースを細かく制御できます。
 |
VPCエンドポイントポリシー（S3用）
S3ゲートウェイエンドポイントに適用するポリシーです。ここでは、S3バケットへのアクセスを許可する条件を指定します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "xxxxxxxx",
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": [
"arn:aws:s3:::ec2-s3-secure-architecture/example/*"
],
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": "<アクセス元のEC2が持つIAMロールのARN>"
}
}
}
]
}
このポリシーでは、アカウント②が管理するS3バケットの特定のリソース（例としてec2-s3-secure-architecture/example/*）へのアクセスを許可します。Condition句により、アクセス元のEC2インスタンスが持つIAMロールのARNが指定されたものと一致する場合のみ、エンドポイントの通過を許可します。
VPCエンドポイントポリシー（STS用）
STSインターフェースエンドポイントに適用するポリシーです。AssumeRole操作を許可する条件を指定します。
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Principal": "*",
"Resource": [
"<アカウント②のIAMロールのARN>"
],
"Condition": {
"StringLike": {
"aws:PrincipalArn": [
"<アクセス元のEC2が持つIAMロールのARN>"
]
}
}
}
]
}
このポリシーでは、AssumeRoleしたい対象のIAMロール（アカウント②が管理するIAMロール）をResourceに指定し、Condition句でこのロールを借りることができるIAMロールのARN情報を指定します。
以上、2つのエンドポイントにより、
- VPCエンドポイントを利用できるアカウント①内のリソース
- VPCエンドポイントを通過してアクセス可能な、アカウント②内のリソース
のそれぞれを、必要最低限の範囲で厳密に制限することが可能になります。
まとめと実装のポイント
本記事では、AWSにおけるクロスアカウントでのファイル転送を、IAMポリシー、バケットポリシー、そしてVPCエンドポイントを組み合わせることで、いかにセキュアに実現するかを解説しました。
異なるAWSアカウント間でのデータ共有や移行は、セキュリティリスクを伴う作業です。今回ご紹介したような多層的なセキュリティ対策を講じることで、データの機密性を保ちつつ、安全かつ効率的な運用が可能となります。
システムインテグレーション業務において、お客様のビジネス要件とセキュリティ要件の両立は常に大きな課題です。本記事が、皆さんの日々の業務における設計や実装の一助となれば幸いです。