2024年4月5日8:30
「MIXI M」は、MIXIが開発・運用している基盤システムおよびWALLETサービスである。少人数で開発・運用を効率的に進めるために、クラウドのマネージドサービスを積極的に採用した。「MIXI M」ではEMV 3-Dセキュア対応を行うために、3-DセキュアサービスであるAccess Control Serverと3DS Serverをそれぞれ内製開発した。クラウドを活用してPCI 3DS準拠対応を行い、また3-Dセキュアサービスを内製開発する際に行った各種の対応について詳しく紹介する。（2024年3月5日開催「ペイメント・セキュリティフォーラム2024」より）
株式会社MIXI 開発本部 MIXI M事業部 システムグループ 浅見 公輔氏
クラウドを全面的に活用して
PCI 3DS準拠のサービスを内製開発
MIXI 開発本部の浅見です。私は以前、ユーザーアカウント基盤や、ゲームサーバ基盤のサーバサイド開発に携わっていた経験があり、2021年にミクシィ（現：MIXI）に入社して以来、基盤システム＆ウォレットサービスである「MIXI M」の開発・運用に携わってきました。
「MIXI M」はPCI 3DSに準拠しており、3DSサービスを内製開発しています。われわれはクラウドを全面的に採用・活用してPCI 3DSに準拠し、3DSサービスを内製開発いたしました。その際に行った各種の対応について、主に運用上の観点からご紹介させていただきます。
まず「MIXI M」についてご紹介いたします。「MIXI M」は認証から決済までをワンストップで提供できる基盤システムであり、ウォレットサービスです。ユーザーは「MIXI M」にアカウントを登録することで、MIXIのほかのサービスで個人IDを連携して利用できたり、決済を行ったりすることができます。ユーザーはクレジットカードや銀行口座からお金を残高としてチャージします。チャージしたお金を使って、たとえばMIXIのスポーツ事業の1サービスである「TIPSTAR」では、競輪やオートレースの車券チケットを購入することができます。
「MIXI M」でチャージしたお金はMIXIのほかのサービスで決済に利用できると同時に、プリペイドカードの残高としても利用することができます。アプリ上でプリペイドカードを即時発行して非対面決済で利用できると同時に、実物のプリペイドカードの発行を申請すれば実店舗での対面決済でも利用することができます。
このように「MIXI M」は残高をクレジットカードからチャージし、ほかのサービスから決済利用できるという点で、加盟店と決済代行の役割を担っています。一方でプリペイドカードを発行して残高を利用できるという点でイシュアでもあります。
運用負荷を最小限に抑えるため
AWSのマネージドサービスを全面活用
「MIXI M」は2019年2月にPCI DSSに準拠しました。先ほど申し上げたように「MIXI M」はイシュア、加盟店、決済代行の機能を兼ね備えていますので、12要件すべてに完全準拠しました。同年11月に6gramの名称で最初のリリースを行い、2022年2月に「MIXI M」に名称変更。そして2023年8月にPCI 3DSに準拠し、10月に内製のEMV 3DSシステムの運用を開始しました。
われわれは運用の負荷をできるだけ下げることを運用方針として掲げています。理由としては、サービス開始当初から多くても10名程度という少人数で開発・運用を行う必要があったからです。インフラやSREのような専属の運用チームはなく、エンジニアメンバー全員がサービス開発からインフラ運用までフルスタックに携わっています。そのため、サービス開発にできるだけ集中できるように、運用負荷をできるだけ低く抑えることが非常に重要でした。「MIXI M」にはこういった背景があり、サービス開始当初からクラウドを全面的に採用して運用負荷をできるだけ低く抑えられる構成になるように検討しています。
では、クラウドで運用負荷を下げようと思ったとき、どういったアプローチをとれるでしょうか。有効なアプローチのひとつに、クラウド事業者が管理する部分がより大きいサービスを利用するという考え方があります。
「MIXI M」ではクラウド事業者としてAWSを採用しています。AWSでは責任共有モデルというコンセプトを採用しています。これは、AWSのサービスごとにAWSとその利用者との間の責任の境界が異なるというものです。
一例を挙げますと、たとえばAWSでデータベースサーバを動かしたいとします。どういった方法でデータベースサーバを動かすかについてはいくつかのアプローチが考えられると思いますが、ここではEC2インスタンス上に直接データベースサーバを構築するときと、RDSというマネージドサービスを採用してデータベースサーバを構築するときとで比較します。
EC2インスタンス上にデータベースサーバを構築するときに、利用者が責任を負うレイヤは、ホストOS上の全レイヤです。一方でRDSを利用してデータベースサーバを構築するとき、データベースサーバが稼働するホストOSはAWSが管理責任を負うため、それ以下のレイヤについては利用者は責任を負う必要がありません。このようにクラウド事業者が管理する部分が大きいマネージドサービスを利用することで、利用者の責任範囲を減らすことができ、結果的に運用負荷を削減することができます。
PCI DSS準拠という観点でいうと、マネージドサービスの利用には、監査範囲を削減できるというメリットがあります。たとえば要件5や要件11にはウイルス/マルウェア検出スキャン、脆弱性スキャン、IDS、IPS、FIM、それらを含むプロセス稼働状況のモニタリングなどさまざまな監視要件があります。EC2インスタンスを使って運用する場合、ホストの管理を含めて利用者が責任を負う必要がありますので、これらの監視要件をすべて満たす構成を検討する必要があります。一方でRDSのような利用者がソフトウェアだけを利用できるマネージドサービスを利用する場合、PCI DSS要件を満たすためのホスト運用はすべてAWSに任せることができます。ホスト運用はクラウド事業者の責任であるため、利用者側の監査の対象から外れます。監査範囲の削減は運用負荷を軽減できるだけでなく、運用自体をクラウド事業者にオフロードすることでセキュアな構成を担保することができます。
ここではPCI DSSを例にお話ししましたが、AWSはPCI 3DS準拠でもあります。そのためPCI 3DS準拠に関しても同様にマネージドサービスを利用することで監査範囲を削減できます。
では「MIXI M」が実際にどのような構成を採用しているかについて紹介いたします。ユーザーはApplication Load Balancerを介してコンテナをオーケストレーションするマネージドサービスであるECS FargateにAPIリクエストを行います。ECS FargateはNetwork Load BalancerとDirect Connectを介して決済ネットワークに接続します。データベースにはDynamoDBを、売上データなどを格納するオブジェクトストレージにはS3を利用しています。AWSのさまざまな鍵管理はKMSで行っています。アプリケーションログや監査ログはCloudWatchおよびCloudTrailに集約され、バッチシステムとしてCodeBuildを採用しています。
特徴としては、データベースサーバをはじめとして、アプリケーションサーバや鍵管理、ログ収集など、全面的にマネージドサービスを利用していることが挙げられます。環境にログインするためのいわゆる踏み台サーバのようなインスタンスも存在せず、すべての操作はAWSのマネジメントコンソールから行います。これらのサービス選定はすべて運用負荷を減らすことを念頭に置いて行っています。結果としてサービス開始当初から現在に至るまで、小規模なチームで開発・運用を行うことができています。
3DS ServerとACSを内製開発
開発期間1年で運用を開始
続いてEMV 3-Dセキュア内製開発プロジェクトについてご説明します。加盟店や決済代行会社が3D認証を行うとき、3DS Serverに3DS認証リクエストを投げます。 認証リクエストはDirectory Serverを介してACSに到達します。ACSはイシュアとやり取りを行いながら、必要に応じてカードホルダーの本人認証を行います。
今回「MIXI M」では、3DS ServerとACSの内製開発を行いました。内製開発に踏み切ったモチベーションのひとつが、コストの削減です。はじめにお話ししましたように、「MIXI M」は、イシュアとしての機能と、加盟店、決済代行としての機能を併せ持っています。イシュアとしては、イシュイングしたプリペイドカードを3-Dセキュア対応するためにACSと契約する必要があります。そしてプリペイドカードに残高をチャージするとき、そのチャージオーソリの3-Dセキュア対応を行うために、3DS Serverと契約する必要があります。このACSと3DS Serverの利用額が無視できないほど大きく、運用上の問題になっていました。そこで、JCBブランドでの残高チャージ対応開始にともなって、ACSと3DS Serverの内製開発を決断しました。
3DSシステムを内製開発するときに必要になった対応について紹介します。まずEMVCoの仕様に即したシステム開発を行い、コンプライアンスを取得する必要があります。その際には、テストプラットフォームやテストラボラトリーと呼ばれる事業者と契約して、コンプライアンステストを通過する必要があります。並行して、3DSシステムを提供する環境をPCI 3DSに準拠させる必要があります。PCI 3DSの要件はパート1とパート2に分かれており、パート1の要件はすべてPCI DSSに含まれています。「MIXI M」はPCI DSS準拠済みの環境の上で3DSシステムを提供するため、パート1の監査はスキップとなりました。パート2には7要件75項目があります。こちらにもPCI DSS要件と被っているものがいくつかあるため、PCI DSS準拠済みの環境でPCI 3DSに準拠する場合、要件準拠にかかわる工数を削減できます。最後に接続先のカードブランドに要求される項目をクリアし、コンプライアンスを取得します。
内製開発の選定技術に関しては、開発メンバーが「MIXI M」と同じであるため、既存の「MIXI M」決済システムと同じ技術を選定しました。開発言語はElixir、データベースはDynamoDBを採用しています。コンテナのオーケストレーションも「MIXI M」と同様にECS Fargateを利用しており、マネージドサービスを中心にシステムを構成しています。
2022年11月にプロジェクトを始動し、およそ1年後の2023年10月と12月に内製ACSと3DS Serverの運用を開始しました。プロジェクトに参加した開発人員は、主担当1名、副担当1名の計2名。開発実働機関は、ACS/3DS Server開発にそれぞれ1～2カ月、PCI 3DS準拠対応に約1カ月、ブランド接続や既存システムとのつなぎ込みなどに約1カ月かかりました。マネージドサービスを中心にシステムを構成したことで、運用関係の工数はほぼ生じませんでした。結果としてエンジニアの工数をサービス開発に注力することができ、比較的小さい工数で対応することができました。
内製EMV 3-Dセキュアの構成を紹介します。基本的に、先ほど紹介した決済システムの構成図と大きく違いはありません。内製3DSはECS Fargateで提供されており、外部のDirectory ServerとはAPI GatewayとApplication Load Balancerを介して接続しています。ECS Fargate上のアプリケーションは、データベースであるDynamoDBやメッセージキューのSQS、鍵管理を行うKMSといったマネージドサービスと通信を行って、電文の処理を行います。監査要件のためにCloudTrailやAWS Config、IaCツールとしてCloudFormationなども利用しています。
