対象となる環境
三層に分かれたネットワークと多様な端末を管理する環境
自治体では、取り扱う情報と業務に応じて、マイナンバー利用事務系、LGWAN接続系、インターネット接続系を分ける三層の対策が採られています。
各系統には、業務端末、共用端末、プリンター、電話、カメラなど、用途と更新時期が異なる機器が接続しています。
採用するネットワークモデルやクラウド利用方針によって、端末とシステムの配置、系統間で許可する通信、管理方法は異なります。
拠点ごとの接続状況を揃えて確認し、変更による住民サービスへの影響を抑えるには、どの系統のどの場所に端末が接続し、通信がどの経路を通るかを整理する必要があります。
- 本庁、支所、出先施設など、複数の拠点がある。
- マイナンバー利用事務系、LGWAN接続系、インターネット接続系で、接続できる端末と通信経路が異なる。
- 業務端末、共用機器、ネットワーク機器の更新時期が異なる。
- 拠点ごとに配線、接続機器、保守体制が異なる。
- 情報システム担当者が複数拠点を管理する自治体と、兼任担当者や委託先が少数の拠点を管理する自治体がある。
- 住民サービスへの影響から、一斉変更や長時間の停止を避けたい。
確認したい通信
拠点ごとに分散する端末と運用情報
現在の接続状況を揃えて確認しにくい
端末の更新、移設、臨時接続が重なると、資産台帳や構成図と実際の接続状況が一致しないことがあります。
問題が起きたときに確認対象を絞るには、現在接続している端末と通信経路を把握できる状態が必要です。
拠点ごとに確認方法が異なる
管理機器や保守体制が拠点ごとに異なると、端末、イベント、設定の確認に時間がかかります。
管理対象と確認項目を揃え、拠点間で同じ手順を使える状態にする必要があります。
必要以上に広い通信経路が残る
三層の対策による系統間の分離と、同じ系統にある端末間の通信制御は、担当する範囲が異なります。
同じ系統内で業務に必要な通信と不要な通信が分かれていないと、一台の端末で問題が起きたときに、ほかの端末やシステムへ到達できる経路が残ります。
一方で、必要な通信を確認せずに一律の制御を適用すると、窓口や庁内業務へ影響する可能性があります。
全拠点を同時に変更しにくい
構成の異なる拠点を同時に変更すると、異常が起きた場合の影響範囲と原因を絞りにくくなります。
代表拠点で通信と運用を確認し、標準構成と例外を整理してから対象範囲を広げる進め方が必要です。
解決方針
拠点ごとの接続状況を把握し、共通の運用へつなげる
端末に近い場所で通信を確認する
三層の対策による系統間の分離を維持し、業務端末や共用機器が接続する対象系統のアクセスエッジにTiFRONTを配置します。
対象となる通信がTiFRONTを通過する構成とすることで、端末へのソフトウェア追加だけに依存せず、ネットワーク側から接続端末と通信を確認できる範囲を補完します。
TiFRONTが三つの系統を接続したり、既存の境界対策を置き換えたりすることはありません。
系統内の通信範囲を分ける
通信範囲の制御を行う場合は、同じ系統にある部署、端末、業務システムの間で必要な通信を整理し、TiFRONTを通過する通信へポリシーを適用します。
既存の分離構成と接続ルールを維持したうえで、代表構成を使って必要な通信と例外を確認します。
検知モードで業務への影響を確認する
通信の遮断が窓口業務や住民サービスへ影響する場合は、TiMatrixの対応項目を検知モードで運用し、通信を遮断せずにイベントとアラートの内容を確認できます。
TiMatrixで選択できる動作は項目ごとに異なるため、対象項目で検知モードを利用できることを確認します。
脅威の兆候を確認対象へ結び付ける
vCATは、ネットワーク内部に用意した仮想的なトラップへの接続を手掛かりに、確認すべきアクセス元端末と事象を把握するために使用します。
利用できる場所と検知後の通信制御は、採用するSwitch、TiControllerとの接続条件、運用方法に応じて確認します。
複数拠点の運用をまとめる
TiControllerを使用する構成では、管理対象となるTiFRONT、端末、イベント、ポリシーを共通の管理体系で扱います。
管理できる具体的な項目、台数、拠点数、ログ、権限は採用構成ごとに確認します。
配置する場所
本庁と出先拠点の端末が接続するアクセスエッジ
TiFRONT Intelligent Defense Switchは、業務端末や共用機器などが有線で接続するアクセスエッジへ配置します。
対象となる通信がSwitchを通過するとき、対応する機能による可視化、検知、通信制御の対象になります。
無線接続ではSecurity APを検討できますが、有線側のSwitchとは対応機能が異なります。
下位スイッチ内で完結する通信や、TiFRONTを通らない別経路の通信は、同じ範囲で確認または制御できません。
TiControllerを利用する場合は、各系統の分離方針と接続ルールに従って管理通信の経路を設計します。
三層の分離を保ったまま、系統内の通信を確認・制御

使用する製品と機能
自治体ネットワークで使用するTiFRONT
※ 利用できる製品と機能は、モデル、PLOS、ライセンス、TiControllerとの構成によって異なります。
導入後に変わること
拠点ごとの確認と共通運用をつなげる
| 導入前の状態 | 導入後に確認・実行できること | 成立条件 |
|---|---|---|
| 接続端末やイベントの確認方法が拠点ごとに分かれている | 管理対象となる機器、端末、イベントを共通の管理体系で確認する | TiControllerの管理対象、接続条件、管理項目を確認する |
| 端末の接続状況と資産情報を照合しにくい | TiFRONTの管理対象に接続する端末情報を確認材料にする | 確認できる端末情報と資産管理側の照合方法を決める |
| 三層に分離した系統内で、端末間の通信範囲を確認しにくい | 対象系統のアクセスエッジで接続端末と通過通信を確認材料にする | 対象端末の通信がTiFRONTを通過する構成とする |
| 通信を遮断した場合の住民サービスへの影響が分からない | TiMatrixの検知モードで通信を遮断せず、イベントとアラートを確認する | 対象項目で検知モードを利用できることを確認する |
| 庁内で確認すべき兆候を見つけにくい | vTrapへの接続をイベントとして確認し、アクセス元端末の調査につなげる | vCATを利用できる構成とTiControllerとの接続条件を確認する |
| 必要な通信と不要な通信が分かれていない | 確認済みの条件に応じて、Switchを通過する通信へポリシーを適用する | 業務に必要な通信、例外、利用できる機能を事前に確認する |
導入の進め方
代表ラインで確認してから対象を広げる
- 本庁、支所、出先施設の端末と接続機器を、マイナンバー利用事務系、LGWAN接続系、インターネット接続系に分けて整理する。
- 採用しているネットワークモデル、クラウド利用方針、系統間で許可する通信を確認する。
- 拠点内、拠点間、上位ネットワーク、保守接続、TiControllerへの管理通信の経路を確認する。
- 対象系統で、端末の通信が通過するアクセスエッジとTiFRONTの配置候補を決める。
- 代表拠点では、TiMatrixの検知モードで通信を遮断せずにイベントとアラートを確認する。
- 業務に必要な通信、例外、制御時の影響、切り戻し方法を確認する。
- 標準構成、例外構成、イベント確認、ポリシー変更、切り戻しの手順を整える。
- 大規模または多拠点の自治体は代表拠点から段階的に展開し、小規模自治体は少数の接続点と委託先を含む役割分担を確認する。
適用前に確認すること
TiFRONTが担当する範囲と既存ネットワークとの関係
- 対象端末の通信がTiFRONTを通過するか。
- 下位スイッチ内または別経路で完結する通信があるか。
- 採用しているネットワークモデルと、端末や業務システムを配置している系統はどれか。
- 既存の三層の分離構成、接続ルール、境界対策を維持できるか。
- TiControllerへの管理通信が、各系統の分離方針と接続ルールを満たすか。
- 拠点間で共通化する構成と、個別に扱う例外を分けられるか。
- 必要なポート数、PoE、性能、電源、冗長化条件を満たすモデルはどれか。
- 対象製品で利用する機能と、TiControllerとの接続条件は何か。
- 検証方法、変更可能な時間帯、切り戻し手順を定義できるか。
- UTM、ファイアウォール、EDR、バックアップ、端末認証など、TiFRONT以外の対策が担う領域はどこか。

