決済カード開発の裏側 - スマートバンクにおけるインフラセキュリティアーキテクチャ大解剖

スマートバンク社の会社・事業説明

スマートバンクは、「人々が本当に欲しかったものをつくる」をビジョンに掲げ、家計簿アプリとVisaプリペイドカードが一体となった 「B/43（ビーヨンサン）」 を提供しています。
毎月の予算をカードにチャージして日々の支払いをすることで、支出が自動で記録され、見える化されるので、支出管理をかんたんに継続することができます。
個人の支出管理ができる「B/43マイカード」や、夫婦やカップルで共有できる 「B/43ペアカード」、お子さまのお小遣い管理に便利な 「B/43ジュニアカード」 を提供しています。

PCI DSSに準拠したインフラ構成

スマートバンクの提供する「B/43」のインフラ構成を解説するにあたってまずはPCI DSSについて簡単に説明します。

PCI DSSとは

PCI DSS（Payment Card Industry Data Security Standard）はクレジットカード業界のセキュリティ基準になります。スマートバンクは2024年8月31日付けで、PCI DSS v4.0に準拠しております。
PCI DSSを制定したのは、PCI SSC（PCI Security Standards Council）で国際カードブランド5社（JCB、Visa、Mastercard、 American Express、 Discover）によって設立された団体です。
PCI DSSは全部で12の要件となっており、中には定期的に対応を必要とするものがあります。
例えば90日毎にパスワードの変更を実施する（要件8 システムコンボーネントへのアクセスを識別・認証する）といった要件があります。
また、PCI DSSは1年に1回更新するための審査が必要であり、スマートバンクでは約3ヶ月ほど準備を含め工数をかけています。その時に監査員（QSA）に対応した要件のエビデンスを提出する必要があります。

アカウント分割による PCI DSS の範囲を絞る工夫

スマートバンクのインフラ構成は大きくPCI DSS 準拠環境とPCI DSS 非準拠環境に分かれており、構成図の左側の部分がPCI DSS 準拠環境です。

PCI DSSに準拠するスコープを絞ることでPCI DSSに対応するコストを必要最低限に抑えることができています。 スコープを狭めることによるメリットは以下のようなものがあります。

1. PCIDSS準拠のコストや運用負担の削減
2. セキュリティリスクの低減

PCIDSS準拠のコストや運用負担の削減

後述しますが、PCI DSSは1年に1度更新する必要があります。この更新においてQSAによる審査が必要となります。この時に各種要件に対応したエビデンスを提出する必要がありますが、スコープが広いと提出するエビデンスが増えてしまい、更新時の対応コストが上がってしまいます。
また、ASV（Approved Scanning Vendor）による脆弱性スキャンを四半期ごとに行う必要があり、スコープが広いとこのスキャン対象が増えてしまいます。

セキュリティリスクの低減

PCI DSSの運用を初めとしたインフラの運用を行うSREは基本的にPCI DSS準拠環境/非準拠の両アカウントにアクセスしますが、それ以外のエンジニアは通常、PCI DSS準拠環境にアクセスはできません。
PCI DSS準拠環境へのアクセスはIAMのスイッチロールを用いていますがSREへ事前に申請がないとスイッチロールができないようにアクセスコントロールを行っています。
これはPCI DSS準拠環境へのアクセスは事前に申請があり、準拠環境で必要な作業を行う場合のみに限定しているためです。

Fintech 特有の鬼門：セキュリティ&コンプライアンス

インフラにおける技術・ツール選定の背景・意図

サービスを提供するにあたりPCI DSSに準拠する必要があった訳ですが利用するクラウドベンダーがまずは準拠しているかが重要です。例えばAWSやGC、AzureはPCI DSSに準拠しています。オンプレミスで運用する場合にデータセンターを利用する場合も同じ様にPCI DSSに準拠しているかは重要です。

スマートバンクではAWSを選択していますが、インフラ構築を行ってくれたSREチームの同僚である上平さんの過去の経験からAWSを選定しています。余談ですが筆者も過去にPCI DSSに準拠したインフラ構築を担当した経験がありますがその時もAWSを選定しました。ホワイトペーパーが公開されていたりAWSサポートが手厚かった印象を持っています。

さて、実際にどのような要件があり、どのようなツールを選定しているのかご紹介したいと思いますが、いくつかPCI DSSの要件をピックアップし説明します。

要件5.2 悪意のあるソフトウェア(マルウェア)が防止または検出され、対処されている

EC2の場合ではウイルススキャンを実施するためにエージェントのインストールやウイルス定義の更新、実際の対応が必要となり運用するコストが高くなってしまいます。
スマートバンクではECS Fargateを採用しており、readonlyRootFilesystem:trueとすることでこの課題をクリアしています。readonlyRootFilesystem:trueとすることでルートファイルシステムが読み取り専用になり、マルウェアの設置を防いでいます。

要件6.3 セキュリティの脆弱性を特定し、対処している

コンテナイメージの脆弱性はECRのイメージスキャンを利用することで脆弱性の検知を行っています。スキャンのタイミングはイメージがプッシュされる度に実行されるようになっており、結果はSlackに通知されるようになっています。 脆弱性が発見された場合はSREによって対応し、再度スキャンを行います。

要件10.3 監査ログが破壊や不正な改ざんから保護されていること

システムや業務で必要な場合を除き、IAMロールのポリシーにS3に対する更新・削除といったアクションはDENYとしています。加えてCloudTrailのログファイルの整合性の検証機能の有効化、S3のObject Lockの有効化を実施しています。

要件10.4 監査ログをレビューし、異常または疑わしいアクティビティを識別することができる

Amazon GuardDutyを利用しセキュリティイベントの異常を検知できるようにしています。また、1日に1回の頻度でLambdaからAthenaに対してログに機密情報が含まれていないかクエリを投げる機構が導入されています。

ツールの選定の背景やセキュリティに関する要件をどのようにクリアしているか説明いたしました。構築時の詳細な話は上平さんが過去にブログを書いてくれているのでぜひこちらもご覧ください。

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

YAPC::Hakodate 2024にてCTOの@yutadayoさんが発表したクレジットカードを製造する技術ではカードの製造工程についての話がありました。印刷会社にカード情報を連携する処理もAWS上で構築しており、S3とLambda、ECSのバッチサーバーを組み合わせて実現しています。

PCI DSSの更新

先ほどQSAにエビデンスを提出していると記載しました。PCI DSSの更新は1年に1回あり、先述した要件を満たしているエビデンスを提出しています。
スマートバンクにおけるPCI DSSの対応については別途ブログを書かせて頂きましたので詳しくはこちらをご覧ください。

PCI DSS v4.0準拠までの道のりとこれからについて

ここではスマートバンクとQSAの関係性についてご説明します。
先述した要件以外にもたくさんの要件があり、SREだけでは完結しない要件もあります。例えばスマートバンクでは物理カードを厳重に管理しており、その棚卸し作業をCSチームに実施していただいております。他にもエンジニア向けに利用しているPCのパスワード変更の依頼など社内に対する依頼もあったりします。
スマートバンクとQSAとの関係性をまとめた図が以下になります。



左側がスマートバンクのPCI DSSの運用・審査に関係しているメンバーです。

• SRE
  
  • PCI DSSの運用・審査の対応を主導しています。
    
  • PCI DSSの要件を満たしているエビデンスをQSAに提出します。
    
  • 現在は情シスも兼務しており社内ネットワーク機器のパスワード変更に対応しています。
    
• カスタマーサポート
  
  • スマートバンクでは物理カードを提供しているため、物理カードをセキュリティルーム内の施錠された金庫で管理しています。この物理カードの棚卸しを実施して頂いています。
    
• 社員
  
  • 開発者
    
    • 利用しているアカウントのパスワード変更の対応をしています。
      
    • ベンダーへの脆弱性診断の準備（APIの実行手順）と対応を行っています。
      
  • その他の方
    
    • PCI DSSの要件には社員への情報セキュリティポリシーの向上を目的としたトレーニングを実施が必要となっておりトレーニングを受けて頂いています。（一例）
      

右側はQSAを表しています。

• 担当者
  
  • スマートバンクに対してPCI DSSの要件を満たしているエビデンスの提供を求めます。
    
  • 提出されたエビデンスの精査を行い、審査が完了すればAOC（準拠証明書）を作成します。
    

サービス運用の実践策

スマートバンクではサーバーサイド観点とインフラ観点の2つの軸でパフォーマンスミーティング（以下パフォミ）を開催しています。それぞれ2週間毎に実施されており、サーバーサイドのパフォミではサーバーサイド、モバイル、SRE エンジニアが参加しています。インフラのパフォミはSREのみで実施し、気になる点があればサーバーサイドに確認を取っています。
それぞれのミーティングの内容は以下の通りです。

サーバーサイドのパフォミ

• 内容
  
  • APMにNewRelicを利用しており、各APIサーバーのSummary、Slowest average response time、Slowest query timeを確認
    
  • エラートラッキングにSentryを利用しておりエラーの内容を確認
    
  • アプリケーションで利用しているDBのメトリクスを確認
    
  • SLI/SLOのエラーバジェットの確認
    
  • その他共有事項の確認
    

SLI/SLOの内容についてまとめた資料がありますのでよろしければご覧ください。

• 我々はこうしてSLI/SLOを設計し 運用を始めました -これからSLI/SLOの運用を始める人に向けて-
  
• ゆるっと話すSLI/SLOを設定してよかったこと出来ていないこと
  

過去にエラーバジェットが減少することが続いたことがありました。サーバーサイドに調査頂き無事解消することが出来ています。その時の対応をサーバーサイドエンジニアの栗栖さんがブログにしてくれていますのでぜひご覧ください！

インデックスの"正解"を探せ！決済レスポンスタイムを改善したパフォーマンスチューニング

インフラのパフォミ

• 内容
  
  • 広くサービス運用に関連するアプリケーションのメトリクスをCloudWatchを利用して確認
    
    • 例えばバッチサーバーのリソース状況やメールのバウンスレートの確認
      
  • Redashでログのステータスコード（4xxと5xx）別に集計しており異常にスパイクしているところがないか確認
    
  • AWSのコストの確認
    

サーバーサイドのパフォミはサービスに直結するアプリケーションのパフォーマンスチェックが主ですが、インフラのパフォミでは広くパフォーマンスやリソースの状況を確認するのでそういった違いがあります。
アラートの振り返りを火曜日、木曜日に実施しているSREの朝会で行っています。アラートのレベルをwarningとemergencyの2種類に分類しており、それぞれ違うSlackチャンネルに通知がきます。スマートバンクではドキュメント管理にNotionを利用しており、emergencyに通知されたアラートをNotionのデータベースで管理しています。

現在の課題と今後の展望

「スケーラブルなインフラをつくり、安心して使っていただけるサービスを提供する」というミッションのもと、インフラの運用・保守に加え、PCI DSSの定期的な更新作業を行っています。SREは攻守のバランスを求められると思いますが、2024年は守りにリソースを使ったと思っています。それはPCI DSS v4.0の対応に向けての取り組みや更新対応のコストが大きくあったからです。
2025年もPCI DSS v4.0への取り組みは続きますが、開発生産性能向上であったりセキュリティガバナンスの向上など攻めと守りをしっかりと行っていきたいと考えています。

執筆

中野 雅之(@maaaato)
X: @maaaato

株式会社スマートバンク エンジニアリング本部
SREチーム所属