web-dev-qa-db-ja.com

SSLをPostgresql 9.6で常に使用していることを確認する方法

別のマシンにアプリサーバーとデータベースがあり、スレーブデータベースの場合は別のデータセンターにある機密アプリケーションがあります。

私のpostgresqlは常にsslを使用するように構成されていると思いますが、これを再確認する方法が必要です。

すべてのクライアント接続が実際にsslを使用するように強制されていることを確認する簡単な方法はありますか？

postgresqlpostgresql-9.6ssl
4
David Simic

非SSL接続は pg_hba.conf で無効にできます。

たとえば、次のように始まる場合があります。

# allow local connections through Unix domain sockets
local  all  all  peer

# allow non-encrypted local TCP connections with passwords
Host       all  all  127.0.0.1/32   md5
Host       all  all  ::1/128        md5

# reject any other non-encrypted TCP connection
hostnossl  all  all  0.0.0.0/0     reject
hostnossl  all  all  ::/0          reject

# other rules...

ルールは最初に一致するまで順番にテストされるため、これらのいずれかが一致した場合、これらのルール以降のルールは無効になります。

実行時に、どのセッションが暗号化されているかを確認するために、 pg_stat_sslシステムビュー があります（PostgreSQL 9.5以降）。そのpid列は pg_stat_activity への参照であり、usename、datname、client_addr...などの接続の識別に関連する可能性のある他の情報ビットを保持します。たとえば、次のクエリを使用できます。

SELECT datname,usename, ssl, client_addr 
  FROM pg_stat_ssl
  JOIN pg_stat_activity
    ON pg_stat_ssl.pid = pg_stat_activity.pid;
7
Daniel Vérité

pg_stat_ssl を参照して、クライアントがSSL経由で接続されていることを確認できます。 pg_hbaにバグがあると思われる場合でも、なぜpg_stat_sslをこれ以上信頼する必要があるのか​​はわかりません。ただし、これはクライアントがSSL経由で接続されていることだけを示していることに注意してください。クライアントが実際にサーバー証明書に対してフルベリファイを行ったかどうかをサーバーから知る方法はありません。 （またはもちろん、クライアントが正しいサーバーではなく敵対的なサーバーに接続している場合、正しいサーバーはこれを認識しません）。

クライアント側では、sslmode = verify-fullを使用するように構成します。この構成が有効であることをテストするには、名前を変更して接続が失敗することを確認して、一時的に〜/ .postgresql/root.crtを妨害することができます。設定ミスは簡単にできるため、sslmodeの設定を無視して常にverify-fullを実装する独自のクライアントをコンパイルする方が安全な場合があります。

0
jjanes