如何保護開放的 PostgreSQL 埠
所以，情況就是這樣。看來我們需要一個開放的 TCP 埠 5432 到世界，客戶可以訪問他的 PostgreSQL 數據庫。
出於顯而易見的原因，我們不能只說“不”，只能作為最後的手段。
最大的煩惱是什麼？我如何保護我們的基礎設施？
不管怎樣：為什麼不向世界開放呢？我想，也許它比一些有 20 年曆史、無人維護的 FTP 伺服器更安全。
PS VPN 不行。可能會進行一些加密（如果我可以給他一個有效的 JDBC 連接 URL ）。
需要 SSL，保持 SELinux 開啟，監控日誌，並使用目前的 PostgreSQL 版本。
伺服器端
需要 SSL
在
postgresql.conf集合中ssl=on並確保您正確安裝了密鑰文件和證書文件（請參閱文件和 中的註釋postgresql.conf）。如果您想讓客戶端信任它而不需要在客戶端上進行特殊設置，您可能需要從 CA 購買證書。
在
pg_hba.conf使用類似的東西：hostssl theuser thedatabase 1.2.3.4/32 md5… 可能對使用者和/或數據庫使用“全部”，並且可能使用更廣泛的源 IP 地址過濾器。
限制可以登錄的使用者，拒絕遠端超級使用者登錄
如果可能，不要讓使用者“全部”；如果您可以避免需要，您不想允許超級使用者遠端登錄。
限制使用者權限
限制可以登錄的使用者的權利。不要給他們
CREATEDB或CREATEUSER權利。
REVOKE對所有數據庫的CONNECT權限PUBLIC，然後只將其歸還給應該能夠訪問該數據庫的使用者/角色。（將使用者分組為角色並將權限授予角色，而不是直接授予單個使用者）。確保具有遠端訪問權限的使用者只能連接到他們需要的數據庫，並且只能訪問他們實際需要的架構、表和列。這對本地使用者來說也是一種很好的做法，它只是明智的安全措施。
客戶端設置
要指示 JDBC 驅動程序嘗試建立 SSL 連接，您必須添加連接 URL 參數 ssl=true。
…並將伺服器證書安裝在客戶端的信任庫中，或者如果您不希望使用者必須安裝證書，則使用 Java 內置信任庫中的一個 CA 信任的伺服器證書。
正在進行的行動
現在確保讓 PostgreSQL 保持最新。PostgreSQL 只有幾個 pre-auth 安全漏洞，但這不僅僅是零，所以要保持最新狀態。無論如何，您都應該擁有錯誤修正。
如果您知道不需要訪問的大型網路塊/區域，請在前面添加防火牆。
記錄連接和斷開連接（請參閱 參考資料
postgresql.conf）。如果可行，記錄查詢。如果可行，請在前面執行入侵檢測系統或 fail2ban 或類似系統。對於使用 postgres 的 fail2ban，這裡有一個方便的操作方法監控日誌文件。
額外的偏執狂
需要考慮的額外步驟…
需要客戶端證書
如果需要，您還可以使用
pg_hba.conf要求客戶端提供伺服器信任的 X.509 客戶端證書。它不需要使用與伺服器證書相同的 CA，您可以使用自製的 openssl CA 來執行此操作。JDBC 使用者需要將客戶端證書導入他們的 Java 密鑰庫，keytool並可能配置一些 JSSE 系統屬性以將 Java 指向他們的密鑰庫，因此它不是完全透明的。隔離實例
如果您想真正偏執，請在單獨的容器/虛擬機中執行客戶端實例，或者至少在不同的使用者帳戶下執行，只使用他們需要的數據庫。
這樣，如果他們破壞了 PostgreSQL 實例，他們將不會再有任何進展。
使用 SELinux
我不應該說這個，但是…
執行支持 SELinux 的機器，如 RHEL 6 或 7，不要關閉 SELinux 或將其設置為許可模式。保持在強制模式。
使用非預設埠
只靠默默無聞的安全是愚蠢的。一旦你做了一些明智的事情，使用一點晦澀的安全性可能不會受到傷害。
在非預設埠上執行 Pg 會使自動攻擊者的生活更加困難。
在前面放一個代理
您還可以在 PostgreSQL 前面執行 PgBouncer 或 PgPool-II，充當連接池和代理。這樣您就可以讓代理處理 SSL，而不是真正的數據庫主機。代理可以在單獨的虛擬機或機器上。
無論如何，使用連接池代理通常是 PostgreSQL 的一個好主意，除非客戶端應用程序已經有一個內置池。大多數 Java 應用程序伺服器、Rails 等都有內置的池。即便如此，伺服器端池代理在最壞的情況下也是無害的。