読み込み中...
投稿日
Eponaで作ったインフラ環境に一手間加えてバックエンドへの不正アクセスを抑止する
はじめに
こんにちは。アプリケーション開発部の谷野です。
私の所属するアプリケーション開発部では、社内の様々なプロジェクトと協力して開発を行っているチームがあります。 私はその中で自社サービス開発を推進するインキュベーションセンターと協力するチームに所属しています。
直近では2021年5月に「オープンイノベーションプラットフォームbit-finder」のサービス更改に従事していました。
今回はそのサービスの中で利用しているDevOps環境構築キットEpona で作ったインフラ環境に一手間加えることで不正アクセスを抑止した事例を紹介します。
※本記事の内容については、後日Eponaのアップデートにより対応される見込みです。
本記事で利用している要件
- AWS環境
- Epona v0.2.1
- React TypeScript×Nablarchのアプリケーション
構成図
Eponaを利用して構成されるバックエンドアプリケーションの構成図はこちら。
背景
図のようにRuntime環境で稼働しているバックエンドアプリケーションはAPI呼び出しを公開インターネットから受けています。
今回構築した環境でテストを実施している際、バックエンドアプリケーションのアクセスログ上でサービスとは無関係なAPIを呼び出そうとしているログを検知しました。
主にセキュリティの観点から、このようなAPI呼び出しをバックエンドアプリケーションに到達させたくありません。
このため、想定しているAPIパスのアクセスのみをバックエンドアプリケーションに転送するよう、ALBへの対応を追加しました。
- 想定していないパスへのリクエスト
2021-04-09 07:24:21.381 -INFO- ACC http-nio-8080-exec-8 : @@@@ BEGIN @@@@ rid = [/api/v1/time] uid = [anonymous] url = [http://api.********.com/api/v1/time] - 正しいアクセスログ
2021-04-08 15:02:59.629 -INFO- ACC http-nio-8080-exec-2 : @@@@ BEGIN @@@@ rid = [/api/systeminfo/messages] uid = [anonymous] url = [http://api.bit-finder.jp/api/systeminfo/messages] method = [GET] status_code = [200]
対応内容
今回対応するにあたって以下の2つの方法を検討し、今後予定されているEponaのアップデート対応を見据えて(2)を選択する方針としました。
- (1) ALBの前にWAFを追加してパスを制限する
- (2) ALBのパスベースルーティングでパスを制限する
設定手順
- AWS Management Consoleにログインする
- サービスからEC2を選択する
- 左側タブメニューからロードバランサーを選択する
- 変更する対象のロードバランサーの「ルールの表示/編集」リンクを押下する
- 下図のようにパスルートの設定を限定したい内容（今回はAPIのもの）に変更し、それ以外のアクセスには403を返すよう変更する
実施結果
設定内容が反映されると下図のように誤ったパスでアクセスした場合には403を返却します。
最後に
本記事で設定した内容はこちらのモジュールを修正して反映することにより上書きされるため注意が必要です。
はじめに記述したとおりアップデートで対応されるまでの一時的な措置ですが参考になれば幸いです。
※ AWS、AWS WAF、Amazon RDS for PostgreSQL、Amazon ElastiCache for Redis、Amazon S3、Amazon Route 53、Amazon CloudWatchは、米国および/またはその他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
本コンテンツはクリエイティブコモンズ(Creative Commons) 4.0 の「表示—継承」に準拠しています。
