FinTechスタートアップ企業のインフラができるまで(構築編2部)

こんにちは！インフラを担当しております上平と申します。このエントリーでは弊社が運営するサービスB/43のインフラをどのように構築してきたかを紹介します。
スタートアップでイチからインフラを構築する大変さや面白さをお伝えできればと思います！

今回のエントリーは前回の構築編の2部となり サービスインフラ構築 の続きを紹介していきます。

セキュリティスキャン

前回の選定編でも書きましたが、PCI DSSではセキュリティスキャンを定期的に実施する必要があります。今回はセグメンテーションスキャンの内製化に関して紹介します。

なぜ内製化？

PCI DSSの要件上、内製化出来るものとできないものがあります。内製化することができればコスト削減を行えます。

診断名	内製化可否
外部ASVスキャン	不可
内部脆弱性スキャン	可能
WEBアプリケーションペネトレーション診断	不可
セグメンテーションスキャン	可能

なぜ必要？

弊社の環境のようにアカウントを分けた場合や、オンプレミス環境とDX接続されているなどネットワークセグメントが複数存在する場合に必要となります。今回で言うと、PCI DSS準拠アカウント「10.x.x.x/16」とPCI DSS非準拠アカウント「172.x.x.x/16」間で通信の可否をスキャンする必要があります。

逆を言うとセグメントが複数存在しない環境であればセグメンテーションスキャンは必要ありません。

どうやる？

古典的なやり方ですが、相互のVPCの全てのsubnet上にスキャン用のEC2を作成し、それぞれのsubnetに対してportscanを実施しています。スキャンした結果、意図しない通信が開放されていないかを確認する必要があります。

弊社の環境でのsubnet数は下記のようになっており、27回portscanを実施する必要があります。スキャンするためのEC2からnmapコマンドを用いてportscanを実施しております。

アカウント	subnet数
PCI DSS準拠アカウント	9
PCI DSS非準拠アカウント	3

デプロイ環境

デプロイ基盤は AWS CodePipeline を採用しています。 GitHubによるwebhookにて自動でdeployされるようにしており、GitHub側でgit-pr-releaseを用いてプルリクエストの自動作成を行った後、GitHub Actions にて release tag を作成しています。その release tag を AWS CodeBuild にてECR imageのタグとして設定できるようにしています。

PCI DSSでは内部脆弱性スキャンの実施を求められているため、イメージの push をトリガーとして ECR image scan が自動で行われるように設定しています。

また、コンテナ起動時にDBのスキーママイグレーションや環境変数の設定を実施していたのですが、複数コンテナを運用(起動)すると起動時のタスクが多重実行されてしまうため、pipelineに組み込む形にしております。

f:id:smartbank:20211221140904p:plain

バッチ基盤

airflow.apache.org

弊社では Airflow を採用しており以下を行っています。

バッチ処理のスケジュールに AirFlow を使っている
Airflowから AWS ECS のタスクを呼び出して、ECSタスクの中でバッチ処理を実行している

PCI DSS非準拠アカウントのバッチを実行するのは問題ありませんが、PCI DSS準拠アカウントでバッチを動かすには下記の2パターンの構築方法があり、それぞれ懸念点がありました。

PCI DSS準拠アカウント側にも Airflow を構築する
PCI DSS非準拠アカウントの Airflow から準拠アカウント側のバッチを動かす

PCI DSS準拠アカウント側にもAirflowを構築する場合の懸念点

オペレータがバッチ処理を操作するWebシステム（Airflow）がある場合はペネトレーションテストを実施する必要があるため、運用負荷や追加のコストが発生する

PCI DSS非準拠アカウントのAirflowから準拠アカウント側のバッチを動かす場合の懸念点

PCI DSSではバッチの動作だとしてもシステムを変更する可能性があるアカウント(IAMユーザーやロール)は全て管理する必要があります。また、PCI DSS準拠アカウントと非準拠アカウント間での情報連携(ネットワーク通信)では、以下の制約もあります。

リクエスト元	リクエスト先	通信可否
PCI DSS準拠アカウント	PCI DSS非準拠アカウント	可
PCI DSS非準拠アカウント	PCI DSS準拠アカウント	不可

PCI DSS非準拠アカウントからPCI DSS準拠アカウントにswitchロールしてバッチを動かしてしまうとPCI DSS非準拠のバッチサーバーが何らかの要因で乗っ取られた場合、環境変数やコマンドをOverrideしてバッチを実行され、PCI DSS準拠アカウントで意図していない挙動が起こせてしまいます。つまり、PCI DSS非準拠アカウントのバッチサーバーからPCI DSS準拠アカウントに対して直接バッチを実行できません。

懸念点を踏まえつつも、弊社では最終的には PCI DSS非準拠アカウントのAirflowからバッチを動かす 方を採用しました。

上記の通信制約上の問題は弊社では以下のような方法にて回避しております。結論から言うとAWSマネージド製品を利用して直接的ではなく間接的にバッチを実行する仕組みを構築しました。