香港の決済会社が想定していなかったペネトレーションテスト要件

要点： 香港のライセンスを持つ決済会社が、通常の規制レビュー要請を受け取り、その中でペネトレーションテストの証拠提出を求められる——そして少人数のIT担当チームは、「証拠」とは2年前に一度実施したスキャンのPDF一枚では足りないことに気づく。これは複合的な例示シナリオであり、特定の実在顧客を指すものではない。本稿では、テストが単発の出来事から継続的なサイクルへと変わったときに何が変わるのか、そしてITパートナーの運用面での役割がどこで終わり、企業自身のコンプライアンスおよび法務判断がどこから始まるのかを整理する。

ライセンス取得後も消えない規制当局の目

香港には、ライセンスを持つ決済・送金サービス企業が数多く存在する——ストアドバリューファシリティ（SVF）事業者、マネーサービス事業者、そして資金移動や決済処理を中核事業とする企業だ。ライセンス取得は一つの節目にすぎない。その後に何が起きるかは、外部からは見えにくい。香港金融管理局（HKMA）およびその関連フレームワークは、ライセンス企業がテクノロジーリスクをどのように管理しているかに継続的な監督上の関心を持っている——それはライセンス取得時に一度チェックすれば終わる項目ではなく、継続的な監督関係である。

その関心の現れ方は企業ごとに異なる——定期的な報告、随時の情報要請、オンサイトまたはオフサイトのレビュー、業界内の他社で発生したインシデントを契機とした問い合わせなど。HKMAのテクノロジーリスク関連ガイダンスが一般に説明されている範囲で公に理解されているのは、ライセンス企業が自社のテクノロジーリスク——自社のアプリケーションやインフラが悪用可能な弱点を抱えるリスクを含む——を理解し、能動的に管理していることを示すよう期待されているという点だ。特定のレビューが具体的に何を、どのようなスケジュールで、どのような基準に照らして求めるかは、HKMAと企業自身のコンプライアンス機能との間の判断事項であり、テクノロジーベンダーが企業に代わって予測したり約束したりできるものではない。以下では、この問いが実務上取る典型的な形と、その運用面についてのBrocent自身の考え方を、香港の金融サービス業界における実際の業務経験に基づいて説明する。

この種のライセンスを持つ企業は、HKMA関連の話題でより頻繁に取り上げられる銀行や保険会社よりも、往々にしてはるかに小規模である。従業員100人未満の決済・送金事業者が銀行並みの規模の専任コンプライアンス部門を持つことは稀で、セキュリティ専任の担当者すら置いていないことも非常に多い——規制レビューの技術的な質問に答える人物が、同時にヘルプデスクのチケット処理やクラウドホスティングの請求管理も担当しているというのは、決して珍しいことではない。これはこうした企業の運営方法を批判するものではなく、少人数体制の決済事業者が直面する現実的な運用実態にすぎない。そして、この現実こそが場当たり的なテスト対応が根付きやすい土壌であり、他のあらゆる業務に加えて継続的なテストプログラムを維持する余力を持つ人がいないというのが実情だ。

この客層が銀行や保険会社と異なる理由

香港の金融IT分野で公に語られる話題は、ヘッジファンドやファミリーオフィス、保険ブローカーといった、コンプライアンス人員が比較的充実し、テストプログラムが（存在する場合）すでに一定の成熟度を持っていることが多いセグメントに偏りがちだ。ライセンスを持つ決済・送金企業は明らかに異なる客層である——概して組織はより小規模で、事業としての歴史も浅く、プラットフォームがすでに当初の設計範囲を大きく超えて成長した時点で、初めて自社のテクノロジー態勢に対する本格的な規制レビューに直面することが多い。本稿が描くギャップは、このセグメントにとって仮説的な例外事例ではなく、むしろデフォルトの出発点に近い——だからこそ、単に「もっとテストをすべき」という一般論よりも、運用面での改善策のほうがはるかに実際的な意味を持つ。

レビュー要請と、手元の証拠が噛み合わない瞬間

従業員約50〜90人の香港ライセンス決済会社を想像してほしい。この会社は着実に成長してきた——新しい加盟店との連携、増え続ける取引量、そして数年かけて元のプラットフォームに積み重ねられてきたいくつかの新しい製品ライン。IT機能は小規模で、数名のチームがプラットフォームの稼働、機能開発、日常サポートを担っている。セキュリティテストがまったく行われてこなかったわけではないが、同規模の多くの企業と同じように、その実施は受動的だった。決済用口座を開設する前に、取引を予定していた銀行がペネトレーションテストのレポートを求めたため、一度委託した。その1年後、ある大口加盟店自身のベンダーセキュリティ質問票が同じ質問をしてきたため、スキャンを一度実行した。継続的なテストプログラムを所有する担当者は誰もいない。テストは常に「直近で誰が尋ねてきたか」への対応であり、誰かのカレンダーに定期的に組み込まれた項目ではなかった。

そこへ、通常の監督レビューが到着する——インシデントを契機としたものではなく、ライセンス企業が時折直面すると想定しておくべき類の定期的な確認である。その中の一つの質問には、これまで非公式には答えたことがあったが、きちんと文書として整理したことは一度もなかった——御社のペネトレーションテストプログラムは何か、その証拠を提示できるか、というものだ。会社は手元にあるものをかき集める。約2年前に実施した一度のテストのPDF——それは自社のリスク管理のために能動的に手配したものではなく、銀行の口座開設プロセスに対応するために委託したものだった。それ以降の記録は一切ない。実際に何がテストされたのかも、明確には答えられない——公開されている決済APIなのか、加盟店ポータルなのか、社内ネットワークなのか、それとも三つすべてなのか。当時そのスコープを決定した人物は、今では誰も社内に残っていない。

このギャップが露呈するのはまさにこの瞬間だ。会社が不注意だったからではない——プラットフォーム自体は比較的しっかり運用されており、最初のテストも捏造や手抜きではなかった——問題は、テストが一度もプログラムとして構築されてこなかったことにある。それは、その時々で最も強く要求してきた相手への一連の単発対応として構築されてきたにすぎない。

「一度スキャンした」が実際に露呈させるもの

企業が「テストは実施している」と口頭で主張するだけでなく、実際にレビュー担当者にテスト履歴を提示しなければならなくなったとき、通常次の三つの問題が浮かび上がる。

• 日付の入った証拠の連続性がない。 2年前の一度きりのレポートは「一度でもテストしたか」には答えられても、「現在、テスト済みで最新の状態のセキュリティ態勢を維持しているか」には答えられない。そのレポート以降、明らかに変化した技術スタック——新しい連携、新しい製品ライン、場合によっては新しいインフラ——を見たレビュー担当者には、それらの変化が一度でもテストされたのかどうかを知るすべがない。
• スコープが不明確。 レポートが存在していても、会社側がそれが何をカバーしていたのかを自信を持って説明できないことがある。外部ネットワークのみだったのか、Webアプリケーション層も含んでいたのか。前回のテスト以降に追加されたAPIエンドポイントは含まれていたのか。範囲が明確に記録・保管されていないレポートは、何か具体的な事項について現行の証拠として主張するのが難しい。
• 締め切りに追われた駆け込み対応。 ギャップが露呈すると、すぐにテストを予約したくなるものだが、資格を持つテストチームはしばしば数週間先まで予約が埋まっており、締め切りに追われた駆け込みの依頼は、計画的に実施されるテストよりも悪い出発点になる。一つのレビュー担当者の質問に答えるためだけに委託されたテストは、継続的なプログラムの最初のサイクルとしてではなく、会社が本来脱却しようとしているまさにその単発パターンを繰り返す結果になりがちだ。

これら三つの問題は、実は個々のテストの品質そのものとはあまり関係がない。個々のテストを取り囲むプログラム構造が存在するかどうかの問題であり、それこそが「一度テストをした」を「テスト済みで最新状態の環境を維持しており、それを正確に示すことができる」に変える要素なのだ。

Brocentの役割はどこから始まり、どこで終わるか

このような状況において、ITおよびセキュリティパートナーに何ができて何ができないのかを率直に説明しておくことは重要だ。ベンダーが自らの役割を過大に主張することが、ライセンス企業にとって何の利益にもならない、まさにそういう状況だからである。

このような状況におけるBrocentの役割は運用面のものであり、規制上のものではない。具体的には——実際の企業環境に合わせてスコープを設定したペネトレーションテストエンゲージメントを通じて、有資格のテスターとCVSSスコア付きの、概念実証（PoC）付きの調査結果とともに、企業自身が設定し維持するスケジュールに沿って実際のテストを実施すること。時間をかけて証拠の連続性を築く文書記録と日付入りレポートを維持すること。何がテストされ、いつ実施され、何が見つかり、どう修正されたのかを、企業のコンプライアンスチームが平易な運用言語で理解できるよう支援すること。Brocentが行わない、また行うべきではないこととして——ライセンス企業に対し、その規制当局が何を十分と判断するかを伝えること、特定のテストサイクルがHKMAの特定の要件を満たすと認定すること、あるいはレビューが実際に何を求めているかを解釈する上で企業自身のコンプライアンス・法務顧問の代わりを務めることが挙げられる。これらの判断は企業自身のコンプライアンス機能、そして必要に応じて外部の法律顧問に属するものであり、どれほど経験豊富であってもテクノロジーベンダーに属するものではない。そうでないと主張するパートナーは、実際には果たせないことを約束していることになる。

この役割分担は率直に繰り返しておく価値がある。5人程度の少人数体制のITチームにとって、実際よりも物事を単純に考えたくなるのは自然なことだからだ。しかし、どれほど資格を持つベンダーであっても、ライセンス企業に「コンプライアンス達成済み」と書かれた証明書を渡すことはできない。Brocentが企業に提供できるのは、日付が入り、範囲が明確で、是正済みで、最新状態に保たれた証拠一式である。企業自身のコンプライアンス機能は、それをもとに自らの規制当局に対して自らの立場を主張することができる。証拠を提供するのはBrocentの仕事だ。その証拠が特定のレビューにとって十分であるかどうかの判断は企業自身の仕事であり、企業のコンプライアンス・法務顧問を通じて行使される。この二つを混同することが、企業がつまずく原因になりやすい——ベンダーが「コンプライアンスは対応済み」と示唆したために投資不足に陥るか、あるいは環境がすでに変化しているにもかかわらず、過去の一度のテスト結果を過度に信頼し続けるかのいずれかだ。

維持されたテストサイクルが実際にどう機能するか

場当たり的なテストと維持されたプログラムという二つの状態の実際の違いは、理念の転換ではなく、いくつかの具体的な習慣に集約される。

• 単発の予約ではなく、繰り返されるスケジュール。 外部から依頼が来たときにだけテストを委託するのではなく、企業自身が選び、説明できる一定の間隔で運用する——一般的には最低でも年1回、決済データを直接扱うシステムについてはより頻繁に実施されることもある。Brocent自身のペネトレーションテストエンゲージメントはまさにこの形で設計されており、単発の時点レポートではなく、是正後の再テストを含む年間テストパッケージが用意されている。
• 必要なときだけ探し出す単一ファイルではなく、継続的な証拠の連続性として保管される日付入りレポート。 各サイクルのレポート、スコープの記録、是正記録が積み重なり、コンプライアンス責任者が時間的プレッシャーの中で慌てて再構築する必要なく、そのままレビュー担当者に提示できる履歴を形成する。
• 範囲が固定されたものと想定せず、サイクルごとに見直す。 前回のテスト以降、加盟店向けの新しいAPIを追加したり、インフラの一部を新しいクラウド環境に移行したり、新しい製品ラインを立ち上げたりした企業は、実質的に未テストの攻撃対象領域を新たに増やしていることになる。デフォルトで前回と同じテスト計画を繰り返すのではなく、各サイクルの開始時にスコープを見直すことこそが、クラウドでホストされている部分を含め、証拠の連続性を現在の環境に確実に適合させ続ける方法だ。
• スキャンとテストを混同せず、それぞれに適したサイクルで明確に区別して運用する。 脆弱性スキャンは自動化されており、対象範囲が広く、より頻繁なサイクルに適している。ペネトレーションテストは手動で、より深く、頻度は低いがより徹底したサイクルに適している。どちらか一方しか実施していない企業には、どちらが欠けているにせよ、実質的なギャップが存在する。

これらはいずれも特別なツールや大規模な社内セキュリティチームを必要としない。必要なのは、外部から質問されるたびに発生する取引としてではなく、明確な担当者を持つ継続的なプログラムとしてテストの関係性を構築することだ。

香港の決済会社がペネトレーションテストに取り組む3つの方法

• 正式なプログラムがない。 顧客、銀行の取引先、あるいは加盟店が直接証拠を求めてきたときにのみテストが行われる。定期的なスケジュールも、一貫したスコープ管理もなく——上記のシナリオが示すように、レビュー担当者がこれまで書面で答えたことのない質問を投げかけた瞬間に、実質的なリスクが露呈する。
• 保管された一度きりのテスト。 何もないよりはましだ——少なくとも日付の入ったレポートが一つは存在する。しかし、変化し続けるプラットフォームに対しては、一度きりのテストはすぐに陳腐化する。それが答えるのは「一度でもテストしたか」であって、「現在実際に運用しているものを現在テストしているか」ではない。
• 維持された証拠の連続性を伴う繰り返しのテストサイクル（Brocentのモデル）。 企業自身が所有し説明できるスケジュールでテストが運用され、各サイクルで現在の環境に照らしてスコープが見直され、レポートと是正記録が積み重なって説得力のある履歴を形成し、企業のコンプライアンスチームはいつでもその履歴を提示できる——そして「十分」かどうかという規制上の判断は、本来あるべき場所、すなわち企業自身とその顧問の手元に留まる。

よくある質問

脆弱性スキャンはペネトレーションテストの要求を満たしますか？

一般的には単独では満たしません——この二つは異なる活動です。脆弱性スキャンは自動化ツールを使って広範囲にわたる既知の弱点を特定するものであり、ペネトレーションテストは有資格のテスターがそれらの弱点を実際に悪用しようと試み、複数の弱点を連鎖させ、現実世界での影響を実証するものです。レビュー担当者が特にペネトレーションテストについて尋ねている場合、スキャンレポートを同等の証拠として受け入れる可能性は低いでしょう。ただし両者は補完関係にあり、成熟したプログラムでは通常、それぞれに適したサイクルで両方を実施します。特定の規制当局や特定のレビューが一方をもう一方の代わりとして受け入れるかどうかは、企業自身のコンプライアンス判断の範囲であり、ベンダーが企業に代わって断定すべき事柄ではありません。

ライセンス企業はどのくらいの頻度でテストすべきですか？

すべての企業に当てはまる単一の数字は存在せず、Brocentも特定の頻度を規制上の要件として断定することはありません。実務上、決済データを扱う企業に一般的に見られるのは、最低でも年1サイクルというペースで、外部向けの新しいシステム、重大なインフラ移行、顧客資金に関わる新しい製品ラインといった重大な変化があれば追加のテストが発生するというパターンです。特定の企業にとって適切なサイクルは、企業自身のコンプライアンス・リスク機能が関与し、その実際のリスクプロファイルに基づいて判断すべき事項です。

テストの証拠の連続性には何を含めるべきですか？

最低限、各テストサイクルに対応する日付入りレポート、何が（システム、環境、テストの種類）テストされたかを明確に説明するスコープ記述、深刻度評価付きの調査結果、そして何がいつ修正されたかを示す是正記録——理想的には修正が確認された再テストも含みます。目標は、コンプライアンス責任者が散在するファイルから履歴を組み立て直す必要なく、明確で時系列に沿った全体像をレビュー担当者に提示できることです。

自社のテストプログラムが十分かどうかは誰が判断するのですか？

企業自身が、自社のコンプライアンス機能とともに、必要に応じて外部の法律またはコンプライアンス顧問と連携して判断します——自社のライセンスと事業に適用される具体的な規制上の期待に基づいてです。Brocentを含むITまたはセキュリティベンダーは、自社のテストプログラムが何を行うかを説明し、企業が必要とする証拠を提供することはできますが、あるプログラムが特定の規制基準を満たしていると企業に伝えることはできませんし、すべきでもありません。その判断は企業自身のものであり、テストの実施という運用作業とは本質的に異なる種類の判断です。

同じプロバイダーがスキャンとテストの両方を担当できますか？

可能です——同じ環境に対して両方の活動で可視性を持つ単一のプロバイダーであれば、より一貫した文書管理を維持しやすいため、比較的一般的な構成です。ただし必須ではありません。テストと、より広範なマネージドIT関係とであえて別々のプロバイダーを使う企業もあります。証拠の連続性にとって最も重要なのは、どのプロバイダーの組み合わせを採用するかではなく、テストを担当するプロバイダーが一貫したスケジュールで、日付入りの記録を保持しながら実施することです。

レビューで過去のテスト記録がないことが判明した場合、何が起きますか？

それは企業と規制当局の間の問題であり、Brocentは具体的な規制上の結果について推測することはしません。ITパートナーがコントロールできるのは、その時点から企業が迅速かつ説得力を持って対応できるよう支援することです——速やかにスコープを設定してテストを実施し、さらに重要なのは、同じギャップが次回のレビューで再び現れないよう、継続的なプログラムを立ち上げることです。ある指摘事項への企業の対応の仕方、そしてそれがどう受け止められるかは、一般的に、当初のギャップそのものと同じくらい、その後何が変わったかによって評価されます。

クラウドでホストされたインフラは、テストすべき内容を変えますか？

変わるのはスコープに含めるべき対象であり、テストが必要かどうかではありません。一部または全部がクラウド上で稼働している決済プラットフォームにも、依然として攻撃対象領域は存在します——API、Webアプリケーション層、アイデンティティおよびアクセス設定、そしてクラウドプロバイダーの責任共有モデルによっては、企業自身が直接テストの責任を負うインフラ層の一部です。前述の「サイクルごとにスコープを見直す」というプラクティスは、まさにこうした変化を捉えるためのものです——前回のテスト以降のクラウド移行は、まさにテスト範囲を改めて見直すべきトリガーとなる変化の一つです。

テストサイクルを一連の単発予約ではなく、マネージドITプランに組み込む

このシナリオの企業には、実は独立した「テストの問題」があるわけではない——「プログラムの問題」があり、テストがたまたま最初にそれを露呈させた場所にすぎない。よく見れば、同じギャップは他の領域にも現れがちだ——パッチ適用のサイクル、バックアップの検証、アクセス権のレビューなど、こうした継続的な運用上の規律はいずれも、製品も出荷し続けなければならない5人程度のITチームにとって、一度実施するのは簡単でも、一貫して続けるのは難しい。

だからこそBrocentは、維持されたテストサイクルを、レビュー担当者が質問してくるたびに個別に交渉する一連の予約としてではなく、継続的なマネージドITプランに組み込まれるものとして位置づけている。同ページで提供されているユーザー単位課金のマネージドITプランは、まさにこうした継続的な運用規律を中心に構築されている——セキュリティテスト、パッチ適用、監視、文書化が、必要になるたびに締め切りのプレッシャーの中でゼロから組み立て直すのではなく、この関係性の定常的な一部として、決まったサイクルで運用される。ライセンスを持つ決済会社にとって、この一貫性こそが実際の価値である——一度合格したテストではなく、次に「テストプログラムを見せてほしい」と問われたときにいつでも、説得力があり最新状態の答えを返せることだ。ペネトレーションテスト、そして環境上より高度なテスト層が必要な企業向けのRed Team上級ペネトレーションテストのオプションは、このプランの到達点そのものではなく、その中に含まれる追加項目として位置づけられている——エンゲージメントとエンゲージメントの間もサイクルを継続的に動かし続けているのは、このプランなのだ。

もし貴社がレビュー要請に直面しており、現在のテスト履歴に満足していないのであれば、実務的な次の一歩は駆け込みでのテスト予約ではなく、まず対話から始めることだ。マネージドITプランの料金をご覧いただくか、お問い合わせいただき、貴社の具体的な環境に合った維持可能なテストサイクルがどのようなものかを一緒に検討していただきたい——そして規制対応の側面において、Brocentの運用面での役割が貴社自身のコンプライアンス・法務判断とどのように連携するのかについても。