はじめに
オンプレミス環境からAWS S3へファイルを転送したいが、オンプレミス側のサーバーにエージェントを入れる事ができない + ネットワーク機器の導入もできないと言う制約下で、SMBを使用した安全なファイル共有基盤を構築する必要がありました。
この記事は、その際に実施したセキュリティ対策をまとめたものです。
要件整理
本案件の要件と制約は以下の通りです。
機能要件
- 顧客オンプレミス環境（Windows Server）からAWS S3へファイルを転送する
- ファイルアップロードをトリガーに、S3イベントで後続処理を起動する
- SMBプロトコルでのファイル転送が必要
制約
- 顧客環境へのVPNエージェントやネットワーク機器の導入は不可
VPNが使えないので、インターネット経由での通信が前提となります。
ここがこの案件で最も設計が必要なポイントでした。
なぜStorage Gatewayを選定したか
ファイル転送の手段としては、いくつかの選択肢が考えられます。
AWS Transfer Family
SFTP/FTPSによるファイル転送が可能ですが、顧客の要望はSMBでのファイル転送でした。
顧客側のオペレーション変更が必須になるため今回の要件には合致しませんでした。
S3へのダイレクトアップロード
AWS CLIやSDKを使ったS3への直接アップロードも可能ですが、顧客側にAWSの認証情報付与・管理やCLI/SDKの導入が必要となり、運用負荷が上がります。SMBでのファイル転送という要件にも合致しませんでした。
⭐️ Storage Gateway（S3 File Gateway）
S3 File Gatewayは、SMBプロトコルでファイル共有を提供し、背後でS3にデータを同期します。顧客側からはネットワークドライブとしてマウントするだけで利用でき、オペレーションの変更が最小限で済みます。さらに、S3への同期後はS3イベント通知で後続処理を起動できるため、クラウド側での追加の処理の柔軟性を担保する事も容易です。
これらの比較から、顧客のSMB要件・運用負荷・後続処理との連携を総合的に判断し、Storage Gatewayを採用しました。
構成概要
簡単な構成図ですが、下記のイメージです。
Storage GatewayはEC2インスタンス上にデプロイしています。
顧客のWindows ServerからSMBプロトコルでStorage Gatewayに接続し、アップロードされたファイルはS3に同期されます。S3イベント通知により後続処理が起動する流れです。
多層防御の設計
なぜSMBをインターネット上に公開する事は危険か？
SMBが使用する445番ポートは、ランサムウェアやブルートフォース攻撃の標的になりやすいポートとして知られています。この辺りは下記の記事がわかりやすかったので是非読んでみてください🙏
参考: 「WannaCry」が採用した新たな感染手法とその対策
話を戻しますが、本案件ではVPNが使えないため、この445番ポートをインターネット上に公開せざるを得ません。そこで、以下4つの多層防御を実施しました。
SMB 3.xの暗号化強制
Storage Gatewayのセキュリティレベル設定で「暗号化の適用」を選択し、SMBv3の暗号化を強制しました。
この設定により、暗号化が有効になっているSMBv3クライアントからの接続のみが許可されます。SMBv1やSMBv2、暗号化なしのSMBv3接続は拒否されます。
これにより、インターネットを経由する通信であっても、転送データの機密性が確保されます。
セキュリティグループによるアクセス制御
Storage GatewayをホストするEC2インスタンスのセキュリティグループで、インバウンドルールを最小限に設定しました。
| プロトコル | ポート | ソース |
|---|---|---|
| TCP | 445 | 顧客のパブリックIP/32 |
上記のようなイメージです↑
許可するのはSMBの445番ポートのみ、かつソースを顧客のパブリックIPアドレスに限定しています。これにより、顧客環境以外からのアクセスは一切遮断されます。
認証の強制
ネットワークレイヤーの制御に加え、SMBファイル共有へのアクセスにはパスワード認証を設定しています。
Storage GatewayのSMBファイル共有では、ファイル共有のマウント時にパスワードの入力を求める設定が可能です。これにより、仮にネットワークレイヤーの制御を突破されたとしても、認証情報を持たないクライアントはファイル共有にアクセスできません。
EventBridge SchedulerによるEC2インスタンスの必要最適限の実行
たとえセキュリティグループで接続元を制限していても、EC2インスタンスが常時稼働している限り攻撃の可能性は存在し続けます。そこで、Amazon EventBridge Schedulerを使い、業務時間帯のみEC2を起動する制御を導入しました。
具体的には、1日の業務時間帯中のアップロードに必要な最低限の時間のみEC2インスタンスを起動し、業務終了後に停止するスケジュールを設定しています。
これにより、Storage Gatewayが外部に公開される時間を必要最小限に抑え、攻撃面を大幅に短縮することができます。
運用上の考慮点
SMBキャッシュのクリア
ここは少しハマったところなのですが、S3FileGatewayの仕様として、S3バケット側で直接ファイルが追加・更新された場合、ゲートウェイ側はそれを自動では検知しません。
今回のシステムフローでは、「アップロードされたファイルをトリガーに後続のバッチ処理が走り、その処理結果のファイルがS3に書き戻され、それを顧客が再びSMB経由で参照する」という往復のデータ連携が必要でした。
そのため、バッチ処理によってS3にファイルが配置された後、顧客がアクセスする前にStorage Gatewayのキャッシュを最新化（S3側の変更を再読み込み）する必要があり, 今回はEventBridge Schedulerを用いてキャッシュ削除APIを実行するアプローチを採用しました。
参考: AWS Storage Gateway AWS Black Belt Online Seminar
改善点
堅牢性を高めるのであれば、スケジュール実行ではなく、「後続バッチの処理完了イベント」をEventBridgeで検知し、Lambdaを起動する様なイベント駆動型のアーキテクチャにするのがベストプラクティスだと思います。
ただ今回の業務要件や運用サイクルの範囲内においては、現状のスケジュール実行の仕組みでも特に問題は起きておらず、十分に要件を満たすことができています。
コスト最適化
EC2を必要な時間帯のみ稼働させることで、常時稼働と比較してEC2のコストも削減できます。セキュリティ対策がそのままコスト最適化にもつながる設計です。
まとめ
本案件では、VPN不可という制約下において、以下の4つのレイヤーで多層防御を実現しました。
| レイヤー | 対策 | 効果 |
|---|---|---|
| プロトコル | SMB 3.x暗号化の強制 | 通信の機密性を確保 |
| ネットワーク | SGによるIP・ポート制限 | 不正アクセスの遮断 |
| 認証 | SMBファイル共有のパスワード認証 | 未認証アクセスの防止 |
| 時間制御 | EventBridge Schedulerによる起動制御 | 攻撃面の最小化 |
今後同様の制約を持つ案件で少しでも参考になれば幸いです。