SalesforceにおけるPCIコンプライアンスの達成：アーキテクト向けガイド

背景と適用シナリオ

現代のビジネス環境において、顧客の支払い情報を安全に取り扱うことは、信頼を維持し、規制を遵守するための絶対的な要件です。特にクレジットカード情報を扱う企業にとって、PCI DSS (Payment Card Industry Data Security Standard、ペイメントカード業界データセキュリティ基準) への準拠は避けて通れない課題です。PCI DSSは、カード会員データ（Cardholder Data、以下CHD）を保護し、クレジットカード詐欺を防止するために策定された一連の技術的および運用的要件です。

多くの企業が顧客関係管理（CRM）の中心としてSalesforceを活用しています。営業プロセス、サービス提供、マーケティング活動のすべてがSalesforceプラットフォーム上で管理される中で、支払い情報の処理も例外ではありません。例えば、以下のようなシナリオが考えられます。

EコマースサイトとSalesforceを連携させ、注文情報と支払い状況をSalesforceで一元管理する。
コンタクトセンターのオペレーターが、電話で受け付けた注文のクレジットカード決済をSalesforce画面から直接行う。
サブスクリプション型のビジネスモデルで、Salesforce Billingを用いて月次の請求と決済を自動化する。

これらのシナリオにおいて、CHDを不用意にSalesforce内に保存してしまうと、Salesforce組織全体がPCI DSSの監査範囲（スコープ）に含まれることになります。これは、セキュリティ要件が格段に厳しくなり、監査コストの増大やコンプライアンス維持の複雑化を招きます。したがって、Salesforceアーキテクトとしての我々の使命は、ビジネス要件を満たしつつ、PCI DSSのスコープを最小限に抑え、安全でスケーラブルなソリューションを設計することにあります。この記事では、Salesforceプラットフォーム上でPCIコンプライアンスを達成するためのアーキテクチャ上の原則、ベストプラクティス、そして具体的なアプローチについて解説します。

原理説明

Salesforce環境でPCIコンプライアンスを達成するための最も重要かつ効果的な原則は、「SalesforceをPCI DSSのスコープから除外する（De-scoping）」ことです。これは、機密情報であるCHD（特にプライマリアカウント番号PANやCVV）をSalesforceプラットフォーム上に一切「保存、処理、送信」しないことを意味します。この原則を実現するための主要な技術がTokenization（トークン化）です。

Tokenization（トークン化）の活用

トークン化とは、機密性の高いCHDを、トークンと呼ばれる非機密性のランダムな文字列に置き換えるプロセスです。このプロセスは通常、PCI DSSに準拠したサードパーティのペイメントゲートウェイ（決済代行サービス）によって提供されます。

アーキテクチャ上のフローは以下のようになります。

ユーザーがWebフォームやSalesforceの画面（例：Lightning Web Component）にクレジットカード情報を入力します。
入力されたCHDは、Salesforceサーバーを経由せず、ユーザーのブラウザから直接、またはSalesforceからセキュアなAPIコールアウトを通じてペイメントゲートウェイに送信されます。
ペイメントゲートウェイはCHDを受け取って安全に保管し、それに対応する一意のトークンを生成して返します。
Salesforceには、このトークンのみが保存されます。顧客オブジェクトや注文オブジェクトに関連付けられるのは、このトークンです。
以降の決済処理（請求、返金など）は、Salesforceに保存されたトークンをペイメントゲートウェイに送信することで実行されます。実際のCHDは一切Salesforceを通過しません。

このアーキテクチャにより、Salesforce組織はCHDを直接扱わないため、PCI DSSの多くの厳しい要件から解放されます。アーキテクトとしては、このトークン化のプロセスをいかにシームレスかつ安全にシステムに組み込むかが設計の鍵となります。

Salesforceプラットフォームのセキュリティ機能

たとえCHDを保存しない（スコープ外の）アーキテクチャを採用したとしても、Salesforceプラットフォーム自体のセキュリティを確保することは極めて重要です。これは「多層防御（Defense in Depth）」の考え方に基づきます。Salesforceアーキテクトが活用すべき主要なセキュリティ機能には以下のようなものがあります。

Salesforce Shield: これは、コンプライアンス要件が厳しい企業向けの高度なセキュリティ機能群です。
- Platform Encryption (プラットフォーム暗号化): 保存データ（Data at Rest）を暗号化する機能です。標準項目、カスタム項目、ファイルなどを暗号化できます。CHDを保存しない場合でも、個人情報（PII）などの他の機密データを保護するために不可欠です。
- Event Monitoring (イベント監視): ユーザーの操作ログやAPI利用状況など、Salesforce組織内で発生した詳細なイベントを追跡・分析できます。これにより、「誰が、いつ、何にアクセスしたか」を監視し、不正アクセスの兆候を検知することが可能となり、PCI DSSの要件10（ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する）の精神に合致した運用が実現できます。
- Field Audit Trail (項目監査履歴): データの変更履歴を最大10年間保持できます。監査対応やデータガバナンスの強化に役立ちます。
基本セキュリティ設定:
- Profiles & Permission Sets (プロファイルと権限セット): Principle of Least Privilege (最小権限の原則) に従い、ユーザーが必要最小限のデータと機能にのみアクセスできるよう、アクセス権を厳格に管理します。
- Multi-Factor Authentication (MFA、多要素認証): すべてのユーザーに対してMFAを強制することは、不正アクセスに対する最も効果的な防御策の一つです。
- Named Credentials (指定ログイン情報): Apexから外部システム（ペイメントゲートウェイなど）へAPIコールアウトを行う際に、エンドポイントURLや認証情報をコードから分離し、安全に管理するための仕組みです。ハードコーディングを避け、セキュリティを向上させるためのベストプラクティスです。

示例コード

ここでは、Apexを使用してペイメントゲートウェイにCHDを送信し、トークンを取得する、というコンプライアンスを意識した実装例を示します。この例では、SalesforceにCHDを保存するのではなく、直接外部サービスへコールアウトを実行します。

重要：以下のコードは、あくまで概念を示すためのものです。実際の実装では、使用するペイメントゲートウェイのAPI仕様に厳密に従う必要があります。また、このコードはクレジットカード番号（`cardNumber`）やCVV（`cvv`）をメモリ上で扱いますが、決してSalesforceのデータベースには保存（INSERTやUPDATE）しません。

この例は、Salesforce Developerドキュメントにある標準的なApex RESTコールアウトのパターンを基にしています。

// PaymentGatewayController.cls
// 警告：このクラスはクレジットカード情報をメモリ上で扱いますが、
// Salesforceデータベースには決して保存しません。
// 実際のプロジェクトでは、セキュリティ専門家によるレビューが必須です。
public with sharing class PaymentGatewayController {

    /**
     * @description Lightning Web Componentから呼び出され、ペイメントゲートウェイにカード情報を送信してトークンを取得するメソッド
     * @param cardNumber クレジットカード番号
     * @param expiryMonth 有効期限（月）
     * @param expiryYear 有効期限（年）
     * @param cvv セキュリティコード
     * @return String 成功した場合はペイメントトークン、失敗した場合はnull
     */
    @AuraEnabled
    public static String getPaymentToken(String cardNumber, Integer expiryMonth, Integer expiryYear, String cvv) {
        
        // Named Credential 'Payment_Gateway' を使用してエンドポイントを取得
        // これにより、エンドポイントURLや認証情報をコードから分離し、安全に管理できる
        HttpRequest req = new HttpRequest();
        req.setEndpoint('callout:Payment_Gateway/tokens');
        req.setMethod('POST');
        req.setHeader('Content-Type', 'application/json;charset=UTF-8');
        
        // ペイメントゲートウェイのAPI仕様に合わせたリクエストボディを構築
        // 注意：これはあくまで一例です。実際のペイロード形式はゲートウェイに依存します。
        Map<String, Object> cardDetails = new Map<String, Object>{
            'card_number' => cardNumber,
            'expiry_month' => expiryMonth,
            'expiry_year' => expiryYear,
            'cvv' => cvv
        };
        
        Map<String, Object> requestBodyMap = new Map<String, Object>{
            'payment_card' => cardDetails
        };
        
        req.setBody(JSON.serialize(requestBodyMap));
        
        Http http = new Http();
        String paymentToken = null;
        
        try {
            // APIコールアウトを実行
            HttpResponse res = http.send(req);
            
            // 応答を処理
            if (res.getStatusCode() == 201) { // 201 Created: 成功時のステータスコードの例
                // 応答ボディをパースしてトークンを抽出
                Map<String, Object> responseBody = (Map<String, Object>) JSON.deserializeUntyped(res.getBody());
                paymentToken = (String) responseBody.get('token');

                // 重要：ここでは決して機密情報をデバッグログに出力しない
                System.debug(LoggingLevel.INFO, 'Payment token received successfully.');

            } else {
                // エラー処理
                System.debug(LoggingLevel.ERROR, 'Payment gateway callout failed. Status: ' + res.getStatus() + ', Status Code: ' + res.getStatusCode() + ', Body: ' + res.getBody());
                // フロントエンドに返すためのカスタム例外をスローするなどの処理をここに追加
                throw new CalloutException('Failed to communicate with payment gateway. Status code: ' + res.getStatusCode());
            }
        } catch (Exception e) {
            // 接続タイムアウトなどの例外をキャッチ
            System.debug(LoggingLevel.ERROR, 'An unexpected error occurred during payment gateway callout: ' + e.getMessage());
            throw e; // 例外を再スローして呼び出し元に通知
        }
        
        return paymentToken;
    }

    // 補助的な例外クラス
    public class CalloutException extends Exception {}
}

このコードは、`getPaymentToken`メソッド内でカード情報を受け取り、即座に`HttpRequest`を構築してペイメントゲートウェイへ送信しています。成功すればペイメントゲートウェイから返されたトークンを返し、そのトークンをSalesforceのレコード（例えば商談や注文）に保存します。カード番号やCVV自体は、メソッドの実行が終了するとメモリから破棄され、データベースには一切残りません。これがPCIコンプライアンスを遵守したアーキテクチャの基本パターンです。

注意事項

PCI準拠のソリューションを設計・構築する際には、以下の点に細心の注意を払う必要があります。

Shared Responsibility Model (責任共有モデル): SalesforceはPCI DSSに準拠したインフラストラクチャを提供していますが、その上でお客様が構築するアプリケーションや設定のコンプライアンスはお客様自身の責任です。Salesforceがプラットフォームの安全性を保証しても、開発者がCHDをカスタム項目に保存するコードを書けば、その組織はコンプライアンス違反となります。
CHDの偶発的な保存の防止: メール、Chatterフィード、タスク、ケースのコメント、デバッグログなど、意図しない場所にCHDが保存されるリスクがあります。データ損失防止（DLP）のルールを設定したり、デバッグログのレベルを本番環境で適切に管理したり（`System.debug`で機密情報を出力しない）、ユーザーへのトレーニングを徹底したりすることが重要です。特にCVV（セキュリティコード）は、いかなる形式であっても決済処理後に保存することがPCI DSSで固く禁じられています。
API制限 (API Limits): ペイメントゲートウェイへのコールアウトは、Salesforceのガバナ制限（同時コールアウト数や総コールアウト時間など）の対象となります。大量の決済処理をバッチで行う場合などは、非同期処理（Queueable Apex, Batch Apex）を検討し、制限に抵触しない設計を心がける必要があります。
権限 (Permissions): Apexクラスがコールアウトを行うためには、そのエンドポイントをRemote Site Settings (リモートサイトの設定) または、より推奨されるNamed Credentials (指定ログイン情報)に登録する必要があります。また、この機能を呼び出すLightning Web ComponentやVisualforceページにアクセスできるユーザープロファイルも最小権限の原則に従って厳格に制限すべきです。
エラー処理とロギング (Error Handling and Logging): ペイメントゲートウェイとの通信でエラーが発生した場合の処理は、アーキテクチャの重要な一部です。エラーメッセージやログにCHDやその他機密情報が含まれないように、慎重なエラーハンドリングとロギング戦略を設計する必要があります。

まとめとベストプラクティス

SalesforceアーキテクトとしてPCIコンプライアンスに取り組む際の目標は、テクノロジーを駆使してビジネス価値を最大化すると同時に、リスクを最小限に抑えることです。CHDの取り扱いに関しては、そのリスクが非常に高いため、防御的かつ慎重なアプローチが求められます。

以下に、SalesforceでPCI準拠ソリューションを設計するためのベストプラクティスをまとめます。

De-scope by Default (デフォルトでスコープ外を目指す): 設計の第一歩として、常に「SalesforceにCHDを保存しない」という前提からスタートしてください。これが最も安全で、コスト効率の高いアプローチです。
Tokenization is Key (トークン化が鍵): 信頼できるペイメントゲートウェイを選定し、そのトークン化サービスを全面的に活用するアーキテクチャを構築します。フロントエンド（ブラウザ）で直接トークン化を行うソリューションは、Salesforceサーバーを経由するCHDの量をさらに減らすため、より強力な選択肢となり得ます。
Leverage AppExchange (AppExchangeの活用): ゼロから開発する前に、AppExchangeで提供されているPCI準拠済みの決済ソリューションを評価してください。多くの場合、実績のあるパッケージを利用する方が、開発期間の短縮、コスト削減、リスク低減に繋がります。
Implement a Defense-in-Depth Strategy (多層防御戦略の実装): Salesforce Shieldの導入、MFAの徹底、厳格なアクセス制御など、複数のセキュリティレイヤーを組み合わせることで、たとえスコープ外の環境であっても組織全体のセキュリティ態勢を強化します。
Secure Integrations (セキュアなインテグレーション): 外部システムとの連携には必ずNamed Credentialsを使用し、APIキーなどの認証情報を安全に管理します。通信はすべてTLS 1.2以上で暗号化されていることを確認してください。
Consult a QSA (Qualified Security Assessorへの相談): 組織のPCI DSSコンプライアンス要件が複雑な場合や、アーキテクチャに不安がある場合は、認定セキュリティ評価機関（QSA）に相談することを強く推奨します。専門家によるレビューは、潜在的なリスクを特定し、準拠を確実にするための最良の方法です。

最終的に、SalesforceにおけるPCIコンプライアンスは、単一の技術や製品を導入すれば完了するものではなく、アーキテクチャ設計、開発プラクティス、運用プロセスのすべてにセキュリティを組み込むという継続的な取り組みです。アーキテクトとしてこれらの原則を理解し適用することで、企業はSalesforceの強力な機能を活用しながら、顧客の信頼を守り、ビジネスを安全に成長させることができます。

にゃんこのSalesforce日記

このブログを検索