大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第5回ブラウザ設定と認証

Qualiteg コンサルティング

2026年2月17日 — 16 min read

こんにちは、今回はシリーズ第5回「ブラウザ設定と認証」について解説いたします！

さて、前回（第4回）では、プロキシサーバーをドメインに参加させることで、ChatGPTやClaudeへのアクセスを「誰が」行ったかを確実に特定する仕組みを解説しました。「信頼の連鎖」の概念や、Windows版Squidなら1時間で構築できる環境、Negotiate/NTLM/Basicという3段階の認証フォールバック機構について理解いただけたかと思います。

しかし、せっかくサーバー側で完璧な統合Windows認証環境を構築しても、ブラウザ側の設定が適切でなければ、ユーザーには毎回パスワード入力ダイアログが表示されてしまいます。

「Edgeだと自動でログインできるのに、Chromeだとパスワードを聞かれる」
「同じサーバーなのにURLの書き方で動作が違う」

これらはヘルプデスクに寄せられる典型的な問い合わせです。（ただ、業務に好きなブラウザ使っていいよ、という企業はそんなに多くはないとおもいます）

今回は、統合Windows認証がブラウザでどのように動作するのか、その仕組みから各ブラウザ（Edge/Chrome/Firefox）での具体的な設定方法、そしてグループポリシーによる一括管理まで詳しく解説します。特に「イントラネットゾーン」という概念を理解することで、なぜ認証動作が変わるのかが腑に落ちるはずです。

それでは、エンドユーザーにストレスを与えない、シームレスな認証環境の構築に挑戦していきましょう！

連載の構成

第1章：基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎
第2章：ドメイン環境の構築 - 検証環境の構築手順
第3章：クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順
第4章：プロキシサーバーと統合Windows認証
【★今回です★】第5章：ブラウザ設定と認証 - 各ブラウザでの設定方法
第6章：トラブルシューティング - よくある問題と解決方法
第7章：セキュリティとベストプラクティス - 本番環境での考慮事項
第8章：実践的な構成例 - AIセキュリティツールとの統合事例

第5章：ブラウザ設定と認証

5.1 統合Windows認証の動作条件

5.1.1 イントラネットゾーンの概念

統合Windows認証が自動的に動作するかどうかは、アクセス先がどの「セキュリティゾーン」に属するかによって決まります。これは、多くのユーザーが混乱するポイントです。

まずは、現場でよくある「なんで？」という声から始めましょう。

同じサーバーにアクセスしているはずなのに、URLの書き方が違うだけで認証動作が変わってしまう。この不思議な現象、実は「セキュリティゾーン」という仕組みが原因なのです。

【なぜ自動認証されたりされなかったりするのか】
田中：「同じサーバーなのに、アクセス方法で動作が違う？」

ケース1：
田中：「http://fileserver/ にアクセス」
ブラウザ：「イントラネットゾーンだ。自動認証OK」
結果：パスワード入力なしでアクセス成功

ケース2：
田中：「http://192.168.1.20/ にアクセス」（同じサーバー）
ブラウザ：「IPアドレスか...インターネットゾーンとして扱う」
結果：認証ダイアログが表示される

田中：「同じサーバーなのになんで！？」

では、この「セキュリティゾーン」とは何でしょうか？Windowsには、アクセス先の信頼度に応じて4つのゾーンが定義されています。この仕組みはInternet Explorer時代に設計されましたが、現在も「インターネットオプション」としてWindowsに残っており、Edgeの動作にも影響を与えています。つまり、Windows環境でブラウザ認証を理解するには、この古くからある仕組みを避けて通れないのです。

【Windowsのセキュリティゾーン】
IT管理者：「Windowsには4つのセキュリティゾーンがあり、EdgeやChromeの認証動作に影響します」

1. インターネットゾーン（最も制限が厳しい）
   - 一般的な外部Webサイト
   - 統合Windows認証は無効

2. イントラネットゾーン（社内向け）
   - 社内サーバー
   - 統合Windows認証が有効

3. 信頼済みサイト
   - 明示的に信頼したサイト
   - カスタム設定可能

4. 制限付きサイト
   - 危険なサイト
   - 最も厳しい制限

新人：「どうやって判定してるんですか？」

では、ブラウザはどうやって「これはイントラネットだ」と判定しているのでしょうか？

実は、いくつかの明確なルールが存在します。このルールを知っておくと、「なぜこのURLだと認証ダイアログが出るのに、別のURLだと出ないのか」という疑問がスッキリ解消されます。特に、ドット（.）の有無やIPアドレスかどうかが重要な判定基準になっている点に注目してください。

【自動判定の仕組み】
ブラウザの判定ロジック：

1. ドット（.）を含まない名前
   http://server01/ → イントラネット ✓
   http://server01.jp.qualiteg.com/ → 判定が微妙

2. NetBIOS名
   http://fileserver/ → イントラネット ✓
   
3. UNCパス
   \\server01\share → イントラネット ✓

4. プロキシをバイパスするサイト
   プロキシ例外リストに含まれる → イントラネット ✓

5. IPアドレス
   http://192.168.1.20/ → インターネット ✗
   （ただし、設定で変更可能）

「理屈は分かったけど、実際に自分のアクセス先がどのゾーンに判定されているか確認したい」という方も多いでしょう。残念ながら、現在のEdgeにはゾーンを直接表示する機能がありませんが、いくつかの方法で確認することができます。トラブルシューティングの際にも役立つので、覚えておくと便利です。

【どのゾーンか確認する方法】
方法1：インターネットオプションで確認
コントロールパネル → インターネットオプション → セキュリティタブ
→ 各ゾーンの「サイト」ボタンで登録されているサイトを確認

方法2：イントラネットゾーンの自動判定設定を確認
インターネットオプション → セキュリティ → ローカルイントラネット → サイト
□ イントラネットのネットワークを自動的に検出する
□ プロキシサーバーを使用しないサイトをすべて含める
□ すべてのネットワークパス(UNC)を含める

方法3：レジストリで確認（上級者向け）
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap
→ 各サイトがどのゾーンに属するか確認可能

5.1.2 URLの形式による認証動作の違い

同じサーバーでも、URLの書き方によって認証動作が変わります。これは、システム管理者でも見落としがちな重要なポイントです。

「同じサーバーなのになぜ？」という疑問をさらに深掘りしてみましょう。実際に、同一のファイルサーバーに対して4種類の異なるURL形式でアクセスした場合、それぞれどのような認証動作になるかを実験してみます。この違いを理解しておくと、ユーザーからの「なぜ認証を求められるのか」という問い合わせに的確に回答できるようになります。

【URL形式と認証の関係】
実験：同じファイルサーバーに異なるURLでアクセス

1. NetBIOS名でアクセス
URL: http://fs01/share
ブラウザ：「イントラネットゾーン。Kerberosで自動認証」
結果：シームレスにアクセス

2. FQDNでアクセス
URL: http://fs01.jp.qualiteg.com/share
ブラウザ：「ドットが含まれる...でもローカルドメイン」
結果：設定次第（デフォルトは認証ダイアログ）

3. IPアドレスでアクセス
URL: http://192.168.1.50/share
ブラウザ：「IPアドレスはインターネットゾーン」
結果：認証ダイアログ表示

4. 外部ドメイン名でアクセス
URL: http://fs01.external.com/share
ブラウザ：「外部ドメイン。インターネットゾーン」
結果：認証ダイアログ（統合認証は無効）

ここで、なぜIPアドレスでのアクセスだと認証がうまくいかないのか、技術的な背景を説明しておきましょう。これはKerberos認証の仕組みに起因しています。Kerberosは「サービスの名前」でチケットを発行する仕組みのため、IPアドレスという「番号」ではチケットを要求できないのです。この制約を知っておくと、「なぜ名前でアクセスしてください」とユーザーにお願いするのか、その理由を説明できるようになります。

【なぜIPアドレスではKerberosが使えないか】
IT管理者：「Kerberosにはサーバーの『名前』が必要なんです」

Kerberosの仕組み：
1. クライアント：「HTTP/fs01.jp.qualiteg.com のチケットください」
2. KDC（Key Distribution Center）：「SPN（Service Principal Name）を検索...」
3. KDC：「見つかった！チケット発行」

IPアドレスの場合：
1. クライアント：「HTTP/192.168.1.50 のチケットください」
2. KDC：「そんなSPNは登録されてない」
3. 結果：Kerberos失敗 → NTLMにフォールバック

開発者：「だからIPアドレスだと遅いんだ...」

さて、ここまででゾーンの概念とURLの関係を理解いただけたかと思います。次に、実際の各ブラウザがどのように動作するかを確認しましょう。同じ社内サイトにアクセスしても、ブラウザによって「すんなり入れる」「パスワードを聞かれる」と動作が異なります。これは各ブラウザの設計思想の違いによるもので、特にChromeとFirefoxはデフォルトで統合認証が無効になっている点に注意が必要です。

【各ブラウザでの動作】
テストシナリオ：http://intranet/ にアクセス

Microsoft Edge:
- インターネットオプションの設定を継承
- イントラネットゾーンなら統合Windows認証が自動実行
- 基本的に追加設定不要

Google Chrome:
- デフォルトでは認証ダイアログが表示
- グループポリシーまたは起動オプションで設定が必要
- --auth-server-whitelist="*.jp.qualiteg.com"

Mozilla Firefox:
- デフォルトでは認証ダイアログが表示
- about:config での設定が必要
- network.negotiate-auth.trusted-uris

Edge（IEモード）:
- レガシーな社内システム向けの互換機能
- 完全なIE互換が必要な場合のみ使用
- 通常のEdgeで問題なければ不要

5.1.3 ブラウザごとの設定方法

各ブラウザで統合Windows認証を有効にする具体的な設定方法を見ていきましょう。

まずはMicrosoft Edgeから。EdgeはMicrosoftが開発しているだけあって、Windowsとの親和性が高く、多くの場合は追加設定なしで統合Windows認証が動作します。Edgeは「インターネットオプション」の設定を継承するため、Windowsの設定が正しければそのまま使えるのが大きなメリットです。ただし、念のため設定を確認しておきたい場合や、期待通りに動作しない場合のチェックポイントを押さえておきましょう。

【Microsoft Edgeの設定】
最も簡単 - 多くの場合、デフォルトで動作

Edgeはインターネットオプションの設定を継承するため、
Windowsの設定が正しければ追加設定は不要です。

確認手順：
1. コントロールパネル → インターネットオプション
2. セキュリティタブ
3. 「ローカル イントラネット」を選択
4. 「レベルのカスタマイズ」

重要な設定項目：
- ユーザー認証
  └ログオン
    ○ イントラネット ゾーンでのみ自動的にログオンする ← デフォルト
    ○ 現在のユーザー名とパスワードで自動的にログオンする
    ○ ユーザー名とパスワードを入力してログオンする

IT管理者：「通常はデフォルトのままでOKです」

Edgeの追加設定（必要な場合）：
edge://settings/profiles/sync → 仕事用プロファイルの確認
edge://policy/ → 適用されているポリシーの確認

次はGoogle Chromeです。Chromeは社内でも利用者が多いブラウザですが、統合Windows認証についてはデフォルトで無効になっています。そのため、「Chromeだと毎回パスワードを聞かれる」という問い合わせがヘルプデスクに殺到することも珍しくありません。設定方法は複数ありますが、企業環境ではグループポリシーでの一括設定が最も効率的です。テスト目的であれば、起動オプションやレジストリ編集でも対応可能です。

【Google Chromeの設定方法】
問題：
ユーザー：「Chromeだと毎回パスワード聞かれる！」
IT管理者：「Chromeは追加設定が必要です」

方法1：グループポリシー（推奨）
場所：コンピューターの構成 → 管理用テンプレート → 
      Google → Google Chrome → 認証

設定項目：
1. 統合Windows認証を許可するサーバーのリスト
   値：*.jp.qualiteg.com, intranet

2. Kerberos委任を許可するサーバーのリスト
   値：*.jp.qualiteg.com

GPO適用後：
gpupdate /force
Chrome再起動

方法2：レジストリ直接編集
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"AuthServerAllowlist"="*.jp.qualiteg.com"
"AuthNegotiateDelegateAllowlist"="*.jp.qualiteg.com"

方法3：起動オプション（テスト用）
chrome.exe --auth-server-whitelist="*.jp.qualiteg.com" 
          --auth-negotiate-delegate-whitelist="*.jp.qualiteg.com"

Firefoxユーザーも忘れてはいけません。開発者やデザイナーを中心に、Firefoxを愛用している方は一定数いらっしゃいます。Firefoxの場合は、about:configという設定画面で直接パラメータを編集する必要があります。少し上級者向けの操作になりますが、一度設定してしまえば快適に使えるようになります。なお、企業環境では後述するグループポリシーや設定ファイルの配布で一括設定することも可能です。

【Mozilla Firefoxの設定方法】
Firefoxユーザー：「Firefoxでも統合認証使いたい」
IT管理者：「about:configで設定します」

手順：
1. アドレスバーに about:config 入力
2. 警告を承諾
3. 以下の設定を検索・編集

必要な設定：
network.negotiate-auth.trusted-uris
値：.jp.qualiteg.com, intranet

network.negotiate-auth.delegation-uris  
値：.jp.qualiteg.com

network.automatic-ntlm-auth.trusted-uris
値：.jp.qualiteg.com, intranet

補足設定：
network.negotiate-auth.allow-non-fqdn
値：true（NetBIOS名を許可）

network.automatic-ntlm-auth.allow-non-fqdn
値：true

確認：
設定後、Firefoxを再起動して http://intranet/ にアクセス
→ パスワード入力なしでアクセスできれば成功

最後に、Edgeの詳細設定とIEモードについても触れておきましょう。「基本的に追加設定不要」と説明しましたが、細かい制御が必要な場合や、レガシーな社内システムとの互換性が必要な場合は、グループポリシーやIEモードを活用することになります。特にIEモードは、古いActiveXコントロールを使用するシステムなど、最新のEdgeでは動作しないアプリケーション向けの機能です。新規システムでは使用する必要はありませんが、移行期間中は重宝する場面もあるでしょう。

【Microsoft Edgeの詳細設定とIEモード】
Edge利用者：「EdgeでもChromeと同じような設定はあるの？」
IT管理者：「はい、グループポリシーで細かく制御できます」

Edgeのポリシー設定：
edge://policy/ で確認できる設定：
- AuthServerAllowlist（認証サーバーの許可リスト）
- AuthNegotiateDelegateAllowlist（Kerberos委任の許可リスト）

グループポリシーでの設定：
コンピューターの構成 → 管理用テンプレート → 
Microsoft Edge → HTTP認証

IEモード（レガシーシステム向け）：
古い社内システムがEdgeで正常動作しない場合のみ使用

設定方法：
1. IEモードサイトリストを作成（XML形式）
   <site url="legacy.jp.qualiteg.com">
     <open-in>IE11</open-in>
   </site>

2. グループポリシーで配布
   - IEモードを有効化
   - サイトリストのURL指定

注意：IEモードは互換性のための機能です。
新しいシステムでは通常のEdgeを使用してください。

5.2 Chrome/Firefoxでの課題と対策

5.2.1 なぜChromeでは自動認証が動作しないか

ChromeやFirefoxでデフォルトで統合Windows認証が動作しない理由は、セキュリティとクロスプラットフォーム対応にあります。

「なぜEdgeだと何もしなくても自動認証できるのに、Chromeだとダメなの？」——これは非常によくある疑問です。答えは、それぞれのブラウザの設計思想と開発元の違いにあります。MicrosoftはWindowsというOSも開発しているため、EdgeとWindowsは密接に連携するよう設計されています。一方、GoogleのChromeはWindows、Mac、Linuxなど複数のOSで動作することを前提に設計されているため、Windows固有の機能はオプション扱いになっているのです。

【根本的な理由】
開発者：「なんでEdgeは自動認証できて、Chromeはできないの？」
IT管理者：「それぞれの設計思想の違いです」

Microsoft Edge：
- Microsoftが開発
- Windowsと密結合
- 企業内利用を想定
- インターネットオプションを継承
- デフォルトで統合認証ON

Google Chrome：
- Googleが開発  
- クロスプラットフォーム（Windows/Mac/Linux）
- インターネット利用を前提
- Windows固有の設定に依存しない設計
- デフォルトで統合認証OFF

セキュリティ専門家：「デフォルトOFFの方が安全ではある」

実は、Chromeがデフォルトで統合認証を無効にしているのには、セキュリティ上の理由もあります。もし無条件で自動認証が有効だったら、悪意のあるサイトに対してもユーザーの認証情報（NTLMハッシュなど）を送信してしまう可能性があるのです。「面倒だな」と感じるかもしれませんが、これは意図的なセキュリティ設計であることを理解しておきましょう。

【なぜデフォルトで無効なのか】
シナリオ：悪意のあるサイトの場合

悪意のあるサイト：「私は intranet.evil.com です」

もしデフォルトで有効だったら：
ブラウザ：「intranetという名前...自動認証します」
ブラウザ→悪意のサイト：「私は JP\tanaka です」（NTLMハッシュ付き）
悪意のあるサイト：「認証情報ゲット！」

だから：
Chrome：「明示的に信頼されたサイトのみ自動認証」
ユーザー：「面倒だけど安全なのか...」

もう少し技術的な観点から、ブラウザのアーキテクチャの違いも見ておきましょう。EdgeはWindowsのWinINet/WinHTTP APIを使用しており、Windowsの認証サブシステムと直接連携しています。一方、Chromeは独自のネットワークスタックを持っており、Windows固有の機能を使うかどうかは明示的な設定に依存しています。これがコードレベルでどのような違いになるか、イメージで示してみます。

【ブラウザアーキテクチャの違い】
Edge の実装：
- WinINet/WinHTTP API を使用
- Windowsの認証サブシステムと直結
- SSPIを直接呼び出し
- インターネットオプションの設定を参照

Chromeの実装：
- 独自のネットワークスタック
- クロスプラットフォーム前提
- Windows固有機能はオプション扱い

具体例：
// Edgeの内部（イメージ）
if (IsIntranetZone(url)) {
    UseWindowsAuthentication();
}

// Chromeの内部（イメージ）  
if (IsInWhitelist(url) && IsPlatformWindows()) {
    UseWindowsAuthentication();
}

5.2.2 グループポリシーでの設定

企業環境では、グループポリシーを使用してChromeやEdgeの設定を一括管理するのが最も効率的です。

数台のPCであれば手動設定でも対応できますが、数十台、数百台となると現実的ではありません。Active Directory環境であれば、グループポリシー（GPO）を使って全社のPCに一括で設定を配布できます。一度設定してしまえば、新しいPCがドメインに参加した際も自動的に設定が適用されるため、運用負荷を大幅に削減できます。

まずは、Chromeのグループポリシー設定に必要なADMXテンプレートの準備から始めましょう。ADMXテンプレートとは、グループポリシーエディターでChrome固有の設定項目を表示するために必要なファイルです。GoogleがEnterprise Bundle として公開しているので、ダウンロードしてActive Directoryサーバーに配置します。

【GPO設定の準備】
IT管理者：「まず、Chrome用のADMXテンプレートが必要です」

手順：
1. GoogleのEnterprise Bundleをダウンロード
   https://chromeenterprise.google/browser/download/

2. ADMXファイルをコピー
   chrome.admx → C:\Windows\PolicyDefinitions\
   chrome.adml → C:\Windows\PolicyDefinitions\ja-JP\

3. グループポリシー管理エディターで確認
   コンピューターの構成 → 管理用テンプレート → Google → Google Chrome
   
IT管理者：「これで準備完了」

※Edge用のADMXテンプレートも同様に入手可能
   https://www.microsoft.com/ja-jp/edge/business/download

ADMXテンプレートの準備ができたら、実際に認証関連のポリシーを設定していきましょう。主に設定するのは「統合Windows認証を許可するサーバーのリスト」と「Kerberos委任を許可するサーバーのリスト」の2つです。ワイルドカード（*.jp.qualiteg.com）を使うことで、サブドメインも含めて一括で許可できます。

【認証関連のポリシー設定】
グループポリシー管理エディターで設定：

■ Chrome の設定
パス：Google Chrome → 認証

1. 認証サーバーの許可リスト
設定名：統合Windows認証を許可するサーバーのリスト
値：
*.jp.qualiteg.com
intranet
intranet.jp.qualiteg.com
*.internal.jp.qualiteg.com

2. Kerberos委任の許可リスト
設定名：Kerberos委任を許可するサーバーのリスト
値：*.jp.qualiteg.com

■ Edge の設定（必要な場合）
パス：Microsoft Edge → HTTP認証

同様の設定項目が用意されています。
Edgeはインターネットオプションを継承するため、
通常は追加設定不要です。

確認コマンド：
gpresult /h report.html
→ 適用されたポリシーを確認

GPOを設定したら、実際にユーザーのPCに適用されるまでの流れを確認しておきましょう。通常、グループポリシーはバックグラウンドで定期的に更新されますが、すぐに反映させたい場合はgpupdate /forceコマンドを実行します。ユーザーにとっては、「昨日までパスワードを聞かれていたのに、今日はスムーズにアクセスできる」という体験になります。

【GPO適用後の動作】
翌朝、ユーザーのPC：
田中：「いつも通りChromeを起動」
Chrome：「グループポリシーを読み込み中...」
Chrome：「*.jp.qualiteg.comは信頼済みサイトとして登録」

田中：「http://intranet/ にアクセス」
Chrome：「このサイトは許可リストに含まれる」
Chrome：「統合Windows認証を実行」
結果：パスワード入力なしでアクセス成功！

田中：「あれ？昨日まで聞かれてたのに...IT部門が何かしたな」

GPOを設定したはずなのに反映されない、というケースも時々発生します。そんな時のためのトラブルシューティング手順を押さえておきましょう。まずはブラウザのポリシー確認ページ（chrome://policy/ や edge://policy/）で、設定が実際に適用されているかを確認します。適用されていない場合は、OUの構造、GPOのリンク、セキュリティフィルタリングなどを順番にチェックしていきます。

【GPOが適用されない場合】
確認手順：

1. クライアントPCでポリシー確認
Chrome: chrome://policy/
Edge: edge://policy/
→ 設定されたポリシーが表示される

2. 未適用の場合
gpupdate /force
→ グループポリシーを強制更新

3. それでもダメなら
- OU構造の確認（PCが正しいOUに所属？）
- GPOのリンク確認
- セキュリティフィルタリング確認
- WMIフィルター確認

4. ブラウザのログ確認
Chrome: chrome://net-export/
Edge: edge://net-export/
→ ネットワークログをキャプチャ
→ 認証関連のエラーを検索

5.2.3 Basic認証の課題（パスワード保存）

統合Windows認証が使えない環境では、Basic認証にフォールバックしますが、これには独自の課題があります。

在宅勤務やBYOD（私物デバイス）の普及により、ドメインに参加していないPCから社内システムにアクセスするケースが増えています。このような環境では統合Windows認証が使えないため、Basic認証（ユーザー名とパスワードを入力する方式）にフォールバックすることになります。ここで問題になるのが、ブラウザの「パスワードを保存する」機能です。

【Basic認証の動作】
在宅勤務の山田：「自宅のPCからプロキシ経由でアクセス」
プロキシ：「認証が必要です」
Chrome：「統合認証は使えない...Basic認証のダイアログ表示」

認証ダイアログ：
┌─────────────────────────┐
│ proxy.jp.qualiteg.com:8080 でユーザー名と │
│ パスワードが必要です                      │
│                                          │
│ ユーザー名: [JP\yamada_h        ]        │
│ パスワード: [****************    ]        │
│                                          │
│ □ パスワードを保存する                    │
└─────────────────────────┘

山田：「毎回入力は面倒...保存しちゃえ」

「パスワードを保存する」は便利な機能ですが、企業のセキュリティポリシー上は大きなリスクとなります。特に、共用PCでの認証情報の漏洩、ブラウザの同期機能による意図しないクラウドへのアップロード、マルウェアによるパスワード窃取など、複数のリスクシナリオが考えられます。これらのリスクを具体的に見ていきましょう。

【保存されたパスワードの問題】
セキュリティ監査：「Basic認証のパスワード保存は危険です」

リスク1：共用PCでの漏洩
営業A：「客先のPCでパスワード保存」
営業B：「同じPCを使用...前の人のアカウントでアクセスできる！」

リスク2：ブラウザの同期機能
個人のGoogleアカウントで同期ON
→ 会社のパスワードが個人のクラウドに保存
→ 自宅のPCにも同期される

リスク3：マルウェアによる窃取
chrome://settings/passwords
edge://settings/passwords
→ 保存されたパスワードが見える
→ マルウェアが収集する標的に

では、組織としてどのような対策を講じればよいでしょうか？技術的な制限、プロキシ側の設定、代替認証方式の提供など、複数のアプローチがあります。グループポリシーでパスワード保存機能自体を無効化するのが最も確実ですが、ユーザビリティとのバランスも考慮する必要があります。

【パスワード保存を防ぐ方法】
方法1：技術的な制限（グループポリシー）
Chrome GPO：
パスワード管理ツールを有効にする → 無効

Edge GPO：
パスワードの保存を有効にする → 無効

結果：パスワード保存オプションが表示されない

方法2：プロキシ側の設定
# 短いセッションタイムアウト
auth_param basic credentialsttl 30 minutes
→ 頻繁に再認証が必要 = 保存の意味が薄い

方法3：代替認証方式の提供
- VPN + 統合認証
- クライアント証明書
- ワンタイムパスワード

5.2.4 実用的な解決策

現実的な運用では、セキュリティと利便性のバランスを取った解決策が必要です。

「すべてのアクセスを統合Windows認証で」というのが理想ですが、現実にはリモートワークの常態化、個人デバイスの利用増加、多様なブラウザ環境など、様々な制約があります。そこで重要になるのが、アクセス元の環境に応じて認証方式を使い分ける「段階的なアプローチ」です。

【段階的なアプローチ】
IT部門の方針：
「理想」と「現実」のギャップを埋める

理想：すべて統合Windows認証
現実：
- 個人デバイスの利用増加
- リモートワークの常態化  
- 多様なブラウザ利用

段階的解決策：
1. 社内ネットワーク → 統合認証（GPO強制）
2. VPN接続 → 統合認証（可能な限り）
3. 外部アクセス → 別の認証方式

具体的に、プロキシサーバー側でどのように認証方式を使い分けるかの設定例を見てみましょう。社内ネットワークからのアクセスには統合認証を、外部からのアクセスにはHTTPS必須のBasic認証を適用するという構成です。これにより、社内ユーザーの利便性を確保しつつ、外部アクセスのセキュリティも担保できます。

【認証方式の使い分け】
プロキシ設定例：
# 社内ネットワークからのアクセス
acl internal_network src 192.168.0.0/16
acl internal_network src 10.0.0.0/8

# 認証方式の定義
# 1. 統合認証（社内向け）
auth_param negotiate program /usr/lib/squid/negotiate_wrapper_auth
auth_param negotiate children 10

# 2. Basic認証（外部向け、HTTPS必須）
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic realm "External Access - HTTPS Required"

# アクセス制御
# 社内：統合認証
http_access allow internal_network authenticated

# 外部：HTTPSでのみBasic認証許可
acl HTTPS proto HTTPS
http_access allow HTTPS authenticated
http_access deny !HTTPS

技術的な対策と同様に重要なのが、ユーザーへの教育です。どんなに優れたセキュリティ対策も、ユーザーが適切に利用しなければ効果を発揮しません。IT部門からの明確なガイドラインを提示し、なぜそのルールが必要なのかを理解してもらうことが大切です。

【セキュリティ意識向上の取り組み】
IT部門からの通知：

件名：Chrome/Edge/Firefoxでの認証についてのお知らせ

1. 社内PCでの利用
   - IT部門が設定済み
   - パスワード入力不要
   - そのままご利用ください

2. 個人PC/在宅勤務での利用
   - VPN接続を推奨
   - やむを得ずBasic認証を使用する場合：
     * パスワードを保存しない
     * HTTPSのサイトのみアクセス
     * 定期的にパスワード変更

3. セキュリティのヒント
   - 共用PCでは絶対に保存しない
   - ブラウザの同期機能に注意
   - 不審な認証要求は IT部門に報告

問い合わせ：IT部門（内線: 1234）

より高度な対策として、IT部門公認のブラウザ拡張機能を活用する方法もあります。企業が開発または選定した拡張機能を使うことで、認証情報を暗号化して安全に管理できます。ただし、拡張機能自体のセキュリティ審査や、ユーザーへの展開方法など、運用面での考慮事項も多いため、導入には十分な検討が必要です。

【ブラウザ拡張機能の活用】
IT部門公認の拡張機能：

1. 認証情報管理拡張
- 企業が開発/選定
- ローカルで暗号化保存
- マスターパスワードで保護

実装例（概念）：
chrome.webRequest.onAuthRequired.addListener(
  function(details, callback) {
    // 信頼されたサイトか確認
    if (isTrustedSite(details.url)) {
      // 暗号化されたストレージから認証情報取得
      const creds = getEncryptedCredentials(details.url);
      callback({
        authCredentials: {
          username: creds.username,
          password: decrypt(creds.password)
        }
      });
    }
  },
  {urls: ["<all_urls>"]},
  ["asyncBlocking"]
);

2. SSO連携拡張
- SAMLやOAuth連携
- 別の認証基盤を利用

最後に、将来を見据えた対策についても触れておきましょう。パスワードに関する問題を根本的に解決するには、パスワードレス認証への移行が有効です。Windows Hello for Business、FIDO2/WebAuthn、証明書ベース認証など、複数の選択肢があります。すぐに全社展開するのは難しいかもしれませんが、パイロットユーザーでの検証から始めて、段階的に移行していく計画を立てておくことをお勧めします。

【パスワードレス認証への移行】
IT戦略会議：
CTO：「パスワード関連の問題を根本的に解決したい」
セキュリティ担当：「パスワードレス認証を検討しましょう」

選択肢：
1. Windows Hello for Business
   - 生体認証やPIN
   - Kerberosチケット取得
   - パスワード不要

2. FIDO2/WebAuthn
   - セキュリティキー使用
   - フィッシング耐性
   - クロスプラットフォーム

3. 証明書ベース認証
   - クライアント証明書
   - スマートカード
   - 管理は複雑

移行計画：
Phase 1：パイロットユーザーで検証
Phase 2：IT部門で本格導入  
Phase 3：全社展開

CTO：「3年後にはパスワードを廃止したい」

これらの対策により、Edge/Chrome/Firefoxユーザーも安全かつ便利に認証を利用できるようになります。重要なのは、技術的な対策だけでなく、ユーザー教育と段階的な移行計画です。

今回のまとめ

第5回では、統合Windows認証がブラウザでどのように動作するかを解説しました。

「イントラネットゾーン」という概念を理解することで、同じサーバーでもURLの書き方（NetBIOS名、FQDN、IPアドレス）によって認証動作が変わる理由が明確になったかと思います。また、Chrome/Firefoxではデフォルトで統合認証が無効になっている理由（セキュリティとクロスプラットフォーム対応）と、グループポリシーによる一括設定方法も学びました。

次回予告：第6章トラブルシューティング - よくある問題と解決方法

次回は、統合Windows認証環境で発生しがちなトラブルとその解決方法を詳しく解説します！

「Kerberosが失敗してNTLMにフォールバックする」「時刻が5分ずれただけで認証できない」「SPNって何？どう設定するの？」「ドメインが見つからないエラーが出る」——これらは現場で必ず遭遇する問題です。

診断コマンドの使い方から、DNS・SPN・時刻同期といった根本原因の特定方法、そして具体的な解決手順まで、実践的なトラブルシューティングガイドをお届けします。

それでは、第6回でお会いしましょう！

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第5回ブラウザ設定と認証

Qualiteg コンサルティング

連載の構成

第5章：ブラウザ設定と認証

5.1 統合Windows認証の動作条件

5.1.1 イントラネットゾーンの概念

5.1.2 URLの形式による認証動作の違い

5.1.3 ブラウザごとの設定方法

5.2 Chrome/Firefoxでの課題と対策

5.2.1 なぜChromeでは自動認証が動作しないか

5.2.2 グループポリシーでの設定

5.2.3 Basic認証の課題（パスワード保存）

5.2.4 実用的な解決策

今回のまとめ

次回予告：第6章トラブルシューティング - よくある問題と解決方法

Read more

スライドパズルを解くAIから学ぶ、「考える」の正体

楽観的ロック vs 悲観的ロック：実際のトラブルから学ぶ排他制御

企業セキュリティはなぜ複雑になったのか？〜AD+Proxyの時代から現代のクラウド対応まで〜

【IT温故知新】WS-* の栄光と黄昏：エンタープライズITはいかにして「実装」に敗北したか

連載の構成

第5章：ブラウザ設定と認証

5.1 統合Windows認証の動作条件

5.1.1 イントラネットゾーンの概念

5.1.2 URLの形式による認証動作の違い

5.1.3 ブラウザごとの設定方法

5.2 Chrome/Firefoxでの課題と対策

5.2.1 なぜChromeでは自動認証が動作しないか

5.2.2 グループポリシーでの設定

5.2.3 Basic認証の課題（パスワード保存）

5.2.4 実用的な解決策

今回のまとめ

次回予告：第6章 トラブルシューティング - よくある問題と解決方法

Read more

スライドパズルを解くAIから学ぶ、「考える」の正体

楽観的ロック vs 悲観的ロック：実際のトラブルから学ぶ排他制御

企業セキュリティはなぜ複雑になったのか？ 〜AD+Proxyの時代から現代のクラウド対応まで〜

【IT温故知新】WS-* の栄光と黄昏：エンタープライズITはいかにして「実装」に敗北したか

次回予告：第6章トラブルシューティング - よくある問題と解決方法

企業セキュリティはなぜ複雑になったのか？〜AD+Proxyの時代から現代のクラウド対応まで〜