Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
クラウドを活用したEMV 3-Dセキュア内製開発 / ペイメント・セキュリティフォーラム2024
Search
MIXI ENGINEERS
PRO
March 07, 2024
Technology
1
210
クラウドを活用したEMV 3-Dセキュア内製開発 / ペイメント・セキュリティフォーラム2024
2024/3/5に開催されたペイメント・セキュリティフォーラム2024に登壇した、MIXI M浅見の発表資料です。
MIXI ENGINEERS
PRO
March 07, 2024
Tweet
Share
More Decks by MIXI ENGINEERS
See All by MIXI ENGINEERS
MIXI における技術広報とその役割
mixi_engineers
PRO
2
160
セキュリティ監視の内製化 効率とリスク
mixi_engineers
PRO
7
1.8k
IT企業でロボットを作った話 / A story about building a robot in an IT company
mixi_engineers
PRO
2
54
「共闘ことばRPG コトダマン」 SREチーム流 アプリのユーザー体験向上を支えるオブザーバビリティ
mixi_engineers
PRO
1
190
MIXI M のこれまでとこれから / Welcome Fintech Community #2
mixi_engineers
PRO
1
140
Git 研修 Advanced【MIXI 24新卒技術研修】
mixi_engineers
PRO
3
670
データベース研修 DB基礎【MIXI 24新卒技術研修】
mixi_engineers
PRO
5
820
データベース研修 分析向けSQL入門【MIXI 24新卒技術研修】
mixi_engineers
PRO
4
430
テスト・設計研修【MIXI 24新卒技術研修】
mixi_engineers
PRO
3
520
Other Decks in Technology
See All in Technology
Develop to Survive - YAPC::Hakodate 2024 Keynote
moznion
8
2.1k
ADRを運用して3年経った僕らの現在地
onk
PRO
10
4.8k
普通の Web エンジニアのための様相論理入門 #yapcjapan / YAPC Hakodate 2024
ytaka23
5
1.3k
Perlで始めるeBPF: 自作Loaderの作り方 / Getting started with eBPF in Perl_How to create your own Loader
takehaya
1
810
それでもやっぱり ExpressRoute が好き!
skmkzyk
0
230
【shownet.conf_】多様化するネットワーク環境を柔軟に統合するルーティングテクノロジー
shownet
PRO
0
360
OPENLOGI Company Profile for engineer
hr01
1
12k
Assisted reorganization of data structures
ennael
PRO
0
250
「ばん・さく・つき・たー!」にならないためにSHIROBAKOから 学んだこと
ysknsid25
3
650
OPENLOGI Company Profile
hr01
0
54k
【shownet.conf_】トポロジ図の歩き方
shownet
PRO
0
480
Semantic Kernel の Agent 機能試してみた!
okazuki
1
130
Featured
See All Featured
Fashionably flexible responsive web design (full day workshop)
malarkey
404
65k
Six Lessons from altMBA
skipperchong
26
3.4k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
The World Runs on Bad Software
bkeepers
PRO
65
11k
4 Signs Your Business is Dying
shpigford
180
21k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
38
2.1k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Building an army of robots
kneath
302
42k
Producing Creativity
orderedlist
PRO
341
39k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Done Done
chrislema
181
16k
Bash Introduction
62gerente
608
210k
Transcript
©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