Azure Payment HSM v2、決済セキュリティにおける専用ハードウェアモデルに挑む
Azure Payment HSM v2は9月17日にパブリックプレビューを開始し、多くの重要な決済システムを現在も支えている専用ハードウェアモデルに一石を投じた。
Microsoft、Marvell、Utimacoは、このサービスを3つの異なるレイヤーで構築した。Azureがマネージドプラットフォームを運用し、MarvellがLiquidSecurityハードウェアを提供し、UtimacoがAtalla Payments Moduleソフトウェアを担う。
この組み合わせは、規制対象の決済ワークロードを扱う銀行、決済処理事業者、金融機関、その他のプロバイダーを対象としている。カード発行、PIN変換、モバイル決済認証、暗号鍵管理といった機能をサポートする。
より重要な変化は運用面にある。決済組織は、自社施設内で物理的な決済ハードウェアセキュリティモジュール（HSM）を導入・保守することなく、暗号鍵に対する制御を維持できる。
この約束が、今回の発表をめぐる中心的な緊張関係を生む。決済HSMは極めて機密性の高い取引を保護する一方、それを取り巻く統制には従来、専用デバイス、専門チーム、慎重に管理された復旧手順が求められてきた。
Azure Payment HSM v2は、その運用責任のより多くをクラウドサービスへ移す。その成否は、コンプライアンス、アプリケーション互換性、予測可能なレイテンシ、明確な統制境界を維持しながら、金融機関がこのトレードオフを受け入れるかどうかにかかっている。
Azure Payment HSM v2は3つのセキュリティレイヤーを統合する
この新サービスは、顧客が運用するハードウェア導入ではなく、専門的な決済暗号技術をマネージドAzureインフラストラクチャとして提供する。
パブリックプレビューの発表によると、Azure Payment HSM v2は当初、West USおよびWest Europeの顧客に提供される。限定的なリージョン展開は、今回のローンチに重要な境界を設けている。
これはプレビューであり、あらゆる本番決済システムに対応できる準備が整ったという宣言ではない。Microsoftとそのパートナーは、プラットフォームがグローバルな移行計画を支えられるようになる前に、顧客テスト、運用上の実証、より広範な提供地域を必要としている。
HSMは、保護されたハードウェア境界の内部で暗号鍵を生成、保護、使用する耐タンパー性コンピューティングデバイスである。決済HSMには、カードネットワークや決済処理事業者が必要とする専門的な操作が追加される。
こうした操作には、PINの保護、PINブロックの変換、決済認証情報の発行、取引データの検証、信頼できるパートナーとの鍵交換が含まれる。これらは一般的な暗号化や証明書管理のワークロードとは異なる。
Marvellは、LiquidSecurity HSM技術を通じてハードウェア基盤を提供する。同社はこのハードウェアを、複数の分離されたワークロードで高い暗号処理スループットが必要となる高密度クラウド環境向けに設計した。
Utimacoは、Atalla Payments Moduleを通じて決済固有のレイヤーを提供する。このソフトウェアは、長年にわたるAtalla製品ファミリーに関連するインターフェースと決済機能を維持する。
Microsoftはその後、統合システムをマネージドサービスとしてAzureを通じて提供する。Azureは、機器、施設、ネットワーク、ベンダーサポートにまたがって金融機関が通常調整する基盤インフラ機能を担う。
各社は、顧客が暗号鍵の主権を保持すると述べている。実務上、鍵の主権とは、クラウド事業者が支援インフラを管理する一方で、顧客が鍵へのアクセスとポリシーを制御することを意味する。
この区別が重要なのは、運用管理と鍵の権限が同じものではないためだ。銀行は、プロバイダーに決済鍵の使用を許可することなく、ハードウェア保守を委任できる。
このサービスは、PCIセキュリティ、コンプライアンス、監査、パフォーマンス、運用要件に対応するよう設計されている。ただし、こうした要件に対応するよう設計されたサービスであっても、すべての顧客導入が自動的に準拠するわけではない。
コンプライアンスは引き続き共同で取り組むべき課題である。金融機関は依然として、サービスを取り巻くアプリケーション、アクセス制御、ネットワーク、手順、監視、監査証跡を構成しなければならない。
パートナー各社は、この組み合わせを業界初とも表現している。ただし、マネージド決済暗号技術はすでに他にも存在するため、この主張は限定的に解釈すべきだ。
特徴的な主張は、この特定のマルチベンダーアーキテクチャに関するものである。Atallaの決済ソフトウェア、MarvellのクラウドHSMハードウェア、Azureのサービス運用を、1つのマネージドオファリング内に統合している。
これは、Azureがマネージド決済暗号技術を発明したと主張するより正確だ。AWSはすでに決済暗号サービスを運用しており、MicrosoftもThalesハードウェアに基づく以前のAzure Payment HSMを提供している。
変化したのは、Azure内部のアーキテクチャと責任モデルだ。新バージョンは、顧客が管理するアプライアンス作業をより多くクラウド運用サービスへ置き換えることを目指す。
決済暗号技術が物理ハードウェアの近くにとどまってきた理由
決済HSMは、専用の銀行インフラストラクチャを中心にインターフェース、統制手順、コンプライアンス義務が発展してきたため、クラウド移行に抵抗してきた。
汎用暗号サービスは数年前にパブリッククラウドへ移行した。組織は、暗号鍵、証明書、デジタル署名、アプリケーションシークレットにマネージドシステムを日常的に利用している。
決済暗号技術はより緩やかな道をたどった。銀行は決済HSMを通常のKey Vaultに置き換えることはできない。決済システムには、専門的なコマンドと運用統制が必要だからだ。
決済アプリケーションは、確立されたHSMファミリーに結び付いたインターフェースを通じて通信することが多い。これらのアプリケーションを移行するには、鍵の移転や別のクラウドリージョンの選択以上の作業が必要になる場合がある。
移行は、メッセージ形式、鍵ブロック、監査プロセス、災害復旧、レイテンシ、外部決済パートナーとの接続に影響を及ぼし得る。変更のたびに、テストの範囲が拡大する可能性がある。
Atallaはこの歴史において重要な位置を占める。Mohamed Atallaは、現金自動預払機と銀行システムの間でPINを保護する技術を開発した後、1973年にAtalla Corporationを設立した。
この製品ラインはその後、複数の所有者を経て、2018年にUtimacoが買収した。インターフェースは、こうした移行を経ても決済環境に組み込まれ続けた。
Marvellによれば、Atalla Payment Moduleにより、既存アプリケーションは新サービスで使い慣れたAtallaインターフェースを利用できる。この互換性に関する主張は、決済インフラストラクチャの近代化における大きな障害に対応するものだ。
このアプローチは、アプリケーション側の決済ロジックを維持しながら、その下層のハードウェアを変える。完全な決済アプリケーションの書き換えというより、インフラストラクチャ移行に近い。
この区別はビジネスケースの中核をなす。移行によって決済スタック全体で安定稼働している取引ソフトウェアの置き換えを余儀なくされるなら、銀行がマネージドインフラストラクチャから得られるものはほとんどない。
パートナー各社によれば、顧客は既存のAtallaアプリケーションをAzure Payment HSM v2へ向けることができる。その後、Azureがスケーリング、可用性、バックアップ、復元、基盤ハードウェアを管理する。
Marvellは、クラウド移行に関する説明で有用な背景を示している。同社によれば、LiquidSecurity 2アダプター1台で最大10万の鍵ペアを管理でき、毎秒100万回を超える暗号操作を実行できる。
これらの数値は基盤となるアダプターを示すものであり、すべてのAzure Payment HSM v2導入におけるパフォーマンスを保証するものではない。アプリケーションのレイテンシは、ネットワーク、サービス構成、ワークロード設計にも左右される。
従来の導入では、容量計画も別の問題を生む。金融機関は、平均トラフィックがその水準を大幅に下回る場合でも、予想されるピーク需要に合わせて物理アプライアンスを用意することが多い。
また、冗長性、安全な管理、ファームウェア保守、予備容量、バックアップ手順、災害復旧も整備しなければならない。取引需要が安定している場合でも、こうした責任は継続する。
クラウドスケールのインフラストラクチャは異なるモデルを約束する。プロバイダーは、分離された顧客環境とハードウェアに裏付けられた鍵保護を維持しながら、共有ハードウェアフリートを運用できる。
このモデルは利用効率を改善し、プロビジョニングサイクルを短縮できる。一方で、サービス運用者、そのリージョン展開、障害管理手順への依存を集中させる可能性もある。
したがって、決済暗号技術が物理ハードウェアの近くにとどまってきたのには理解できる理由がある。新サービスによって、こうした懸念が消えるわけではない。
その代わりに、Azure Payment HSM v2は、インフラストラクチャ作業をMicrosoftへ移管しつつ、使い慣れた決済動作を維持しようとしている。その魅力は、アプリケーション境界での変更を減らせる点にある。
圧力は顧客運用の決済HSMに及ぶ
Azure Payment HSM v2が最も大きな圧力をかけるのは、顧客がアプライアンスの容量、可用性、保守、復旧を依然として自ら管理している導入環境だ。
Microsoftはすでに、Thales payShield 10Kデバイスを中心に構築されたAzure Payment HSMサービスを提供している。このサービスは専用の決済アプライアンスをAzureデータセンターに導入するが、顧客には依然として大きな責任が残る。
Microsoftの既存サービスに関するガイダンスでは、現行製品をベアメタルサービスとして説明している。顧客はプロビジョニング後に管理制御を引き受け、HSM構成に対する責任を引き続き負う。
既存サービスでは、デバイスを顧客の仮想ネットワーク内に直接配置できる。金融機関は可用性のためにペアのHSMを導入し、安全なリモートアクセスにはThalesの管理ツールを利用できる。
この構成は、専用アプライアンスモデルを放棄せずにクラウドホスト型アプリケーションを支援する。ただし、専用決済ハードウェアに伴う運用モデルをなくすものではない。
Microsoftは、既存サービスには決済HSM自体に関する特定のアップタイム保証がないと述べている。標準的なAzureネットワークのコミットメントは適用されるが、顧客はHSMの可用性を自ら設計しなければならない。
導入ガイダンスでは、別個のインフラストラクチャスタンプに複数のデバイスを配置することが求められている。顧客は、ロードバランシング、鍵のバックアップ、災害復旧のための代替リージョン導入も実装する必要がある。
これこそが、Azure Payment HSM v2が直接的に問い直すモデルである。新プラットフォームは、顧客が管理しなければならないホスト型ハードウェアではなく、マネージドサービスを約束する。
インフラストラクチャチームにとって、これにより複数の繰り返し発生する判断がMicrosoft側へ移る。これには、容量追加、障害機器の交換、プラットフォーム保守、復元の調整が含まれる。
セキュリティチームにとって、判断はより複雑になる。マネージド境界が、必要な統制、証跡、職務分離、鍵管理手順を維持しているかを判断しなければならない。
財務・調達チームにとって、比較はアプライアンス取得にとどまらない。専用インフラストラクチャには、施設、サポート、人員、冗長性、ライフサイクルに関するコストが伴う。
パブリックプレビューの発表には価格情報は含まれていなかった。そのため、購入者は発表だけを基に完全な商業比較を行うことはまだできない。
移行リスクは、直接的なインフラストラクチャコスト以上に重要となる可能性がある。安定したHSM導入は、多数の決済アプリケーションやパートナー接続の中核に位置する場合がある。
このコンポーネントを変更するには、広範な認証および運用レビューが必要になる場合がある。互換性のあるインターフェースであっても、ローカルアプライアンスとリモート管理エンドポイントの間にあるすべての違いをなくせるわけではない。
このリリースは、従来のAzureサービス群にも圧力をかける。Microsoftは、顧客がThalesベースのPayment HSMではなくv2を選ぶべき場面を説明する必要がある。
専用ハードウェアと直接的な管理権限を好む組織もある。一方で、インフラ管理の削減と迅速な拡張を優先する組織もある。
Microsoftは既存サービスの廃止に向けた方針を公表していない。顧客は、v2が直ちに現在のすべてのアーキテクチャを置き換えると考えるべきではない。
両モデルの共存は、むしろ機能となり得る。Azureは、リスク要件が異なる顧客向けに、高度に統制された専用デプロイメントと管理型決済暗号機能を併せてサポートできる。
このセグメンテーションが明確かどうかは、プレビューで明らかになる。特にコンプライアンスチームが責任分担を正確に整理する必要がある場合、製品境界が曖昧だと導入が遅れる可能性がある。
AWSが示す、管理型決済セキュリティはすでに競争市場であるという事実
より大きな争点はクラウドか否かではなく、どのクラウドモデルが許容可能な統制、互換性、コンプライアンスの証跡、運用の簡素さを提供するかにある。
AWS Payment Cryptographyはすでに、決済処理向けの管理型暗号機能を提供している。顧客は専用のPayment HSMインスタンスを調達することなく、これらの機能にアクセスできる。
AWSのサービスモデルは、発行会社、加盟店契約会社、プロセッサー、ネットワーク、スイッチ、決済ファシリテーターを含む決済参加者をサポートする。AWSによると、このサービスはPCI PIN、PCI P2PE、PCI DSSの要件に対応している。
AWSは、サービスAPI、コマンドラインツール、ソフトウェア開発キット、管理コンソールを通じて決済操作を提供する。リクエストはPCI認証済みHSMの管理フリートに到達する。
このアーキテクチャは異なる移行経路を提供する。アプリケーションは、馴染みのあるAtallaアプリケーション境界の管理版を受け取るのではなく、AWSのインターフェースに統合する。
Azure Payment HSM v2は、Atallaベースの既存環境との互換性を重視しているように見える。この焦点は、確立済みの決済コマンドを再設計せずにクラウド運用を望む金融機関に訴求する可能性がある。
どちらのアプローチも普遍的に優れているわけではない。API中心のサービスは、クラウドのID管理、監視、自動化、アプリケーションツールとの密接な統合を提供できる。
互換性中心のサービスは、特定のPayment HSMインターフェースにすでに依存している組織の変更を抑えられる。また、既存のAtallaデプロイメントを含むハイブリッド移行も簡素化できる可能性がある。
選択は購入者の出発点に左右される。新しい決済プラットフォームは、数十年にわたる統合の履歴を抱えることなく、クラウドネイティブAPIを評価できる。
大規模なプロセッサーには、既存のHSMファミリーを中心に構築された多数のアプリケーション、スクリプト、手順、パートナー接続がある場合がある。これらのインターフェースを維持することには大きな価値があり得る。
Thalesも引き続き重要な競争要因である。同社のpayShieldシステムは、既存のAzure Payment HSMサービスを含め、決済環境で大きな存在感を持つ。
すでにThalesを標準化している顧客にとって、移行する差し迫った理由はほとんどないかもしれない。スタッフ、アプリケーション、鍵セレモニー、監査プロセスがすでにそのプラットフォームに適合している可能性がある。
Utimacoは、MarvellとMicrosoftの提携を通じてクラウド決済ワークロードへの新たな経路を得る。Atallaソフトウェアは、従来型のAtallaアプライアンスと不可分であり続ける必要がなくなる。
Marvellは、すでにクラウドセキュリティ用途に位置付けられているハードウェア向けの専門的なワークロードを得る。この提携により、LiquidSecurityは一般的な鍵管理や署名のユースケースを超えて拡張される。
Microsoftは、管理型決済暗号機能においてAWSに対抗するためのより強力な回答を得る。また、Atalla顧客に対し、現在のThalesベースの運用モデルを採用するよう求めることなくサービスを提供する手段も得る。
この競争環境は、業界初という主張を限定する。初めてなのは、管理型クラウド決済暗号機能というカテゴリーそのものではない。
より妥当な「初」は、これら3社とそれぞれのレイヤーを組み合わせた管理型サービスに関するものだ。購入者は、ラベルではなく測定可能な機能を通じて、その結果としてのサービスを評価すべきである。
こうした測定項目には、サポートされる決済コマンド、リージョン提供状況、トランザクションレイテンシ、スループット、可用性に関するコミットメント、移行ツール、コンプライアンス文書が含まれる。
鍵交換への対応も重要である。決済組織は、厳格に統制された手順を用いて、金融機関、プロセッサー、ネットワーク、レガシーシステム間で鍵を頻繁に交換する。
管理型サービスは、こうした外部との関係に適合しなければならない。顧客が重要な鍵を交換・復旧する方法を無視し、Azure内部の部分だけをモダナイズすることはできない。
競争圧力により、時間の経過とともに文書はより明確になるはずだ。Microsoftは、Azure Payment HSM v2が既存サービスや外部の代替手段とどう異なるかを示す必要がある。
管理型インフラは決済セキュリティのリスクをなくさない
このサービスはハードウェア管理を軽減するが、アプリケーションセキュリティ、アクセス設計、移行判断、そしてコンプライアンス上の成果の多くは、依然として顧客が担う。
「管理型」という言葉は非現実的な期待を生みかねない。これはどちらの当事者がインフラを運用するかを示す言葉であり、すべてのセキュリティ義務がプロバイダーへ移転することを意味しない。
MicrosoftがHSMハードウェアを管理していても、顧客がアプリケーション権限を誤設定することはあり得る。また、顧客はHSM境界の外にある脆弱な運用統制を通じて、機密性の高いワークフローを露出させる可能性もある。
決済セキュリティはトランザクション経路全体に依存する。その経路には、アプリケーション、ネットワーク接続、オペレーターのID、鍵交換手順、監視、下流システムが含まれる。
HSMは、鍵と暗号操作のための保護環境を提供する。しかし、アプリケーションの別の場所にある不正なビジネスロジックや侵害された認証情報を修正することはできない。
プレビュー段階であることは、追加の不確実性をもたらす。この発表では、公開されたサービスレベルのコミットメント、最終的な提供開始スケジュール、完全なリージョンロードマップ、公開価格体系は示されていない。
また、実稼働顧客の実名も示されていない。独立した性能結果や移行事例は、このリリースに含まれていなかった。
こうした詳細がないことは、初期プレビューでは通常のことである。しかし規制対象の金融機関は、ミッションクリティカルな認可またはPIN処理ワークロードを移行する前に、それらを必要とする。
リージョンのカバレッジも別の制約となる。米国西部と西ヨーロッパは2つの出発点を提供するが、多国籍金融機関はより具体的なデータ所在地と復旧の選択肢を必要とすることが多い。
サービスがデータ主権をサポートできるのは、利用可能なリージョンが組織の法的・運用上の要件と合致する場合に限られる。国境を越える復旧計画には、別途制約が課される可能性がある。
各社は、このプラットフォームは高可用性だとしている。それでも導入検討者は、冗長性、障害ドメイン、メンテナンス時の挙動、復旧目標、リージョンフェイルオーバーに関する具体的な情報を必要とする。
鍵主権についても慎重な検証が必要である。顧客は、Microsoftが実行可能な操作と、顧客の権限下にのみ残る統制を正確に確立すべきだ。
鍵がどのようにサービスへ入り、どのように外へ出るのか、バックアップがどう保護されるのか、緊急時の復旧がどのように機能するのかを検討する必要がある。廃止手順にも同様の注意が必要だ。
互換性に関する主張は、実際のアプリケーションでテストする必要がある。馴染みのあるAtallaインターフェースが、同一のタイミング、エラー挙動、サポートコマンド、運用ツールを保証するわけではない。
以前は同じデータセンター内のHSMにアクセスしていたトランザクションシステムでは、ネットワークレイテンシが重要になる可能性がある。わずかな変更でも、厳格な処理目標を持つシステムに影響を与え得る。
チームは通常のワークロードだけでなく、障害条件もテストすべきである。ピークトラフィック、接続喪失、スロットリング、メンテナンスイベント、リージョン障害は、異なる挙動を明らかにする可能性がある。
また、サービスがどのように監査証跡を生成するかも確認すべきだ。コンプライアンスチームには、プロバイダー統制と顧客統制を該当するPCI要件に対応付ける文書が必要になる。
PCIへの適合は顧客のスコープをなくさない。組織は依然として、認定評価者に完全な環境と運用手順を評価してもらう必要がある。
ベンダー集中は別のトレードオフをもたらす。3つの専門ベンダーを組み合わせることでサービスは強化され得るが、各社のロードマップとサポート組織にまたがる依存関係も生じる。
インシデントがAzureプラットフォーム、Marvellハードウェア、Utimacoソフトウェアをまたぐ場合、顧客には明確なエスカレーション経路が必要になる。責任の所在が曖昧であれば、復旧時間が長引く可能性がある。
これらの問いはサービスの価値を否定するものではない。魅力的なアーキテクチャを信頼できる決済プラットフォームへ転換するために必要な作業を定義するものだ。
次に何が起きるかを決める3つのシグナル
リージョン拡張、検証済みの移行結果、本番環境レベルのコミットメントが、Azure Payment HSM v2が決済インフラを変えるのか、それとも専門的なプレビューにとどまるのかを示す。
第1のシグナルはMicrosoftの提供ロードマップである。リージョンの追加は、グローバル展開、ローカル処理、準拠した災害復旧の根拠を強化する。
拡張が遅ければ、サービスはより限定的なワークロードに制約される。さらに多国籍顧客は、初期提供範囲外の市場で専用HSMを維持せざるを得なくなる可能性がある。
第2のシグナルはAtalla移行から得られる証拠だ。MicrosoftとUtimacoは、既存アプリケーションがどのように接続し、鍵を転送し、障害に対処し、監査統制を維持するかを示すリファレンスアーキテクチャを提示する必要がある。
実名の顧客デプロイメントは、一般的な互換性の説明よりも説得力を持つ。金融機関が重要な決済アプリケーションを再設計せずにモダナイズできるかを示すことになる。
性能の証拠には、ハードウェア容量だけでなくアプリケーションレベルの測定を含めるべきだ。購入者には、現実的なトランザクションパターンとリージョンのネットワーク条件下でのレイテンシおよびスループットの結果が必要である。
第3のシグナルは本番サービス契約だ。一般提供開始にあたっては、サービスレベル、サポート責任、復旧時の挙動、コンプライアンスの証跡、運用境界を対象とする明確なコミットメントが求められる。
これらの詳細によって、顧客がv2を重要インフラとして扱うかどうかが決まる。規制対象の購入者が、その判断をハードウェア仕様だけに基づいて下すことはめったにない。
競合他社の反応にも注意を払うべきだが、実行力に比べれば二次的である。AWSは対応操作を拡張でき、Thalesは専用または管理型デプロイメントの選択肢を強化できる。
Microsoftにとって当面の課題は、新しい責任モデルが機能することを証明することだ。同社は、顧客による決済鍵の統制を弱めずにインフラを運用しなければならない。
Marvellにとっての試金石は、クラウドハードウェアの経済性と予測可能な性能である。同社のLiquidSecurityプラットフォームは、厳しい運用条件下で専門的な決済ワークロードをサポートしなければならない。
Utimacoにとっての試金石はソフトウェアの移植性だ。Atalla互換性は、馴染みのあるアプライアンスからMicrosoftの管理型サービス環境への移行を経ても維持されなければならない。
銀行と決済プロセッサーは、範囲を限定した評価から始めるべきである。統制されたワークロードであれば、中核的な認可トラフィックを直ちにリスクにさらすことなく、統合上のギャップを明らかにできる。
チームはテスト前に、現在のHSM依存関係を文書化すべきだ。そのインベントリには、コマンド、鍵フォーマット、アプリケーション、パートナーとの鍵交換、レイテンシ目標、復旧手順を含める必要がある。
その後、プレビューを既存のAzureサービス、AWS Payment Cryptography、現在のインフラと比較できる。重要なのは一般的なクラウド志向ではなく、運用上の適合性である。
Azure Payment HSM v2は、鍵管理をハードウェア運用から分離するための信頼できる新たな選択肢を決済事業者に提供する。ただし、その分離が自動的に実現されるわけでも、リスクがないわけでもない。
次の問いは実務的なものだ。規制対象の顧客がマネージドモデルを信頼できるよう、Microsoftは制御、可用性、移行パスを十分に文書化できるのか。
このサービスを評価する組織は、重要なトランザクション経路に導入する前に、この3つのシグナルを注視すべきだ。リージョンごとの挙動をテストし、Atallaとの互換性を検証し、本番環境における明確なコミットメントを求める必要がある。
これらの結果が期待どおりであれば、Azure Payment HSM v2は、より多くの決済ワークロードでハードウェア所有を任意にすることで、専用デプロイメントに圧力をかけるだろう。そうでなければ、金融機関は最も機密性の高いシステムの近くで、使い慣れたアプライアンスを使い続けることになる。
