SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

【デブサミ2020】セッションレポート (AD)

ミクシィの新決済サービス「6gram」が”真のサーバーレス”になったワケ【デブサミ2020】

【13-D-3】サーバーレスなPCI DSS対応クレジットカード決済基盤システムを運用しながら、みんなでわいわいDIYの精神で、新しいモバイル決済サービス6gramを作っている話

  • このエントリーをはてなブックマークに追加

 クレジットカード決済情報を扱うためには、カード情報や取引情報を保護するために策定されたPCI DSSに準拠することが求められる。これら基準を厳格に満たしつつ、プラットフォームの設計や工夫でうまく複雑さを吸収し、運用負荷を下げることはできないだろうか。そんな課題を自ら課して、”普通の決済サービス”ではなく”プラス1の決済サービス”作りを実現したミクシィの田岡文利氏とIDペイメント事業部のチームメンバーたち。同氏はPCI DSS対応の基本や要件を整理しながら、負担少なく運用可能な決済サービス基盤を構築するためのポイントを紹介した。

  • このエントリーをはてなブックマークに追加

運用負荷を押さえながらPCI DSS対応するには

 ミクシィのウォレットサービス「6gram」(ロクグラム)は、簡単に言えば共同財布のアプリ版だ。1つのアカウントで複数のプリペイドカードを作成でき、プリペイドカードを複数名で使うといった利用方法が特長だ。ちなみに、一般的なカードの重さが5グラムで、それにプラス1グラムの付加価値を追加したサービスであるというのが名前の由来という。

 「社内では、お菓子を買う共有ウォレットとして利用しており、コンビニに出かけた人がついでにみんなで食べるお菓子を(共有ウォレットの支払いで)買ってくる」と話すのは、同サービスの開発に携わったミクシィの田岡文利氏。Apple PayやGoogle Payとも連携可能で、今後はリアルカードも発行予定だという。

株式会社ミクシィ ID・ペイメント事業部 システムグループ 田岡文利氏
株式会社ミクシィ ID・ペイメント事業部 システムグループ 田岡文利氏

 決済サービスを扱う上で、重要となるのがPCI DSS(Payment Card Industry Data Security Standard)だ。ユーザーのクレジットカード情報や取引情報を安全に扱うための要件をまとめた業界基準である。

 決済サービスは、ユーザー、イシュア(カード発行業務を行う信販会社など)、ブランド(VISAやJCBなどのクレジットカード会社)、加盟店(ECサイトなど)、アクワイアラ(ブランドの加盟店網を拡大・管理する業者)、決済代行業者で構成される。ユーザーは加盟店で商品をクレジットカード決済で購入する場合、イシュアから発行されたカード情報を提供し、決済代行業者が決済を行う。

 「カード情報を取り扱うイシュアと決済代行業者は、PCI DSS対応が必須。同基準ではカード情報の保存以外にも、伝送も対象となっているが、ECサイトは購入ページに入力されるカード情報を決済代行システムへ直接送信し、トークンやカードIDに変換された情報のみを保持することから、対応は必要ない」(田岡氏)

 では、6gramの場合はどうなるのか。プリペイドカードを発行することからイシュアとしての業務があり、決済代行システムも運用している。つまりは、PCI DSS対応必須ということだ。

6gramでPCI DSS対応が必要になる箇所
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への道のり

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
【デブサミ2020】セッションレポート 連載記事一覧

もっと読む

この記事の著者

CodeZine編集部(コードジンヘンシュウブ)

CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/12080 2020/04/13 12:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング