- 講演資料：「サーバーレスPCI DSS対応クレジットカード決済 基盤システムを運用しながら、みんなでわいわい DIYの精神で、新しいモバイル決済サービス 6gramをともにつくっている話/6gram-DIY」
運用負荷を押さえながらPCI DSS対応するには
ミクシィのウォレットサービス「6gram」（ロクグラム）は、簡単に言えば共同財布のアプリ版だ。1つのアカウントで複数のプリペイドカードを作成でき、プリペイドカードを複数名で使うといった利用方法が特長だ。ちなみに、一般的なカードの重さが5グラムで、それにプラス1グラムの付加価値を追加したサービスであるというのが名前の由来という。
「社内では、お菓子を買う共有ウォレットとして利用しており、コンビニに出かけた人がついでにみんなで食べるお菓子を（共有ウォレットの支払いで）買ってくる」と話すのは、同サービスの開発に携わったミクシィの田岡文利氏。Apple PayやGoogle Payとも連携可能で、今後はリアルカードも発行予定だという。
決済サービスを扱う上で、重要となるのがPCI DSS（Payment Card Industry Data Security Standard）だ。ユーザーのクレジットカード情報や取引情報を安全に扱うための要件をまとめた業界基準である。
決済サービスは、ユーザー、イシュア（カード発行業務を行う信販会社など）、ブランド（VISAやJCBなどのクレジットカード会社）、加盟店（ECサイトなど）、アクワイアラ（ブランドの加盟店網を拡大・管理する業者）、決済代行業者で構成される。ユーザーは加盟店で商品をクレジットカード決済で購入する場合、イシュアから発行されたカード情報を提供し、決済代行業者が決済を行う。
「カード情報を取り扱うイシュアと決済代行業者は、PCI DSS対応が必須。同基準ではカード情報の保存以外にも、伝送も対象となっているが、ECサイトは購入ページに入力されるカード情報を決済代行システムへ直接送信し、トークンやカードIDに変換された情報のみを保持することから、対応は必要ない」（田岡氏）
では、6gramの場合はどうなるのか。プリペイドカードを発行することからイシュアとしての業務があり、決済代行システムも運用している。つまりは、PCI DSS対応必須ということだ。
PCI DSSは12要件、約400項目で構成。数年に一度基準が改定され、対応企業は年に一度、運用手順のドキュメントや実施証跡などのオンサイト監査を受ける必要がある。
要件には、例えば稼働中のサーバーをウイルスから保護するためにウイルスチェックなどを実施する（要件5）、IDS/IPSによる侵入の警告や、変更検出メカニズムでのファイル変更の監視や警告を行う（要件11）ことなどが記載されている。
準拠することではじめて、カードブランドやアクワイアラとの契約ができるスタートライン。しかし、ミクシィの開発および運用部隊にはエンジニアリングマネージャーである田岡氏が1名、サーバーサイドエンジニアが5名、クライアントエンジニアが2名と”少数精鋭”体制。運用負荷を下げることは必須だったという。
そこで田岡氏たちは、コンテナをRead Onlyで動かす方法を思い立った。
「リモートコンソールがないので侵入ポイントが1つ潰せる。また、Read Onlyで書き換え不可なので、そもそもファイル変更検出ソフトウェアが不要になる。ログイン先もないため、IDもパスワードもなく、パスワード要件もクリアだ」（田岡氏）
課題は、データベースだった。リレーショナルデータベースはユーザーとパスワードが基本的に必要だ。ID／パスワード管理の複雑さを考え、田岡氏たちはクレジットカード情報含むすべてのデータをマネージドNoSQLデータベースのAmazon DynamoDBへ保存することに決めた。
「IAMベースで、サービスのロールごとに細かくアクセス制御ができ、ログも一元管理できる。少しでも権限管理が楽になる方向で整備した」（田岡氏）
6gramへの道のり
6gramの開発にあたり、田岡氏たちは必要な機能を整理した。まずはプリペイドカードの発行だが、これはカード番号やトークン、残高を管理するイシュア基盤が必要になる。また、銀行やATMからの入金やポイント利用などのチャージ機能、Apple PayやGoogle Payとの連携およびモバイル決済機能も考えることになる。
「モバイル決済については、TSP（トークンサービスプロバイダー）と連携することで解決するにしても、コンテナをサポートするなどの要件を満たすパッケージが見当たらなかった」（田岡氏）
なぜないのか。
「決済基盤は30年以上も前からあるためかシステム自体が古く、コンテナのサポートなんてもっての外だった。また、Read Onlyで動くようにしたため、デーモンを起動してPIDを書こうとしても処理されない。諸々検討した結果、最初に頑張って低コスト運用に向いたシステムをDIYで開発することにした」。みんなで楽しくワイワイDIYするのがベストという決断だった。
気を付けたのは、レイヤリングだ。今後特殊な対応が必要になって変更を加えたいとき、コンポーネントをごそっと入れ替えたり間に挟んだりできるような設計を意識したと田岡氏は話す。例えば入金機能では、決済処理と残高処理を別要素に分解し、ネット通信と専用線での特殊プロトコルによる通信を見極めて抽象化。特殊プロトコル通信では専用の変換アプリを開発、コンテナとの間にかませて、Amazon SQS（Simple Queue Service）でキューイングする形にした。
続いて、イシュア基盤の開発だ。構築方法は3通りあると田岡氏。1つは、イシュア基盤をすべて構築する方法。2つめは、モバイル決済だけ移譲する方法。3つめは、残高だけ管理する方法だ。
「モバイル決済だけTSPにカード情報を同期する形で移譲し、トークン決済にしてしまえば、カード情報を保持しなくて済み、モバイル決済周りのシステム開発はいらなくなる。オーソリシステム（信用照会システム）も通常のカード決済システムとあまり変わらないので、開発も大変ではない。ただ、決済のたびにTSPへ問い合わせすることになるが、通常のカード決済よりも平均で500ミリ秒ほど遅いことを観測している」（田岡氏）
一方の、残高だけ管理する方法では、オーソリシステムを借りて同期やAPIコールで送金処理する。この方法であれば、PCI DSS対応が必要な部分をかなり切り離せるため、運用もかなり簡素化できる。
いろいろ検討した結果、田岡氏たちは1つめの方法をとることにした。開発言語はElixir（一部DynamoDB Streamsを経由したNodeJSや解析環境でPythonなどを使用）。インフラは、AWSで固めた。データベースはAmazon DynamoDB、処理はAWS Fargate、監視はAmazon CloudWatchやRollbarを使用している。
ここまでで、「5グラム」の実装が完了した。あとは、カードの複数枚発行やグループウォレット機能などの、残り「1グラム」を実装することだ。残高には複数のカードを紐付けられるようにして、必要に応じて切り替えられるようにした。グループウォレットについては、ユーザーごとにグループ用カードを作成し、それを共同残高に紐付ける。
「すべて開発したことで、カードの同期や残高の数などに制限が生まれず、かなり自由度の高い”プラス1グラム”が構築できた。監査なしでも安全なシステムが保たれるような組織作りができたと思う」（田岡氏）
また、ルールや仕組み、設計、開発まですべてやったことで、さまざまなメリットを享受できたと田岡氏は言う。チームビルディングやチーム力の底上げは、その一つだ。DIYで楽しく取り組む先に、これまでとは違う世界が待っているのかもしれない。
お問い合わせ
株式会社ミクシィ
