PostgreSQLの初期インストールを終えた直後、多くのエンジニアが「ローカルからは接続できるのに、別のWebサーバーや管理端末から接続できない」というトラブルに直面します。PostgreSQLでは、安全性を担保するためにデフォルトで外部からの通信が遮断されています。外部通信を許可し、セキュアなアクセス制御を構築するためには、postgresql.confとpg_hba.confという2大設定ファイルの役割と構文を正確に理解する必要があります。
本記事の到達目標
postgresql.confとpg_hba.confの責務の違いと正確な配置場所を説明できる。listen_addressesとOSファイアウォール（firewalld）を設定し、外部通信を確立できる。pg_hba.confの5大フィールドの構造と、上から順に評価されるルールを理解してSCRAM認証を設定できる。pg_settingsビューのcontextを確認し、設定変更時にリロード（reload）で済むか再起動（restart）が必要かを判断できる。
検証環境情報
- ホストOS：AlmaLinux 10.2 (Lavender Lion) x86_64
- DBサーバーノード：alma-db01 (IP: 192.168.2.132 / PostgreSQL 18.6 PGDG)
- クライアントノード：alma-proxy (IP: 192.168.2.121 / psql クライアント)
目次
1. 2大設定ファイルの役割分担と配置場所
1.1 postgresql.conf と pg_hba.conf の本質的な違い
PostgreSQLの動作環境は、主に2つの設定ファイルによって制御されます。両者の役割を混同せず明確に区別することがトラブル回避の鍵となります。
- postgresql.conf（サーバー動作設定）：データベースエンジン全体の振る舞いを決定するファイルです。どのIPアドレス・ポートで接続を待ち受けるか（
listen_addresses,port）、メモリをどれだけ確保するか（shared_buffers,work_mem）、ログをどのように記録するか（logging_collector,log_line_prefix）など、サーバー自体のスペックや動作方針を定義します。 - pg_hba.conf（ホストベース認証制御）：クライアントからの接続要求に対するアクセス権限を制御するファイルです（HBAはHost-Based Authenticationの略語）。接続元のIPアドレス、アクセス先のデータベース名、ログインを試みるユーザー名に基づいて、接続を許可するか、どの認証方式（パスワード暗号化方式など）を要求するかを判定します。
1.2 PGDG版とAppStream版でのファイル配置パスの確認
第2回で解説した通り、インストールしたリポジトリの系統によって設定ファイルの格納場所が異なります。稼働中のPostgreSQLにSQLを発行することで、現在読み込まれている設定ファイルの絶対パスを正確に取得できます。
$ sudo -u postgres /usr/pgsql-18/bin/psql -c "SHOW config_file;" -c "SHOW hba_file;"
config_file
----------------------------------------
/var/lib/pgsql/18/data/postgresql.conf
hba_file
------------------------------------
/var/lib/pgsql/18/data/pg_hba.confPGDG公式RPM版では/var/lib/pgsql/18/data/配下に格納され、AppStream版では/var/lib/pgsql/data/配下に配置されます。設定変更を行う際は、自身が運用している環境のデータディレクトリを必ず確認してください。
2. postgresql.conf の基本設計：通信待ち受けとログ基盤
2.1 外部接続を許可する listen_addresses と port の設定
PostgreSQLの初期状態では、listen_addressesパラメータに'localhost'（ループバックアドレス）のみが設定されています。この状態では、サーバー自身（127.0.0.1やUNIXドメインソケット）からの接続しか受け付けず、外部からのTCP通信はOSレベルで接続拒否されます。
外部のアプリケーションサーバーや管理端末からのアクセスを受け付けるには、対象のネットワークインターフェースを指定します。
# すべてのネットワークインターフェースで接続を受け付ける設定
listen_addresses = '*'
# ポート番号（標準は5432）
port = 5432重要ポイント：文字列パラメータのクォート指定
postgresql.confにおいて文字列を指定する際は、必ずシングルクォート（’）で囲む必要があります。ダブルクォート（”）を使用すると構文エラー（syntax error）と判定され、サービスの起動に失敗します。
2.2 パスワード暗号化方式（password_encryption）とSCRAM-SHA-256
password_encryptionは、CREATE USERやALTER USERでパスワードを設定した際に、システムカタログ（pg_authid）へ保存するハッシュアルゴリズムを決定します。
- scram-sha-256（標準・推奨）：RFC 5802およびRFC 7677に準拠した強固な認証方式です。サーバーとクライアントの間で平文パスワードはもちろん、パスワードハッシュそのものもネットワーク上に流さずに認証を完結させるため、盗聴や中継者攻撃に対して高い耐性を持ちます。
- md5（非推奨）：過去のバージョンで広く使われていましたが、暗号学的な脆弱性が指摘されており、現代のセキュリティ基準では使用を避けるべき方式です。
PostgreSQL 14以降では、デフォルトでscram-sha-256が有効化されています。
2.3 運用障害を防ぐ基本ログ設計
障害発生時の原因究明や監査を行うため、運用開始前に最低限のログ出力パラメータを設定しておきます。
# ログ収集プロセスの有効化
logging_collector = on
# ログ出力先ディレクトリ（データディレクトリ配下のlog）
log_directory = 'log'
# ログファイルの命名規則（日次ローテーション）
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
# ログ行の接頭辞（時刻、プロセスID、ユーザー名、DB名）
log_line_prefix = '%m [%p] %u@%d '2.4 パラメータ変更の反映スコープ（context）の完全体系化
postgresql.confに記述されたパラメータは、変更を有効化するための手順が内部プロパティ「context」によって明確に分類されています。本番稼働中に不用意な再起動を避け、かつ設定漏れを防ぐために、主要な分類を整理します。
| コンテキスト（context） | 反映に必要な操作 | 既存接続への影響 | 代表的なパラメータ例 |
|---|---|---|---|
| postmaster | DBサービスの完全再起動（restart） | 全セッションが一時切断される | listen_addresses, port, shared_buffers, max_connections |
| sighup | 設定ファイルのリロード（reload） | セッションを切断せず即時反映 | log_line_prefix, work_mem（デフォルト値）, logging_collector |
| superuser | セッション内でSET実行（特権ロール限定） |
自セッションのみ変更 | log_min_messages, session_preload_libraries |
| user | セッション内でSET実行（全一般ロール可能） |
自セッションのみ変更 | work_mem, statement_timeout, search_path |
| internal | 変更不可（初期化時またはビルド時に固定） | 変更不可 | block_size, wal_block_size, data_checksums |
設定ファイルを直接編集してリロードする前に、構文エラーや不正な値が混入していないかを検証するには、PostgreSQL 10以降で提供されているシステムビュー pg_file_settings を活用します。
-- 設定ファイルの構文検証とエラー検出クエリ
SELECT sourcefile, sourceline, name, setting, error
FROM pg_file_settings
WHERE error IS NOT NULL;編集後に上記クエリを実行し、error列が空（0行）であることを確認してからSELECT pg_reload_conf();を実行することで、設定ミスによるリロード失敗を未然に防ぐ運用が確立できます。
2.5 includeディレクティブによる設定ファイルの分割管理
大規模な本番運用では、1つの巨大なpostgresql.confにすべてのパラメータを詰め込むのではなく、機能単位や環境単位でファイルを分割する「モジュール化設計」が有効です。
推奨される設定分割パターン（conf.dディレクトリの導入）
# /var/lib/pgsql/18/data/postgresql.conf の最末尾に追記
include_dir = 'conf.d'データディレクトリ配下にconf.dディレクトリを作成し、目的別に設定ファイルを分割配置します。
01_network.conf：listen_addresses,port,max_connections02_memory.conf：shared_buffers,work_mem,maintenance_work_mem03_logging.conf：logging_collector,log_directory,log_line_prefix04_wal.conf：wal_level,max_wal_size,checkpoint_timeout
アルファベット順に読み込まれるため、プレフィックスに数値を付与して読み込み優先度を制御します。AnsibleやTerraformなどの構成管理ツールと連携する際にも、差分管理をシンプルに維持できます。
3. pg_hba.conf の構文規則と認証方式の整理
3.1 5大フィールドの構造と読み方
pg_hba.confは、1行に以下の5つのフィールドをスペースまたはタブ区切りで記述します。
| フィールド | 指定可能な値の例 | 説明 |
|---|---|---|
| TYPE | local, host, hostssl |
接続種別。localはUNIXドメインソケット、hostはTCP/IP（平文またはSSL）、hostsslはSSL暗号化通信に限定。 |
| DATABASE | all, appdb, replication |
対象のデータベース名。allはすべてのDB、カンマ区切りで複数指定可能。 |
| USER | all, postgres, appuser, +group |
接続を試行するロール名。+を付与すると指定ロールの所属メンバー全体に適用。 |
| ADDRESS | 127.0.0.1/32, 192.168.2.0/24 |
接続元クライアントのIPアドレスをCIDR記法で指定（localの場合は不要）。 |
| METHOD | scram-sha-256, peer, reject |
適用する認証方式。 |
3.2 認証方式（METHOD）のセキュリティ比較
設定可能な主要認証方式の特徴を把握します。
- peer（ローカル専用）：クライアントを実行しているLinuxのOSユーザー名と、接続先のPostgreSQLロール名が一致している場合に認証をパスします。ローカル端末での管理者運用（
sudo -u postgres psql）で多用されます。TCP/IP接続（host）には使用できません。 - scram-sha-256（ネットワーク推奨）：パスワードによるセキュア認証です。外部ノードからの通信にはこの方式を採用します。
- trust（危険）：パスワード検証を一切行わず、無条件で接続を許可します。開発環境であってもネットワーク経由の接続に
trustを設定することは重大な脆弱性となるため厳禁です。 - reject：条件に合致した接続要求を即座に明示拒否します。特定サブネットからのアクセスを遮断する用途で使用します。
3.3 評価順序の鉄則：上から順に最初のマッチで確定
pg_hba.confの最も重要なルールは、「ファイルの上から順に1行ずつ評価され、最初にすべての条件（TYPE, DATABASE, USER, ADDRESS）が合致した行の認証方式が適用される」という点です。
一度マッチした行が存在した場合、それより下にある行は一切評価されません。そのため、「特定の管理端末のみ許可し、同一サブネットの他端末は拒否する」といった制御を行う場合は、より条件の厳しい（限定的な）ルールを上に記述し、汎用的なルールを下側に配置する必要があります。
3.4 認証方式（METHOD）の技術仕様とセキュリティ強度比較
PostgreSQLがサポートする主要な認証方式について、実務設計で求められるセキュリティ強度と適用領域を整理します。
| 認証方式 | 暗号化レベル | パスワード送信 | 推奨利用用途 |
|---|---|---|---|
| scram-sha-256 | 高（ソルト付きチャレンジレスポンス） | 送信しない（ハッシュも非送信） | Web/APサーバーからの通常接続、DBAリモート接続 |
| cert | 高（クライアントSSL証明書検証） | 不要（PKI証明書のDNで認証） | 金融・機密システム、無人バッチサーバー、常時暗号化通信 |
| peer | OS依存（カーネルソケット認証） | 不要（OSユーザーUID/GID一致） | ローカルコンソール運用（postgresユーザーのsudo実行） |
| gss / ldap | 高（Active Directory / Kerberos統合） | 方式による（暗号化通信前提） | 社内統合認証基盤とのシングルサインオン（SSO） |
| md5 | 低（過去のハッシュ方式、脆弱性あり） | チャレンジレスポンス | 非推奨（レガシー互換用） |
| trust | なし（無条件全許可） | なし | 原則禁止（ローカルの一時初期化時を除く） |
3.5 CIDRサブネット設計の原則とプロキシ経由接続時の注意点
pg_hba.confで接続元アドレスを指定する際は、IPアドレスの範囲を無駄に広げず、必要最小限のサブネットに限定（最小権限の原則）します。
CIDRプレフィックス指定のベストプラクティス
- 単一ホスト指定：
192.168.2.121/32（特定のAPサーバー1台のみに許可）。 - 業務セグメント指定：
192.168.2.0/24（同一次階層の全APサーバーに許可）。 - 全開放（非推奨）：
0.0.0.0/0（インターネット全公開。パスワード総当たり攻撃の標的となるため厳禁）。
なお、PgBouncerやHAProxyなどのコネクションプーラーやリバースプロキシを介してPostgreSQLに接続する場合、PostgreSQL側から見える接続元IPアドレスはプロキシサーバーのIPアドレスになります。そのため、エンドユーザーの端末IPではなくプロキシサーバーのIPを指定してpg_hba.confを定義する必要があります。
4. 【実機検証】設定変更・反映とリモート接続テスト
実機環境（DBサーバー: alma-db01、クライアント: alma-proxy）を用いて、外部公開の設定変更、ファイアウォール開放、そして接続検証を実演します。
4.1 OSファイアウォール（firewalld）のポート開放
Linuxサーバーでは、PostgreSQLの設定だけでなく、OS側のファイアウォール（firewalld）でTCP 5432ポートを開放しなければ通信が届きません。
実行手順
- DBノード（alma-db01）でpostgresqlサービスをfirewalldに追加します。
- ファイアウォール設定をリロードして恒久反映します。
$ sudo firewall-cmd --add-service=postgresql --permanent
success
$ sudo firewall-cmd --reload
success
$ sudo firewall-cmd --list-services
cockpit dhcpv6-client postgresql sshpostgresqlサービスが許可リストに追加されたことを確認します。
4.2 設定反映手順：reload と restart の境界線
パラメータを変更した際、サービス再起動（systemctl restart）が必要か、即時リロード（systemctl reload）で反映できるかは、内部ビューpg_settingsのcontext列によって厳密に定義されています。
$ sudo -u postgres /usr/pgsql-18/bin/psql -c "SELECT name, setting, context FROM pg_settings WHERE name IN ('listen_addresses', 'port', 'log_line_prefix', 'work_mem');"
name | setting | context
------------------+-----------+------------
listen_addresses | localhost | postmaster
log_line_prefix | %m [%p] | sighup
port | 5432 | postmaster
work_mem | 4096 | user
- context = postmaster：ネットワークソケットのバインドや共有メモリの確保に関わるパラメータです。変更を適用するにはデータベースの再起動（systemctl restart）が必須です。稼働中の全セッションが一時切断されます。
- context = sighup：動作中に変更可能なパラメータです。サービス再起動を伴わないリロード（systemctl reload または SELECT pg_reload_conf();）で即座に反映されます。既存セッションを切断しません。
pg_hba.confの全ルールもこのsighupコンテキストに該当します。
4.3 リモートクライアントからの疎通確認と代表的エラーの読み解き
DBノード（alma-db01）にテスト用データベースとユーザーを作成し、クライアントノード（alma-proxy: 192.168.2.121）から接続テストを実施します。
# alma-db01 上でテスト用ユーザーとDBを作成
$ sudo -u postgres /usr/pgsql-18/bin/psql -c "CREATE USER appuser WITH PASSWORD 'SecureAppPass123';" -c "CREATE DATABASE appdb OWNER appuser;"
# pg_hba.conf に特定DB・特定ユーザーのルールを追加
# host appdb appuser 192.168.2.0/24 scram-sha-256
# 設定のリロード
$ sudo systemctl reload postgresql-18クライアントノードから以下の3つのシナリオを検証します。
# パターン1: 正常接続（許可されたDB・ユーザー・パスワード）
$ PGPASSWORD='SecureAppPass123' psql -h 192.168.2.132 -U appuser -d appdb -c "SELECT current_database(), current_user, inet_client_addr();"
current_database | current_user | inet_client_addr
------------------+--------------+------------------
appdb | appuser | 192.168.2.121
# パターン2: パスワード誤り（認証拒否）
$ PGPASSWORD='WrongPassword' psql -h 192.168.2.132 -U appuser -d appdb -c "SELECT 1;"
psql: エラー: "192.168.2.132"、ポート5432のサーバーへの接続に失敗しました: FATAL: ユーザー"appuser"のパスワード認証に失敗しました
# パターン3: pg_hba.conf にルールが存在しないDBへのアクセス試行
$ PGPASSWORD='SecureAppPass123' psql -h 192.168.2.132 -U appuser -d postgres -c "SELECT 1;"
psql: エラー: "192.168.2.132"、ポート5432のサーバーへの接続に失敗しました: FATAL: pg_hba.conf にホスト"192.168.2.121"、ユーザー"appuser"、データベース"postgres, 暗号化なし用のエントリがありませんパターン3のエラーメッセージFATAL: pg_hba.conf にホスト...用のエントリがありません（英語表記: FATAL: no pg_hba.conf entry for host ...）は、クライアントのIP、指定したDB、接続ユーザーの組み合わせに合致する行がpg_hba.conf内に見つからなかったことを明確に示しています。
運用上の注意点：安易な全開放の危険性
「とりあえず繋げるため」として、host all all 0.0.0.0/0 trustを記述する設定例を見かけることがありますが、これはインターネットや社内LANのあらゆる端末からパスワードなしで全データベースに管理者アクセスを許す行為です。必ずアクセス元のIPサブネットを絞り込み、scram-sha-256による認証を義務付けてください。
4.4 実機検証：pg_hba_file_rules ビューによる構文エラー事前検知
設定ファイルpg_hba.confにタイプミスや不正なCIDR表記が含まれている場合、リロード時に構文解析エラーが発生し、該当行のルールが無効化される危険があります。PostgreSQL 10以降では、システムビュー pg_hba_file_rules をクエリすることで、現在読み込まれているルールのパース結果とエラーの有無を一覧確認できます。
# pg_hba.conf のパース状態とエラー行の検証クエリ
$ sudo -u postgres /usr/pgsql-18/bin/psql -c "
SELECT line_number, type, database, user_name, address, auth_method, error
FROM pg_hba_file_rules
WHERE error IS NOT NULL;"
line_number | type | database | user_name | address | auth_method | error
-------------+------+----------+-----------+---------+-------------+-------
(0 行)もし誤って host all all 192.168.2.300/24 scram-sha-256 のような不正なIPアドレスを記述してリロードした場合、error列に「invalid IP address "192.168.2.300/24": invalid octet value」と明確に記録されます。本番環境への反映作業では、リロード直後に必ずこのビューを監査することが運用規範として推奨されます。
5. 実務トラブルシューティング事例集（3大障害シナリオと解決策）
アクセス制御やネットワーク設定において現場で最も頻発する3大障害シナリオと、その迅速な原因特定・解決手順を解説します。
5.1 シナリオ1：接続拒否エラー（FATAL: no pg_hba.conf entry）の原因特定
新規アプリケーションサーバーをデプロイした際、DB接続テストで最も目にするエラーが FATAL: no pg_hba.conf entry for host ... です。
クライアント側エラーログ
psql: エラー: "192.168.2.132"、ポート5432のサーバーへの接続に失敗しました: FATAL: pg_hba.conf にホスト"192.168.2.140"、ユーザー"web_user"、データベース"production_db", SSL無効用のエントリがありません原因の特定手順：エラーメッセージには、PostgreSQLサーバーが認識した「接続元IP（192.168.2.140）」「ユーザー名（web_user）」「DB名（production_db）」「SSL有無（SSL無効）」の4要素が完全に記載されています。
解決策チェックリスト
- 行のマッチング確認：
pg_hba.confに上記4条件をすべて網羅する行が存在するか確認します。 - 記述位置（ファーストマッチ）：許可ルールより上位に、該当クライアントを包括して拒否する
rejectルールが存在しないかを確認します。 - リロードの実行漏れ：ファイルを編集しただけで
systemctl reload postgresql-18を実行し忘れていないかを確認します。
5.2 シナリオ2：パスワード暗号化の不整合（md5保存とscram-sha-256接続の衝突）
過去バージョンからマイグレーションした環境や、password_encryptionの設定を変更した環境において、正しいパスワードを入力しているにもかかわらず認証が拒否される事象です。
パスワード認証エラー
FATAL: password authentication failed for user "legacy_user"
DETAIL: User "legacy_user" does not have a valid SCRAM secret.原因：pg_hba.confではscram-sha-256認証を要求しているのに対し、対象ロールのパスワードハッシュが古いmd5形式（pg_authid.rolpasswordがmd5...で始まる形式）で保存されているため、SCRAMチャレンジレスポンスの計算が成立しません。
解決手順
- スーパーユーザーでログインし、現在のハッシュ形式を確認します：
SELECT rolname, substring(rolpassword from 1 for 10) FROM pg_authid WHERE rolname = 'legacy_user'; -- 結果が md5... の場合は古いハッシュ形式 - 現在のセッションで
SET password_encryption = 'scram-sha-256';が有効であることを確認の上、パスワードを再設定します：ALTER USER legacy_user WITH PASSWORD 'NewSecurePass456'; - ハッシュが
SCRAM-SHA-256$...で再生成されたことを確認し、リモート接続を再試行します。
5.3 シナリオ3：OSファイアウォール・SELinuxによるポート5432通信遮断
postgresql.confでlisten_addresses = '*'を設定し、pg_hba.confも正しく記述したにもかかわらず、クライアントからConnection refusedやConnection timed outとなる障害です。
クライアント側エラーログ
psql: エラー: "192.168.2.132"、ポート5432のサーバーへの接続に失敗しました: 接続がタイムアウトしました
サーバーがホスト"192.168.2.132"で稼働しており、そのポートでTCP/IP接続を受け入れていることを確認してください原因切り分けフロー：エラーが「接続拒否（Connection refused）」か「タイムアウト（Connection timed out）」かで原因が分岐します。
- Connection timed out の場合：OSの
firewalldまたはクラウド/仮想化基盤のセキュリティグループでパケットが暗黙破棄（DROP）されています。前述のfirewall-cmd --add-service=postgresql --permanent && firewall-cmd --reloadでポート5432を開放します。 - Connection refused の場合：パケットは届いているが、OSがTCP RSTを返答しています。
ss -tulpn | grep 5432を実行し、PostgreSQLプロセスが0.0.0.0:5432（全IP）で待ち受けているか、誤って127.0.0.1:5432（ローカル専用）になっていないかを確認します。
6. 本番運用セキュリティ監査と完成形設定テンプレート
安全なデータベース運用を継続するために、インフラ設計者およびセキュリティ管理者が確認すべき監査チェックリストと、本番環境でそのまま適用できる実機設定テンプレートを整理します。
6.1 セキュリティ監査必須チェックリスト
セキュリティ監査必須チェック項目
- [ ]
postgresql.confのlisten_addressesは必要なネットワークのみに絞られているか（開発用PCへの不用意な直接開放がないか）。 - [ ]
pg_hba.confにtrust設定の行が一切存在しないこと（特にTCP/IP接続）。 - [ ] 外部からの全接続（
hostおよびhostssl）に対してscram-sha-256またはcert認証が強制されているか。 - [ ] スーパーユーザー（
postgres）のリモートログインがpg_hba.confで明示拒否（reject）またはローカル接続（peer）に限定されているか。 - [ ] レプリケーション用ロール（
replication）のアクセス元IPがスタンバイノードのCIDRに限定されているか。 - [ ]
pg_file_settingsおよびpg_hba_file_rulesにパースエラー行が残存していないか。
6.2 本番推奨の pg_hba.conf 完全定義テンプレート
最小権限の原則とファーストマッチ規則を正しく組み合わせた、実務で標準採用される設定ファイルの完成形です。
# ==============================================================================
# PostgreSQL Client Authentication Configuration File (pg_hba.conf)
# Production Security Baseline Template
# ==============================================================================
# 1. ローカル管理用接続（UNIXドメインソケット）
# OSのpostgresユーザーのみpeer認証でスーパーユーザー昇格を許可
local all postgres peer
local all all peer
# 2. スーパーユーザーのリモートログイン明示遮断
# 外部ネットワーク経由でのpostgresユーザー直接ログインを最上位で拒否
host all postgres 0.0.0.0/0 reject
host all postgres ::/0 reject
# 3. ストリーミングレプリケーション専用通信
# スタンバイノード（192.168.2.135）からの専用レプリケーション接続のみ許可
host replication repuser 192.168.2.135/32 scram-sha-256
# 4. アプリケーション業務接続
# Web/APセグメント（192.168.2.0/24）から業務DBへの接続をSCRAM認証で許可
host appdb appuser 192.168.2.0/24 scram-sha-256
# 5. ローカルホスト経由のTCP接続（ヘルスチェック等）
host all all 127.0.0.1/32 scram-sha-256
host all all ::1/128 scram-sha-256
# 6. 未定義の接続試行に対するデフォルト明示拒否
# ルールに合致しない全リモート通信を最末尾で遮断
host all all 0.0.0.0/0 reject
host all all ::/0 rejectこのように、「最上位で特権ロールのリモートログインを遮断」「中央で特定IP・特定DB・特定ロールを個別に許可」「最末尾で未許可トラフィックを全拒否」という3段防壁を構成することで、予期せぬアクセス経路を遮断し、堅牢な運用基盤を確立できます。
7. 本番想定 総合確認演習問題
実務の現場で直面する設定変更とアクセス制御の挙動を確認演習問題で点検します。
確認演習問題 1
以下の設定が記述されたpg_hba.confが存在する環境において、IPアドレス192.168.2.50を持つクライアント端末からユーザーappuserがデータベースproduction_dbへの接続を試みた場合、適用される認証方式として正しいものを1つ選択してください。
# 行1
host production_db all 192.168.2.0/24 scram-sha-256
# 行2
host all appuser 192.168.2.50/32 reject
# 行3
host all all 0.0.0.0/0 reject- 行2が合致するため、接続は直ちに拒否（reject）される。
- 行1が合致するため、SCRAM-SHA-256によるパスワード認証が要求される。
- 行3の全拒否ルールが優先され、エラーとなる。
- 定義が重複しているため構文エラーとなり、サービスが起動しない。
解答と解説を見る
正解： 2
解説：
pg_hba.confは上から順に走査され、最初に条件を満たした行で評価が確定します。
接続要求（DB: production_db, ユーザー: appuser, IP: 192.168.2.50）は、行1の条件（DBがproduction_db、ユーザーが全ユーザー、IPが192.168.2.0/24内）に完全に合致します。したがって、行1のscram-sha-256が採用され、行2以降の記述は無視されます。
もし192.168.2.50からのアクセスを拒否したい場合は、行2の特定拒否ルールを行1よりも上に記述しなければなりません。
確認演習問題 2
24時間365日稼働している本番データベースにおいて、クライアントセッションを切断させずに即時反映（reload）できるパラメータと、サービス停止・再起動（restart）を伴うパラメータの組み合わせとして正しいものを選択してください。
- リロード可能：
shared_buffers/ 再起動必須：log_line_prefix - リロード可能：
listen_addresses/ 再起動必須：work_mem - リロード可能：
log_line_prefix/ 再起動必須：listen_addresses - リロード可能：
max_connections/ 再起動必須：pg_hba.confの変更
解答と解説を見る
正解： 3
解説：
log_line_prefixのコンテキストはsighupであり、systemctl reloadやSELECT pg_reload_conf();によってセッションを切断することなく即座に反映されます（pg_hba.confの全変更も同様にリロード可能です）。
一方、listen_addresses、port、shared_buffers、max_connectionsのコンテキストはpostmasterであり、サーバープロセスの再起動（systemctl restart）が必須となります。
8. まとめと次回予告
postgresql.confはサーバーエンジン全体の動作方針を、pg_hba.confはクライアント接続のアクセス制御を司る。- 外部接続を許可するには、
listen_addresses = '*'の設定とOSファイアウォール（firewalld）のポート開放（TCP 5432）が必須となる。 pg_hba.confは上から順に評価され、最初に条件一致した行が適用されるため、限定的・厳格なルールを上に配置する。- 認証方式には平文やハッシュを通信経路に流さない強固な
scram-sha-256を採用する。 - パラメータ変更時は
pg_settingsのcontextを確認し、sighup（リロード）とpostmaster（再起動必須）を判別する。
次回は第4回「ロール・権限管理とデータベース作成のベストプラクティス」を解説します。スーパーユーザー（postgres）に依存しない業務ユーザーの作成、最小権限の原則に基づくGRANT構文、特定スキーマへのアクセス制限、およびパスワード失効管理を実機で整理します。
PostgreSQL 18 構築・運用ガイド
- 前の記事: 第2回「【AlmaLinux 10】AppStream vs PGDG公式RPM 比較検証と初期構築」
- 現在の記事: 第3回「postgresql.conf と pg_hba.conf の基本設計とアクセス制御」
- 次の記事: 第4回「ロール・権限管理とデータベース作成のベストプラクティス」
- シリーズ企画・目次: シリーズ総合ロードマップとカリキュラム一覧
エンタープライズSSL暗号化と証明書認証を書籍で習得する
本記事ではSCRAM-SHA-256によるパスワード認証とIP制限を解説しました。金融機関や政府機関水準のセキュリティ要件において必須となる「SSL/TLSによる通信経路の完全暗号化（hostssl設定）」および「クライアント証明書（cert認証）によるパスワードレス強固認証」、さらに詳細な操作証跡を記録する「pgaudit監査ログ設定」の実装手順については、Kindle書籍版『現場で困らない PostgreSQL 本番運用大全 —— 4ノード実機で作る高可用性・チューニング・障害復旧』第3章にて完全収録しています。
