Help Net Securityのインタビューに応じたHikvisionのグローバル情報セキュリティ担当VP、チャック・デイビス氏は、ゼロトラストの概念をカメラやドアコントローラーといった物理セキュリティシステムにどう適用するかを解説しています。デイビス氏は、かつての境界防御的な前提を持ち込まずにエッジで信頼判断を行う方法、これらのデバイスをITアセットとして扱うべき理由、そしてMiraiボットネットが業界に与えた教訓について詳しく説明しています。
また、標準的なエージェントを実行できないデバイスのポスチャアセスメント、数万台規模のエンドポイントにおけるデバイスのアイデンティティ管理、そしてインシデント発生中に信頼を失効させる方法についても取り上げています。
ゼロトラストの原則は「常に疑い、常に検証する」ですが、物理セキュリティシステムにはシビアな制約があります。200ミリ秒以内に行わなければならないドア解錠の判断は、レイテンシの生じるクラウド型ポリシーエンジンを待つ余裕がありません。排除しようとしているはずの境界防御的な前提を再び持ち込まずに、エッジで信頼判断を設計するにはどうすればよいのでしょうか？
ゼロトラストに関する最大の誤解の一つは、すべての認可判断をリアルタイムで集中型ポリシーエンジンに送らなければならないという思い込みです。この誤解は、物理セキュリティシステムをゼロトラストアーキテクチャから除外する理由として頻繁に持ち出されます。まるでドアコントローラーの200ミリ秒という制約が、健全なセキュリティ原則の適用免除を意味するかのような扱われ方です。しかしこれは設計上の制約にすぎず、この制約を満たしながらもゼロトラストの核心原則——ネットワーク上の位置だけを根拠に何かを信頼してはならない——を守るための、実績あるアーキテクチャが存在します。
ゼロトラストが求めるのは、集中型での意思決定の実行ではありません。集中型での信頼ガバナンスです。この二つは別物であり、その違いを明確に理解することがエッジでの実施を機能させる鍵となります。
このような場面で私が推奨するモデルは、「集中型ポリシーによる分散型信頼」です。ポリシーの作成、アイデンティティガバナンス、認可ロジックは集中管理します。一方、実際の実施はレイテンシや運用継続性が重要なエッジで行います。このアーキテクチャを実現するのが、ポリシー決定ポイント（PDP）とポリシー実施ポイント（PEP）の分離です。PDPはアイデンティティ、コンテキスト、ポリシー、リスクシグナルに基づいてアクセスを許可すべきか判断します。エッジコントローラーやアクセスデバイスに存在するPEPは、その判断をローカルで実行します。ドアは200ミリ秒をはるかに下回る時間で開きます。その判断を支配するポリシーは集中型システムで作成・検証され、そこから配布されたものです。
ここで重要なのは、ローカルでの実施はローカルでの信頼を意味しないという点です。エッジデバイスは、暗号署名されたポリシー、短命のクレデンシャル、明確に定義されたアクセス境界のもとで動作すべきです。ポリシーはローカルに配布・キャッシュされますが、管理は集中型で行われ、定期的に更新され、再検証の対象となります。特定のVLANや建物内ネットワークに存在するからといって、コントローラーを信頼すべきではありません。それは旧来の境界型セキュリティモデルを disguise したものにすぎず、意識的に排除しなければゼロトラストアーキテクチャにじわじわと忍び込んできます。
ここが組織にとって運用上の落とし穴となる部分です。最初は良好に設計されたアーキテクチャと90秒のポリシーキャッシュ有効期間から始まります。しかし、ネットワークの不具合でドアが開かず、ファシリティ部門にチケットが上がります。根本的なネットワーク信頼性の問題を修正する代わりに、セキュリティチームは再発防止のためにキャッシュ有効期間を延ばします。90秒が30分になり、4時間になり、12時間のオフライングレース期間になります。その時点では、もはやエッジのゼロトラストとは呼べません。一例外ずつ積み重なった結果、誰もそれをセキュリティ上の意思決定として記録しないまま、境界型セキュリティへと静かに後退していくのです。
このアーキテクチャでは、フェイルセーフとフェイルセキュアのどちらを取るかについても明確な答えが必要です。そしてその答えはすべてのドアで同じではありません。緊急退出システムは可用性と人命安全を優先するよう設計されることが多いため、ネットワーク障害時はデフォルトで開放状態になるべきです。高度に制限された環境では逆の設定が必要な場合もあります。これらの結果は、ネットワーク接続の切断による偶発的な副作用ではなく、明示的なアーキテクチャ上の設計判断として定めるべきです。
結局のところ、ゼロトラストとはすべての判断をクラウド経由でルーティングすることではありません。判断がどこで行われるにせよ、それがアイデンティティを認識し、制約があり、継続的に検証され、失効可能であることを保証することです。200ミリ秒のドアコントローラーはこの原則の例外ではありません。むしろ、アーキテクチャがその動作環境に合わせて設計されなければならない理由を、特に明確に示す事例といえます。
Hikvisionのデバイスは、IoTエンドポイント、データプロセッサー、物理的アクチュエーターという三つのアイデンティティが交差する興味深い存在です。顧客環境の脅威モデリングを行う際、この三つのアイデンティティの中で最も危険なブラインドスポットを生み出すのはどれでしょうか？また、そのブラインドスポットが悪用された実際のシナリオを教えてください。
ご質問の前提は、組織がこれら三つのアイデンティティをすべて積極的に管理しており、そのうちの一つを間違えているというものです。しかし業界全体でより一般的な課題は、根本的な認識転換がまだ十分に浸透していないことです。物理セキュリティデバイスは、本来あるべきITアセットとして、いまだ普遍的には扱われていません。
物理セキュリティ機器を物理的な目的だけで捉えがちな傾向があります。カメラはカメラ、バッジリーダーはバッジリーダー、NVRは録画アプライアンスといった具合です。この見方がすべての下流工程を規定します。デバイスのインベントリ管理、メンテナンスの方法、そして組織内でそれらのシステムのサイバーリスクがどう割り振られるかまでが、この見方に左右されます。しかし物理セキュリティデバイスがネットワークに接続された瞬間、それはまったく別の存在になります。オペレーティングシステム、認証サービス、API、Webインターフェース、データベース、暗号化機能、リモート管理機能を実行する組み込みコンピューティングプラットフォームになるのです。
物理セキュリティとITが別々のサイロで運用されている場合、そのリスクはその間のギャップに落ち込みます。そこがブラインドスポットの温床です。
このことをセキュリティ業界全体にとって鮮明に浮かび上がらせたのが、2016年のMiraiボットネットです。Miraiの攻撃者はインターネット上のIoTデバイスをスキャンし、出荷時のまま変更されていないデフォルトクレデンシャルでログインすることで、IPカメラやDVRを大量に侵害しました。ゼロデイ攻撃も高度な手口も使っていません。侵害されたカメラはボットネットに組み込まれ、記録上最大規模の分散型サービス拒否（DDoS）攻撃の発射台となりました。2016年10月にDynを標的とした攻撃では、Twitter、Reddit、Netflix、そして広大なインターネットインフラが数時間にわたってダウンしました。
Miraiがこれほどの被害をもたらしたのは、攻撃の高度さによるものではありません。これらのデバイスのデプロイとセキュリティ確保について、業界全体での一貫した基準がまだ確立されていなかったことが原因です。デバイスはファイアウォールの保護なしにインターネットに公開されていました。セキュリティ強化のガイダンスは一貫性がないか、存在しませんでした。物理セキュリティセグメントのネットワーク監視はほぼ行われていませんでした。Miraiは、これらのデバイスの実際のデプロイ状況と、ネットワーク接続されたITアセットとして管理すべき姿のギャップを白日の下にさらしました。
これがブラインドスポットの正体です。複雑な脅威モデルに対する高度な攻撃ではありません。デフォルト設定のまま、インターネットに公開され、自らが生成しているトラフィックをおそらく誰も監視していなかったカメラ——それだけのことです。
これらの対策のほとんどは目新しいものではありません。課題は運用上の規律です。物理セキュリティデバイスを専用のネットワークセグメントに隔離する。インターネットからの直接インバウンドアクセスを遮断するファイアウォールの背後に配置する。ファームウェアを最新の状態に保つ。メーカーのセキュリティ強化ガイダンスに従う。リモートアクセスが必要な場合は、VPNまたはゼロトラストネットワークアクセスソリューションを使用する。攻撃者がセキュリティカメラに到達できなければ、そのカメラを攻撃することもできません。
物理セキュリティインフラはエンタープライズITインフラです。最も重要なアーキテクチャ上の転換は、そう認識してそのように管理することです。
ファームウェアは物理セキュリティデバイスのアキレス腱です。EDRエージェントを実行できず、業務時間中にパッチを適用できず、ファシリティ予算に7年間の減価償却サイクルが組み込まれているカメラやアクセスリーダーに対して、ゼロトラストのポスチャアセスメントはどのように行うのでしょうか？
このような環境での成熟したゼロトラストアセスメントは、ある不快な現実を受け入れることから始まります。多くの物理セキュリティデバイスは、エンタープライズのノートPCやサーバーと同じレベルのセキュリティテレメトリや制御の深さを達成することは決してないという現実です。従来のITセキュリティの前提を無理に当てはめようとすると、フラストレーションと不適切なリスク判断につながります。目標は完全な可視性ではなく、補完的な管理策によるリスク低減です。
ここで最も有用だと私が考えるコンセプトは、「トラストエンベロープ」です。デバイスを直接計装しようとするのではなく、そのデバイスを取り巻く許容可能な動作の境界を定義して実施します。このデバイスはどの相手と通信すべきか？どのプロトコルで？どのくらいの頻度で？どのくらいの量で？隣接するインフラのネットワークテレメトリを通じて把握されたそのプロファイルが、ポスチャの代替指標となります。ローカルの映像管理サーバーとのみ通信すべきカメラが、見覚えのないインフラへのアウトバウンド接続を開始していれば、それは調査に値します。
デバイス側のアセスメントでは、実際に検証できるものに集中すべきです。セキュアブートと署名済みファームウェアの検証は、デバイスが想定どおりのものを実行しているという強力な保証を提供します。ソフトウェア部品表（SBOM）は、ファームウェア内のサードパーティライブラリの脆弱性が実際に自社に影響するかどうかを判断するために必要なコンポーネントレベルのインベントリを提供します。さらに一歩進めて言えば、ネットワーク部品表（NetBOM）——存在するデバイス、その想定通信パターン、承認済みネットワーク依存関係の構造化されたインベントリ——も同様に重要だと主張したいところです。この基盤がなければ、未知のベースラインに対してセキュリティアサーションを行うことになります。
デバイスの周囲では、エンドポイント制御が利用できない場合に最小権限ネットワーキングが重要な役割を果たします。セグメンテーション、デフォルト拒否のファイアウォールルール、専用アウトオブバンドネットワークを通じた厳格にスコープされた管理アクセスを組み合わせることで、デバイスが完全に侵害されたとしても攻撃者が行える操作を制限できます。箱の中を見ることはできなくても、箱がアクセスできる先と、箱にアクセスできる者を制御することはできます。
ライフサイクルガバナンスは、多くの組織が課題を抱える領域です。ファシリティ予算は7〜10年の運用使用を想定しています。一方、セキュリティへの要求はそれよりもはるかに速いペースで変化します。このギャップは、完全に機能しているのに誰もアップデートしていないファームウェアを動かすデバイスが出てくるまで、静かに広がり続けます。その時点では、もはや技術的な問題ではなく、ビジネスリスクの意思決定となります。交換基準、脆弱性開示の監視、ベンダーのサポートコミットメントに結びついた調達基準は、すべて最初からアセスメントフレームワークに組み込む必要があります。
真の成熟度を測る試金石は、組織が侵害を迅速に検出し、影響を受けたデバイスをクリーンに隔離し、より大きな問題に発展するのを防げるかどうかです。
人間ユーザーのアイデンティティ管理でさえ困難ですが、物理セキュリティデバイスの場合、単一のキャンパスデプロイで数万台規模のエンドポイントのデバイスアイデンティティを扱うことになります。「ユーザー」がPTZカメラである場合、クレデンシャルの侵害はどのような形で現れるのでしょうか？そして、ライブインシデントの発生中に制限区域の天井に固定されたデバイスへの信頼を失効させるにはどうすればよいのでしょうか？
人間ユーザーのアイデンティティ管理でさえ困難ですが、大規模なデバイスアイデンティティはまったく異なる問題です。そして物理セキュリティ環境は、十分に注目されていない形でこれをさらに困難にします。
共有クレデンシャルや静的APIキーで管理されたキャンパスデプロイは、デバイスアイデンティティプログラムではありません。根拠のない自信を付与されたアセットリストにすぎません。共有クレデンシャルは、人間のアカウントのような侵害の仕方をしません。見慣れない場所からのログイン失敗もなく、不審な認証時刻もなく、セキュリティチームがユーザープロファイルと照合できる行動異常もありません。認証済みユーザーアカウントのように振る舞うPTZカメラに対して、検出ルールを書いている環境はほとんどありません。
物理セキュリティデバイスにおけるクレデンシャルの侵害はより巧妙な形で現れます。予期しない管理ソースから開始された設定変更。デバイスが確立した通信ベースラインの範囲外の宛先へのアウトバウンド接続。アセットインベントリに記録されているはずのバージョンとのファームウェアバージョンの不一致。指定コントローラー以外のIPアドレスからの管理プレーンへの認証試行。これらは奇異な指標ではありません。ただ、ほとんどの物理セキュリティ環境が積極的に監視していない指標というだけです。
スケールの問題がすべてを複雑にします。数千台のデバイスがクレデンシャルプールを共有している場合、単一の侵害は一台のデバイスにしか影響しません——いいえ、場合によってはすべてに影響する可能性があり、どのデバイスがアクセスされ何が行われたかを特定するクリーンな手段がないかもしれません。これを管理可能にするアーキテクチャは、自動登録と更新を備えたエンタープライズPKIから発行された個別デバイス証明書です。デバイス一台につき一枚の証明書。定義された有効期間。自動更新。更新に失敗したデバイス、または証明書が明示的に失効したデバイスは、認証済みアクセスを失います。
証明書のサポートはメーカーによって大きく異なります。WebインターフェースからのBasic的な証明書インポートから、SCEPエンロールメント、OCSPによる失効、API駆動の証明書ローテーションを備えた完全自動ライフサイクル管理まで様々です。これらは同じものではありません。調達担当者は、エンタープライズPKI統合が可能かどうかを前提としてしまう前に、デバイスが具体的にどの機能をサポートしているかを必ず確認すべきです。自動ローテーションのないアイデンティティは、最終的にはクレデンシャル管理の負債となります。証明書ライフサイクルの自動化は、物理セキュリティ調達においてますます重要な差別化要素になりつつあります。
失効のための基盤は、インシデントの最中ではなく、その前に構築しておく必要があります。隔離アクションを実行するための承認は事前に付与されている必要があります。ネットワークのフックは事前に設定されている必要があります。すべてのデバイスからスイッチポート、VLAN、管理コントローラーへのマッピングは、何か問題が発生する前にアセットインベントリに存在している必要があります。その準備が整っていれば、侵害されたデバイスの隔離は、ネットワークアクセス制御プラットフォームからのVLAN再割り当てかACL更新として、物理的な現場への派遣なしに1分以内にリモートで実行できます。証明書ベースのアイデンティティが導入されている環境では、失効によって認証済みセッションを迅速に閉じることができますが、その速度はリアルタイムOCSPチェックを使用しているか、CRLベースの失効を使用しているかによって異なります。
大規模なデバイスアイデンティティには、意図的なアーキテクチャ設計、検証済みのプロセス、そして明確なオーナーシップが必要です。その基盤を構築すべき時期は、インシデントによって緊急性が高まる前です。
翻訳元: https://www.helpnetsecurity.com/2026/06/02/chuck-davis-hikvision-zero-trust-physical-security/
