決済にまつわるセキュリティの話 第1回 クレジットカードセキュリティ入門
皆様、はじめましてWebPay CTOの曾川(@sowawa)です。
今日はさくらのナレッジに出張（寄稿）させていただきました。
はじめての方もいらっしゃると思いますので、簡単な自己紹介とWebPayの紹介をさせていただきます。私は、2011年からサンフランシスコのfluxflexという会社でクラウドサービスを開発していました。現在はWebPayという決済ゲートウェイの開発を行っています。WebPayは、数行のブログラムを記述するだけでクレジットカード決済を簡単に組み込むことが出来る決済ゲートウェイです。今日は、そんな決済ゲートウェイサービスを提供している経験から、Webサービス上でクレジットカード決済を提供する上で避けては通れないセキュリティの話をしたいと思います。さくらインターネットにはfluxflexでクラウドサービスを開発しているときからご支援いただきWebPayでもご支援いただいております。
クレジットカードのためのセキュリティ標準入門
インターネット上にはクレジットカードで支払いができる多くのWebサービスやeコマースサイトがあふれています。ですが、クレジットカード番号の取り扱いが不適切なサービスも多く、漏洩事件が繰り返し発生しているのも事実です。ここではクレジットカードのためのセキュリティ標準がどのようなものなのかをご紹介いたします。
決済ゲートウェイサービスを提供するために避けては通れないのがPCIDSSと呼ばれるセキュリティ標準です。VisaやMasterCardのような国際ブランドはクレジットカード情報の漏洩を防止するためPCIDSSと呼ばれるセキュリティ標準に準拠することをクレジットカードを扱う事業者に求めています。PCIDSSは、12の大項目にわかれた約300項目の詳細な項目によって構成されています。
PCIDSSの12の大項目は以下の様な構成になっています。（参考文献: PCI Standards & Documents）
| 安全なネットワークとシステムの構築と維持 | 1 | カード会員データを保護するために、ファイアウォールをインストールして維持する |
|---|---|---|
| 2 | システムパスワードおよびその他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない | |
| カード会員データの保護 | 3 | 保存されるカード会員データを保護する |
| 4 | オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する | |
| 脆弱性管理プログラムの維持 | 5 | マルウェアにしてすべてのシステムを保護し、ウィルス対策ソフトウェアを定期的に更新する |
| 6 | 安全性の高いシステムとアプリケーションを開発し、保守する | |
| 強力なアクセス制御手法の導入 | 7 | カード会員データへのアクセスを、業務上必要な範囲内に制限する |
| 8 | システムコンポーネントへのアクセスを識別・認証する | |
| 9 | カード会員データへの物理アクセスを制限する | |
| ネットワークの定期的な監視およびテスト | 10 | ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する |
| 11 | セキュリティシステムおよびプロセスを定期的にテストする | |
| 情報セキュリティポリシーの維持 | 12 | すべての担当者の情報セキュリティに対応するポリシーを維持する |
PCIDSSはクレジットカードの取り扱い量に応じてレベルが用意されており、その中でも最上位のレベル1に準拠するためには、上記の12の大項目分けられる約300項目をpayment card industry data security standard councilによって認定された監査員によるオンサイト監査を受ける必要があります。
「保存」「処理」「伝送」の3つのポイントを抑えたリスク分析
もしあなたがWebサービスを運用していて決済手段にクレジットカード決済を提供している場合、「保存」「処理」「伝送」の3つのポイントに注目してリスク分析をしてみましょう。Webサービスのクレジットカード決済の実装で想定されるケースとしては3つのものが考えられます。1つ目がクレジットカード情報の「保存」「処理」「伝送」を行っていない場合、2つ目が「処理」「伝送」のみを行っている場合、3つ目は「保存」「処理」「伝送」のすべてを行っている場合の3つに分けて解説します。
1つ目のWebサービス内でクレジットカード情報の保存、処理、伝送を行っていない場合は、これはもっともリスクの低い状態と言えます。外部の決済ページにページ遷移を誘導するような形でユーザに決済を行ってもらう形態のものです。保存だけでなく処理や伝送を行っていないことからも万一サーバに不正アクセスがあった場合でもデータベース上にクレジットカード情報が保存されていないため漏洩のリスクはかなり低くなります。しかし、不正アクセスによってWebページの書き換えなどが行われた場合は、ユーザをフィッシングサイトのような悪意のあるサイトへ誘導することでユーザにクレジットカード番号を入力させてクレジットカード情報を取得するといった攻撃の可能性が残されていることには注意が必要といえます。
2つ目のクレジットカード情報の保存を行わずに「処理」「伝送」のみを行っている場合について、これは1つ目と比べて「処理」と「伝送」を行っているため漏洩のリスクが大きくなっています。Webサービス内のページでクレジットカード番号の入力を求めて、バックエンドのプログラムで決済ゲートウェイなどのクレジットカード番号の保存機能を利用する場合です。この場合、データベース上にはクレジットカード番号が存在しないためSQLインジェクションなどの攻撃による漏洩のリスクがないという点にメリットが有ります。しかし、運営側が無意識に保存しているApacheやNginxなどのWebサーバのログのリクエストパラメータなどにクレジットカード番号が残っていたというような漏洩リスクには注意が必要といえるでしょう。Webサービスを開発するプログラマーだけでなくWebサーバを運営するサーバ管理者にも注意が必要なポイントがあるといえます。
3つ目はクレジットカード情報の「保存」「処理」「伝送」のすべてを行う場合です。大規模なWebサービスなどでは直接クレジットカード会社とやりとりをするためクレジットカード番号をデータベース上に保存していることがあります。この場合は、PCIDSS全項目を確実に準拠することを強くお勧めいたします。最もリスクが高いことは言うまでもありませんが、保存されているクレジットカード情報に対するあらゆる面からのセキュリティ対策が必要になります。
クレジットカード情報を取り扱っているWebサービスの運営者の皆さんはこれを機会に是非一度「保存」「処理」「伝送」の3つポイントからリスク分析してみてください。
おしらせ
