対象となる環境
多数の拠点と管理組織が関係するネットワーク
組織の規模が大きくなると、同じ会社や団体の中でも、拠点の役割、接続する端末、ネットワーク構成、保守契約が揃わない場合があります。
中央の情報システム部門だけでなく、事業部門、拠点担当者、グループ会社、保守事業者が運用へ関わるため、技術構成とともに判断権限と連絡手順を定める必要があります。
- 本社、支社、営業所、工場、倉庫、研究施設など、多数かつ種類の異なる拠点がある。
- PC、プリンター、電話、カメラ、IoT機器、OT機器、業務専用端末が接続している。
- 有線と無線の接続環境があり、拠点や部門ごとに構成が異なる。
- 中央の情報システム部門、拠点担当者、グループ会社、保守事業者が運用へ関わる。
- ネットワークの階層、セグメント、拠点間通信、認証、境界対策が複数の方式で構成されている。
- 全拠点を同時に変更できず、展開期間中は新旧の構成が併存する。
確認したい通信
分散する接続情報と、拠点ごとに増える例外
接続端末とイベントの確認先が分散する
拠点ごとに管理機器や保守事業者が異なると、端末、イベント、設定を確認する方法が分かれます。
問題が起きたときに確認対象を絞るには、どの拠点のどの接続場所に端末があり、通信がどの経路を通るかを共通の基準で確認できる状態が必要です。
同じ対策を適用できない端末がある
PCへ導入する端末対策だけでは、IoT機器、OT機器、カメラ、電話、業務専用端末を同じ方法で管理できない場合があります。
端末側で揃えられない範囲は、対象端末の通信が通るネットワーク側で補完する必要があります。
通信可能な範囲が業務上の必要範囲より広い
組織変更、システム追加、拠点統合が続くと、現在は使われていない通信経路や、必要以上に広い到達範囲が残る場合があります。
一方で、必要な通信を確認せずに一律の制御を適用すると、部門システム、拠点間通信、保守接続へ影響する可能性があります。
標準構成だけでは扱えない拠点がある
標準構成を定めても、工場、研究施設、物流拠点、買収した組織などでは、端末と通信の条件が異なる場合があります。
標準から外れる構成を単なる未対応として残さず、例外の理由、対象範囲、承認者、見直し条件を管理する必要があります。
運用上の判断が複数の組織へまたがる
イベントの確認、通信制御の判断、設定変更、障害対応を行う担当が異なると、問題発生時の連絡と判断に時間がかかります。
中央と拠点の役割、保守事業者へ依頼する条件、緊急時の変更手順を事前に定めます。
全社展開の途中で新旧構成が併存する
多数の拠点を段階的に変更する期間は、TiFRONTを導入した範囲と未導入の範囲が併存します。
展開状況と対象範囲を明示し、導入済みの拠点だけを全社の確認結果として扱わない運用が必要です。
解決方針
拠点を分類し、標準構成と例外を管理しながら展開する
拠点を役割と構成で分類する
本社、標準的な支社、小規模な営業所、工場、倉庫などを、接続端末、通信経路、停止条件、運用体制が近い単位に分類します。
各分類から代表拠点を選び、TiFRONTを配置する場所、対象となる通信、対象外となる通信を確認します。
アクセスエッジで接続端末と通信を確認する
有線端末が接続するアクセスエッジにはIntelligent Defense Switch、無線端末が接続する場所にはSecurity APを検討します。
対象端末の通信がTiFRONTを通過する構成にし、接続端末とイベントの情報を構成図、資産台帳、追加調査の判断材料にします。
TiFRONTだけで全社の資産、脆弱性、端末の用途、管理主体、必要通信を自動的に特定するものではありません。
検知結果を拠点分類ごとに評価する
通信の遮断が業務へ与える影響を判断しにくい場合は、TiMatrixの対応項目を検知モードで運用し、検知による通信遮断を行わずにイベントとアラートを確認できます。
代表拠点で確認した結果をほかの拠点へ無条件に適用せず、同じ端末、通信、業務条件が成り立つかを確認します。
必要な通信と例外を分けて管理する
部門、端末、業務システムの間で必要な通信を整理し、Intelligent Defense Switchを通過する通信へポリシーを適用します。
標準構成へ適用する条件と、拠点固有の例外を分け、例外の理由、承認者、見直し時期を運用手順として管理します。
中央と拠点で確認方法を揃える
TiControllerを使用する構成では、管理対象となるTiFRONT、端末、イベント、ポリシーを共通の管理体系で扱います。
管理できる具体的な項目、台数、拠点数、ログ、権限は採用構成ごとに確認し、中央担当者、拠点担当者、保守事業者の役割へ対応させます。
展開状況と対象範囲を記録する
拠点分類ごとに検証、展開、運用移行の完了条件を定めます。
導入済み、検証中、未導入の範囲を区別し、TiFRONTで確認できる情報の対象範囲を明示します。
配置する場所
各拠点と部門の端末が接続するアクセスエッジ
Intelligent Defense Switchは、PC、プリンター、電話、カメラ、IoT機器、OT機器、業務専用端末などが有線で接続するアクセスエッジへ配置します。
Security APは、PC、スマートフォン、タブレット、無線対応機器などが無線で接続する場所へ配置します。
対象となる通信が各機器を通過するとき、対応する機能による可視化、検知、通信制御の対象になります。
下位スイッチ内で完結する通信や、TiFRONTを通らない別経路の通信は、同じ範囲で確認または制御できません。
TiControllerを使用する場合は、通常のデータ通信とは別に、各拠点からの管理通信の経路と接続条件を設計します。
構成状態を分けて、多拠点を一元管理する

使用する製品と機能
大規模、多拠点組織で使用するTiFRONT
※ 利用できる製品と機能は、モデル、PLOS、ライセンス、TiControllerとの構成によって異なります。
導入後に変わること
分散した情報と運用判断を、対象範囲ごとに整理する
| 導入前の状態 | 導入後に確認・実行できること | 成立条件 |
|---|---|---|
| 接続端末とイベントの確認先が拠点ごとに分かれている | 管理対象となる拠点の機器、端末、イベントを共通の管理体系で扱える | TiControllerの管理対象、接続条件、管理項目を確認すること |
| 端末へ同じセキュリティソフトを導入できない | 通過通信をネットワーク側の確認対象にできる | 対象通信がTiFRONTを通過すること |
| 通信を遮断した場合の影響が分からない | TiMatrixの対応項目を検知モードで運用し、イベントとアラートを確認できる | 対象項目で検知モードを利用できること |
| 部門や拠点に必要以上に広い通信経路が残っている | 確認済みの条件に応じて通過通信へポリシーを適用できる | 必要通信、例外、対応モデル、ライセンスを確認すること |
| 拠点ごとの構成差を把握しにくい | 標準構成、例外構成、未導入範囲を分けて展開状況を管理できる | 拠点分類、完了条件、例外の管理手順を定めること |
| 運用判断が複数組織にまたがる | 中央、拠点、保守事業者の役割に沿って確認と変更の手順を揃えられる | 権限、承認、連絡、緊急変更の手順を定めること |
導入の進め方
代表ラインで確認してから対象を広げる
- 拠点、部門、接続端末、通信経路、管理主体、停止条件を整理する。
- 拠点を構成と業務条件が近い単位に分類し、各分類の代表拠点を選ぶ。
- 代表拠点でTiFRONTを配置する候補と、対象にならない通信を確認する。
- 使用する製品、機能、モデル、ライセンス、TiControllerの構成を選定する。
- TiMatrixの検知モードなどを利用してイベントを確認し、必要通信、例外、業務への影響を整理する。
- 標準構成、例外構成、ポリシー、切り戻し条件、検証完了条件を決める。
- 中央担当者、拠点担当者、保守事業者の権限、承認、連絡、障害対応の手順を整える。
- 拠点分類ごとに展開し、導入済み、検証中、未導入の範囲を記録する。
- 運用開始後も例外と構成変更を確認し、標準構成の見直しへ反映する。
適用前に確認すること
技術構成、管理容量、運用権限を採用構成へ合わせる
- 拠点分類、代表拠点、標準構成、例外構成を確認する。
- TiFRONTを配置する場所、対象端末、対象となる通信経路を確認する。
- TiFRONTを通過しない通信、既存スイッチ内で完結する通信、未導入拠点を確認する。
- 有線と無線で使用する製品と対応機能を分ける。
- 対応モデル、PLOS、ライセンス、TiControllerとの接続条件を確認する。
- TiControllerで管理する機器、端末、イベント、ポリシー、台数、拠点数、ログ、権限を確認する。
- 拠点間通信、業務システム、クラウド、保守接続に必要な通信と例外を確認する。
- 中央、拠点、グループ会社、保守事業者の権限と責任範囲を決める。
- 検証、変更、障害対応、緊急変更、切り戻し、運用移行の条件を決める。
- UTM、ファイアウォール、EDR、バックアップ、認証など、既存対策が担当する範囲を維持する。

