Deciding on an SSL model#

PEMエージェントは、 PEMアーキテクチャで詳細に説明しているように、libpqを使用してPEMバックエンドデータベースに直接接続するPostgresクライアントです。

通信を安全に管理および暗号化するために、PEMはPostgresバックエンドのネイティブSSL/TLS機能を活用します。

このセキュリティモデルが機能するには、次のコンポーネントを構成する必要があります。

エージェント認証 すべてのPEMエージェントには、割り当てられたPostgresユーザーの名前と一致するクライアント証明書が必要です。
ルート信頼 バックエンドPostgresサーバーをルートCAファイルで構成して、受信エージェント証明書を検証する必要があります。
サーバー暗号化 バックエンドPostgresサーバーには、データストリームを暗号化し、IDを確立するために独自のSSL証明書とプライベートキーが必要です。

ニーズとポリシーに応じて、これらの証明書とキーを提供するために使用できるさまざまなモデルがあります。以下の情報は、インストールを開始する前にどのモデルに従うかを決定するのに役立ちます。

証明書管理モデル#

自動sslutils経由 または 手動外部CAまたはローカルCAを使用 の2つの方法でセキュリティ証明書を処理するようにPEMを構成できます。適切なパスの選択は、インフラストラクチャの複雑さとコンプライアンスのニーズによって異なります。

sslutilsで自動化 sslutils拡張機能を活用することにより、PEMは独自の認証局CAとして機能します。エージェントが登録すると、PEMは必要なクライアント証明書を自動的に生成します。

以下の用途に最適速度と利便性が優先される標準の非HA展開。

欠点厳密な外部CAポリシーを使用する組織の制御が低下します。

長所 pgBouncerと唯一の互換性のある方法トランザクションはプールされる同じユーザーからである必要があるため。少数の証明書の管理がはるかに簡単になります。

短所特定のエージェント接続を監査するのが困難です。証明書を失効すると、すべてのエージェントが切断されます。

一意のエージェントユーザー個人の証明書 すべてのエージェントには、独自の一意の証明書と、対応する番号のPostgresユーザーたとえば、agent1、agent2などがあります。

長所高い監査可能性。 1つの証明書を失効すると、1つのエージェントにのみ影響します。

短所大量の証明書による多大な管理オーバーヘッド。

ローカルCA手動 sslutilsに依存する代わりに、PEMホストまたは他の場所でローカルCAを手動で構成し、それを使用してPEMサーバーとエージェントの証明書を発行できます。上記の 外部CA の場合と同じアーキテクチャの選択があります。これは、sslutilsを使用できずpgBouncerを使用する予定がある場合、外部/組織CAがない場合にのみお勧めします。