SOCは社員を監視している。ベンダーは監視していない。

サードパーティが関与した情報漏洩は、わずか1年で15%から30%へと倍増しました。これはVerizon 2025 Data Breach Investigations Reportが記録した中で最大の単年変化です。サプライチェーン侵害の平均コストは491万ドル、検知と封じ込めまでに267日を要し、IBMが追跡するすべての侵害経路の中で最も長いライフサイクルです。フィリピンでは、過去1年間にサードパーティ経由で被害を受けた組織の100%が、自社の境界への直接攻撃ではなく、ベンダーアカウント経由で侵害されました。

製造業は今や世界で最も標的にされている業界であり、アジア太平洋地域のサイバー攻撃の40%を占めています。私たちがタイで仕事をしている製造業の多くはSIEMを持ち、SOCを持ち、自社の社員とエンドポイントに対しては妥当な検知カバレッジを持っています。しかし、設備ベンダーのVPNアカウントが、これまで接続したことのない国から午前2時にログインした際に発報するルールを持つ企業はほとんどありません。

これは調達の問題ではありません。検知の問題です。SOCツールは社員を監視するために作られたのであって、組織が社員以外の全員に発行しているアカウントを監視するためには作られていないからです。

これが見落としではなく、構造的な死角である理由

典型的なSOCのベースラインは社員の行動を軸に構築されています。このユーザーは通常バンコクから8時〜19時にログインし、この3つのシステムにアクセスし、財務サーバーには一切触れない——このベースラインからの逸脱がアラートを生成します。

ベンダーや委託先のアカウントはこのモデルに当てはまりません。理由は構造的に3つあります。

意図的に不規則である。 ベンダーのサポートエンジニアは、四半期に一度、ファームウェア更新のためにログインするかもしれません。自分のタイムゾーンに都合の良い時間に、たまたま使っているネットワークから。逸脱すべき安定したベースラインが存在しないため、行動検知の多くはこれらのアカウントを無視するか、ノイズを大量に生成してアナリストがアラートを無視するようになります。

アイデンティティ層で見えない。 ほとんどの組織はベンダーアカウントを社員アカウントと同じ方法でプロビジョニングします——同じADグループ、同じ命名規則、時にはベンダー側の複数スタッフで同じログインを共有していることもあります。「これは時間・スコープが限定されたサードパーティのアクセスである」と「これは自社のエンジニアである」を区別する情報が、アイデンティティシステムのどこにもありません。

デプロビジョニングの責任者が誰もいない。 Bitsightの2026年の調査では、サードパーティとの関係を継続的に監視している組織はわずか3分の1に過ぎず、大半は数ヶ月単位の可視性の空白を残す定期評価サイクルに頼っています。ベンダーとの契約が終了し、請求書が止まっても、18ヶ月前に発行されたVPN認証情報は、それを閉じる責任を持つチームがいないために、静かに動き続けます。

経済安全保障推進法が特定重要物資・重要インフラ事業者に求めるサプライチェーンのセキュリティ監視義務、そしてJ-SOXの内部統制監査証跡の観点から見ても、これは技術的なギャップであると同時にコンプライアンス上のギャップです。NISCの重要インフラガイドラインは、委託先・ベンダーを含むサプライチェーン全体の可視性を明示的に求めています。監査人が「このベンダーアカウントの最終レビューはいつか」と尋ねたとき、答えられないこと自体がリスクです。

これは以前取り上げたアイデンティティ債務の問題と同根です——一元化された所有者を持たないアカウントは、誰も削除を覚えていないアカウントになる——ただしベンダーアカウントにはさらなるリスクが上乗せされます。組織側は、その認証情報がベンダー側でどのように保管・使用されているかをほとんど制御できません。

2つの攻撃面、同じ根本原因

ITベンダー：MSPとSaaS統合の経路

マネージドサービスプロバイダー、請求プラットフォーム、SaaS統合は、コアシステムへの広範なアクセス権を持つ常設の認証情報やAPIキーを保持していることが多くあります。これらのプロバイダーの一つが侵害されると、攻撃者は正当で既に信頼されたアクセス権を引き継ぎます——フィッシングも不要、エクスプロイトも不要、侵入に見えるアラートすら発生しません。技術的にはまだ侵入ではないからです。

OTベンダー：設備保守の経路

この点については工場フロアのセキュリティに関する記事でより詳しく扱いましたが、ここでも改めて述べる価値があります。産業分野のリモートアクセスリスクの多くは、設備ベンダーが数年前に設定し、それ以降誰もローテーションしていない認証情報を使って、OTセグメントに直接置かれたVPNコンセントレーターに由来します。この経路はIT/OT境界を完全に迂回します。なぜならそれは正当な保守チャネルとして構築されたものであり、攻撃経路として使われるまでは、そうとは認識されないからです。

両方の攻撃面は同じ根本的な失敗を共有しています。そのアクセスは本物であり、認可されており、独立したリスクカテゴリーとして一切追跡されていない。

flowchart TD
  A["ベンダー・委託先アカウント"] --> B["社員アカウントと同様にプロビジョニング"]
  A --> C["時間の区切りがないスコープ"]
  A --> D["専用のリスクティアがない"]
  B --> E["通常の認証ログに紛れ込む"]
  C --> F["契約終了後もアクセスが継続"]
  D --> G["異なる扱いをする相関ルールがない"]
  E --> H["SOCは有効なログインと見なし、リスクイベントと見なさない"]
  F --> H
  G --> H
  H --> I["267日後、あるいはそれ以降も検知されないまま"]

このギャップを実際に閉じる方法

ベンダーアクセスの監視は、社員アクセスの監視を大きくしたものではありません。サードパーティのアイデンティティを、最初から最後まで独立したカテゴリーとして扱う必要があります。

1. プロビジョニング時点でベンダーのアイデンティティにタグを付ける。インシデント後ではなく。 すべてのベンダー、委託先、統合アカウントには、識別可能な属性が必要です——ディレクトリ内の専用OU、命名規則、あるいはサードパーティ専用のSSOグループ。これがなければ、どの下流の検知ルールもベンダーアクセスを別扱いできません。そもそもSIEMにどのアカウントがベンダーかを伝える手段がないからです。

2. 一般的な異常ベースラインではなく、ベンダーのリスクティアを軸に相関ルールを構築する。 年に2回しかログインしないアカウントの「正常」パターンを学習しようとするのではなく、明示的なルールを書きます：事前承認された保守ウィンドウ外でのベンダーアカウントのアクセスは、デフォルトで高重要度とする。文書化されたスコープ外のシステムへのベンダーアカウントのアクセスは、デフォルトで高重要度とする。

3. アクセスを発生源で時間制限する。 最も効果的な対策は検知的なものではなく、アーキテクチャ的なものです：ベンダーのVPNおよびリモートサポート認証情報は、アクティブな保守ウィンドウのために明示的に延長されない限り、自動的に失効すべきです。

4. ベンダータグ付きアラートを別のプレイブックに通す。 アカウントがタグ付けされれば、SOARレイヤーは異なるエスカレーション経路を適用できます——ベンダーアカウントの異常は、デフォルトで人間にページするべきで、自動クローズすべきではありません。件数が少なく、潜在的な被害範囲が大きいからです。これは、アラート疲労全般に適用される自動クローズの前にトリアージアシストを行う規律と同じものです。誤検知よりも見逃しの方がはるかに高くつくカテゴリーに適用しているだけです。

5. デプロビジョニングを希望ではなく、定期レビューにする。 すべてのベンダーアカウントを、作成時点で契約終了日に紐付け、対応する有効な契約のないベンダー認証情報には自動90日レビューを設定します。

flowchart TD
  A["ベンダーのオンボーディング"] --> B["アイデンティティにタグ付け：ベンダーOU + スコープ + 有効期限"]
  B --> C["アクセスウィンドウを定義"]
  C --> D["相関ルール：ウィンドウ外のアクセス = 高重要度"]
  D --> E["SOAR：ベンダーアラートはアナリストへ、自動クローズなし"]
  E --> F["契約終了"]
  F --> G["デプロビジョニングの定期レビュー"]
  G --> H["発生源で認証情報を無効化"]

simpliSOCによるベンダーアクセスの取り扱い

simpliSOCは検知にWazuh、ケース管理にDFIR-IRIS、自動化にShuffleを使用しています——他のSOC展開と同じスタックです。ベンダーアクセスをカバーするための拡張に新しいツールは不要で、異なるルールセットを追加するだけです。

ベンダー・委託先アカウントはアイデンティティ層（AD OUまたはSSOグループ）でタグ付けされ、Wazuhの相関ルールが一般的な社員ベースラインとは異なる重要度ベースラインを適用できるようになります
アクセスウィンドウのルールはベンダー契約ごとに明示的に記述され、合意された保守ウィンドウ外の認証イベントはIPレピュテーションに関係なく高重要度としてフラグ付けされます
Shuffleのプレイブックは、ベンダータグ付きアラートを契約とスコープのコンテキストを事前に付与した状態でアナリストへ直接ルーティングします
ベンダーアカウントに関わるIRISケースは別途タグ付けされ、四半期レビューで一般的なケースログを掘り返すことなくベンダー関連のインシデントをすべて抽出できます

これは、契約締結前に調達部門やGRCチームがすでに行っているべきベンダーリスク評価に代わるものではありません。その評価と、ベンダーが実際にライブアクセスを持ったときにSOCが実際に見ているものとの間のギャップを埋めるものです——Verizonのデータによれば、今や侵害の3割近くがそこから始まっています。

現在、御社のSOCがベンダーアクセスをどれだけ可視化できているか、セカンドオピニオンが必要ですか？
simpliSOCチームに相談する → hello@simplico.net

よくある質問

ベンダーリスクは調達の問題であって、SOCの問題ではないのでは？
両方です。契約締結前のベンダーリスク評価（財務健全性、セキュリティ態勢、認証取得状況）は調達・GRC部門の機能です。契約締結後に何が起きるか——そのベンダーの実際のアクセスが監視され、スコープが定められ、予定通り失効するかどうか——はSOCの機能です。

API統合を伴うSaaSツールを多く使っていますが、オンサイトのベンダーがいなくても当てはまりますか？
はい、むしろより当てはまります。広いスコープを持つAPIキーは、機能的にはベンダーVPNアカウントと同じリスクです——通常のユーザー行動ベースラインに当てはまらない、常設の認可されたアクセスです。

現在どれだけのベンダーアクセスがあるかをどう把握すればよいですか？
ツール購入からではなく監査から始めてください。現職の社員に紐付いていないすべてのAD/SSOアカウント、有効なすべてのAPIキー、すべてのVPN認証情報を抽出し、それぞれを有効な契約と照合します。

OTベンダーアクセスはITベンダーアクセスと扱いが異なりますか？
原則は同一です——タグ付け、スコープ設定、時間制限、逸脱時のアラート——ただし、侵害された設備ベンダーの認証情報が生産システムに直接到達しうるため、OTベンダーアクセスはより高いリスクを伴います。OTセグメント自体への検知の拡張方法については、工場フロアセキュリティの記事をご覧ください。

これによって正当なベンダーサポート依頼が遅くなりませんか？
その場で申請するのではなく、アクセスウィンドウが事前に承認されていれば遅くなりません。時間制限付きベンダーアクセスを導入している組織の多くは、保守ウィンドウをサポート契約の一部として事前にスケジュールしています。

当社は小規模です。フルスケールのSOCを持つ前にこれに取り組む価値はありますか？
あります。むしろ早期に正しく行う方が簡単です。オンボーディング時点でベンダーのアイデンティティにタグを付け、有効期限を設定するコストはほぼゼロです。何年も蓄積した、タグ付けされていないベンダーアカウントに後から手を加える方がはるかに困難です。

関連サービス