©MIXI ペイメント‧セキュリティフォーラム2024 株式会社MIXI 開発本部 MIXI M事業部 システムグループ 浅⾒ 公輔 クラウドを活⽤した EMV 3-Dセキュア内製開発

2 ©MIXI 発表者について ● 所属 ○ 株式会社MIXI 開発本部 MIXI M事業部 システムグループ ● 経歴 ○ 2014年 〜 2021年 ■ ユーザーアカウント基盤‧ゲームサーバ基盤のサーバサイド開発‧インフラ運⽤ ○ 2021年 〜 現在 ■ 株式会社ミクシィ（現 MIXI）に⼊社 ■ 基盤システム & ウォレットサービス「MIXI M」の開発‧運⽤ 浅⾒ 公輔

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セキュア内製開発

©MIXI MIXIの基盤システム & ウォレットサービス MIXI Mの紹介

55 ©MIXI MIXI Mとは 認証から決済までをワンストップで提供できる 基盤システム & ウォレットサービス アカウントを登録することで「個⼈ID」「決済情報」などをMIXIの様々 なサービス間で連携して利⽤できます

66 ©MIXI MIXI Mカード MIXI MカードはVisa/JCB加盟店で利⽤できるプリペイドカード アプリ上で発⾏したカードにチャージして利⽤可能

©MIXI MIXI Mのこれまでの取り組み

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 ©MIXI MIXI Mの運⽤⽅針 MIXI Mの運⽤⽅針 ⇒運⽤負荷をできるだけ下げる 少⼈数で開発‧運⽤（専属運⽤チーム無し） ⇒クラウドで運⽤負荷をできるだけ抑えた構成を検討

10 ©MIXI クラウドで運⽤負荷を下げるには クラウド事業者が管理する部分がより⼤きいサービスを利⽤する ● MIXI MはAWSを利⽤ ○ AWSは責任共有モデル ■ サービスごとにAWSと利⽤者の責任の境界が異なる ● 例: データベースサーバを動かしたい (EC2 vs RDS) ○ EC2インスタンス上に直接構築 ■ 利⽤者はホストOSの上の全レイヤに責任 ○ Amazon RDSを利⽤して構築 ■ ホストOSはAWSの責任 ■ 利⽤者はホストOSを触れないし気にする必要もない ● クラウド事業者が管理する部分がより⼤きいサービス（マネージドサービス）を利⽤する ○ → 利⽤者の責任範囲を減らせる ○ → 運⽤負荷の軽減

11 ©MIXI マネージドサービス活⽤に伴うメリット ● 例: PCI DSS要件5‧要件11 ○ ウイルス/マルウェア検出スキャン‧脆弱性スキャン‧IDS‧IPS‧FIM‧それらを含むプロセス稼働 状況のモニタリングなど ○ EC2インスタンスを建てる場合 ■ ホストの管理を含めて利⽤者が責任を負う ■ 上記要件を満たす構成で運⽤する必要あり ○ RDSのようなソフトウェアだけを利⽤できるマネージドサービスを利⽤する場合 ■ ホストの管理ごと上記要件をAWSに任せることができる ● → 利⽤者の監査対象外 ● 監査範囲の削減 ○ 運⽤負荷を軽減しつつ、セキュアな構成を実現できる ● AWSはPCI 3DS準拠なので、PCI 3DSに関しても同様に監査範囲を削減できる PCI DSS監査範囲の削減

12 ©MIXI MIXI Mの構成図（簡略版）

©MIXI EMV 3-Dセキュア内製開発

14 ©MIXI ECサイト 決済代⾏ カードホルダー 3DS Server Directory Server Access Control Server (ACS) イシュアー EMV 3-Dセキュア 概要図（簡略版） 決済 3DS認証 本⼈認証 内製化したEMV 3-Dセキュアシステム （今回お話しする対象）

15 ©MIXI 内製開発のモチベーション ● イシュアとしてのMIXI M ○ イシュイングしたプリペイドカードを3-Dセキュア対応する ■ Access Control Server (ACS)が必要 ● 加盟店‧決済代⾏としてのMIXI M ○ プリペイドカードへの残⾼チャージ取引を3-Dセキュア対応する ■ 3DS Serverが必要 ● ACS‧3DS Serverの利⽤額が無視できないほど⼤きく、運⽤上問題になっていた ○ JCBブランドでの残⾼チャージ対応開始に伴い、ACSと3DS Serverの内製化を決断 運⽤コスト削減のため

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 ©MIXI EMV 3-Dセキュアシステムの内製開発 ● 基本⽅針 ○ 既存のMIXI M決済システムと同じ技術を選定 ● 開発⾔語 ○ Elixir ● データベース ○ Amazon DynamoDB ● コンピュート ○ Amazon ECS on AWS Fargate ● AWSのマネージドサービスを中⼼に構成 選定技術

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 ©MIXI 内製EMV 3-Dセキュアの構成図（簡略版）

©MIXI PCI 3DS準拠に伴う対応

21 ©MIXI PCI 3DS準拠に伴う対応 ● Part2-要件3 ○ 3DSシステムとアプリケーションの保護 ○ 可⽤性の維持 ● Part2-要件4 ○ セキュアなリモートアクセス ● Part2-要件5 ○ TLS構成 ○ データストレージの暗号化 ● Part2-要件6 ○ HSMの運⽤ 以下のそれぞれについてMIXI Mで⾏った対応を説明します

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 ©MIXI PCI 3DS準拠に伴う対応 ● 主な要件 ○ 3DSシステムの可⽤性メカニズムの実装 ○ 実装された可⽤性メカニズムの監視‧保守 ● MIXI Mでの対応 ○ マネージドサービスではレジリエンスの責任をクラウド事業者が負うものが多い ■ DynamoDB‧KMS‧SQSなど ● 利⽤者側では対応不要 ■ ECS Fargateなど ● Availability Zoneの利⽤など考慮するべき点がいくつかある ● 可⽤性を管理するためのメカニズムが⽤意されている 可⽤性の維持 (Part2-要件3.5)

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 ©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 ©MIXI PCI 3DS準拠に伴う対応 ● 主な要件 ○ 機密データを保存する際は「強⼒な暗号化」で保護しなければならない ○ 暗号化の鍵管理はNIST SP 800-57のような業界標準に従う ● MIXI Mでの対応 ○ データベースはAmazon DynamoDBを採⽤ ■ MIXI M決済システムは全てのデータベースでDynamoDBを採⽤ ○ DynamoDBに保存されるデータは保管時に透過的にAES-256で暗号化されるため要件クリア ■ 鍵はAWS所有キー/KMSキー ● いずれにせよユーザーは鍵管理を⾏う責務がない ○ 保存⾃体が許可されない機密データがあることに注意 データストレージの暗号化 (Part2-要件5.4.2)

27 ©MIXI PCI 3DS準拠に伴う対応 ● Key-Value型のNoSQL ○ 3DSシステムは3DS認証取引ごとに電⽂処理を⾏うため、KVSとうまくマッチする ○ MIXI Mの決済システムも基本的にユーザーごと、取引ごとの処理なのでKVSとマッチする ● DynamoDBを採⽤した理由 ○ 無制限にスケール可能なスケーラビリティ ○ デフォルトで3AZにまたがる冗⻑化を⾏うアベイラビリティ ○ 完全IAMベースのアクセスコントロール ○ KMSベースのデータ暗号化 ● メリット ○ 運⽤の完全⾃動化‧オンデマンドキャパシティモードによる従量課⾦など ● デメリット ○ 複雑なクエリは難しい‧データ集計や解析に弱い‧ベンダーロックインなど 補⾜ - DynamoDBについて

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 ©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について

©MIXI 3DSサービス内製開発に伴う対応

31 ©MIXI ACS開発に伴う対応 ● EMV 3DS仕様 ○ 3DS認証が何らかの理由で⼀定時間内に完了しない場合、ACSは認証取引をタイムアウトさせる責 務がある ● MIXI Mの対応 ○ Amazon SQSの「遅延キュー」を使って⾮同期処理を実装する ■ キューメッセージの配信を指定した秒数延期することができる ○ EMVCo仕様で定義された秒数「遅延キュー」を設定 ■ 3DS認証が完了しているか判定→完了していない場合タイムアウト処理を⾏う ● こういったよくある要件に関してはマネージドサービス側で機能提供が⾏われている印象がある 3DS認証取引タイムアウトの実装

32 ©MIXI 3DS Server開発に伴う対応 ● 要件 ○ 3DS Serverで扱う⼀部のデータは機密扱いとし、⼀時的にしか保存が認められない ■ 「PCI 3DS Data Matrix」で定義されている ● MIXI Mの対応 ○ DynamoDBの「レコードTTL」機能を利⽤する ■ レコードごとにTTLタイムスタンプを設定でき、タイムスタンプの有効期限が切れるとレコ ードの物理削除が⾃動的に⾏われる ● 有効期限が切れてから物理削除されるまでにはラグがある ■ MIXI M決済システムでも活⽤している ● 例えばカード会員データの⼀時的保存など ● マネージドサービスで機能提供される「よくある要件」の⼀例 3DS機密データの⼀時的な保存

©MIXI まとめ

34 ©MIXI 本発表のまとめ ● クラウドのマネージドサービスを活⽤するメリット ○ クラウド事業者が⼤部分を管理するため、コンプライアンス監査範囲を削減できる ○ コンプライアンス準拠に必要な運⽤について、運⽤負荷の軽減が期待できる ● EMV 3-Dセキュア内製開発について ○ PCI DSS準拠だけでなく、PCI 3DS準拠に関してもマネージドサービスは有効に活⽤できる ○ マネージドサービスを中⼼に構成することで、⼯数をサービス開発に注⼒できた ■ → 少ない⼈員と短い開発期間でサービスリリースを達成できた クラウドを活⽤したEMV 3-Dセキュア内製開発

©MIXI