Apache Webサーバー構築とTLS/HTTPSセキュリティ【202試験 主題2.09】



LinuCレベル2（202試験）の主題2.09「Webサービスとプロキシ（Apache）」では、オープンソースのWebサーバーとして世界中で採用されている Apache HTTP Server（httpd） の内部アーキテクチャ、基本ディレクティブの構文規則、アクセス制御、バーチャルホスト、およびTLS/HTTPSによる暗号化通信の構築技術が出題範囲に指定されています。

特にLinuC試験では、Apache 2.2系からApache 2.4系への移行に伴って刷新された「アクセス制御構文（Order/Allow/Deny から Require への変更）」や、公開鍵暗号基盤（OpenSSL）を用いた証明書・秘密鍵の生成手順、mod_ssl ディレクティブの割り当てが最頻出ポイントです。本記事では、AlmaLinux 9.8の実機環境に Apache 2.4.62 および OpenSSL 3.5.5 を導入し、設定ファイルのスコープ制御からHTTPS通信の確立までを実機検証ログとともに体系的に解説します。

1. Apache HTTP Serverのアーキテクチャと基本設定#

Apache HTTP Serverは、モジュール構造を採用した高機能なWebサーバーです。基本機能に加えて必要な拡張モジュール（mod_*.so）を動的ロード（DSO: Dynamic Shared Object）することで、柔軟なサーバー構成を実現します。

図1: Apache 2.4 ディレクティブスコープとアクセス制御の評価順序

1.1 Webサーバーの役割とMPM（Multi-Processing Module）#

クライアント（ブラウザ）から送信されるHTTPリクエスト（GET, POST等）を並行処理する基盤エンジンが MPM（Multi-Processing Module） です。LinuC 202試験では以下の3大MPMの特性比較が出題されます。

1.2 httpd.conf の基本構造と主要グローバルディレクティブ#

AlmaLinuxやRHEL系における主設定ファイルは /etc/httpd/conf/httpd.conf です（Debian/Ubuntu系では /etc/apache2/apache2.conf）。サーバー全体の動作を決定する主要ディレクティブは以下の通りです。

1.3 ディレクティブスコープ（<Directory>, <Files>, <Location>）#

特定のリソースに対して個別のアクセス権限やオプションを適用する「コンテナディレクティブ（スコープ）」の使い分けは試験の頻出分野です。

1.4 apachectl による設定構文検査とサービス制御#

Apacheの制御および構文検査には、管理用CLIツール apachectl（または httpd コマンド）を使用します。

• apachectl configtest（または apachectl -t）: httpd.conf および conf.d/*.conf の構文エラーを検査します。
• apachectl graceful: 処理中の接続を切断することなく、安全に設定ファイルを再読み込みします（無停止リロード）。
• apachectl status: mod_status が有効な場合、稼働ワーカー数やリクエスト処理状況を表示します。

2. Apache 2.4におけるアクセス制御と認証#

Apache 2.4系では、アクセス制御の記述方式が抜本的に変更されました。LinuC 202試験の合否を左右する重要ポイントです。

2.1 AllowOverride ディレクティブと .htaccess の制御#

各ディレクトリに配置された分散設定ファイル .htaccess による設定の上書きを許可するか否かを指定するのが AllowOverride です。

• AllowOverride None: .htaccess を完全に無視します。ディスクI/Oを抑制してWebサーバーの性能を最大化する本番環境の推奨設定です。
• AllowOverride All: .htaccess 内のすべてのディレクティブ記述を許可します。
• AllowOverride AuthConfig: ユーザー認証関連ディレクティブ（AuthType, Require 等）の上書きのみを許可します。
• AllowOverride Indexes: ディレクトリ一覧表示の制御（Options +Indexes 等）のみを許可します。

2.2 mod_authz_core による Require ディレクティブ構文#

Apache 2.2系で使用されていた Order allow,deny および Allow from all / Deny from all は非推奨となり、Apache 2.4系では mod_authz_core が提供する Require ディレクティブに一本化されました。

さらに複合的な条件判定を行う場合、論理コンテナディレクティブを使用します。

• <RequireAll> ... </RequireAll>: 内部に記述された条件の「すべて」に一致する場合のみアクセスを許可（AND条件）。
• <RequireAny> ... </RequireAny>: 内部に記述された条件の「いずれか1つ」に一致すればアクセスを許可（OR条件・既定の挙動）。

2.3 htpasswd によるBasic認証の実装#

特定ディレクトリに対してID・パスワードによる認証を要求するBasic認証は、htpasswd コマンドと以下のディレクティブで構築します。

# パスワードファイルの初期作成（-c オプションで新規生成）
[user01@linuc-node01 ~]$ sudo htpasswd -c /etc/httpd/.htpasswd webadmin
New password:
Re-type new password:
Adding password for user webadmin

# httpd.conf 内のディレクティブ記述
<Directory "/var/www/html/admin">
    AuthType Basic
    AuthName "Restricted Admin Area"
    AuthUserFile "/etc/httpd/.htpasswd"
    Require valid-user
</Directory>

3. バーチャルホストによる複数Webサイトの集約#

1台のサーバーハードウェア（単一のhttpdデーモン）上で、複数の異なるドメイン名やWebサイトを並行稼働させる技術が バーチャルホスト（VirtualHost） です。

3.1 名前ベース（Name-based）バーチャルホスト#

単一のIPアドレスとポート番号（80番）を共有しながら、ブラウザから送信されるHTTPリクエストヘッダ内の Host: ヘッダ情報を識別してコンテンツを振り分ける方式です。IPv4アドレスを浪費しないため、現代のWeb運用の主流となっています。

<VirtualHost *:80>
    ServerName siteA.example.com
    ServerAlias www.siteA.example.com
    DocumentRoot "/var/www/siteA"
    ErrorLog "logs/siteA_error_log"
    CustomLog "logs/siteA_access_log" combined
</VirtualHost>

<VirtualHost *:80>
    ServerName siteB.example.com
    DocumentRoot "/var/www/siteB"
    ErrorLog "logs/siteB_error_log"
    CustomLog "logs/siteB_access_log" combined
</VirtualHost>

3.2 IPベース（IP-based）バーチャルホスト#

ホストOSに複数のネットワークインターフェース（またはIPエイリアス）を割り当て、接続先IPアドレスごとにサイトを分離する方式です。<VirtualHost 192.168.2.10:80> のように特定のIPアドレスを明示します。

4. OpenSSLとmod_sslによるTLS/HTTPS通信の構築#

Web通信の盗聴や改ざん、なりすましを防ぐため、TLS（Transport Layer Security）による通信暗号化をApacheに組み込む手順を整理します。

図2: OpenSSLによるTLSサーバー証明書の発行フローとmod_ssl設定

4.1 公開鍵暗号基盤（PKI）とTLSハンドシェイクの流れ#

HTTPS通信の確立（TLSハンドシェイク）では、ハイブリッド暗号方式が採用されています。

4.2 OpenSSLコマンドによる秘密鍵・CSR・自己署名証明書の生成#

LinuC 202試験では、暗号化通信に必要なファイル群を生成する OpenSSLコマンド の構文が頻出します。

実機環境において、秘密鍵と自己署名証明書を一括生成した検証ログです。

[user01@linuc-node01 ~]$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout /etc/pki/tls/private/localhost.key \
  -out /etc/pki/tls/certs/localhost.crt \
  -subj "/C=JP/ST=Tokyo/L=Chiyoda/O=ExampleCorp/CN=linuc-node01.example.com"

[user01@linuc-node01 ~]$ sudo apachectl configtest
Syntax OK

4.3 mod_ssl の設定とディレクティブ#

ApacheでTLSを有効化するには mod_ssl モジュールを導入し、/etc/httpd/conf.d/ssl.conf にて以下のディレクティブを定義します。

実機環境で起動したApacheに対して curl でHTTPS通信テストを実行したログです（自己署名証明書のため -k オプションで証明書検証をスキップ）。

[user01@linuc-node01 ~]$ curl -k -I https://localhost/
HTTP/1.1 403 Forbidden
Date: Mon, 07 Sep 2026 00:45:17 GMT
Server: Apache/2.4.62 (AlmaLinux) OpenSSL/3.5.5
Last-Modified: Mon, 24 Mar 2025 16:15:24 GMT
ETag: "1680-63118e9567f00"
Accept-Ranges: bytes
Content-Length: 5760
Content-Type: text/html; charset=UTF-8

5. ログ管理とパフォーマンスチューニング#

Webサーバーのアクセス傾向分析やトラブルシューティング、高負荷耐性の向上のためのログ設計および持続的接続制御を整理します。

5.1 LogFormat と CustomLog によるアクセスログ設計#

Apacheのアクセスログは、LogFormat ディレクティブで定義された書式文字列に従って記録されます。標準フォーマットである combined 形式の指定子を整理します。

5.2 KeepAlive による持続的接続の最適化#

Webページを表示する際、HTML本体だけでなく多数の画像やCSS、JavaScriptファイルが読み込まれます。リソースごとに毎回TCP 3ウェイハンドシェイクを繰り返すオーバーヘッドを抑制する機構が KeepAlive（持続的接続） です。

• KeepAlive On: 単一のTCP接続上で複数のHTTPリクエストを連続処理することを許可します。
• MaxKeepAliveRequests <回数>: 1回の持続的接続で処理を許可する最大リクエスト数（例: 100）。0 を指定すると無制限となります。
• KeepAliveTimeout <秒数>: 同一接続上で次のリクエストが到着するまでの待機時間（秒）。値を大きくしすぎるとアイドル状態の接続がプロセス・スレッドを占有し、新規接続を受け付けられなくなるリスクがあります。

6. LinuC 202試験（主題2.09）重要ポイント総整理#

主題2.09「Webサービスとプロキシ（Apache）」における記述式問題（コマ問）頻出コマンドおよび新旧構文の対比を整理します。

6.1 記述式（コマ問）頻出コマンド・ディレクティブ一覧#

6.2 Apache 2.2系と2.4系のアクセス制御構文対比#

過去問や古い解説書を解く際に混乱しやすい変更点を整理します。

7. まとめと次回予告（第12回：Nginx & Squidプロキシ）#

本記事では、LinuCレベル2（202試験）におけるWebサービスの基盤であるApache HTTP Serverについて、MPMアーキテクチャ、基本ディレクティブ、ディレクティブスコープ、Apache 2.4のRequireアクセス制御、名前ベースバーチャルホスト、およびOpenSSLとmod_sslによるセキュアなTLS/HTTPS環境の構築手順を実機ログとともに体系的に整理しました。

Webサーバーの構築は、設定構文の正確さに加えて、証明書発行やパーミッション管理など総合的なLinuxインフラ運用スキルが求められます。実機でコマンドラインから秘密鍵を生成し、ブラウザやcurlで検証した実体験が、試験本番のコマ問記述において迷いのない回答を可能にします。

次回（第12回）は、近年の高負荷Webサービスでデファクトスタンダードとなっているイベント駆動型軽量Webサーバー Nginx と、企業ネットワークの帯域節約・アクセス制御を担うプロキシサーバー Squid を取り上げます。リバースプロキシによる負荷分散やキャッシュ制御、クライアントプロキシのアクセスフィルタリングを実機検証していきます。

リンク