PCI DSSの審査を完了しました

こんにちは。CTOの冨田です。 先日、Kipp Financial TechnologiesはPCI DSSの監査を完了しました。

PCI DSSはカード会員データ（主にカード番号）を取り扱う事業体が準拠すべきセキュリティ基準です。 PCI DSSの監査は毎年受け、準拠状況を更新することが求められます。 監査は毎年国際マネジメントシステム認証機構に依頼しています。 Kipp社は2020年に初回の監査を受け、2022年で3回目になります。 初年度は準備も監査中もかなりの時間と労力を要しましたが、ノウハウを積み重ねることで年々監査の負担が減少しています。 今回はPCI DSS準拠の負担を軽減しつつ、セキュアにサービス構築するためのノウハウをお伝えします。

この記事で参照するPCI DSSはバージョン3.2.1です。 近くバージョン4への移行が予定されていますが、執筆時点では正式公開されていません。 AWSクラウドサービス上で構築することを前提に、全体でAWSの用語を使っています。 同様の考え方は他のクラウドサービスにも適用できますが、非クラウド形式のインフラサービスや自社が所有する機器では事情が大きく異なりますのでご注意ください。 本記事の内容はすべてkippの経験に基づくものであり、PCI SSCや国際マネジメントシステム認証機構の見解を示すものではありません。

対象領域のコントロール

PCI DSS準拠の負担を軽減する最も効果的な方法は、監査対象領域を縮小することです。 これがこの記事で説明するすべてです。 当たり前のように聞こえますが、実際に対象領域を縮小するアプローチは興味深いものがあります。 この記事ではkippが実際に行った対象領域をギリギリまで減らす努力を具体的に紹介します。

企業規模にかかわらず、事業体は複数の業務を行うの一般的です。 kippのようにプリペイドカードを発行する事業体でも、会員管理やプリペイドカードへの入金など、カード会員データと直接関係ない機能があります。 またkippが提供するサービスにはミライバライ向け機能のようにカード情報の取扱が一切生じないサービスもあります。 対象領域のコントロールをしないと、無関係にみえるサービス、実装もすべてPCI DSS監査対象になってしまいます。

これは直感的におかしいです。 カード会員データを扱わない部分はPCI DSSを適用する必要はないはずです。 PCI DSSより条件の緩い、別のセキュアなサービスを構築するプラクティスを適用すれば十分でしょう。

PCI DSSの監査対象になるのはカード会員データ（カード番号など）と機密認証データ（CVVや暗証番号など）の「保存、処理、伝送」に関わるシステムコンポーネントと事業体です。 決済サービスを行っていてもクレジットカードを取り扱わない事業体はPCI DSSに準拠する必要がありません。 カード発行機能を持つサービスの中でもカード会員データの「保存、処理、伝送」に関係ない部分は監査対象から外せます。

「関係ない」と言いきれるのはネットワークの構造やデータの流れを調査して、「保存、処理、伝送」のいずれにも関与しない場合です。 この3つの要素をよく見ると、保存するには処理する必要があり、処理するにはどこかからカード会員データを受け取る（伝送される）必要があります。 ですからカード会員データに関係するコンポーネントを図に整理したとき、伝送していない部分は対象外にできます。

データの流れはどのように調査するのでしょうか。 PCI DSS要件1.1はコンポーネントとその関係をネットワーク図やデータフロー図といった図にまとめることを要求しています。 図は人が手で書くものですので、実際のシステム構成とずれてしまうリスクがあります。 ずれが生じないよう定期的に見直す要件（1.1.2.b）もありますが、見直しも人手で行う点は同じです。 監査もこれら文書や図を元に行うので、図に抜け漏れがあると不正に準拠状態になってしまう危険があります。 人が作成した文書に基づいて人が監査するということの不確実性を肝に命じ、普段の業務でも監査時も嘘偽りなく対応することが健全な準拠の前提条件になります。

伝送していない部分は対象外になりますから、ネットワークが完全に分離しており、通信の手段がひとつもなければ間違いなく対象外です。 AWSではVPCが主要なコントロール手段になります。 カード会員データを取り扱うVPCが完全に独立してVPC PeeringやInternet Gatewayを持たなければ、そのVPCのみが監査対象になります。

kippではカード会員データを取り扱う専用のAWSアカウントを作成し、AWS Organizationsの機能で管理しています。 他のサービスもそれぞれ独立のAWSアカウントで動作しており、サービス間のデータの混入や障害の相互影響のリスクを低減しています。 その中でインターネットにも接続していないカード会員データ環境VPCを用意し、監査対象のネットワークをこのVPCひとつに限定しています。

アウトソーシング

通常、カード決済業務は外部サービスとの通信が必要です。 カード発行者（イシュア）であればブランドのネットワークと接続し、決済リクエスト（オーソリゼーション）や売上情報を受信します。 決済代行やアクワイアラであれば消費者からカード番号を受け取り、上位のアクワイアラやブランドに伝送します。 そう考えるとインターネットにも接続していないVPCで業務が成立するのは変ですね。

kippはブランド接続の機能をほとんどアウトソーシングしています。 TIS社のPAYCIERGE ブランドプリペイドプロセッシングサービス(以下、PAYCIERGE)はワンストップでプリペイドカードのイシュイング機能を実装できるサービスです。 ブランドネットワークと接続するための開発はとても分量が多く、慎重な実装が求められます。 PAYCIERGEを利用すればブランドネットワークとの通信はすべて提供されており、カスタマイズしたい部分だけを拡張できます。 kippではカード発行前に発行データを調整する部分と、決済リクエストに対して不正対策や複雑な残高処理を実現する部分で拡張しています。

PCI DSSはインターネットからのアクセスが特に重大な脅威源となることを踏まえ、インターネットからのリクエストを受け付けるネットワークとアプリケーションに重厚な要件を課しています。 しかしPAYCIERGEからの決済リクエストのカード番号はすべてPAYCIERGE内のトークンに置き換えられているため、決済リクエスト処理ではカード会員データを受け取りません。 同様にクレジットカードから入金を受ける場合も、決済代行のトークン化APIを利用することで自社のサーバでカード会員データを受け取るのを避けられます。 PAYCIERGEのようなトークン化の機能を持ったサービスを活用することで、機能性を損ねることなく公開されたコンポーネントからカード会員データを排除でき、監査対象を大幅に削減できます。

ただし私達はカード会員データの管理の一部をPAYCIERGEに委託していることになりますから、PAYCIERGEがカード会員データを適切に扱っているか確認しなければいけません。 PCI DSS要件12.8では委託先の適格性を各社が調査するほか、PCI DSS AOC（準拠証明書）を確認することでこの責務を果たすよう義務づけています。

マネージドサービスの利用

アウトソーシングによりkippがカード会員データを扱うのはPAYCIERGEからカード発行データファイルを受領し、変換し、印刷会社に受け渡す部分のみになりました。 この変換機能はAWSにあるので、PAYCIERGEおよび印刷会社との接続はインターネット経由になります。 するとPAYCIERGEからカード発行データファイルを受け取る部分、印刷会社に受け渡す部分も上述の要件の対象になりそうです。

ここでもアウトソーシングの考えを活用し自社の責任範囲から外すことができました。 AWSは非常に多くの機能に対してPCI DSSの準拠証明を受けており、S3やTransfer for SFTPもそのなかに含まれます。 PAYCIERGEからはS3 APIを利用してアップロードしてもらい、印刷会社にはTransfer for SFTPで提供したSFTPサーバからS3内のデータをダウンロードしてもらっています。 インターネットからのリクエストを受ける部分はすべてAWSマネージドサービスになりますから、自社でASVスキャンを受けずに済みます。 かわりにAWSのAOCを参照し、該当機能についてAWSが責任を持っていることを確認します。

ここまでの工夫により自社で管理する部分はS3バケットからデータを取り出し、別のS3バケットにデータを書き込む部分のみとなりました。 実にサービスの99%程度が監査対象から外せたと言えます。 この変換処理の中でも監査対象を減らす工夫があります。 AWS VPC内からS3にアクセスするのにインターネットを経由せず、VPC内にS3エンドポイントを建てています。 さらにEC2などのサーバを管理するとサーバのミドルウェアの更新（要件2.2）やウィルススキャンの要件（要件5.1）が生じます。 AWS Fargateで動作するように設定したECSタスクを利用すれば、これらも緩和できます。

結果的に、インフラストラクチャで監査対象になるのは以下に絞れます。

• ECSでタスクが動作するVPC
• そのルーティングテーブル
• そのサブネット
• そのセキュリティグループ
• タスク上で動くアプリケーションの開発、管理手順
• アプリケーションのイメージのビルド手順
• ECS実行環境の設定とIAM権限
• それらのCloud Watch Logsログ

12章もある要件のすべてが1時間程度で見られる項目に絞れるのは非常に価値があります。

なお、PCI DSSバージョン3.2.1はコンテナ技術やマネージドサービスについての言及が限定的であり、監査会社や監査人によって解釈が異なる場合もあります。

最後にAWSマネージドサービスを使い、かつペネトレーションテストを行う場合、AWSのテストポリシーに従う必要があることに注意します。 たとえばAmazon ECSやAWS Fargateはこの許可リストの中に含まれていないため、Fargate上で動作するコンテナにペネトレーションテストを行う場合は個別に判断を仰ぐ必要があります。 S3のパブリックエンドポイントのようにペネトレーションテストが許可されないだろうリソースについてはAWSのPCI DSS AOCを以て不要と整理します。

物理環境の管理

クラウド環境のみでなくオフィスやデータセンターなど物理環境を利用する場合、それらもPCI DSSの監査対象になります。 サーバを設置せず、オペレーション業務用の端末を利用するだけでも厳しいコントロールが必要になります。 kippも当初はカード番号を取り扱うオペレーション用のオフィスを用意していましたが、賃料から担当者によるメンテナンスまで費用が非常に高く付くので、現在は閉鎖しました。

カード会員データを取り扱えるオフィスを管理すると管理リソースが増え、結果的にカード情報漏洩の危険が増します。 カード会員データを扱うためには入退室管理、監視カメラの設置、私有デバイスの持ち込み禁止など通常のオフィスで求められる以上のコントロールが必要です。 すでに一般業務用のオフィスを持っていても、そこでカード会員データを扱えるように変更するのは手間です。 感染症の流行下にあり、また働き方が多様化する現在にあってはオフィスを開設しない選択肢を積極的に検討するべきでしょう。

しかしほとんどのカード会員データを取り扱う事業者はオフィスを持っており、また他の事業者もカード会員データを取り扱える場所を持つことを前提としています。 オフィスを置かない場合、オフィスがない、カード会員データを人が取り扱えないことを取引先に理解し、正しく対応してもらう必要があります。 カード業務を行う会社間ではチャージバックやカードデータ漏洩時の対応など、カード番号を伝達する場面があります。 kippの従業員はカード会員データを直接取り扱わない定めをしているため、そういった場合トランケートして授受するよう依頼しています。 特別にカード会員データを扱える場合を定めるより、端から扱わないよう業務を構築したほうがセキュアかつ簡単になります。

オフィスに関連した例外規定

カード会員データを扱える環境を廃止するにあたり、懸案になった箇所が2つあります。 ひとつは物理プリペイドカードを発送したもののカードが受け取られず、郵便が戻ってきた場合です。 郵便の返戻先はカード発行会社と自社オフィスを選べましたが、費用の問題もあり自社オフィスになっていました。 この返戻された封筒にはカード会員データが入っているため、そのまま取り扱うと監査対象になります。

PCI SSCは無効であると証明できるPANに適用されないという公式解釈があります。 そこでカード発行のライフサイクルを工夫し、利用者が自身でカードを受け取り、アプリから有効化しない限り利用できないように設計しました。 さらに同一カード番号での再発行を禁止し、すでに利用可能なカード番号や将来利用可能になりうるカード番号が返戻されてこないようにしました。 結果オフィスに返戻されるカードは返戻された時点で無効であり、将来にわたっても無効でありつづけるため、返戻カードをカード会員データ環境外で扱えます。

もう一点は管理アクセスの拠点の問題です。 実際にカード会員データを閲覧する業務は発生しないものの、カード会員データを保存するAWS環境を設定・運用するためのリモートアクセスが必要です。 kippは現在ほとんどすべての業務をリモートで行っているため、管理アクセスもリモートで行うべく検討しました。

こちらも公式のガイダンスが出ています。 簡単にまとめると、従業員の自宅からのアクセス経路は信頼できないネットワークと識別しなければならないが、その経路は事業体の管理が及ばないので監査対象にはしない。 そのかわり自宅からのリモートアクセスの手順と仕組み、接続をセキュアにして全体のセキュリティを担保すべきとなります。

AWS環境の例であればログインに使う端末、ログイン時の認証手段、そしてAWSとの通信経路が適切に保護されていることを確認します。 kippでは次のようにこの保護を達成しています。

• カード会員データ環境の管理に使えるラップトップの貸与
• ウィルススキャンの導入を含めたラップトップの管理方法の策定
• Oktaを導入し、きめ細かく認証とセッションライフサイクルを管理
• Okta、AWSとの接続がTLS v1.2以降で保護されていることの確認
• Okta、AWSのAOCの確認

管理対象を削減し一石二鳥

今回の記事では3回のPCI DSS監査を受けた経験をもとに、PCI DSS監査の負担を軽減する業務設計のノウハウを紹介しました。 監査負担の軽減が監査対象を減らすことによって達成されること、同時に漏洩リスクを抱える箇所が減ってセキュリティも向上することを説明しました。

私自身、当初は「そんなに削っちゃって大丈夫か」という不安を抱いていました。 最初はAWS Fargateを使わず、わざわざEC2インスタンスを起動してECSを運用していたほどです。 監査員の方々に丁寧に説明をしていただき、まったくの杞憂であること、むしろ管理する対象を減らすのが正しいことを理解しました。 業務効率化によってPCI DSS準拠の負担は年々減り、今年の監査は検出事項ゼロを達成したのみならず、予定より1時間以上早く終了しました。

本記事の内容はすべてkippの経験に基づくものであり、PCI SSCや監査会社である国際マネジメントシステム認証機構の見解を示すものではありません。 要件の具体的な取り扱いは監査会社や監査人によって異なる場合があります。 すべての監査において今回紹介したロジックが適用されるわけではありません。 あくまで一例、体験談として参考にしてもらえれば幸いです。

kippはプリペイドカードの発行サービスを維持、拡大し、ますます多くのお客様に安心して使っていただくため、今後もPCI DSSへの準拠とシステム全体のセキュリティ向上を続けます。 セキュリティの知見を生かしたい、セキュアなソフトウェア構築の現場で働いてみたいという方はお気軽にpeople@kipp-corp.comまでご連絡ください。