AWS Payment Cryptography

解決する課題

• 決済処理に必須の 専用 HSM を自前で調達・運用する重い負担から解放されたい
• イシュア・アクワイアラ・決済ゲートウェイで必要な PIN 変換やカードデータ暗号化をクラウドで実行したい
• 取引相手や端末と 対称鍵を安全に交換・共有する仕組みをマネージドに整えたい
• 決済鍵を扱う基盤について、PCI PIN や PCI P2PE などの準拠維持コストを下げたい

AWS Payment Cryptography は、クレジット・デビット決済の処理で求められる暗号鍵の管理と暗号化処理を、マネージドサービスとして提供します。決済特化の HSM をオンプレで抱え込まずに、PIN ブロックの変換やカード番号の保護、相手方との鍵交換といった決済固有の暗号処理を、PCI 準拠の基盤上で実行できます。汎用の鍵管理を担う KMS とは異なり、決済業界の規格（PIN・鍵交換方式など）に特化している点が特徴です。

主要概念と用語

• 決済 HSM: 決済処理に特化したハードウェアセキュリティモジュール。PIN や鍵を平文で外部に出さずに暗号処理を行う。本サービスはこれをマネージドに提供する
• 鍵管理 API（Control Plane）: 鍵の作成・インポート・エクスポート・削除など、鍵そのものを操作する API 群
• 暗号化処理 API（Data Plane）: PIN の生成・検証・変換、カードデータの暗号化・復号、MAC 生成などの実処理を行う API 群
• PIN ブロック: PIN を所定の形式で暗号化したデータ。フォーマット間の変換（PIN 変換）が決済経路で頻繁に発生する
• DUKPT: 取引ごとに異なる鍵を導出する方式。端末ごとの基底鍵から1取引1鍵を生成し、鍵漏えいの影響を局所化する
• 鍵ブロック: 鍵に用途や属性を結合して保護する形式。属性改ざんを防ぎつつ鍵を安全に受け渡すために使う
• KEK（鍵暗号化鍵）: ほかの鍵を暗号化して保護・交換するための鍵。相手方との鍵共有の起点になる
• TR-34 / TR-31: 決済業界で使われる鍵交換・鍵保護の規格。非対称鍵を使った鍵搬入（TR-34）や鍵ブロック形式（TR-31）に対応する
• KCV（鍵チェック値）: 鍵が正しく搬入・共有できたかを照合するための検査値。鍵の中身を露出せず一致を確認できる

仕様・制限・クォータ

• 2つの API 面に分かれる: 鍵を扱う鍵管理 API と、暗号処理を行う暗号化処理 API が分離している。鍵の作成・共有と日常の暗号処理を別々の権限・経路で扱える
• 決済特化の鍵種別: PIN 暗号化鍵、PIN 検証鍵、KEK、MAC 鍵など、決済処理で使う鍵タイプを属性付きで管理する
• 鍵交換規格に対応: TR-34 や TR-31 などの方式で、外部の決済 HSM や相手方と鍵を安全に搬入・搬出できる
• PIN・カードデータ処理: PIN 生成・検証・変換、カードデータの暗号化・復号、MAC 生成・検証といった決済固有の操作を提供する
• リージョンスコープ: 鍵はリージョン単位のリソース。提供リージョンは限られるため、利用前に対象リージョンを確認する
• 鍵数やリクエストレートなどには上限があり、件数の上限はクォータ引き上げ申請で緩和できる場合がある
• 変動しうる具体的な数値や対応規格の細部は、利用時点の公式ドキュメントで確認する

内部の仕組み

中核は「決済特化 HSM をマネージドに動かす」ことです。鍵はクラウド上の HSM 基盤内で生成・保管され、平文で外部に取り出されません。利用者は鍵管理 API で鍵を作成・インポートし、暗号化処理 API で PIN 変換やカードデータ保護などの処理を指示します。実際の暗号演算は HSM 内部で完結し、PIN や鍵の平文が API レスポンスに現れない設計です。

鍵は用途や属性と結びついた形（鍵ブロック）で扱われます。これにより、たとえば PIN 暗号化用の鍵を MAC 生成に流用するといった想定外の用途を防ぎます。外部の決済 HSM や取引相手との鍵共有では、TR-34 などの規格に沿って KEK で鍵を保護した状態で搬入・搬出し、KCV で正しく共有できたかを照合します。

決済経路では、受け取った PIN ブロックを次の経路が要求するフォーマットへ変換する処理が繰り返し発生します。本サービスは入力 PIN ブロックを HSM 内で復号し、新しい鍵・フォーマットで再暗号化して返すことで、PIN を平文でアプリケーションに露出させずに変換を実現します。

設計パターン / ベストプラクティス

• 管理面と処理面で権限を分離する: 鍵管理 API（作成・共有・削除）と暗号化処理 API（PIN 変換など）を別々の IAM 権限で制御し、日常処理に鍵管理権限を与えない
• 鍵を用途ごとに分ける: PIN 用・MAC 用・KEK など用途別に鍵を分離し、属性で用途を固定して流用を防ぐ
• DUKPT で取引ごとに鍵を変える: 端末側は基底鍵から取引ごとの鍵を導出する方式を採り、1取引1鍵で漏えい影響を局所化する
• 標準規格で鍵交換する: 外部 HSM や相手方との鍵共有は TR-34／TR-31 など標準方式を用い、独自手順による鍵露出を避ける
• PIN を平文で持ち回らない: アプリケーション側で PIN を復号せず、変換・検証は本サービス内で完結させる
• 移行は段階的に: 既存決済 HSM からの移行では、鍵搬入と並行稼働の検証を経て切り替える

運用・監視

• 操作を監査する: 鍵の作成・インポート・エクスポート・削除といった管理操作は CloudTrail に記録される。誰がいつどの鍵を操作したかを追跡する
• 処理メトリクスを監視する: 暗号化処理 API の呼び出し量やエラー率を監視し、決済経路の異常やエラー増を早期に検知する
• 鍵の棚卸し: 用途ごとの鍵がどれだけあるか、不要な鍵が残っていないかを定期的に確認する
• 鍵共有の検証: 相手方との鍵搬入後は KCV を照合し、正しく共有できたことを確認してから本番経路に乗せる
• リージョンと提供範囲の確認: 利用するリージョンでサービスと必要な規格が使えるかを事前に確認する

コスト

• 鍵の保持に課金: 管理している鍵の数に応じた料金が発生する。不要な鍵を削除して保持数を抑える
• API 呼び出しに課金: 暗号化処理 API の呼び出し回数に応じた料金がかかる。決済トランザクション量が費用に直結する
• HSM 自前運用との比較: 専用 HSM の調達・冗長化・PCI 認証維持にかかる固定費と比べ、利用量に応じた課金で初期投資を抑えられる
• 具体的な単価は変動するため、見積もりは利用時点の料金ページで確認する

セキュリティ

• 鍵を HSM で保護: 鍵は HSM 内で生成・保管され、平文でエクスポートされない。決済鍵の平文露出リスクを排除する
• PCI 準拠の基盤: PCI PIN や PCI P2PE などの決済セキュリティ規格に沿った基盤上で処理が行われ、準拠維持の負担を軽減する
• IAM で最小権限: 鍵管理と暗号化処理の権限を IAM ポリシーで分離し、操作できる主体と用途を絞る
• 鍵属性で用途を固定: 鍵に用途属性を結合し、PIN 用鍵を別用途に流用するといった誤用を防ぐ
• CloudTrail で証跡: 鍵操作を記録し、監査と異常検知に使う
• 標準規格での鍵交換: TR-34／TR-31 など実績ある方式で鍵を搬入・搬出し、鍵共有時の露出を抑える

関連サービス・比較

AWS Payment Cryptography は決済特化の鍵管理・暗号処理サービスで、汎用のデータ暗号鍵を扱う KMS とは対象も用途も異なります。両者の違いを整理します。

ハンズオン / CLI例

# 決済鍵を作成する（用途を属性で指定。ここでは PIN 暗号化用の例）
aws payment-cryptography create-key \
  --exportable \
  --key-attributes KeyAlgorithm=TDES_3KEY,KeyUsage=TR31_P0_PIN_ENCRYPTION_KEY,KeyClass=SYMMETRIC_KEY,KeyModesOfUse='{Encrypt=true,Decrypt=true,Wrap=true,Unwrap=true}' \
  --region us-east-1

# 作成済みの鍵を一覧して状態を確認する
aws payment-cryptography list-keys --region us-east-1

# 特定の鍵の属性（用途・アルゴリズム・KCV など）を確認する
aws payment-cryptography get-key \
  --key-identifier <鍵のARNまたはエイリアス> \
  --region us-east-1

# 暗号化処理は別エンドポイント（dataplane）を使う。
# 例として PIN ブロックを別フォーマット／別鍵へ変換する操作を呼び出す
aws payment-cryptography-data translate-pin-data \
  --encrypted-pin-block <入力PINブロック> \
  --incoming-translation-attributes <入力フォーマット指定> \
  --outgoing-translation-attributes <出力フォーマット指定> \
  --incoming-key-identifier <入力鍵のARN> \
  --outgoing-key-identifier <出力鍵のARN> \
  --region us-east-1