セキュリティは生産性を上げるのか？｜企業ネットワークを通信構造から問い直す

1. インターネットは速くなった。仕事も速くなったのか

企業の情報システムは、この20年で大きく変化しました。FAXや代表電話を中心とした時代から、社員一人ひとりがメールアドレスを持ち、Web、SaaS、クラウド、生成AIへ直接接続する時代へ移行しています。

その過程でFirewall、UTM、VPN、MFA、EDR、SWG、CASB、DLP、メールセキュリティ、URLフィルタ、DNSフィルタなど、多数の防御機能が追加されました。個々の製品には明確な役割があります。しかし、機能を積み上げた結果として、情報取得が速くなったのか、障害に強くなったのか、運用が簡単になったのか、コストが下がったのかは、別途検証する必要があります。

2. なぜFAX番号は一つだったのに、メールアドレスは社員数だけあるのか

かつて企業への入口は、代表電話やFAXなど、会社や部門単位で設けられていました。 外部から届いた情報は、受付や総務、担当部門を経由して、必要な人へ振り分けられていました。

現在は違います。社員一人ひとりがメールアドレスを持ち、 Web、SaaS、チャット、SNSなど複数の経路から外部情報を直接受け取ります。 社員100人なら、企業の外から個人へ直接到達できる入口も大きく増えます。

ここには、インターネットによる企業コミュニケーションの大きな変化があります。 情報を届ける経路は増えました。 しかし、人と人をつなぐ経路が同じように増えたわけではありません。 むしろ、受付、分類、判定、振り分けをシステムへ置き換えることで、 人間の接点を減らす方向にも進んできました。

3. 現在のメールとWebは、人が読む前に機械が読む

2020年以降、クラウド型メール、URL検査、Secure Web Gateway、DNS判定、EDR、SaaS制御などの中間層が増えました。Webアクセスは、検索からWebサイトへ一直線に到達するとは限りません。

その結果、Openが人間の閲覧、Clickが人間の関心を意味するとは限らなくなりました。当社のメール配信・Web運用でも、URL安全性検査や自動リンク展開を含むと考えられる機械アクセスが観測されます。アクセス解析では、人間と機械を切り分ける必要があります。

4. Apacheログには、悪質BOTの「探索行動」がそのまま残る

当社 ieee802.co.jp の2026年8月25日Apache SSL access logでは、複数IPからWordPress系プラグイン、管理画面、不審なPHPファイル名などを順番に探索するアクセスを確認しました。

GET /wp-content/plugins/hellopress/wp_filemanager.php 404
GET /this_is_a_new_hello_world.php                  404
GET /admin.php                                      404
GET /images.php                                     404
GET /alfa.php                                       404
GET /wp-cron.php                                    404
GET /media.php                                      404
GET /LegioN_LeakeRs.php                             404

5. WAFで止めやすい攻撃と、止めにくいBOTは別物

SQL Injection、XSS、OSコマンド実行、PHP-CGI悪用、ディレクトリトラバーサルなど、明確に悪いペイロードはWAFの得意分野です。当社運用でも、こうした典型的な攻撃通信をBLOCKする役割は確認できます。

一方、スクレイパーは必ずしも不正な文字列を送るわけではありません。通常のページへ通常のGETを送り、200 OKを受け取るだけなら、HTTPとしては正常です。ここでは「攻撃を止める」だけでは不十分です。

必要なのは BOT Block ではなく、BOT Classification → Policy です。

6. 攻撃側ほど、Proxy・Cloud・分散経路を使いこなしている

Proxy、VPN、Cloud、Residential IP、Relay、Redirect、短命ドメイン、分散ノードは、企業側では制御・ログ・可用性のために使われます。同じ技術は、スクレイパーや攻撃側では発信元の秘匿、制限回避、分散、スケールのためにも使われます。

7. 守る側は組織図で分断され、攻める側は通信経路全体を見る

企業内では、ネットワーク、情報システム、セキュリティ、メール、クラウド、総務、事業部門が別々に管理されがちです。その結果、個別最適が積み上がります。

攻撃側はこの経路を一つとして見ます。守る側も製品一覧ではなく、情報がどの入口から入り、どの認証を通り、どの出口から出て、どこにログが残り、障害時にどこへ迂回できるかを一続きの経路として見る必要があります。

8. FortiGateはある。しかし回線は一本

高額なFirewallやUTM、MFA、EDR、拠点間VPNがあっても、WAN側が単一キャリア・単一ISP・単一収容局・単一物理経路へ依存していれば、回線障害で業務は停止します。

回線を二本にすれば十分でもありません。同じキャリア、同じ局舎、同じ管路、同じISP、同じ上位網を共有すれば、共通障害点を残す可能性があります。必要なのは回線数ではなく、障害モードを分けることです。拠点内の通信・電源に残る単一障害点については、電源SPOFと可用性も確認対象になります。

• 異キャリア
• 異ISP
• 固定回線 + LTE/5G
• 異なるDNS系統
• 異なる出口
• 独立した認証経路

9. Proxyを「防御製品」ではなくControl Pointとして見る

ProxyやSecure Gatewayの本質は、単にWebを止める装置ではありません。外部通信の入口と出口を集約し、企業の情報流通を制御・記録・迂回させるControl Pointとして使えることにあります。

重要なのは「何を止めるか」だけではありません。何を通すか、どこから出すか、障害時にどこへ逃がすか、誰が何へアクセスしたか、業務上必要な情報をどう例外化するかまで設計できることです。

10. 中堅企業ほど「製品はあるが、全体設計がない」状態を点検する

Firewallはある、EDRもある、Microsoft 365もある、VPNもある。しかし、出口設計が単純、回線冗長性が弱い、ログが分散、例外処理が属人的という構成は起こり得ます。

この場合、「セキュリティ予算が足りない」と考える前に、投資の順序と配分を評価する必要があります。新しい製品を増やすより、既存機能の重複、二重課金、SPOF、人的処理を特定した方が効果が大きい場合があります。投資優先順位は、何もしない場合の損失と選択肢も基準に判断します。

11. 最初にやることは、通信経路を一枚の図にすること

この図に対し、次の観点を対応付けます。取得したログや計測値の再現性は、一次データの判断条件と合わせて確認します。

• どこがSPOFか
• どこが重複しているか
• どこで同じ機能に二重課金しているか
• どこでログが分断されているか
• どこで人間が余計な作業をしているか
• どこで障害時に迂回できないか

ここから初めて、必要な投資と不要な投資を切り分けられます。停止時の電源・通信の成立条件は、非常用電源の設計条件や防災通信を維持した実装事例からも確認できます。

12. セキュリティと生産性は、本来トレードオフではない

Webが見にくい、メール確認が増える、例外申請が増える、必要な情報に到達できず私物スマートフォンへ迂回する。この状態は、安全性を上げるために生産性を犠牲にしているのではなく、統制経路の外側へ業務を押し出している可能性があります。

ポリシー、ログ、例外処理、回線冗長化を一つの構造として設計すれば、安全性と生産性を同時に改善できる余地があります。

14. 私物スマートフォンへの迂回は「Block成功」ではない

企業ネットワークで必要な情報へ到達できないと、利用者は必ずしも情シスへ申請するとは限りません。「スマホで見ればよい」と判断すれば、セキュリティログ上はBlock成功、Incidentなし、問い合わせなしに見えます。

しかし実際には、業務時間増加、管理外端末利用、情報共有困難、AI利用の管理外化、原典確認不足が生じる可能性があります。過剰防御による損失は、セキュリティログには現れにくい点が重要です。

15. Web公開側と企業利用側は鏡像になっている

Allow / Blockだけでは足りません。

誰が、何の目的で、何を、どの速度で、どの範囲まで、どの経路から利用しているかを見ます。現代のネットワークは、単純な境界防御だけでは評価できません。