STORES 決済 と PCI DSS (1) 現状と効率化 - 情報の集約と管理

こんにちは。セキュリティ本部の soh です。 昨年から STORES 決済 の PCI DSS 対応 を、バックエンドエンジニアやコーポレート IT エンジニアとともに担当しています。

私自身、初めて PCI DSS 対応を担当する中でさまざまな知見を得ることができ、また改善点も発見することができました。

本稿では、その中でも、 STORES 決済 の PCI DSS 対応における現状と、管理上の効率化の取り組みについてご紹介します。

歴史

STORES 決済 は、以下の 2 つの場面におけるキャッシュレス決済を提供しているサービスです。

• 実店舗で店員とお客様の間で行われる決済端末による決済（対面決済）
• メールリンクからオンラインでクレジットカード決済を行う「請求書決済」（非対面決済）

現 STORES 株式会社 の前身である コイニー株式会社 は 当社 VPoPX の 佐俣が 2012 年に創業しました。 当サービスは開始当初から PCI DSS 対応を行っており、現在では PCI DSS v4.0.1 に準拠しています。

また、準拠当初よりクラウドを活用して PCI DSS 準拠に向けて効率化に取り組んでいます。過去取り組みの詳細については以下資料等をご確認ください。（内容は当時のものです）

• https://d1.awsstatic.com/ja_JP/startupday/sudo2020/SUD_Online_2020_Tech03.pdf
• https://aws.amazon.com/jp/solutions/case-studies/coiney/

当サービスは開始当初から PCI DSS 対応を行っており、現在では PCI DSS v4.0.1 に準拠しています。

このように我々は比較的長く提供しているサービスにおいて、事業者様やお客様が安心して、いつでも、どこでも、だれでもかんたんにキャッシュレス決済を利用できるように努めてきました。

課題

過去メンバーが安全かつ持続的なサービスを構築するためにさまざまな努力を重ねてきましたが、長い歴史の中で、さらなる効率化が求められるようになった点が存在します。 例を挙げると、以下のような改善を実施する余地がありました。

• 証跡の集約
• 承認フローの整理
• 不文律的な運用の明文化
• より先進的なセキュリティ上のベストプラクティスを導入した対応

過去、全メンバーが安全性と事業継続性を担保するための取り組みに尽力する中、当時のベストプラクティスに従ってより安全なフロー構築を行ってきました。 一方で、時間の経過とともにまたサービスの拡大とともに、徐々に小さな課題が積み重なってしまったことで、承認フローや資料・証跡が複雑になってしまっていました。

PCI DSS 対応の中でも、より重要な課題にフォーカスし、事業者様・ユーザー様に安心して利用していただくためにも、これらの課題を解決し、PCI DSS の対応を効率化する必要がありました。

これまで各チームが守ってきた堅牢な運用体制に私たちセキュリティ専門のチームが加わることで、より高度なセキュリティ上の判断を迅速かつ正確に行えるよう、セキュリティ本部から PCI DSS 担当としてアサインされた私は、タスク・証跡の収集管理およびセキュリティ観点に主眼をおいて改善の取り組みを行っています。

今回はその中でも証跡およびタスクの集約管理について記載します。

効率化・改善の取り組み - 証跡・タスクの集約と整理

証跡

STORES 決済 では、いままで、各種証跡を以下のように管理してきました。

• 証跡類
  • Google Drive
    • Google スプレッドシート
    • Google ドキュメント
    • Google スライド
  • (一部 esa/Notion)

これらのサービスは非常に優れたものである一方、PCI DSS 対応というユースケースにおいて、特に Google Drive には以下のような課題が存在しました。

• 検索がしづらく、必要な情報を探すのに時間がかかる
• 複数の場所に散逸しており、情報の集約ができていない
• ドキュメントの更新履歴が追いづらい
• 承認を管理しづらい

また、当社では扱いやすさや環境差異の少なさというところから、Google Drive で管理していた各種ファイルを PDF に変換して提出するケースが存在したのですが、これらはメンバーが個別に手作業で PDF 化を実施しており、効率化の余地がありました。

これらの課題を解決するために、 STORES 決済 では、証跡類を Google Drive から GitHub へ移行することにしました。Git 管理を行うことで以下のようなメリットが得られるためです。

• ローカルへのクローンが容易で、編集や検索の効率が向上する
• GitHub の Pull Request (以下 PR) を利用することで、承認フローが明確になる
• ドキュメントの更新履歴が明確になり、過去の変更内容を容易に追跡できる
• GitHub Actions を利用して、PDF 化や Lint チェックなどの自動化が可能になる

タスク

また、 STORES 決済 では、今まで PM 的な役割を担っていたメンバーが主となってタスク管理を行っていましたが、実際の細かいタスクに関してはそれぞれのメンバーやチームが個別に管理を行っていました。そのため、パッと見てすぐに全体のタスク状況を把握することが難しく、引き継ぎ時などの情報共有および全体把握のハードルが高くなっていました。

これに関しても、GitHub を利用してタスクの集約と整理を行うことにしました。具体的には、GitHub Issues を利用して以下のようなメリットを得ることができます。

• Kanban を利用して、タスクの進捗状況を可視化できる
• タスクの優先度や担当者を明確にし、進捗を追跡できる
• GitHub Actions を利用して、タスクの自動化や通知を行うことができる
• PR を直接紐づけることで、タスクと証跡の関連付けが容易になる

特に、PCI DSS においては、要件で定められた定期的なタスクを実施する必要があるため、Issue の集約は自動化という点においてもメリットが存在します。

具体的な取り組み

上記を実現するため、TypeScript で開発した CLI ツールと GitHub Actions を連携させ、定期タスクの起票から完了、そして証跡化までを一定程度自動化する仕組みを構築しました。

この自動化フローは、以下の 2 つの主要な機能で構成されていますが、先に簡易的なフローを図に示すと、以下のような形となっています。

flowchart TD
    %% 1. 定期タスクの計画と実行の自動化
    subgraph One["1. 定期タスクの計画と実行の自動化"]
        direction TB
        subgraph Step1["ステップ1: 定期実行"]
            S1_Schedule["GitHub Actions<br/>スケジュール実行"]
            S1_JSON["JSONファイル読み込み<br/>（タスク定義）"]
            S1_Log["S3上のJSONログファイル読み込み<br/>（実行履歴）"]
            S1_CLI["CLI: Issue作成処理"]
        end

        subgraph Step2["ステップ2: タスク管理"]
            S2_Issue["GitHub Issue<br/>自動作成"]
            S2_Work["👤 担当者<br/>タスク実施"]
            S2_Close["Issue手動クローズ"]
        end

        subgraph Step3["ステップ3: 中間証跡PR作成"]
            S3_Trigger["Issueクローズ<br/>トリガー"]
            S3_CLI["CLI: 証跡生成処理<br/>(ログ更新)"]
            S3_PR["証跡更新PR<br/>自動作成"]
        end
    end

    %% 2. PR を起点とした各種自動化
    subgraph Two["2. PR を起点とした各種自動化"]
        direction TB
        S4A_Materials["👤 担当者<br/>materials/config<br/>手動更新"] --> S4A_PrOpened["PR作成・更新<br/>トリガー"]
        S4A_PrOpened -- "変更あり" --> S4A_CLI["CLI: PDF証跡生成"] --> S4A_Commit["PDFをPRに<br/>自動コミット"]
    end

    %% 3. 共通のレビュー・マージフロー
    subgraph Three["3. 共通のレビュー・マージフロー"]
        direction TB
        S5_Review["👤 レビュアー<br/>PRレビュー・承認"]
        S5_Review -- "承認" --> S5_LogApprover["CLI: 承認者記録<br/>(S3)"]
        S5_LogApprover --> S5_Merge["PRマージ"]
        S5_Merge -- "トリガー" --> S5_Sync["CLI: PDF証跡生成 および 外部サービス同期<br/>(Google Driveなど)"]
    end

    %% フローの接続
    S1_Schedule --> S1_JSON --> S1_Log --> S1_CLI --> S2_Issue
    S2_Issue --> S2_Work --> S2_Close
    S2_Close --> S3_Trigger --> S3_CLI --> S3_PR

    %% 2つのフローがレビューに合流
    S3_PR --> S5_Review
    S4A_PrOpened --> S5_Review
    S4A_Commit --> S5_Review

    %% スタイリング
    classDef human fill:#ffebee,stroke:#d32f2f,stroke-width:2px
    classDef auto1 fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    classDef auto2 fill:#e0f2f1,stroke:#00796b,stroke-width:2px
    classDef review fill:#e8f5e8,stroke:#388e3c,stroke-width:2px

    class S2_Work,S4A_Materials,S5_Review,S2_Close human
    class S1_Schedule,S1_JSON,S1_Log,S1_CLI,S2_Issue,S3_Trigger,S3_CLI,S3_PR auto1
    class S4A_PrOpened,S4A_CLI,S4A_Commit auto2
    class S5_LogApprover,S5_Merge,S5_Sync review

なお、補足すると、証跡については広く周知することが求められる要件も存在するため、これらに関しては Google Drive と Sync するための仕組みを実装しています。また、ログデータに関しては AWS S3 への保存を行っています。 当然、長期間有効なクレデンシャルを保持することは理想的とは言えないため、いずれも OpenID Connect (OIDC) による認証を実施しています。これらのサービスにおける OIDC の詳細は以下の公式ページをご確認ください。

GitHub Actions からのキーなしの認証の有効化 | Google Cloud 公式ブログ

Configuring OpenID Connect in Amazon Web Services - GitHub Enterprise Cloud Docs

1. 定期タスクの計画と実行の自動化

先述の通り、PCI DSS では「四半期ごと」や「年次」でのレビュープロセスなど、多くの定期タスクを実施する必要があります。この仕組みでは、これらのタスクを計画通りに実行し証跡を残すための一連のプロセスを半自動化します。

1. タスクの自動起票

   • トリガー
     • ワークフローの schedule による定期実行
   • 処理
     1. S3 から Issue 作成・クローズ履歴が記録された JSON のログファイルをダウンロードする
     2. 次に、yarn run start create-issues コマンドを実行する。この CLI ツールではタスク定義が記載された設定ファイルと S3 から取得したログを比較する（各タスクには UUID が割り振られている）
     3. 比較結果に基づき、以下を実行する
        1. 定期タスクなどスケジュールに基づいた Issue 作成
        2. 実行期限が近づいた Issue へのリマインド（GitHub Issue に対するコメント投稿）
     4. 起票した Issue を 各チームおよび PCI DSS プロジェクトの GitHub Projects に自動追加する
     5. 更新されたログファイルを S3 にアップロードする

2. タスクの完了と証跡の自動生成

   • トリガー
     • 担当者が作業を終え、起票された Issue を closed としたタイミングでのissue-closed.yml ワークフローの実施
   • 処理
     1. S3 から Issue 作成・クローズ履歴が記録された JSON のログファイルをダウンロードする
     2. 次に、yarn run start check-issues コマンドを実行する。このコマンドでは、以下のタスクを実行する
        1. 完了したタスクの情報を S3 上のログファイルに「いつ、誰が、どのタスクを完了したか」といった情報とともに記録する
        2. ログ情報を基に、materials ディレクトリ内の関連する証跡ドキュメント（Markdown ファイル、CSV ファイル、JSON ファイル、XLSX ファイルなど）を自動で更新し、レビューのための PR を自動作成する

3. レビューと承認

   • トリガー
     • 自動作成された PR が、承認者によってレビューされ、 main ブランチにマージされる
   • 処理
     1. 承認者が S3 上のログファイルに記載される。また、必要に応じて証跡にも追記される
     2. タスクの完了とそれに対応する証跡が、コミットログと共に永続的に記録される

この一連のフローにより、「Issue をクローズする」というアクションが、そのまま PCI DSS のタスク完了報告と証跡作成につながることとなります。また、毎回適切なログおよび承認フローが確保されることとなるため、証跡としての有効性も一定程度確保されます。

なお、この仕組みを構築するにあたっては、SmartBank さんの GitHub を利用した PCI DSS 対応の取り組みを参考にさせていただきました。

GitHub Actionsを利用しPCI DSSの更新に向けたissuesを自動作成してトイルを削減した - inSmartBank

2. PR を起点とした各種自動化

日々の運用では、定期タスク以外にも、ドキュメントの更新など、様々な作業が PR を通じて行われます。

特に PCI DSS においては、規定類のアップデート時には承認履歴の保持等が求められる場合があります。

これらの PR に対しても、一貫した品質と証跡を担保するための自動化を導入しています。

ドキュメント変更時の自動処理

• トリガー
  • main ブランチをターゲットとした PR が作成・更新 (opened, synchronize) されたタイミングでのワークフロー実行
• 処理
  1. _check-changes.yml ワークフローが呼ばれ、materials (各種ドキュメント) や config (設定ファイル) ディレクトリ内に変更があるかをチェックする
  2. 変更があった場合、_update-evidence.yml ワークフローがトリガーされる。このワークフローは、yarn run start update-evidence コマンドを実行する
  3. 変更された Markdown ドキュメントに対応する PDF の証跡を evidences ディレクトリに自動で生成・更新する
  4. 生成された PDF ファイルが PR に対してコミットされる。これにより、レビュアーは元のドキュメントの変更と、それによって生成された PDF 証跡を 1 つの PR で同時に確認できる

PR 承認時の自動処理

• トリガー
  • PR がレビュアーによって approved とされたタイミング
• 処理
  • _update-approver.yml ワークフローが呼び出される。このワークフローは、PR を承認したユーザーの情報を S3 上のログファイルに追記する。これにより、「誰が承認したか」という証跡が自動的に記録される

main ブランチマージ後の自動処理

• トリガー
  • PR が main ブランチにマージされた直後
• 処理
  • _sync-evidences-with-third-party.yml ワークフローが呼び出される
  • evidences ディレクトリに保存されている最終的な証跡 PDF を、Google Drive などの外部サービスと同期する

これらの自動化により、手作業によるミスの削減と、承認プロセスを含めた一貫した証跡管理を実現しています。

得られた結果と課題

得られたこと

定期タスクのリマインドと実行管理の効率化

この仕組みにより、従来は担当者がカレンダーやスプレッドシートを元に手動で行っていた以下のような一連の作業が半自動化されました。

• 定期タスクの洗い出しと担当者へのリマインド
  • 対応時期が来たタスクが自動で Issue として起票されるため、担当者は自分が何をすべきか、いつまでにすべきかを GitHub 上で把握できるようになった。これにより、タスクの実行漏れや遅延のリスクが低減され、リマインドの手間も一定削減された
• タスク完了報告の統一
  • 担当者は、作業完了後に Issue をクローズするだけで自動的に完了報告を行えることとなった
  • これにより、報告の手間が削減され、コメント等による実施履歴の保持が可能となった

証跡作成・収集の自動化と品質向上

PCI DSS 準拠において重要な証跡の管理についても、一定改善を行うことができました。

• 一貫性の担保
  • Issue のクローズや PR のマージといったアクティビティをトリガーとして関連するログやドキュメントが自動で更新・生成されるため、証跡の作成漏れが一定減少した。また、承認者や変更日時といった情報も自動的に記録されるため、証跡としての一貫性と品質が向上した
• レビュープロセスの明確化
  • すべての変更は PR を通じて行われ、承認プロセスそのものが証跡として記録されるため、誰が、いつ、何をレビューし承認したかが明確になるようになった
• 手作業によるミスの削減
  • ワークフローによる PDF の自動生成など、これまで手作業で行っていた定型業務を自動化したことで、ヒューマンエラーの発生を一定防ぐことができるようになった

将来より良くしたい部分

さらなる自動化

今回の半自動化で解決できたのは、主にリマインドや証跡としてのログ取得部分であり、実対応についてはまだまだ自動化を行う余地が残っています。 最も重い対応かつ効率化したい部分は中身の対応であるため、将来的にはセキュリティや実効性を担保したまま、実対応のフローについても効率化していきたいと考えています。

保守性の向上

今回の仕組みはセキュリティエンジニアである私が単独で構築したもので迅速な改善を優先したため、保守性などに改善の余地があります。 今後はよりチーム全体で協力し、保守性や柔軟性をさらに高め、より持続可能なシステムへと発展させていきたいと考えています。

全証跡の移行

現状、一部のファイルに関しては GitHub への移行が済んでいますが、保存場所が散らばっていたり他タスクに関連する考慮が必要などの理由により、移行が完了していないファイルも存在しています。 これらのファイルに関しても GitHub への移行を行うことで、変更履歴や承認履歴の取得といった観点での恩恵を受けられることとなるため、早急に移行を完了させたいと考えています。

おわりに

今回ご紹介した改善はあくまで一部ですが他作業の自動化・効率化についてもバックエンドエンジニア、コーポレート IT エンジニアがそれぞれ日々改善に取り組んでいます。

また、付け加えると、PCI DSS 対応におけるそのサービスの歴史や要件は非常に奥深く、継続的に理解を深め、常に最善の策を追求していく必要があると考えています。個別要件に関しても積極的にセキュリティとユーザビリティや現場負荷のバランスを取りつつ、モダンなベストプラクティスに基づいた選択を積極的に行っていきたいです。

PCI DSS については特に公開情報が少ない領域ですが、運用面など、より積極的に改善を行いそれをアウトプットすることで他の PCI DSS 対応で苦慮している方の一助になれば嬉しいと感じます。

今後、更に実効的な対応や改善を実施することで、より安心して利用できるようなサービスとなるように努めていきたいと思います。