如何在UbuntuVPS上保护PostgreSQL
什么是 PostgreSQL？
PostgreSQL，也称为 postgres，是一种流行的数据库管理系统，用于处理许多网站和应用程序的数据。
在本指南中，我们将讨论一些保护 PostgreSQL 数据库的方法。 这将有助于防止未经授权或恶意使用您的数据。
我们将在 Ubuntu 12.04 VPS 上完成本教程中的步骤，但几乎每个现代发行版都应该以类似的方式运行。
安装
如果您当前尚未安装 PostgreSQL，则可以使用以下命令安装它：
sudo apt-get update sudo apt-get install postgresql postgresql-contrib
数据库软件现在应该安装在您的系统上。
对等身份验证
默认情况下，PostgreSQL 通过将 Linux 用户帐户与 PostgreSQL 帐户相关联来处理身份验证。 这称为“对等”身份验证。
安装后，Postgres 会创建一个名为“postgres”的 Linux 用户，可用于访问系统。 我们可以通过键入以下内容更改为该用户：
sudo su - postgres
从这里，我们可以通过键入以下内容连接到系统：
psql
请注意我们如何在没有密码的情况下进行连接。 这是因为 Postgres 已通过用户名进行身份验证，它假定它是安全的。
不要将Linux“postgres”用户用于访问数据库软件以外的任何事情。 这是一个重要的安全考虑。
通过键入以下内容退出 PostgreSQL 和 postgres 用户：
\q exit
不允许远程连接
删除潜在攻击向量的一种简单方法是不允许远程连接到数据库。 这是从 Ubuntu 存储库安装 PostgreSQL 时的当前默认设置。
我们可以通过查看基于主机的身份验证文件来仔细检查是否不允许远程连接：
sudo nano /etc/postgresql/9.1/main/pg_hba.conf
local all postgres peer local all all peer host all all 127.0.0.1/32 md5 host all all ::1/128 md5
我已经从上面的输出中删除了评论。
如您所见，前两个安全行将“本地”指定为它们适用的范围。 这意味着他们正在使用 Unix/Linux 域套接字。
后两个声明是远程的，但是如果我们查看它们应用到的主机（127.0.0.1/32 和 ::1/128），我们会看到这些是指定本地机器的接口。
如果您需要远程访问数据库怎么办？
要从远程位置访问 PostgreSQL，请考虑使用 SSH 连接到数据库机器，然后使用本地连接从那里连接到数据库。
也可以通过 SSH tunnel 访问 PostgreSQL，这样客户端机器就可以像本地一样连接到远程数据库。 您可以在此处了解如何通过 SSH 对 PostgreSQL 进行 隧道连接。
另一种选择是使用 SSL 证书 配置访问。 这将允许信息的加密传输。 您可以通过此链接学习 使用 PostgreSQL 设置 SSL。
PostgreSQL 中的安全性
虽然保护对提示的访问很重要，但保护 PostgreSQL 环境中的数据也很重要。 PostgreSQL 通过使用“角色”来实现这一点。
登录 PostgreSQL 以跟随本节：
sudo su - postgres psql
为每个应用程序创建单独的角色
确保在必要时可以分离用户和数据的一种方法是为每个应用程序分配不同的角色。
要创建新角色，请键入以下内容：
CREATE ROLE role_name WITH optional_permissions;
要查看您可以分配的权限，请键入：
\h CREATE ROLE
您可以通过键入以下内容来更改任何角色的权限：
ALTER ROLE role_name WITH optional_permissions;
通过键入以下内容列出当前角色及其属性：
\du
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------+-----------
hello | Create DB | {}
postgres | Superuser, Create role, Create DB, Replication | {}
testuser | | {}
创建一个新用户并为每个将使用 PostgreSQL 的新应用程序分配适当的权限。
将用户与功能分开
角色是一种处理权限的灵活方式。 它们共享用户和组的某些方面，并且可以像两者一样工作。 角色可以拥有其他角色的成员资格。
这为我们提供了一些解决权限的独特方法。
我们可以为用户分配 login 角色（例如我们上面谈到的应用程序角色），然后我们可以将这些角色分配到 access 角色中，以对数据执行实际功能。
这种权限分离使我们能够在更细粒度的级别上管理每个用户可以执行的操作。
为了测试这一点，让我们创建两个角色：
CREATE ROLE login_role WITH login; CREATE ROLE access_role; \du
List of roles
Role name | Attributes | Member of
-------------+------------------------------------------------+-----------
access_role | Cannot login | {}
login_role | | {}
postgres | Superuser, Create role, Create DB, Replication | {}
如您所见，我们有两个新角色，其中一个无法登录。
我们现在可以创建一个由“access_role”拥有的数据库：
CREATE DATABASE demo_application WITH OWNER access_role;
我们现在可以连接到数据库并锁定权限，只让“access_role”创建表：
\c demo_application REVOKE ALL ON SCHEMA public FROM public; GRANT ALL ON SCHEMA public TO access_role;
我们可以通过将用户更改为“login_role”并尝试创建一个表来测试这一点：
SET ROLE login_role;
CREATE TABLE test_table(
name varchar(25));
ERROR: permission denied for schema public
最后，我们可以将“login_role”作为成员添加到“access_role”。 这将允许它访问“access_role”具有的相同功能。
我们将角色重置为“postgres”，在“access_role”中授予“login_role”成员资格，然后重试该过程：
RESET ROLE;
GRANT access_role TO login_role;
SET ROLE login_role;
CREATE TABLE test_table(
name varchar(25));
CREATE TABLE
这行得通。
我们现在可以使用“login_role”登录并管理数据库。 这使得添加或撤销在该数据库上工作的能力变得容易。
结论
本文中讨论的方法只是开发您自己的安全策略的起点。 您的安全需求将是独一无二的，具体取决于不同的数据库用户以及您需要满足的流量数量和类型。
建议您在生产系统上实施任何安全措施之前研究它们的优点和缺点。 必须进行彻底的测试，以确保您已经实施了您正在寻找的控制，并且您没有意外限制您的软件的合法使用。
