以前、「WindowsからMacへの移行というチャレンジ」というタイトルで、従業員の使用するPCの入れ替えと課題にどう取り組んでいったかをまとめましたが、今回の記事はネットワークインフラの整備についてまとめた記事を作成しました。EFAにおいてネットワークインフラの整備を進めることは、「ユーザーの利便性の向上」と「会社の情報セキュリティの強化」という大きな2つの意味がありました。この記事ではその2つのテーマにおいて改善を行ってきた内容を記載します。

PCなどのデバイスをネットワークに繋ぐ目的は利便性の向上、効率化、仕事の速度向上だったりしますが、それと同時にセキュリティのリスクが伴います。ネットワークに繋いでいる以上、情報セキュリティのリスクをゼロにすることはできません。この利便性の向上とリスクのバランス、またその対策にどこまでコストをかけるかはネットワークに繋ぐ以上、考え続ける必要があります。

今振り返ると、過去のEFAのネットワークインフラは利便性が悪く、客観的に見てセキュリティリスクの高い状況であったと言えると思います。しかしながら、今回の記事に記載した対策によってなんとか持ち直し、社内の情報システムエンジニアの集まるイベントなどにいって話すと「そこまでやっているんですね」と評価いただけるくらいまで改善ができました。裏を返せば、弊社と同じ規模で同じようにインフラの整備を行うことができている企業は比較的少ないのかもしれません。

この記事は、中小企業における一つのケースとして、EFAのネットワークインフラに関する取り組みを共有したいということと、EFAの情報システムインフラに対する考え方と向き合い方を少しでも知っていただき、弊社のサービスを使っていただけるきっかけにしたいと考えて作成しました。

真っ先に直面した問題

私は2013年に環境コンサルタントとして入社し、それから2020年まで地歴調査、建物の環境調査、アスベスト調査などを行なってきました。この7年間で従業員が増加すると共に、現場で調査をしたり調査結果のレポートを作成する際などの「改善」がもっとできるのではないかと考え、現在の管理部へ異動しました。

しかし、異動してしばらくすると「ネットに繋がらない」、「共有ドライブにつながらない」、「分析報告書を出力するためのサーバーが応答がない」、「パソコンが遅い」など、どちらかと言えば情報システム/ネットワークインフラに関わる問題ばかり相談されることが増えました。生産側のツールを作ったりやり方を改善することを想定していた私でしたが、そういった社員からの相談（クレーム？）に直面して初めて自社が「ネットワーク・サーバー周りのインフラが大きな問題を抱えているのではないか？」と意識し始めることとなります。

何をすれば良いか分からない

私が実質的な担当者となる2年ほど前に別の者が概ね管理を行なっていたのですが、その担当者が退職してからさらにEFAの規模が拡大し、同時にネットワーク周りのトラブルが増えていったタイミングで、私が広くICTの担当となりました。

私は趣味で自作PCを作ったりしていた経験があり、PCの不具合については多少周りの方より知っていることはありました。そのため、「パソコンが遅い」という問い合わせについてはある程度の回答や対応ができたものの、一方で「インターネットに接続できない」、「共有フォルダーにつながらない」、「分析報告書のPDFを生成するためのレポートサーバーが応答がない」といったネットワーク・サーバー周りのことについては何をすれば良いか検討もつきませんでした。

加えてその頃、茨城県つくば市に新たな拠点を作り、分析業務を行うという話が持ち上がっていました。その拠点を運用させるためには、分析結果をシステムに入力するために神保町本社にあるサーバーに拠点からアクセスが行えるようにする必要があることが分かりました。

その分析結果を入力するシステムは古く、バグの修正や、帳票類の修正などによって業務改善をしたくとも機能を追加することができないなど、会社を成長させていく上でネットワーク・サーバー周りのインフラの管理ができていないことが、事業拡大のボトルネックとなっていることに次第に明確になっていきました。

同時にそれらの問題を解決するには私自身の能力不足を感じ、次第に「社内の情報システム担当」としてネットワーク・サーバー周りについて勉強が必要なことを自覚しつつ、徐々にですが対応していくこととなります。

原因と改善策

まずは外部のネットワークエンジニアの方を探して、社内の現状を洗い出すことから始めました。前任の管理者から引き継ぎが殆どなかったので最初はサーバーにログインするパスワードすら分からない状態で、現状がどうなっているかを確認することすら困難でした。それでも少しずつ情報を収集していくにつれて問題が明らかになってきました。

当時のネットワーク周りの課題はたくさんありました（以下の通りです）。

・課題1：メーカー混在。ネットワーク機器のメーカーがバラバラで、統合的な管理や障害箇所の特定が困難。

・課題2：老朽化機器の使用。一部スイッチングハブなどがサポート終了（EOL）を迎えており、脆弱性修正や最新機能の提供が停止していた。

・課題3：拠点間接続の不備。拠点拡大やリモートワークに必要なVPN接続環境が整備されていなかった。

・課題4：IPアドレスの枯渇。IPアドレスが管理されず、貸出可能な数が足りなくなっていた。

・課題5：ネットワーク分離不備。ゲスト用Wi-Fiがネットワーク分離されていない状態であった。

・課題6：回線契約内容の陳腐化。回線契約が古く、通信速度が遅いプランのまま利用していた。

・課題7：無線LANの負荷増大。無線LAN利用が集中し、通信が不安定になりやすかった。

・課題8　ネットワークセキュリティの弱さ。ネットワーク構成にセキュリティ強化策が十分に盛り込まれていなかった。

そして、以下のような改善を行いました。

・改善1：ネットワーク機器の総入れ替え

・改善2：IPアドレス整理とVLAN設計

・改善3：速度を改善するための対応

・改善4：インターネット通信のセキュリティ対策

次の章からはそれぞれの問題の詳細とそれに対して改善を行なった流れを記載します。

改善1：ネットワーク機器の総入れ替え

1-1. 背景

・課題1：メーカー混在。ネットワーク機器のメーカーがバラバラで、統合的な管理や障害箇所の特定が困難。

・課題2：老朽化機器の使用。一部スイッチングハブなどがサポート終了（EOL）を迎えており、脆弱性修正や最新機能の提供が停止していた。

・課題3：拠点間接続の不備。拠点拡大やリモートワークに必要なVPN接続環境が整備されていなかった。

社内のネットワーク機器はNETGEARとBUFFALOの機器が混在していました。メーカーが統一されていないと集中管理ツールの活用が難しくなるため、各機器の状態確認や設定変更に個別アクセスが必要となり、管理負荷が増大することになります。また、障害時の原因特定や復旧が遅れるリスクもありました。

機器の管理が難しくなるということは、管理に時間がかかり、その結果管理自体がされなくなる恐れも出てきます。当時の社内は「なぜここにこの線があるの？」というような放棄されたように見えるLANケーブルがあったり、どこにもつながっていないスイッチングハブがあったりと、まさに管理されていない状態でした。

放棄されているものはまだしも、現在現役の機器のファームウェアが古いままだったり、メーカーのサポートが終了しているのに使い続けたりということが発生すると一気にリスクが高まります。EFAではメインのスイッチがメーカーサポートを迎えていたのにそのまま使い続けてしまっていたことが判明しました。メーカーサポートが終了すると脆弱性が発見されてもアップデート用のファームウェアが提供されなくなります。

総じて、老朽化機器の放置によりセキュリティリスクが高まり、拠点間接続や基幹システムへの安全なアクセス構築にも支障をきたすという状況でした。

1-2. 改善策

このため、管理性とセキュリティの観点からネットワーク機器の刷新が必要と判断しました。そして全てのネットワーク機器を全面的に刷新し、メーカーを統一することにしました。入れ替えに際してネットワークエンジニアから勧められたのはYAMAHAの機器でした。

YAMAHAというとピアノやバイクなどを思い浮かべましたが、小規模オフィス（SOHO）向けのルーターシェアもかなり高いことを知りました。選定理由は以下の通りです。

・家電量販店やオンラインで入手しやすい

・設定情報や事例が豊富で、社内運用者が学習しやすい

・GUIが充実しており、初心者でも扱いやすい

・YAMAHAデバイス同士での接続可視化や集中管理（LANマップ機能）が可能

新拠点（つくば）にもYAMAHAルーターを導入し、本社との間にIPsec VPNを構築しました。

1-3. 改善結果

管理状況の可視性向上と負荷の軽減により、脆弱性を排除し将来の拠点拡張にも柔軟に対応可能となりました。

新しい拠点でもYAMAHAのルーターを導入し、拠点間を結ぶVPNの設定を行うことでつくばから神保町のサーバーにアクセスし、つくばからでも基幹システムへのデータ入力ができるようになりました。なんとか新拠点稼働までに機能するよう間に合わせることができました。

機器のメーカーがバラバラであった状態から統一し管理ツールを使っていくと非常に便利なことを実感しました。集中管理ツールでは例えば以下の「図1：LANマップの例」のように設定や機器の状態がビジュアルで分かります。設定するための個々の機械へのアクセスもこの画面からクリックで行えるため、複数台の機器を管理する上でのメリットを大きく感じました。

ヤマハのネットワーク機器管理画面のスクリーンショット。「LANマップ」という機能で、SWX3220やSWX2210など複数の機器がツリー状に接続されている様子がグラフィカルに表示されています。

図1：LANマップの例（設定や機器の状態がビジュアルで分かります）

老朽化機器を廃止したことで、セキュリティリスクを低減することもできました。メーリングリストに登録していると最新版ファームウェアが出たことも通知がくるため、それを確認して更新するようになりました。

神保町本社とつくば拠点のネットワーク構成図。両拠点がVPN接続されており、それぞれルーター、メインスイッチ、フロアスイッチを介してPCや無線LANアクセスポイントに接続されています。

図2：ネットワーク機器を統一した結果の構成図

改善2：IPアドレス整理とVLAN設計

2-1. 背景

・課題4：IPアドレスの枯渇。IPアドレスが管理されず、貸出可能な数が足りなくなっていた。

・課題5：ネットワーク分離不備。ゲスト用Wi-Fiがネットワーク分離されていない状態であった。

「ネットに繋がらない」といったことは状況によって原因が様々です。EFAで起きていたことは「たまにネットに繋がらない機器がある」ということでした。頻度は徐々に増加したため調査したところ、DHCPサーバーでのIPアドレス割り当て設定が端末の増加に対応できていないことが原因と判明しました。

DHCPサーバーは、ネットワークに参加してきた機器に対してIPアドレスを自動的に貸し出ししてくれる役割を担っています。貸し出したIPアドレスは、一定時間が経って使用されていなければ回収し、別の端末に割り当てて使うことで複数端末のネットワーク接続を維持しています。しかしこの回収のタイミングが適切でなかったり、利用が想定される端末とIPアドレスの数が合っていない規模で構成してしまっていると、ネットワークに参加できない機器が出てきてしまいます。

EFAでは約150個のIPアドレスを貸し出しできる設定でしたが、利用者数の増加に伴ってアドレスが不足し、人が多くなるにつれ次第にそのIPアドレスを使い切ってしまうようになっていました。

本来はIPアドレスを固定する端末がどれで、どのアドレスにするかや、動的にIPアドレスを付与する端末数がどれくらいあれば良いか、そして動的にIPアドレスを貸し出す（リース）時間はどれくらいにするかを見ておく必要がありましたが、その管理が出来ていませんでした。全体のアドレス設計が不十分だったのです。

2-2. 改善策

そこでIPアドレスの管理表を作成し、動的IPアドレスが必要な分も再計算して設計しなおしました。また、それと同時にVLANによるネットワークの分離も行いました。

IPアドレスの管理表作成 固定IPを割り当てる機器を洗い出し、アドレス範囲を明確化。
DHCPリース時間の見直し 実利用状況に合わせてリース期間を短縮し、アドレスの回転率を向上。
VLANによるネットワーク分離
- 社員用、ゲスト用、プライベート端末用など用途別にVLANを設定
- VLAN間通信をルーター/L3スイッチで制限
- 社用PC用とその他用でIPアドレスプールを分けて管理可能に

以前はWiFiのSSIDを社内用とゲスト用で分かれて設定がされていたものの、ネットワーク全体としてのVLAN設定が行えていませんでした。SSID分かれていても物理的には同一ネットワークに属していたため、リスクがある状態でした。VLAN導入により、ネットワークを論理的に分離し、セキュリティとアドレス管理の両面を改善しました。

2-3. 改善結果

VLAN導入と通信制限設定を入れることでセキュリティ向上がされたことに加え、使用するネットワークが異なることでIPアドレスの管理がしやすくなりました。社員のプライベート端末やゲストの端末の数を社用の端末と分けて考えられることで、より重要な社内端末の接続安定性に集中できることになりました。

また、ネットワーク構成が明確化したことによって、将来的な端末追加や拠点増設にも対応可能になりました。

調整の結果「ネットに繋がらない」といった問い合わせがなくなりましたが、もし今後同様のことが起きても、現在どの程度アクセスされていて貸し出されているIPアドレスがどれくらいで、どのように対処すれば良いかということまで想像がつくようになりました。ネットワークの仕組みの理解はある程度必要でしたが、使いやすい機器を使用して設定がうまくいくことを体験することで、自分の自信向上にも繋がりました。

改善3：速度を改善するための対応

・課題6：回線契約内容の陳腐化。回線契約が古く、通信速度が遅いプランのまま利用していた。

・課題7：無線LANの負荷増大。無線LAN利用が集中し、通信が不安定になりやすかった。

3-1. 回線の選択と10Gbps対応

第1段階（社員20名規模）

EFAで「ネットが遅い」という状態に陥ったのは2つの段階がありました。1段階目は社員が20人程度の規模の時点での話です。

「ネットが遅い」という原因には、ネットワーク機器の問題だったり、LANケーブルの問題だったり、PCの問題だったりと様々ありますが、ネットワーク機器を統一することでボトルネックがどこになっているかが分かりやすくなりました。

ネットワーク機器の統一後、ルーターの管理画面でインターネット通信の通信量のログを見ていたところ、100Mbpsが上限となっているようだということに気づきました。調べたところEFAが設立された当初からの通信速度契約のまま変えておらず、そこがボトルネックになっていることが分かりました。何も知らないまま当初の契約を続けているうちに世間では1Gbpsが標準となっていて、それに対応できていませんでした。毎月数百円増額するだけで契約を変更することができ、即座にボトルネックが解消されました。

ネットワークトラフィックの推移を示すグラフ。縦軸はMbps、横軸は日付です。契約変更前はトラフィックが100Mbpsの限界に達している様子が示され、契約変更後の1Gbps回線では、通信量が大幅に増加していることがわかります。

図3：100Mbps → 1Gbps 変更後のトラフィック

第2段階（社員40名規模）

1段階目の規模感は20人程度でしたが、2段階目はさらに増員して40人規模になってきたタイミングです。再度「ネットが遅い」と言われるようになってきました。理由は増員の他にもコロナ禍でオンラインミーティングが増えたり、リモートワークを実現するために共有ストレージをオンラインにしたりすることで急速にインターネット通信を多用するようになっていったためと考えられます。それに加え、1Gbps回線は一般家庭向けの回線だったこともあり、コロナ禍以降特に利用者が増える時間帯での急速な通信速度低下が起きていました。

そこで1Gbps回線に加え、10Gbps回線を別途契約することを検討し、10Gbps回線の方は帯域確保、稼働率99.9%、24時間365日対応といったサービスのついた法人向け回線を採用選択しました。

また、回線だけ速くしてもその機能を持て余してしまいます。「改善1：ネットワーク機器の総入れ替え」の時点では「将来の拠点拡張にも柔軟に対応可能となりました」と記載したものの、さすがに10Gbps回線を導入することまで想定していなかったため、より恩恵を受けるために基幹部分のネットワーク機器は10Gbpsに対応するように交換・増設し、配線も階層を跨いだフロアスイッチまでは光ファイバーケーブルを設置しました。配線や1Gbpsの機器は残し、今までの環境と併用することで冗長性を持たせることにしました。

社内ネットワークの構成図。本社にあるサーバー室から、3階、4階、8階の各フロアへ10Gbps対応機器を介して接続されています。各フロアでは、機を経由して、PCやモニター、無線LANアクセスポイントなどが接続されています。

図4：10Gbps対応後の構成図

3-2. 有線LAN環境の整備

「Wifiの調子がおかしい」という問い合わせは以前から何度もありましたが、原因や対応策をどう考えれば良いか分からずにいました。しかしあるとき無線LANの仕組みを理解していくと、非常に高度な技術で支えられていることに感動すると共に、通信傍受対策のための暗号化、デジタルアナログ変調、2.4GHz帯・５GHz帯の電波干渉、マルチパス干渉、半二重通信、1度に通信できる端末数が限られる、といったようなことが無線LANの仕様としてあるため、有線LANに比べて通信方法がかなり複雑で不安定になりやすいということをより意識するようになりました。

このため、LANケーブルを用意し、「無線LANを使っていて調子が悪ければ有線LANを使うようにしてください」と案内はしていました。しかし実際に設置した有線LANケーブルが使われることはほとんどありませんでした。理由はわかっています。接続の手間がかかるためです。私はPCでよくゲームをしていたからか、イヤホンでもマウスでも無線より有線の方が安心して使用でき、積極的に有線で接続して使用するのですが、世間一般ではそうではないようです。

つまり、無線LANの「場所を選ばない」という圧倒的なメリットが有線LANの利用普及を阻害していました。いくら有線LANの方が通信が安定していて良いですよと言ったところで、接続が面倒であればユーザーに定着しないのだということが分かりました。それでも社内LANの利便性を高めるには有線LANの利用が不可欠だと、上述した原理的にもそうなんだと信じていたため、なんとか有線LANを使ってもらう方法がないかを考えました。

そこで、上司との相談の結果、モニターに有線LANポートを備え、PCとモニターをUSB-Cで接続時にユーザーが意識せずに自動的に有線LANへ切り替わるマシン環境を構築することにしました。ついでにアスペクト比と目疲れ防止機能を含んだ質の高いモニター機種に全て統一することが決まりました。しかし、費用は以前使用していた一般的なモニターよりも3倍ほど高いものとなったため、1〜2ヶ月に1台程度の数を徐々に購入していく計画にしました。結果的に整備するまで4年ほどかかりました。

モニターを介してPCと有線LAN接続している2枚の写真。左側の写真には、モニター背面の接続部が写っており、有線LANとケーブルの接続箇所が示されています。右側の写真には、ケーブルでモニターとPCが接続されている様子が写っています。

図5：モニターを介して有線LAN通信を行なっている様子

3-3. 対策の効果

契約変更によって回線速度のボトルネックは解消されました。100Mbps → 1Gbps → 10Gbps（理論最大値）というように、段階に応じて徐々に契約を変更していくことでうまく対応できました。世の中の流れとしても10Gbps回線が一般化し、月額費用も下がってきていたため、タイミングとしてはちょうど良かったかもしれません。

また、法人向け回線にすることで混雑時間帯でも安定性が高い通信を実現することができました。過去には遅い回線の時に2MbpsでPINGが100を超えることもしばしばありましたが、そのようなことはなくなりました。

モニターを介して有線LANを使ってもらう作戦もうまくいきました。コストはかかりましたが、ユーザーは「意識をしなくても有線LANでつながっている状態」を増やすことができました。モニターからは電源も供給されたり、USB-Aポートもついているため、導入結果としては一石四鳥でした。

無線LANの仕組みを考えると、無線を使う端末が減れば減るほど、無線を使う端末の安定性が増すはずだという想定をしていましたが、「Wifiの調子がおかしい」という問い合わせは驚くほど無くなり、思った以上の効果がありました。想定していたように有線LAN使用率を増加させることで、無線LANを使用する端末同士の回線の混雑、電波干渉などが減ったことや、そもそも問題の起きやすいWifiの使用率が減ったことなどが合わさって、結果的に不具合率を下げることに成功したのだと思います。

ここまでの対策を行ってそれでも問題がありそうであれば処理能力の高い無線LANアクセスポイントを追加で何台か購入し、負荷を分散させる予定でした。しかし現状ではそこまでする必要はなくなりました。

改善4：インターネット通信のセキュリティ対策

・課題8　ネットワークセキュリティの弱さ。ネットワーク構成にセキュリティ強化策が十分に盛り込まれていなかった。

このセクションの内容は、今までと異なり明確に「ここが問題だ」ということが分かっていたわけではありませんが、コロナ禍で「リモートワーカー」というスタイルが明確になり始めたことで、EFAでも社外で仕事を行う際のセキュリティリスクをどう考えるかがより明確に焦点になりました。

こうした背景の元、WindowsからMacへの移行というチャレンジで記載した内容と少し重複する内容もありますが、アイデンティティ管理とネットワークセキュリティについて取り組んできた内容を記載します。

4-1. Active DirectoryからGoogle Cloud Identityへの移行（アイデンティティ管理）

EFAでは主に基幹システムへのアクセスと共有ファイルサーバーへのアクセスのためにActive Directory（以下、AD）で統合管理を行なっていました。ただしこの構成では全ての通信を本社と繋げるために、拠点やリモートワーカーのPCを本社にVPN接続する必要がありました。クラウドサービスが一般化する以前の時期には、社外にあるPCもあたかも社内にあるかのように管理する手法としてVPN接続は一般的でした。

しかしこの方法は、本社のネットワーク回線に大きな負荷をかけ、ただでさえ通信速度の遅さについて問い合わせがあったのが、さらにその要因を増やすことになります。また、昨今の情報漏洩のニュースでもVPNルーターの脆弱性を突かれたという事例が目につくようになり、VPNを管理することやVPNの認証のみに頼ったアクセス管理はリスクが高いことが世間的に認識されると共に、私自身もVPN設定などを管理する自信はありませんでした。

そこで、ADによるユーザー管理を辞め、Google Workspaceのアカウントを利用することにしました。さらに、基幹システムの更新のタイミングでサーバーをクラウド化し、Googleアカウントによる認証を基幹システム改修要件の一つとすることにしました。基幹システムの更新については別の記事でも記載しています（課題1：Windows専用の基幹システムの変更、課題4：Active Directoryとの決別）

他にも勤怠、経理、労務システムや、ファイルサーバーなどのSaaS製品を導入し、効率化と社内のサーバー管理からの脱却という両方の面での改善を進めていましたが、こうしたSaaSサービスについては可能な限りSSO（Single Sign-On）でログインできるように設定しました（例えばMicorsoft Office 365へのログインはGoogleとEntra IDを連携し、Googleアカウントでログインできるようにするなど）。

現在はエンタープライズSSO（SAMLやOIDCといった厳格な認証プロトコルを利用して、組織のシステム全体でSSOを実装すること）とソーシャルSSO（GoogleやLINE、Facebookなどの個人アカウントを使って、様々なWebサービスにログインすること）の中間で運用しています。弊社の規模感からしてGoogleをIdPとしたソーシャルSSOや、認可のみのOAuth設定に留めた運用がバランスが良いと考えています。組織全体で厳密な管理にした場合、各SaaSを連携可能なプランにアップグレードするコストや、証明書の有効期限が切れの問題や、自動プロビジョニングのメリットを受けるためのグループ管理の煩雑さなどが発生すると考えられます。まずはこの先、パスワードマネージャーの導入や多要素認証の設定を徹底するなど効果的な対策から順に実施していくことが課題と考えています。

4-2. SSEの導入と細かいアクセス制御（ネットワークセキュリティ）

EFAでは、できるだけ使用するツールを最小限にし、重複した機能のSaaSサービスは契約しないように慎重に検討するという方針で改善を進めてきました。しかしそれであっても、便利なSaaSやWebアプリがでてくるようになったり、ノーコードツールやAIの登場によってマイクロアプリがWebブラウザ上で当たり前に作れるようになってきたりするにつれ、ユーザーによる安易なサービスの利用はコントロールできなくなってきていました。「シャドーIT」や「シャドーAI」といったような言葉も聞くようになり、情報漏洩の観点ではどのように通信を管理するかの重要性が急速に上昇してきました。

そこで各社員の端末が意図せずリスクの高いネットワーク通信を行うことを防ぐ目的で導入を考えていたのがSASE（Secure Access Service Edge）またはSSE（Security Service Edge）と呼ばれる製品の導入です。機能によっては大きな導入コストがかかることや、数ある各製品がそれぞれどういった仕様かが良くわからず、検討を始めてから実際に導入にこぎつけるまでに約2年かかりました。最終的にCato Networksを採用し、半年ほどかけて徐々に適用していきました。

実際の設定による制御内容の一部例を表1にまとめました。なお、機能の概要を説明するために、ガートナーによるSSE機能分類を元に制御内容の例を分けて記載しています。

表1：Cato及びGoogleのContext Aware Accessで実施している主なアクセス制御（機能分類別）

制御内容の例	機能分類	概要説明
・特定のカテゴリー（例：フィッシング、ギャンブル、犯罪行為など）のサイトやドメインとの通信をブロック・特定のサイト（例：無料のファイル共有、ファイル変換サイトなど）へのファイルアップロードのブロック	SWG（Secure Web Gateway）	Webアクセスを安全にするためのゲートウェイ。URLフィルタリング、マルウェア対策、Webアプリ制御などを行う
・業務に不要な特定のSaaSアプリとの通信をブロック・会社以外のドメイン（例：@gmail.comや@outlook.comなど）でのGoogle、Microsoftアカウント等へのログインをブロック	CASB（Cloud Access Security Broker）	SaaS利用を可視化・制御するゲートウェイ。認可されていないクラウドサービスやアカウント利用を制限
・地理的に特定された国（北朝鮮など）への通信をブロック・マルウェア感染端末の遠隔操作に使われるC&Cサーバーとの通信をブロック・暗号化されていないプロトコル（例：TELNETなど）や、既知の脆弱性を含む旧バージョンのプロトコル（例：SMBv1など）での通信をブロック	FWaaS（Firewall as a Service）	クラウド上で提供されるファイアウォール機能。IPアドレスやプロトコル、地理的ロケーションなどの条件で通信を制御
・会社PCから私用アカウント（例：@gmail.comや@outlook.comなど）へのログインをブロック・会社支給のPC以外（BYOD端末）での会社ドメインアカウントへのログインをブロック（※）	ZTNA（Zero Trust Network Access）	ユーザーや端末の信頼性を常に検証し、必要最小限のアクセス権だけを付与する
・特定のサイトへのファイルアップロードのブロック（SWGと併用）・生成AI、メール、チャットなどのやり取りにおいて特定の文字列（例：マイナンバーなど）の通信をブロック	DLP（Data Loss Prevention）	機密情報の漏えい防止。ファイルや通信内容を解析し、機密データの送信を防ぐ

※共有ドライブのような重要なファイルなどについては、SSEが起動していないもしくはMDMがインストールされていない端末から会社ドメインのGoogle Workspaceへのアクセスをブロックするよう、GoogleのContext Aware Accessを導入しました。

端末からインターネット通信を行う際にはSSEを通過していきますが、それぞれの宛先ごとに通信制御のイメージを図6にまとめました。

ネットワークセキュリティの通信制御の概念図。MDM、IdP、SSE、SaaSなどの用語と、それらの間を矢印で結んだ図です。MDMが端末を管理し、IdPがログインを制御し、SSEが通信制御を行う様子が示されています。

図6：ネットワーク通信制御のイメージ

（実際の通信の流れとは異なる部分や記載がされていないまたは省略している箇所があります）

SSE導入によってSaaSの利用状況確認やリスクの高いWebサイトへのアクセス制限、社用とプライベートアカウントの明確な切り分け、といったようなことができるようになり、効果を実感しています。今後会社のポリシーを変更してもそれに追従して設定を入れることで、即座に対策を行えるようになりました。

おおよそSSEでできることは表1にある通りで、どのくらいの効果があるかを定量的に示すことはできません。言えるとすれば、何かが発生した際にこれくらいの損害が出るので、このくらいの費用をかけて対策をして保険をかけるといったことかと思います。

しかし、それでもあえて私の独自の実感値としてどのくらいの効果があったと思えるかを簡単なグラフにしました。例えば外出先でネットワークに繋ぎたいと考えた場合、何も対策しないで公共の電波に繋ぐ場合の「未対策」のリスクを100とし、考えうる最善の方策として、「モバイル回線 + EDR + SSE」の組み合わせをリスク5とした場合を仮定しました。その際の「モバイル回線」のみを導入している場合、「モバイル回線 + EDR」を導入している場合、をプロットしたものが図7になります（EDR：Endpoint Detection and Response）。

ネットワークセキュリティ対策の段階とリスクの関連を示す折れ線グラフ。横軸は「未対策」「モバイル回線」「モバイル回線 + EDR」「モバイル回線 + EDR + SSE」の4つの段階、縦軸は「セキュリティリスク」です。対策が進むにつれてリスクが大幅に低下していく様子が示されています。

図7：ネットワークセキュリティリスク低減のイメージ

（※あくまでも筆者の経験から整理した感覚値で、実際のリスクを定量化したものではありません）

セキュリティ対策の効果を数値化することはできませんが、イメージとしてはSSEを導入することでリスクを大幅に低減できるような感覚があります。これはあくまで私の独自の感覚値であり、実際の効果は利用環境や運用状況に大きく左右されます。もちろん導入しただけでセキュリティを意識した設定をしていなければ効果も低くなります。

最後に

最初は自分が何も知識を持たず状況が分からないことに絶望感さえありましたが、それから4年ほど経過しネットワークインフラを安定化させ、セキュリティ対策が徐々に行えるまでになりました。改善1（ネットワーク機器の総入れ替え）、改善2（IPアドレス整理とVLAN設計）、改善3（速度を改善するための対応）は、主にネットワーク機器の入れ替えや回線の契約変更によって、利便性の面で非常に大きな効果がありました。社員からの問い合わせも格段に減りました。改善4のセキュリティ対策については他社の情報セキュリティ担当の方から「そこまでやっているんですね」と評価いただけるくらいに進歩することができました。私が見聞きする範囲では、この規模の会社でのSSE導入はまだ少ないようです。EFAにおいても「VPN依存からの脱却」という大きな障害を乗り越えての導入でした。

試しに国内の法人を約360万社とし、主要な各SASE/SSE製品10社で公表されている採用数や顧客数から、日本のSASE/SSE導入企業数をフェルミ推定してみました。その結果、採用率はだいたい2.5万〜3.5万社（全体の約0.7〜1.0%）程度と推定されました。仮に母数を5人以上の会社（全体の60%）と仮定しても、約1.2〜1.6%と推定されます（あくまでも私の推定です）。SASE/SSEベンダーは各国にPoP（Point of Presence）を配置して通信を裁いています。PoPの数や性能には物理的な上限があるため、1社で何十万社もの顧客を支えることは現実的には困難です。実際のところグローバルで見ても各ベンダーは数千〜数万社規模の導入実績が多いため、日本国内では数百〜数千社レベルにとどまっているかもしれません。

私が導入検討をした際には「他社がどのようにSASE/SSEを導入し、どのような効果があったのか」という情報が極めて少なく、不安を抱えていました。特に50名以下の例はほとんど見つけることができません。本記事は、同じような状況にある方にとって少しでも判断材料になる情報があればと思い、実体験をもとにまとめています。もちろん環境や規模によって結果は変わりますが、こうした情報が増えることで、より現実的な議論が広がることを願っています。

SSEを導入した一方で、組織の情報セキュリティの向上は単にツールを購入するだけで実現できるものではないと実感しています。適切な設定や日常的な異常監視、どういったポリシーで運用するか、報告や改善体制の構築、未知の攻撃への対応方針、利用者各々の情報リテラシー向上、利用者や管理者のモラル向上、レポートと改善、といったような複数の要素の組み合わせと、掛けるコストとのバランスが必要で、EFAでもまだまだ課題はあります。

これらを前向きに進めていくためには、ネットワークインフラやセキュリティ対策が単にコストというわけではなく企業価値を高める資産として、徐々に経営層が主体的に取り組むべき戦略的課題とすることです。EFAにおいてはそういった認識で今後も対策を行っていく必要があると考えています。

情報インフラをしっかり整備することは、EFAがお客様に提供する価値の基盤であり、安心してご依頼いただける理由の一つになると信じています。今後も企業価値を高める重要な資産として、社内インフラの整備に継続的に取り組んでまいります。

長くなりましたが、最後までお読みいただき、誠にありがとうございました。私の通ってきた道のりと苦労がネットワークインフラ改善の検討をされている方の参考になれば幸いです。

図2、図4には、ヤマハ株式会社がクリエイティブ・コモンズ表示 - 改変禁止 4.0 国際ライセンスで提供している「ネットワーク構成図作成用アイコン」を使用しています。（https://network.yamaha.com/support/download/tool）

〇ライター紹介

今回のライター：管理部　八木（情報システム担当）

2013年EFAに入社し、土地・建物の環境調査を7年経験。その後バックオフィス業務に4年従事。

・共同購入でキーボードを購入してから届くまでに一番時間のかかった待ち時間：2年11ヶ月