inSmartBank

B/43を運営するSmartBank社のメンバーによるブログです

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マネージド製品を利用して直接的ではなく間接的にバッチを実行する仕組みを構築しました。

PCI DSS準拠アカウント側での構築内容

  1. バッチを実行する ECS タスクをインフラチームにて作成
  2. バッチが動くリポジトリにてバッチ実行時の設定内容を記載した yml ファイルを作成してコミット

事前にタスクとバッチ実行時の設定内容を定義しておくことで、Airflow から任意の設定やコマンドを実行することができないようにし、実行したいコマンドがあった場合は都度承認フローを経てタスクを作成するようにしています。

PCI DSS非準拠アカウントでの構築内容

  1. Airflow からバッチ処理をトリガーする
  2. バッチが準拠アカウントの S3 にファイルを設置する
  3. ファイル設置をトリガーにして、S3 Notification を用いて AWS Lambda を実行する
  4. Lambda が ECS タスクを実行する

図解すると下記のように、S3 と Lambda 処理を組み合わせて、間接的にバッチを実行するようにし、且つ任意のコマンドや環境変数で実行できないように、予めレビューを受けて管理された内容でバッチを動かすようコントロールしています。

f:id:smartbank:20211221142926p:plain

まとめ

B/43のインフラ構築編2部をご紹介しました。

PCI DSSのスコープを縮めて構築することは開発スピードを落とさないためにすごく重要なことですが、その結果アカウント間の通信において苦労したポイントがありました。 また、セキュリティスキャンに関しても内製化を行うために目的を理解しQSAに確認を取りながら進める点で苦労しました。

今後もセキュリティ面を担保しつつ、スピード感を持ってインフラ構築をしていきたいと思っています!
最後にスマートバンクでは一緒に B/43 を作り上げていくメンバーを募集しています! カジュアル面談も受け付けていますので、お気軽にご応募ください 🙌

smartbank.co.jp