クラウドを活用したEMV 3-Dセキュア内製開発 / ペイメント・セキュリティフォーラム2024

2024/3/5に開催されたペイメント・セキュリティフォーラム2024に登壇した、MIXI M浅見の発表資料です。

Transcript

1. ©MIXI ペイメント‧セキュリティフォーラム2024 株式会社MIXI 開発本部 MIXI M事業部 システムグループ 浅⾒ 公輔 クラウドを活⽤した EMV 3-Dセキュア内製開発
2. 2 ©MIXI 発表者について • 所属 ◦ 株式会社MIXI 開発本部 MIXI M事業部 システムグループ • 経歴 ◦ 2014年 〜 2021年 ▪ ユーザーアカウント基盤‧ゲームサーバ基盤のサーバサイド開発‧インフラ運⽤ ◦ 2021年 〜 現在 ▪ 株式会社ミクシィ（現 MIXI）に⼊社 ▪ 基盤システム & ウォレットサービス「MIXI M」の開発‧運⽤ 浅⾒ 公輔
3. 3 ©MIXI 本発表について • 概要 ◦ MIXIの基盤システム & ウォレットサービスMIXI MでPCI 3DS準拠と3DSサービスの内製開発を⾏い ました ◦ クラウドを活⽤してPCI 3DS準拠対応と3DSサービスを内製開発する際に⾏った各種の対応につい て、主に運⽤上の観点からご紹介します • 全体の流れ ◦ MIXIの基盤システム & ウォレットサービスMIXI Mの紹介 ◦ MIXI Mのこれまでの取り組み ◦ EMV 3-Dセキュア内製開発 ◦ PCI 3DS準拠に伴う対応 ◦ 3DSサービス内製開発に伴う対応 クラウドを活⽤したEMV 3-Dセキュア内製開発
4. ©MIXI MIXIの基盤システム & ウォレットサービス MIXI Mの紹介
5. 55 ©MIXI MIXI Mとは 認証から決済までをワンストップで提供できる 基盤システム & ウォレットサービス アカウントを登録することで「個⼈ID」「決済情報」などをMIXIの様々 なサービス間で連携して利⽤できます
6. 66 ©MIXI MIXI Mカード MIXI MカードはVisa/JCB加盟店で利⽤できるプリペイドカード アプリ上で発⾏したカードにチャージして利⽤可能
7. ©MIXI MIXI Mのこれまでの取り組み
8. 8 ©MIXI これまでの取り組み • 2019年2⽉ ◦ PCI DSS v3.2.1 準拠 ▪ イシュアー‧加盟店‧決済代⾏を兼ね揃えているため完全準拠 • 2019年11⽉ ◦ 6gramリリース • 2022年2⽉ ◦ 6gram→MIXI Mに名称変更 • 2023年8⽉ ◦ PCI 3DS v1.0 準拠 ▪ 後ほどお話しします • 2023年10⽉ ◦ 内製EMV 3DSシステム運⽤開始 タイムライン
9. 9 ©MIXI MIXI Mの運⽤⽅針 MIXI Mの運⽤⽅針 ⇒運⽤負荷をできるだけ下げる 少⼈数で開発‧運⽤（専属運⽤チーム無し） ⇒クラウドで運⽤負荷をできるだけ抑えた構成を検討
10. 10 ©MIXI クラウドで運⽤負荷を下げるには クラウド事業者が管理する部分がより⼤きいサービスを利⽤する • MIXI MはAWSを利⽤ ◦ AWSは責任共有モデル ▪ サービスごとにAWSと利⽤者の責任の境界が異なる • 例: データベースサーバを動かしたい (EC2 vs RDS) ◦ EC2インスタンス上に直接構築 ▪ 利⽤者はホストOSの上の全レイヤに責任 ◦ Amazon RDSを利⽤して構築 ▪ ホストOSはAWSの責任 ▪ 利⽤者はホストOSを触れないし気にする必要もない • クラウド事業者が管理する部分がより⼤きいサービス（マネージドサービス）を利⽤する ◦ → 利⽤者の責任範囲を減らせる ◦ → 運⽤負荷の軽減
11. 11 ©MIXI マネージドサービス活⽤に伴うメリット • 例: PCI DSS要件5‧要件11 ◦ ウイルス/マルウェア検出スキャン‧脆弱性スキャン‧IDS‧IPS‧FIM‧それらを含むプロセス稼働 状況のモニタリングなど ◦ EC2インスタンスを建てる場合 ▪ ホストの管理を含めて利⽤者が責任を負う ▪ 上記要件を満たす構成で運⽤する必要あり ◦ RDSのようなソフトウェアだけを利⽤できるマネージドサービスを利⽤する場合 ▪ ホストの管理ごと上記要件をAWSに任せることができる • → 利⽤者の監査対象外 • 監査範囲の削減 ◦ 運⽤負荷を軽減しつつ、セキュアな構成を実現できる • AWSはPCI 3DS準拠なので、PCI 3DSに関しても同様に監査範囲を削減できる PCI DSS監査範囲の削減
12. 12 ©MIXI MIXI Mの構成図（簡略版）
13. ©MIXI EMV 3-Dセキュア内製開発
14. 14 ©MIXI ECサイト 決済代⾏ カードホルダー 3DS Server Directory Server Access Control Server (ACS) イシュアー EMV 3-Dセキュア 概要図（簡略版） 決済 3DS認証 本⼈認証 内製化したEMV 3-Dセキュアシステム （今回お話しする対象）
15. 15 ©MIXI 内製開発のモチベーション • イシュアとしてのMIXI M ◦ イシュイングしたプリペイドカードを3-Dセキュア対応する ▪ Access Control Server (ACS)が必要 • 加盟店‧決済代⾏としてのMIXI M ◦ プリペイドカードへの残⾼チャージ取引を3-Dセキュア対応する ▪ 3DS Serverが必要 • ACS‧3DS Serverの利⽤額が無視できないほど⼤きく、運⽤上問題になっていた ◦ JCBブランドでの残⾼チャージ対応開始に伴い、ACSと3DS Serverの内製化を決断 運⽤コスト削減のため
16. 16 ©MIXI EMV 3-Dセキュアシステムの内製開発 • EMVCo仕様に即したシステム開発 ◦ EMVCo compliance取得が必要 ▪ Test Platform‧Test Laboratoryと契約してcomplianceテストに通過する必要がある • 3DSシステムを提供する環境のPCI 3DS準拠 ◦ Part1 ▪ 要件は全てPCI DSS要件に含まれている • MIXI MはPCI DSS準拠済みの環境上で3DSシステムを提供するため監査skip ◦ Part2 ▪ 7要件75項⽬ • こちらもPCI DSS要件と被っている要件がいくつかある • 接続先ブランドcompliance取得 必要な対応
17. 17 ©MIXI EMV 3-Dセキュアシステムの内製開発 • 基本⽅針 ◦ 既存のMIXI M決済システムと同じ技術を選定 • 開発⾔語 ◦ Elixir • データベース ◦ Amazon DynamoDB • コンピュート ◦ Amazon ECS on AWS Fargate • AWSのマネージドサービスを中⼼に構成 選定技術
18. 18 ©MIXI EMV 3-Dセキュアシステムの内製開発 • 内製開発PJ ◦ 2022年11⽉: PJ始動 ◦ 2023年10⽉: 内製ACS運⽤開始 ◦ 2023年12⽉: 内製3DS Server運⽤開始 • アサイン開発⼈員 ◦ 主担当1名、副担当1名 • 開発実働期間 ◦ ACS/3DS Server開発: それぞれ1〜2ヶ⽉ほど ◦ PCI 3DS準拠対応: 約1ヶ⽉ ◦ ブランド接続や既存システムとの繋ぎ込みなど: 約1ヶ⽉ • マネージドサービス中⼼に構成することで運⽤関係の⼯数がほぼ⽣じなかった ◦ → エンジニアの⼯数をサービス開発に注⼒することができた PJ規模‧⼯数について
19. 19 ©MIXI 内製EMV 3-Dセキュアの構成図（簡略版）
20. ©MIXI PCI 3DS準拠に伴う対応
21. 21 ©MIXI PCI 3DS準拠に伴う対応 • Part2-要件3 ◦ 3DSシステムとアプリケーションの保護 ◦ 可⽤性の維持 • Part2-要件4 ◦ セキュアなリモートアクセス • Part2-要件5 ◦ TLS構成 ◦ データストレージの暗号化 • Part2-要件6 ◦ HSMの運⽤ 以下のそれぞれについてMIXI Mで⾏った対応を説明します
22. 22 ©MIXI PCI 3DS準拠に伴う対応 • 主な要件 ◦ システムイメージや設定ファイルなどのベースライン構成を攻撃者から保護すること ◦ 動作しているアプリケーションが未認証の変更から保護されること • MIXI Mでの対応 ◦ アプリケーションとして動作しているコンテナを全て読み取り専⽤にする ▪ ベースライン構成の保護→変更不可のためベースライン構成の整合性が担保される ▪ 未認証の変更からの保護→変更不可のため⾃動的にクリア ▪ ECS FargateのロギングはAmazon CloudWatch Logsで⾏えるため、読み取り専⽤で問題な い • PCI DSS v4.0 要件11.5（IDS‧IPS‧FIMの要件）と関連 ◦ MIXI MではPCI DSSもコンテナを読み取り専⽤にすることでクリア 3DSシステムとアプリケーションの保護 (Part2-要件3.2, Part2-要件3.3)
23. 23 ©MIXI PCI 3DS準拠に伴う対応 • 主な要件 ◦ 3DSシステムの可⽤性メカニズムの実装 ◦ 実装された可⽤性メカニズムの監視‧保守 • MIXI Mでの対応 ◦ マネージドサービスではレジリエンスの責任をクラウド事業者が負うものが多い ▪ DynamoDB‧KMS‧SQSなど • 利⽤者側では対応不要 ▪ ECS Fargateなど • Availability Zoneの利⽤など考慮するべき点がいくつかある • 可⽤性を管理するためのメカニズムが⽤意されている 可⽤性の維持 (Part2-要件3.5)
24. 24 ©MIXI PCI 3DS準拠に伴う対応 • 主な要件 ◦ ⾮コンソールアクセス‧リモートアクセスに対して多要素認証が必要 • MIXI Mでの対応 ◦ いわゆる「踏み台サーバ」を設置しない「インスタンスレス」運⽤ ▪ 外部ネットワークからダイレクトに3DS環境に接続させない ◦ 全ての操作はAWS Management Consoleを介して⾏う必要がある ▪ → AWS Management Consoleでの認証は多要素認証を求める • PCI DSS v4.0 要件8.3（システムユーザーの認証に関する要件）や要件11.5（IDS‧IPS）と関連 ◦ システムユーザー認証の責務をAWS Management Consoleにオフロード ◦ 侵⼊検知の仕組みを導⼊する必要がない ▪ リモートコンソールが存在しないためそもそも侵⼊できない セキュアなリモートアクセス (Part2-要件4.2, Part2-要件4.3)
25. 25 ©MIXI PCI 3DS準拠に伴う対応 • EMV 3DS仕様 ◦ 他EMV 3DSシステムとの通信の際にmTLS認証が求められる • 主な要件 ◦ EMVCo仕様で定義されるTLSバージョン‧暗号スイートでの通信 ▪ 下位TLSバージョンや未承認の暗号スイートにロールバックしないこと ◦ 構成がモニタリングされること • MIXI Mでの対応 ◦ mTLS認証に関わるシステムはAmazon API GatewayとApplication Load Balancerを利⽤ ▪ AWS CloudFormation(IaC)を使って構成管理を⾏う • 構成設定と現状に差分がある場合、ドリフト検知機能で検出可能 • AWS Configを使うことで、リソースの変更にフックして検出した差分を通知可能 ▪ サービスを組み合わせて要件にマッチした構成にしていく TLS構成 (Part2-要件5.3)
26. 26 ©MIXI PCI 3DS準拠に伴う対応 • 主な要件 ◦ 機密データを保存する際は「強⼒な暗号化」で保護しなければならない ◦ 暗号化の鍵管理はNIST SP 800-57のような業界標準に従う • MIXI Mでの対応 ◦ データベースはAmazon DynamoDBを採⽤ ▪ MIXI M決済システムは全てのデータベースでDynamoDBを採⽤ ◦ DynamoDBに保存されるデータは保管時に透過的にAES-256で暗号化されるため要件クリア ▪ 鍵はAWS所有キー/KMSキー • いずれにせよユーザーは鍵管理を⾏う責務がない ◦ 保存⾃体が許可されない機密データがあることに注意 データストレージの暗号化 (Part2-要件5.4.2)
27. 27 ©MIXI PCI 3DS準拠に伴う対応 • Key-Value型のNoSQL ◦ 3DSシステムは3DS認証取引ごとに電⽂処理を⾏うため、KVSとうまくマッチする ◦ MIXI Mの決済システムも基本的にユーザーごと、取引ごとの処理なのでKVSとマッチする • DynamoDBを採⽤した理由 ◦ 無制限にスケール可能なスケーラビリティ ◦ デフォルトで3AZにまたがる冗⻑化を⾏うアベイラビリティ ◦ 完全IAMベースのアクセスコントロール ◦ KMSベースのデータ暗号化 • メリット ◦ 運⽤の完全⾃動化‧オンデマンドキャパシティモードによる従量課⾦など • デメリット ◦ 複雑なクエリは難しい‧データ集計や解析に弱い‧ベンダーロックインなど 補⾜ - DynamoDBについて
28. 28 ©MIXI PCI 3DS準拠に伴う対応 • 主な要件 ◦ ⼀部の秘密鍵管理にFIPS140-2 Level3以上もしくはPCI PTS認定のHSMの利⽤が求められる ◦ HSMの鍵操作における監査ログの維持 ◦ HSMの論理的‧物理的アクセスからの保護 • MIXI Mでの対応 ◦ キー管理サービスAWS KMSでHSM管理対象の秘密鍵を⽣成‧管理する ▪ 2023年5⽉にAWS KMS内部のHSMがFIPS 140-2 Level3にアップグレードされた ▪ AWS KMSはマネージドサービスなので、追加対応ほぼ無しで要件をクリア • 操作ログは全てCloudTrailに記録される • 論理的‧物理的アクセスからの保護要件はAWSにオフロード • AWS公式ブログ「MIXI M が AWS Key Management Service(KMS)を⽤いて 3D セキュアを実装、暗号鍵 管理とコンプライアンス対応のコストを最⼩化」 HSMの運⽤ (Part2-要件6)
29. 29 ©MIXI PCI 3DS準拠に伴う対応 • 当初はAWS CloudHSMの利⽤を検討していたが、以下の観点からKMSを利⽤するメリットが⼤きい ◦ コンプライアンス対応のための運⽤負荷 ▪ CloudHSMはバックアップや冗⻑化などの対応‧論理的アクセス保護要件への対応が必要だ が、KMSはほとんどの要件をAWSにオフロードできる ◦ SDKの利⽤ ▪ CloudHSMではHSM標準のSDKの利⽤が必要だが、KMSはAWS標準のSDKで利⽤可能 • → 開発コストの⼤幅な削減 ◦ ランニングコスト ▪ CloudHSMは時間課⾦だが、KMSはリクエスト課⾦ • → 想定よりもコストを抑えることができた • AWS KMSが標準でFIPS 140-2 Level3になったため、KMSで暗号化を⾏うS3やDynamoDBもFIPS 140-2 Level3のHSMで保護されているとみなすことができた 補⾜ - HSMについて
30. ©MIXI 3DSサービス内製開発に伴う対応
31. 31 ©MIXI ACS開発に伴う対応 • EMV 3DS仕様 ◦ 3DS認証が何らかの理由で⼀定時間内に完了しない場合、ACSは認証取引をタイムアウトさせる責 務がある • MIXI Mの対応 ◦ Amazon SQSの「遅延キュー」を使って⾮同期処理を実装する ▪ キューメッセージの配信を指定した秒数延期することができる ◦ EMVCo仕様で定義された秒数「遅延キュー」を設定 ▪ 3DS認証が完了しているか判定→完了していない場合タイムアウト処理を⾏う • こういったよくある要件に関してはマネージドサービス側で機能提供が⾏われている印象がある 3DS認証取引タイムアウトの実装
32. 32 ©MIXI 3DS Server開発に伴う対応 • 要件 ◦ 3DS Serverで扱う⼀部のデータは機密扱いとし、⼀時的にしか保存が認められない ▪ 「PCI 3DS Data Matrix」で定義されている • MIXI Mの対応 ◦ DynamoDBの「レコードTTL」機能を利⽤する ▪ レコードごとにTTLタイムスタンプを設定でき、タイムスタンプの有効期限が切れるとレコ ードの物理削除が⾃動的に⾏われる • 有効期限が切れてから物理削除されるまでにはラグがある ▪ MIXI M決済システムでも活⽤している • 例えばカード会員データの⼀時的保存など • マネージドサービスで機能提供される「よくある要件」の⼀例 3DS機密データの⼀時的な保存
33. ©MIXI まとめ
34. 34 ©MIXI 本発表のまとめ • クラウドのマネージドサービスを活⽤するメリット ◦ クラウド事業者が⼤部分を管理するため、コンプライアンス監査範囲を削減できる ◦ コンプライアンス準拠に必要な運⽤について、運⽤負荷の軽減が期待できる • EMV 3-Dセキュア内製開発について ◦ PCI DSS準拠だけでなく、PCI 3DS準拠に関してもマネージドサービスは有効に活⽤できる ◦ マネージドサービスを中⼼に構成することで、⼯数をサービス開発に注⼒できた ▪ → 少ない⼈員と短い開発期間でサービスリリースを達成できた クラウドを活⽤したEMV 3-Dセキュア内製開発
35. ©MIXI