Benötigen Sie SSL, lassen Sie SELinux aktiviert, überwachen Sie die Protokolle und verwenden Sie eine aktuelle PostgreSQL-Version .
Serverseite
SSL erforderlich
In postgresql.confReihe ssl=onund stellen Sie sicher , dass Ihre Schlüsseldatei und certfile angemessen (die Dokumentation und die Kommentare in sehen installiert postgresql.conf).
Möglicherweise müssen Sie ein Zertifikat von einer Zertifizierungsstelle kaufen, wenn Sie möchten, dass es von Clients ohne spezielle Einrichtung auf dem Client als vertrauenswürdig eingestuft wird.
In pg_hba.confGebrauch so etwas wie:
hostssl theuser thedatabase 1.2.3.4/32 md5
... möglicherweise mit "all" für Benutzer und / oder Datenbank und möglicherweise mit einem breiteren Quell-IP-Adressfilter.
Beschränken Sie die Anzahl der Benutzer, die sich anmelden können, und verweigern Sie die Anmeldung als Remote-Superuser
Erlaube nicht "alle" für Benutzer, wenn möglich; Sie möchten Superuser-Anmeldungen nicht remote zulassen, wenn dies nicht erforderlich ist.
Beschränken Sie die Rechte der Benutzer
Schränken Sie die Rechte des Benutzers (n) , die sich anmelden können. Sie sie nicht geben CREATEDBoder CREATEUSERRechte.
REVOKEKlicken Sie auf das CONNECTRecht von PUBLICin allen Ihren Datenbanken und geben Sie es dann nur den Benutzern / Rollen zurück, die auf diese Datenbank zugreifen dürfen. (Gruppieren Sie Benutzer in Rollen und erteilen Sie Berechtigungen für Rollen, nicht direkt für einzelne Benutzer).
Stellen Sie sicher, dass Benutzer mit Remotezugriff nur eine Verbindung zu den von ihnen benötigten DBs herstellen können und nur Rechte für die Schemas, Tabellen und Spalten haben, die sie tatsächlich benötigen. Dies ist auch für lokale Benutzer eine gute Praxis, es ist nur eine vernünftige Sicherheit.
Client-Setup
Übergeben Sie in PgJDBC den Parameterssl=true :
Um den JDBC-Treiber anzuweisen, eine SSL-Verbindung herzustellen, müssen Sie den Verbindungs-URL-Parameter ssl = true hinzufügen.
... und installieren Sie das Serverzertifikat im Truststore des Clients oder verwenden Sie ein Serverzertifikat, das von einer der CAs im integrierten Truststore von Java als vertrauenswürdig eingestuft wird, wenn der Benutzer das Zertifikat nicht installieren muss.
Laufende Maßnahmen
Stellen Sie nun sicher, dass Sie PostgreSQL auf dem neuesten Stand halten . PostgreSQL hatte nur ein paar Sicherheitslücken vor der Authentifizierung, aber das ist mehr als null. Bleiben Sie also auf dem Laufenden. Sie sollten trotzdem Bugfixes haben.
Fügen Sie eine Firewall voran, wenn es große Netblocks / Regionen gibt, von denen Sie wissen, dass Sie nie Zugriff benötigen.
Verbindungen und Verbindungen protokollieren (siehe postgresql.conf). Fragen protokollieren, falls sinnvoll. Führen Sie ein Intrusion Detection-System oder ein Fail2Ban-System oder ähnliches aus, falls dies sinnvoll ist. Für fail2ban mit Postgres, gibt es eine bequeme How-to hier
Überwachen Sie die Protokolldateien.
Bonus Paranoia
Zusätzliche Schritte zum Nachdenken ...
Client-Zertifikate anfordern
Wenn Sie möchten, können Sie auch festlegen pg_hba.conf, dass der Client ein vom Server als vertrauenswürdig eingestuftes X.509-Clientzertifikat vorlegt. Es muss nicht dieselbe Zertifizierungsstelle wie das Serverzertifikat verwendet werden. Sie können dies mit einer homebrew openssl-Zertifizierungsstelle tun. Ein JDBC-Benutzer muss das Client-Zertifikat mit in seinen Java-Keystore importieren keytoolund möglicherweise einige JSSE-Systemeigenschaften so konfigurieren, dass Java auf seinen Keystore verweist, sodass es nicht vollständig transparent ist.
Instanz unter Quarantäne stellen
Wenn Sie wirklich paranoid sein möchten, führen Sie die Instanz für den Client in einem separaten Container / einer separaten VM oder zumindest unter einem anderen Benutzerkonto mit nur den erforderlichen Datenbanken aus.
Auf diese Weise kommen sie nicht weiter, wenn sie die PostgreSQL-Instanz kompromittieren.
Verwenden Sie SELinux
Ich sollte das nicht sagen müssen, aber ...
Führen Sie einen Computer mit SELinux-Unterstützung wie RHEL 6 oder 7 aus und schalten Sie SELinux nicht aus und setzen Sie ihn nicht in den zulässigen Modus . Behalten Sie den Erzwingungsmodus bei.
Verwenden Sie einen nicht standardmäßigen Port
Sicherheit nur durch Dunkelheit ist Dummheit. Sicherheit, die ein wenig Dunkelheit verbraucht, wenn Sie die vernünftigen Dinge getan haben, wird wahrscheinlich nicht schaden.
Führen Sie Pg auf einem nicht standardmäßigen Port aus, um automatisierten Angreifern das Leben etwas zu erschweren.
Stell einen Proxy voran
Sie können auch PgBouncer oder PgPool-II vor PostgreSQL ausführen, das als Verbindungspool und Proxy fungiert. Auf diese Weise können Sie festlegen, dass der Proxy SSL verarbeitet, nicht den tatsächlichen Datenbankhost. Der Proxy kann sich auf einer separaten VM oder Maschine befinden.
Die Verwendung von Verbindungspooling-Proxys ist bei PostgreSQL im Allgemeinen sowieso eine gute Idee, es sei denn, die Client-App verfügt bereits über einen integrierten Pool. Die meisten Java-Anwendungsserver, Rails usw. verfügen über ein integriertes Pooling. Selbst dann ist ein Server-Side-Pooling-Proxy im schlimmsten Fall harmlos.