初めまして！インフラを担当してます上平と申します。 このエントリーではFintech事業を実現するインフラ構築に関して紹介します！ スタートアップ企業でイチから構築する大変さや面白さをお伝えできればと思います！
Fintech事業において事業内容にもよりますが、我々のようなカード発行会社の場合、PCI DSSというカード業界における国際セキュリティ基準への準拠が必須となります。 弊社ももちろんPCI DSSに準拠しておりますが、準拠のためにはインフラ構築を始めるタイミングから考えることがたくさんあります。
今回から、選定編、構築編、運用編と3部に分けて弊社の取り組みを紹介させていただきます。
そもそもPCI DSSとは？
PCI DSSとは、クレジットカード情報の安全な取り扱いを目的に策定されたクレジットカード業界における国際セキュリティ基準のことです。 国際クレジットカードブランドであるVISA、Mastercard、JCB、American Express、Discover（国際カードブランド５社）によって策定されました。
準拠することで最新のセキュリティ基準に則ってクレジットカード情報を取り扱っていることが立証され、不正アクセスから自社のサイトを守り、悪用/情報盗用等のリスクを低減できます。
PCI DSSに準拠したシステムが、もしクレジットカード情報の漏えいが発覚し不正使用された場合は、クレジットカード会社からのペナルティが免責される場合があります。弊社はカード発行会社(イシュア)になりますので、準拠は必須です。
選定編
インフラ基盤
インフラ基盤にはクラウド基盤が1択でした。
前職でPCI DSSに準拠した経験があり、以下の点から迷いはありませんでした。
- PCI DSS観点の大きな差はデータセンターなどの要件9がほぼ全てスキップできる事
- PCI DSSに限った話ではないが、企業にとってオンプレミスで構築/運用していくことはかなりのハードルになる事
クラウド基盤を使用するとは言えAWS,GCP,Azureなど色々ありますが、 私の今までのスキルセットと、セキュリティ実績が高かったことからAWSでいくことにしました。 AWSではPCI DSSに準拠しているため、QSA(Qualified Security Assessor)も判断し易い環境であるのは間違いないと思います。
https://d1.awsstatic.com/whitepapers/ja_JP/compliance/pci-dss-compliance-on-aws.pdf
AWSアカウント
PCI DSSの要件では、大規模な変更を実施した場合はセキュリティスキャンを実施するなどシステム変更において厳しい制約があります。
新機能などをリリースする度にセキュリティスキャンや外部の監査を受ける必要があるとシステムの開発スピードが低下してしまうという懸念があったので、当初は1アカウントで実施するつもりでしたが、カード情報を扱うシステム(PCI DSS準拠対象)とユーザー情報を扱うシステム(PCI DSS非準拠対象)でアカウントを分けてPCI DSSのスコープを小さくするという事を実施しました。
アカウント間はPeeringして通信可能にし、問題は解決できましたが、PCI DSS非準拠アカウントからPCI DSS準拠アカウントに通信してはならないという新たな問題が浮上します。
これは構築時に大きな問題となりましたが、現在はマネージドサービスを駆使することでクリアしています。 このあたりは、次回記載する構築編で詳しく書こうと思います。
サーバー環境
サーバー環境にはEC2環境とコンテナ環境のどちらか2つの選択肢がありました。
PCI DSSの要件を考慮するとEC2の方が要件に沿った運用ができますが、守らなければならない要件や日々実施する要件が多いのもEC2になります。 コンテナでの運用を考慮すると免除可能な項目が見えてきたため、結局コンテナを採用しました。
しかしながらAWSコンテナに関してもECS,Fargate,EKSがあり、それぞれの選定にも悩みました。 個人的にはEKSで構築を考えておりましたが、AWSの方と相談させていただき、懸念点がいくつか見つかったため断念しました。
ECSでの構築を考えた際は、起動タイプに悩まされました。 ECS on EC2 (以下ECS) とECS on Fargate (以下Fargate) で考え、以下の点からFargateを採用しました。 現在のサーバー構成では全てFargateで運用しています。
- Fargateだとコンテナのリソースのみを考慮するだけで良い
- ECSだとHOSTのスケールも考慮する必要がある
- Fargateだとコンテナイメージのみのセキュリティ担保で良い
- ECSだとHOSTのセキュリティも担保する必要がある
- Fargateだとsshログイン不可 + rootファイルシステムをreadonlyにして IDS / IPS をクリア可能
- ECSだとHOSTにDeepSecurityなどのagentを入れて IDS / IPS を実施する必要がある
ログ基盤
初期段階である程度使えるものにしないといけないため、ログ基盤はかなり考えました。
当初サイドカー形式でログ転送することを考えていましたが、ログがロストすることは避けられないことをAWSの方々にアドバイスいただき採用を見送りました。 (サイドカー形式でのdeployなどはどうしても停止してしまう)
PCI DSSではログは最低で365日保存しておく必要があり、直近3ヶ月分は即時検索可能にしておくことが求められます。
DataDogなどのサードパーティ製品も検証しましたが、料金が高くコスト感で見合わなかったので、初期構築コストを抑えた下記のような構成にしAthenaで検索できるようにしています。
バッチ基盤
今まではバッチサーバーと言われるシングル構成でサーバーを作ることが多かったのですが、 シングル構成ではサーバーがdownするとバッチは実施されず、バッチ間での連携などができないという問題があったため、今回はAirflowを採用しました。なお、現在はAWSマネージドでAirflowがあるので乗り換えも検討しています。
AirflowをPCI DSS対象アカウントに構築してしまうとweb画面があるのでセキュリティスキャンを実施するなど、要件に準拠する必要がでてきてしまいます、したがってAirflowをPCI DSS非対象のアカウントに構築し、PCI DSS対象アカウントのバッチは S3+Lambdaを活用して実行しています。 このあたりの詳しくは次回以降に書こうと思います。
セキュリティスキャン
PCI DSSではセキュリティスキャンを定期的に実施する必要があります。
- 年一回: WEBアプリケーションペネトレーション診断 (資格のある第3者による診断)
- 半年に一回: セグメンテーションスキャン
- 四半期に一回: 外部ASVスキャン、内部脆弱性スキャン
これら全てを外注すると費用コストが高くなるので社内で実施を検討したのですが、内製化して実施できないものもあります。
| 診断名 | 内製化可否 |
|---|---|
| 外部ASVスキャン | 不可 |
| 内部脆弱性スキャン | 可能 |
| WEBアプリケーションペネトレーション診断 | 不可 |
| セグメンテーションスキャン | 可能 |
ASV(Approved Scanning Vendor)スキャンは内製化できず、PCI DSS管理機関から認定された企業にスキャンしてもらう必要があります。
https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors
また、ペネトレーション診断も資格のある第3者による診断が求められていますが、これは必須ではなくWAF(Web Application Firewall)を導入するか選択可能です。 弊社ではWAFとペネトレーション診断の両方を実施しております。
現在は内部脆弱性スキャンとセグメンテーションスキャンの仕組みを構築して社内で実施し、同時にコストを抑えるようにしています。
オフィス基盤
オフィスではWifiなどを使う通常業務と、PCI DSS対象アカウントへのリモートでの障害対応は完全に分離しなければなりません。 ネットワーク物理回線から分離が必要となり、社内にPCI DSS用回線を引くことから実施しました。 回線増設後はPCI DSS専用回線とし、通常業務で使用してはいけません。
障害対応時はVPNを使って社内ルーターへアクセスし、さらにAWSに対してVPNを張っており、IAM認証を用いて内部通信でAWS環境に接続します。 社内ルーターは実績の高いYamahaRTXを用いてluaスクリプトをRTX内で動かし、ワンタイムパスワードを使用してVPN接続するように設定しております。
まとめ
ざっくりFintechインフラ構築の選定編を記述しました。 PCI DSSに準拠することが前提でインフラ選定をすることは割と大変でした。 これからPCI DSSに準拠される方は自己問診(SAQ)を頭に入れておくことをおすすめします。
PCI DSSに準拠する際はインフラ選定時点で先まで見据えた選定を行わないと後々大変な思いをすることがあります。
本番稼働開始から1年近く経った今振り返ってみると、開発のスピードを損ねず、かつ比較的低コストでの構築と運用ができていると思っています。前職でPCI DSSに準拠した経験を生かした技術選定の結果として現時点では上出来と自負はしていますが、まだまだ改善するポイントはあります。今後の運用改善が楽しみです。
