こんにちは！

ChatGPTやClaudeといった生成AIサービスが業務に浸透し始めた今、

「AIに機密情報を送ってしまうリスク」

が新たなセキュリティ課題として浮上しています。

この課題に向き合う中で、私たちは改めて「企業のセキュリティアーキテクチャはどう変遷してきたのか」を振り返る機会がありました。

すると、ある疑問が浮かんできます。

「なんでこんなに複雑になってるんだっけ？」

企業のセキュリティ担当者なら、一度は思ったことがあるのではないでしょうか。

アルファベット3〜4文字の製品が乱立し、それぞれが微妙に重複した機能を持ち、設定は複雑化し、コストは膨らみ続けています。

当社ではAIセキュリティ関連プロダクトをご提供しておりますが、AI時代のセキュリティを考える上でも、この歴史を理解することは重要ではないかと考えました。

本記事では、企業ネットワークセキュリティの変遷を振り返りながら、「なぜこうなったのか」を整理してみたいと思います。

第1章：観測点を集約できた時代 ― オンプレAD + Proxy（〜2010年代前半）

統制しやすかったモデル

かつて、企業ネットワークにおける「インターネット出口の統制」は比較的シンプルでした。

もちろん、当時も境界ファイアウォール、IDS/IPS、メールゲートウェイ、アンチウイルスなど、様々なセキュリティ製品は存在していました。

しかし、
インターネットへの出口をProxyに集約できた
ことで、Web通信の統制という観点では非常に筋の良い構成が実現できていました。

上図のようにWindows系のPCを活用している企業の場合、Active Directory(以後AD)がユーザーの認証の仕組みや証明書の配布、Proxyサーバーの設定などを一元管理します。

なぜこのモデルが統制しやすかったのか

このモデルがうまく機能していた理由は、以下の3点に集約されます。

通信経路の一本化について

社内ネットワークは「閉域網」として設計されていました。

インターネットへの出口はProxyサーバーだけであり、社員がProxyを経由せずに外部と通信することは、そもそも不可能、という仕組みです。

認証の統合について

さらに、ユーザー認証についても考えてみましょう。

すべてのユーザーが（論理的に）１つのProxyを通ってインターネットにでていくということは、会社側がその気になれば、従業員がどんな通信をしているかわかります。

そのとき、Windows系のPCを導入している会社には統合Windows認証という仕組みがありました。それを使うと、Proxyサーバーが、それを使ってるのは誰か、という「ユーザー特定」ができるようになります。

といってもProxyがユーザーを特定できるのは、Proxy側が認証（Proxy-Auth）を要求し、Kerberos/NTLM（統合Windows認証）でユーザーを確定できた場合です。

ただADがあれば自動的に特定できるわけではなく、Proxy側・ブラウザ側の統合認証設定が正しく噛み合って初めて成立します。

実運用では、この統合認証の設定が地味にハマりどころでもありました。

しかし、一度正しく構成できれば、ユーザーが意識的に何かをする必要なく認証をすることができました。

観測点の集約について

そして、上記の2つが組み合わさることで、企業は
「誰が」「いつ」「何を」したかを把握できました。

そして、Web通信に関するDLP（Data Loss Prevention：情報漏洩対策）を実装するなら、Proxyで実施するのが効率的でした。Proxyを通って外の世界とインタラクションするからです。

ただ、データの出口はWebだけではありません。メール、ファイルサーバー、USBデバイスなど、当時も複数の経路が存在していましたので、DLP製品ではそういった部分の監視、追跡もやっています。Proxyは強力でしたが、万能ではなかったという点は認識しておく必要があります。

情報漏洩対策としてのMITM

さて、現代ではほとんどの通信がHTTPSで暗号化されています。

では、暗号化された通信の中身をどうやって検査していたのでしょうか？

答えは「SSL/TLSインスペクション」、実質的にはMITM（Man-in-the-Middle） という仕掛けをつかいます。

つまり、Proxyの中でいったん暗号通信を復号化して検査します。問題がなければ、そのままインターネット側につなぐ、という方式です。

この仕組みを実現するためには、まずユーザーが使うブラウザがProxyを信頼しないといけないため、ブラウザに企業独自のルートCA証明書（会社内のProxyはあやしくないですよ、っていうことを証明できる）を全社員のPCにインストールする必要があります。

「全社員のPCに証明書インストールする？面倒そう？」と思われるかもしれませんが、そういうときのためのADです。

ADドメイン環境では、グループポリシー（GPO）を使ってルート証明書を自動配布できたため、この点でも統制が取りやすかったのです。

ADが配布していたもの

ADは単なる認証基盤ではなく、様々な設定を一括配布する役割も担っていました。

社員は何も意識する必要がありません。ドメインにログインするだけで、必要な設定はすべて自動的に適用されていたのです。

つまり、Proxy設定も配布できるので、ふつうのProxyからDLP用のProxyに社員のPCの設定をかえたいときもADを経由して全社員のPCに自動的に反映することができます。従業委員を管理する側としてはＡＤはとっても楽でした。

この時代の特徴まとめ

「セキュリティと利便性はトレードオフ」とよく言われますが、この時代は
社内にいる限り、観測点を集約できるので統制が取りやすかった時代
だったと言えます。

第2章：変化の始まり ― クラウドとモバイルの台頭（2010年代中盤〜）

ビジネス環境の変化

さて、2010年代中盤から、企業を取り巻く環境に大きな変化が起きました。

大きく２つあります

まずクラウドコンピューティングの時代となりＳａａＳが普及し、いろいろなアプリがクラウド化されていきました。Ｗｅｂから使う感じですね。

もう１つは、iPhoneの登場によりガラケーからスマホの時代になり、スマホで外出先でも仕事をしたい！という需要がでてきました。

これらの変化により、「社内ネットワークに物理的にいないと仕事ができない」という前提が崩れ始めました。

閉域網モデルの限界

従来のモデルで社外から仕事をするには、VPN（Virtual Private Network） を使って社内ネットワークに接続する必要がありました。

この方式にも課題がありました。

こうした社内ネットワークへのリモートアクセスは現代でも一般的ではありますが、特にクラウドサービスの利用が増えると、
「社内にいないのに社内を経由してクラウドにアクセスする」
という非効率さもめだってきました

この非効率もスマートに解消できないか、という思いから
企業は新しいアプローチを模索し始めました。

第3章：クラウド認証基盤の登場（2010年代後半〜）

オンプレADは今も現役、しかし選択肢が増えた

さて、クラウド時代にＳａａＳが普及しスマホで外出先から仕事をするのはわりと当たり前になってきましたが、ここで重要なのは、オンプレミスのActive Directoryが「古くなった」わけではないという点です。

現在でも多くの大企業では、オンプレADが認証基盤の中核として稼働していますし。

特に、社内にファイルサーバーやレガシーアプリケーションが残っている環境、厳格なセキュリティ要件がある環境では、オンプレADは引き続き重要な役割を果たしています。

クラウドサービスの普及に伴い、認証基盤もクラウドに移行する流れが生まれました。 従来のオンプレミスADに加えて、クラウド型の認証基盤（IDaaS） を導入する企業が 増えていきました。

代表的なのが Microsoft Entra ID（旧 Azure AD） です。オンプレミスのActive Directory と同期させてハイブリッド構成にしたり、クラウド単独で運用したりと、柔軟な構成が 可能になりました。

クラウド認証基盤が選ばれる理由

Microsoft Entra ID（旧 Azure AD） のようなクラウド型の認証基盤（IDaaS）を導入・併用する企業が増えている背景には、以下のような理由があります。

これにより、社内ネットワークを経由せずにクラウドサービスにアクセスできるようになりました。

得たものと新たな課題

クラウド認証基盤の導入・併用により、利便性は確かに向上しました。

しかし、セキュリティの観点では新たな課題が生まれています

なぜ「誰が」の特定が難しくなったのか

さて、ADをつかってProxyをうまく連動させると、統合Ｗｉｎｄｏｗｓ認証をつかって「誰が」「どんな通信をしてるか」は観測可能です、という話を冒頭でしましたが、昨今はなぜ「誰が」の特定が難しくなってるのでしょうか。

重要なポイントは
「認証方式が変わったから」というより、「経路と観測点が分散したから」
です

クラウド認証（SAML/OIDC/OAuth）とは「アプリ（SaaS）側で認証が完結」する仕組みです。

そして端末が社内網を経由せず直接SaaSへ出るようになると、従来の「出口Proxyで一括観測」というモデルが崩れてきます

とはいえ
「クラウド認証だからProxyが絶対に誰か分からない」わけではありません。

端末の通信を依然としてSWG/Proxyに強制し、Proxy側でユーザー認証（IdP連携や端末証明書、Kerberos/NTLM等）をさせれば、Proxyはユーザーを把握できます。現代のSWG/SSE製品がまさにそれをやっており、後述するSASEが「identity/contextベース」を含むとされるのもこの方向性です。

ただし、そのためには端末の通信を確実にProxy/SWGに向ける仕組みが別途必要になります。

なんだかまどろっこしいですが、がんばればProxyに通信をもってこさせることはできるんだけど、そのためには「追加のソリューションが必要」ということになります。

第4章：観測点を再集約するための様々なアプローチ

クラウド直行で分散した観測点を、もういちど何らかの形で再集約しようとする動きが生まれました。

そうして様々な「補完ソリューション」が登場しました。その背景には、この「分散した観測点をどう束ねるか」という課題があります。

時代が進化していろいろ複雑になってしまったけど、なんとかして「誰が何をしてるのか」を観測したい、ということでいろいろ考えてみた、という感じでしょうか。

アプローチ1：エンドポイントにエージェントを導入

まず１つめあ、「境界で観測できないなら、端末側で観測すればいい」という発想です。

この方式は要するにPCに監視用アプリをインストールしましょう、という発想です。PCにインストールされたエージェント（実態はただのPCアプリ）が「今このPCにログインしているのは誰か」を把握し、通信情報と紐付けて監視サーバーに送信します。

この方式の考慮点

アプローチ2：デバイス管理基盤（MDM）との連携

エージェントを確実に配布するために、MDM（Mobile Device Management） と呼ばれるデバイス管理基盤を導入する企業が増えました。

会社支給のPCであれば、初回起動時に自動でMDMに登録され、必要なエージェントも自動インストールされる仕組みを構築できます。

この方式の考慮点

アプローチ3：クラウドアクセス監視基盤（CASB）の導入

「通信経路で観測できないなら、クラウドサービス側で観測すればいい」という発想から生まれたのが、CASB（Cloud Access Security Broker） です。

CASBには主にAPI連携型とProxy型、そしてそれらを組み合わせたハイブリッド型があります。

CASBは一般に「可視化（Visibility）」「データセキュリティ」「脅威防御」「コンプライアンス」の4つの柱で語られることが多く、クラウド利用の統制において重要な役割を果たしています。

この方式の考慮点

アプローチ4：ネットワーク全体のクラウド化（SASE/SSE/ZTNA）

「分散した観測点を、クラウドサービスとして再集約しよう」という思想から生まれたのが、SASE（Secure Access Service Edge） です。

SASEは、ネットワーク機能（SD-WANなど）とセキュリティ機能（SWG/CASB/ZTNA/DLPなど）を統合したクラウドサービスです。セキュリティ機能側だけを指す場合は SSE（Security Service Edge） と呼ばれることもあります。HTTPのプッシュ送信のSSEとちょっと紛らわしいですが。

また、ZTNA（Zero Trust Network Access） は、「社内ネットワーク」という概念を前提とせず、アプリ単位でアイデンティティとコンテキストに基づいてアクセスを仲介するアプローチです。

このアプローチでは、すべてのアクセスがクラウド上のセキュリティ基盤を経由します。「社内」「社外」という区別をなくし、どこからのアクセスも同じように検証するという考え方です。

この方式の考慮点

第6章：振り返り ― シンプルさの価値

2つのアプローチの比較

さていろいろみてきましたが、

ここで改めて、ＡＤをつかったアプローチと、ＡＤを使わないクラウド時代でいろいろがんばるアプローチ、2つのアプローチを比較してみましょう。

重要な前提として、これは「古い vs 新しい」という対比ではありません。

閉域網中心のアプローチは今も多くの企業で現役であり、特にセキュリティ要件が厳格な環境では引き続き協力で有効な選択肢です。

クラウド対応のために構成を拡張するかどうかは、あくまで各企業のビジネス要件次第です。

複雑になればなるほど、運用の難易度は上がります。シンプルな構成の価値は、今も変わっていません。

なぜ構成が拡張されてきたのか

多くの企業で構成が拡張されてきた背景には、繰り返しこの記事でふれていますが、ビジネス要件の変化があります。

仕事のやり方がテクノロジーとともに進化すると、効率化の観点、もっと楽にやりたいという観点などで、いろんな現場の要求があがってきます

そうなると、セキュリティ側としてもそうした現場要求に最大限応えつつもセキュリティもしっかり、というジレンマが発生し、その結果として今の複雑な状況につながっているのかもしれません。

結論：シンプルさという価値を忘れずに

どちらのアプローチを選ぶにせよ、以下のことは認識しておくべきではないでしょうか。

セキュリティの世界では、シンプルさは価値です。

複雑なものは運用が難しく、設定ミスも起きやすく、コストも高くつきます。

閉域網 + AD + Proxyという構成が示す「観測点を集約できる筋の良さ」は、今も有効なアプローチです。

クラウド対応で構成を拡張する場合でも、この「筋の良さ」を参照点として、必要最小限の複雑さに留める意識を忘れないようにしたいと思います。

おわりに：LLM時代のセキュリティを考える

さて、ここまで企業セキュリティの歴史を振り返ってきましたが、実は私たちQualitegも、まさにこの「シンプルさ」と「観測点の集約」を大切にしながらLLM時代のセキュリティに取り組んでいます。

そうした中で、ChatGPTやClaudeといった生成AIサービスへの情報漏洩対策として、私たちは LLM-Audit というソリューションを開発・提供しています。このLLM-Auditは、まさにこの記事で紹介したAD+ MITM方式（Proxy型） を選択することが可能です。（ほかの連携方法もあります）

AD+Proxy型は導入がシンプル

AD + Proxyという「観測点を集約できる」アーキテクチャの場合、こうしたAIセキュリティの実装がもっともシンプルになり、かつモレが少なくて強力です。エージェントを全端末に配布する複雑さを避け、Proxy経由で通信を監視することで、「誰が」「何を」AIに送信したかを把握できます。

Proxy型が有効な条件と、そうでない領域

この記事にあるとおりProxy型（MITM方式）にも適用条件があります。本記事内容の復習を兼ねてまとめますと、以下のようになります。

だからこそ、優先順位の設計が重要になります。「すべてを監視する」のではなく、「業務で使う管理端末からのLLMアクセスを確実に統制する」という形で、現実的なスコープを定めることが大切です。

さて、この記事で解説したActive DirectoryとProxyの統合については、私たちの技術ブログでより詳しく解説していますので、そちらもご参照いただけますと、Proxy方式の理解が深まると思います

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第1回 基本概念の理解

こんにちは！ 今回から数回にわたり Active Directory について解説してまいります。 Active Directory（AD:アクティブディレクトリー）は、Microsoft が開発したディレクトリサービスであり、今日の大企業における IT インフラストラクチャーにおいて、もはやデファクトスタンダードと言っても過言ではない存在となっており、組織内のユーザー、コンピューター、その他のリソースを一元的に管理するための基盤として広く採用されています。 AIセキュリティの現実：単独では機能しない ChatGPTやClaudeなどの生成AIが企業に急速に普及する中、「AIセキュリティ」という言葉が注目を集めています。情報漏洩の防止、不適切な利用の検知、コンプライアンスの確保など、企業が取り組むべき課題は山積みです。 しかし、ここで注意しなければいけない事実があります。それは、 AIセキュリティソリューションは、それ単体では企業環境で限定的な効果しか期待できない ということです。 企業が直面する本質的な課題 AIセキュリティツールを導入する際、企業のIT部門

Qualiteg BlogQualiteg コンサルティング

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第2回 ドメイン環境の構築

こんにちは、今回はシリーズ第２回ドメイン環境の構築 - 検証環境の構築手順について解説いたします！ 連載の構成 第1章：基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎 【★今回です★】第2章：ドメイン環境の構築 - 検証環境の構築手順 第3章：クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順 第4章：プロキシサーバーと統合Windows認証 第5章：ブラウザ設定と認証 - 各ブラウザでの設定方法 第6章：トラブルシューティング - よくある問題と解決方法 第7章：セキュリティとベストプラクティス - 本番環境での考慮事項 第8章：実践的な構成例 - AIセキュリティツールとの統合事例 第2章：ドメイン環境の構築 2.1 ドメイン名の設計 2.1.1 ドメイン名の命名規則 Active Directoryを構築する際、

Qualiteg BlogQualiteg AIセキュリティチーム

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第3回 クライアントとサーバーのドメイン参加

こんにちは、今回はシリーズ第３回クライアントとサーバーのドメイン参加について解説いたします！ はじめに こんにちは！シリーズ第3回「クライアントとサーバーのドメイン参加」へようこそ。 前回（第2回）では、Active Directoryドメイン環境の構築手順について、ドメインコントローラーのセットアップからDNS設定まで詳しく解説しました。ドメイン環境の「土台」が整ったところで、今回はいよいよ実際にコンピューターをドメインに参加させる手順に進みます。 「ドメインユーザーアカウントを作ったのに、なぜかログインできない」「新しいPCを追加したけど、ドメイン認証が使えない」といった経験はありませんか？実は、Active Directoryの世界では、ユーザーアカウントを作成しただけでは不十分で、そのユーザーが使用するコンピューター自体もドメインに「参加」させる必要があるのです。 本記事では、このドメイン参加について、単なる手順の説明にとどまらず、「なぜドメイン参加が必要なのか」「裏側で何が起きているのか」という本質的な仕組みまで、初心者の方にも分かりやすく解説していきます。Win

Qualiteg BlogQualiteg AIセキュリティチーム

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第4回 プロキシサーバーと統合Windows認証

11月に入り、朝晩の冷え込みが本格的になってきましたね。オフィスでも暖房を入れ始めた方も多いのではないでしょうか。 温かいコーヒーを片手に、シリーズ第4回「プロキシサーバーと統合Windows認証」をお届けします。 さて、前回（第3回）は、クライアントPCやサーバーをドメインに参加させる際の「信頼関係」の確立について深掘りしました。コンピューターアカウントが120文字のパスワードで自動認証される仕組みを理解いただけたことで、今回のプロキシサーバーの話もスムーズに入っていけるはずです。 ChatGPTやClaudeへのアクセスを監視する中間プロキシを構築する際、最も重要なのが「確実なユーザー特定」です。せっかくHTTPS通信をインターセプトして入出力内容を記録できても、アクセス元が「tanaka_t」なのか「yamada_h」なのかが分からなければ、監査ログとしての価値は半減してしまいます。 今回は、プロキシサーバー自体をドメインメンバーとして動作させることで、Kerberosチケットの検証を可能にし、透過的なユーザー認証を実現する方法を詳しく解説します。Windows版Squid

Qualiteg BlogQualiteg AIセキュリティチーム

さて、最後に、
複雑さと戦い続ける、すべてのセキュリティ担当者の皆さまにエールを送りつつ、この記事を終わりたいと思います。本記事がご参考になりますと幸いです。