Deciding on an SSL model ======================== PEMエージェントは、 :ref:`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ポリシーを使用する組織の制御が低下します。 .. Note for High Availability (HA) & Connection Pooling:: `1_blank_3_-` **HAクラスター** クラスターマネージャーEFMやRepmgrなどの干渉を回避するために、PEMはHAセットアップのノードを自動的に構成または再起動しません。 SSLを手動で構成する必要があります。`2_blank_2_-` **pgBouncer** pgBouncerを使用する場合、プーリングには単一の共有ユーザーが必要であるため、一般にsslutilsは推奨されません。以下を参照してください。 .. Note for High Availability (HA) & Connection Pooling:: `2_blank_1_-` **外部CAマニュアル** sslutilsに依存する代わりに、組織の承認されたCAによって署名された証明書を提供できます。独自の証明書を持ち込む場合、アーキテクチャには2つの選択があります。`2_blank_4_1.` **共通エージェントユーザ共有証明書** すべてのエージェントは、単一のPostgresユーザーと同じクライアント証明書/キーペアを共有します。 **長所** pgBouncerと唯一の互換性のある方法トランザクションはプールされる同じユーザーからである必要があるため。少数の証明書の管理がはるかに簡単になります。 **短所** 特定のエージェント接続を監査するのが困難です。証明書を失効すると、すべてのエージェントが切断されます。 2. **一意のエージェントユーザー個人の証明書** すべてのエージェントには、独自の一意の証明書と、対応する番号のPostgresユーザーたとえば、agent1、agent2などがあります。 **長所** 高い監査可能性。 1つの証明書を失効すると、1つのエージェントにのみ影響します。 **短所** 大量の証明書による多大な管理オーバーヘッド。 - **ローカルCA手動** sslutilsに依存する代わりに、PEMホストまたは他の場所でローカルCAを手動で構成し、それを使用してPEMサーバーとエージェントの証明書を発行できます。 上記の **外部CA** の場合と同じアーキテクチャの選択があります。 これは、sslutilsを使用できずpgBouncerを使用する予定がある場合、外部/組織CAがない場合にのみお勧めします。