自治体ネットワーク強靭化の考察　「三層の対策」の次を考える（その２）

「にわかに盛り上がるゼロトラスト」後編

認証の強化と認可の動的管理（まとめ）

ゼロトラは実行ポイント（PEP）と決定ポイント（PDP）しかないシンプルな概念ですが、実際にこのセキュリティシステムを稼働させるのは簡単ではなく、実現させるのであれば、複数の機材の連携が必要になりそうです。

従来の内と外を分ける境界防御ファイアウオールモデルとは異なり、ゼロトラでは認証と認可の境界点を一点にまとめて「統合ID認証システム＆アプリケーションファイアウオール」として考えます。一元化されたディレクトリで、認証、及び認可の動的管理を実現する必要がありそうですし、通信をアプリケーション単位で制御できるファイアウオールが必要になりそうです。もちろん、各端末の状況を知らせるエージェントや状態の変更を伝えるセキュリティ検知システムも連携しなければならないように思います。さらに、通信を一点に集めるのは経路的に非効率な場合があるはずですから、PEPの分散は必須ではないかと思われます。

ゼロトラの導入を考える上で様々な疑問点が出てきます

・どのような認証要素やセキュリティ情報を確認するのか？　これは定期的に、もしくは変更時に確認しなおす必要があります。

・取得した認証要素やセキュリティ情報をリスク評価しなければなりません。事象とリスクの重み付けが必要となります。複合的な事象の場合は、足し算なのか？掛け算なのか？

・定期的に再確認する際の頻度は？　動的な認可の部分。ユーザビリティにもつながります。

・アクセス終了の判断は？　アクセスのタイムアウトやアプリケーションの停止などがありそうです。

・そもそもの個人やグループ単位、組織単位での情報資産アクセス権限との折り合いは？上位互換？

・どのような場合に、機密性の高い情報資産にアクセスできなくなるかを、職員に事前に通知しておく必要があります。

・許可・拒否を実行するポイント（PEP）は一点集中でよいのか？　IEEE802.1x認証のように適所にばらしたほうがトラフィック的に、特に有線LANでは効率的。

さまざまな要因が絡んでのリスク評価や、自動にお任せできるようにするために緻密計画が必要となりそうです。

ゼロトラストの成熟度

ただ現実は、システムの縦割り導入のため、認証システム（ID管理システム）がバラバラで、IDの一元化が難しくなっている状況なのかもしれません。

すぐさまゼロトラのすべてのしくみを導入するのは困難です。そのため、統合IDクラウドサービス（IDaaS）を提供するOKTA社で述べられている成熟度4ステップを紹介します。（OKTA社は、IDの統合管理をクラウドサービスする企業です。）ステージ０～ステージ３にわけられ、多くの自治体ではステージ０かステージ１ではないかと思います。わかりやすいように用語を差し替えてステージ2、ステージ３を説明します。

・成熟度ステージ0:　分散されたID システムごとにID管理している状態。個別のADやLDAPを複数管理している状態。

・成熟度ステージ1:　統合ID管理（IAM）や SSO、多要素認証、統一的ポリシーの適用を実現できている状態。

・成熟度ステージ 2:　接続状況に基づくアクセス認可

多くの認証要素（ユーザ、アプリケーション、端末、場所と接続方式など）に基づくアクセスポリシーを適用すること。（個別の認証要素に基づくセキュリティ対応）

・成熟度ステージ 3: 適応型のアクセス（常時監視と動的変更）

ゼロトラ導入の最終形は、アクセスの認証や認可にまでゼロトラストを拡張している状態。つまりさきほど認証認可したその通信は、今大丈夫？という考え方。究極のゼロです。つまり、認証は最初だけではなく、利用者の情報資産利用状態のすべてが継続的監視対象となります。OKTA社では、適応型のリスクベース評価（Adaptive Risk Management）によって想定される脅威を特定するしくみ。としています。そのリスク判定の結果、追加の認証を用意できるようにします。（インテリジェントなリスクベースのエンジンを追加する）

自治体ネットワークに適用した場合のゼロトラスト

• 庁外からのリモートアクセス

セキュリティクラウド（セキクラ）を通すかどうかは、接続方式によっても左右されます。LGWAN接続系の業務は、基本的に画面転送となりましょう。従来の閉域SIM方式や、IPA/J-LISなどがサービスしているLGWAN-ASP経由であればセキクラは経由しません。インターネット経由になるとセキクラ経由にするか、閉域SIMなどと同等のセキュリティを確保して直接インターネット接続系に引き込むことも検討できましょう。ただしインターネット接続系経由になると、系間の「特定通信の許可」が必要となります。

接続機材の盗難、OTPのようなセキュリティ装置の紛失、ID/パスワードの漏洩などさまざまなリスクを考えると、セロトラ要素が満載なのがリモートアクセス（テレワーク）です。要するに「そのアクセスは、なにも信用できない」となります。

また、図③の系間「特定通信の許可」は、本来はテレワークのセッション単位で個別に制御されるべき。いつも最小限の許可。というのがゼロトラなんです。

• 庁内からのアクセス

有線LANと無線LANでの接続となり、画面転送かリアルデータ通信のどちらかになると思います。「βモデル」のように、インターネット接続系の物理端末からアクセスする場合は、LGWAN系への画面転送の「特定通信の許可」する必要があります。（前述のように、この特定通信の許可もゼロトラスト配下で必要なときのみ個別に許可されるのが理想です）

例えば（あくまで想像のシナリオです）

• 窓口業務をするA職員は、マイナンバー系基幹業務が主となりますので、ネットワーク接続時に最大限の本人確認と端末の確認を行います。（ID\パスワード、OTP、顔認証、証明書、MAC・・・）　そのアプリ利用環境は終日終了せずタイムアウトもないので、状況変化もなく追加認証もありません。A職員はLGWAN業務も行うがその情報資産はマイナンバー側よりも低位となるので、追加認証は必要なく内部管理系業務（事務）が行えます。
• 内部管理系業務（事務）を主として行い、マイナンバー系基幹業務も時々進捗をのぞきに利用するB管理職は、LGWAN系業務を行うためにネットワーク接続時を多要素認証（ID/パスワード、顔認証）で行い、基幹業務をのぞきに行くときはさらに追加の認証（OTP、証明書、MAC・・・）を行う。基幹業務アプリ利用環境はすぐ終了したりタイムアウトしたりすれば、認可は終了し、再度基幹業務アプリを利用する場合は、追加の認証をやり直すことになる。

時代は、パスワードレスへ

魔の手はさらに一歩先へ。類推されにくく、定期的なパスワード変更をお願いしたり、と職員の運用負荷も高いわりには、職員の運用負荷も高いわりには、ハッキングツールなどの機械的な総当たり攻撃（パスワードクラック）やフィッシングによる「ID/パスワード漏洩事故」も起こりえるのが現状のようです。

そのため、アクセスを許可する職員は正しい人なのか？　利用端末は本当に正しい端末なのか？　パスワードへの依存を下げて個人と端末をできる限りの精度で確認できることが望ましいわけです。

FIDO2

ちなみに、生体認証などに使う認証用装置と、サーバーや端末とのやり取りを標準化した、FIDO2（Fast Identity Online2：ファイド2）という技術規格があります。

最後に裏口

最も重要な入り口は、運用業者のリモートメンテの接続口かもしれません。回線はできる限りの閉回線で、充分な認証セキュリティが必要なポイントです。

まとめ

【内】、【外】の境界はすでに崩壊し、職員も侵入者もウイルス（での端末の乗っ取り）なども、場所や利用する端末に関係なくネットワークアクセスを試みようとします。利用する端末も貸出端末、自宅PC、BYOD、タブレットやスマホなど多岐に及びます。このため、二要素認証やさまざまなセキュリティ要素を確認することでネットワークアクセス（認証）を厳とします。同時に確認したセキュリティ要素のリスクの変化にもとづき、情報資産へのアクセス制御（認可）をダイナミックに変更します。とても刹那的。これがゼロトラの世界です。成熟度を少しずつ高めながら、できるところからこういった概念を取り込んでいければよいかと思います。

縦が横になった絵（逆？）は2度目の登場です。庁内ネットワークに当てはめるとピッタリですね！

性善説のLGWAN接続系は・・・・・

本当は情報資産やアプリをクラウドに置いた場合も書くべきですが、今回は省略します。

最初に書きましたが、ゼロトラは既存のセキュリティを置き換えるものではありませんので、従来のファイアウオールや端末のセキュリティソフトなども併用する必要があります。メール添付ファイルやURLリンクへの誘導などのセキュリティ脅威は依然として残ったままです。

まずは、接続状況が見えないリモートアクセス時の確認として、貸出端末や個人宅PCにMDM（モバイルデバイス管理）やIT資産管理ソフトを入れてみるところから始めてみましょう。端末の利用状況の把握、盗難や紛失対策（遠隔ロック）、ユーザ/グループ単位での一括機能管理、統一的セキュリティポリシーの投入、利用アプリケーションの情報取得/配布/管理、コンテンツの管理/配布（MCM）、ライセンス管理などができます。

では、「Leave quietly」。

「自治体ネットワーク強靭化の考察 「三層の対策」の次を考える」（その３）に続く

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