PCI DSS の要件 8 は共有 ID をどう扱うか(EC 事業者と運用代行の場合)

PCI DSS は、クレジットカードの情報を守るための国際的な基準です。その要件 8 は、システムを使う人を見分け、本人かを確かめる項目です。基準を作る PCI SSC は FAQ で、共有 ID(1 つの ID を複数の人で使うもの)は例外の場面に限るとしています。FAQ は、そのねらいを、操作の一つひとつを個人に結びつけることだと説明しています。国内の EC 事業者には、カード情報を持たない場合でも、業界のガイドラインが管理画面の二段階認証などを求めています。

PCI DSS は誰に当てはまるか

PCI DSS の最新版は 2024 年 6 月に公表された v4.0.1 です。基準書は PCI SSC の文書ライブラリで入手でき、日本語版もあります。PCI SSC の説明では、対象はカード会員のデータを保存・処理・送信する事業者と、その環境の安全に影響しうる事業者です。加盟店、決済を処理する事業者、カード会社、サービスを提供する事業者などが含まれます。ただし、準拠や審査を求められるかどうかは、PCI SSC ではなく、カードのブランドや加盟店と契約するカード会社が決めます。

要件 8 は共有 ID をどう扱うか

PCI SSC の FAQ によれば、共有 ID の利用は例外の場面で必要なとき以外は防ぎ、使うなら要件 8.2.2 のすべての項目に沿って管理します。対象は「admin」「root」のような管理者のアカウントに限らず、複数の人で使うログイン情報すべてです。

FAQ はその理由として、誰が何をしたかが ID ごとに残れば、不正や誤った操作の原因を絞り込み、被害を早く食い止められることを挙げています。共有 ID では、システムの記録に残るのは ID だけで、その時間に誰が使っていたかは別に調べるしかありません。

そのうえで FAQ は、管理の作業で共有 ID を限って使うために、道具やパスワードを保管する仕組みを使ってよいとしています。そうした仕組みで、使う人の本人確認をし、一人ひとりの責任と記録を保てるという説明です。使い道の例には、緊急時にだけ使う管理者アカウントが挙がっています。

要件 8 のほかの項目で、共有 ID だと守りにくいもの

PCI SSC の FAQ は、要件 8 のほかの項目を次のように説明しています。

共有 ID では、この 3 つが守りにくくなります。誰かが使い続けるので、辞めた人が知っている ID でも使われていない扱いになりません。パスワードを変えれば全員へ配り直し、2 つめの確認の手段も全員が受けられるようにしなければなりません。なお FAQ によれば、8.3.9 は 2 つ以上の方法で確かめている利用には当てはまりません。

EC 事業者に求められること

国内には、クレジット取引セキュリティ対策協議会の「クレジットカード・セキュリティガイドライン」(6.1 版)があります。割賦販売法が求める措置の、実務の指針とされています。ガイドラインの措置か、それと同等以上の措置を行っていれば、法律の「必要かつ適切な措置」を行っているとみなされます。

EC 加盟店に求められるのは、カード情報を持たない「非保持化」か、持つ場合の PCI DSS 準拠です。非保持化とは「自社で保有する機器・ネットワークにおいて『カード情報』を『保存』『処理』『通過』のいずれも行わないこと」です。PCI DSS に準拠した決済代行会社の決済画面に移す方式などで実現できます。

ただし、ガイドラインは、カード情報を持つかどうかにかかわらず、EC サイトの「脆弱性対策」(弱いところをふさぐ対策)をすべて行うよう求めています。非保持化した店でも、管理者の権限の管理などの不備からカード情報が漏れた事案があるためです。ガイドラインの本文は、管理画面について次の 3 つを挙げています。

1. 管理画面に入れる IP アドレスを限る。限れない場合は、ベーシック認証(ブラウザーが出す ID とパスワードの入力)などを設ける
2. 二段階認証か多要素認証(2 つ以上の方法でログインを確かめる仕組み)を使う
3. ログインに 10 回以下失敗したらアカウントをロックする

附属文書(EC 加盟店向けの対策一覧)の表には、もう 1 つ対策が並びます。管理画面の URL や ID・パスワードを、admin のような推測されやすいものにしないことです。表では、IP アドレスの制限(またはベーシック認証)と、推測されにくい URL・ID・パスワードは、両方入れるのが原則です。システムの都合で無理なときだけ、どちらか 1 つが必須になります。二段階認証か多要素認証はどちらかが必須、ロックは必須です。

ガイドラインは共有 ID には触れていません。ただ、管理画面の ID を何人かで使い、二段階認証のコードが登録した 1 台にしか出ない設定なら、ほかの人はその持ち主に頼むことになります。方式ごとの問題は共有アカウントの二段階認証を複数人で使うときの問題と選択肢にまとめています。

運用代行やシステム会社に求められること

ガイドラインは、委託先の管理について 3 つの場面を書いています。カード情報を扱う業務を外に出すときは、PCI DSS に準拠しているなど必要な対策をとる事業者を選び、契約後も実施の状況を確かめます。EC システムや Web サイトの構築・運用を外に出すときは、加盟店が行う脆弱性対策を理解したうえで作業するよう、委託先に求めます。複数の委託者からカード情報を扱う業務を受ける事業者は、自社のシステムでのカード情報の持ち方を確かめます。そのうえで PCI DSS 準拠などの対策をとります。

決済の仕組みを運営して EC 加盟店に提供する会社には、PCI DSS に準拠し、それを保つことが求められています。ガイドラインが「EC システム提供会社」と呼ぶ事業者です。

店舗の管理画面で受注や商品を扱う運用代行は、2 つめの場面に近い立場です。管理画面の二段階認証やロックは店の側の対策なので、運用代行の担当者もそれに従います。担当者ごとの ID を作る機能があれば、まずそれを使います。モールの例は楽天 RMS・Yahoo! ショッピングの店舗管理を代行するときのアカウントで扱っています。

PCI SSC の FAQ には、カード情報を持ち PCI DSS に準拠する店が外部の事業者を使う場合の説明があります。外部の事業者が店の代わりに要件を満たしているなら、その事業者の準拠の状況が店の準拠に影響します。外部の事業者は、どの要件を自社と顧客のどちらが受け持つかを顧客に示すことになっており、その道具に責任の分担表が挙がっています。この考え方は管理画面のアカウントにも使えます。ID を発行する人、二段階認証のコードを受ける人、担当を外す人を表にしておけば、店と運用代行のどちらが聞かれても答えられます。

共有 ID を残すときに決めておくこと

担当者ごとの ID を作れない管理画面で、FAQ の考え方に沿って共有 ID を残す場合の決め方の一例です。

1. 共有 ID が残る管理画面と、分けられない理由を一覧にする。例外として扱うには、どれが例外かが分かっている必要があるためです。
2. 使う前に本人を確かめ、誰がいつ使ったかを残す方法を決める。FAQ が道具でできることとして挙げる、本人確認と一人ひとりの記録に当たります。
3. 担当を外れた人が入れなくなる手順を決める。共有のパスワードを本人が知っていると、変えて配り直すまで入れる状態が続くためです。
4. 二段階認証のコードを誰がどう受けるかを決める。1 人の端末にしか届かないと、その人がいない日は作業が止まるためです。