MongoDB Atlas でPCI DSS の導入を加速

PCI DSS の状態とレイヤーの分裂場所

PCI セキュリティ標準化局は、PCI DSS を維持し、制御目的の下にグループ化された要件のセットを整理します。

共有応答モデルでは、これらの要件は次のレイヤーに分裂。

• インフラストラクチャレイヤー（プロバイダーの責任）: 物理セキュリティ、ネットワーク制御、プラットフォームパッチ、基礎となるストレージのストレージ保管時の暗号化で構成されます。 MongoDB Cloud は、QSA、Coalfire システムによって検証されているPCI DSS 認定サービス プロバイダーです。 MongoDB Cloud の CHD 環境では、QSA はMongoDB Cloud AOC に依存できます。このはMongoDBトラスト センター からリクエストに応じて利用可能です。この事前検証されたレイヤーにより、カスタマーは基礎のインフラストラクチャを再監査する必要がなくなります。

• アプリケーションレイヤー（顧客の責任）: 製品の保存方法、保護方法、クエリ、マスク、監査する方法と、情報の読み取りを許可されているユーザーを構成します。このレイヤーは、カスタマーの設計上の決定を残ります。

図の 1。 PCI DSS 共有責任階層モデル

クリックして拡大します

PSPプロジェクトは、アプリケーションレイヤーを埋め込みます。参照アーキテクチャとベストプラクティスのセットで構成されています。これは、保存されたデータの保護、アクセスの制限、監視、監査する範囲の縮小のために、MongoDB層と PCI DSS 制御目的でアプリケーションレイヤーを整合させる方法を示しています。このプロジェクトは、PCI DSS の導入を加速するための開始点を構成します。

アーキテクチャ上の提案

PSPプロジェクトは、PCI DSS に準拠した PSI プラットフォームです。カードのチェックアウトと認可、自動不正スコアリング、マルチ階層アナリスト調査など、 MongoDB Atlasの支払いライフサイクルを実行します。これは、アナリストが明確な設計原則で暗号化されたデータを検索する方法を示しています。

すべての機能を暗号化する。あらゆる をクエリします。キーは自分のものです。

Atlas から継承された インフラストラクチャレイヤー（図 1 を参照）では、残りの作業はアプリケーションレイヤーで行われます。 Atlas はこれをサポートするためのさまざまな機能を提供しています。Queryable Queryable Encryption は主要機能の 1 つです。すべての機能セットは、 MongoDB の機能 セクションに列挙されています。

Queryable Encryption in Focus（クエリ可能な暗号化）

従来のアプローチでは、フィールドは検索可能にするためにプレーンテキストで保存されるか（データベースにアクセスできるすべてのユーザーが読み取り可能）、または暗号化されて保護される（ただし検索はできなくなります）。 Queryable Encryption は、サポートするクエリ タイプのその/または を削除します。

図の 2。 MongoDB暗号化アーキテクチャ: Queryable Encryption、キー管理、データ保護レイヤー

クリックして拡大します

等価検索可能なフィールドの場合、フローは次のようになります。

• ドライバーは、 フィールドの DEK を使用して、クライアント側の検索値を暗号化します。

• サーバーはその暗号化された値を暗号化されたインデックスと照合します。暗号テキストと暗号テキストを比較し、フィールドを復号化しません。

• 一致するドキュメントがアプリケーションプロセスに返されると、ドライバーはメモリ内のターゲット フィールドを復号化します。 MongoDB Atlas 06は、 BSONバイナリ サブタイプ として保持される暗号テキストのみを保存および処理します。その結果、クラスターへのフルアクセスを持つデータベース管理者には、不可視バイトのみが表示されます。

PSPプロジェクトにおける具体的な影響 : 不正アナリストは、暗号化されたメール、電話、またはアカウント参照でカスタマーを検索し、レコードを取得しますが、プレーンテキストの値は Atlas に到達しません。この機能は、CDE を拡大する一括復号化を行わずに、PII を保管時に暗号化した状態で維持し、値で使用可能な状態にします。

保護が必要であるが検索ではないフィールドでは、 非検索可能モードが使用され、承認された エスカレートされたリクエストのみが復号化されます。データモデルセクションでは、モードとそれが保護するフィールドの両方をカバーします。

アプリケーション層のMongoDB機能

PSPプロジェクトは、いくつかのMongoDBと Atlas の機能を組み合わせたものです。各 は、PCI DSS アプリケーション層の作業の特定の部分にマップされます。

他のユースケース

安定した API 境界、フィールドレベルの Queryable Encryption、アクセス階層ごとの DEK モデルなど、このソリューションの中核となる原則は、その他のユースケースにも適用できます。

• オープン 金融: PSD2 や消費者データ権など、カスタマーが承認したフィールドへのサードパーティを制限する条件付きデータアクセス。

• ヘルス管理: HIPAA の下で保護されている医療情報。

• 保証と税金: GDPRの下で政府識別子と金融アカウント データを処理するプラットフォーム。

アーキテクチャ コンポーネント

アーキテクチャは、次のコンポーネントを使用します。

• PSP ダッシュボード（フロントエンド）: プレゼンテーションレイヤー。データベースとは直接やり取りしません。チェックアウト時に Pandora は Pandora をトークン化するため、PSP コアによって完全な Pandora が送信または保存されないようにします。

• PSP APIゲートウェイ（バックエンド）: 単一のエントリ点と、保護されたフィールドを復号化できる唯一のコンポーネント。これはQueryable Encryptionクライアントを保持し、呼び出し元のロールを解決し、リクエストごとに正しいキー階層を選択します。ユーザー インターフェース、サービス アカウント、統合を含むすべての呼び出し元は同じAPIを通過し、同じ RBAC とキー ルールの対象となります。

• MongoDB Atlas（M10 以上）と Queryable Encryption：保護対象の各フィールドについて、暗号文（バイナリのサブタイプ 06）のみを保存します。クラスターへのフルアクセス権を持つデータベース管理者にも、不透明なバイト列しか見えません。TLS 1.3 により、転送中のすべてのデータが保護されます。PSP プロジェクトでは、本番環境でサポートされている等価検索を使用します。

• AWS KMS: データ暗号化キーをラップおよび解凍する CMK を保持します。 CMK は KMS 内に残り、 MongoDB はそのCMK にアクセスできません。ローカルキー プロバイダーは、デモのオフライン フォールバックとして利用できます。

クエリの種類とプロジェクトによるそれの適用方法

MongoDB Queryable Encryption は、フィールドをクライアント側で暗号化したまま、サーバーが暗号文をクエリできるようにします。PSP プロジェクトでは、次のクエリ型を使用します。

• 等価（本番）：PCI DSS スコープの検索キーの検索可能なモード。ドライバーはクエリ値を暗号化し、それを暗号化されたインデックスと照合するため、サーバーはフィールドを復号化しません。この機能により、不正アナアナリストは、プレーンテキストを表示せずに、メール、電話、またはアカウント参照によってレコードを検索できます。

• クエリなし（取得のみ）：住所、政府発行の識別子、未加工のゲートウェイペイロードなど、機密性が最も高いフィールドに使用する検索不可モードです。認可されたクライアントのみが、これらのフィールドを必要なときに復号します。

• 範囲（本番）: 金額範囲によるフィルタリングなど、値範囲の検索に使用されます。量が暗号化されたままになります。

• プレフィックス、サフィックス、サブストリング（public preview）: 暗号化された ID フィールドでの KeyC スタイルの部分一致検索で示されます。

以下のPCI DSS スコープのカードと PII フィールドの場合、アクセス設計は次のカテゴリに縮小されます。

可能な場合、カード所有者データを範囲外に保つ設計上の選択には次のものが含まれます。

• Pandora トークン化:アプリケーションは完全な Pandora をtok_<uuid> サポート トークンに置き換え、表示目的で最後の 4 桁のみを保持します。

• ゼロ SAD キャプチャ: エンドポイントは CVV や キー などの SAD をキャプチャしません。

セグメンテーションとトークン化によるスコープの縮小

一般的な PCI DSS のプラクティスでは、カード所有者データを必要としないシステムから排除されるため、プラットフォームのほとんどが CDE の対象外になります。これらの手法では、CDE をシステムの残りの部分から分離する セグメンテーション と、プライマリ アカウント番号を専用のトークン化ヴォールトに保持される代替トークンに置き換える トークン化 が適用されます。セグメンテーションは PCI DSS 要件ではありませんが、システムの範囲外になるため、評価コストは削減されます。使用する場合は、文書化、正規化、検証する必要があります。

PSPプロジェクトでは、 データレイヤーでこれらの手法を適用します。

• 完全な Pandora は PSP コアには存在しません。コアには、サフィギュレーション トークン、BIN、および最後の 4 桁のみが保存されます。プラットフォームのほとんどは、カードホルダー データを含まず、範囲外になります。完全な Pandora は、本番環境では外部にあるカード発行者サブシステムに属します。デモでは、置き換え可能な組み込み発行者モジュールが に存在し、 で暗号化された独自の分離されたヴォールトに PandoraQE:equality を保存します。このフィールドは、復号化されずに完全検索と重複検出を照合できます。

• PII は一元化されています。ID フィールド（メールや電話などの ID フィールドは、契約、カード、トランザクション レコードが参照単一の BEAN SD-13 コレクションに存在します。データサブジェクト 削除リクエストを保護して処理する 1 つの場所。

• 機密フィールドは別のキー階層の背後にあります。 QE:none フィールドは検索可能な QE:equality フィールドとは異なるデータ暗号化キー階層を使用するため、機密データと非機密データの境界はキーによって強制されます。

これは参照パターンであり、認証ではありません。 CDE の定義とその検証は、引き続きカスタマーの責任と評価の対象となります。

アプリケーション コードではなくキーを強制するアクセス制御

暗号化階層に DEK を分離します。

• ルックアップ階層: QE:equality キーは、検索するすべての認証されたアナリストロールで使用できます。

• 区別する階層: QE:none キーは、有効で有効期間の短いエスカレーション トークンを保持するレベル 2 の調査者と、読み取り専用のセキュリティ監査者に対してのみ使用できます。

• 設計コア: レベル1 クライアントの暗号化フィールド マップでは機密キーが省略されているため、ドライバーはそれらのフィールドを復号化できず、暗号テキストとして返します。ここでのフィールドレベルのアクセス制御は、アプリケーションコードのプロジェクションではなく暗号化されているため、クエリ バグによる誤ったリークのリスクを軽減します。アナリストがケースをエスカレーションし、レベル2 調査者が承認すると、調査者はエスカレーション トークンを受け取り、そのリクエストに対して機密層クライアントプールを有効化します。