Amazon Web Services ブログ
イージャイズ株式会社（旧ルミーズ株式会社）様：決済端末リモートキーインジェクション基盤にAWS Payment Cryptographyを採用。鍵の「注入」と「復号」を一元化し、HSM運用の負荷を大幅削減
by Koshiro Fujikawa | on 1 10月 2026 | in AWS Payment Cryptography, Financial Services, Security, Identity, & Compliance, General
本ブログはイージャイズ株式会社（旧ルミーズ株式会社）とアマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。
みなさん、こんにちは。AWS アカウントマネージャーの藤川です。
キャッシュレス決済の普及にともない、決済端末を安全に運用するための「鍵管理」の重要性がこれまで以上に高まっています。カード情報を扱う事業者にとって、暗号鍵をいかに安全に、かつ効率的に管理するかは、セキュリティとコストの両面で大きな経営課題となっています。
決済ソリューションを幅広く展開するイージャイズ株式会社（以下、イージャイズ様）は、新しい決済端末「salo-02」と次世代決済ネットワーク基盤「aegise2.0」の開発にあたり、鍵管理の中核として AWS Payment Cryptography（以下、APC）を採用されました。本記事では、リモートキーインジェクション（RKI）を題材に、APC 採用に至った経緯と選定理由、そして得られた効果についてご紹介します。本記事は、2026 年 7 月に開催されたカードセキュリティフォーラムにおける、イージャイズ株式会社 開発部 部長 大池 絢輔 氏のご講演内容をもとに構成しています。
お客様の状況と検証に至る経緯
イージャイズ様は、長野県小諸市に本社を構え、2001年以来約 25 年にわたり決済サービスを提供してきた PSP（Payment Service Provider）です。EC 決済からスタートし、現在では対面決済、コールセンター向けの MOTO（Mail Order / Telephone Order）決済ソリューションなど、幅広い決済シーンに対応しています。「決済にプラス α の付加価値をつけて、今までになかったソリューションを形にする “Payment SIer”」を掲げ、全国 20,000 社以上への導入実績と、PCI P2PE 認定をはじめとする高いセキュリティへの取り組みを強みとしています。
こうした事業を支えてきたのが、自動精算機や自動販売機向けのマルチ決済端末「salo」シリーズです。しかし、先代端末である「salo-01」の運用には、鍵管理の面で以下の課題がありました。
salo-01 では、暗号鍵を端末に注入する方式が「ダイレクトキーインジェクション」のみに限られていました。これは、端末を 1 台ずつ HSM（Hardware Security Module）にケーブルで直接つないで鍵を注入する方式です。この運用には、次のような負担が伴っていました。
- ファシリティコスト：キーインジェクションを行う専用の設備・部屋が必要であり、その要件と維持コストが重い
- 運用コスト：鍵の初期設定・注入はデュアルコントロール（複数人での相互牽制）が前提となるため、作業のたびに複数名の稼働が必要
- 再注入の非効率：出荷後の端末が不具合や調査でセンドバック（返送）されるたびに、鍵の再注入作業が発生する。初期入荷時のようにまとまった台数をまとめて処理できず、不定期に返ってくる 1 台のためにも複数名で作業を強いられていた
大池氏は当時をこう振り返ります。「特に、既存で動いている端末が返ってきた際の鍵の再注入は一番重い作業でした。数百台・数千台をまとめて注入するならまだしも、不定期に返ってくる 1 台のために毎回デュアルコントロールで人を集めなければならない。効率の悪い作業を強いられていました」
ソリューション／構成
これらの課題を解決するため、イージャイズ様は後継機「salo-02」の開発において、鍵注入方式を「リモートキーインジェクション（RKI）」を必須要件とする方針を打ち出しました。RKI は、端末を一か所に集めることなく、遠隔で安全に鍵を注入できる仕組みです。
この RKI を実現する基盤として、イージャイズ様は salo-02 の開発と並行して進めていた次世代決済ネットワーク基盤「aegise2.0」を活用しました。aegise2.0 は、決済に必要な機能（ゲートウェイ、加盟店管理など）をモジュール化し、オフライン／オンラインを問わず必要なだけ組み合わせて利用できるプラットフォームです。その機能の一つとして構築した TMS（Terminal Management System：ターミナルマネジメントシステム）の中に、RKI の機能を組み込みました。
そして、この新たに構築した鍵管理環境の中核に採用されたのが、AWS Payment Cryptography（APC）です。APC は、決済業界特有の暗号処理と鍵管理をフルマネージドで提供するサービスで、事業者が物理 HSM を自前で保有・運用する必要をなくします。
RKI の流れと構成
salo-02 における RKI は、以下のシンプルな流れで実現されています。
- 鍵の要求：決済端末 salo-02 が端末内で秘密鍵を生成し、CSR（証明書署名要求）を作成。クライアント証明書で接続し、CSR を添付して鍵をリクエストする。この入口には AWS IoT Core を利用しており、TMS の機能（アプリケーション／ファームウェアの配布など）と共通の基盤として活用している
- 端末の検証：鍵発行エンジンが Private CA を用いて端末の正当性を検証する
- 鍵の導出とラップ：APC が BDK（Base Derivation Key）から IPEK（Initial PIN Encryption Key）を導出し、①で受け取った端末の公開鍵を使って TR-34 形式でラップする。鍵は平文のまま暗号境界の外に出ない
- 鍵の配送：TR-34 でラップ済みの IPEK を、IoT Core 経由で端末へ配送する
- 端末内での展開：端末内で鍵を展開し、KCV（Key Check Value）で自己検証したうえで DUKPT 鍵を有効化する
APC を選定した理由
大池氏は、数ある選択肢の中から APC を選定した理由を、以下の 3 つの観点から説明しています。
理由① セキュリティ
APC は、セキュリティ面で以下の準拠・認定状況を備えています。
- PCI DSS の準拠対象サービス
- PCI PIN・PCI 3DS の準拠対象サービス
- すべての暗号処理を、PCI PTS HSM 基準に準拠したペイメント HSM 上で実行
- PCI P2PE の準拠対象サービスであり、APC 自体が Decryption Management コンポーネント認定を取得
大池氏は、イージャイズ様にとって特に大きかったのは 4 番目の認定だったと語ります。「弊社は複数の P2PE ソリューションを持っており、それらの鍵を APC で管理するにあたっては、P2PE の Decryption Management コンポーネント認定が必須条件でした。この認定を取得しているクラウド型 HSM はほぼ存在しない状況でしたので、APC がこの認定を取得されているというのは非常に嬉しいことでした」
「P2PE の Decryption Management は非常にハイレベルなセキュリティ認定です。ここまでの認定は不要という事業者様も多いかもしれませんが、それだけハイレベルな環境で鍵が管理されているということは、一つの安心材料になるのではないでしょうか」（大池氏）
理由② 性能・拡張性・運用
もともとオンプレミスの HSM で構築・運用していたため、クラウド化によって性能が低下するのではないかという懸念がありました。しかし、実際に検証を進める中で、以下の点で実運用に十分な水準であることが確認されました。
- 処理性能：物理 HSM と遜色ない処理性能を確認。復号処理は数ミリ秒から十数ミリ秒程度で完了し、条件によっては APC の方が速いというテスト結果も得られた
- 拡張性・可用性：マネージドサービスであるため、台数や容量を自前で抱える必要がない。端末数や取引量の増加に対して、基盤側が自動的にスケールする
- 運用負荷の軽減：HSM の物理管理、鍵セレモニー、DR（災害復旧）構成を自前で持たなくてよい。オンプレミスで複数台の HSM を運用する場合、各 HSM に同じ鍵を入れ、そのバックアップを厳格な手順のもとデュアルコントロールで管理する必要があり、運用が非常に煩雑になる。APC であれば、基本的に APC に鍵を置いておくだけでよく、鍵管理の運用が大幅に軽減される
理由③ 既存鍵の移管性
salo-02 はすべて新規の鍵で運用するため、APC で直接鍵を作成すれば済みます。しかし、イージャイズ様は「既存のオンプレミス HSM で動いている鍵の移管先にもなれること」も選定条件としていました。
APC は、TR-34 / TR-31 でラップした鍵をインポート／エクスポートする機能を標準で備えています。この形式で暗号化したキーブロックをインポートすればよく、将来的には他サービスの既存鍵も APC に集約できる見込みです。
なお、鍵をアルゴリズムで安全に分割してマニュアル入力する「キーコンポーネント」方式についても、現在は Physical Key Exchange として APC が正式にサポートしています。紙のキーコンポーネントを PCI PIN / P2PE の物理・論理セキュリティ要件を満たす AWS の施設に送付すると、訓練を受けた AWS のキーカストディアンがオフライン HSM を用いた鍵セレモニーを実施し、電子形式に変換して APC へ安全に取り込むことができます。大池氏は「ここで足踏みをされていた事業者様もかなり多かったのではないかと思いますので、そのハードルがぐっと下がったのは非常に朗報だと感じています」と語ります。
導入効果
APC を鍵管理の中核に据えたことで、イージャイズ様は以下のような効果を得られました。
- 鍵の「注入」と「復号」を一つの APC で完結：APC が保持する 1 つの BDK（Base Derivation Key：大元の鍵）から、鍵注入（RKI）フェーズでは IPEK を導出して端末へ配送し、取引（復号）フェーズでは同じ BDK から取引鍵を導出してカードデータを復号する。注入も復号も、この 1 つの鍵に由来する
- 鍵管理の一元化：従来はインジェクション用と復号用で環境（部屋・HSM）を分け、それぞれに同じ鍵を入れて管理する煩雑な運用が必要だった。APC に BDK を 1 つ置いておけば、その鍵で注入も復号も行えるため、鍵管理を完全に一元化できる。鍵基盤を二重に持つ必要がなく、複数箇所で鍵を共有する必要もない
- バックアップ運用の削減：キーコンポーネントを用いたバックアップ運用がほぼ不要となり、「APC で 1 回鍵を作れば、それで完結する」という運用に倒せるようになった
- ファシリティ・運用コストの削減：ダイレクトキーインジェクションで必要だった専用設備や、センドバック時の非効率な再注入作業から解放された
今後の展望
大池氏は、今回構築した RKI と復号の仕組みが salo-02 専用のものではないことを強調します。
「この仕組みは、aegise2.0 の TMS（RKI ／復号 + APC）の一機能として構築しているため、salo-02 以外の端末にも接続できる機構になっています。自社・他社を問わず、複数の決済端末が同じ TMS に接続可能です」
これにより、決済端末のメーカーが自らキーインジェクション設備を用意する、あるいはメーカーに委託するといった従来の選択肢に加えて、イージャイズ様のようなサービスを利用する、または事業者自身で組み立てるという選択肢が現実的になりました。
「鍵管理・キーインジェクションのハードルが従来よりもだいぶ下がりました。APC の登場によって、決済に関わる事業者が非常に多くの選択肢を持てるようになったのではないかと考えています」（大池氏）
イージャイズ様は今後も、決済セキュリティと鍵管理の分野で培ってきた知見を活かし、AWS のマネージドサービスを活用しながら、より安全で柔軟な決済ネットワーク基盤の提供を目指していきます。
AWS Payment Cryptography は、決済処理に必要な暗号処理と鍵管理をクラウド上でフルマネージドに提供するサービスです。詳しくは AWS Payment Cryptography の製品ページ をご覧ください。
このブログの著者
中島 智広（Nakashima, Tomohiro）シニアセキュリティソリューションアーキテクト
藤川 高志朗（Koshiro, Fujikawa）アカウントマネージャー