三層分離見直しの見直しに向けた課題整理
三層分離の見直しに向けて今回は、地方自治体のセキュリティ対策の方向性について、論じていこうと思います。自治体のセキュリティについて述べていくにあたり、避けられないのは「三層分離」です。「インターネット分離」「WEB 分離」「強靭性向上モデル」などといった多くの呼び名で知られていますが、今回は「三層分離」で統一したいと思います。
三層分離の経緯
この「三層分離」の生い立ちから振り返っていきます。政府機関の大規模情報漏えいにより、地方自治体にあるマイナンバーを絶対に守らないといけないということで、非常に早いスピード感で全自治体がセキュリティ対策を講じるために「三層分離」の方針が策定されました。
元々、地方自治体では、住民サービス系のネットワークセグメントである基幹系セグメントと、事務作業中心のインターネットに接続する情報系セグメントに分割されてセキュリティを保護していました。そのため、自治体によってはデスクの上に、2 つの端末が並んで業務によって使い分けている姿があったと記憶しています。
しかしながら、先のセキュリティ事故により、情報系セグメントを更に分割して、以下の 3 つのセグメントを設定することになりました。
・番号利用事務系
・LGWAN 系
・インターネット接続系
先に書きましたとおり、既にデスク上に 2 つの端末が並んでいるケースもあり、3 端末目を置いて 3 つのセグメントの業務によって使い分けることも可能な施策だったのですが、多くの自治体が PC の画面転送をする VDI（仮想デスクトップ）をインターネットセグメントに配置しました。LGWAN 系の物理端末で、インターネット接続系のセグメントの PC の画面をセキュアに操作して、インターネットが必要な業務について脅威を避けながら実施する方式を採っていました。
もちろん、3 セグメントに分けることが明示されていたので、インターネット接続系を物理端末にして、LGWAN セグメント側に仮想デスクトップを配置していることでも成立するため、このような方法を選択していた自治体もありました。いずれにせよ、短時間でこのようなことに取り組む必要があったシチュエーションにおいては、賛否両論あったものの、すべきことが明確だった施策だったと思っています。
三層分離の見直しの背景
時代は変わり、その当時導入した仮想デスクトップ環境もリプレースの時期になってきています。まさに世の中の状況や、テクノロジーの進化により、当時実施した施策に見直しをしても良いのではないかということになりました。具体的には以下のようなことがあると考えています。
自治体を中心とした状況
・用意する仮想デスクトップ数は自治体職員の半分以下がほとんどでしたが、常にそこまで必要ないケースもあった。初めての取り組みだったので、利用数に余裕を持った調達だったケースもあった。
・インターネット側では SaaS を始めとしたクラウド利用が進みました。特にテレワークにおける、音声及びビデオ会議が多く活用されるような事態が、当時は想定されていなかったため、ユーザーエクスペリエンスが保てないことが増えてきた。
・インターネット利用時に仮想デスクトップを経由するので、利便性が低い（と言われることもある）。これは賛成・反対の両方の意見があると思います。慣れてしまったという説と、元々そんなに不便だと思っていない説は両方聞くケースがあります。
テクノロジーの進化
・クラウド技術が進化してきたため、都度利用や柔軟なスケーリングができるようになった。
・攻撃方法が高度化したと同時に、端末側に掛けるセキュリティが非常に進化した（後述します）
三層分離の見直し内容
これらを踏まえて、総務省が三層分離の見直しのガイドラインを公開しました。
具体的には前回のインターネット接続系を仮想デスクトップとする構成を α パターンとして、反対にインターネット接続系に物理端末を配置して LGWAN 系セグメントに仮想デスクトップを配置する β,β'のパターンを新たに追加しました。どのパターンを選択しても構わないというアナウンスがされたということになります。
β パターンにおいては、先に述べたクラウド利用を考えた際の利便性を主な目的として目指すために設定されています。そのため、物理端末のセキュリティを強化しようということで、EDR を必須として検討を進めている自治体がほとんどだと思います。
例えば、北海道庁様のような既にβパターン導入を決められている自治体もあります。
本日現在、どちらのパターンの導入も進んでいますが、α パターンは前回踏襲ということもあり、進め方や構成が非常に明確なのですが、β パターンは今回が初めてということもあるのと、選定するにあたっては多くのことを勉強して選定しなければならない状態です。よく使われるような設計みたいなものも浸透していない中で、各自治体が各自治体の判断で検討が進めている状態かと思います。
三層分離の見直しに向けた課題整理
こちらでは、以下の流れで今回の三層分離導入にあたり課題となりそうなところをまとめていきたいと思います。
1. β パターンにおける課題
2. α パターンにおける課題
3. 両方のパターンにおいて、関連する別の課題
エンドポイントセキュリティ
まず、β パターンについての課題感はどんなところにあるのでしょうか？以下の 2 点が、検討にあたり顕在化している箇所と考えています。
・EDR の定義が不明確で、どのソリューションも EDR と位置づけが可能で、低レベルなものを選択されてしまう
・運用をどこまでやるべきかの定義がない。かつ、自治体職員のスキルセットに依存しており、最終的に達成されるセキュリティの質に違いが出てしまう
EDRの定義
最初は、EDR の定義について整理します。EDR とはそもそも Endpoint Detection and Response の略称ですが、厳密に言えばそれ以上でもそれ以下でもありません。そのため、解釈次第でどんなソリューションだとしても EDR だと言うことが出来てしまう可能性があるということです。本来 EDR に求められる機能が達成されず、EDR を導入したという事実だけを求めてしまった場合には、価格的なメリットだけが強調され、本来のセキュリティ保護が達成されないことが有り得る危険な状態だと思います。
今回インターネット接続系の端末セキュリティを強化したい背景には、高度化された攻撃があるわけです。では、最近の攻撃にはどのような傾向があるのでしょうか。それは、「パターンマッチングではない、既存のツールを使った攻撃」です。従来のアンチウィルスソフトウェアは、攻撃するファイルが特定のパターンにマッチしていたら検知して排除するという仕組みでした。そのため、そういったファイルは、攻撃者側しか使わないのです。しかしながら、現在はユーザー自身も利用する PowerShell などのツールを使ってくるため、そのツール自体を消すことができないので、パターンマッチングでも保護することができないのです。
EDR は、PC 上での動作をログとして取得しておき、セキュリティインシデント発生時に、何が契機で、何を動かして、どのように情報漏えいが起きたかについて後から追えるようにしておくという目的のために導入されるものです。そのため、これからお話しする 2 点について明確に定義する必要があるかと思います。
取得するログの定義の明確化
PC に関連する変更ログをアプリケーションだけでなく、OS やシステム全体にまで広げて取得し、調査が必要な際にはそれらを総合的に加味して検知に活用する。一部のログが抜け落ちていたりすると、調査が非常に困難になるためです。また、攻撃者は攻撃終了後に自身の実行ファイル自体を削除してしまうので、可能であれば実行ファイル形式のものについても保存しておけると良いと考えています。取得するログの対象については、以下、「テレワークセキュリティガイドライン（第５版）」の P.77 の注釈 24 にも記載があります。
EDR の導入に当たっては、必要とする機能への対応を確認するようにしてください。また、その際には、取得・分析しようとするログ（OS の動作やそれによって発生するファイル操作やレジストリ変更等）について確認することも有効です。
EDR は振る舞いをベースに検知しているが、既知の危険な振る舞いと同様の挙動が見えた場合には、セキュリティ事故が発生する前に止められるべきです。この機能を一般的に NGAV（Next Generation Anti-Virus）と言います。
どのような経路でその既存のツールを使うかであったり、既存のツールを使ってどうしたかといった振る舞いにフォーカスを当てて、その挙動と同様の動き方をしたら検知をするようなアプローチです。改めて後述しますが、純粋な EDR だけですと、アラート数が膨大になったり、検知してから除去までのタイムラグが発生します。
「対応しなければならない脅威」をいかに減らしておくことが、運用負荷的にも大規模なセキュリティ事故になってしまうことを防ぐ意味でも、既知の振る舞いを防ぐことの出来る NGAV のような仕組みが必要であると、明確にされるべきと思います。
運用の定義
続いて、運用の定義について整理します。α パターンより、β パターンのほうが高度な運用が求められることになります。端末のログを取得しているので、そのログを利用した検知や隔離などのアクションを迅速に行うことが求められるからです。また、EDR の整理についても述べましたが、できるだけ自治体職員の運用負荷を減らさなければ、セキュリティ対策に忙殺されてしまいます。今回は以下の点について整理を進めていきます。
・脅威を「自動的に」できるだけ減らす：運用負荷を低減する
・できるだけ迅速に脅威に対処する：情報漏えいを早期に防ぐ
EDR導入時の運用負荷と役割分担
まずはじめに、EDR を導入した場合の運用負荷を想像してみます。
1. 挙がったアラートに対して、アクションの必要性を検討し、対処する
2. 隔離された職員のサポートをする（アクションが隔離だった場合に、業務ができなくなるなどの連絡が来る等）
続いて、どの範囲を誰がやらなければならないかを想像してみます。1 つ目は、MDR(SOC)のベンダーが対処してくれるはずです。しかしながら、2 つ目はほとんどのケースで自治体職員もしくは庁内にいる運用ベンダーがやらなければならないはずです。つまり、アラートが多ければ多いほど自治体職員に掛かる負荷は高くなっていくことが想像できます。また、人が介在すればするほど、対処までに時間がかかり、情報漏えいまでの猶予期間を与えることになってしまいます。できるだけ、アラートを減らしておきたい、アラートに対して自動的に処理を施していきたいというのが、運用負荷を下げるポイントになり得ます。
ではアラートが多くなってしまう原因を見ていきましょう。一般的にセキュリティは、脆弱性や設定が不十分なものを狙われて破られてしまいます。我々に出来ることは、その脆弱性や設定ミスをできるだけ早く見つけて、できるだけ早期に対処することなのです。
つまり、端末がきちんと統制されて可視化されていなければならないということなのです。仮想デスクトップは比較的 OS のイメージや設定を統制しやすいソリューションでしたが、物理端末というのは常に電源が入っているわけでも、常にネットワークが繋がっているわけでもないため、どうしてもセキュリティパッチや設定が完全に浸透しきっていることを保証するのは難しいです。そこで、何かしらの仕組みを入れることによって統制と可視化を実現する必要があります。
ただ可視化の結果、パッチが当たっていないので、当てるまで業務をできないように隔離するかというと、先程の理由から突然そこに踏み切るのは大きな影響が出ると思います。そのため、段階的に制御していく必要があると考えます。例えば、以下のようなフローができると、利便性とセキュリティの両立が可能になっていくと思います。
1. パッチが当たっていない状態の職員にメールを出す
2. その数日後に、まだパッチが当たっていない職員の PC 上にアラートを出す
3. 更に数日後に、パッチ適用が完了していない場合は、隔離処理をする
NGAV といった仕組みに加えて、このようにできるだけ脅威が入る隙間を減らす作業が定常的に必要であるとともに、これを自動的におこなうような仕組みが求められてくると考えています。この点については、以下のパブコメでも議論されています。
以下、「「テレワークセキュリティガイドライン（第５版）」（案）に対する意見募集の結果」の項目 28 に記載があります。
https://public-comment.e-gov.go.jp/servlet/Public?CLASSNAME=PCM1040&id=145209702&Mode=1
議論の内容はこちら。
https://public-comment.e-gov.go.jp/servlet/PcmFileDownload?seqNo=0000219508
「マルウェア感染後の対応を迅速に行えるように…」と記載がある通り、迅速に行うようにするためには、このようなオペレーションフローを自動化するという方法もありますし、パッチが当たっていなければネットワーク的に隔離するなどのアクションも自動化されれば、達成しやすくなっていくはずです。
実際に侵入されてから情報漏えいするまでの時間が 1 時間かかっていないケースもあり、検知から対処までのトータル時間を短縮するというアプローチの他に、検知した後すぐに自動的に一時的対処をおこない、よく調査してからの対処までの間に攻撃が完了されないようにするというアプローチも非常に有効と言えます。
このように EDR を導入してセキュリティ対策をすることは非常に重要なのですが、その前に取り組んでおくべきフェーズが何で、それを誰が担当するか、そしてどこまで運用負荷を下げられるかについて定義した一連の流れを設定すべきだと考えています。以下のような定義が改めて設定されるべきだと思いますし、これらのフェーズごとにきちんと一連の流れとして連携した対処ができることが必要だと思います。それぞれの情報を繋げる役目が手動になってしまうと、これらに取り組んでいた意味がなくなってしまうからです。
・マルウェアに感染しないように、脆弱性・設定ミスを統制・可視化するようにして予防フェーズを徹底する
・既知ツールを使った既に判明済みの振る舞いを検知して自動的に排除することで、インシデント対処数を低減する
・取得するログの範囲を、脅威の対象として可能性があるOS・アプリケーションに加え、実行ファイル自体の取得にまで拡大しておくことで、脅威の調査に滞りがないようにする
・端末の統制管理に、段階的な自動化の仕組みを導入して、利用者と管理者の負荷を下げるようにする
・検知から最終的な対処までの間に、一時的対処を連携して自動的におこなうような仕組みの奨励
LGWAN系セグメントにおけるEDRの必要性
続いて、β パターンにおいて、LGWAN 系セグメントでも EDR を利用するべきかについて考えていきたいと思います。その前にセキュリティ対策において何を守りたいかを明確にしなければなりません。そこには、「何を」「何から」守りたいかの目的設定が必要です。
何を守りたいか
まず、「何を」です。マイナンバーを守りたいというのが三層分離の根本の目的ではありますが、では以下のケースはどう思いますか？
・LGWAN 系セグメントに存在する（職員の）マイナンバー
・インターネット接続系セグメントに存在する外部業者とのやりとりの署名に含まれる業者氏名や連絡先
これらのケースについて、もし流出して第三者から指摘があった場合に、大丈夫と言えるかであるとか、調査して報告しなければならないかどうかを想像してみていただければと思います。今まで私が自治体の職員の方々と話していても、かなり認識に差がありました。国からのガイドライン上は住民のマイナンバーさえ守れればよいということで、最低限それを実施するという方もいらっしゃいましたし、たしかにマイナンバー以外の情報が漏れても問題になるので、それらを守るために対処しなければならないとおっしゃられる方もいらっしゃいました
何から守りたいか
次は、「何から」です。マルウェアの攻撃による情報漏えいを防ぐというのは、やはり至上命題であります。では、何らかの形でマルウェアが LGWAN セグメントに持ち込まれた場合、三層分離の構成をしているので情報が漏洩されないということで良いでしょうか？
ちなみにそのマルウェアがインターネット上に情報を流出させるつもりなら、それで良いでしょう。しかしながら、ランサムウェアだったらどうでしょう？情報を盗む気などなく、使えなくすることで金銭を受けることを目的としているタイプの攻撃は、インターネット上に接続する必要がありません。
直近では以下の事件も発生しています。これは閉域網で起きたものです。
https://www.topics.or.jp/articles/-/612733
このように、この 2 つの「何を」「何から」守りたいかは、適用すべきセキュリティソリューションの選定に最も影響する目的設定です。では最悪なケースとして、「LGWAN 系のデータ」を「ランサムウェアから」も守りたい場合、LGWAN 系のデータをどのように守れるかについてまとめていきたいと思います。
LGWAN系のデータを守るために。
まずは、インターネット接続系と同様に EDR が必要か否かです。答えは必要となるはずです。先にも述べた既知のツールを利用した攻撃が想定されるため、パターンマッチング形式では防ぐことが難しいと考えます。ただし、EDR や付随する NGAV の機能は、常に進化する脅威の情報をインターネット越しに入手して、最新の脅威に対応するスタイルを取っています。そのため、何らかの形で LGWAN 系セグメントからそういった脅威情報を入手する必要があるのです。LGWAN 系セグメントの端末から直接ですと、開放しなければならないポート数が膨大になるため、プロキシのような仲介役を通じてできるだけセキュアに接続する方法を定義して公開する必要があると思います。このやり方を定義しなければ、各地方自治体が自身の基準と判断でインターネットへの経路を開けてしまい、危険に晒されることにもなりかねません。
また、特定通信としてLGWAN系セグメントの端末からインターネットに接続しているケースもあると認識しています。インターネットに接続することを咎めるわけではありませんが、インターネットに接続するからこそ対策は必要だと思います。
ランサムウェアから守るために。
2 つ目は、ランサムウェアから守るためにはどのようにしたら良いかです。まずランサムウェアから守りたいものは、各端末のデータというよりは、大規模に影響を与えるはずのサーバーシステム側のデータになるはずです。これは、β/β'パターンにおけるインターネット接続系セグメントに移動されることになる、グループウェア等の一部システムにおいても同様の対策が必要と考えます。
先述の通り、基本的にはユーザーの何かしらの操作によって、マルウェアに感染することになるため、端末側が基点になります。マルウェア側からすると、システム構成もわからない真っ暗闇の中で、システムのデータにたどり着かなければならないため、ラテラルムーブメントを使った攻撃が想定されます。ラテラルムーブメントとは、システムの中でシステムを把握する動きであるとか、感染端末を増やすといった内部での活動を意味します。このような動きに対しては、境界型のセキュリティは意味を成しません。ランサムウェアはインターネットに出る必要がないからです。普段の端末 ⇔ サーバー間、サーバ⇔ サーバー間の通信と同じ経路のため、それが正常なものなのか、マルウェアによるものなのかを判断するには通信の中身を見ていくしかありません。しかしながら、セグメント間ならまだしも同一セグメント内での通信にセキュリティ対策などが掛けられているケースは少ないでしょう。
このようにサーバーサイド及び端末 ⇔ サーバー間でも、例えば普段使わない通信ポートを使っていた場合に検知をしたり、通信の中身がマルウェアの振る舞いと似ているといった検知の方法を組み込むといったような設計・運用の定義ができれば、このような内部セグメントに対する方針も明確になってセキュリティの向上に影響できるのではないかと思っております。
β パターンの場合には、インターネット接続系セグメントが物理端末になるため、ほとんどのケースでは LGWAN 系セグメントに置く端末は仮想デスクトップになることが多いと思われますので、このような取り組みがしやすい環境になるのではないかと思います。いずれにせよ、β パターンにおいては先行事例が少ないことと、検討項目で明確なものが定まっていない状況になりますので、上記のようなソリューションと運用の定義を明確にするとさらに検討負荷が低減され、セキュリティの質も向上していくのではないかと考えております。
αパターンにおけるEDRの必要性
ここまで β パターンの課題感を整理してきましたが、α パターンを選択した場合においても、同様の課題感があるのではないでしょうか。α パターンにおけるインターネット接続系に置く端末は仮想デスクトップですが、ここには EDR は導入しなくてもいいのでしょうか。例えば、仮想デスクトップの場合、物理 PC とは異なり、容易にリフレッシュ処理が可能です。それが故に、端末には後追いするためのログがなくなってしまいます。そのため、クラウドにログを保存しておくようなことが必要になってくるのではないでしょうか。α パターンと β パターンの間では、物理端末と仮想デスクトップの位置づけが変わるだけで、何から守り、何を守るかは基本的には変わらないはずです。それであれば、インターネット接続系が仮想デスクトップだったとしても物理 PC だったとしても、EDR を始めとした高度なセキュリティ対策は必要なのではないかと思います。
しかしながら、昨今ではインターネット接続系の仮想デスクトップ用途として、ライセンスコストの低減を目指して、Linux 系の仮想デスクトップソリューションが検討されることもあります。ただ、EDR 等の高度なセキュリティ対策製品が Linux に対応していないケースもあるので、それらが必須となれば仮想デスクトップソリューションにも影響を及ぼす可能性が高いと考えています。
いずれにせよ、インターネット接続系が物理 PC であろうが仮想デスクトップであろうが、本質的には変わらないため、β パターンにおいて EDR 等の高度なセキュリティ製品が必須であれば、α パターンにて不要とする結論にはならないと思います。そのため、このようなセキュリティ品質のズレを生じさせないためにもインターネット接続系サイトにも EDR 等の導入が必要であることを明確にすべきだと考えます。
テレワーク端末におけるエンドポイントセキュリティ
最後に、三層分離全体に関わる課題の中で、今まで触れられなかったテレワーク端末について整理したいと思います。
例えば、自宅等の庁外からインターネット接続する際に、一旦庁内に VPN 接続してからセキュリティクラウドを通じてインターネットに接続することになっています。自宅から直接インターネットに出られるにも関わらず、庁内を経由するという非効率なネットワーク経路になり、需要が増減する VPN 装置も最大需要に合わせた調達が必要になっています。LGWAN 系セグメントへのアクセスについては、仮想デスクトップ等の画面転送のソリューションを使うことが定義されているので明確になっていますが、インターネットサイドの仕事については、庁外からでも、一度庁内を経由するような経路ではなく、自宅から直接セキュリティクラウドに接続されてセキュリティを適用する方法が許可されるべきだと考えます。
今までは、一度庁内に接続する前提からも端末のセキュリティ状態はかなり高いレベルが求められ、運用に高負荷がかかっています。端末を庁内に持ち帰るごとにリフレッシュをしていたり、設定のパッチの完全性を保証するなど物理 PC では時間も手間もかかるような運用をしており、テレワークに対するネガティブな取り組みになっているケースもあります。できれば β パターンと同様に、できるだけ予防を徹底して、様々なコンディションごとにアクセスできるリソースなどを制限するといったことを組み合わせれば、テレワークの運用も軽減されるのではないでしょうか。
まとめ
ここまで様々なケースについて考えを整理してきましたが、ただでさえ検討項目が多く、複合的な要件を整合性を取りながら検討していくことの大変さがご理解いただけたかと思います。これらが難しいと感じて、α パターンに踏み切る自治体もあるでしょうし、考え抜いて β パターンを導入することを決める自治体もいるでしょう。それらを踏まえて、職員の方々がお持ちのスキルセットに照らし合わせて、地方自治体全体のセキュリティについてどうあるべきかを考えていかなければならないことは困難を極めると思っております。そのため、できるだけ高度なセキュリティ対策が施されるように、以下を改めて明確にしていただきたいと考えております。
EDR の在り方を再定義して、セキュリティの質と運用負荷の低減を実現
・取得するログについては、アプリケーションレベルに加えて、OS レベルについても分析対象とするといった解析に必要なログの範囲を定義する
・マルウェアに感染しないように、脆弱性・設定ミスを統制・可視化するようにして予防フェーズを徹底する
・既知ツールを使った既に判明済みの振る舞いを検知して自動的に排除(NGAV 等)することで、インシデント対処数を低減する
・端末の統制管理に、段階的な自動化の仕組みを導入して、利用者と管理者の負荷を下げるようにする
・検知から最終的な対処までの間に、一時的対処を自動的におこなうような仕組みの奨励
ランサムウェアへの対策を明確化
・LGWAN 系のセグメントから、脅威インテリジェンス情報を取得するためのインターネット接続を特定通信として許可
・端末 ⇔ サーバー間、サーバ⇔ サーバーで通信内容の振る舞い検知を実装
α パターン
・インターネット接続系のセグメントに置く仮想デスクトップにも EDR のソリューションが必要と明確化する
・インターネット接続系のセグメントに置く仮想デスクトップにも EDR のソリューションが必要と明確化する
テレワーク
・自宅等のリモートからは、インターネットを通じて直接セキュリティクラウドにアクセスできるようにする
・テレワーク端末については、β パターンと同様のセキュリティレベルの設定することで、検討負荷の明確化
その他
4層モデルなど、各自治体が独自で検討したものについては、必要性や妥当性があるため、取り組まれた構成についての可否を明確にするべき
最後に…
今回は現状の課題を中心に、「三層分離の見直し」についての課題を整理してみました。今後行われるであろう見直しの参考になれば幸いです。また、ガバメントクラウドやガバメントネットワーク・LGWANといったものとの関連性や、セキュリティクラウドの在り方についても今後まとめていければと思いますので、引き続き、note及びTwitterのフォローをお願いできれば幸いです。