👨‍✈️

AWSの本番環境からデータ持ち出しを防ぐ方法とは？特定アカウントへのアクセス制限における課題と最新機能の紹介

2024/05/09に公開

AWS

はじめに

突然ですが、皆さんは会社の本番環境で使用するAWSアカウントへどのようにアクセスしていますか？高いセキュリティレベルや統制要件が求められる現場の場合、専用の端末ルームや本番作業専用の端末からマネジメントコンソールにアクセスするケースが多々あると思います。

その場合、作業端末から会社で管理していないAWSアカウントへのアクセスを制御することは重要です。例えばもし、作業端末から個人のAWSアカウント上にあるS3バケットにファイルアップロードできてしまえば、会社の本番環境から簡単に重要データを持ち出せてしまいますよね。

このようにAWS上にある本番データを管理外のAWS環境へ持ち出しできる状況をどのように防げばよいのでしょうか？
本ブログでは、このデータ持ち出しを防止する方法と実装について、AWSの仕様と検証結果を交えらながら考えていきたいと思います。（金融系業種ではよくある統制要件だと思います。本ブログがこの要件に悩む人たちの一助になれば幸いです）

状況の設定

ここから先は、私が経験した案件をベースに以下の状況を想定して記載していきます。

金融機関（A社）の機密データが格納されたとある本番システムをAWS環境上で稼働させている
Organizationsを使ったマルチアカウント構成で本番環境を管理しており、AWS上のユーザと権限をIAM Identity Centerで一元管理している
本番環境へのアクセスは作業専用ルームの特定の作業端末からのみ実施できるようにしている
- マネジメントコンソールアクセスの経路としては、作業端末から社内プロキシサーバを通じて、インターネット経由でIAM Identity Centerのポータルを経て、各AWSアカウントへアクセスしている

図解すると以下の通りです。

実現したいことは作業端末から社外のAWSアカウントへのアクセスを防止すること

「はじめに」の章に記載したとおり、本番データの漏洩を防止したいです。具体的には、プロキシサーバを使って社外のAWSアカウントへのマネジメントコンソールアクセスを防止することが一旦のゴールになります。

要件を文字と図で整理すると以下の通りです。

青線経路
- 要件①A社Organizations配下のアカウントのみにアクセスできること
赤線経路
- 要件②社外アカウント（B社など）へ直接アクセスできないこと
- 要件③IAM Identity Center経由で社外アカウントへアクセスできないこと

結論としてプロキシサーバでは特定のAWSアカウントへのアクセス制御はできません

早速結論を書いてしまいますが、見出しの通り、Squidなどのプロキシサーバでは現状こちらの制御はできません。プロキシサーバがもつドメインベースのURLフィルタリング機能ではAWSの仕様上できないのです。

ここからはその理由について、AWSの仕様とAWSのマネジメントコンソールにアクセスする際に裏側では何が起こっているのかに注目して紐解いていきたいと思います。

マネジメントコンソールへのアクセスに必要な許可ドメインは？

下記のAWSドキュメントにマネジメントコンソールへのアクセスに必要とされるドメイン一覧が記載されています。

裏側ではCloudFrontなど様々なサービス・ドメインにアクセスされていることがわかりますね。

ここでは★のドメイン「*.amazonaws.com」が必要なんだくらいを認識しておいてください。

*.amazonaws.com 　★重要です（理由は後述）
*.a2z.com
*.amazon.com
*.aws
*.aws.com
*.aws.dev
*.awscloud.com
*.awsplayer.com
*.awsstatic.com
*.cloudfront.net
*.live-video.net

また、IAM Identity Centerポータルサイトへのアクセスに必要なドメイン一覧が下記に記載されています。

*.awsapps.com (http://awsapps.com/) ※こちらも重要です（理由は後述）
*.signin.aws

AWSのサービスを使う際にアクセスされるドメインは？

AWSの各種サービスを使う場合は、サービスごとに用意された下記のエンドポイントにAPIリクエストが投げられます。

どのサービスを使うにしても、「*.amazonaws.com」のドメインにはアクセスされます。こういうわけで、前項に★で記載したドメインをプロキシサーバでアクセス許可することがどうしても必要になります。

マネジメントコンソールへアクセスする際に指定するURLは？

下記のAWSドキュメントにマネジメントコンソールへアクセスする方法が記載されています。

こちらによると、下記3つのアクセス方法があるようです

#	方法	アクセス先のURL
①	IAM Identity Centerのポータル経由	`https://<xxxx>.awsapps.com/start`
②	AWS公式サイトから対象アカウントにログインアクセス後にアカウントIDを入力しルートユーザorIAMユーザで認証	`https://console.aws.amazon.com`
③	対象アカウントに直接ログイン IAMのアカウントエイリアスを指定	`https://<アカウントエイリアス>.signin.aws.amazon.com/console/`

ということは・・・？

やりたいことをもう一度振り返りましょう。

ここまで説明してきたAWSの仕様を考慮すると、下記のようなフィルタをプロキシサーバで実装できれば、上記図の要件①～③の制御は実現できそうに思えますよね。

#	ドメイン	制御	理由
1	AAA.awsapps.com	許可	要件①③：Ａ社のIAM Identity Center経由してA社のAWSアカウントにのみアクセスするため
2	*.amazonaws.com	許可	要件①：A社のAWSアカウント上で各種サービスを操作するため
3	console.aws.amazonaws.com	拒否	要件②：社外のAWSアカウントに直接ログインできないようにするため（AWS公式サイト経由のログインを禁止）
4	*.signin.aws.amazon.com	拒否	要件②：社外のAWSアカウントに直接ログインできないようにするため（アカウントエイリアス指定のログインを禁止）
5	それ以外に必要なドメイン（*.cloudfront.netなど）	許可	割愛

しかし、このフィルタには落とし穴があります！

#4を拒否してしまうと、マネジメントコンソールへのサインインのアクションが一切できなくなります。実は、IAM Identity Center経由でマネジメントコンソールへアクセスする際、裏でsign専用のエンドポイント（signエンドポイント）へリクエストが発行されており、この動作が拒否されてしまうのです。（結果的に上記の図でいうオレンジ色の★のアクセスができなくなります。）

この動作を実際に検証して確認してみました。

検証してみます

構成図

構成は以下の通りです。
プロキシサーバの代表格であるSquidを使用しました。

URLフィルタの設定

Squidのconfファイルに下記の拒否リスト許可リストを定義しました。

◆拒否リスト
.signin.aws.amazon.com　　★


◆許可リスト　
.aws.amazon.com　#★より上に書くと、★の許可が聞かない（この行は★を包含する。また、上から順番に評価されるため）
.awsstatic.com
.amazonaws.com
.aws.a2z.com
.cloudfront.net
.aws.dev
assets.crowd.aws
.amazonwebservices.com
.amplifyapp.com
.ssl-images-amazon.com
fls-na.amazon.com
.signin.aws
xxxx.awsapps.com

IAM Identity Center経由でマネジメントコンソールへアクセスしてみる

IAM Identity Centerのポータルにはログインできましたが、そこからマネジメントコンソールへのアクセスに失敗しました。

上述したとおりの動作になりましたね。リージョンのsiginエンドポイント（<リージョン名>.signin.aws.amazon.com）にリダイレクトされ、SquidのURLフィルタで拒否されています。

ではプロキシサーバ以外なら制御できないか？

ここからは他の方法で制御できないか考えていきます。

AWSのAPIリクエストの中身でフィルタリングする

まず思いつくのがこちらの方法です。AWSサービスの操作は全てAWSへのAPIリクエストで行われているので、APIリクエストの中身をフィルタリングして、特定のAWSアカウント以外の通信を遮断できればやりたいことは実現できそうに思います。

しかし、AWSのAPIリクエストには、AWSアカウントのアカウントID情報を含まれていないため、この方法では実現できません。

APIリクエストに含まれる情報は「アクセスキー」と「シークレットキー」になります。具体的には、これらの文字列とリクエストパラメーターを含んだ認証情報（SigV4の署名情報）がリクエストには含まれます。これらの情報からはアカウントIDを特定することはできません。

認証情報（SigV4の署名情報）の詳細は下記のサイトにうまくまとめれているので気になる方はぜひ読んでみてください。

なかなか一筋縄ではいきませんね...

AWS Management Console プライベートアクセスの機能

2023年5月に待望の機能がAWSから発表されました。それが「Management Console プライベートアクセス」の機能です。

これはVPCエンドポイントを利用して、インターネットを抜けずに閉域網からマネジメントコンソールにアクセスできる機能です。さらに、VPCエンドポイントのポリシーにアクセス対象のアカウントIDを定義して、特定のAWSアカウントにのみマネジメントコンソールアクセスを限定することができます。

発表当初は東京リージョンが非対応だったのですが、最近東京リージョンでも対応されたことにより、こちらの機能が任意のAWSアカウントにアクセスすることを防ぐには第一候補となりました

以下、AWSドキュメントにある構成図です。

では、これを使えば万事解決か？

これで全て解決かというとまだ現状はそうではないです。というのも本サービスでは対応していないAWSサービスが散見されます。

どういうことかというと、Management Console プライベートアクセスの機能でマネジメントコンソールにアクセスしても、対応していないAWSサービスにはマネジメントコンソールから操作できないということです。

以下のAWSドキュメントに対応サービス一覧が記載されています。かなり多くのサービスが対応しているとわかりますが、RDSなどの主要なサービスが対応されていなかったりします。（2024年5月時点）

ただし、AWSはサービスの継続的な改善に定評があるため、今後のアップデートによって主要なサービスも対応してくれるはずです！みんなでAWSサポートにサービス改善要望を送りましょう！きっとAWSがなんとかしてくれます。

まとめ

AWSの本番環境から社外のAWSアカウントへのデータ持ち出しを防ぐ方法について、AWSの仕様を交えながら考察してきました。

プロキシサーバのURLフィルタリングではAWSアカウント単位でのアクセス制御ができないことがわかりました。これはマネジメントコンソールへのアクセスに必要なドメインを許可せざるを得ないためです。

一方、2023年5月にリリースされた「AWS Management Console プライベートアクセス」の機能を使えば、VPCエンドポイントのポリシーで特定のAWSアカウントへのアクセスを制限できることがわかりました。
ただし現状は、対応していない主要なAWSサービスもあるため、全ての運用要件を満たすことは難しいでしょう。

とはいえ、AWSはサービス改善に定評があります。私たちユーザから改善要望を積極的に出していくことで、将来的にはこの課題も解決されるはずです。AWSの新機能にも注目しながら、引き続きセキュアなAWS環境を実現を追求していきたいと思います。