【Squid講座 第3回】「誰？」を識別せよ！Basic認証とDigest認証によるユーザー管理完全ガイド

「IPアドレス」は嘘をつくことがある。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、IPアドレスを使ったアクセス制御（ACL）を学びました。これで「社外の人は通さない」という基本的な守りは完成しました。

でも、それだけで十分でしょうか？
例えば、社員が勝手にIPアドレスを変更したら？ ノートPCを持って会議室（別のIP帯）に移動したら？
IPアドレスだけでは、「今アクセスしているのが本当に『田中さん』なのか」までは特定できません。

本記事では、Squidにおけるユーザー認証の仕組みから、認証用データベース（パスワードファイル）の作成、そして実務で遭遇するトラブルシューティングまでを、コマンド実例付きで完全解説します。

---

第1章：認証プロキシの仕組みと種類

構築を始める前に、認証方式の違いを理解しておきましょう。
Squidは主に以下の認証方式に対応しています。

1. Basic（ベーシック）認証

最も古くからある、最もシンプルな方式です。
ほぼ全てのブラウザやツールが対応していますが、「IDとパスワードを平文（Base64エンコードのみ）で送信する」という致命的な弱点があります。
ネットワークを盗聴されるとパスワードが即バレますが、設定が簡単なので、社内LANなどの閉じた環境では今でも主流です。

2. Digest（ダイジェスト）認証

Basic認証の弱点を克服した方式です。
パスワードをそのまま送るのではなく、「ハッシュ値（暗号化された文字列）」に変換して送信します。
盗聴されてもパスワードそのものは漏れません。
セキュリティを重視する場合はこちら推奨されます。

---

第2章：必要なツールのインストール

認証用のパスワードファイルを作成するために、Apache HTTP Serverに含まれるツール（htpasswd）を使います。
Squid自体にはパスワード生成機能がないため、このツールを借ります。

httpd-toolsのインストール

AlmaLinuxなどのRHEL系OSの場合、以下のコマンドでインストールします。

sudo dnf install httpd-tools -y

インストール後、htpasswd コマンドが使えるか確認してください。

htpasswd -h

---

第3章：【実践】Basic認証の実装手順

それでは、まずは基本となるBasic認証を設定してみましょう。

ステップ1：パスワードファイルの作成

ユーザー「user01」を作成し、パスワードを設定します。
ファイルは /etc/squid/passwd に保存することにします。

# 初回作成時（-c オプションをつける）
sudo htpasswd -c /etc/squid/passwd user01

# パスワードを聞かれるので2回入力します。

2人目以降を追加する場合は、-c オプションを外します（付けると上書きして消えてしまいます！）。

# 2人目の追加
sudo htpasswd /etc/squid/passwd user02

作成できたら、Squidが読み取れるように権限を設定しておきます。

sudo chown squid:squid /etc/squid/passwd
sudo chmod 640 /etc/squid/passwd

ステップ2：認証プログラムの場所を確認

Squidには、認証を行うための「ヘルパープログラム」が同梱されています。
RHEL/AlmaLinux 9の場合、以下の場所にあります。

/usr/lib64/squid/basic_ncsa_auth

念のため、存在するか確認しましょう。

ls -l /usr/lib64/squid/basic_ncsa_auth

ステップ3：squid.confの設定

いよいよSquidの設定です。
sudo nano /etc/squid/squid.conf を開き、以下の設定を追記します。
追記場所はファイルの先頭付近（ACL定義の前）が見やすくておすすめです。

# --- Basic認証設定 開始 ---

# 1. 認証プログラムの指定
# auth_param [認証方式] program [ヘルパーパス] [パスワードファイル]
auth_param basic program /usr/lib64/squid/basic_ncsa_auth /etc/squid/passwd

# 2. 同時実行プロセス数（同時アクセスが多い場合は増やす）
auth_param basic children 5

# 3. 認証ダイアログに表示されるメッセージ
auth_param basic realm Squid Proxy Server

# 4. 認証の有効期限（一度認証したら2時間は再入力不要）
auth_param basic credentialsttl 2 hours

# --- Basic認証設定 終了 ---

ステップ4：ACLの設定と適用

認証機能を有効にしただけでは動きません。
「認証に成功した人」というグループ（ACL）を作り、それを許可する必要があります。

squid.conf のACL定義エリア（acl localnet ...などの下）に追記します。

# "authenticated" という名前で、認証必須のACLを定義
acl authenticated proxy_auth REQUIRED

そして、http_access ルールの一番上（deny allより前）に適用します。
※注意：ローカルネット許可（http_access allow localnet）よりも上に書かないと、社内からのアクセスで認証が求められません。

# 認証済みユーザーのみ許可
http_access allow authenticated

# その他の許可ルール（必要に応じて削除またはコメントアウト）
# http_access allow localnet

設定が終わったら、再起動します。

sudo systemctl restart squid

動作確認

ブラウザで任意のサイトにアクセスしてください。
ユーザー名とパスワードを求めるポップアップが表示されましたか？
作成した user01 でログインできれば成功です！

アクセスログ（/var/log/squid/access.log）を見ると、これまで - だった部分にユーザー名が記録されているはずです。

1705482345.123 ... 192.168.1.5 ... user01 ...

---

第4章：【実践】Digest認証の実装手順

次は、よりセキュアなDigest認証に切り替えてみましょう。
Basic認証の設定はいったんコメントアウトしてください。

ステップ1：Digest用パスワードファイルの作成

Digest認証には htpasswd ではなく htdigest コマンドを使います。
書式が少し異なります。

書式： htdigest -c [ファイル名] [レルム] [ユーザー名]

# Digest用ファイルの作成
sudo htdigest -c /etc/squid/passwd_digest "Squid Proxy Server" user01

パスワードを入力して作成完了です。
権限設定も忘れずに。

sudo chown squid:squid /etc/squid/passwd_digest
sudo chmod 640 /etc/squid/passwd_digest

ステップ2：squid.confの設定

Basic認証の部分を以下のように書き換えます。
ヘルパープログラムの名前が digest_file_auth に変わる点に注意してください。

# --- Digest認証設定 開始 ---

auth_param digest program /usr/lib64/squid/digest_file_auth /etc/squid/passwd_digest
auth_param digest children 5
auth_param digest realm Squid Proxy Server
auth_param digest nonce_garbage_interval 5 minutes
auth_param digest nonce_max_duration 30 minutes
auth_param digest nonce_max_count 50

# --- Digest認証設定 終了 ---

ACLの設定（acl authenticated proxy_auth REQUIRED）や http_access はBasic認証と同じでOKです。
変更不要です。

動作確認

再起動後、ブラウザでアクセスして認証ダイアログが出ればOKです。
見た目はBasic認証と変わりませんが、裏側ではパスワードが暗号化されて飛んでいます。

---

第5章：現場で役立つチューニングと運用ノウハウ

設定はできましたが、実際に運用を始めると色々な問題が出ます。
プロが調整するポイントを紹介します。

1. プロセス数（children）の調整

auth_param basic children 5

これは「認証処理を行うヘルパープログラムをいくつ起動しておくか」という設定です。
デフォルトの「5」は、小規模なオフィスなら十分ですが、社員が100人以上いて一斉にアクセスすると、認証待ちが発生してネットが遅くなります。
アクセスログに WARNING: All basicauth processes are busy. と出ていたら、数を増やしてください（例：20〜50）。

2. 有効期限（credentialsttl）の罠

auth_param basic credentialsttl 2 hours

これは「一度パスワードを入れたら、どのくらいの間、再入力を免除するか」の設定です。
短すぎると「さっき入れたのにまた聞かれた！」とクレームになります。
長すぎると、退職した社員のアカウントを無効化しても、ブラウザを開きっぱなしならしばらく使えてしまいます。
通常は「2時間〜8時間（勤務時間分）」が適切です。

3. ログ活用による個人特定

認証プロキシの最大のメリットは「ログの可視化」です。
access.log をExcelなどで集計すれば、「誰が」「どのサイトを」「どれくらい見ているか」が一目瞭然になります。
これはセキュリティ監査だけでなく、「業務に関係ない動画サイトを見すぎて帯域を圧迫している犯人」を特定する際にも役立ちます。

---

第6章：トラブルシューティング

Q1. 正しいパスワードを入れても弾かれる！

A. パスワードファイルの権限を確認してください。
Squidの実行ユーザー（通常はsquid）が、/etc/squid/passwd を読み取れる権限を持っていますか？
sudo -u squid cat /etc/squid/passwd コマンドを打って、中身が表示できるかテストしてください。

A. Digest認証の場合、レルム不一致の可能性があります。
htdigest コマンドで指定したレルム文字列と、squid.conf の realm 文字列は、一言一句（スペースまで）同じでなければなりません。

Q2. 何度も認証ダイアログが出る（無限ループ）

A. ブラウザがパスワードを記憶できていない可能性があります。
シークレットモードを使っていませんか？
また、Active Directory連携などをしている場合、時計がズレていると認証に失敗することがあります。

---

まとめ：「誰が」を握れば管理は楽になる

お疲れ様でした！
今回は、セキュリティレベルを一気に引き上げる「ユーザー認証」を実装しました。

今回の重要ポイント：

• IP制限だけでは不十分。ID/Pass認証で個人を特定する。
• 社内なら手軽なBasic、社外を通るならDigest（またはSSL）。
• パスワードファイルの権限と所有者に注意。
• children パラメータで認証負荷を分散させる。

これで、あなたのプロキシサーバーは「顔パス」を許さない、厳格な関所となりました。
しかし、最近のWebサイトはほとんどが HTTPS（SSL化） されています。
実は、今の設定のままでは、HTTPSサイトにアクセスした時にプロキシが中身を見ることができず、十分な制御ができません。

次回、第4回は「暗号化通信の制御！HTTPSとSSL接続の仕組み」です。
プロキシにおける最大の難所、SSLデコード（SSLバンピング）の仕組みと、CONNECTメソッドによるトンネリングについて解説します。
ここを理解すれば、脱・初心者間違いなしです！