PostgreSQL 的审计和权限控制系统

背景介绍

GrowingIO 作为一家大数据公司，核心资产虽然在大数据平台上，但关系型数据库仍扮演着不可或缺的角色。它担负着存储产品逻辑，配置信息等重要数据信息。
GrowingIO 目前的数据库实例较多，例如按环境区分为开发环境，测试环境，生产环境等不同环境。按需求来说，又存在运维人员需要直接修改线上脏数据，开发人员本地访问开发环境的实例进行联调等情况。
而随着公司员工不断发展，人员的流动性会加剧，数据库权限控制会越来越复杂。
这时一个易用的数据库管理工具会减少相当大的工作量。
由于 GrowingIO 选用 PostgreSQL 作为关系型数据库，所以以下内容以 PostgreSQL 作为基础展开。

目前状况

之前 GrowingIO 是使用基于 SSH + Iptables + PostgreSQL 日志的组合架构来实现的 PostgreSQL 的管理。
这种架构只是满足了权限控制和审计的基本需求，但是实际使用中有些问题是很难解决，例如:

• 由于权限控制和日志审计属于独立的系统，造成审计的溯源比较麻烦。

• 权限控制比较粗粒度，只能控制能不能访问，无法做更细粒度的权限划分。

• 无法做到 SQL 级别的限制。

• 没有接到统一账号管理系统，账号管理繁琐。

由于以上种种原因，所以决定将该架构进行一次重构。

基于 PostgreSQL 审计和权限控制系统

前期准备

功能需求

• 不对 PostgreSQL 数据库做变更或者侵入较小。
• 支持 RBAC 权限控制。
• 使用 LDAP 作为 RBAC中的角色和用户认证系统。
• 有审计功能。
• 有 SQL 过滤的功能。 易于使用和管理。

工具调研

由于目前市面上主要数据库使用 MySQL 居多，而 PostgreSQL 使用的较少，扩展工具方面的资料相对较少。
目前找到的可行的方案是 PostgreSQL 本身的 LDAP 功能 + pgAudit 组合来达到权限和审计功能。
该方案可实现的功能包括:

• 基于 LDAP 的用户和角色认证。
• 基于 pgAudit 的日志审计功能。

该方案存在的问题:

• 需要操作 PostgreSQL 本身，对 PostgreSQL 本身有一定的侵入性。
• 各个 PostgreSQL
• 实例的管理还是割裂的状态。 后期功能扩展性不强。

由于该方案每个 PostgreSQL 实例的管理还是割裂的状态，当实例过多时仍会带来管理的复杂，对于不支持公网的实例仍需在 PostgreSQL 实例前端搭建一个 Pro