CVV とは、カードの表面または裏面に印字された短い数字で、そのカードが手元にあることを示すために使われます。番号そのものはカードから読み取れても、この短いコードはカードを実際に手に取らなければ分かりません。この記事では、コードがどこに印字されているのか、決済のどの場面で使われるのか、そしてなぜ法律や業界規則の水準で保存が禁じられているのかを説明します。
セキュリティコードの基本
呼び方は事業者によって異なりますが、指しているものは同じです。カードの磁気ストライプや IC チップに記録された情報ではなく、目で見て読み取る位置に印字された数字を指します。多くの場合 3 桁で、特定のブランドでは 4 桁です。
このコードが導入された背景には、番号の扱いやすさがあります。カード番号は請求書や控え、過去の記録など、さまざまな場所に残ります。番号だけを知っていれば決済できてしまうと、記録が漏れた時点で不正利用の危険が生じます。そこで、カードの現物を示す情報を別に要求する仕組みが加わりました。
カードのどこに印字されているか
印字位置はブランドによって異なります。ここを取り違えると、利用者が入力欄の前で迷うことになります。
| ブランドの例 | 印字位置 | 桁数 |
|---|---|---|
| 多くのブランド | カード裏面の署名欄の右側 | 3 桁 |
| American Express | カード表面の番号の右上 | 4 桁 |
案内文を書くときは、「裏面の 3 桁」と決めつけないほうが安全です。両方の位置に触れておけば、表面にコードがあるカードを持つ利用者も迷いません。
何のためにあるのか？
オンラインの決済では、カードを物理的に提示することができません。そこで、カードに印刷された情報のうち、現物を見なければ分からない要素を入力させます。これによって、番号だけを写し取っただけでは決済に進めない、という一段の壁を作っています。
対面の決済でも近い役割を果たす場面がありますが、あくまで補助的な確認です。このコードはカードの所持を示すだけで、利用者が正当な持ち主であることや、口座に十分な残高があることを保証するものではありません。したがって、コードが合っていても取引が承認されるとは限らず、逆にコードが合わない取引は承認されません。
決済サービス側での扱いの原則
もっとも重要な原則は、このコードを取引の承認後に保存してはならないという点です。カード業界のデータ保護基準である PCI DSS は、認証に使う機密データとして扱い、承認が完了した時点で保持しないことを求めています。番号や有効期限は、条件を満たせば保存できますが、このコードだけは例外が認められていません。
理由は単純です。番号と有効期限とコードの 3 つが揃うと、カードを提示せずに決済を組み立てられてしまいます。番号が漏れても有効期限が漏れても単独では決済に至りませんが、3 つが揃うと事情が変わります。だからこそ、この組み合わせを作らないために、コードだけを明確に切り離して扱うのです。
保存禁止はどう運用に落とすのか？
原則を掲げるだけでは現場は守れません。実際の運用では、コードが保存され得る経路をすべて洗い出す必要があります。次のような場所が見落とされがちです。
- 入力フォームの一時的なキャッシュやブラウザの自動入力の記録
- 障害調査のために取得したリクエストの本文
- アプリケーションのログに出力されたデバッグ情報
- 問い合わせ対応のために保存されたスクリーンショットやメール
- テスト用に複製されたデータベース
いずれも、意識して作った保存先ではありません。しかし結果としてコードが残っていれば、基準の求める状態にはなっていません。
開発者向け: コードを残さないための設計
まず、入力されたコードを保持する変数の寿命をできるだけ短くします。決済要求を組み立てる直前に受け取り、要求を送った時点で破棄する流れが基本です。データベースの表に列を用意しないこと、ログ出力の対象から除外することを、設計の段階で決めておきます。
次に、リクエストの記録を見直します。開発や障害調査のためのログは便利ですが、要求本文をそのまま残す設定になっていないかを確認してください。マスクの対象は、カード番号の中央部分だけでは足りません。このコードも伏せる対象に含める必要があります。
テスト環境では、合成の値を用いてください。実際のカードのコードをテストに流用してはなりません。基準はテスト環境に対しても本番と同等の管理を求めています。生成したテスト用のカードには任意の 3 桁を組み合わせて構いませんが、それは構造上の値であって、実在のカードに対応するものではありません。
最後に、入力欄の作り方です。コードの桁数はブランドによって 3 桁と 4 桁があります。入力欄を 3 文字に固定すると、4 桁のカードを持つ利用者が先へ進めなくなります。番号からブランドを推定して桁数を切り替えるか、少なくとも 4 桁まで受け付ける作りにしておきましょう。この補助は テスト用クレジットカード番号生成 のような生成ツールでも再現できるので、表示の確認に使えます。あわせて、カード番号の構成 を押さえておくと、どの部分をマスクすべきかの判断がしやすくなります。
次のステップ
自分の決済フローの中で、コードが一度でも保存され得る場所がないかを書き出してみてください。書き出せれば、そこを塞ぐ作業は比較的容易です。次に、入力欄が 4 桁のコードを受け付けるかを実際に試し、案内文が表面と裏面の両方を説明しているかを確認しましょう。入力欄まわりの確認項目は 決済フォームのテスト項目 にまとめています。