自治体・公共機関向けゼロトラストアクセスネットワークへの対応　～スイッチ担当エンジニアの視点から～

2026.04.16

近年求められている自治体・公共向けの高セキュリティ要件に対応したアクセスネットワーク検討の実績をもとに、ゼロトラスト前提のアーキテクチャが設計や機器構成にどのように反映されていったのか、スイッチ担当エンジニアの視点からご紹介します。

ライター：中村　喜之: キャンパス、キャリアネットワークおよびハイパーコンバージドインフラ製品の
提案および導入を支援する業務および製品の評価検証・拡販業務に従事。
現在はデータセンターネットワーク製品や製品検証の自動化に注力している。
2020年よりExtreme Networks Hero Engineerに認定

はじめに

近年の自治体・公共分野アクセスネットワークでは「誰が・どの端末で・どこから接続しているか」を厳密に扱うことが求められています。職員端末だけでなく、ゲストとなる他組織職員や一時利用者も含むため、今までの一律単純なエッジでの制御だけでは要件を反映しきれませんでした。そこで本記事では、昨今の実案件や検証で得た知見をもとに、新たにどのような認証アーキテクチャを検討・採用していったかを、その検討経緯を通じてご紹介したいと思います。

求められる要件

昨今の公共機関系ネットワークは高いセキュリティ要件が求められるだけでなく、利用者の拡大や権限の細分化により要件が細分化・複雑化する傾向があります。

利用者区分が多い（職員／他組織／ゲスト）
有線・無線が混在
端末管理状態（MDM・コンプライアンス）を考慮
利用形態に応じて到達先を動的に分離

これらの要件を扱うには「接続できた＝信頼」だけではなく、ネットワーク内外を問わず常に検証するゼロトラスト思考が有効です（継続的な都度評価／最小権限。姿勢やユーザー状態の変化時は CoA や再認証で動的に見直し）。

ネットワーク側では、以下のようなデバイス/ユーザー双方を確認する認証とそれに対応する認可システムによって、このような要件を達成することが可能になりました。

デバイス認証
初期接続で、証明書を用いた無線(WPA3-Enterprise)/有線802.1X（EAP‑TLS）により端末を識別し、端末状態（MDM/準拠）を確認します。
ユーザー認証と認可
続いて本人認証（MFA含む）を行い［EAP‑TEAP のチェイニング、またはユーザーサインイン検出に基づく RADIUS CoA により権限を更新］、属性（所属・役割・区分）に応じて VLAN/ACL に加えダイナミックACLやユーザーロール／タグを割り当て、アクセス範囲を確定します。

システムの構成例

ここまで述べた設計に基づくシステム構成は、特定ベンダーに依存しない考え方ですが、実際の案件では次のような製品で構成されています。

クラウド ID プロバイダ（IdP）
ユーザー認証・多要素認証を担う基盤として利用します。ユーザー属性やグループ情報をRADIUSサーバー側とAPIを通じて連携し、RADIUS 属性（ロール/タグ、dACL 等）へマッピングしてネットワーク側の制御に反映します。
RADIUS サーバー（オンプレミス／クラウド）
802.1X によるデバイス認証の中核です。既存のオンプレミス RADIUS を継続利用する構成と、クラウド型 RADIUS を採用する構成の双方があり、運用体制や認証・可用性要件に応じて選択されます。通信は可能な限り RadSec（RADIUS over TLS）で保護し、クラウド利用時は遅延や障害に備えたローカルプロキシ／キャッシュの有無を検討します。
MDM／端末管理基盤
証明書配布や端末コンプライアンス判定を担い、デバイス認証の前提条件を提供します。
ネットワーク機器（有線／無線）
スイッチやアクセスポイントは、PDP から受領した認証・認可結果に基づき、VLAN だけでなくロール/タグやダイナミックACLを適用する実行点（PEP）として機能します。姿勢やユーザー状態の変化時には CoA/再認証によりポリシーを動的に更新します。

これらの要素を組み合わせる際は、「どの基盤が何を判断し（IdP→NAC/RADIUS：PDP→スイッチ/AP：PEP）、どの結果をネットワーク制御に使うのか」を明確にし検討することが、設計のポイントとなってきます。

スイッチ担当の視点では

ゼロトラスト型アクセス制御では、認証や端末状態の判定は IdP、RADIUS、MDM などスイッチ外で行われます。したがってスイッチ担当は、その結果をどのポートで、どの条件で適用するかを設計段階で明確に検討する必要があります。特に以下のような事前整理が不可欠です。

ポート収容条件と例外端末の整理
単独 PC、IP 電話機配下の PC、プリンタなどでは前提となる認証方法や判定条件が異なります。特に 802.1X 非対応端末は初期設計で扱いを検討し、MAC認証等を用いる場合も最小権限のロールに限定し、通信先を明示的に制限する必要があります。
CoA／再認証時の動作
CoA による権限更新がポートへの属性再適用で済むのか、再認証や VLAN 変更に伴う port-bounce を要するのかを事前に確認しなければなりません。特に VLAN 変更時は、DHCP 再取得や既存セッション断を前提に評価が必要です。
障害時制御とログ
認証基盤障害時は原則 Fail-Closed とし、必要時のみ限定ロールを許容します。また、Session-Id、MAC、ユーザー ID、ポート、適用 VLAN／ロールを相関確認できるよう、ログを残すシステムや設計が必要になります。

NetOneの取り組み

弊社では、このような複雑性の高い高セキュアなアクセスネットワークにおける設計品質と再現性を高めるため、以下のような取り組みを行っています。

専用ラボで有線/無線・認証基盤・ID基盤を再現し、制御点や障害/例外時まで検証
段階的認証や信頼境界の定義をドキュメント化し、案件での設計品質を向上
社内教育を拡充し、ゼロトラストと段階的認証を共通言語として定着

このような基準となる取り組みをもとに、各案件の固有事情を反映した設計、検討を行い、実際のお客様向けシステムを構成しています。

まとめ

本稿では、自治体・公共案件のアクセスネットワークを題材に、スイッチ担当エンジニアの立場から、ゼロトラスト前提で採用する認証アーキテクチャの考え方を整理しました。
スイッチ側担当としては、IdP や RADIUS、MDM といった周辺基盤の判断結果をどの順序で受け取り、どの条件でポートや端末に適用するのかを明確にすることが重要でした。加えて、CoA／再認証時の挙動、例外端末の扱い、障害時の制御を含めて設計していくことが、構成の複雑化を抑えつつ、公共案件における持続可能な高セキュリティネットワークにつながると考えます。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。

お問い合わせはこちら