SSL isteyin, SELinux'u açık tutun, günlükleri izleyin ve geçerli bir PostgreSQL sürümü kullanın .
Sunucu tarafı
SSL iste
Gelen
postgresql.confseti
ssl=onve (docs ve yorumları görmek için keyfile ve certfile uygun yüklü olduğundan emin olun
postgresql.conf).
İstemcide özel kurulum yapılmadan müşteriler tarafından güvenilmesini sağlamak için bir CA'dan sertifika satın almanız gerekebilir.
In
pg_hba.confgibi kullanım şey:
hostssl theuser thedatabase 22.214.171.124/32 md5
... muhtemelen kullanıcı ve / veya veritabanı için "tümü" ile ve daha geniş bir kaynak IP adres filtresi ile.
Giriş yapabilen kullanıcıları sınırlandırın, uzak kullanıcı girişini reddetme
Mümkünse kullanıcılar için "hepsine" izin verme; İhtiyaç duymamak için süper kullanıcı oturum açmalarına uzaktan izin vermek istemezsiniz.
Kullanıcıların sınır hakları
Giriş yapabilen kullanıcıların haklarını sınırlayın. Onlara
CREATEDBveya
CREATEUSERhaklar vermeyin .
REVOKE
CONNECTdoğru
PUBLICtüm veritabanları üzerinde, daha sonra veritabanına o erişebileceğini gereken tek kullanıcılar / rolleri geri vermek. (Kullanıcıları rollere ayırın ve doğrudan bireysel kullanıcılara değil rollere hak verin.)
Uzaktan erişime sahip kullanıcıların yalnızca ihtiyaç duydukları DB'lere bağlanabildiğinden ve yalnızca gerçekten ihtiyaç duydukları şemalar, tablolar ve sütunlar üzerinde haklara sahip olduklarından emin olun. Bu, yerel kullanıcılar için de iyi bir pratiktir, sadece mantıklı bir güvenliktir.
Müşteri kurulumu
PgJDBC'de şu parametreyi iletin
ssl=true :
JDBC sürücüsüne bir SSL bağlantısı kurmasını denemek için bağlantı URL parametresini ssl = true olarak eklemelisiniz.
... ve sunucunun sertifikasını müşterinin güvenilir mağazasına kurun veya kullanıcının sertifikayı yüklemesini istemiyorsanız, Java'nın yerleşik güvenilir deposundaki CA'lardan biri tarafından güvenilen bir sunucu sertifikası kullanın.
Devam eden aksiyon
Şimdi PostgreSQL'i güncel tuttuğunuzdan emin olun . PostgreSQL'in sadece birkaç ön-güvenlik güvenlik açığı vardı, ama bu sıfırdan fazla, bu yüzden güncel kal. Yine de yapmalısınız, hata düzeltmeleri olması gereken güzel şeyler.
Hiçbir zaman erişmeniz gerekmediğini bildiğiniz büyük bloklar / bölgeler varsa, önüne güvenlik duvarı ekleyin.
Bağlantıları ve bağlantıları kes
postgresql.conf. Pratik ise sorguları günlüğe yaz. Pratik bir izinsiz giriş tespit sistemi veya fail2ban veya benzeri bir cihaz çalıştırın. Postgres ile fail2ban için burada uygun bir nasıl yapılır
Günlük dosyalarını izleyin.
Bonus paranoya
Düşünmek için ekstra adımlar ...
İstemci sertifikaları gerektir
İsterseniz
pg_hba.conf, istemcinin sunucu tarafından güvenilen bir X.509 istemci sertifikası sunmasını istemek için de kullanabilirsiniz . Sunucu sertifikasıyla aynı CA'yı kullanmasına gerek yoktur, bunu bir homebrew openssl CA ile yapabilirsiniz. Bir JDBC kullanıcısının, istemci sertifikasını Java Anahtar Deposuna alması
keytoolve bazı JSSE sistem özelliklerini, Java'yı anahtar deposuna yönlendirmesi için yapılandırması gerekir, bu yüzden tamamen şeffaf değildir.
Örneği karantinaya al
Gerçekten paranoyak olmak istiyorsanız, istemciye, ayrı bir kapta / VM'de ya da en azından farklı bir kullanıcı hesabı altında, sadece ihtiyaç duydukları veri tabanları ile çalıştırın.
Bu şekilde PostgreSQL örneğini tehlikeye atarlarsa daha fazla elde edemezler.
SELinux kullanın
Bunu söylememeliydim, ama ...
RHEL 6 veya 7 gibi SELinux destekli bir makine çalıştırın ve SELinux'u kapatmayın veya izin verilen moda getirmeyin . Zorlama modunda tutun.
Varsayılan olmayan bir bağlantı noktası kullanın
Sadece belirsizliğin sağladığı güvenlik aptallıktır. Mantıklı şeyleri yaptıktan sonra biraz belirsizliği kullanan güvenlik muhtemelen zarar vermez.
Yaşamı otomatik saldırganlar için biraz zorlaştırmak için Pg'yi varsayılan olmayan bir bağlantı noktasında çalıştırın.
Öne bir proxy koy
PgBouncer veya PgPool-II'yi PostgreSQL'in önünde, bağlantı havuzu ve proxy olarak da çalıştırabilirsiniz. Bu şekilde, proxy'nin SSL'yi yönetmesine izin verebilirsiniz, gerçek veritabanı sunucusu değil. Proxy, ayrı bir VM'de veya makinede olabilir.
İstemci uygulamasında zaten yerleşik bir havuz yoksa, bağlantı havuzu proxy'lerinin kullanılması yine de PostgreSQL ile iyi bir fikirdir. Java uygulama sunucularının çoğu, Rails, vb. Dahili havuzlamaya sahiptir. O zaman bile, bir sunucu tarafı havuz proxy'si zararsızdır.