PR

AWSの決済暗号化が大幅進化 鍵管理3つの悩みを一気に解消

cryptography クラウドニュース

クレジットカード決済やPIN処理を扱うシステムでは、暗号鍵の管理が欠かせません。

しかしその管理は思った以上に手が込んでいます。

  • 専用のハードウェア(HSM)を調達して設置する
  • 取引先と鍵をどう交換するか手順を決める
  • 複数のAWSアカウントに鍵を配布する
  • 重要な操作を誰がいつ承認したか証跡を残す

これらをすべて自前で整備しようとすると、コンプライアンス対応だけで相当な工数がかかるのは想像できますよね。

AWS Payment Cryptography(APC)はそうした負担をAWS側に引き受けさせるサービスです。
2026年4〜5月にかけて新機能が3つ追加され、さらに痒いところに手が届くようになりました。

AWS Payment Cryptographyとは? 決済暗号化に必要なHSMをAWSが代わりに運用するサービス

AWS Payment Cryptography(APC)は、クレジットカード決済やPIN処理に必要な暗号鍵をAWSが管理・保護するフルマネージドサービスです。

従来、このレベルのセキュリティを確保するには、HSM(Hardware Security Module)と呼ばれる耐タンパー性を持つ専用ハードウェアを自社で購入・設置・維持する必要がありました。

HSMは安いものではなく、運用にも専門知識が必要で、PCI DSSやPCI PINといったカード業界の厳格なセキュリティ規格に準拠した形で維持管理し続けなければなりません。

APCを使うと、そのHSMをAWSが用意・運用するため、自社でハードウェアを抱えなくて済みます。

対応規格は

  • PCI PIN(ATMやPOSでのPINブロック暗号化)
  • P2PE(Point-to-Point Encryption:カード情報を端末から決済処理まで一貫して暗号化する方式)

カード会社・FinTech企業・決済システムを自社開発している企業が主な利用対象です。

すでにAWSを使っているチームであれば、IAMや既存のSDKからそのまま利用できる点も導入のハードルを下げています。

今回追加された3つの新機能——承認・物理交換・クロスアカウント共有

2026年4月30日と5月4日に、APCへ3つの機能が追加されました。

それぞれ独立したアップデートですが、共通するテーマは「鍵管理にまつわるリスクと手間を減らす」です。
順に見ていきましょう。

1. マルチパーティ承認(MPA)——ルート証明書の操作を一人に任せない仕組み

ルート証明書は、PKI(公開鍵基盤)の信頼の起点になる最も重要な証明書です。

これを誰かが一人で差し替えられる状態は、内部不正や操作ミスのリスクを生み出します。

  • 悪意を持った管理者が鍵をすり替えた
  • 設定ミスで誤った証明書をインポートしてしまった

といったインシデントは、後から気づいたときには被害が大きくなっているケースもあります。

今回追加されたマルチパーティ承認(Multi-Party Approval、MPA)は、ルート証明書のインポート操作に「2名以上の承認」を必須とする仕組みです。

承認フローはAWS IAM Identity Centerとネイティブ統合されており、マネージドな承認ポータルから申請・承認を行うことができます。

申請者と承認者を別の人物にすることで、単独での操作を物理的にできなくしてくれるんです。

対応している証明書形式はX.509およびPKI証明書(RSAとECCの非対称鍵)で、追加料金は発生しません。標準的なAPI使用料のみで利用できます。

金融系のシステムでは「4-eyes principle(4の目の原則)」と呼ばれる、重要操作を複数人で確認するルールがコンプライアンス要件として求められることがあります。

MPA対応により、このルールをAWSの仕組みの中で満たせるようになりました。

2. 紙ベースの鍵交換(Physical Key Exchange)——電子交換に対応していない取引先とも繋がれる

決済ネットワークに参加する企業の中には、電子的な鍵交換の仕組みをまだ整備していないところも実際には存在しているようです。

電子交換が主流になりつつある一方で、既存の商習慣やシステムの制約から紙ベースの鍵コンポーネント交換を続けているカード発行会社やアクワイアラーも。

そうした取引先との接続が必要な場合、これまでは自社でHSMKLD(Key Loading Device:鍵を安全にロードするための専用機器)を持つ必要がありました。

今回追加されたPhysical Key Exchange(物理鍵交換)は、その問題を解決してくれます。

紙の鍵コンポーネントをAWSに送付すると、AWSの訓練を受けた鍵管理者が安全な施設でセレモニー(鍵をシステムに正式に取り込む手続き)を実施してくれます。

PCI PINおよびP2PE準拠の形で処理されるため、規格上の問題も発生しません。
自社でHSMやKLDを保有・運用するコストをかけずに、紙ベースの取引先とも接続することができます。

利用するにはAWSサポートケースを開くか、AWSアカウントチームに連絡する形で申し込みます。

「将来的には電子交換に移行したいが、今すぐ取引先に対応を求めることは難しい」という状況の橋渡しとして、特に役立つ機能ではないでしょうか。

3. リソースベースポリシー(RBP)——複数AWSアカウントで鍵を1コピーのまま共有

複数のAWSアカウントを使い分けてワークロードを環境ごとに分離する構成は、セキュリティやコスト管理の観点から大企業では一般的です。

しかし従来のAPCでは、各アカウントで暗号鍵を利用するためにアカウントごとに鍵をインポートしたり複製したりする必要があり、

  • どのアカウントの鍵が正しいバージョンか?
  • 鍵の同期がずれていないか?

といった管理の煩雑さが生じていました。

今回追加されたリソースベースポリシー(Resource-Based Policy、RBP)によるクロスアカウント共有は、この問題を解消します。

1つのアカウントに保持した鍵に対して、リソースベースポリシーで他のアカウントからのアクセスを許可する形を取ります。

鍵は1コピーのまま管理でき、インポートやエクスポートのプロセスに依存する必要がなくなります。

リソースベースポリシーはIAMのリソースポリシーと同じ考え方で、S3バケットポリシーやKMSキーポリシーに慣れている方にはすんなり理解できるでしょう。

既存のAWS運用の延長線上でクロスアカウントの鍵管理を整備できるのは嬉しいですね。

まとめ——3つの強化で「鍵管理をAWSに任せる」がさらに現実的に

今回の3つのアップデートは、それぞれ

  • 承認フローのコンプライアンス強化
  • 既存取引先への接続性
  • マルチアカウント運用の効率化

という、現場でよく直面する課題に直接応えるものです。

AWS Payment Cryptographyはもともと「HSMを自前で持たなくていい」というコンセプトのサービスですが、今回の強化でその周辺の運用上の摩擦も大きく減りました。

決済インフラの暗号鍵管理に課題を感じているチームは、改めて導入を検討するタイミングかもしれません。


タイトルとURLをコピーしました